攻撃者は、ソーシャルメディア、インスタントメッセージングアプリ、悪意のある検索エンジン広告など、メール以外の配信チャネルを使ってフィッシングリンクを送信するケースが増えています。この記事では、なぜフィッシング攻撃がメールベースの配信に限定されなくなってきているのか、そしてそれがセキュリティチームにとって何を意味するのかを探ります。
フィッシングはメールボックスの外へ移動した
働き方の変化により、従業員はこれまで以上に外部の攻撃者からアクセスしやすくなっています。かつては、メールが外部との主なコミュニケーションチャネルであり、業務はローカル（自分のデバイスやロックダウンされたネットワーク環境内）で行われていました。そのため、セキュリティの観点からはメールとエンドポイントが最優先事項でした。
しかし今では、現代の業務は分散型のインターネットアプリのネットワーク上で行われ、メール以外にも多様なコミュニケーションチャネルが存在するため、ユーザーが悪意のあるコンテンツとやり取りするのを防ぐのが難しくなっています。
攻撃者は、インスタントメッセージアプリ、ソーシャルメディア、SMS、悪意のある広告、アプリ内メッセージ機能を使ってリンクを配信できるほか、SaaSサービスから直接メールを送信してメールベースのチェックを回避することもできます。同様に、企業ごとに数百ものアプリがターゲットとなり、それぞれアカウントセキュリティの設定レベルも異なります。
なぜこの話をあまり耳にしないのか？
メール以外でのフィッシング攻撃は、通常報告されません。これは、業界のフィッシング攻撃に関するデータのほとんどがメールセキュリティベンダーやツールから得られているため、当然のことです。
フィッシングがメール層を回避した場合、ほとんどの組織はユーザーからの攻撃報告に頼るしかありません。一部の組織はウェブプロキシで補完することもありますが、これらも最新のフィッシングキットによって回避されつつあります。これらのキットは、さまざまな難読化や検出回避技術を使って検知をすり抜けます。
今日のセキュリティチームにとって最も価値のある情報は、ネットワークトラフィックを通じて読み込まれるウェブページです。HTML本体はどのようなものか？ユーザーはページ上で何を見ている可能性が高いのか？これを行うには、ネットワークデータを見てブラウザが何をしているかをつなぎ合わせて再構築する必要があります。ごく単純なウェブサイトを除き、これはクライアント側のJavaScriptによって行われます。
これは一般的なSaaSアプリを分析するだけでも十分難しい作業です。しかし、最新世代の完全カスタマイズ型「Attacker-in-the-Middle（AitM）」フィッシングキットは、DOM難読化、ページ難読化、コード難読化などの技術を使い、ネットワーク層で見えるのは乱雑で難読化されたJSコードの塊だけになるよう、あえて解析を困難にしています。
つまり、メール以外のフィッシングは技術的なコントロールをすり抜けて広く見逃されています。たとえユーザーが発見して報告したとしても、実際に何ができるでしょうか？
ソーシャルメディアでのフィッシングを例にとりましょう。自社のユーザー基盤の中で他にどのアカウントがターゲットにされたか、または被害に遭ったかを把握できません。メールと違い、同じメッセージが複数ユーザーに届いた場合にリコールや隔離する方法もありません。変更できるルールやブロックできる送信者もありません。アカウントを報告することはできますが、サイト運営者が対応する頃には攻撃者はすでに目的を達成し、次のターゲットに移っているでしょう。
ほとんどの組織は関与したURLをブロックするだけです。しかし、攻撃者がフィッシングドメインを素早くローテーションしている場合、1つのサイトをブロックする頃にはすでに別の3つが登場しています。
これらは個人アカウントだけの問題では？
現代のフィッシング攻撃は、企業と個人の境界を曖昧にします。実際、従業員は業務用デバイスで個人のメッセージングやソーシャルメディアアプリに日常的にアクセスしています。
ユーザーはLinkedIn、X（旧Twitter）、WhatsApp、Signal、Redditのような掲示板などのアプリに、業務用ノートPCやモバイルデバイスでサインインしています。また、検索エンジン上の悪意のあるリンク（いわゆるマルバタイジング）もあり、通常のウェブ閲覧中に偶然アクセスしてしまうこともあります。
要するに、ユーザーが組織外の誰かから連絡を受ける可能性がある場所なら、どこでもフィッシングの機会が存在します。実際、こうしたケースでは、知らない人から連絡が来ることが当たり前だと考えている人も多いのです。
また、これらのプラットフォーム上ではキャンペーンが同じようにターゲット化できない、つまりよりランダムで危険性が低いというのも誤解です。たとえば、ソーシャルメディアアカウントは攻撃者が大量に作成したり乗っ取ったりするのが非常に簡単です。
最新のVerizon DBIRによると、インフォスティーラーログで発見された認証情報の60％以上がソーシャルメディアサイトのものでした。また、これらは単一要素認証であることが多いです。攻撃者が1つのアカウントを乗っ取り、それを使って従業員に信頼できる形で連絡できれば、一般的な迷惑メールよりもはるかに成功率が高くなります。
悪意のある広告もターゲット化できます。たとえば、Google広告は特定の地理的ロケーションからの検索や、特定のメールドメイン、特定のデバイスタイプ（デスクトップ、モバイルなど）に合わせて配信できます。
ターゲット組織の所在地が分かれば、その場所に合わせて広告を調整できます。フィッシングサイトには条件付き読み込みパラメータが付いていることも多く、特定の条件下（例：特定のメールキャンペーンリンクから来た場合、特定の組織・ブラウザ・IPレンジの場合のみ）で悪意のあるペイロードを配信します。
たとえ攻撃者が従業員の個人デバイスにしか到達できなかったとしても、それが企業アカウントの侵害につながることもあります。2023年のOkta侵害事件では、Oktaの従業員が業務用デバイスで個人のGoogleプロファイルにサインインしていたことが悪用されました。
これにより、ブラウザに保存された認証情報がすべて個人デバイスと同期され、カスタマーサポートシステムのサービスアカウント（134の顧客テナントへのアクセス権を持つ）も含まれていました。個人デバイスがハッキングされると、業務用の認証情報もすべて流出したのです。
このように、メール以外のフィッシングでもターゲット型の攻撃キャンペーンにつながる可能性は十分にあります。むしろ、攻撃者にとってはメール送信者の信頼構築などの下準備をするよりも、これらの非メールキャンペーンを展開する方が手間が少ないとも言えるでしょう！
ケーススタディ：LinkedInスピアフィッシング
攻撃者は最近、テック企業の幹部をターゲットにしたLinkedInスピアフィッシングキャンペーンを実施しました。 被害者は、別の幹部からのダイレクトメッセージで偽の投資話を持ちかけられました。送信者のアカウントは乗っ取られ、ハイバリューターゲットへの接触に利用されていました。
攻撃は、正規サイト（Google Sites、Google Search、Microsoft Dynamicsなどの検知回避テクニックでよく使われる）にホストされたカスタムページの連鎖を経て、Google Workspaceを装ったAttacker-in-the-Middleフィッシングページ、さらにセッション窃取型AitMフィッシングページへと誘導されました。
ケーススタディ：Google検索マルバタイジング
ある企業がターゲット型Google広告の被害に遭いました。この広告は非常に説得力のある見た目で、正規の広告より上位に表示されていました。多くのユーザーがブックマークではなく検索でログインページを探すという事実を悪用したものです。
このケースでは、攻撃者はレンタル可能なサブドメイン（us[.]com）を利用し、リンクを非常に正規に見せかけていました。実際のURLとの違いはごくわずかで、見落としやすいものでした。
本物のログインページではなく、被害者はセッション窃取型AITMページに誘導されました。
この攻撃は後にScattered Spiderキャンペーンに関連していることが判明しました。
攻撃者は侵害したアカウントで何ができるのか？
現代のフィッシングによる侵害については、より大きな視点で考えることが重要です。
ほとんどのフィッシング攻撃は、MicrosoftやGoogleなどの主要なエンタープライズクラウドプラットフォームや、Oktaのような専門のIDプロバイダーを狙います。これらのアカウントを乗っ取ることで、該当アプリ内のコアアプリやデータへのアクセスだけでなく、SSOを利用して従業員がそのアカウントでログインしている他の接続アプリにもサインインできるようになります。
これにより、攻撃者は組織内のほぼすべての主要なビジネス機能やデータセットにアクセスできます。そしてこの時点から、SlackやTeamsのような内部メッセージアプリや、SAMLjackingのような手法を使って、他のユーザーがログインしようとするアプリをウォータリングホール化するなど、他のユーザーを狙うのがはるかに容易になります。
たった1つのアカウント侵害が、数百万ドル規模の組織全体の侵害へと急速に発展する可能性があります。
組織はメール以外のフィッシングにどう対応できるか？
従来のアンチフィッシングツールセットは、フィッシングの進化についていけていないのは明らかです。
現代のフィッシング攻撃に対処するには、すべてのアプリと配信ベクトルにわたってフィッシングを検知・ブロックできるソリューションが必要です。
Push Securityはリダイレクトのトリックを検知したり、古いドメインTIフィードに頼ったりしません。どの配信チャネルやカモフラージュ手法が使われても関係なく、Pushはユーザーがウェブブラウザでページを読み込み・操作する際にリアルタイムで攻撃を特定し、ブロックします。
Pushのブラウザベースのセキュリティプラットフォームは、AiTMフィッシング、クレデンシャルスタッフィング、ClickFixing、悪意のあるブラウザ拡張機能、盗まれたセッショントークンを使ったセッションハイジャックなどの手法に対して、包括的なID攻撃検知・対応機能を提供します。
Pushについて詳しくは、最新の製品概要をご覧いただくか、弊社チームとのライブデモをご予約ください。
スポンサー提供・執筆：Push Security