不正アクセスから自社サイトを守るのに、攻撃側のStrixを使えるか？

2026年9月、オープンソースのAIツールを3つ組み合わせただけで、少なくとも27社が侵入され、うち2社からはカード情報が60万件以上持ち出されたと報告されました。使われた道具は、どれも無料で、誰でも手に入ります。

今日は、ECやWebサービスを運営する側の人に向けた話です。攻撃に使われたのと同じ道具、なかでも穴を探す偵察役の「Strix」を、自分が持っているサイトに先に向けて、穴がないか確かめられるのか。やる前に引いておく線まで、見張り番として整理します。

少ない指示で27社に入った道具は、3つだけだった

報告を公開したのはGambit Securityで、日付は2026年9月22日です。日本で報じられ始めたのは10月初旬でした。報告によると、9月10日から15日のあいだに105件の攻撃プロジェクトが走り、アクセスに成功したケースは、多くが1日とかからず、数時間で中に入られたものも少なくありません。

使われたのは、名前の付いた3つの道具だけでした。

費用もかかっています。報告では1社あたり平均で約25ドル、幅は3.13ドルから79.31ドルで、全体でも1.2万ドルから1.8万ドルほどとされています。「数行で」という言葉がひとり歩きしましたが、実際には少ない指示で道具が自走した、と読むのが正確です。本当に効いているのは費用の安さより、攻撃を仕掛けるまでの時間がここまで短くなったこと。あなたのサイトも、この値段で試される側に入っているかもしれません。

AI Agents Are Hacking Online Retailers for $25 a Company

Gambit Threat Intelligence reconstructed an ongoing campaign in which open source AI agents compromised online retailers for about $25 each.

gambit.security

Strixとは何か。偵察役が無料で配られている理由

Strixは、Webアプリやソースコードに向けて、どこに穴があるかを自分で探して報告するAIツールです。見つけた穴は、実際に成立するかを検証したうえで、証拠つきのレポートにまとめてくれます。ライセンスはApache 2.0で、GitHubの星は6万を超えています。動かすにはDockerと、OpenAIやAnthropicなどのLLMのAPIキーが要ります。

攻撃者がこれを使えたのは、偵察を自動で回せるからです。そして守る側が使える理由も、まったく同じです。向ける先を相手のサイトではなく自分のサイトにするだけで、道具のふるまいは変わりません。

手元でも入れてみました。pip install strix-agent の1コマンドで、バージョン1.7.0が入ります。Python以外のビルド作業はいりませんでした。strix --help を見ると、URL・ソースコードのディレクトリ・ドメイン・APIの仕様書まで、診断の対象として指定できることが分かります。

ただ、万能ではありません。AIが「穴かもしれない」と拾う以上、誤検知は混じります。専門の診断会社がやる手作業の検査まで代わりになるわけではありません。あくまで最初のふるい、と考えておくのが安全です。

GitHub - usestrix/strix: Open-source AI penetration testing tool to find and fix your app’s vulnerabilities.

Open-source AI penetration testing tool to find and fix your app’s vulnerabilities. - usestrix/strix

github.com

Cairnは、守る側が触るべき道具なのか？

Cairnは、見つけた穴から実際に中へ入り、シェルや管理者の権限を取るところまでを自分で進めるAIツールです。事件では侵入の役を担いました。星は約3,400、検証されている主な用途はペネトレーションテストです。

守る側がこれに手を出すべきかというと、まずは要りません。理由は2つあります。

1. ライセンスの壁がある。CairnはAGPLv3で、個人や教育の用途はそれでよいのですが、業務で使うなら別に商用ライセンスの確認が必要です。会社のサイトを診断するつもりなら、ここは最初に引っかかります。
2. 役割が重い。穴を見つけるところまではStrixで足ります。そこから先、実際に侵入まで試すのは、隔離した環境と明確な許可がそろって初めて考える段階です。

まずはStrixで穴を洗い出す。Cairnはその名前と役割を知っておけば、今は十分です。

GitHub - oritera/Cairn: A AI general-purpose state-space search engine, validated first on autonomous penetration testing.

A AI general-purpose state-space search engine, validated first on autonomous penetration testing. - oritera/Cairn

github.com

Hermesは司令塔。守る側が学ぶのは使い方ではなく速さ

Hermesは、StrixとCairnを束ねて動かした司令塔です。これもオープンソースの自律型エージェントで、攻撃者はそこに攻撃用のスキルや短い指示を載せ、全体の進行を任せていました。自分でゼロから攻撃ツールを作ったわけではなく、配られている部品を組み合わせて司令塔に仕立てた、というのがこの事件の怖いところです。

守る側がHermesの中身を学ぶ必要はありません。見ておくべきは、速さのほうです。報告では、入られたサイトの多くは1日かからず、数時間で中まで届かれたケースも目立ちました。一方で、見つかった穴をふさぐ側の作業は、原因の特定から修正、確認まで数週間かかることも珍しくありません。

攻撃は数時間、修正は数週間。この差を埋める唯一のやり方は、相手より先に自分で穴を見つけておくことです。だからこそ、偵察役のStrixを自分の側に置く意味があります。

自分のサイトに向ける前に決めておく3つ

道具を動かす前に、決めておくことが3つあります。

1. 対象が誰のものか。Strixは公式に「自分が所有する、または明示的な書面の許可がある対象にのみ実行する」としています。レンタルサーバーやクラウド、SaaSの上に乗っているなら、事業者の規約も確認が要ります。クラウド事業者によっては、診断の実施に事前の許可や申請を求める場合があります。あなたのサイトは、どこまでが自分の持ち物ですか。
2. どこで動かすか。本番ではなく、まずステージング環境に向けます。本番を誰も見ていない時間に走らせるのは避けてください。診断の動きそのものが、サービスに負荷をかけることがあります。
3. いくらまでか。LLMのAPIは使った分だけ課金されます。--max-budget で上限を決めておけば、そこに達した時点で安全に止まります。

最後に、法律の話をひとつ。日本では、許可のない相手のシステムに向けて診断を走らせると、不正アクセス禁止法に触れ得ます。これは法律の助言ではありませんが、「自分のもの、または書面の許可がある相手にだけ」という線は、技術より先に守る前提です。

Strixを最初の1回だけ動かす最小の流れ

攻撃の手順はここには書きません。書くのは、自分のサイトを自分で診断する流れだけです。

準備は2つ、DockerとLLMのAPIキーです。Dockerは必須でした。手元では、pip install strix-agent の1コマンドで入れたあと、APIキーを設定しないまま試しに動かしてみました。すると、その手前で止まります。Dockerが無い環境では、起動した直後に DOCKER NOT INSTALLED と出ました。Strixは診断そのものを自前のサンドボックスの中で走らせる作りなので、APIキーより先にDockerの壁があります。

対象の指定は、公式のREADMEにある基本の形で足ります。ソースコードを見てほしいなら strix --target ./自社リポジトリ、動いているステージングを見てほしいなら strix --target https://自社のステージングURL です。最初の1回は、-m quick で軽く回し、--max-budget で費用の上限を決めておくと安心です。結果は strix_runs/ の中にまとまります。

ここまでで、動かさない人にも分かることがあります。この道具は無料で手に入り、PythonとDocker、それにLLMのAPIキーがあれば、自分のサイトに向けられる。攻撃者が使えた偵察を、持ち主が先に回せる。やるかどうかは別として、その選択肢が今は自分の側にもある、ということです。

出てきた結果を、事件の連鎖から逆算して並べ替える

レポートが返ってきたら、指摘を上から順に直すより先に、事件で起きた連鎖の入口を思い出します。報告された侵入例のひとつは、認証前の画面にあった穴から入り、多要素認証をすり抜け、管理者の権限を取り、ファイルをアップロードできる場所から奥へ進み、そこからシークレットの保管先やデータベースにまで届く、という流れでした。

だから、見る順番も入口からです。ログインする前の画面で、外に出している機能はどれか。あなたのサイトは、認証前にどこまでの操作を許していますか。そこにStrixが穴を見つけているなら、どの指摘より先にふさぐ対象です。

事件では、入られたあとに決済ページのスクリプトが書き換えられ、カード情報を抜くコードを埋め込まれていました。決済まわりのJavaScriptやタグが昨日と同じか、気づける仕組みがあるか。バックアップが本番と同じ場所にあって一緒に消される作りになっていないか。このあたりは、Strixのレポートと合わせて見直す価値があります。

ただ、ここまでやっても、自前の診断は最初のふるいです。カード情報を扱う、規模が大きい、満たすべき基準が決まっている。こうした条件に当てはまるなら、専門の診断会社に頼む段階です。Strixで一度自分の穴を見ておくと、その相談の精度も上がります。事件の詳しい経緯はBleepingComputerの記事や、日本語では週刊アスキーが伝えています。

攻撃が数時間で終わる時代に、守る側に残された時間は、相手が来る前のあいだだけです。今夜、自分のステージングに一度だけ向けてみる。その1回が、連絡を受け取る側に回らないための、いちばん手前の一歩になります。