安全ガードレールを逆用してLLMスキャナーを黙らせる——UAC-0099の新手口が示すAI運用リスクです

今日の深掘りポイント

• 攻撃側が「AI安全ガードレール」を武器化し、LLM支援のマルウェアスキャンを意図的に中断・拒否させるという逆説が現実化しています。
• コメントやメタデータに“安全配慮”の文言を埋め込み、スクリプト実行時には無害・AI解析時には有害という二面性を作る「インバンド型プロンプトインジェクション」の一種です。
• UAC-0099（ロシア関与とされるグループ）がウクライナ組織を狙う作戦で活用したと報じられ、戦時サイバー作戦の教義に「AI対運用」の章が加わりつつあります。
• SOC/CTIは「LLMを分析器に組み込む設計自体」を見直し、入力の無害化、解析段の分離、失敗時のフェイルセーフ、多段エンジン照合の4点を最優先で固めるべきです。
• 脅威は新規性と再現性の双方が高く、運用現場では“静かに起きる偽陰性”として顕在化しやすいです。可観測性（LLM拒否・中断ログの可視化）を上げることが即効策になります。

はじめに

AIが防御側の生産性を底上げする一方で、攻撃側もその“癖”を研究し始めています。今回の報道が示すのは、AI安全ガードレールという善意の設計が、条件次第で検知回避のためのスイッチへと化ける現実です。とりわけ、解析パイプラインにLLMを組み込む潮流の中で、入力側の一工夫が解析そのものを停止させる——そんな静かな敗北のシナリオに、私たちは今から備える必要があると考えます。

深掘り詳細

事実整理

• 報道によれば、UAC-0099がウクライナ組織に対する攻撃で、悪意あるVBScript内に“安全に関するリクエスト”をコメントとして埋め込み、実行系には影響させず、LLM支援スキャナーのみを撹乱する手口を用いたとされています。目的は、スキャナーがコード本体を検査する前にAIの拒否や解析中断を誘発することです。
• この手口は“GuardBreaker”と呼称され、LLMがテキストを「指示」と「データ」に厳密分離せず同一コンテキストで処理しがちな点、そして安全ガードレールが「危険や違法性を示唆する指示」を検出すると応答を拒否・中断する挙動を突いています。
• UAC-0099はこれまでウクライナ政府・防衛関連への攻撃で複数のマルウェアファミリ（例：MATCHBOIL、MATCHWOK）を用いてきたとされ、フィッシングによる侵入を常套としています。
• 出典は下記の二次報道です。一次情報（ベンダー詳細レポート）への参照は本稿執筆時点で未確認です。
  • GBHackers: AI safety guardrails abused to hide malware from LLM-based scanners

インサイトと評価

• 本質は「AI-in-the-loop防御」に対するインバンド型プロンプトインジェクションです。Interpreterが無視する領域（コメント、メタデータ、アーカイブ内のREADME、ドキュメント）を、LLMは貪欲に読み込みます。ここで“安全配慮を装うメッセージ”を混入されると、LLMの安全ポリシーが自発的にブレーキを踏み、解析が止まります。結果として、悪性コードに到達する前にスキャンが空振りする偽陰性が生まれます。
• 従来の難読化やパッキング（T1027）と違い、これは「解析装置の意思決定を誘導する」防御回避（T1562）です。被弾時の兆候は静かで、SIEMやEDRのアラート量は増えず、むしろ“何も起きない”のが症状になります。この不可視性が運用の怖さです。
• メトリクスから総合的に読むと、信頼性は高く、再現性と実運用への波及も十分にあり、楽観できない新規性を伴うテーマです。一方で、対策は設計原則と工程管理で相当程度は抑え込めます。すなわち“LLMで全部やらない”“LLMの前処理と失敗時の後処理を決める”だけでも、実害を大きく減らせます。

脅威シナリオと影響

• 想定シナリオA（EDR/メールゲートウェイのLLM補助解析の撹乱）です。
  • Initial Access: フィッシング添付（MITRE ATT&CK T1566）です。
  • Execution: VBScript実行（T1059: Command and Scripting Interpreter）です。
  • Defense Evasion: スクリプト内コメントに“安全配慮文”を仕込み、LLMスキャナーの拒否・中断を誘発（T1562: Impair Defenses。解析ツールの機能低下に該当）です。
  • User Execution（T1204）の文脈では、利用者が添付を開くと同時に、SOC側の自動解析はLLMの拒否で素通りし、一次検知が立ち上がらない、という偽陰性リスクが立ちます。
• 想定シナリオB（CI/CD・サプライチェーン審査の盲点化）です。
  • ライブラリやインストーラに“安全コメント”を混在させ、LLMコードレビューの工程で“不適切コンテンツ検出”として自己抑制を引き起こし、レビュー結果が欠落・ホワイトリスト化される恐れがあります。依存関係スキャンにLLMを併用する組織ほど、審査抜けが連鎖しやすいです。
• 想定シナリオC（CTI/ログ要約の情報損失）です。
  • LLMでIOC抽出やレポート要約を行うパイプラインに、安全誘導の指示を混ぜると、要約自体が停止または情報を間引きます。結果として、検知コンテンツの品質がじわじわ劣化します。
• 影響評価です。
  • 偽陰性率の上昇、スキャン時間の短縮（早期中断）による“処理成功錯覚”、誤ったKPI改善といった二次的な運用歪みが懸念です。対外的説明責任（監査・規制対応）において、“なぜ見逃したか”の根拠がログに残りにくい点も重大です。
• 地政学的含意です。
  • 戦時環境での運用撹乱は意思決定の遅延に直結します。同盟国支援や防衛産業サプライチェーンのスクリーニング工程にLLMを組み込んでいる場合、同様の撹乱が水平展開される可能性が高いです。運用デグレの検出・復旧（SRE for SOC）が新たな防御要件になります。

セキュリティ担当者のアクション

• 解析パイプラインの“4点締め”です。
  1. 前処理での無害化: LLMに渡す前に、コメント・メタデータ・README・ドキュメントを除去またはサンドボックス化し、コード本体と別チャネルで供給します。構文パーサでAST化して“実行可能要素のみ”を提示するのが理想です。
  2. 多段・異種エンジンの整列: ルール/シグネチャ/数理静的解析/動的サンドボックスを先に走らせ、LLMは補助要約と相関分析に限定します。LLM判定は決定権を持たず、常に別系統の根拠で裏づけます。
  3. フェイルセーフと再走査: LLMが“拒否/中断”キーワードを返したら自動で別モデル・別プロンプト・非LLMエンジンにフォールバックし、結果を比較します。拒否は成功ではなく“要再解析”に分類します。
  4. 入出力の境界設計: プロンプト（指示）とデータを厳密に分離し、アプリ層でデータ側の指図文（“無視して”“中断して”など）を脱毒・無効化します。シリアライザでデータを安全な構造体に封じてからプロンプトに埋め込む設計を徹底します。
• 監視と可観測性の強化です。
  • LLMログに対して拒否・回避フレーズ（例：“支援できません”“ガイドラインに反します”）のメトリクス化、異常増加の検知、ジョブ中断率のSLO設定を行います。モデル更新やプロンプト変更の前後比較をダッシュボード化し、運用デグレを早期に炙り出します。
• レッドチーム/パープルチーム演習です。
  • コメント・メタデータ・多言語・暗号化風表現など多様な“安全装いテキスト”を使った対LLM撹乱テストスイートを作り、CIに組み込みます。再現性の維持と回帰検証が要です。
• ベンダー問い合せの論点です。
  • 解析の前処理（サニタイズ）の有無、LLM拒否時のフォールバック戦略、拒否ログの可視化、モデル群の多様性、プロンプトインジェクション対策（コンテンツ分離・ポリシー層）をRFP項目に含めます。
• ガバナンスと人の運用です。
  • LLMの出力は“補助意見”として扱い、否定・拒否応答は必ず別系統の検査に回す運用規程を整えます。アナリスト教育では“静かな偽陰性”の兆候（解析時間の異常短縮、出力テンプレ化）に着目するよう訓練します。
• 技術的補足のATT&CK整理です（仮説ベース）。
  • 初期侵入: Phishing/Spearphishing（T1566）です。
  • 実行: Command and Scripting Interpreter（T1059、VBScript）です。
  • 防御回避: Impair Defenses（T1562、解析ツールの機能低下の誘発）および、状況によりObfuscated/Compressed Files & Information（T1027）相当の混在活用があり得ます。
  • 利用者依存: User Execution（T1204）です。
    上記は本件をATT&CK観点でオペレーション化するための枠組みであり、実案件ではアーティファクトに基づく再マッピングを推奨します。

参考情報

• 二次報道: GBHackers – AI safety guardrails abused to hide malware from LLM-based scanners

編集後記です。
“AIに任せれば早い”という正しさの裏側に、“AIが自ら止まってしまう”という新しい脆弱性が潜んでいました。今回の一件は、モデルの賢さよりも、運用の賢さが試されていることを教えてくれます。LLMは強力な補助輪ですが、進むべき方向とブレーキの優先権は、私たちが握り続けるべきです。