最初に

本記事はARTEXをローカル環境で動作するWebアプリに対して脆弱性解析を行った体験談を伝えることを目的としています

ARTEXの入手方法、設定方法などについての記述はありません
また、質問をいただいてもお答えすることはできませんのであらかじめご承知おきください

ARTEXとは

2026年10月19日現在、数多くの日本企業から情報漏洩のニュースが発表され、ニュースでも連日報道されている状態です
サイバー攻撃に利用されたのではないかと言われている「ARTEX」について、今回実際に動作させてみて、どのような挙動を取るのか確かめてみたいと思います

※1:日本企業への不正アクセス、中国のAIツール「ARTEX」使用を確認
https://news.yahoo.co.jp/articles/51bdb52f0b706e75a2aad02aea056bf9945d1d50

※2:ARTEXは現在公開が終了しており、入手することはできません

ARTEX動作画面

ローカル環境にARTEX動作環境を構築し、実際に動作させた画面が以下になります

表記が中国語となっており、言語設定などもないため日本人には扱いにくそうな感じです
ただAIにお願いすればどんな言語にも翻訳可能なので、言語の壁はないと思ったほうが良いでしょう

脆弱性診断の設定も簡単で
・どのサイトに対して行うか
・目標な何か
を指定すれば、後はLLMが自動で計画を立てて、ワーカーがそれぞれのタスクをこなしてくれます

ワーカーの動作が終了すると、サマリが表示されます
このワーカーの場合、
・どのような技術スタックで構成されているか
・各種セキュリティの設定状況(CSRF-Tokenなど)の適用状況
・侵入に利用できそうなAPIのエンドポイント
と言った情報がまとめて表示されました

驚いたのはこの時点で「/api/item/[id]にabcを設定してもレスポンス200が返却されたので、値が正しく検証されていない可能性がある」という結果が出ていたこと
通常IDといえば数値が設定されるべきなので、そのようなチェクが甘い部分がこの時点で割り出されていたのは衝撃的でした

脆弱性チェックにはそれなりに時間が掛かる

ローカルLLMを利用して脆弱性チェックを行ったところ、45分経っても、7個のうち2個のワーカーが終わっていました
ワーカーは進捗に応じて増えたりするため、サイト全体の脆弱性チェックにはかなりの時間がかかりそうです

ただし、これはあくまで「ローカルLLM」の環境で動かした場合なので
・ローカルに高スペックな環境が準備できる
・OpenAIやClaudeに課金できて、フロンティアAIを大量に利用できる環境がある
場合は、探索時間は相応に短くできる可能性があります

個人が面白半分でARTEXを動かしてサイバー攻撃を行うのはあまり現実的ではありませんが
組織としてサイバー攻撃を行うのであれば、十分に脅威となる可能性を秘めていることが、今回実際に動かして感じたことです

※1:個人が面白半分でARTEXで外部サイトに攻撃を仕掛けた場合でも「不正アクセス行為の禁止等に関する法律」に抵触する可能性があるため、絶対に行わないでください

ARTEXの攻撃を受けたサイト側のログ

以下はARTEXからのリクエストの一部です

{"time":"2026-10-21T13:02:45.509307088+09:00","level":"WARN","msg":"該当ライダーIDが存在しない : -1"}

{"time":"2026-10-21T13:02:45.510751918+09:00","level":"INFO","msg":"request","method":"GET","uri":"/rider/profile/-1","status":400}

{"time":"2026-10-21T13:02:45.593460711+09:00","level":"ERROR","msg":"クッキー取得でエラーが発生しました : http: named cookie not present"}

{"time":"2026-10-21T13:02:45.593574715+09:00","level":"INFO","msg":"request","method":"GET","uri":"/rider/profile/1","status":200}

{"time":"2026-10-21T13:02:45.668416624+09:00","level":"INFO","msg":"request","method":"GET","uri":"/rider/profile/test","status":400}

{"time":"2026-10-21T13:03:20.844216648+09:00","level":"INFO","msg":"request","method":"GET","uri":"/rider/profile/1'%20OR%20'1'='1","status":400}

{"time":"2026-10-21T13:03:20.891242984+09:00","level":"INFO","msg":"request","method":"GET","uri":"/rider/profile/1%20UNION%20SELECT%20NULL--+","status":400}

{"time":"2026-10-21T13:03:20.936057217+09:00","level":"INFO","msg":"request","method":"GET","uri":"/rider/profile/1'%20AND%201=CONVERT(int,(SELECT%20TOP%201%20table_name%20FROM%20information_schema.tables))--+","status":400}

ライダー情報を取得するためのAPI「rider/profile」エンドポイントに対して SQLインジェクション攻撃が行われていることが確認できます
ARTEXではSQLインジェクション攻撃を行うにしても、複数パターンを生成して攻撃している様子が見て取れます

いったんここまで

簡単にですが、ARTEXを動作させてみた内容を記載しました
特に驚いたのは
・セットアップが簡単である(シェルを起動し、簡単な質問に答えるだけ)
・脆弱性チェックが簡単に行える(日本語でこのサイトに対して脆弱性をチェックして　だけ)
・幅広いパターンを試す(SQLインジェクション一つとっても、様々な可能性を考慮して攻撃してくる)
という点です

ただ、今のところ「革新的な」攻撃方法は行われていないように見えるため、Webアプリケーション基本である
・権限や認証が正常に設定されているか
・SQLインジェクションなどの対策は行われているか
・WAFのような防御機構が設定されているか
と言った、従来のWebアプリケーションセキュリティをしっかり行うだけでも、効果があるのかなと感じています

上記のようなツールを使うことでウェブセキュリティの「戸締りが甘い部分」の調査が簡単になってしまった印象です
これを機に、Webアプリケーションのセキュリティを見直すのが良さそうです(自分含めて)