はじめに
現代のフィッシング攻撃はもう “下手な偽ログインページ” ではありません。
最先端は Reverse Proxy（中継型）フィッシング、つまり 正規サイトをリアルタイム中継しながら MFA すら突破する攻撃です。
「え、そんなの本当にできるの？」
——できます。しかも仕組みはシンプル。
この記事では、その技術的背景から実際の攻撃フロー、そして根本的な対策まで一気に解説します。
Reverse Proxy 攻撃とは？
攻撃者がユーザーと正規サイトの間に “透明な仲介者” として入り込み、
認証情報・TOTP・MFA 後の Session Cookie などをすべて盗む攻撃。
従来のフィッシングが “偽ページでパスワードを盗む” だけだったのに対し、
Reverse Proxy 攻撃は ログイン → TOTP → セッション確立の全工程をリアルタイムで中継します。
代表ツール
- Evilginx2
- Modlishka
- Muraena
- Necrobrowser
どうして攻撃が成立するのか？
技術的に言えば、Reverse Proxy はこんなことをします：
-
被害者は攻撃者のドメインにアクセス
正規ドメインに “似せたドメイン” を使う（例：g00gle-secure-login.com）。 -
攻撃者の Reverse Proxy が本物サイトへ接続
HTML、JS、画像、API すべて中継。 -
ユーザーは「本物のログイン画面」にログインした気になる
実際には攻撃者のサーバに ID/PW が送られる。 -
攻撃者はそのまま本物へログイン
TOTP が求められれば、それも被害者に表示し中継する。 -
サーバが発行する Set-Cookie（session token）を攻撃者が横取り
→ これが決定的。
→ MFA を通過した後の “認証済みセッション” が盗まれる。 - 攻撃者はその Cookie をブラウザに貼り付けてログイン成功
→ MFA 突破完了
図解：攻撃フロー（Evilginx2 の典型パターン）
[被害者ブラウザ]
│
▼ ①攻撃者ドメインへアクセス
https://login-google-phish.com
│
▼
[攻撃者 Reverse Proxy]
│ ②本物Googleに中継
▼
https://accounts.google.com
ログイン工程：
- Victim → ID/PW → Attacker → Google
- Google → TOTP要求 → Attacker → Victim
- Victim → TOTP入力 → Attacker → Google
- Google → Set-Cookie → Attacker（盗む）
- Attacker → Session Cookie を使用してログイン成功
→ MFA 付きアカウントでも秒で乗っ取り可能
なぜ HTTPS でも防げないのか？
ここが多くの初心者が誤解する点。
HTTPS は「サーバとクライアント間の暗号化」
通信が暗号化されていても 中継者自身が “サーバ” として振る舞う ため、
攻撃者のサーバとの通信は正規の HTTPS になってしまいます。
つまり：
- 攻撃者は Let’s Encrypt で SSL 証明書を普通に取得できる
- ブラウザには鍵マーク 🔒 がちゃんと出る
- TLS は“攻撃者 ↔ 被害者” と “攻撃者 ↔ 本物サイト” で別々に成立
ユーザー視点：
「鍵マーク付いてるし大丈夫だな」
攻撃者視点：
「うん、ありがとう Chrome」
Cookie が盗まれるとなぜ危険？
Reverse Proxy が奪うのは、単なる ID/PW ではありません。
奪うのは：
MFA 通過後の “認証済み Session Cookie”
これは最強。
なぜなら、
Google / Microsoft / Facebook すべて Cookie ベースのセッション管理で動いているため、
Session Cookie を使えば、そのまま被害者になりすますことができます。
Reverse Proxy 攻撃で MFA が突破される理由
MFA は確かに強いが、「受け取って入力するだけ」の方式は中継に弱い。
| MFA方式 | 中継される？ | 理由 |
|---|---|---|
| SMSコード | ✔ | ただの数字。中継可。 |
| TOTP | ✔ | 6桁コード。中継可。 |
| プッシュ通知 | ✔ | 「Yes」を押すだけ。中継可。 |
| U2F / WebAuthn / Passkey | ❌ | オリジンバインディングがあるため偽ドメインでは動かない。 |
つまり：
現代のフィッシングに勝てるのは WebAuthn（Passkey）だけ。
技術的コア：Reverse Proxy がやっていること
① TLS Termination
攻撃者が HTTPS の終端を担う。
② Header Rewriting
Host や Origin を動的に書き換える。
③ Cookie の双方向転送
攻撃者が自由に Cookie を読み書きできる。
④ URL Rewriting
サブリソース（画像・JS）を攻撃者ドメインに合わせて書き換える。
⑤ リアルタイム中継
被害者が入力する情報すべてが攻撃者経由。
この「透明な中継」が Reverse Proxy 攻撃の本質。
実際のツール（例：Evilginx2）の動作イメージ
Evilginx 設定で典型的なのはコレ↓
phishlets:
google:
proxy_hosts:
- {phish_sub: "accounts", orig_sub: "accounts", domain: "google.com"}
cookie:
domain: "google.com"
Evilginx はこの設定を使って：
- HTML を中継
- Cookie を盗む
- redirect_uri を再構築
- MFA も通過
という動作を自動化している。
まとめ
Reverse Proxy 攻撃の本質は：
「正規サイトをそのまま中継し、認証済み Cookie を奪う」
「TOTP では太刀打ちできない」
「Passkey（WebAuthn）が唯一の根本防衛手段」
という点にあります。
現代のフィッシング対策は、
もはや「怪しいページを見分ける」レベルでは限界。
技術的に防げる方式（Passkey）を使う時代に入っています。