更新情報2：ARTEX亜種が「公開面突破→内部段階突破→AD陥落」へ進化。大多数の企業にとっての駆け込み寺とは？
情報システム部門を持っているほぼすべての日本企業において、非常時になっていると思います。サイバーセキュリティ専門の担当を置いて、この非常時に采配をふるうことができる企業はごくわずかと見ています。残りの大多数の企業に向けて、「サイバーセキュリティのリアルタイム情報収集と分析、提言では今最高のキレを見せているGrok」から得たテキストを共有します。Grokをぜひお使い下さい。
Grokは、現在進行形のA2B攻撃やARTEX亜種による新しいタイプのAIエージェント攻撃についても、分析対象のウェブページURLを入れるだけで、かなりのことをかみ砕いてくれます。プロにはプロなりに、サイバーセキュリティの知識がほとんどないCIOにはそれに合わせて、わかるように説明できます。
ありがたいのは、多くのIT専門誌にありがちの「危機は指摘するが、対策は書かない/書けない」という姿勢ではなく、「では、この非常時に誰を頼ればいいのか？」「次善の策はないのか？」といった質問にも、的確に応えられることです。
なお、ご参考までに、御社の公開情報ベースで、サイバーセキュリティの脆弱性の所在地が、Gemini + ディープリサーチ（有料版で使えます）で、かなりのところまでわかります。対策の前段階の準備として、レポーティングさせると、専門会社と話し合う際に便利です。プロンプトはGeminiと問答しながら作りこんで下さい。
駆け込み寺的に使うことができるTCSについて、利用のハンドブックを作成しました。以降、Infosys, Wipro, HCLTechについても作成し、ここで共有します。
さっつーのAIエージェント：AIエージェント型サイバー攻撃（A2B攻撃）の対策をTCS（タタコンサルタンシーサービシズ）に依頼するためハンドブック
さっつーのAIエージェント：AIエージェント型サイバー攻撃（A2B攻撃）の対策をInfosysに依頼するためハンドブック（インフォシス）：販売価格1万2,000円
さっつーのAIエージェント：AIエージェント型サイバー攻撃（A2B攻撃）の対策をWipro（ウィプロ）に依頼するためハンドブック
伏字...
その後の数日で、状況はさらに具体化しています。特にARTEXの派生版が、単なるWeb/APIレベルの侵害を超えて公開サーバから内部ネットワークを段階的に突破し、Active Directory（AD）まで到達する機能を強化している点、そして国内事案での使用確認は、脅威の質が一段変わったことを示しています。
### ARTEX系の進化と国内確認
ARTEXは百度コンテストで優勝したオープンソースのマルチエージェント型ペネトレーションテスト基盤で、外部LLMをオーケストレートして自律的に偵察・脆弱性探索・攻撃を進めるツールです。韓国の金融機関攻撃で痕跡が確認され、開発者がソースを非公開化した後も、複数のフォークやリブランド版が流通しています。
三輪信雄氏：サイバー攻撃に使われているとされるARTEXが、二次フォークで進化している様子を系統図にしました。
オリジナルの分析だけでは不十分です。（系統図はX投稿を参照）
その中で注目されるのが3次フォークとされるRuBat-Bです。セキュリティ事業者の観測では、この派生版は公開Webサーバの初期侵害を足がかりに、DMZを経由して内部の業務AP/DBセグメントへ、さらにAD環境まで「段階突破」する機能を追加しています。ファイアウォールが許可する業務通信を持つホストを乗っ取り、その通信許可を「相続」して1段ずつ進む仕組みで、従来の多層構成では被害が広がりやすい構造です。英語・韓国語ローカライズ版のScopeWeaverのような派生も確認されており、オリジナルの名前だけを追うだけでは不十分な状況になっています。
国内でも、GMO関連の事案でARTEXの使用が確認されたと報じられました。韓国の銀行事案と共通するパターンであり、「中国製AIソフト」という表現よりも、オーケストレーションツールとして強力なモデルを組み合わせることで能力を発揮する実態の方が正確です。
### 検知の現実と脅威の裾野の広がり
初期段階のWeb攻略に対して従来型WAFの効果は限定的です。一方で、系統のソースにハードコードされたUser-Agentは現時点で有効な痕跡として残っており、巨大JSバンドル取得直後の体系的なAPI連続リクエスト、単一変数の差分プロービング、応答時間が一定間隔に揃うパターン、OOBコールバック、同一脆弱性への構造的再プローブの反復といった挙動は、変形されにくい特徴として指摘されています。最終的な層としては実行シンクでの検知（RASP的アプローチ）が回避困難です。
以下の文章を、サイバーセキュリティの中級者向けに噛み砕いて解説します。
> 一方で、系統のソースにハードコードされたUser-Agentは現時点で有効な痕跡として残っており、巨大JSバンドル取得直後の体系的なAPI連続リクエスト、単一変数の差分プロービング、応答時間が一定間隔に揃うパターン、OOBコールバック、同一脆弱性への構造的再プローブの反復といった挙動は、変形されにくい特徴として指摘されています。最終的な層としては実行シンクでの検知（RASP的アプローチ）が回避困難です。
この文章が言っていることは、「WAFなどのシグネチャベース検知は簡単に回避されるが、攻撃ツールの"やり方そのもの"に残る特徴は比較的残りやすく、最終的にはアプリケーション内部の実行箇所で検知するしかない」という内容です。
### 1. ハードコードされたUser-Agent
攻撃ツール（ARTEX系統のフォークなど）のソースコードを見ると、静的収集やクローリングを行う部分で、特定のUser-Agent文字列を固定で送るように書かれていることがあります（例: `Mozilla/5.0 (spa-api-recon)` など）。中級者向けのポイントは、「User-Agentは簡単に変えられるはずなのに、なぜ有効なのか」です。理由は、ツールの開発者が「とりあえず動く」ことを優先してハードコードしたままフォークが進んでいるケースが多いからです。完全にカスタマイズされた攻撃では消えますが、現時点で流通している派生ツールではまだ残っている、という観測に基づいた話です。
### 2. 巨大JSバンドル取得直後の体系的なAPI連続リクエスト
モダンなWebアプリ（特にSPA）では、フロントエンドのロジックが大きなJavaScriptファイル（バンドル）にまとめられています。攻撃ツールはまずこの巨大なJSを取得し、そこからAPIエンドポイントやパラメータを機械的に抽出し、直後にそれらのエンドポイントへ体系的にリクエストを送ります。「体系的」というのは、ただランダムに叩くのではなく、抽出したエンドポイント群に対して一定の順序やパラメータの組み合わせで連続してアクセスする動きです。人間が手動でやるには不自然な速さ・パターンになります。
### 3. 単一変数の差分プロービング
ほぼ同じリクエストを何度も送りながら、1つのパラメータだけを少しずつ変えていく手法です（A/B比較のような動き）。例えば、IDの値を1ずつ変えたり、文字列の一部を変えてレスポンスの差分を見たりします。認可不備（IDORなど）や入力検証の弱点を効率的に探すための典型的なやり方で、ツールが自動化しやすい動きです。### 4. 応答時間が一定間隔に揃うパターン
time-based SQLインジェクションなどでよく見られる動きです。攻撃ツールが「応答が3秒遅れたら真、5秒なら偽」のように、意図的に遅延を入れて結果を判定する場合、応答時間が3s/5s/7sなど綺麗に揃います。通常のユーザーアクセスではこんなに規則正しく遅延が揃うことは稀です。### 5. OOBコールバック
Out-of-Band（帯域外）の通信です。攻撃が成功したかどうかを、対象サーバから攻撃者の用意した外部サーバへDNSやHTTPで問い合わせが来ることで確認する手法です。公開サーバから本来不要な外部への通信が発生するため、ネットワーク監視で検知しやすい特徴になります。### 6. 同一脆弱性への構造的再プローブの反復
1つの弱点を見つけた後、ツールが「本当に悪用可能か」を確認するために、同じ脆弱性に対して構造を変えた複数のプローブ（試しのリクエスト）を繰り返し送る動きです。単純な再送ではなく、ペイロードの形式を少しずつ変えて検証するパターンが特徴的です。### なぜこれらは「変形されにくい」のか
User-Agentや特定の文字列は変えやすいですが、上記の挙動は「攻撃を成功させるための手順そのもの」に近いです。ツールが効率的に脆弱性を探すためには、JSを読んでエンドポイントを洗い出し、差分を見て、時間差やOOBで確認し、再検証する、という流れをある程度踏まざるを得ません。完全にこの流れを崩すと、ツールとしての利便性が大きく落ちるため、フォークが進んでも比較的残りやすい、という指摘です。### 最終的な層：実行シンクでの検知（RASP的アプローチ）
WAFやネットワーク層でいくら回避されても、実際にSQLが実行されたり、OSコマンドが走ったり、テンプレートが処理されたりする「シンク（最終的な実行箇所）」で悪性な値が通ったことを検知する方式です。RASP（Runtime Application Self-Protection）と呼ばれるアプローチに近く、アプリケーション内部でデータを追跡（taint tracking）して、危険な処理に到達した時点で検知・遮断します。攻撃を成功させるためには、結局どこかで悪性値をシンクに通す必要があるため、ここは比較的回避しにくい層になります。ただし導入・運用コストはWAFより高くなります。
### まとめ（中級者向けの実務的な読み方）
- 文字列マッチ（User-Agentなど）は「今はまだ使えるが、すぐ消える可能性がある」暫定策。
- 挙動パターン（JS取得直後の体系的API叩き、差分プロービング、時間の規則性、OOB、再プローブ）は、ログやトラフィック解析で比較的長く使える検知材料。
- 本当に確実に止めたいなら、アプリケーション内部のシンク検知まで視野に入れる必要がある。この文章は、「WAFだけで安心するな。ツールの動作原理に根ざした特徴を監視し、最終的にはアプリ内部で検知する層も検討せよ」という実務的な警告
技術的な詳細を超えて重要なのは、攻撃能力の民主化です。オープンウェイトモデルを中心にフロンティアモデルを組み合わせ、オーケストレーションツールでつなぐだけで、一定レベルの攻撃が実行可能になります。金銭動機のアクターだけでなく、政治的ハッカーや悪戯レベルの行為者によるサービス停止や小規模侵害が増えると、被害の裾野が広がり、特にセキュリティ投資が薄い組織の対応コストと信頼低下が経済的負担として蓄積します。
### 大多数の企業にとっての現実と駆け込み寺的対応
ここで直面する最大の問題は、こうした脅威に対して当事者能力を持つ企業が極めて限られている点です。東証プライム上場企業のうち、自前でアーキテクチャを設計・運用し、ベンダーをコントロールできる層はおそらく数％前後にとどまり、残り大多数は長年日本のSIerに丸投げして外注管理だけをやってきた構造です。国内SIerは現在の非常時で新規を受け付けにくい状況にあり、「方針は自社で主導し、実装は分担する」という理想形を取れる企業は少数派です。
こうした企業にとって現実的な延命策は、インド系大手（TCSなど）への実質的な依存を前提とした「駆け込み寺的な対応」です。完全に自社で方針を固められない以上、以下の最低限のガードレールを契約に組み込みながら、外部の力を使うしかありません。
- 成果物（手順書・ポリシー・ログ・監査記録）は日本語で自社に引き渡すことを義務づける。英語のみの成果物は受け入れない。
- 主要担当者を契約で特定し、週次または隔週の進捗確認を義務づける。技術者がいなくても、経営企画や情報システム部門の管理職が「何が終わったか」を確認できる状態を作る。
- 最初から全システムを対象にせず、「公開資産の棚卸しと優先APIの暫定対策を90日以内に完了させる」など、具体的な成果指標に絞る。
- データ処理の範囲、使用するAIモデルの制限（中国系モデルの除外など）、データの所在を契約で明確に縛る。
優先すべきは本格的なゼロトラストやAIエージェント防御ではなく、まず公開面のリスクを下げることです。インターネットから見えるWeb・アプリ・APIを一覧化し、不要なものを止めるかアクセスを制限する。直近数ヶ月のログを外部で分析してもらい、不審なパターンがないかを確認する。管理画面や重要なAPIにMFAを強制する。これらは比較的短期間で実施可能で、インド系パートナーに「まずこれをやれ」と指示しやすい内容です。
国内の専業セキュリティ企業に診断やログ分析だけを限定依頼したり、既存取引のあるSIerに「公開面の棚卸しだけでも」と優先枠を交渉したり、クラウド事業者のネイティブ機能をインド系パートナーに設定してもらう形も組み合わせられます。完全な丸投げを避けるための可視性確保と、スコープの極端な絞り込みが、当事者能力のない企業にとっての駆け込み寺的な最低条件です。
### 経営層への伝え方と今後の見通し
「国内SIerが受けられない以上、インド系を使わざる得ない。ただし契約で最低限の可視性は確保し、まず90日で公開面のリスクを下げる」という現実を、経営層に正直に伝える必要があります。何もしないことのリスク（漏えい・サービス停止・信頼失墜）の方が、外部に頼るコストより大きいという判断です。
前回の時系列仮説は、百度コンテスト→A2B急増→ARTEX系の悪用確認という流れで一定の整合性を保っています。今後、フォークのさらなる進化や国内事案の詳細が明らかになるにつれ、「低コスト高並列の既知弱点狙い＋内部ピボット」というパターンが標準化していく可能性が高いです。大多数の企業にとっては、理想を追うより、限定的でも外部の力を使って公開面のリスクを下げる駆け込み寺的な対応が、現時点での現実的な延命策になります。
t-Kimura氏：
やはり韓国の銀行と同じパターンですね。
日経は「人工知能ソフト」と表現しているが、誤解を招くは表現です。ARTEXは「オーケストレーションツール」です。
ARTEXがばら撒かれた以上、オーケストレーションの中央にオープンウェイトを置き、あとは最強のフロンティアモデルを複数並べれば完成する。
誰にでもできることが問題で、テロリストや政治ハッカーのみならず、世界中の「無敵の人」たちが悪戯で様々なサービスを停止できる。
フロンティアモデルがオーケストレーションツール検知機能を付けたところで、いくらでも回避策は出てくるため、デスマーチは必至です。
