不可視Unicode文字でフィッシング検知を回避 Microsoftが大規模なサイバー攻撃 キャンペーンを確認、1日最大237万件

セキュリティニュース

投稿日時: 更新日時:

不可視Unicode文字でフィッシング検知を回避 Microsoftが大規模なサイバー攻撃 キャンペーンを確認、1日最大237万件

Microsoft Security Researchは2026年9月3日、通常の画面では見えないUnicode文字をメール本文へ挿入し、フィッシング・スパム検知を回避しようとする大規模なサイバー攻撃 キャンペーンを確認したと公表しました。

使われていたのは、Unicodeの「Tags」ブロックに含まれる不可視文字です。攻撃者は金融関連の単語の途中へ不可視文字を差し込み、人間には通常の単語として見せながら、キーワード一致や一部の機械学習・自然言語処理による判定では別の文字列として扱わせようとしていました。

MicrosoftのDefender for Office 365テレメトリでは、この手法に一致するメールが2026年2月9日から急増し、2月26日には1日あたり最大約237万件に達しました。高水準の活動は約3か月続き、5月15日以降に大幅に減少しました。

Microsoftはこの手法を「ASCII smuggling」の応用として説明しています。ただし、今回確認されたメールは、不可視文字で別の隠しメッセージ全体を埋め込んだものではありません。金融関連キーワードの途中にUnicode Tagsブロックの文字を挿入し、フィルターの解析を妨げる使い方でした。

不可視Unicode文字を使ったフィッシングのサマリー

確認できている内容:

  • Microsoft Security Researchは2026年9月3日、Unicodeの不可視文字を利用した大規模なフィッシング・スパムキャンペーンを公表しました。
  • 使用されたのは主にUnicode Tagsブロック「U+E0000~U+E007F」の文字です。
  • 攻撃者は「funding」「capital」「loan」「credit」など金融関連の誘導語の途中へ不可視文字を挿入していました。
  • 人間の画面上では通常の単語に見える一方、単純なキーワード一致や一部のトークナイザーでは文字列が分割される可能性があります。
  • Microsoft Defender for Office 365の観測では、2月8日に約2万1,000件だったシグネチャ一致が、2月9日に130万件超へ急増しました。
  • 2月26日には1日あたり約237万件まで増加しました。
  • 高ボリュームの活動は約3か月継続し、5月15日以降に大幅に減少しました。
  • 2月9日に確認された活動では、金融関連の名称を持つ約148の送信ドメインが使われていました。
  • このクラスターは同日のシグネチャ一致メールの約96%を占めました。
  • メールの配送には正規のメールマーケティングサービスActiveCampaignの基盤が利用されていました。
  • ActiveCampaignはMicrosoftから報告を受け、不可視Unicode文字を含むメールを通常の文字列と同様に評価し、多用自体も不審なシグナルとして扱っていると説明しました。
  • Microsoft Defender for Office 365では、Unicode文字そのものの検知だけに依存せず、送信者・IP・URL・ドメイン評価、認証、機械学習、OCRなど複数の防御層によって対象メールの99%超を検知したとしています。
  • 日本企業や日本語利用者が直接狙われたとの情報は、Microsoftの公表資料では確認できません。

現時点で未確認の内容:

  • 攻撃者・脅威アクターの身元
  • 特定の国家や犯罪組織との関係
  • 日本企業・日本利用者への具体的な配信件数
  • キャンペーン全体の最終的な被害人数
  • 認証情報窃取や金銭被害の確定件数
項目 内容
公表日 2026年9月3日
公表組織 Microsoft Security Research
攻撃 不可視Unicode文字を挿入したフィッシング・スパム
使用文字 主にUnicode Tagsブロック U+E0000~U+E007F
主なテーマ 事業資金、融資、信用枠など金融関連
急増確認 2026年2月9日
最大規模 約237万件/日、2月26日
高ボリューム期間 約3か月、5月15日以降に急減
送信ドメイン 2月9日に約148の金融テーマ系ドメインを確認
配送基盤 正規サービスActiveCampaignの基盤が悪用
Defender for Office 365 99%超を他の防御シグナルも含め検知
攻撃者 公表されていません
日本への直接影響 公表資料では確認できず

ASCII smugglingとは

ASCII smugglingは、通常の画面では表示されない、または表示されにくいUnicode文字を利用し、人間が見る内容とソフトウェアが処理する文字列の差を悪用する手法です。

Microsoftが今回注目したのは、Unicode Tagsブロックの「U+E0000~U+E007F」です。

この範囲には、通常のASCII文字に対応するタグ文字が含まれています。多くのフォントやユーザーインターフェースでは表示されないため、人間が見たときには異常に気づきにくい特徴があります。

ASCII smugglingは2025年ごろから、AIに対するプロンプトインジェクション研究の文脈で広く知られるようになりました。

たとえば、人間には見えない命令をWebページやメール、文書に埋め込み、内容を読み込んだAIだけに処理させようとする手法です。

今回Microsoftが確認したのは、その性質を従来型のフィッシング検知回避へ転用したケースです。

関連記事:AIセキュリティとは?生成AI・AIシステムのリスクと企業のセキュリティ対策を解説

関連記事:AIエージェントを狙う間接的プロンプトインジェクション

今回は「隠しメッセージ」ではなく単語の途中へ不可視文字を挿入

Microsoftは今回の手法について、厳密には完全なASCII smugglingとは異なると説明しています。

従来のASCII smugglingでは、不可視文字を使ってAIなどへ読み取らせる別の文字列や命令を隠します。

今回のキャンペーンでは、金融関連の誘導語の途中に単一の不可視文字を挿入していました。

たとえば、画面上では利用者に通常の「funding」と見える単語でも、内部データ上では文字の途中にUnicode Tagsブロックの文字が入り、文字列が連続しない状態になります。

その結果、

  • 単純なキーワード一致
  • 一部の正規表現
  • トークン単位で処理する機械学習
  • NLPベースのメール分類

などで、通常の単語と異なる形に分割される可能性があります。

Microsoftは、今回の使い方を「不可視文字の挿入によるフィルター回避」と位置付けています。

2月9日に約130万件へ急増、最大237万件/日

Microsoft Defender for Office 365のテレメトリでは、この手法を検知するためのハンティングシグネチャへの一致数が2026年2月9日に急増しました。

2月8日は約2万1,000件でしたが、翌2月9日には130万件を超えています。

その後、平日を中心に大量配信が続き、1日あたり100万~237万件規模で推移しました。

最大は2月26日の約237万件です。

高ボリュームの活動は約3か月続き、5月15日以降に大幅に減少しました。6月中旬まで低水準の残存活動や小規模な増加が確認されています。

Microsoftは、この期間が「キャンペーン全体の活動期間」を示すものではないと説明しています。

不可視Unicode文字を使う前から関連キャンペーンは存在し、この手法の使用が減少した後も別の手法で活動が続いていました。

そのため、「2月9日に攻撃が始まり、5月15日に終了した」と解釈するのは正確ではありません。

平日に集中し、週末は急減

Microsoftの観測では、キャンペーンには明確な曜日パターンがありました。

平日は大量配信が続く一方、週末、特に日曜日にはシグネチャ一致数がほぼゼロに近い水準まで減少し、翌営業日に再び増加する動きが確認されています。

Microsoftは、このオン・オフのパターンについて、自動化された大量メール送信基盤にみられる特徴と説明しています。

また、2月のピーク後は徐々に配信数が低下し、3月末時点では平日の量がピーク時から約80%減少しました。

金融関連の148ドメインが2月9日の約96%を占める

2月9日の観測では、Microsoftは約148の金融テーマ系送信ドメインを一つのクラスターとして特定しました。

ドメイン名には、

  • funding
  • capital
  • loan
  • finance
  • business
  • advance
  • growth
  • credit

など、事業資金・融資を想起させる語が組み合わされていました。

このクラスターは、同日に不可視Unicode文字のシグネチャへ一致したメールの約96%を占めています。

メール本文も、事業資金、融資、信用枠、前払い型資金提供などを装う内容でした。

MicrosoftはMITRE ATT&CKの分類として、この活動をPhishing(T1566)とObfuscated Files or Information(T1027)に対応付けています。

正規のActiveCampaign基盤がメール配信に悪用

今回のキャンペーンでは、攻撃者独自のメールサーバーだけが使われていたわけではありません。

メールは、正規のメールマーケティングサービス「ActiveCampaign」に関連する送信基盤を経由していました。

ActiveCampaignは企業がメールマーケティングや顧客コミュニケーションに利用する正規サービスです。

Microsoftによると、攻撃メールのリンクも同サービスのクリックトラッキング機能を経由する形になっていました。

正規の送信サービスは、

  • 良好なIPレピュテーション
  • メール認証
  • 共有配信基盤
  • 正規利用者による大量メール送信

といった特徴を持ちます。

そのため、攻撃者が正規プラットフォームを悪用すると、送信元のIPやドメイン評価だけで悪意を判断することが難しくなる場合があります。

ただし、ActiveCampaign自体が攻撃主体だったわけではありません。

ActiveCampaignは不可視文字を不審シグナルとして評価

Microsoftは調査結果を公開する前にActiveCampaignへ情報を共有しました。

ActiveCampaignはMicrosoftに対し、今回確認された不可視Unicode文字を自社のコンテンツモデレーションシステムで検証したと説明しています。

同社によると、

  • 不可視Unicode文字を含むメールも、通常の文字列と同様に判定
  • 不可視文字を大量に使用すること自体を不審シグナルとして扱う
  • AI・機械学習を利用して、不正な送信行動をアカウント利用初期から検知する取り組みを拡大

しているとしています。

今回の事案は、正規のクラウド・メール配信基盤が悪用された場合、送信元レピュテーションだけでは十分でないことを示しています。

Defender for Office 365は99%超を別の防御層でも検知

不可視文字がメールフィルターを回避できるからといって、Microsoft Defender for Office 365が今回のメールを大量に通過させたという意味ではありません。

Microsoftによると、対象メールの99%超は、Unicode Tagsブロック固有の検知に依存しない複数の防御層でも検知されていました。

使われていたシグナルには、

  • 送信者評価
  • IPレピュテーション
  • URL評価
  • ドメイン評価
  • 機械学習によるスパム・フィッシング分類
  • ブランドなりすまし検知
  • メール認証
  • OCRによる可視文字の解析

などがあります。

Microsoftは、メールを画像として解析し、OCRで画面上に見える文字列を抽出する処理も利用しています。

この方法では、内部の文字列に不可視Unicode文字が挿入されていても、人間に見える状態のテキストを別経路から取得できるため、検知回避を受けにくくなります。

従来の「不可視文字による難読化」と何が違うのか

フィッシングやスパムで不可視文字を使う手法そのものは新しくありません。

Microsoftは2021年にも、

  • ソフトハイフン
  • Word Joiner
  • ゼロ幅スペース
  • ノーブレークスペース
  • 見た目の似たUnicode文字

などを使い、キーワードを分断する攻撃を報告していました。

今回異なるのは、

  • AIセキュリティ研究で知られるようになったUnicode Tagsブロックが使われた
  • 1日数百万件規模まで拡大した
  • AI/NLPベースの検知パイプラインにも影響し得る

という点です。

AI向けに研究されていた攻撃手法が、従来のメール攻撃へ逆輸入された形です。

AIがメールを読む企業ではプロンプトインジェクション対策にもつながる

企業では、生成AIやAIエージェントに、

  • メールの要約
  • 問い合わせ分類
  • 自動返信作成
  • 添付ファイル解析
  • フィッシング判定
  • チケット生成

などを行わせるケースが増えています。

この場合、メールは従業員だけでなくAIも読み取るデータになります。

Unicode Tagsブロックの不可視文字は、人間には見えなくても、AIや前処理ソフトウェアが生データとして取り込む可能性があります。

Microsoftは、メールセキュリティのためのUnicode正規化を、AIへ入力する前段でも行うよう推奨しています。

これにより、今回のようなフィッシング回避だけでなく、メール内へ不可視の命令を埋め込む間接的プロンプトインジェクションへの対策にもつながります。

関連記事:AIエージェントのセキュリティとは 公的資料から見る6つのリスクと対策

情報システム・SOCが確認したい対策

Microsoftが示した中心的な対策は「照合する前に正規化する」ことです。

企業側では、メールゲートウェイやSOCの検知ロジックについて次を確認できます。

メール本文・件名を正規化してから検知する

キーワード、正規表現、シグネチャによる照合の前に、

  • Unicode Tagsブロック
  • ゼロ幅文字
  • その他の非表示・非描画文字

を除去または正規化する処理が行われているか確認します。

単純に画面表示された文字列だけを見てルールを設計すると、内部表現との差を悪用される可能性があります。

Tagsブロックの存在自体を異常シグナルとして扱う

Microsoftは、Unicode Tagsブロックの文字は通常のメールではほとんど使われないため、存在自体が有力な異常シグナルになると説明しています。

ただし、イングランド、スコットランド、ウェールズの旗絵文字など、一部の正規用途では同じ範囲の文字が使われます。

そのため「Tagsブロックを含むメールをすべて悪性と判定する」のではなく、正規用途を除外した上で、

  • 送信元
  • 件名
  • URL
  • 大量配信
  • ドメインレピュテーション

などと組み合わせて評価します。

単一のキーワード検知に依存しない

今回Microsoftが99%超を検知できたのは、不可視文字専用ルールだけに依存していなかったためです。

メール防御では、

  • SPF・DKIM・DMARCなどの認証
  • 送信元IP・ドメイン評価
  • URL解析
  • 添付ファイル解析
  • ブランドなりすまし検知
  • 機械学習
  • OCR
  • 利用者からの通報

を組み合わせます。

関連記事:フィッシングメールとは 概要や手口を解説

正規メール配信サービスを一律許可しない

ActiveCampaignのような正規サービスも、不正利用される可能性があります。

「有名なメール配信サービスのIPだから許可する」といった単純なホワイトリストは、攻撃者に悪用される余地があります。

共有配信基盤では、サービス全体ではなく、

  • 実際の送信ドメイン
  • メール認証
  • URL
  • 配信パターン
  • 本文内容

まで含めて判断する必要があります。

AIへメールを渡す前にも正規化する

社内AIがメールや問い合わせを自動処理する場合、メール本文をそのままLLMへ渡す前に不可視文字を正規化します。

さらに、

  • 外部メールを信頼できない入力として扱う
  • メール本文内の指示をシステム命令として扱わせない
  • AIエージェントへ過剰なメール送信・ファイル操作権限を与えない
  • AIが実行した処理を監査できるようにする

といった制御も必要です。

今回のキャンペーンから企業が確認したいポイント

  • メールゲートウェイはUnicode Tagsブロックを正規化できるか
  • ゼロ幅文字など他の不可視Unicode文字も処理できるか
  • キーワード一致前に正規化を実行しているか
  • OCRなど、画面上の文字を別経路で解析する仕組みがあるか
  • 正規クラウド配信サービスを無条件で許可していないか
  • 大量送信・使い捨てドメイン・金融テーマなど複数シグナルを組み合わせているか
  • SOCで不可視Unicode文字を異常として検索できるか
  • AIにメールを読み込ませる前にも文字列を正規化しているか
  • AIエージェントが外部メールの内容だけで自動操作を実行しない設計になっているか
  • 従業員からの不審メール報告をSOC・CSIRTの調査へつなげられるか

今回の事例では、攻撃者は新しいマルウェアや未知の脆弱性を利用したわけではありません。

文字列の「人間には同じに見えるが、ソフトウェアには同じとは限らない」という差を利用し、既存のフィッシング検知を回避しようとしていました。

メールセキュリティでは、本文の見た目だけでなく、正規化、送信元、URL、認証、配信行動を組み合わせた多層検知が前提になります。

出典