フィッシング攻撃を阻止するためにブラウザが最適な3つの理由

フィッシング攻撃は2025年においても組織にとって大きな課題です。実際、攻撃者がソフトウェアの脆弱性を利用するよりも、ますますアイデンティティベースの手法を利用するようになっているため、フィッシングはこれまで以上に大きな脅威となっています。

攻撃者はソフトウェアの脆弱性を利用するよりも、ますますアイデンティティベースの手法を利用するようになっており、フィッシングや盗まれた認証情報（フィッシングの副産物）が今や侵害の主な原因となっています。出典：Verizon DBIR

攻撃者は、従来のエンドポイントやネットワーク攻撃と同じ目的を達成できるため、フィッシングのようなアイデンティティ攻撃に目を向けています。被害者のアカウントにログインするだけで済むのです。そして、組織が今や何百ものインターネットアプリを使用しているため、フィッシングや盗まれた認証情報で狙われる可能性のあるアカウントの範囲は飛躍的に拡大しています。

MFAを回避するフィッシングキットが新常態となり、SMS、OTP、プッシュベースの方法で保護されたアカウントをフィッシングすることができるため、検出コントロールは予防コントロールが不足する中で常に圧力を受けています。

攻撃者は検出コントロールを回避しています#

フィッシングの検出とコントロールの強制は、主にメールとネットワーク層に焦点を当てています。通常、セキュアメールゲートウェイ（SEG）、セキュアウェブゲートウェイ（SWG）/プロキシ、またはその両方です。

しかし、攻撃者はこれを知っており、これらのコントロールを回避するための手段を講じています。具体的には：

IP、ドメイン、URLなどの一般的な署名要素を動的に回転させて更新することで、IoC駆動のブロックリストを定期的に回避します。
CAPTCHAやCloudflare Turnstileなどのボット保護を実装し、他の検出回避方法とともにフィッシングページの分析を防ぎます。
ページの視覚的およびDOM要素を変更し、ページが読み込まれた場合でも検出署名がトリガーされないようにします。

Cloudflare Turnstileのようなボットチェックを実装することは、サンドボックス分析ツールを回避する効果的な方法です

実際、マルチチャネルおよびクロスチャネル攻撃を展開することで、攻撃者はメールベースのコントロールを完全に回避しています。この最近の例を見てください。攻撃者がOnfidoを装い、悪意のあるGoogle広告（いわゆるマルバタイジング）を介してフィッシング攻撃を配信し、メールを完全に回避しました。

攻撃者は、IM、ソーシャルメディア、悪意のある広告を使用して被害者をターゲットにし、信頼されたアプリを使用してメッセージを送信することで、メールを回避しています

ここでメールベースのソリューションの限界を指摘する価値があります。メールには送信者の評判やDMARC/DKIMのような追加のチェックがありますが、これらは実際には悪意のあるページを識別しません。同様に、いくつかの最新のメールソリューションは、メールの内容のより深い分析を行っています。しかし…それは実際にはフィッシングサイト自体を識別するのに役立ちません（メールにリンクされている可能性があることを示すだけです）。これは、被害者を社会的にエンジニアリングすることを目的としたBECスタイルの攻撃にはるかに適していますが、上記で強調したように異なる媒体で開始された攻撃には役立ちません。

ブラウザベースの検出と応答がどのようにして競争の場を平準化できるか#

ほとんどのフィッシング攻撃は、ユーザーに悪意のあるリンクを配信することを伴います。ユーザーはリンクをクリックし、悪意のあるページを読み込みます。ほとんどの場合、悪意のあるページは特定のウェブサイトのログインポータルであり、攻撃者の目的は被害者のアカウントを盗むことです。

これらの攻撃は、ほぼ被害者のブラウザでのみ発生しています。したがって、ブラウザでアクセスされるフィッシングページを外部から見るメールやネットワークベースのコントロールを構築するのではなく、ブラウザ内にフィッシング検出と応答機能を構築することによって提供される大きな機会があります。

検出と応答の歴史を振り返ると、これは非常に理にかなっています。2000年代後半から2010年代初頭にかけてエンドポイント攻撃が急増したとき、主にネットワークベースの検出、ファイルの署名ベースの分析、サンドボックスでのファイルの実行を使用してマルウェアを検出しようとしていました（これはサンドボックス対応のマルウェアやコードに単純な実行遅延を入れるだけで信頼性を持って打ち破られました）。しかし、これはEDRに道を譲り、リアルタイムで悪意のあるソフトウェアを観察し、傍受するためのより良い方法を提示しました。

EDRは、エンドポイントへのトラフィックに依存するのではなく、OSレベルでのリアルタイム検出と応答を可能にしました。

ここでの鍵は、データストリーム内に入り込み、エンドポイントでの活動をリアルタイムで観察できるようにすることでした。

今日、私たちは同様の状況にあります。現代のフィッシング攻撃は、ブラウザを介してアクセスされるウェブページで発生しており、私たちが頼りにしているツール（メール、ネットワーク、さらにはエンドポイント）は必要な可視性を持っていません。彼らは外部から内部を見ています。

現在のフィッシング検出は、リアルタイムで悪意のある活動を観察して阻止するための適切な場所にありません。

しかし、もしブラウザ内で検出と応答を行うことができたらどうでしょうか？ここに、ブラウザがフィッシング攻撃を阻止するために最適な3つの理由があります：

#1: リンクではなくページを分析する#

一般的なフィッシング検出は、悪意のあるページではなく、リンクや静的HTMLの分析に依存しています。現代のフィッシングページはもはや静的HTMLではありません。ほとんどの他の現代のウェブページと同様に、これらはブラウザでレンダリングされる動的なウェブアプリであり、JavaScriptがページを動的に書き換え、悪意のあるコンテンツを起動します。これにより、ほとんどの基本的な静的チェックはページ上で実行される悪意のあるコンテンツを識別できません。

より深い分析がない場合、既知の悪いブロックリストに対してドメイン、URL、IPアドレスなどを分析することに依存しています。しかし、これらはすべて非常に使い捨てです。攻撃者はそれらを大量に購入し、正当なドメインを常に乗っ取り、一般的にそれらを多く通過させることを計画しています。現代のフィッシングアーキテクチャはまた、訪問者に提供されるリンクを継続的に更新されるプールから動的に回転させて更新することができ（したがって、リンクをクリックするたびに異なるURLが提供されます）、さらにはワンタイムマジックリンクのようなものを使用することさえあります（これにより、後でページを調査しようとするセキュリティチームのメンバーがそれを行うことができなくなります）。

最終的に、これはブロックリストがあまり効果的でないことを意味します。なぜなら、攻撃者が検出を作成するために使用されるインジケータを変更するのは簡単だからです。痛みのピラミッドを考えると、これらのインジケータは一番下に位置しています。これは、エンドポイントセキュリティの世界で何年も前から移行してきたものです。

しかし、ブラウザでは、レンダリングされたウェブページをそのまま観察することができます。ページ（およびその悪意のある要素）のはるかに深い可視性を持って、あなたは…

#2: IoCではなくTTPを検出する#

TTPベースの検出が行われている場合でも、それらは通常、ネットワークリクエストを組み合わせるか、サンドボックスでページを読み込むことに依存しています。

しかし、攻撃者は単にCAPTCHAやCloudflare Turnstileを使用したユーザーインタラクションを要求することで、サンドボックス分析を回避するのがかなり上手になっています。

Cloudflare Turnstileのようなボットチェックを実装することは、サンドボックス分析ツールを回避する効果的な方法です

たとえTurnstileを通過できたとしても、正しいURLパラメータとヘッダーを提供し、JavaScriptを実行して、悪意のあるページを提供される必要があります。これは、ドメイン名を知っている防御者が単純なHTTP(S)リクエストをドメインに送るだけで悪意のある行動を発見できないことを意味します。

そして、これだけでは不十分である場合、彼らは視覚的およびDOM要素を隠して署名ベースの検出がそれらを拾わないようにしています — したがって、ページに着陸できたとしても、検出がトリガーされない可能性が高いです。

プロキシを使用すると、ユーザーがページにアクセスして対話する際に生成されるネットワークトラフィックの一部を可視化できます。しかし、膨大な量の整理されていないネットワークトラフィックデータを扱う際に、特定のタブと関連付けられたユーザーがパスワードを入力したかどうかなどの重要なアクションを関連付けるのに苦労します。

しかし、ブラウザでは、次のようなすべての可視性が得られます：

完全に復号化されたHTTPトラフィック — DNSおよびTCP/IPメタデータだけでなく
完全なユーザーインタラクショントレーシング — すべてのクリック、キーストローク、DOMの変更をトレース可能
実行のすべてのレイヤーでの完全な検査、提供された初期HTMLだけでなく
ブラウザAPIへの完全なアクセス、ブラウザ履歴、ローカルストレージ、添付されたクッキーなどと関連付けるため

これにより、ページの動作とユーザーインタラクションに焦点を当てた高精度の検出を構築するために必要なすべてが得られます — これは、IoCベースの検出と比較して攻撃者が回避するのがはるかに難しいです。

ブラウザ内にいることで、TTPに基づいたはるかに効果的なコントロールを構築できます

そして、この新しい可視性を持つことで、ブラウザ内にいて、ユーザーがページと対話しているのと同時にページを見ているため、あなたは…

#3: 事後ではなくリアルタイムで傍受する#

非ブラウザソリューションでは、リアルタイムのフィッシング検出は基本的に存在しません。

最良の場合、プロキシベースのソリューションは、ユーザーがページと対話する際に生成されるネットワークトラフィックを通じて悪意のある行動を検出できるかもしれません。しかし、TLS暗号化後のネットワークリクエストを再構築する複雑さのため、これは通常、時間遅延で発生し、完全に信頼できるわけではありません。

ページがフラグ付けされると、通常、セキュリティチームによるさらなる調査が必要であり、誤検知を排除し、調査を開始します。これは、最良の場合で数時間、おそらく数日かかります。その後、ページが悪意のあるものとして特定され、IoCが作成されると、情報が配布され、TIフィードが更新され、ブロックリストに取り込まれるまでに数日、さらには数週間かかることがあります。

しかし、ブラウザでは、ユーザーがページを見ているときに、ブラウザ内からリアルタイムでページを観察しています。これは、ユーザーがフィッシングされて被害が発生する前に攻撃を検出し、傍受し、シャットダウンすることに関してのゲームチェンジャーです。これは、事後の封じ込めとクリーンアップから、リアルタイムでの事前妨害に焦点を変えます。

フィッシング検出と応答の未来はブラウザベースです#

Push Securityは、従業員のブラウザ内で発生するフィッシング攻撃を傍受するブラウザベースのアイデンティティセキュリティソリューションを提供します。ブラウザ内にいることは、フィッシング攻撃を検出し、傍受する際に多くの利点をもたらします。ユーザーが見るライブウェブページを、ユーザーが見るときに見ることができるため、ページ上で実行される悪意のある要素をはるかに良く可視化できます。また、悪意のある要素が検出されたときに発動するリアルタイムコントロールを実装することもできます。

フィッシング攻撃がPushを使用しているユーザーにヒットすると、配信チャネルに関係なく、私たちのブラウザ拡張機能はユーザーのブラウザで実行されているウェブページを検査します。Pushは、ウェブページがログインページであり、ユーザーがページにパスワードを入力していることを観察し、次のことを検出します：

ユーザーがフィッシングサイトに入力しているパスワードは、以前に別のサイトにログインするために使用されたことがあります。これは、パスワードが再利用されている（悪い）か、ユーザーがフィッシングされている（さらに悪い）ことを意味します。
ウェブページは、Pushによってフィンガープリントされた正当なログインページからクローンされています。
フィッシングツールキットがウェブページ上で実行されています。

その結果、ユーザーはフィッシングサイトとの対話をブロックされ、続行を防がれます。

これらは、攻撃者が回避するのが難しい（または不可能な）検出の良い例です — 被害者がフィッシングサイトに資格情報を入力できない場合、フィッシングすることはできません！Pushがフィッシング攻撃を検出し、ブロックする方法について詳しくはこちらをご覧ください。

Pushは、ブラウザで検出されたフィッシングページへのアクセスをユーザーに防ぎます。

詳細を知る#

それだけではありません — Pushは、クレデンシャルスタッフィング、パスワードスプレー、盗まれたセッショントークンを使用したセッションハイジャックなどの技術に対する包括的なアイデンティティ攻撃検出と応答機能を提供します。また、Pushを使用して、ゴーストログイン、SSOカバレッジのギャップ、MFAのギャップ、弱い、侵害された、再利用されたパスワード、リスキーなOAuth統合など、従業員が使用するすべてのアプリでアイデンティティの脆弱性を見つけて修正することもできます。

Pushが一般的なアイデンティティ攻撃技術を検出し、打ち破るのにどのように役立つかを知りたい場合は、ライブデモのために私たちのチームの一員と時間を予約するか、無料で試すためにアカウントを登録してください。クイックスタートガイドはこちらをご覧ください。