HN 日本語サマリー

← 一覧へ戻る
セキュリティ

Microsoft、メールスパマーがASCIIスマグリングを採用したと発表

Microsoft says email spammers are adopting ASCII smuggling (arstechnica.com)

11 pointsby utiiiD1 コメント

要約

Microsoftは、AI攻撃で悪用されていた「ASCIIスマグリング」と呼ばれる技術が、メールスパマーによって検知回避のために採用されていると報告しています。この技術は、人間には見えない特殊なUnicodeタグを使用して、スパムフィルターが検出するキーワードを隠蔽します。これにより、従来のテキストベースのフィルターや機械学習による分類を回避する新たな手口となっています。

全文翻訳

AIエージェントへの攻撃で悪用されていた巧妙な技術が、大量キャンペーンで使用される不要なメッセージをフラグ付けするように設計されたメールプラットフォームのフィルターを回避するために、スパマーによって採用されています。この技術は一般的にASCIIスマグリングとして知られています。2年前に、プロンプトインジェクションとして知られるAI攻撃の一種をよりステルスにする手段として注目を集めました。 LLM(大規模言語モデル)によって処理されるメールやその他の信頼できないコンテンツに埋め込まれた悪意のある指示は、通常のテキストでは記述されていません。代わりに、特殊な範囲のUnicodeタグでレンダリングされます。例えば、タグポイントU+E0041は「A」を、U+E0061は「a」をミラーリングします。 AI攻撃のためだけではなくなりました これらのタグのブロックは、情報交換のための米国標準コード(ASCII)の一部をほぼ完璧に模倣していますが、大きな違いが1つあります。それは、エンコードされた文字はコンピューターには読み取れますが、意図的に人間にはほとんど見えないということです。これらのタグで悪意のあるプロンプトを表現することにより、LLMは指示を検出しますが、メールを読んでいる人間はそれを見ることはありません。ASCIIスマグリングの詳細についてはこちらをご覧ください。 今年初め、Microsoftはこの技術を使用したスパムメッセージの急増を目撃し始めました。2月初旬のある日を境に、Microsoft Defender for Officeによって検出されたASCIIスマグリングのシグネチャ数は、1日あたり約21,000件から130万件以上に急増しました。4日以内には、シグネチャ検出数は250万件に跳ね上がりました。この洪水は数ヶ月続き、その後5月中旬に急激に減少しました。 Microsoftは木曜日に、「タグ文字は人間には見えませんが、テキスト処理レベルに存在するため、モデルに指示をスマグリングするのに役立つのと同じ特性が、検出器が評価する前にキーワードを不明瞭にするのにも役立ちます」と説明しました。「意図は反転していますが、メカニズムは似ており、ユーザーの疑念は高まりません。」 [画像の説明: ASCIIスマグリングシグネチャへの日次ヒット数、発生前後の1週間。出典: Microsoft] [画像の説明: 2026年2月9日から6月18日まで毎日測定された、金融をテーマにした送信者ドメインに対するUnicodeタグシグネチャのヒット数(対数スケール)。出典: Microsoft] スパマーは、大量メールに一般的に見られる金額や「クレジット」「期間」といった単語を検索するフィルターを回避するために、Unicodeを埋め込んでいます。例えば、「funding」という単語の真ん中に不可視のテキストを散りばめることで、フィルターは「fun」と「ding」を読むかもしれませんが、受信者には「funding」という単語が見えます。 特定のトリガーワードをカモフラージュするために特殊なテキストを使用することは新しいことではありません。スパマーは何十年もの間、ゼロ幅スペースやノンブレークスペースを使用して同様の結果を達成してきました。これらの文字は、リテラル文字列との一致検索を妨害し、正規表現フィルターが検索するバイトシーケンスを変更することができます。スパマーが隠されたUnicodeタグを採用したのは、一部のスパムフィルターがまだそれらを検出するようにプログラムされていなかったためでしょう。 その使用のより大きな理由はおそらく、スパム検出に使用される機械学習(ML)および自然言語処理(NL)LLMによって可能になった利点を無効にすることです。Microsoftは次のように説明しています。 攻撃者にとってより大きな報酬は、リテラル文字列の一致を防ぐことではありません。それは、現代のスパムおよびフィッシング分類をますます推進しているMLおよびNLPベースのモデルです。フィルタリングシステムがメッセージの画像を撮り、その視覚的な画像に対してOCR抽出を行わない限り、このタイプのアタックを見逃す可能性があります。標準的なメール分類子は、人間が見るのと同じように単語全体を推論しない場合があります。効率化のため、まずテキストをトークンまたはサブワードピースに分割することがあります。fundingのようなクリーンなルアー(誘い文句)は、馴染みのあるトークンまたは馴染みのあるサブトークンのシーケンスとして表される場合があります。しかし、不可視のU+E0020を中間に挿入すると、トークナイザーはその同じ馴染みのある単位を見なくなるかもしれません。それは、fun、予期しないタグ文字、dingにテキストを分割するかもしれません。まれな、または未知のサブトークンを放出するかもしれません。あるいは、正規化が最初に行われる場合、単にU+E0020文字を削除し、fundingを残します。 木曜日の投稿では、開発者がスパムにおけるASCIIスマグリングをより良く考慮するようにフィルターをプログラムする方法についてのガイダンスが提供されました。 Dan Goodin、シニアセキュリティエディター Dan GoodinはArs Technicaのシニアセキュリティエディターであり、マルウェア、コンピュータ諜報、ボットネット、ハードウェアハッキング、暗号化、パスワードのカバレッジを監督しています。余暇には、ガーデニング、料理、インディーズミュージックシーンを追うことを楽しんでいます。サンフランシスコ在住。MastodonとBlueskyでフォローしてください。SignalではDanArs.82まで連絡できます。 53 コメント この文字範囲の意図されたユースケースは何でしたか? 以前のArsの記事(この記事でリンクされています)で詳細が説明されています:https://arstechnica.com/security/2026/09/once-popular-for-attacking-ai-ascii-smuggling-is-embraced-by-spammers/ 非推奨(2回)だが忘れられていない Unicode標準は、世界中の言語で見られる約150,000文字のバイナリコードポイントを定義しています。この標準は、100万以上の文字を定義する能力を持っています。この広大なレパートリーの中に、ASCII文字に平行する128文字のブロックがひっそりと存在します。この範囲は一般的にTagsブロックとして知られています。 Unicode標準の初期バージョンでは、テキストが英語または日本語で書かれていることを示すために、「en」や「jp」のような言語タグを作成するために使用される予定でした。このブロックのすべてのコードポイントは、意図的に不可視でした。文字は標準に追加されましたが、言語を示すためにそれらを使用する計画は後に中止されました。 文字ブロックが未使用のままだったため、後のUnicodeバージョンでは、国を表すために放棄された文字を再利用することが計画されました。例えば、「us」または「jp」は米国と日本を表すかもしれません。これらのタグは、一般的な🏴旗絵文字に付加されて、自動的に公式の米国🇺🇲または日本の🇯🇵旗に変換される可能性があります。しかし、その計画も最終的には頓挫しました。再び、128文字のブロックは控えめに引退しました。 Scale AIの独立系研究者でプロンプトエンジニアであるRiley Goodside氏は、🏴を伴わない場合、ほとんどのユーザーインターフェースでは表示されませんが、一部のLLMではテキストとして理解できることを発見した人物として広く認識されています。 Arsの記事がフラグ修飾機能が本質的に「非推奨」であると呼んでいるのは興味深いですが、このコメントがあります: 公式には言語指定子としての使用は非推奨です。それらは、より多くの地域が旗を持てるように、旗絵文字の修飾子として再利用されています。🏴gbwls✦はウェールズの旗を生成します。しかし、これは非常にまれで、あまりサポートされていません。 そしてWikipedia:https://en.wikipedia.org/wiki/Tags_(Unicode_block) Unicode 9.0のリリースにより、U+E007Fはもはや非推奨の文字ではありません。(U+E0001 LANGUAGE TAGは非推奨のままです。)2017年5月のEmoji 5.0のリリースでは、これらの文字は特別なシーケンスでの修飾子としての使用のために絵文字と見なされています。指定されている唯一の使用法は、国旗の地域インジケーターシンボルの使用と並んで、地域旗を表すことです。タグシーケンスはISO 3166-2から派生していますが、地方旗(例えば米国の州)を表すシーケンスもこのメカニズムを使用して可能です。しかし、Unicodeバージョン12.0の時点では、上記の3つの旗シーケンスのみがUnicodeコンソーシアムによって「一般交換に推奨」されており、これは「複数のプラットフォームで広くサポートされる可能性が最も高い」ことを意味します。 フラグ修飾機能は「非推奨」というよりは「広く実装されていない」ことを示唆しています。 2026年9月4日