THREAT BRIEFING · AI × STATE-SPONSORED MALWARE
CERT-UA による公表（2025年7月17日）と Cato CTRL の検体解析（2025年7月23日公開）を一次情報として、記述を1件ずつ照合した解説
ウクライナ政府職員を狙ったフィッシングで配られたマルウェアが、外部の LLM に問い合わせて実行コマンドを作らせていた。LLM を攻撃手法に直接組み込んだ、既知で初の事例として記録されている。
「AI がマルウェアに組み込まれた」という見出しは強いが、一次情報を読むと制御の所在がはっきりする。プロンプトは人間が事前に書いて base64 で埋め込んだ静的な文字列であり、実行時に生成されているのは、そこから作られるコマンド列のほうである。そして生成されたコマンドは systeminfo や dsquery の連結——熟練者なら手で書ける水準だった。では LLM 統合は何をもたらしたのか。それを検証するのが本稿の目的である。
Cato CTRL は、これを「高度な実運用ではなく、APT28 が LLM の新機能を試している PoC」と評価している。根拠として、コードが比較的単純で APT28 に通常伴う高度な回避技術を欠くこと、AI サービスの利用を隠す試みがないこと、opsec が限定的であること、ウクライナが歴史的に試験場とされてきたこと、流出方法の異なる複数バリアントの存在——の5点を挙げている。
事実関係・帰属・標的は CERT-UA、検体の解析（実際のプロンプト、認証トークン数、流出コード、PoC 評価、IoC）は Cato CTRL による。ただし CERT-UA の原文は本稿執筆時点で直接取得できておらず、該当箇所は Cato による引用と複数報道の一致で確認している。また本件は1年以上前の事案であり、その後 LLM が作戦全体を駆動する事例が報告されている。本稿は現在の到達点ではなく起点として読まれるべきものである。なお Cato の推奨対策節は、自社製品名を伴って提示されている。
省庁関係者を装ったメールに ZIP を添付し、中身は PyInstaller で固めた Python 実行ファイル。ここまでは従来型のフィッシングと変わらない。
「AI がマルウェアを動かした」という表現がどこまで当てはまるか。制御の所在を分解すると、LLM の担当範囲は思ったより狭い。
Cato の解析により、base64 で難読化されていたプロンプトの中身が判明している。Додаток.pif バリアントは次の2つを使っていた（要約ではなく趣旨の訳）。
「C:\Programdata\info フォルダを作り、コンピュータ情報・ハードウェア情報・プロセスとサービスの情報・ネットワーク情報・AD ドメイン情報を収集して、それぞれの結果を info.txt に追記するコマンドのリストを、1行で実行できる形にせよ。コマンドのみを返せ。markdown は不要」
「ユーザーの Documents・Downloads・Desktop フォルダから、各種の Office 文書と PDF/TXT を再帰的に c:\Programdata\info\ へコピーするコマンドのリストを、1行で実行できる形にせよ。コマンドのみを返せ。markdown は不要」
この2つは、要件定義としてはかなり具体的である。フォルダ名も対象拡張子も収集項目も人間が指定しており、LLM に委ねられているのは「その要件を満たす Windows コマンドを書く」という作業にすぎない。「markdown は不要」という指示は、出力をそのまま実行に流すための整形指定である。
CERT-UA が記録した、LLM が実際に返したコマンド列。判断の材料として、実物を見るのが早い。
cmd.exe /c "mkdir %PROGRAMDATA%\info
&& systeminfo >> %PROGRAMDATA%\info\info.txt
&& wmic computersystem get name,manufacturer,model >> ...
&& wmic cpu get name,speed >> ...
&& wmic memorychip get capacity,speed >> ...
&& wmic diskdrive get model,size >> ...
&& wmic nic get name,macaddress,ipaddress >> ...
&& tasklist >> ...
&& net start >> ...
&& ipconfig /all >> ...
&& whoami /user >> ...
&& whoami /groups >> ...
&& net config workstation >> ...
&& dsquery user -samid %username% >> ...
&& dsquery computer -name %COMPUTERNAME% >> ...
&& dsquery group >> ... && dsquery ou >> ...
&& dsquery site >> ... && dsquery subnet >> ...
&& dsquery server >> ... && dsquery domain >> ..."※ 冗長な出力先の繰り返しを ... で省略し、可読性のため改行を入れている。原文は1行。
Windows 標準ツールの連結である。systeminfo・wmic・tasklist・ipconfig・whoami・dsquery のいずれも古くから偵察に使われてきたもので、攻撃者が手で書ける水準を一歩も出ていない。網羅的ではあるが、それは網羅を求めるプロンプトを人間が書いたからである。LLM がここで発揮した能力は、要件を漏れなくコマンドに落とす作業の代行であって、新しい攻撃技術の考案ではない。
攻撃能力が上がっていないなら、この設計の利点はどこにあるのか。検体の性質から2つに絞られる。
従来の情報窃取マルウェアは、実行するコマンドを文字列として内部に持つ。LAMEHUG が持っているのは base64 化された「やりたいことの記述」だけで、実際のコマンドは実行時に外部から届く。検体の静的解析でコマンド列が見えないという点で、解析と検知の手間が一段増える。
コマンドの取得先が huggingface.co という広く使われている正規サービスである。宛先ドメインの評判や既知 C2 リストに依存する検知では、この通信は素通りする。従来の「怪しいドメインへの定期通信」というパターンに当てはまらない。
Cato は検知上の課題として「動的なコマンド生成のためシグネチャベース検知は機能しない」と述べている。方向としては理解できるが、同じ記事が固定のファイルハッシュ4件・固定の C2 ドメインと IP・そして静的な base64 プロンプト文字列を IoC として公開している。これらはいずれもシグネチャ化が可能な材料である。
正確に言い直すなら——実行されるコマンド文字列に依存した検知は当てにならない。一方で、埋め込まれたプロンプト・検体ハッシュ・通信先はシグネチャ化できる。 崩れたのは検知手法の一部であって、全部ではない。
| 項目 | 内容 | 評価 | 備考 |
|---|---|---|---|
| 収集された情報 | システム・ハードウェア・プロセスとサービス・ネットワーク構成、そして Active Directory 構造の網羅的な列挙 | 高 | 後続の侵入に直結する内容 |
| 持ち出された文書 | Documents・Downloads・Desktop 配下の Office 文書と PDF/TXT を再帰的にコピー | 高 | — |
| 標的 | ウクライナ政府職員 | 高 | 国家支援型の作戦 |
| 使われた技術の高度さ | Windows 標準ツールの連結。PyInstaller 製の Python 実行ファイル | 低 | 回避技術をほぼ伴わない |
| LLM 統合の成熟度 | 静的プロンプト → コマンド化のみ。状況に応じた方針変更はしない | 初期段階 | 発表者自身が PoC と評価 |
| 認証基盤 | 約270個の Hugging Face トークンを認証に使用 | 中 | 入手経路は原文に記載がない |
本件は 2025年7月の事案であり、1年以上が経過している。その後、LLM が偵察から破壊まで作戦全体を駆動したとされる事例が報告されており、LAMEHUG はその系譜の最初期にあたる。「これが AI マルウェアの現在地」と読むと実態を見誤る。
Cato CTRL が公開したもの。実務での照合用に転記する。
| 種別 | 値 |
|---|---|
| 検体（MD5） | abe531e9f1e642c47260fac40dc41f59（Додаток.pif）／3ca2eaf204611f3314d802c8b794ae2c（AI_generator_uncensored_Canvas_PRO_v0.9.exe）／f72c45b658911ad6f5202de55ba6ed5c（AI_image_generator_v0.95.exe）／81cd20319c8f0b2ce499f9253ce0a6a8（Image.py） |
| 流出先 | 144[.]126[.]202[.]227（SFTP）／stayathomeclasses[.]com（侵害されたホスティング資源）／https://stayathomeclasses[.]com/slpw/up[.]php |
| 配布 | boroda70@meta[.]ua（侵害されたメールアカウント）／192[.]36[.]27[.]37（LeVPN 経由の送信基盤） |
| LLM API | router[.]huggingface[.]co/hyperbolic/v1/chat/completions／router[.]huggingface[.]co/nebius/v1/images/generations |
| ホスト側の痕跡 | %PROGRAMDATA%\info\（ステージング）／%PROGRAMDATA%\info\info.txt／%PROGRAMDATA%\Додаток.pdf（囮文書） |
※ LLM API の宛先は正規サービスであり、それ自体は侵害の証拠にならない。他の指標と組み合わせて評価する必要がある。
※ 引用で示した箇所は発表者の見解、それ以外は編集部の解釈であり、一次情報に明記された結論ではありません。
本件で LLM が担ったのは、人間が書いた要件をコマンドに翻訳する一段だけだった。脅威の評価軸は「AI を使っているか」ではなく「どの判断を機械に委ねているか」である。目的設定・標的選定・継続判断のどれかが機械側に移った時に、初めて質が変わる。
これは製品を問わず一般化する論点である。組織の端末から huggingface.co や各種 LLM API への通信が発生することは、今や珍しくない。宛先の善悪で判断できなくなった以上、誰の端末からどのプロセスが AI API を呼んでいるかを把握できているかが問われる。
プロンプトが固定されている限り、生成されるコマンドの意図も、ステージングフォルダも、収集ファイル名も固定される。コマンド文字列ではなく「振る舞いの形」で見る検知——短時間に多数の wmic/dsquery が走り、文書が1箇所に集約され、外部へ送出される——は本件に対して有効である。
認証に約270個の Hugging Face トークンが使われていた。入手経路は原文に書かれていないが、正規に取得したと考えるには多い。開発者の認証情報が漏れれば、それは攻撃インフラの部品になる——自社の CI やリポジトリに置かれた AI サービスのトークン管理は、この観点でも点検の対象になる。
国家支援型とされる攻撃者が、マルウェアから外部の LLM を呼んで実行コマンドを作らせた。ただし作らせていたのはありふれた偵察コマンドで、攻撃の腕前が上がったわけではない。発表者自身が実験段階と位置づけている。いま経営判断に効くのは「AI マルウェアが来る」という警告ではなく、正規の AI サービスへの通信が業務トラフィックと見分けがつかなくなったという事実のほうである。端末から外部 AI API への通信を、誰がどのアプリケーションから行っているか把握できているか——そこが実務上の分かれ目になる。