実環境で確認されたCyberStrikeAI：LLMオーケストレーターがラテンアメリカとアフリカの教育機関標的でドメイン管理者権限に到達

2026年11月2日、Kasperskyは、ラテンアメリカとアフリカの複数国にある教育分野の組織への侵入を記述したSecurelistレポートとプレスリリースを公開した。これらの侵入では、侵害後の作業が大規模言語モデルによって指示されていた。使用されたツールはCyberStrikeAIで、Goベースのオープンソース penetration-testing フレームワークであり、そのコマンドアンドコントロールサーバーがLLMをホストしてツールの選択とコマンドの作成を行い、通常のインプラントが被害ホスト上でそれらを実行する。Kasperskyが詳細に再構成した1件の事例では、人間のオペレーターが侵害されたMicrosoft SQL Server経由で侵入し、2週間停止した後、エージェントを実行させた。ドメイン管理者アカウントは3～4日以内に陥落し、最後の段階——横展開、大規模な認証情報のダンプ、データベースのエクスポート——は1時間以内に完了した。Kasperskyは機関名も国名も挙げておらず、被害者数も示しておらず、2026年9月から10月の間にこの活動を観測したと述べている。このキャンペーンの完全な記録は、深刻度評価、信頼度評価、完全な情報源リストとともに、Orca AI Incident Archiveに、AI支援型侵入に関する他の項目と並んで収録されている。

Kasperskyが実際に公開した内容

主要文書は、2026年11月2日にSecurelistで公開され、Kasperskyの脅威リサーチチームのKirill Antonov、Vladislav Vlasov、Dmitry Chizhmakによるものとされている「CyberStrikeAI in the wild：実環境における組織への攻撃でのAI利用」である。同日に発行されたKaspersky自身のプレスリリースが添えられており、同じ調査結果を要約している。アーカイブの信頼度グレードAは、これら2つの文書が互いにどの程度一致しているか、また技術的詳細がどの程度具体的であるかを示すものであり、別の組織がこの侵入を独立に検証したという表明ではない。

この報告の二次報道は、その第二の組織については何も提供していない。Cybersecuritynews.com、Cyberpress、SecurityOnline、およびナイロビ拠点のTechTrends Kenyaはいずれも2026年11月2日から3日にかけて記事を公開したが、各記事は独自調査によるものではなく、カスペルスキーの発表に基づいている。ケニアの媒体の記事は、カスペルスキーの脅威探索責任者ニキータ・ナザロフによる同一のプレスリリース引用を中心に構成されている。2026年11月9日時点で、被害を受けた大学、教育省、国家コンピュータ緊急対応チームのいずれも侵入を公に確認しておらず、カスペルスキーも被害者の身元を公表していない。この不在自体が記録の一部である。詳細に記録されているのは攻撃手法であり、名指しされた機関への被害ではない。

Kasperskyの対象範囲に関する声明は意図的に狭く限定されている。確認された被害者は、同社の言葉によれば「アフリカおよびラテンアメリカの複数国にある教育分野の組織」だった。何組織か、どの国か、そもそもこのキャンペーンがどのように検知されたのかについては述べておらず、チームが「プロアクティブな脅威監視の一環として」発見したとだけ述べている。

ここで一つの区別が重要である。混同されやすいからだ。独立系組織は今や、実際の侵入事例でCyberStrikeAIを報告している——ただしこれらの侵入事例ではない。Team Cymruは、このツールを稼働させていたインフラを、600台超のFortiGate機器を標的とした2026年1月～2月のキャンペーンに関連付けた。2026年1月20日から2月26日までの間に、それを配信していた21個の固有IPアドレスを観測したことによる。Trend MicroのTrendAI部門は、2026年10月23日に公表した調査で、44体の連携したCyberStrikeAIエージェントを実行する運用者について述べ、それらのエージェント群が、少なくとも19の識別可能な組織（うち少なくとも16が日本）を、その10月の短い期間に検証活動にさらしたとした。Cloud Security Allianceの2026年10月28日のリサーチノートは両者を統合し、公開された情報源で別々のCyberStrikeAIキャンペーンを単一の行為者に結び付けたものはまだなかったと結論付けている。その一連の研究は、このフレームワークが実際のネットワーク攻撃に使われているという前提を裏付けるものであり、Kasperskyの報告におけるラテンアメリカとアフリカの教育機関の被害者については何も述べていない。

ツールと、AIが実際に置かれていた場所

Kasperskyが説明するところによれば、CyberStrikeAIは「Goで書かれた、ペネトレーションテストを自動化するためのオープンソースのモジュール式プラットフォーム」です。その際立った設計上の選択は、インテリジェント層全体が被害者のマシン上ではなく、攻撃者の制御サーバー上に存在することです。偵察および脆弱性悪用のユーティリティ、ウェブシェル管理、エージェントへのタスク割り当て、結果の読み取りはすべて、単一のサーバープロセス内でMCPツールとしてモデルに公開されており、次にどれを呼び出すかを決めるのはモデル自身です。

インプラントはもう半分であり、意図的に愚かにつくられています。Kasperskyは、それを「AI機能を一切持たない古典的なC2エージェント——APIキーもなく、AIサービスAPIへの呼び出しもなく、自律的なロジックもない」と書いています。インプラントはHTTP/S、TCP、またはWebSocketでリスナーをポーリングし、シェルコマンドを実行し、ファイルシステムにアクセスします。被害者のネットワーク内で動作するモデルではなく、AIプロバイダーに接触することも決してありません。役割分担について、Kasperskyがこの仕組み全体を説明するために使っている文はこうです。「意思決定は2つのレベルに分散される。オペレーターがタスクを概括的に定義し、モデルがそれをどのように実行するかを決定する。」

人間による制御は取り除かれるのではなく維持されます。Kasperskyは、ヒューマン・イン・ザ・ループの仕組みを指摘しており、それによれば「オペレーターはプロセス全体に対して完全な制御を保持」し、モデルが生成したコマンドは「実行される前に手動での承認や修正が必要になる場合がある」としています。AIが手順を書き、人間はなおそれを拒否できます。

再構成された1件の侵入を、Kasperskyが年代を特定した順に示す

このレポートは、キャンペーン内の単一のインシデントを追跡しており、その第1段階は通常のハンズオン・キーボード作業のように見える。被害者のシステム上のコマンドはsqlservr.exeプロセスから発せられ、「侵害されたSQL Server（バージョン16.0.1000）」が侵入経路である可能性が高いことを示していた。その後、オペレーターは基本的なホスト情報を収集し、ツールを配備し、手作業でネットワークをマッピングした。これには「ほぼ1日」かかり、その後、攻撃者は約2週間沈黙した。

第2フェーズではテンポが変わる。CyberStrikeAIエージェントを配備すると、永続化とローカル偵察は「2分以内」に完了した——SystemUpdateという名前のスケジュールされたタスクをインプラントに向け、Windowsではフレームワークの代替手段としてHKCU\Software\Microsoft\Windows\CurrentVersion\Run配下のレジストリRunキーを、Linuxではその代替としてcrontabの@rebootエントリまたは~/.bashrc内のnohup行を用いた。ドメイン偵察は「その後5時間にわたり」実行され、モデルが生成したPowerShellスクリプトとActive Directoryに対するLDAPクエリを使用し、KerberoastingとAS-REP Roastingの準備に必要な検索や、LAPS、Azure、.azcopyディレクトリのチェックを含んでいた。「数日間の短い中断」の後、最終段階——SMBとWMIを介した横展開、大量の資格情報ダンプ、データベースのエクスポート——は「1時間以内」に完了した。

カスペルスキーの要約の一文は残す価値がある。攻撃全体は「エージェントの展開からドメイン管理者の侵害に至るまで、3～4日以内に完了した」というものだ。

資格情報に関する作業は、目新しいものではなく、よく知られたWindows技法のカタログである。reg.exeでレジストリハイブをコピーし、コマンドライン照合を回避するためにプロセス名ではなくプロセスIDを使ってcomsvcs.dllのMiniDump関数経由でlsass.exeをダンプし、さらに、組み込みのドメイン管理者アカウントが侵害された後には、名前を変更したMimikatzバイナリwdiag2.exeを通じてDCSyncおよびGolden Ticket攻撃を実行した。横移動にはImpacketのWMIExec、共有管理フォルダー、WMIが使われ、リバースシェルスクリプトp1.ps1がリモートホストにプッシュされて185.186.245[.]144:5501にコールバックした。ペイロードはd3.b64などの断片に分割され、certutilで再構成され、1つのビーコンはsvchosts.exeに偽装していた。

収集は最後だった。エージェントはタスクに合わせたSQLクエリを生成したが、実行する前にデータベースアカウントの権限を確認し、ファイルを取得する前にネットワーク共有を再帰的にスキャンし、すべてを同じ暗号化されたC2チャネル経由で、データをJSON内にBase64エンコードして返送した。WindowsとLinuxの両方でスクリーンショットを取得できたが、Kasperskyの説明では、オーケストレーターがコマンドを発行したときにのみ取得された。報告書は、データ収集が「攻撃の最終段階であり、攻撃チェーンはそこで終了し、それ以上の活動は確認されなかった」と述べている。

何が奪われたのか、そして記録が語らないこと

Kasperskyは、そのエージェントが教育機関のSQLサーバーからデータベースレコードをエクスポートし、ネットワークリソースからファイルを収集したと記録しており、その仕組みを詳細に説明している。ただし、何件のレコードやファイルが持ち出されたのか、エクスポートが完了したのか、テーブルに誰のデータが入っていたのかは述べていない。この点について、二次的な要約は報告書以上に踏み込んでいる。SecurityOnlineの記事は、エージェントが「データベーステーブルから学生と職員の記録を窃取するために標的型SQLクエリを生成した」と述べているが、Kaspersky自身の文章は、教育機関のSQLサーバーに対するクエリについて説明しているものの、テーブルに何が含まれていたかは特定していない。読者は「学生と職員の記録」という説明を、Kasperskyの調査結果ではなく二次的な性格づけとして扱うべきである。

また、記録には次の点も残っていない。被害者のいずれかが侵入自体を検知したかどうか、各機関がその後何をしたか、影響を受けた国の規制当局やデータ保護当局に通知されたかどうか、そしてこのキャンペーンが今も進行中かどうか。Kasperskyは、調査したインシデントで最後に観測された段階はデータ収集だった、とだけ述べている。プレスリリースには影響を受けた組織向けの修復ガイダンスは含まれておらず、その推奨事項は一般の防御者向けのものだ。

アトリビューション：証拠が裏付けるものと、裏付けないもの

Kasperskyは、攻撃者を特定することはできないと明言している。「入手可能なデータでは、この活動を既知の攻撃者グループのいずれにも結び付けることはできず、同じ運営者が両方のキャンペーンの背後にいることを確実に述べることもできない」と。同社が根拠としているのは、インプラント内のGoビルドメタデータであり、これにはバージョン管理のハッシュ、コミット時刻、作業コピーがダーティであることを示すフラグが含まれている——「特定のビルドの一意なフィンガープリント」である。これに基づき、サンプルは2つのグループに分かれ、各グループ内ではWindowsとLinuxのペイロードが同一のメタデータを共有しており、同じ作業コピー由来であることを意味している。

これらのグループは結びついておらず、「共通のC2インフラを共有していない」うえ、2組の制御サーバーでは異なるバージョンのCyberStrikeAIが動作していた。カスペルスキーは、ここで帰属特定が難しい理由を2つ挙げている。フレームワークが公開されているため、異なる運用者が同様の条件下で独立にペイロードを構築できた可能性があること、そしてコマンド自体がモデル生成であるため、その多様性が膨らむ一方で、行動ベースの帰属特定が依存する個々の癖が剥ぎ取られることだ。

残るのは決定的なものではなく示唆的なものだ。一部のスクリプトには中国語のコメントが含まれ、攻撃者は中国のサービス dnslog[.]cn を使って被害ホストからのインターネット接続を確認しており、制御サーバーの再起動の大半は——自己署名TLS証明書が起動のたびにメモリ内で再生成されるため、その not_before フィールドが再起動時刻を記録しており、復元可能だ——UTC+8の業務時間内に発生していた。CyberStrikeAI 自体は中国のサイバーセキュリティコミュニティ内で開発された。Kasperskyのプレスリリースは線引きを明快にしている。これらの痕跡は「攻撃者の身元や所在を立証するものではない」し、同社は「この活動を既知の脅威グループに帰属させることも、同一の運用者が特定されたすべてのインフラを管理していたと確認することもできなかった」と述べている。中国語を話す運用者というのは推論であり、発見事項ではない。

なぜKasperskyがこれは検出の緊急事態ではないと述べているのか

報告書の結論は、キルチェーン内のLLMが新たな種類の防御を必要とするという考えに反論している。モデルは攻撃者のサーバー上に存在するため、それは「インフラ内にその存在の痕跡を残さなかった（ローカルLLMへの特定のAPIリクエストや、ホストによる異常なリソース消費パターンなど）」のだ。代わりに防御側が目にするのは、人間が行ったような侵入である。同じユーティリティ、同じシーケンス、同じイベントログエントリだ。Kasperskyの評決は、「AIを攻撃チェーンに導入することは、まだ検出に根本的に新しい課題をもたらしてはいない」、「古典的で適切に調整された相関分析および行動分析のルールで十分である」、そして新規性は「手法そのものではなく、それが実行された速度と容易さにある」というものである。

公開された検知は、新しい論理を考案するのではなく、その論理に従っています。Kaspersky Anti Targeted Attack は、インプラントのトラフィックに対してネットワーク判定 Backdoor.CyberStrikeAI.HTTP.C&C を付与します。「Scanning domain records via LDAP queries」という名前のネットワーク異常検知ルールがドメイン偵察を捕捉します。Kaspersky SIEM は、DCSync、Golden Ticket、Kerberoasting、Impacket WMIExec を含む、レポート内の手法をカバーする100以上のルールを提供しています。さらに、インプラントは HEUR:HackTool.Win64.CyberStrike.gen および HEUR:HackTool.Linux.CyberStrike.gen に分類されます。Kaspersky の顧客向けガイダンスは従来型のものです。すなわち、エンドポイント検出および応答、ネットワーク検出、脅威インテリジェンス、そして勤務時間外の監視またはマネージドサービスを通じた監視です。

プレスリリースにおけるNazarovの発言は、同じ主張を一文にまとめたものだ。攻撃者は「CyberStrikeAIに基づくAIエージェントを使用して完全な攻撃チェーンを実行し、侵害されたネットワーク内で次のステップを適応させた」ものの、「そのフレームワークは依然として、ディスカバリー、資格情報のダンプ、横展開、収集および外部送信といった既知の手法と手順に依存していた」。

何が確立されており、何が確立されていないのか

率直に言えば、そのメカニズムは、防御側が明日にもそれを追跡できるレベルまで文書化されている——sqlservr.exeからのプロセス系譜、SystemUpdateという名前のスケジュールされたタスク、comsvcs.dllを介したLSASSへのアクセス、ドメインコントローラー以外からのDCSync、X-Implant-Token HTTPヘッダー、そしてKasperskyが列挙するC2アドレスだ。だが、そのメカニズムを取り巻くキャンペーンについてはそうではない。Kasperskyは被害者リストも、国別の内訳も、データ量の推定も、攻撃主体も公表していない。誰が害され、どれほど深刻だったかについて読者が知りたいと思うことはすべて、業種と地域の情報で止まっている。

報告書にもっと多くの情報を期待して読む人にとって、指摘しておく価値のある詳細が2つある。第一に、Kasperskyはこの攻撃を「初の」ではなく「実環境でLLMが関与した侵害についての最初期の公的な説明の一つ」と表現している。これは、主張をチームが公開報告から確認できた範囲にとどめるための慎重な表現だ。第二に、報告書は、インプラントのバージョンはサーバーのバージョンに追随しておらず、リスナー設定とキーはオペレーターの更新後も存続し、サンプルのビルド日は展開可能な最早日を示すだけで、侵害の期間を示すものではないと指摘している。3～4日という数字は、再構成された1件のインシデントの測定値であり、こうした侵入のいずれかが誰かに気づかれる前にどれだけ続いたかの上限を示すものではない。