Hello there, ('ω')ノ
バイブル本の第三弾が出版されました。
Best regards, (^^ゞ
AIの死角を撃ち抜く——OSINTと手動診断で見つける「ビジネスロジックの脆弱性」
Hello there, ('ω')ノ
今回は、AIがスルーしてしまう脆弱性を、OSINT（公開情報調査）と手動診断を組み合わせてどう炙り出すか。その実践的なアプローチについて考えてみたいと思います。
1. OSINTで「AIの守備範囲外」を特定する
一般的なAIスキャナーは、あらかじめ指定されたスコープ（URLやIP）の中でしか動きません。しかし、本当の脆弱性は「管理者が忘れている、あるいは公開されているとは思っていない場所」に潜んでいることが多いです。
- GitHubでの「AI生成コード」の露出:
最近では開発者がAIを使ってコードを書くことが増えていますが、その過程で誤ってAPIキーや内部用URLがコミットされてしまうケースが散見されます。
shhgitなどのツールを使ってこれらを特定するのは、AIスキャナーにはできない「外側からの調査」です。 - 「隠れサブドメイン」の探索:
メインサイトはAIで厳重に守られていても、
dev-test.example.comのような開発用環境が無防備なまま放置されていることがあります。subfinderなどのOSINTツールを駆使して、AIの検知ログに残らない形でターゲットを絞り込みます。
2. 「ビジネスロジック」の矛盾を突く
AIが最も苦手とするのが「この操作は、このユーザーに許可されるべきか？」という論理的な判断です。
例えば、IDOR（認可制御の不備）。
AIは GET /api/user/100 が正常にレスポンスを返せば、それを「正しい挙動」としてパスしてしまいます。
ここで手動診断の出番です。 「ユーザーAのセッションを使って、ユーザーBのID（101）を指定したらどうなるか？」 「決済フローの途中で、パラメータの金額を書き換えたらどうなるか？」
こうした「システムの仕様（ビジネスロジック）を逆手に取った攻撃」は、依然として人間のホワイトハッカーの独壇場と言えます。
3. 脆弱性を「チェイン（連鎖）」させる思考
AIは単体のバグを指摘するのは得意ですが、複数の小さな不備を組み合わせて「致命的な攻撃」に昇華させるのは苦手です。
- OSINT で開発者の技術スタック（使用ライブラリ等）を特定する。
- 手動診断 で、AIが「低リスク」と見なしたエラーメッセージの露出を確認する。
- それらを組み合わせて、サーバーの内部構造を推測し、管理者権限の奪取へと繋げる。
この「点と点を繋いで線にする」プロセスこそが、2026年以降のホワイトハッカーに求められる最も重要なスキルだと感じています。
まとめ：AI時代だからこそ「人間」の視点を
ツールが自動化されればされるほど、その自動化の網をすり抜ける「例外的な手法」の価値が上がります。
AIを「高速な下調べツール」として使いこなしつつ、最終的な突破口は自分の手で見つける。そんなハイブリッドなスタイルが、これからのスタンダードになるのではないでしょうか。
Best regards, (^^ゞ
【考察】AI脆弱性スキャナーに「できない」こと——仕様から読み解くホワイトハッカーの生存戦略
Hello there, ('ω')ノ
2026年、セキュリティ業界は「AIによる自動化」の波に飲み込まれています。 「もう手動の脆弱性診断なんて不要になる」という極端な意見も目にしますが、本当にそうでしょうか？
今回は、話題のAI搭載スキャナー3種の最新仕様とアーキテクチャを徹底調査。ホワイトハッカーの視点で、AIが「得意なこと」と、どうしても「手出しできない領域」を整理してみました。
1. 調査対象としたAIスキャナーの現在地
現在、主流となっている3つのAIアプローチをピックアップしました。
- Snyk (DeepCode AI): 静的解析（SAST）に特化。数兆行のコードを学習したモデル。
- Burp Suite (AI-Augmented Scanner): 業界標準のDASTにLLMを統合。
- Escape (AI-Native DAST): APIの構造をAIが自律的に学習し、ビジネスロジックを突く新興ツール。
2. AIスキャナーが「圧倒的」に進化したポイント
各社のホワイトペーパーや技術ブログを読み込むと、これまでのスキャナーとは次元が違うことがわかります。
- 「意味」を理解したクローリング: これまでのスキャナーはボタンを闇雲にクリックしていましたが、最新のAIは「この入力欄は検索用」「ここは決済用」と文脈を理解して動きます。
- 難読化の突破: JavaScriptで難読化されたパラメータも、AIがその生成ロジックを推論して、適切にペイロードを流し込めるようになっています。
- 低ノイズ: 「コードのこの部分は実際には実行されない」といった判定の精度が上がり、開発者を悩ませた「大量の誤検知」が劇的に減っています。
3. 【本題】AIには見えない「3つの壁」
仕様を深掘りしていくと、人間のホワイトハッカーにしか見えない領域が明確になってきました。
① ビジネスロジックの「意図」の解釈
AIは「コードが正しいか」は判断できても、「サービスとしてその挙動が許されるか」は判断できません。
- 例: 「一般ユーザーが、URLのIDを書き換えるだけで他人の注文履歴を見られてしまう（IDOR）」といった不備。コード自体にエラーはないため、AIはこれを「正常な機能」とみなす傾向があります。
② 複雑な「脆弱性の連鎖（Chain）」
AIは「点（個別のバグ）」を見つけるのは得意ですが、複数の要素を組み合わせて「致命的な一撃」を作るのが苦手です。
- 例: 「権限のないファイルアップロード」と「サーバー側のパス解釈の癖」を組み合わせてRCE（リモートコード実行）に繋げるような、ストーリー性のある攻撃シナリオの構築です。
③ 「未知の未知」への対応
AIの学習データはあくまで「過去の攻撃パターン」です。 発表されたばかりの独創的なゼロデイ攻撃や、その組織固有の特殊な認証フローに対しては、依然として人間の直感と経験が必要とされます。
4. 考察まとめ：AI時代の生存戦略
調査を通じて感じたのは、「AIはホワイトハッカーの代替ではなく、最強のコ・パイロット（副操縦士）になる」ということです。
| フェーズ | AIの役割 | ホワイトハッカーの役割 |
|---|---|---|
| 初期調査 | 網羅的なスキャン、単純バグの排除 | スキャン結果の精査、攻撃面の特定 |
| 深掘り | PoCの雛形作成、コード解説 | ロジックの矛盾を突く攻撃の組み立て |
| 最終報告 | 修正案の提示、レポートの下書き | ビジネスリスクの評価、対策の優先順位付け |
これからのホワイトハッカーに求められるのは、ツールを回す技術ではなく、「AIが『問題なし』と判断した場所から、いかに矛盾を見つけ出すか」という、よりクリエイティブな視点ではないでしょうか。
Best regards, (^^ゞ
バイブル本出版開始
Hello there, ('ω')ノ
ようやく、PortSwigger社のWeb Security Academyをわかりやすく解説したバイブル本を出版しました。
随時、他の脆弱性についても出版予定です。
また、LABについての解説と動画も準備中です。
ちなみにPortSwigger社からは、許可を得ています。
Best regards, (^^ゞ
