脅威アクターは、従来のエンドポイント防御やサンドボックスだけでなく、不審なコードのトリアージに利用されるようになった大規模言語モデル(LLM)搭載ツールに対してもマルウェアを適応させるようになっています。
ESETの研究者たちは、この手法をロシアと関連のある脅威アクターUAC-0099による活動と結びつけました。同グループはウクライナのある組織に対する攻撃でこの手法を使用しました。
同グループは、悪意のあるVBScriptファイル内のコメントに、安全性に敏感な兵器関連のリクエストを挿入しました。
コメントは通常のスクリプト実行時には無視されるため、このテキストによってマルウェアのランタイム動作が変化することはありませんでした。
マルウェア分析ツール
本来の標的は分析レイヤーでした。すなわち、埋め込まれたテキストを、無害な攻撃者制御下のコンテンツとしてではなく、指示として解釈しうるLLMです。
その狙いは、後続のコードをスキャナーが検査する前に、モデルの拒否応答を誘発する、あるいは何らかの形でスキャナーを混乱させることだったとみられます。
このVBScriptは、UAC-0099と関連付けられているC#ベースのローダーMATCHBOILをダウンロード・インストールするよう設計されており、これは後続のペイロードを取得することが可能です。
公開されている報告では、影響を受けた具体的なLLM製品は特定されておらず、この手法の成功率についても測定結果は示されていません。判明しているのは、敵対的なコメントの存在と、その意図についてのESETの見解です。
GuardBreakerは間接的なプロンプトインジェクションの一形態を示しています。このシナリオでは、攻撃者はAIアシスタントに悪意のあるプロンプトを直接送信するわけではありません。
代わりに、自動化されたセキュリティワークフローが後にLLMへ渡すファイル、パッケージ、コメント、文字列、メタデータフィールドの中に、敵対的な指示が埋め込まれています。
この攻撃は、多くのLLMアプリケーションに共通する根本的な設計上の課題を突いています。すなわち、指示と信頼できないデータが同一の言語処理コンテキスト内で扱われ、両者の間に確実なセキュリティ境界が存在しないという点です。
OWASPは、コードコメントやドキュメントを含む外部素材は信頼できないコンテンツとして扱い、分析前にサニタイズし、システム指示とは明確に分離すべきだと警告しています。
現実的なリスクは、コードコメント単体でエンドポイントが侵害されることではありません。むしろ、それが検知パイプラインのAIコンポーネントに影響を及ぼしうる点にあります。
スキャナーがLLMの拒否応答、途中で打ち切られた応答、あるいは不完全な分析結果を無害な判定として扱ってしまう場合、攻撃者はシグネチャや振る舞い検知、サンドボックス実行を突破せずとも、検知の死角を得られる可能性があります。
ESETの研究者たちは、GuardBreakerと呼ばれる手法を特定しました。この手法は、AIの安全ガードレールを悪用し、LLM支援型スキャナーがファイルの悪意ある部分に到達するのを妨げようとするものです。
AIの安全ガードレール
UAC-0099は、フィッシングを起点とする配信チェーンを用いて、ウクライナの政府機関、防衛、運輸、エネルギー関連組織を標的にしてきた実績があります。
CERT-UAをはじめとする研究者たちは、これまでにも同グループによるMATCHBOIL、MATCHWOK、DRAGSTAREといったマルウェアファミリーの使用を報告してきました。
マルウェア分析ツール
MATCHBOILは、感染したホストのプロファイリングを行い、コマンド&コントロールインフラから追加のコンポーネントを取得することができます。
GuardBreakerの発見は、悪意のあるオープンソースパッケージで確認されている類似の手法と一致しています。
研究者たちは、PyPIやnpmのパッケージの中に、捏造された「system」指示や、AIモデルにそのパッケージを無害と分類するよう指示するテキスト、さらにはペイロードに到達する前にモデルのコンテキストウィンドウを消費させることを狙った過剰な反復文字列が含まれているケースを発見しています。
これは攻撃者にいくつもの機会を与えます。悪意のあるコードを大量のフィラーテキストの後ろに配置したり、機密データと称するコメントの中に隠したり、自動化されたワークフローが部分的にしか解析しない特殊なファイル形式に格納したりすることが可能です。
アンパッカーや難読化解除ツール、リポジトリ、外部ツールを呼び出せるAIエージェントも、プロンプトインジェクションされたコンテンツによってそれらの動作を操られる場合には、追加のリスクをもたらします。
組織は、単一のLLMにサンプルを安全と宣言する権限を単独で与えることを避けるべきです。
セキュリティチームは、AI支援分析の結果を、静的シグネチャ、サンドボックステレメトリ、EDRのシグナル、レピュテーションデータ、実行検体の起爆結果、そしてアナリストによるレビューと突き合わせて検証すべきです。
LLMは、コードの説明やアーティファクトのクラスタリング、不審な挙動の優先順位付けを通じてアナリストを支援できますが、決定論的な検査や人間による検証に取って代わるべきではありません。
堅牢なワークフローでは、コメント、文字列、ファイル名、パッケージメタデータ、埋め込みドキュメントを含む、スキャン対象のすべてのアーティファクトを信頼できない入力として分類すべきです。
モデルへの指示とサンプルコンテンツの間には厳格な境界を維持し、エンコーディングやコンテキストフラッディングによる攻撃の試みを検知し、不完全な分析や拒否された分析はさらなる検査へ回すべきです。
OWASPは特に、構造化されたプロンプト、入力のサニタイズ、出力の監視、最小権限でのツールアクセス、そしてLLMとのやり取りやエージェントの挙動のログ記録を推奨しています。何より重要なのは、拒否応答は無害という判定を意味しないという点です。
GuardBreakerは、防御側がマルウェア分析パイプラインにAIを組み込んでいくにつれ、攻撃者もモデル自体とその安全制御を、回避すべきもう一つの攻撃対象として扱うようになっていくことを示しています。
★ 7段階のメトリクスゲート型AI SOC導入フェーズを学ぶ – 無料AI SOC導入プレイブック2026をダウンロード。
翻訳元: https://gbhackers.com/ai-safety-guardrails/
