自律型AIハッカーという恐ろしいキャッチコピーを持つStrixを知っていますか?実際に手を動かして脆弱性を見つけ、証拠まで作ってくれるらしいです。
2015年にWPScanというWordPressの脆弱性をスキャンするツールを使って友人のWebサイトを攻撃しました。その時は私が手を動かしましたが、今回はAIがそれをやってくれるみたいです。残念ながら友人はWebサイトを閉鎖してしまったので、今回は自社システムで試します。
Strixとは?
AIエージェントが実際にアプリを動かしながら、SQLインジェクションやXSS、認可の不備(IDOR)といった脆弱性を能動的に探して、見つけたものを実際に攻撃して証拠を作ってくれるツールです。
プロのペネトレーションテスターが使うのと同じような一式のツール(HTTPインターセプトプロキシ、ブラウザ自動操作、ターミナル、Python実行環境など)をエージェントに持たせて、偵察から攻撃までを自律的にやらせる、というコンセプトのようです。

大事な前提
今回の対象は、実際にAWS上で稼働している自社システムです。自分たちが管理しているAWSアカウント内の資産なので、AWSの侵入テストポリシー上、事前承認なしにペネトレーションテストを行うことができます。
この記事は、Strixで見つかった課題をすべて修正した後に公開しています。ドメインや具体的なエンドポイント、認証情報などは一切載せず、環境がどれくらい古かったか、それがどう危険だったかという学びの部分だけを共有します。見つかった脆弱性の攻撃手順やPoCの中身もここには書きません。
構成
- 対象: 社内システム(AWS上で稼働中)
- 技術スタック: PHP、MySQL、自作のスクラッチMVCフレームワーク
- 実行環境: Docker(Strixのサンドボックス実行用)
- 使用ツール:
Strix - LLMプロバイダ: (使用したものをここに記載)
対象環境について
いわゆるLAMP環境です。
- PHP
- MySQL
- フレームワークは既製のものではなく、スクラッチのMVCフレームワーク(PHP)で、当然ながら昨今のフレームワークが標準で備えているような対策(CSRFトークンの自動付与など)が、作られた当時の水準のままになっていました
やったこと
1. Dockerが動く状態にする
Strixはサンドボックスの実行にDockerを使うので、まずDocker Desktop(またはDocker Engine)が入っているか確認します。
docker --version
docker ps2. Strixをインストールする
インストールスクリプトを叩くだけです。ゲストマシンではなく、ホストマシンで実行します。
curl -sSL https://strix.ai/install | bash

3. LLMプロバイダを設定する
環境変数でLLMプロバイダとAPIキーを渡します。
export STRIX_LLM="anthropic/claude-sonnet-5"
export LLM_API_KEY="your-api-key"4. 対象のシステムに向けて実行する
strix --target {対象ドメイン}初回はサンドボックス用のDockerイメージを自動で取得してくるとのことでした。
5. スキャンの様子を見る
エージェントが偵察(Recon)から始まって、実際に攻撃を試している様子がリアルタイムに表示されました。

6. 結果を確認する
strix_runs/以下に、見つかった脆弱性がレポートとして出力されます。

strix_runs/以下に、見つかった脆弱性がレポートとして出力されました。参考までに2つほどご紹介します。
1. ログインページでの反射型XSS(深刻度: High)
ログイン画面のリダイレクト先を保持する隠しフィールドに、URLパスの値がそのままエスケープなしで出力されてしまっていました。悪意のあるリンクを踏ませることで、ログインページ上で任意のスクリプトが動いてしまう状態で、認証情報を盗まれるリスクに直結する内容でした。原因は、値をHTMLに埋め込む際の出力エンコード漏れです。
2. デバッグ用ファイルの外部公開(深刻度: Medium)
開発時に使っていたと思われる、サーバー情報を表示するデバッグ用のPHPファイルが、認証なしで誰でもアクセスできる状態のまま公開Webルートに残っていました。これ単体で直接侵入されるものではないものの、内部構成やソフトウェアバージョンといった、攻撃者にとって「次の一手を考えるための情報」を無償で提供してしまっている状態でした。デバッグ用ファイルがステージングモードで公開されており、そこからSMTP情報などが外部に漏洩するケースも少なくありません。
7. 見つかった課題を修正する
攻撃手順の詳細やPoCについては、悪用防止のためこの記事では触れませんが、見つかったものは、優先度をつけてひとつずつ潰していきました。この記事は、それらの修正がすべて完了したことを確認したうえで公開しています。
所感
自分たちで手を動かしてリクエストを送るような泥臭い作業を、エージェントが代わりにやってくれるのは正直かなり楽でした。誤検知が少ないと言われているだけあります。
古いシステムほど「動いているから触りたくない」という気持ちが働きがちですが、今回のようにAIエージェントに客観的に洗い出してもらうことで、優先順位をつけて手をつけるきっかけになりました。CI/CDに組み込んでPRごとに簡易スキャンする、という使い方もできるらしいので、次はその辺りも試してみたいと思います。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK