【情報漏洩】AIが勝手に「侵入口」を探す時代！～中国語AI「ARTEX」事件から、今週やるべき6つのこと

「うちは狙われるほど大きな会社じゃないから」

セキュリティの話になると、中小企業の現場でいまだによく聞く言葉です。しかし最近のWebサービスに対する一連の攻撃と情報漏洩などは、この前提を崩してきています。

攻撃側に必要だったのは、狙う会社を一社ずつ吟味することではなく、AIエージェントを利用し弱点ががある会社を「探させる」だけです。
弱点が見つかった会社から順に入られていきます。

今回は、日本企業を狙った攻撃で使われたと報じられた中国語AIエージェント「ARTEX（アーテックス）」について整理します。

1. 何が起きたのか：事実を整理する

まず、報じられている内容を時系列で並べます。

• 2026年9月下旬から10月上旬にかけて、韓国の金融機関を狙った攻撃が発生、米CrowdStrikeが10月7日に、攻撃にARTEXが使われていたと報告しました。
  攻撃者のサーバーには、ARTEXの設定ファイルやAI開発ツールの作業履歴が残っていたとされています。

• 10月8日、ARTEXの開発者はGitHub上で、悪用を受けて更新を終了し、ソースコードを非公開にすると表明しました。

• 10月19日、GMOサイバーセキュリティ byイエラエ（GMOサイバー犯罪対策センター）が、日本企業を狙った一連の不正アクセスでARTEXが使われていたことを確認したと発表しました。

• 同社が9月18日〜10月18日に確認した、日本企業を主に狙う海外の公開サーバー6台すべてで、ARTEXが動いていた痕跡が見つかったとされています。

• 標的となった日本企業のうち8社が、9〜10月に情報漏えいを公表済みです。
  報道では、標的は約80社に上る可能性があるとされています。

業種は保険・金融、通販、ポイント・ギフト、教育、物流など幅広く、サーバーごとに狙う業種が違っていたと伝えられています。

2. ARTEXとは何か

ARTEXは、中国語圏の開発者がGitHubで公開した、オープンソースの自律型ペネトレーションテスト（侵入テスト）用AIエージェントです。

ARTEXそのものは一般的にいうところの「AIモデル」ではありません。
ChatGPT、Claude、DeepSeekといった外部のLLMを「判断役」として呼び出し、次のような作業を連続して実行させる仕組みです。

• 標的の情報収集

• 脆弱性の探索

• 侵入経路の計画

• セキュリティツールの実行

• 見つけた弱点が本当に悪用できるかの検証

本来の目的は、企業が自社システムの弱点を事前に確かめることであり、防御の側にあります。
実際に開発者も「学習と研究のために作った」という趣旨の説明をしており、GitHubのページにも、実在するシステムへの実地テストには使うなという旨の注意書きがあったと報じられています。

けれども、侵入テストの道具は使う人間の意図ひとつで攻撃の道具に変わります。
人間のテスターが数日かけて回る作業を、AIが休まず回し続ける。
防御用に磨かれた自動化が、そのまま攻撃の効率化になってしまったわけです。

3. 攻撃はどう進むのか：5つの段階と、見るべき兆候

自律型の攻撃は、人間の攻撃者と同じ流れを機械の速度でたどります。
段階ごとに見るべき兆候を整理します。

① 偵察
公開Webサイト、API、管理画面、サブドメイン、クラウド上の検証環境を、自動で洗い出します。
→ 兆候：見慣れないクローラー、大量のディレクトリ探索、珍しいUser-Agent、サブドメインの総当たり的な名前解決。

② 弱点探索
既知の脆弱性（CVE）、設定ミス、認証の不備、APIの過剰な権限、古いミドルウェアを優先して探します。
→ 兆候：特定のパスへの反復アクセス、エラーメッセージを集めるような挙動、脆弱性スキャナに似た通信パターン。

③ 侵入
見つけた弱点や、漏えいした認証情報を使って、最初の足がかりを得ます。
→ 兆候：不審なログイン成功、異常なAPI呼び出し、身に覚えのないOAuth同意、管理機能へのアクセス。

④ 横展開
内部の追加情報を集め、権限の昇格や別のサーバーへの移動を試みます。
→ 兆候：想定外のホスト間通信、管理者権限の突然の利用、新しいアカウントやトークンの作成。

⑤ 情報窃取
集めたデータを外に持ち出します。
→ 兆候：大量ダウンロード、異常な外向き通信、深夜や休日の大量APIアクセス。

注目したいのは、ARTEXが「一つのIPから激しく攻撃する」タイプではないと報じられている点です。
WAF（Webアプリケーションファイアウォール）のレート制限を避けるため、しきい値ぎりぎりの量で、数百のIPアドレスを切り替えながら続けていたという報告もあるようです。
もし本当にそうなら、「同じIPからのアクセスが多いからブロックする」という昔ながらの運用だけでは、発見も防ぐことも難しいかもしれません。

4. なぜ被害が広がりやすいのか

理由は4つに整理できます。

わずかな弱点でも自動で突かれる。
GMOの調査担当者は、被害企業が「わずかなシステムの弱点」を突かれたと指摘し、見落としている脆弱性の総点検を呼びかけています。
人間なら見送るような小さな穴でも、AIは疲れずに全部試します。

攻撃のコストが下がる。
診断、計画、ツール実行をAIが担うため、高度な技術を持たない攻撃者でも、反復的な攻撃を実行しやすくなります。
韓国の件でも、少人数の操作者が短期間に複数の組織を狙えた点が懸念されています。

標的を分散できる。
攻撃者は国や業種ごとに攻撃用サーバーを使い分けています。
一つの拠点を見つけてもそこだけを塞げば終わりにはならず、検知を避けやすくなっています。

APIが特に危ない。
認証済みであっても、ユーザーごとの権限や、取得できるデータの量・頻度を制御していなければ、大量の情報を正規の手順のまま持ち出せてしまいます。

5. 優先度の高い6つの対策

対策1：外部公開している資産を、すべて把握する

表で稼働しているWebサイトだけの対策では足りません。
管理画面、API、クラウドの検証環境、委託先が運用するサービス、そして「もう使っていないはずのサブドメイン」まで棚卸しします。

AIによる自動探索で最初の入口になりやすいのは、実は「忘れられた資産」です。
誰も見ていない検証環境は、パッチも当たらず、監視もされません。

• 外部DNS、証明書の発行記録（証明書透明性ログ）、クラウド設定から一覧を作る

• 利用を止めたサービスや、テスト環境、管理画面が公開されたままになっていないか確認する

• 委託先が管理している資産も含め、誰が責任を持つのかを決めておく

対策2：既知の脆弱性と設定ミスを、最優先で潰す

JPCERT/CCは、影響を受けるバージョンの修正、不要なサービスや管理機能の公開停止、侵害後の横展開への備えの見直しなどを促していると報じられています。
派手な対策ではありませんが、ARTEXのような道具が最初に狙うのは、まさにここです。

• OS、Webサーバー、フレームワーク、CMS、VPN機器、ストレージのパッチ適用状況を洗い出す

• 管理画面、デバッグ機能、不要なポート、テスト用エンドポイントを閉じる

• 外部公開サーバーの設定確認と脆弱性診断を、一度きりでなく定期的に行う

対策3：APIを「認証済みだから安全」にしない

APIは、認可（誰に何を許すか）、データの範囲、回数制限、監査記録を、セットで設計します。

• ユーザーごと、テナントごとに最小限の権限だけを与える

• IDを書き換えるだけで他人のデータが見えてしまう「越権アクセス」（BOLA）を防ぐ

• 1回で取得できる件数、短時間の連続実行に上限を設ける

• APIキーは有効期間を短くし、漏えい時に失効させる手順を用意する

• APIごとにログを残し、大量取得や異常なパターンに気付けるようにする

対策4：認証情報は「漏れる」前提で守る

パスワードやトークンが漏れても、すぐ侵害につながらない層を作ります。

• 全社員、とくに管理者にMFA（多要素認証）を必須にする

• 管理者アカウントを、日常業務のアカウントと分ける

• 長期間有効なアクセストークン、APIキー、OAuth同意を減らし、定期的に棚卸しする

• 海外IP、未知の端末、普段と違う時間帯、権限昇格の場面では追加認証を求める

• 特権が必要な作業だけ、一時的に権限を付与する仕組み（PAM／JIT）を検討する

対策5：WAFやIPSを「IPの遮断」から「行動の検知」へ

低頻度かつ多数のIPから来る攻撃は、しきい値だけの運用をすり抜けます。

• 1つのIPだけでなく、「多数のIPから同じ資産に繰り返し来ている」状態を見る

• ボット判定、通信の暗号化の指紋（TLSフィンガープリント）、HTTPヘッダーの整合性、リクエスト順序の不自然さを組み合わせる

• 誤検知を避けつつ、機密性の高いAPIや管理画面には厳しいルールをかける

• 攻撃パターンを、CDN／WAFベンダーや脅威情報の共有網と連携させる

対策6：検知と初動対応を、できる範囲から自動化する

• SIEMやSOARで、「多数のIPから同一資産へ」「API大量取得」「管理者権限の異常な使用」「新規OAuth同意」を、まとめて検知できるようにする

• 外部からの攻撃の兆候があれば、該当資産を一時的に非公開にし、認証情報とトークンを無効にする

• 侵害が疑われるときは、再インストールだけで終わらせず、永続化の設定、OAuth同意、APIキー、サービスアカウント、メール転送ルールまで確認する

これらを全部、今すぐ自前で構築する必要はありませんが、「見つけて、止めて、取り除く」までの流れを、誰が何分で動かすのかはあらかじめ決めておくことです。

まとめ

ARTEXのようなAIは、攻撃を自動化し、速くし、安くします。
ただ、狙われているのは、これまでも指摘され続けてきた脆弱性、設定ミス、権限の持たせすぎです。
だからこそ防ぐ側も同じ速度に合わせる必要があります。
年に一度、人手で行う診断だけでは、AIが毎日回す探索に追いつけません。
資産の発見、脆弱性の確認、設定の検証を、継続的に、できれば道具の力も借りて回す体制へ。

「うちは小さいから大丈夫」ではなく、「小さくても、探されたら見つかる」前提に立てるかどうかが、これからの分かれ目だと思いますよ！