はじめに
多くの人はこう考えがちです。
「致命的な脆弱性を1つ見つければ勝ち」
しかし、現実の攻撃はそんなに派手ではありません。
熟練した攻撃者は、
いきなり RCE や管理者権限を狙ったりしません。
彼らはまず 普通のユーザとしてアプリを使い、
小さな違和感・ズレ・甘さを集め、
それらを静かに、論理的に“一本の道”へと繋げていきます。
本記事では、
「ツールの使い方」ではなく
“攻撃者の頭の中で何が起きているか”
を、再現可能なプロセスとして解説します。
Step 1：まずは「普通のユーザ」になれ
最初にやるべきことは、ハックではありません。
- アカウント登録
- ログイン / ログアウト
- メニューを一通り触る
- 設定を変更する
- ファイルをアップロードする
一切の前提を捨てて、設計を理解する。
ここで見るべきポイントは：
- ユーザロール（未ログイン / 一般 / 管理者）
- 状態遷移（ログイン前 → 後）
- 「信頼されている前提」が置かれている場所
攻撃者は最初から“壊す”のではなく
「どこで信用されているか」を探します
特に注意すべき場所：
- アカウント設定
- プロフィール
- 管理者用・内部向け機能
- アップロード・エクスポート機能
Step 2：弱点を列挙せよ（評価は後）
次に、ようやく「攻撃者モード」に切り替えます。
探すものは：
- SQLi / XSS / IDOR などの定番
- エラーメッセージの違い
- 連番ID・予測可能なURL
- 「たぶん大丈夫」な実装
ここでのルールは1つだけ：
見つけたら全部メモ。
危険度は今は考えない。
- 低影響な XSS？
- 情報量が多いログインエラー？
- 拡張子チェックが甘いアップロード？
👉 全部、未来の材料です。
Step 3：この脆弱性「単体」で何ができるか？
各脆弱性について、必ずこの質問をします。
「これ“だけ”が壊れていたら、何ができる？」
例：
- XSS
→ どの画面？誰の権限で実行？Cookieは？ - ログインエラー
→ ユーザ名の列挙が可能？ - IDOR
→ 他人のデータ？管理データ？ - ファイルアップロード
→ 保存場所は？実行される？
妄想は禁止。実行可能な能力だけを見る。
Step 4：攻撃者の「目的」を決める
攻撃者はこう言いません。
「このアプリをハックしたい」
彼らはこう言います：
- 管理者になりたい
- 個人情報を盗みたい
- コードを実行したい
- 永続的なアクセスが欲しい
文脈がすべてです。
同じ XSS でも：
- 個人ブログ → 低リスク
- 金融ダッシュボード → 致命的
目的が定まらないと、
脆弱性は「点」のまま終わります。
Step 5：脆弱性を“道”に変える
ここが核心です。
考えるのは：
「外部の匿名ユーザが、どうやって目的に到達するか？」
例（現実でよくあるパターン）：
詳細なログインエラー
→ 有効ユーザ名の列挙
→ 弱いパスワードポリシー
→ ログイン成功
→ プロフィールに保存型XSS
→ 管理者が閲覧
→ XSS発火
→ 管理者セッション奪取
→ 権限昇格
1つ1つは「中・低リスク」。
繋がると、完全侵害。
これが実戦です。
Step 6：仮定せず、必ず検証する
映画のようには進みません。
- ブルートフォースは制限される？
- XSS は管理者でも実行される？
- Cookie は再利用できる？
- CSRF に止められない？
攻撃者は何度も失敗します。
ただし、毎回学習します。
止められたら：
- 別ルートを考える
- 条件を変える
- 権限・タイミングを変える
Step 7：レポートは「物語」で書け
よくあるダメな報告：
- XSS（Medium）
- IDOR（Low）
それでは伝わりません。
こう書きます：
「未認証の攻撃者が、複数の弱点を連鎖させることで
管理者権限を取得し、システム全体を掌握可能」
- 初期侵入
- 各ステップの遷移
- 最終的な影響
そして必ず明記する：
単体では軽微でも、連鎖すると致命的である
まとめ：覚えるべき攻撃者の思考
- スキャナは脆弱性を見つける
- 攻撃者は道を作る
- CVE は点
- 攻撃は線
- ツールは補助
- 思考が武器