自律型AI攻撃エージェント「ARTEX」とは？防御ガイドの要点と当社の対策
ARTEX とは
ARTEX は、自律的に動く AI のペネトレーション（侵入）エージェントです。目標を立てる役、攻撃の計画を立てる役、実際にリクエストを送る複数の作業役といったエージェントが役割を分担し、偵察 → 列挙 → パラメータの探索 → 認証やインジェクションの試行、という多段の攻撃を人の手を介さずに最後まで進めることを目的に作られています。
元のプロジェクトは GitHub の Autumn-27/ARTEX（AGPL-3.0）ですが、2026年10月時点ではアクセスできなくなっています。その一方で、派生版の jiwoochris/artex-global に、守る側向けの防御ガイドが公開されています。
- 防御ガイド（英語）：docs/defense-en.md
- 検知ルール（Sigma / Suricata）や指標の一覧も、同じリポジトリの
detections/以下にあります
なにが厄介なのか
防御ガイドでは、脅威を「腕のいい攻撃者が1人いる」状態から「疲れも休みもしないエージェントの群れ」に変わったものとして捉えています。特に気をつけたいのは次の点です。
- 速くて止まらない：偵察から侵入までがひと続きで進むので、最初の接触から情報を持ち出されるまでの時間が短くなります。401 / 403 / 429 が返っても粘り続け、人が寝ている時間帯も動き続けます。
- 固定のシグネチャをすり抜ける：攻撃の文字列を LLM がその場の状況に合わせて作るため、リクエストの形が毎回変わります。決まった文字列に一致させるだけの WAF ルールは避けられやすくなります。
- IP で止めにくい：少数の送信元を入れ替えながら来るため、IP アドレスのブロックだけでは効果が限られます。
- User-Agent も当てにならない：情報収集では
artex-enrich/1.0、攻撃中の取得ではnorma/0.4という User-Agent が使われますが、ツールによって変わるので、「この UA が来ていないから安全」とは言えません。
ガイドがいちばん頼りになる手がかりとして挙げているのは、振る舞いです。同じ送信元から「存在しないページの列挙 → クエリの探索 → ログインや認証の試行」が短時間に続く、レスポンスの内容に合わせて少しずつリクエストを変えてくる、といったパターンは、見た目を変えても隠しにくいからです。
防御ガイドの要点
ガイドの対策は大きく3つに分かれています。
1. 検知と監視
- WAF / IPS で、単発のリクエストではなく一連の振る舞いに点数を付ける（1つのセッションで種類の違うリクエストが混ざる、レスポンスに合わせて連続で変化する、など）
- SIEM で、同じ送信元の「列挙・探索・認証」を短い時間の中で関連付けてアラートを出す（ガイドには 10 分間・送信元 IP ごとに相関させる Sigma のひな形があります）
- ログインや OTP・本人確認のエンドポイントで、失敗率の急な変化や、ゆっくり分散した試行を監視する
2. 守りを固める
- ログイン・認証・重要な API に、状況に応じたレート制限をかける
- 重要な操作には多要素認証（MFA）を必須にする
- すべてのオブジェクトへのアクセスで、所有者・権限をサーバー側で確認する（IDOR 対策）
- インターネットに出ている管理画面や補助的なシステムを棚卸しし、不要なものは VPN や許可リストの内側に移す
- 公表済みの脆弱性（n-day）は早めにパッチを当てる。優先順位付けには CISA の KEV カタログ が使えます
- 後から追跡できるよう、認証・アクセス・通信・DNS のログを十分な期間残す
- 非公式に出回っている IP ブロックリストをそのまま使わない
3. インシデント対応
- 怪しい送信元の隔離やセッションの無効化を、人の承認を待たずに自動で行えるようにしておく
- ログをどれだけ残すかを、事前に決めておく
自分のサーバーで ARTEX が動かされていないかを確認する手順も載っています。たとえば、既定の待ち受けポートである 8787 / 8788 を確認するには次のようにします。
ss -ltnp | grep -E ':8787|:8788'
ガイド自体も、どの指標も「見つからなかった＝安全」ではなく、見つかったものは手がかりの1つとして扱うよう注意しています。
当社の対策について
当社では、このガイドを参考にしながら、自社開発のエージェント型 WAF「JINRAI」と、当社が運用しているサーバーの両方で対策を進めています。
- JINRAI の検知の強化：今の JINRAI は、56 の検知ルールで SQL インジェクションや XSS などを1リクエストずつ判定しています。これに加えて、同じ送信元からの「列挙 → 探索 → 認証試行」の流れや、403 / 429 を受けても続くアクセスといった振る舞いを関連付けて判定し、遮断につなげる仕組みの対応を進めています。
- User-Agent に頼らない運用：
artex-enrich/1.0などの既知の User-Agent は要注意として扱いつつ、それが無いことを安全の根拠にはしない方針で、ルールとダッシュボードの見直しを進めています。 - 運用しているサーバーの見直し：ログインまわりのレート制限、管理画面の公開範囲、ログの保存期間などを、ガイドの項目に沿って順に確認しています。
AI が攻撃側の道具として使われるようになると、少人数で運用している小さなサービスほど、人の目だけで追いかけるのは難しくなります。進み具合はこのブログでもお知らせしていきます。WAF の導入やサーバーのセキュリティについてのご相談は、お問い合わせからお気軽にどうぞ。