2025年9月25日、Microsoftの脅威インテリジェンス部門が**「LLM（大規模言語モデル）を使った難読化手法」を取り入れたフィッシング攻撃**を発見・遮断したと発表しました。
これまでのフィッシングは、偽サイトやマルウェア付き添付ファイルを「人間の手」で作りこむことが一般的でした。しかし今回の攻撃では、AIを駆使してより自然でエラーの少ないコードやメールを生成し、従来よりも発見を難しくしている点が注目されます。
実際に観測された攻撃では、中小企業のメールアカウントが乗っ取られ、「共有ファイルの通知」を装ったメールが送信されました。添付ファイルは一見するとPDFですが、実際にはSVGファイルが仕込まれており、開くとCAPTCHA画面を装った偽サイトに誘導され、その後認証情報を盗み取る仕組みになっていました。
SVG（Scalable Vector Graphics）ファイルはテキストベースで、JavaScriptなどのコードを埋め込める性質を持つため、攻撃者にとって格好の隠れ蓑となります。さらに今回の手口では、コードの中に「revenue」「risk」「operations」といったビジネス用語をつなぎ合わせ、あたかも業務データの一部であるかのように見せかけて悪意ある処理を隠蔽していました。
Microsoftのセキュリティチームはこの手口を**「LLM-obfuscated phishing（LLM難読化フィッシング）」**と呼び、従来型の暗号化や難読化とは異なる新しい流れとして警告しています。
- LLM難読化攻撃の特徴と従来型との違い
- 実際のSVGファイルに仕込まれた攻撃手口の仕組み
- Microsoftの検知プロセスと「AIでAIを見抜く」試み
- 企業と個人が取るべき即時対策
- 検知のためのIOC（侵害の兆候）とログで見るべきポイント
- AI時代の防御設計 — 検出と予防のバランス
- 事後対応（インシデント対応）の簡潔な流れ
- 今後の予測と我々ができること
- まとめと読者への問いかけ
LLM難読化攻撃の特徴と従来型との違い
今回のフィッシング攻撃が注目された理由は、単なる「偽装メール」ではなく、AI生成によるコードの痕跡が多数見られたことです。MicrosoftのAIセキュリティアシスタント「Security Copilot」の解析では、以下の特徴が確認されました。
- 過剰に説明的な変数名や関数名
- 過度に複雑で「作り込みすぎた」コード構造
- 不必要なコメントや冗長な記述
- 定型的で機械的な難読化パターン
これらは人間の開発者よりも、LLM（大規模言語モデル）による生成コードに見られやすい特徴であり、攻撃者がAIを利用していた可能性が極めて高いと結論付けられています。
これまでの難読化は「暗号化」や「乱数文字列」で構造を隠す方法が主流でした。しかし今回のケースでは、逆に**「一見するとビジネス用語の羅列」に見えるように加工する**ことで、セキュリティツールの検出を回避しようとしています。
つまり、AIを使うことで「人間にとっては自然に見えるが、実際はマルウェアに変換されるコード」を大量に生成できるようになったわけです。
実際のSVGファイルに仕込まれた攻撃手口の仕組み
攻撃者は「見た目は業務データ」に見えるテキスト要素を使って、実際には悪意ある命令を後で復元する仕組みを作っていました。
具体的には、SVG内に透明・不透明ゼロの「ビジネスダッシュボード風」要素を多数埋め込み、そこに「revenue」「operations」「risk」などのビジネス用語を連結した長い属性値を置きます。埋め込まれたJavaScriptがその語句列を逐次変換（マッピング）して実際の命令やURLに復元し、条件が揃えばブラウザをフィッシングページへリダイレクトします。SVGはテキスト形式でJavaScript埋め込みが可能なため、従来のバイナリ添付よりも検知を回避しやすいのが特徴です。Microsoft+1
Microsoftの検知プロセスと「AIでAIを見抜く」試み
MicrosoftはSecurity Copilot（AI）を使い、コードの文体的特徴から「生成物＝LLMが作った可能性が高い」と判定しました。
Security Copilotは過度に説明的な変数名、冗長なコメント、過剰設計の痕跡などを検出し、これらをLLM生成のシグナルとみなしました。興味深い点は、AI生成が検出のヒントになることです——すなわち攻撃側がAIを使って巧妙に作っても、逆に「機械臭」が検出シグナルとして働く場面がある、という逆転現象です。Microsoft+1
企業と個人が取るべき即時対策
まずはSVG（.svg）や拡張子を偽装したファイルを安易に開かない運用ルールを徹底してください。
組織ではメールゲートウェイでSVGのインラインスクリプトをブロックし、添付ファイルをサンドボックス解析に回す設定を有効にします。エンドポイントではブラウザの拡張機能やセキュリティ製品で「data:」「javascript:」などのスキームによるリダイレクトを監視・遮断します。また、ユーザ教育として「共有通知を装うメール」「PDFに見えるが中身は異なる」ケースの注意喚起を行ってください。Tom's Hardware+1
検知のためのIOC（侵害の兆候）とログで見るべきポイント
疑わしいSVGやメールを検査する際は「不可解に長い属性値」「透明要素の多用」「JSによるデコード処理」を探すと良いです。
メールログやWebプロキシでは、正規のPDF/CLOUDホスティングドメインからの突然のSVGダウンロード、ユーザのブラウザが外部ドメインへPOST/GETでリダイレクトされるパターン、CAPTCHAを偽装するHTMLが返るフローをIOC候補としてマークしてください。これらは後段の認証ページ誘導の典型的な前兆です。Microsoft+1
AI時代の防御設計 — 検出と予防のバランス
AIは攻撃にも防御にも使われるため、防御側もAIを導入して「生成物らしさ」を検出シグナルにする必要があります。
ただし過信は禁物で、AI検出は誤検知（false positive）や見逃しのリスクもあるため、従来のシグネチャ／振る舞い検知やヒューリスティクスと組み合わせることが重要です。加えて開発パイプラインやSaaS連携で「ファイルタイプと実コンテンツの一致」をチェックする仕組みを入れておくと攻撃成功率を下げられます。Microsoft+1
事後対応（インシデント対応）の簡潔な流れ
感染や認証情報の盗難が疑われる場合、まず該当メール／ファイルを隔離し、影響範囲のスコープを特定してください。
続いて、被害端末のブラウザ履歴と認証ログを回収し、外部へ送信された可能性のあるトークンやクッキーの失効、パスワードのリセット、必要ならば二要素認証（2FA）の強制設定を行います。被害の規模が組織横断的であればCIRT（Computer Incident Response Team）や外部フォレンジックの支援を早期に要請してください。Microsoft
今後の予測と我々ができること
LLMを使った難読化は増える見込みで、攻撃者の「ツール化」が進むほど検知困難な手口が増えます。
防御側は定義更新を高速化し、メールゲートウェイやプロキシのサンドボックス、AI支援検出を組み合わせた多層防御を採るべきです。個人は信頼できない添付を開かない、組織は最小権限とログ収集を徹底する――これらの基本を再確認することが重要です。Microsoft+1
まとめと読者への問いかけ
Microsoftの報告は「攻撃者がAIを道具として取り入れ始めた」現実を示していますが、同時にAIはそれを検出する手段にもなり得ます。
皆さんの職場や家庭では、SVGや不審な「共有」通知に対する取り扱いルールがありますか？ もしあれば、それはどう運用しているか、コメントで教えてください。実例や追加の質問があれば、ここで一緒に議論していきましょう。Microsoft+1
