AIを活用したフィッシングが、なぜブロックリストを完全に無力化したのか

ブロックリストは、AIが登場する以前からすでに劣勢に立たされていました。フィッシングドメインの寿命は年々短くなり、攻撃キャンペーンはインフラをこれまで以上のスピードで使い捨てるようになっています。ブロックリストと攻撃キャンペーンとの間のギャップは開き続けており、AIはその流れにとどめを刺した格好です。

攻撃者はAIを使い、スクリーンショットから数分でフィッシングページを生成し、どんなブロックリストも追いつけない速さでインフラを立ち上げては破棄し、指標ベースの検知を事実上無力化するペースでツールを次々と改良しています。 

フィッシングドメインの89%は稼働期間が2日未満となっており、15日を超えて生き残るのはわずか6.5%にすぎません。あるドメインがブロックリストに掲載される頃には、そのキャンペーンはすでに次へと移行し、インフラも別物に置き換わっています。

AiTMフィッシング、デバイスコードフィッシング、ClickFix、ファイルダウンロード、不正広告(マルバタイジング)など、悪意あるWebページ経由の攻撃に対する主要な防御策が既知の不正指標とのマッチングに依存しているのであれば、常に二歩遅れを取ることになります。

使い捨て前提の設計

問題は、フィッシングインフラの入れ替わりが速いことだけではありません。現代の攻撃は、そもそも使い捨てられることを前提に設計されているのです。攻撃者は検知されるのを待ってから移行するのではなく、検知を先回りする形で自らページを能動的に破棄し、新たなページを立ち上げています。各インフラを、デフォルトで一度きりの使用と割り切って扱っているのです。

攻撃者はまた、稼働中のインフラを解析しにくくする工夫も凝らしています。Cloudflare Workers、Railway、Vercel、Microsoft Dynamics、SharePoint、Adobe、Google Firebase、Google Sites、Jotform、Linode、Azure、Cloudflare、Atlassianなど、信頼されたホスティングプラットフォームの悪用が常態化しており、これにボット対策やスクリーニングチェック、複雑なリダイレクトチェーンを組み合わせることで、研究者や自動スキャナーを排除しています。 

Push Securityが検知したブラウザ内攻撃の95%が何らかのボット対策を用いており、多くの場合はリファラーチェックやブラウザフィンガープリンティングと併用されています。クローラーが目にするページと、実際の被害者が目にするページは、しばしば別物なのです。そして、かつて悪意あるページだった場所(攻撃者が新規に立ち上げたものであれ、既存サイトを侵害したものであれ)にたどり着いた頃には、その不正ペイロードはすでに稼働を停止している可能性があります。 

AIはまた、ページそのものを作成するコストも劇的に下げました。攻撃者は以前からページの複製に長けていましたが、今では正規のログインページのスクリーンショット一枚から、AIによる「バイブコーディング」でフィッシングサイト全体を作り上げることができます。見た目は本物そっくりでありながら、コードベースは完全にオリジナルで元のページとは似ても似つかず、静的解析でフィンガープリントを取る手がかりも残りません。

さらにフィッシングの配信手法も、AIチャットボットの共有機能、検索広告の掲載枠、アプリ内メッセージ、アプリ生成のメールといった正規サービスの悪用が増えており、どんなブロックリストも問題視しないようなプラットフォームのドメイン評価をそのまま引き継いでいます。

結果として、ブロックリストに指標を追加する行為は、最初から不利なルールで行うモグラ叩きのようなものになっています。

ツール層も崩壊しつつある

長年にわたり、David Bianco氏の「Pyramid of Pain」の中間層は、より持続性のある検知面を提供してきました。個々のドメインをブロックする代わりに、フィッシングキットのJavaScript構造やHTMLパターン、コードシグネチャをフィンガープリント化することで、インフラが入れ替わっても数十から数百のキャンペーンにわたって有効な検知ルールを書くことができたのです。

しかし、この層も崩れ始めています。フィッシングキットのエコシステムは今や、フォーク、AI支援の開発、オープンソース的なコード共有によって、誰も追跡しきれないスピードで細分化しています。 

その最も分かりやすい例がデバイスコードフィッシングです。2024年にロシア関連キャンペーンで初期採用が見られてから、本格的に普及するまでには2026年までかかりましたが、その時点で犯罪者向けキットは野生でゼロだった状態から一気に25種類以上(さらに増加中)にまで急増しました。

EvilTokens(稼働開始から最初の5週間で340以上の組織を標的に)、Kali365(FBIの注意喚起の対象にもなりました)、ARToken、DEBULL、Forg365といった犯罪者向けPhaaS(Phishing-as-a-Service)キットの多くが、この機能を提供しています。Tycoon 2FAのような既存のAiTMベンダーも、従来の認証情報窃取機能に加えてデバイスコードフィッシングを追加しており、環境やターゲットの挙動に応じてペイロードを動的に切り替えるキットも最近確認されています。例えば、まずデバイスコードフィッシングを試み、タイムアウトした場合にAiTMへとフォールバックする、といった具合です。

こうしたキットの多くは、攻撃者側が操作する管理パネルによって制御されており、ペイロードそのものやその配信タイミングを完全にコントロールできます。音声を使ったソーシャルエンジニアリングと組み合わせて使われることも多く、管理者が操作した場合にのみ悪意あるページを「有効化」する仕組みになっています。

これにより、こうしたページが事前にフラグ付けされてブロックされる可能性はさらに低くなります。標的型攻撃の中で数回しか観測されないまま、次のインフラへと入れ替わってしまうこともあるのです。 

Push Securityが最近開催したウェビナー(現在オンデマンドで視聴可能)では、VP R&DのLuke Jennings氏が、自前のPhaaSキットをいかに簡単にバイブコーディングできるかを実演しています。

実際に生き残るもの:攻撃手法

真に新しい攻撃手法を発見するには、依然として人間の創意工夫が欠かせません。正規のプロトコルや機能をどう悪用できるかというギャップを見つけ出し、それを実際に運用可能な形にする必要があるからです。この種のイノベーションは自動化されておらず、攻撃手法の仕組みそのものを軸に構築された検知ルールは、インフラの入れ替わりやツールの乱立、キットの細分化を乗り越えて生き残ることができます。

AiTM(Adversary-in-the-Middle)フィッシングを例に取りましょう。Tycoon、Sneaky 2FA、Evilginx、あるいは無数のフォークや派生版(野生で75種類以上のキットを追跡しています)を含め、あらゆるAiTMキットは基本的に同一のインターセプト技術を実装しています。すなわち、被害者のセッションを攻撃者が管理するインフラ経由でプロキシし、認証情報やMFAトークンをリアルタイムで中継し、認証済みセッションを窃取するというものです。

フロントエンドは多様で、インフラも入れ替わりますが、インターセプトの動作メカニズムという部分は変わりません。

ClickFixについても同様のことが言えます。おとりが偽のCAPTCHA(CrowdStrikeによれば563%増加)であれ、偽のブラウザ更新であれ、偽のエラーダイアログであれ、根底にある手法は同じです。ユーザーのクリップボードに悪意あるコマンドを挿入し、それを貼り付けて実行するよう仕向けるのです。ソーシャルエンジニアリングの見た目は変わっても、動作上の特徴は変わりません。

デバイスコードフィッシングもまた同様です。ユーザーは正規のデバイスコードログインページとやり取りし、最終的にデバイスコード認証の付与を完了させることになります。攻撃者がどのキットを使っているか、コードをポーリングするページをどこでホストしているかに関わらず、到達先ページとユーザーの挙動は同じなのです。

攻撃手法のレベルで検知するというアプローチは、攻撃者にとって最も変更しづらい部分、すなわち攻撃そのもののメカニズムを標的にします。しかし、これには多くの検知プログラムに欠けている2つの要素が求められます。

1つ目は、こうした攻撃が実際に実行される場所での可視性です。AiTMによるインターセプト、ClickFixによるクリップボード操作、OAuth同意の悪用、デバイスコードフィッシングといった手法は、ネットワークプロキシからは暗号化された通信としてしか見えず、EDRからは何も見えないブラウザセッション内で展開されます。ユーザーがページを操作する瞬間をあなたの検知スタックが観測できないのであれば、攻撃手法レベルでの検知という選択肢はそもそも使えません。

2つ目は、研究のスピードです。攻撃手法が発見されてから犯罪ツールキットとして産業化されるまでの期間は、どんどん短くなっています。デバイスコードフィッシングが国家主導の新手法から汎用的なPhaaS機能になるまでには約1年しかかからず、ClickFixも同様の経過をたどりました。

行動学的特徴を抽出し、商用化される前に検知ルールを展開できる防御側は、時間とともに複利的に積み上がる構造的優位性を手にできます。指標を待つこと、たとえそれがツールレベルの指標であっても、それは自分から遠ざかっていく加速するカーブを追いかけ続けることを意味します。

その証明:IOCの重複がゼロだった検知事例

今年の初め、Microsoftが公表した調査は、OAuthのエラー処理リダイレクトをフィッシングの配信手段として武器化する新手法を記録していました。標準規格に準拠したリダイレクト動作を悪用し、信頼されたIDプロバイダーのドメインから攻撃者が管理するページへとユーザーを誘導するというものです。URLフィルタリングの観点から見ると、最初のリンクはlogin.microsoftonline.comのドメイン評価をそのまま帯びていました。

Push Securityのエージェント型脅威ハンティングパイプライン、すなわち300万以上の展開環境から集めたブラウザテレメトリを継続的にハンティングし、人間の研究者の能力を増幅させるAIエージェント群は、この調査結果を取り込んで、公表されたIOCではなく、その動作メカニズムを抽出しました。エージェントは、OAuthリダイレクトという行動学的特徴を標的とした検知ルールを構築したのです。 

この検知ルールを作成してから数か月後、それはまったく別のキャンペーンに対して発動しました。あるPush Securityの顧客企業のユーザーが標的にされていましたが、そのおとり、ドメイン、インフラはいずれも元の事例とは異なり、リダイレクトの先にあったフィッシングキットも(元の事例ではマルウェアのダウンロードペイロードだったのに対し)これまで見たことのないものでした。 

根底にある攻撃手法は同一でした。元のIOCは、この攻撃チェーンのどこにも一切登場しなかったのです。 

ブロックリストに基づくアプローチであれば、この攻撃を完全に見逃していたはずです(該当ドメインは当時、悪意あるものとしてフラグ付けされていませんでした)。ツールのシグネチャに基づくアプローチもまた見逃していたでしょう。フィッシングキットが既知のサンプルと一致しなかったからです。生き残った唯一の検知手段は、行動学的な攻撃手法そのものを見るアプローチでした。

このOAuthリダイレクトの事例は、孤立した一例ではありません。同じパイプラインは、3つの新しいブラウザベースの攻撃手法の発見と検知にもつながっています。ソフトウェアインストールのプロンプトを装ったマルウェア配信手法であるInstallFix、OAuth同意フィッシングとClickFix型のユーザー操作を組み合わせたConsentFix、そしてAIチャットボットの共有機能を介したマルウェア配信であるLLMShareです。

いくつかのケースでは、その攻撃手法が公に文書化されるより前の時点で、検知ルールが実際に稼働中のキャンペーンをブロックしていました。 

これまでのところ、Push Securityのエージェント型パイプラインは、直近3か月だけでも新手のフィッシング手法に狙われた60社以上の顧客を保護しており、攻撃者がアカウントを侵害したり、ユーザーをマルウェアペイロードとの接触に誘導したりする前に、約225件の脅威を阻止しています。

セキュリティチームへの示唆

業界は数十年もの歳月をかけて、より大規模なブロックリストの構築に取り組んできました。しかしAIは、そのアプローチを構造的に時代遅れのものにしてしまいました。単に対応が遅いというレベルの話ではなく、そもそも構造的にペースを維持できないのです。 

いまだ持続性を保っているのは、ピラミッドの頂点にある部分、すなわちインフラやそれを実装するツールではなく、攻撃がどのように機能するかを軸に構築された、攻撃手法レベルの行動学的検知です。このレベルで防御を行うには、ブラウザセッションの可視性と、攻撃手法の発見から犯罪者による採用までの短縮し続ける期間を先回りできるだけの、迅速な研究パイプラインが必要になります。

Push Securityでは、AIエージェントを人間の研究者の能力を増幅させる存在として活用することで、このパイプラインを構築してきました。ブラウザテレメトリを継続的にハンティングし、指標の入れ替わりを乗り越えて生き残る攻撃手法レベルの検知ルールを展開しています。より大規模なブロックリストを構築するのではなく、ピラミッドの頂点にある行動学的検知をマシンスピードで運用化することで、月間の検知件数を3倍に増やしました。

デモを予約することで、詳細をご確認いただけます。