BruteForceAI レビュー: LLM でログインフォームのセレクタを推定するブルートフォースツール

ログインフォームのセレクタ特定という地味な工程を LLM に投げる

ブルートフォースそのものは昔からある手法で、Hydra や Burp Suite の Intruder のような道具がすでに存在する。実際に時間を食うのは攻撃のループではなく、その前段の準備である。対象ページの HTML を読み、ユーザー名フィールドとパスワードフィールドの name 属性や id、送信ボタンのセレクタ、失敗時に表示されるメッセージを特定し、ツールが解釈できる形に落とし込む。フォームの構造はサイトごとに違い、JavaScript で DOM を組み立てるページでは静的な解析が通らないことも多い。BruteForceAI はこの工程を LLM に任せる。README は Stage 1 を AI Analysis、Stage 2 を Smart Attack と呼び、前者で LLM が HTML を解析してログインフォームの要素とセレクタを特定し、後者でその結果を使って攻撃を実行すると説明している。対象読者は、多数のログイン画面を抱える案件を扱うペネトレーションテスト担当者やバグバウンティ参加者である。

analyze と attack が分かれている理由と、SQLite に残る実行履歴

コマンドは analyze、attack、clean-db、check-updates の 4 つで、analyze と attack が別プロセスとして分離されている。README の例では、まず analyze で対象 URL を並べたファイルを渡し、次に attack でユーザー名リストとパスワードリストを渡す。解析結果が永続化されるため、同じフォームに対して試行条件だけを変えて再実行できる。攻撃側のモードは 2 つあり、bruteforce はユーザー名とパスワードの全組み合わせを試し、passwordspray は 1 つのパスワードを全ユーザー名に対して順に試す。README の説明では、同一ユーザーに対する試行の間に同期された遅延が入る。実行結果は SQLite に記録され、既存の試行をスキップする重複防止と、--force 系の再試行が用意されている。成功判定は DOM の変化を検出する方式で、HTTP ステータスコードの比較ではない。この設計は JavaScript 主体のログイン画面では有利に働くが、成功時に DOM が変わらない画面では判定根拠が弱くなる。

Ollama と Groq のどちらを選ぶかで変わるもの

LLM の接続先は 2 系統ある。ローカルの Ollama と、クラウドの Groq である。Ollama は API キーが不要で、フォームの HTML が外部に送信されない。README が挙げる既定モデルは llama3.2:3b で、速度重視なら llama3.2:1b、別候補として qwen2.5:3b が示されている。Groq は API キーが必要で、既定は llama-3.3-70b-versatile、代替が llama3-70b-8192、軽量版が gemma2-9b-it とされている。ここで README 自身が興味深い注記を付けている。llama-3.1-8b-instant はレート制限の問題から非推奨とされ、試行回数が 3 回以上に増えると説明されている。他の Groq モデルにはいずれも 1 attempt と付記されており、つまり解析が一発で通るかどうかがモデル選択の実質的な差になっている。解析に失敗した場合、README はフィードバックを伴う自動リトライと、HTML 抽出の調整によって再試行すると述べている。ローカル推論を選ぶかクラウドを選ぶかは、精度の話であると同時に対象 HTML をどこまで外部に出せるかという規程の話でもある。

セットアップで実際に打つコマンド

Python 3.8 以上が必要で、README は venv による分離を勧めている。python -m venv .venv で作成し、Windows の PowerShell なら .venv\Scripts\Activate.ps1、cmd なら .venv\Scripts\activate.bat、macOS と Linux なら source .venv/bin/activate で有効化する。依存は pip install -r requirements.txt のあと、playwright install chromium を実行する。requirements.txt に含まれる主要なパッケージとして playwright、requests、PyYAML が挙げられている。Ollama を使う場合は curl -fsSL https://ollama.ai/install.sh | sh で導入し、ollama pull llama3.2:3b でモデルを取得する。実行は 2 段階で、python BruteForceAI.py analyze --urls targets.txt --llm-provider ollama --llm-model llama3.2:3b のあとに python BruteForceAI.py attack --urls targets.txt --usernames users.txt --passwords passwords.txt --threads 20 --delay 5 --jitter 2 となる。attack 側の主なオプションは --mode passwordspray、--success-exit、--user-agents、--verbose、--output で、--discord-webhook のような通知先指定も用意されている。

通知と自動更新という運用寄りの機能に潜む確認事項

成功時の通知は Discord、Slack、Teams、Telegram の webhook に対応すると README は述べている。長時間走らせる攻撃では、成功の瞬間を捕まえるために通知が要るという判断だろう。もう 1 つ、check-updates コマンドがあり、機能一覧には mordavid.com からの自動更新チェックと書かれている。攻撃系ツールが外部ホストへ定期的に問い合わせる挙動は、閉域網や検査対象の環境によってはそれ自体が問題になる。エアギャップ環境や、外向き通信を監視している案件では、この機能の存在を先に把握しておく必要がある。README には更新チェックの通信内容や無効化方法の説明が見当たらない。同様に、通知 webhook に何が送られるか、認証情報そのものが送信に含まれるのかについても記載がない。成功した資格情報を外部サービスに送る設計だとすれば、取り扱いには注意が要るが、この点は資料からは確認できない。

ライセンス表記が NOASSERTION のままだという事実

リポジトリのライセンス識別子は NOASSERTION で、GitHub が既知のライセンスとして認識できていない状態である。一方 README のバッジには Non-Commercial と表示されている。バッジは README の装飾にすぎず、法的な条件を定める文書ではない。商用利用の可否、再配布の条件、改変物の扱いといった実務上必要な情報は、この資料からは判断できない。NOASSERTION は「ライセンスが存在しない」という意味でも「独自ライセンスである」という意味でもなく、単に自動判定できなかったことを示す。組織で使う場合は、リポジトリ内の LICENSE ファイルの実物を読んで法務に確認する以外に方法がない。なお、ブルートフォースツールの利用そのものは、対象システムへの事前の書面による許可があるかどうかで適法性が決まる。ツールのライセンス条件と、攻撃行為の適法性は別の話である。

Hydra や Burp Intruder との設計差

比較対象として最も分かりやすいのは THC Hydra である。Hydra はプロトコル単位でモジュール化されており、HTTP のフォーム認証に対しては、フォームのパラメータ名、失敗時に現れる文字列、成功時に現れる文字列を利用者が指定する。つまりセレクタの特定は人間の仕事として残る。代わりに、対象の構造が決まっていれば動作は決定的で、再現性があり、外部サービスへの依存もない。BruteForceAI はこの人間側の工程を LLM に移した点が違う。代償として、解析結果がモデルとその時点の推論に依存する。同じ HTML を同じモデルに渡しても、常に同一のセレクタが返る保証は README からは読み取れない。フォームの構造が頻繁に変わる案件や、対象数の多い探索では LLM 側の利点が出る。逆に、対象が数件で構造が固定されているなら、Hydra の設定ファイルを書くほうが速く、外部依存も増えない。

向く現場と向かない現場、導入前に確かめる 3 点

向くのは、管理権限を持つ検証環境や、参加規約で自動スキャンが明示的に許可されているバグバウンティ案件で、ログイン画面の数が多くセレクタ特定に工数を取られているチームである。Ollama をローカルで動かせば、対象 HTML を外部に出すことなく解析を回せる。向かないのは、まず認可のない対象への実行を考えている場合で、これはツールの性能以前の話である。次に、対象 HTML の外部送信が一切許されず、かつローカル推論に割けるマシンリソースもない現場。そして、成功判定を HTTP レスポンスの厳密な比較に依存させたい現場である。このツールの成功判定は DOM 変化の検出であり、判定根拠の性質が異なる。導入前に確認するのは 3 点に絞られる。リポジトリ直下の LICENSE ファイルの実物、check-updates と通知 webhook が発生させる外向き通信の宛先と内容、そして analyze が送信する HTML の範囲である。この 3 点が自組織の規程で説明できなければ、threads の値をいくつにするかの議論には進めない。

編集部の結論

自社が管理権限を持つ検証環境で、フォームのセレクタ特定に時間を取られているチームに向く。認可のない外部サイトへの実行は当然ながら対象外であり、そもそも LLM に HTML を渡す挙動そのものが許可されない現場では使えない。導入前に確認すべきは 3 点で、リポジトリの License が NOASSERTION のままであること、README 記載の自動更新チェックが mordavid.com への外部通信を含むこと、そして analyze 段階でフォームの HTML が選択した LLM プロバイダに送信されることである。この 3 点が自組織の規程で説明できなければ、threads や delay の調整以前の問題として採用は見送るべきだ。

公式情報源

1. Issues
2. MorDavid/BruteForceAI on GitHub
3. Project website
4. README