ARTEXとは｜AI自律型ペネトレーションテストツールの悪用と、Shodanから消える偽装ゲート

ARTEXは、中国で公開されたオープンソースのAI自律型ペネトレーションテストツールです。LLMのエージェントが偵察から脆弱性の検証までを自動で回します。2026年9〜10月に韓国の金融機関への攻撃（CrowdStrike）と、日本企業約20社を狙った不正アクセスの攻撃元（GMOサイバーセキュリティ byイエラエ）で、ARTEXの使用が報告されました。本記事では、その二次フォーク enwjx/artex-ymh に入った「偽装ゲート」がShodanの指紋検索からどう姿を消すかを、コード（server/gate.go）を読んで確かめ、防御側が自社への攻撃に気づくための観測点を、攻撃手順を書かずに整理します。

本記事は連載「事故から逆算するWebセキュリティ」の関連記事です。セキュリティ全体の地図は「サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説」にまとめています。

ARTEXとは：報告された悪用の範囲

ARTEXは、LLMのエージェントに偵察・脆弱性探索・攻撃経路の計画・ツールの実行・検証を自動で回させる、オープンソースのペネトレーションテスト基盤です。単体の大規模言語モデルではなく、外部のLLM（報道ではDeepSeek・GLM・Grok・Claude Codeなどの併用）に接続して動きます。開発者（GitHubのハンドル Autumn-27）はREADMEで、個人の学習・コード研究・ローカルの技術検証に限り、稼働中のシステムへの実テストは禁止すると明記していました。

本来は防御側が自社の弱点を測るための道具ですが、攻撃に転用された事例が相次いで報告されています。

報告された時系列を整理すると、次のとおりです。

AIが自律的に攻撃したのか、人間が既存の手法を速く大量に回す道具として使ったのかは、見方が分かれます。CrowdStrikeの事例では攻撃者のセッション履歴が残っており、人が一手ずつ指示していた形跡が強い、という読み方もあります。どちらかに断定できる公表情報は、現時点ではありません。

偽装ゲートの仕組み：Shodanの指紋検索が効かなくなる理由

攻撃者が公開のインターネット上にARTEXの管理画面を立てると、そのホストは Shodan・FOFA のようなスキャナーに拾われます。素のARTEXは、クローラが GET / すると管理画面（Next.js、ポート8787）がそのまま応答し、画面のtitle「自主渗透测试控制台」、faviconのハッシュ、中国語のログイン文言が指紋になります。三輪信雄氏（@NobMiwa）は2026年10月20日の投稿で、二次フォーク enwjx/artex-ymh がこの指紋を消す「偽装ゲート」を加えた点を指摘しました。実際に該当コミット（1e0ebcc、2026-09-19）の server/gate.go を読んで、挙動を確かめました。

コードから読み取れた挙動は次のとおりです。ファイル冒頭のコメント自身が「隠蔽は認証ではない。入口URLが漏れれば無効で、止めるのは自動の指紋一致（fofa/shodan/quake）だけで、狙い撃ちの攻撃は止めない」と述べています。

結果として、偽装ゲートが有効な個体をShodanから見ると、姿は「どこにでもあるnginxの既定ページ」1枚だけになります。title・favicon・本文のどれで検索しても、ゲート有効の個体はヒットしません。これが「指紋検索が効かなくなる」正体です。

ただし、この隠蔽には穴があります。フォークのREADMEによれば、ゲートの有効化は任意で、非ループバックで待ち受けると既定で有効になる設計です。つまり未設定・ループバック想定のまま外に出た個体には、従来の指標がそのまま効きます。GMOイエラエの観測で見つかった多数の個体の多くも、この従来指標が効く側だと考えられます。

防御側はどこを見るか：指紋より挙動

偽装ゲートは「外からの指紋一致」を消すための層で、「自社に向かう攻撃の挙動」までは消せません。防御側にとって回避されにくい観測点は、指紋そのものよりも挙動の側にあります。

攻撃者が自社を狙えば、入口は公開アプリの解析から始まることが多く、その試行は自社のアクセスログに残ります。短時間に多数の異なるパスを引く総当たり、既知の侵入ツールの試行、Webシェルやトンネルの痕跡などです。レート制限や監査ログの設計は、この挙動を拾って止める土台になります。考え方は「APIレート制限の設計｜正しい認証のまま会員情報を大量に引かれるAPIを、鍵・重さ・業務の流れで止める」と「監査ログの設計｜事故のあとに「誰が・いつ・何を」答えるための記録項目・マスキング・ハッシュチェーンの改ざん検知」にまとめています。

自システムの確認コマンド

自社のアクセスログと公開資産を、読み取りだけで棚卸しする2つの例です。いずれも自社の資産に対してだけ使うもので、他者のホストを探したり接続したりするものではありません。掲載前に陽性・陰性の対照つきで実行し、拾うべきものを拾い、無いときは何も出さないことを確かめています。

まず、自社のアクセスログ（nginx/apacheの結合ログ形式）から、短時間に多数の異なるパスを引く接続元を数えます。列挙（総当たり）はAI型ツールに限らず自動化された偵察に共通する挙動です。

# 自社のアクセスログで、接続元IPごとの「異なるパスの数」を数え、多い順に出す
# 150など自社の通常値より大きいしきい値に合わせる（.gz もまとめて読むなら zcat -f で渡す）
awk '{ip=$1; path=$7; if(!(ip" "path in seen)){seen[ip" "path]=1; c[ip]++}}
     END{for(i in c) if(c[i]>=100) print c[i]" distinct-paths  "i}' \
    /var/log/nginx/access.log | sort -rn | head

次に、自社が公開しているホスト（自分で管理するものだけを並べたファイル）のうち、「Welcome to nginx!」の既定ページを返しているものを洗い出します。これは攻撃基盤の検出ではなく、自社の置き忘れの既定ページの棚卸しです。素のnginx既定ページを外に晒したままの資産は、設定もれの目印になります。

# 自分で管理するホストを並べた my-assets.txt（1行1ホスト）に対してだけ実行する
while read -r host; do
  body=$(curl -s -m 5 "http://$host/")
  case "$body" in
    *"Welcome to nginx!"*) echo "DEFAULT-PAGE: $host" ;;
  esac
done < my-assets.txt

緊急の脆弱性を抱えたまま入口を守る必要があるなら、WAFの仮想パッチで時間を稼ぐ手も併せて検討します。考え方は「仮想パッチとは｜修正版を当てるまでの数日をWAFで稼ぐ手順と、IDORやカーネルなどWAFでは守れない脆弱性」にまとめています。

なお、侵害の調査で使う git fetch --all --prune のような「上流の修正を取り込む」操作は、今回の題材（攻撃元の隠蔽と自社ログの観測）には当てはまらないので置いていません。

ARTEXの影響範囲と、断定しないこと

GMOイエラエの観測では、標的はほぼ日本に限られ、国と業種を絞ってキャンペーンごとに別のホストが使われていました。標的とされた企業名は公表されていません。当サイトが今月扱った国内の事案記事との関係も、公表されていないため結びつけません。

偽装ゲートについても、過大評価は禁物です。有効化は任意で、未設定の個体には従来の指標が効きます。実装コメント自身が、ゲートは指紋一致を止めるだけで狙い撃ちは止めないと述べています。上流がクローズドソース化しても、すでに配布されたコピーやフォークは残ります（実際に二次フォークが公開されています）。

参照ソース

・enwjx/artex-ymh（二次フォーク・公式リポジトリ） — server/gate.go・README-FORK.md・LICENSE（AGPL-3.0）をcommit 1e0ebccで確認（2026-10-20時点、★417・forks 443）
・CrowdStrike: Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance — 韓国の金融機関への攻撃とARTEX・LLMの併用、攻撃者評価（2026-10-07）
・GMOサイバーセキュリティ byイエラエ: 相次ぐ不正アクセスの攻撃元の多くがAIであることを確認 — 日本企業約20社・同業種9社・他6台のAI攻撃インフラ（2026-10-19）