ASCII密輸をフィッシングに悪用 237万通検出

Microsoftが不可視のUnicode文字を悪用した大規模なフィッシング活動を検出した。件数は2月後半に237万通超で頂点に達した。AI助手への間接的な指示挿入で知られるASCII密輸が、従来型のメール詐欺に転用された事例だ。 The Register の Jessica Lyons の報道では、Microsoftの研究者であるNoam Kochavi氏とSarah Wolstencroft氏が9月4日付のブログで詳細を公表したと伝えている。

ASCII密輸は人間の目には正常な文章に見える一方、機械処理では別の文字列として解釈される性質を突く。AI時代の攻撃手法が既存の犯罪基盤に流入した点で注目される。

不可視文字を悪用した攻撃の手法

ASCII密輸は描画されないUnicode文字を文章中に埋め込む手法である。人間には通常の文字列に見えるが、解析処理では隠された内容が読み取られる。AIセキュリティ研究では間接的な指示挿入の手段として知られてきた。 攻撃者はウェブページや文書に不可視文字で指示を隠す。利用者が気付かないままAI助手が読み込み、情報漏えいや不正操作につながる恐れがある。今回の事案は同じ隠蔽技術を別の目的に応用した点が特異だ。 Microsoftの検出ではタグ文字と呼ばれる不可視符号が使われた。文字と文字の間に挿入され、表示上は変化が生じない。受信者は違和感を覚えず本文を読むことになる。

金融用語分割による検出回避手法

今回の攻撃者はAIへの指示を埋め込まなかった。金融関連の誘引語句の内部に不可視文字を挿入し、検出を回避した。文字照合や重要語検査を無効化する狙いがあったと見られる。 例えば「funding」という語をそのまま書かず、中間にタグ空白を挿入した。表示上は「funding」に見えるが、内部表現は分割された状態になる。文字列の完全一致では検出できない仕組みだ。

研究者らは標本調査の結果について次のように述べている。

旗付きメッセージの標本を調べたところ、驚きだったのはAI支援機能への密輸指示がなかった点だ

さらに具体的な回避構造についても説明している。

不可視のタグ文字は一般的な金融用語の内部に挿入されていた。語句を分割することで文字通りの署名や重要語照合を失敗させる狙いだ

人間には金銭の話題として自然に読める。一方で機械的な選別機構は語句を認識できない。表示層と処理層のずれを突いた設計だと言える。

2月後半に急増した送信規模の推移

Microsoftは2月上旬にASCII密輸の署名を初めて検出した。2月8日の検出数は約2万1000通だった。翌日には130万通超へ急増した。 活動の頂点は2月後半で、237万通超に達した。その後3か月間にわたり平日を中心に高い水準が続いた。6月中旬にかけて徐々に減少した。 短期間での急増は自動化された送信基盤の存在を示す。平日に件数が高い点は業務時間帯の開封を狙った可能性がある。組織の経理や財務担当者を標的にした文面が多かったとされる。 攻撃者は金融用語を使い、資金提供や請求、送金手続きを装った。受信者の業務上の関心を引く内容で開封や返信を促した。不可視文字の挿入は本文全体ではなく重要語に集中していた。

防御側に求められる新たな対応策

研究者らはAI時代の攻撃手法が従来型脅威に適応されると警告した。AI領域で生まれた技術が既存の攻撃基盤に急速に波及する事例だと位置付けた。防御側は領域を越えた視点が必要だと訴えた。

AI時代の攻撃手法への理解が進むにつれ、脅威行為者がフィッシングや迷惑メールのような従来型脅威へ転用する可能性がある

AI安全研究で生まれた技術が確立された攻撃基盤へ急速に波及する様子を示している。防御者は新たな脅威を領域横断の視点で捉える必要がある

対策の中心はUnicode正規化と可視化になる。受信時点でタグ文字や零幅文字を除去し、正規形に変換する処理が有効だ。検出規則は表示文字列ではなく正規化後の文字列に適用する必要がある。 メール経路での防御に加え、端末とOS層の強化も重要だ。例えば AF_ALG制限強化、Linux 7.3で新sysctl導入 は暗号処理経路の制限を強める取り組みだ。入力処理の厳格化という方向性は今回の対策と共通する。 AI開発基盤の管理も課題になる。NVIDIA、Hugging Faceを129億ドルで買収発表 が示すように学習用データとモデルの流通は集中が進む。不可視文字を含むデータの混入は学習と推論の双方に影響し得る。開発から運用までの検査体制が求められる。

編集部の見解

短期的影響について見る。今後3か月から6か月で不可視文字を使った選別回避は他の迷惑メールや標的型攻撃へ拡散すると見る。金融用語に限らず請求書や認証通知を装う文面で応用が広がる可能性がある。メール防御製品ではUnicode正規化機能の追加や更新が進むと評価する。導入組織では検出規則の見直しと受信記録の再検査が必要になると見る。 長期的視点で見る。1年から3年の範囲では表示と機械解釈の差異を前提とした設計が標準になると評価する。Unicodeの不可視符号の除去や警告表示は文書編集や閲覧機能にも広がる可能性がある。AI助手とメール機能の連携が進むほど、隠蔽文字列の検査は安全策の中核になると見る。仕様策定と実装の双方で文字処理の透明性が問われると言えそうだ。 編集部からの問いを記す。防御側は利便性と厳格な検査のどちらを優先すべきだろうか。不可視文字を一律除去すれば誤検出や国際表記への影響が出る可能性がある。攻撃側の適応速度に対して防御側の情報共有は十分だろうか。AI領域とメール防御の知見を統合する体制が問われていると評価する。

参考

• 「ASCII smuggling isn’t just an AI security risk」, by Jessica Lyons — The Register, 2026-09-04T19:23:25.000Z (ARR)
• 元記事URL: https://www.theregister.com/security/2026/09/04/ascii-smuggling-isnt-just-an-ai-security-risk/5294595