フィッシング検知は壊れている：ほとんどの攻撃がゼロデイと感じられる理由

フィッシング攻撃は、2025年においても組織にとって大きな課題である。実際、攻撃者はソフトウェアの悪用よりもIDベースのテクニックをますます活用するようになっており、フィッシングは間違いなくこれまで以上に大きな脅威となっています。

MFAをバイパスするフィッシング・キットは、SMS、OTP、およびプッシュ・ベースの方法で保護されたアカウントをフィッシングすることが可能であり、新常識となっています。

フィッシング検出における重要な課題は、業界として一般的にフィッシング・ページを検出するために使用している指標に基づくと、ほとんどすべてのフィッシング攻撃が異なって見え、ドメイン、URL、IP、ページ構成、ターゲット・アプリなどのユニークな組み合わせを使用していることです。事実上、どのフィッシング攻撃もまったく新しいものなのだ。それらを「ゼロデイ」と表現することもできるかもしれない（一斉に息を吸い込む合図）。

ここでの目的は、フィッシング攻撃をセンセーショナルに報道することではなく、その正反対である。むしろ、これはフィッシング検知コントロールの現状に光を当てるものである。率直に言って、もしすべてのフィッシング攻撃がゼロデイであるならば、これらの攻撃を検知する方法において何かが大きく間違っていることになる。

フィッシング検知101

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

フィッシングの検知は、その核心において、悪意のあるページとして特定されたフィッシング・ページに関連するIoC(indicator of compromise)で構成されるブロックリストに依存している。これらのIoCは攻撃に登場した悪意のあるドメイン、URL、IPで構成されている。

IoCはセキュリティ・ベンダーやサービス・プロバイダーによって様々なソースから収集される。しかし、ほとんどの場合、悪意のあるページがフィッシング・キャンペーンで使用されなければ、検知される可能性はない。つまり、被害者となる可能性のある人が何らかの形でそのページとやり取りをする必要があるのです。フィッシング攻撃に引っかかるか、疑わしいページとして報告するかのどちらかです。

一度ページにフラグが立てられれば、手動（セキュリティ担当者）または自動（製品/ツール）で調査することができる。ページにアクセスして分析し、悪意のあるコンテンツが見つかれば（詳細は後述）、そのページのIoCを収集し、ブロックリストに追加することができる。

この情報はその後、様々な脅威インテリジェンス・フィードやこの情報を活用するセキュリティ製品に流通し始める。フィッシングの検知と制御の大部分は電子メールとネットワークのレイヤーに焦点を当てている。

ここでの思考パターンに従っているのであれば、おそらく問題の根源がすでに見えていることだろう。フィッシング・ページを検知しブロックするためには、まず攻撃に使われる必要がある…

a.fl_button { background-color：#border：1px solid #3b59aa; color：#text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; margin：4px 2px; cursor: pointer; padding：12px 28px; } .fl_ad { background-color：#width: 95%; margin: 15px auto 15px auto; border-radius: 8px; border：1px solid #d6ddee; box-shadow: 2px 2px #728cb8; min-height: 200px; display: flex; align-items: center; } .fl_lef>a>img { margin-top: 0px !important; } .fl_rig>p { font-size: 16px; } .grad-text { background-image: linear-gradient(45deg, var(–dawn-red), var(–iris)54%, var(–aqua)); -webkit-text-fill-color: transparent; -webkit-background-clip: text; background-clip: text; } .fl_rig h2 { font-size: 18px!important; font-weight: 700; color：color: #333; line-height: 24px; font-family：font-family: Georgia, times new roman, Times, serif; display: block; text-align: left; margin-top: 0; } .fl_lef { display: inline-block; min-height: 150px; width: 25%; padding：10px 0 10px 10px; } .fl_rig { padding：10px; display: inline-block; min-height: 150px; width: 100%; vertical-align: top; } .fl_lef>a>img { border-radius: 8px; } .cz-news-title-right-area ul { padding-left: 0px; } @media screen and (max-width: 1200px) { .fl_ad { min-height: 184px; } .fl_rig>p { margin: 10p10px; } .fl_rig { padding：0 10px 10px 10px; width: 100%; } } @media screen and (max-width: 400px) { .cz-story-navigation ul li:first-child { padding-left: 6px; } .cz-story-navigation ul li:last-child { padding-right: 6px; } } }.

ほとんどのフィッシング攻撃がまったく新しい理由

攻撃者は、フィッシングの検知とブロックがブロックリストに依存していることを知っています：

• ドメイン、URL、IPのようなIoCのブロックリストに頼る

• 電子メールとネットワークのレイヤーに位置する

• ブロックする前にページにアクセスし、分析する必要がある。

これらの方法は、10年以上ほとんど変わっていない。そのため、攻撃者はこれらを回避することに長けている。

攻撃者がIoCベースの検知を回避するのは簡単だ。

フィッシング・ドメインはもともと使い捨てのものだ。攻撃者はフィッシング・ドメインを大量に購入し、合法的なドメインを常に乗っ取り、多くのフィッシング・ドメインを利用することを想定している。

最新のフィッシング・アーキテクチャは、一般的に特徴的な要素を動的にローテーションさせ、更新することもできる。例えば、訪問者に提供されるリンクを継続的にリフレッシュされたプールから動的にローテーションさせたり（リンクをクリックする人ごとに異なるURLが提供されるように）、ワンタイム・マジック・リンクのようなものを使用することさえできる（これは、後でそのページを調査しようとするセキュリティ・チームのメンバーが調査できないことを意味する）。

ユーザーがどのIPアドレスに接続しているかを調べることもできるが、最近では攻撃者がクラウドホスティングサーバーに新しいIPを追加するのは非常に簡単だ。ドメインがknown-badのフラグを立てられた場合、攻撃者は新しいドメインを登録するか、すでに信頼されているドメイン上のWordPressサーバーを侵害するだけでよい。攻撃者は自分のドメインがいつか焼かれることをあらかじめ計画しているため、この2つのことが大規模に起こっている。

結局のところ、これはブロックリストがそれほど効果的ではないということを意味する。なぜなら、攻撃者にとって、検知を作り出すために使用される指標を変更することは些細なことだからだ。苦痛のピラミッド」について考えてみると、このような指標は、エンドポイント・セキュリティの世界では何年も前から遠ざかっているような、まさに一番下に位置している。

フィッシングは電子メールだけで行われるわけではない

Eメールによる検知を回避するため、攻撃者は複数のチャネルを横断して攻撃を仕掛けています。

攻撃者はさまざまなフィッシング・ベクターを使用しているだけでなく、セキュリティ・ツールによるリンクの遮断を防ぐために、それらを連鎖させている。例えば、ソーシャルメディアのメッセージにリンクが埋め込まれた悪意のないPDFを送信し、最終的に悪意のあるウェブページに誘導するといった具合だ。

電子メールベースのソリューションの限界も指摘しておく価値がある。電子メールには送信者のレピュテーションやDMARC/DKIMのような追加チェック機能がありますが、実際には悪意のあるページを特定することはできません。同様に、最近の電子メールソリューションの中には、電子メールのコンテンツをより深く分析するものもあります。しかし…それはフィッシング・サイトの特定にはあまり役立たない（メールにリンクされている可能性があることを示すだけ）。これは、被害者を悪意のあるページにリンクさせることとは対照的に、被害者をソーシャル・エンジニアリングすることを目的としたBECスタイルの攻撃にはるかに適している。また、上記で取り上げたように、異なる媒体で行われる攻撃については、これでもまだ役に立ちません。

いずれにせよ、最新の電子メール・ソリューションはより多くのことをもたらすことができるが、電子メールもネットワーク（プロキシ）ベースのツールも、ページにアクセスしてそれを分析しない限り、そのページが悪意あるものであることを明確に知ることはできない。

攻撃者はページの解析を妨げている

Eメールもネットワーク（プロキシ）ベースのソリューションも、リンクがクリックされた（あるいはEメールの受信箱に届いた）時に実行されるIoCが生成された後、悪意があるかどうかを識別するためにページを検査し、分析できることに依存している。

最近のフィッシング・ページは静的なHTMLではなく、他のほとんどの最新のウェブ・ページと同様に、ブラウザでレンダリングされる動的なウェブ・アプリケーションであり、JavaScriptが動的にページを書き換えて悪意のあるコンテンツを起動する。つまり、ほとんどの基本的な静的チェックでは、ページ上で実行されている悪意のあるコンテンツを特定することができないのだ。

この問題に対処するため、電子メール・セキュリティ・ツールもネットワーク・セキュリティ・ツールも、サンドボックス内でリンクを爆発させ、ページの動作を観察しようとする。しかし攻撃者は、CAPTCHAやCloudflare Turnstileでユーザーとのインタラクションを要求するボットプロテクションを実装するだけで、これを回避している。

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

また、これだけでは不十分な場合、シグネチャベースの検知に引っかからないよう、視覚的要素とDOM要素の両方を難読化している。

フィッシング攻撃が斬新なのは、フィッシング検出が死後だからだ。

このような検知回避や難読化のテクニックの結果、リアルタイムのフィッシング検知は基本的に存在しない。

せいぜい、プロキシベースのソリューションが、ユーザーがページとやりとりすることによって生成されるネットワーク・トラフィックを介して悪意のある行動を検出できる程度かもしれない。しかし、TLS暗号化後のネットワーク・リクエストの再構築は複雑であるため、これは通常、時間的な遅れで起こり、完全に信頼できるものではない。

ページがフラグを立てられた場合、通常、誤検知を除外し、調査を開始するために、セキュリティチームによる更なる調査が必要となります。これにはせいぜい数時間、おそらく数日かかる。そして、一旦ページが悪意あるものとして識別され、IoCが作成されると、情報が配信され、TIフィードが更新され、ブロックリストに取り込まれるまで、数日から数週間かかることさえある。

その結果フィッシングの検知は本質的に死後に行われるため、ほとんどのフィッシング攻撃はまったく新しいものである。どのようにして悪事が知られるようになるのか?ユーザーがフィッシングされたとき…

フィッシング検知を修正するにはリアルタイム分析が必要だ

フィッシング攻撃を検知し、ブロックする方法に根本的な欠陥があることは明らかです。良いニュースは、我々は以前にもここにいたことがあるということだ。

2000年代後半から2010年代前半にかけてエンドポイントへの攻撃が急増したとき、マルウェアは主にネットワーク・ベースの検知、ファイルのシグネチャ・ベース分析、サンドボックス内でのファイルの実行（サンドボックスを認識するマルウェアやコードに実行遅延を設けるといった単純な方法で確実に撃破された）などで防御側がマルウェアを検知しようとしていたことを利用した。しかし、これはリアルタイムで悪意のあるソフトウェアを観察し、阻止する優れた方法を提示するEDRに道を譲った。

ここで重要なのは、エンドポイント上のアクティビティをリアルタイムで観察できるように、データ・ストリームの内部に入り込むことだった。

今日、我々は同じような立場にいる。最近のフィッシング攻撃はブラウザ経由でアクセスされるウェブページ上で起こっており、私たちが依存しているツール（電子メール、ネットワーク、さらにはエンドポイント）は必要な可視性を持っていない。彼らは外側から内側を見ているのだ。

多くの意味で、ブラウザは新しいオペレーティング・システムである。ブラウザは現代の仕事の主な舞台であり、攻撃もそこで起きている。

フィッシング攻撃を未然に防ぐには、ユーザーがブラウザの内側から見ているページをリアルタイムで観察できる必要がある。サンドボックスの中ではなく、ユーザーと同時に実際のページを見るのだ。そうして初めて、攻撃者が常に2歩先を進んでいる現在の猫とネズミのゲームを超えてフィッシングを行うために必要な検知と封じ込めのコントロールを構築することができる。

フィッシング検知と対応の未来はブラウザ・ベース

プッシュ・セキュリティは、ブラウザベースのアイデンティティ・セキュリティ・ソリューションを提供しています。フィッシング攻撃を検知し、阻止する上で、ブラウザにあることは多くの利点をもたらします。ユーザーが見ているウェブページをそのまま見ることができるため、ページ上で実行されている悪意のある要素をより正確に把握することができます。また、悪意のあるエレメントが検出された際に、リアルタイムで制御を行うことができます。

Pushを使った場合と使わない場合のフィッシング攻撃を比較すると、明らかな違いがあります。

ここでは、攻撃者がWordPressブログをハッキングして評判の良いドメインを取得し、ウェブページ上でフィッシング・ツールキットを実行します。そして、そのリンクを従業員にメールします。SWGやEメールスキャンソリューションはサンドボックス内でこのリンクを検査しますが、フィッシングキットはこれを検知し、良性のサイトにリダイレクトして検査を通過させます。

ユーザーはリンク付きのメールを受け取り、自由にフィッシング・ページにアクセスすることができます。ユーザーは自分の認証情報とMFAコードをページに入力すると、ほら！攻撃者は認証されたセッションを盗み、ユーザーのアカウントを乗っ取る。

しかし、Pushを使えば、我々のブラウザー拡張機能がユーザーのブラウザーで実行されているウェブページを検査する。Pushは、ウェブページがログインページであり、ユーザーがパスワードを入力していることを検知します：

• ユーザーがフィッシング・サイトに入力しているパスワードは、以前別のサイトにログインするために使用されたものである。これは、パスワードが再利用されている(悪い)か、ユーザーがフィッシングされている(さらに悪い)ことを意味する。

• ウェブページは、Pushによってフィンガープリントされた正規のログインページからクローンされている。

• フィッシングツールキットがウェブページ上で実行されている。

その結果、ユーザーはフィッシング・サイトとのやり取りをブロックされ、続行できなくなる。

フィッシングサイトに認証情報を入力できなければ、被害者をフィッシングすることはできません！

Pushがどのようにフィッシング攻撃を検知し、ブロックするかについては、こちらをご覧ください。

さらに詳しく

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

Pushがどのように一般的なID攻撃テクニックを検出し、打ち負かすかについて詳しくお知りになりたい場合は、弊社チームのライブデモをご予約いただくか、アカウントを登録して無料でお試しください。

クイックスタートガイドをご覧ください。

Push Securityがスポンサーとなり、執筆しました。