Deauthentication Attack (ディオース攻撃) #
Deauthentication Attack (略称 Deauth Attack / De-auth、日本語ではディオース攻撃 / 認証解除攻撃) は、IEEE 802.11 (Wi-Fi) の管理フレームの 1 つ「Deauthentication フレーム (Subtype 0x0C)」を偽装して送り、AP / クライアント間の接続を強制切断する攻撃。ハードウェアは数千円の Wi-Fi カード 1 枚で十分、ソフトウェアは aircrack-ng / mdk4 / wifite といった OSS で揃うため、Wi-Fi セキュリティで最も古くから知られた典型的攻撃でありながら、2026 年現在もなお有効に動く現役の攻撃として残っている。
根本原因は 1997 年の IEEE 802.11 初期仕様で「管理フレーム (Management Frame) は平文・無認証で送る」と決められた歴史的設計欠陥。データフレームは WEP / WPA / WPA2 / WPA3 で順次保護されてきたが、「接続 / 切断 / 認証管理を扱う管理フレーム」は何十年も無防備なまま放置されてきた。2009 年に 802.11w (Protected Management Frames, PMF) が策定され、2018 年の WPA3 認証で PMF が義務化されたことでようやく仕様レベルの対策が揃ったが、現実には大半のレガシー機器・公衆 Wi-Fi・古い社内 AP で PMF は無効のままで、攻撃可能な対象が膨大に残っている。
本稿は 「Deauth は単独の DoS というより、より大きな攻撃 (WPA2 ハンドシェイク捕獲 / Evil Twin 誘導 / 5GHz→2.4GHz ダウングレード) の Building Block」 という観点を軸に、Deauth フレームの仕組み (SVG 1) / 4 つの攻撃シナリオ (SVG 2) / 実装ツール / 代表事件 / 802.11w による技術的防御 / 日本電波法・米国 FCC の法的位置付けまでを扱う。
1. 802.11 のフレームと「管理フレームの歴史的欠陥」 #
IEEE 802.11 の MAC 層では、フレームを大きく 3 種類 に分ける:
| 種別 | 役割 | 暗号化 (WPA2 時代) |
|---|---|---|
| Data Frame | 実際のユーザデータ (HTTP / TCP 等) | WPA2 で暗号化 |
| Control Frame | RTS / CTS / ACK など低レベル制御 | 暗号化なし |
| Management Frame | Beacon / Probe / Association / Deauthentication / Disassociation | WPA2 でも暗号化なし (PMF 未対応時) |
問題は Management Frame。接続管理 (Authentication / Association / Deauthentication / Disassociation) の重要フレームを平文・無認証で送る設計は、1997 年の初期仕様策定時から変わらず長らく続いた。
その結果、攻撃者は AP / クライアントのどちらかになりすまし、Deauth フレームをばらまくだけで:
- 接続中のクライアントを切断
- AP に「このクライアントは切断した」と誤認させる
- 切断後、クライアントが自動再接続しようとするタイミングでハンドシェイクを捕獲したりEvil Twin に誘導したりできる
「Wi-Fi の信号が届く範囲にいる」だけで実行可能で、ターゲットの AP / クライアントの認証情報も WEP / WPA キーも不要な点が、Deauth Attack の決定的な強さ。
2. Deauth フレームの構造 — なぜ平文で成立するのか #
実物の Deauth フレームをバイトレベルで見る:
Address 2 (SA = Source Address) を任意の MAC に書き換えれば、AP・クライアントどちらにもなりすませる点が決定的。Wi-Fi カードのモニタモード + パケット注入対応 (Linux で iw / aircrack-ng) があれば、MAC 偽装した Deauth フレームを 1 秒間に数百〜数千発撃ち込める。
3. 攻撃シナリオ — Deauth は単独の DoS ではなく Building Block #
「Deauth Attack」と聞いて DoS (切断攻撃) を思い浮かべる人が多いが、実際の悪用パターンは多様で、より大きな攻撃の構成要素として組み込まれることが多い:
Deauth Attack の 4 つの典型シナリオ
DoS / WPA2 4-way Handshake 捕獲 / Evil Twin 誘導 / 周波数帯ロールバック
① 純粋な DoS — Wi-Fi の継続的妨害
攻撃者: 連続して Broadcast Deauth フレームを送出
対象範囲全クライアントが何度も切断 / 再接続を繰り返す
電子鍵 / IP カメラ / IoT デバイスを物理影響まで含めて停止
② WPA2 4-Way Handshake 捕獲 → 辞書攻撃
攻撃者: 1 度 Deauth → クライアント自動再接続 → 4-way handshake をキャプチャ
capture.pcap → hashcat / aircrack-ng でオフライン辞書攻撃
WPA2-PSK が短いパスワード (~10 文字未満) ならクラック可能
③ Evil Twin / Rogue AP 誘導
攻撃者: 同 SSID の Rogue AP を立ててから、本物 AP からクライアントを Deauth で切断
クライアントは自動的に "より電波が強い" 偽 AP に再接続
攻撃者は中間者として全通信を観察 / HTTPS は SSL Strip / Captive Portal で credential 詐取
④ 5GHz → 2.4GHz ダウングレード
攻撃者: 5GHz バンドの AP を Deauth でクライアントから切断
クライアントは 2.4GHz の同 SSID または偽 AP にロールバック
2.4GHz の方が遠距離・障害物に強い → 攻撃者は離れた場所から作戦継続可能
▼ シナリオ ② (Handshake 捕獲) のシーケンス例
[Attacker] mon0 でターゲット AP の channel を listen / airodump-ng でクライアント MAC を取得
[Attacker → Client] aireplay-ng --deauth 1 -a [BSSID] -c [Client MAC] でターゲット 1 名に Deauth 送出
[Client] 自動再接続 → AP と 4-way handshake を実行 (M1 → M2 → M3 → M4)
[Attacker] handshake.pcap → hashcat -m 22000 で辞書 / GPU クラック
シナリオ毎の戦略的位置付け:
- (1) DoS: 物理セキュリティ / IP カメラ / 電子鍵を意図的に停止したい場面で使う (合法的には Pentest のシナリオ確認のみ)
- (2) Handshake 捕獲: WPA2-PSK が今でもクラック可能な現実を支える。Deauth は「正規接続を一度切ってもらう」必要条件
- (3) Evil Twin: 公共 Wi-Fi での認証情報詐取 / フィッシングの入口。Deauth で本物 AP から離脱させる → 偽 AP に再接続させる
- (4) ダウングレード: WPA3 / PMF 対応の AP からも、未対応バンド/未対応モードへの強制移行で攻撃面を確保する高度な手口
**「Deauth Attack だけが目的」**なケースはむしろ少数派で、より大きな侵害シナリオの最初の一手として使われるのが現実。
4. 実装ツール — OSS で簡単に揃う #
主要ツール (Kali Linux / Parrot OS に標準搭載):
| ツール | 用途 |
|---|---|
| aircrack-ng スイート | 業界標準 — airmon-ng (モニタモード) / airodump-ng (スキャン) / aireplay-ng (Deauth 注入) / aircrack-ng (クラック) |
| mdk3 / mdk4 | より破壊的 — 大量 Deauth Flooding / Beacon Flood / Authentication Flood |
| wifite / wifite2 | aircrack-ng の自動化フロントエンド。1 コマンドで Deauth + Handshake 捕獲 + クラックまで |
| scapy | Python から任意の 802.11 フレーム生成 — Deauth カスタム / 学習用 |
| bettercap | 多用途 MITM フレームワーク — Wi-Fi モジュールに Deauth 機能 |
| airbase-ng / hostapd-mana / WiFi-Pumpkin | Evil Twin / Rogue AP 構築 (Deauth と組合せ) |
aireplay-ng での Deauth 注入の基本コマンド:
# (1) Wi-Fi カードをモニタモードへ
sudo airmon-ng start wlan0
# → wlan0mon が生成
# (2) ターゲット AP の channel / BSSID / クライアント MAC を確認
sudo airodump-ng wlan0mon
# → AP の BSSID = XX:XX:XX:XX:XX:XX / Channel = 6 / Client = YY:YY:YY:YY:YY:YY
# (3) 該当 channel を fix
sudo airodump-ng -c 6 --bssid XX:XX:XX:XX:XX:XX -w capture wlan0mon
# (4) 別ターミナルから Deauth 注入 (--deauth 10 = 10 発)
sudo aireplay-ng --deauth 10 -a XX:XX:XX:XX:XX:XX -c YY:YY:YY:YY:YY:YY wlan0mon
# (5) handshake が capture-01.cap に入っていることを確認
sudo aircrack-ng -w wordlist.txt capture-01.cap
scapy で Deauth フレームを自作する例 (教育目的):
from scapy.all import *
bssid = "XX:XX:XX:XX:XX:XX"
client = "YY:YY:YY:YY:YY:YY"
# Deauth フレーム (Subtype 12 = Deauthentication)
pkt = RadioTap() / \
Dot11(type=0, subtype=12, addr1=client, addr2=bssid, addr3=bssid) / \
Dot11Deauth(reason=7)
sendp(pkt, iface="wlan0mon", count=10, inter=0.1)
法的注意: このコマンドを他人の Wi-Fi に対して実行することは日本では電波法 / 不正アクセス禁止法違反。自分が所有する AP / 自宅 LAN / Pentest 契約下のターゲットでのみ実行可能。後述。
5. 代表事件 — Deauth が実害を出した実例 #
| 年 | 事件 | 内容と教訓 |
|---|---|---|
| 2014 | Marriott Hotel ($600,000 FCC 罰金) | Marriott Gaylord Opryland (Nashville) ホテルが会議参加者の私物 Wi-Fi ホットスポットを Deauth で強制停止し、有料 Wi-Fi 利用を強制。FCC が「商業目的の Wi-Fi 妨害」として $600,000 の罰金。「私物 AP まで企業の都合で切断するのは違法」を確立 |
| 2014 | Hilton 関連の Wi-Fi 妨害 ($25,000 FCC 罰金) | Hilton 系列でも同様に有料 Wi-Fi 強制のため宿泊客の MiFi/ホットスポットを Deauth。FCC が $25,000 の罰金 + 公的調査協力義務を課す。業界全体への警告となった |
| 2015 | Smart-X 関連 / Smart City IoT | スマートシティ実証で街路灯 / 屋外 IP カメラの Wi-Fi 制御チャネルが Deauth でテスト中に停止 → Wi-Fi 制御の IoT を critical infrastructure に使う設計の脆さが露呈 |
| 2016-2020 | 公共 Wi-Fi 利用者の credential 詐取 | 空港 / カフェ / ホテルロビーで Evil Twin + Deauth の組合せにより通行人の SNS / メール認証情報の収集事件が複数報告。WiFi Alliance が WPA3 義務化を急いだ背景の 1 つ |
| 2017 | KRACK 攻撃公開時 | Mathy Vanhoef の WPA2 KRACK 脆弱性は単独で動くが、実際の悪用例は Deauth で再接続を強制 → KRACK で nonce reuse を誘発する組合せ。Deauth が他攻撃のトリガーとして再注目 |
| 2018- | 物理セキュリティ研究 | 自社オフィスの IP カメラ / 電子鍵 / 入退室管理が Wi-Fi 上だと Deauth で容易に停止する事実が、**「Wi-Fi 依存の物理セキュリティは脆弱」**という業界認識を強めた |
「Wi-Fi に依存した IoT / 物理セキュリティ」は、Deauth Attack 1 つで実害を出す前提で設計すべき、というのが教訓。有線 (PoE Ethernet) や 4G/5G セルラーへのフェイルオーバーを持つ製品が増えてきたのはこの認識の表れ。
6. 防御 — 802.11w (PMF) と検知 #
技術的な根本対策は 1 つ: 802.11w (Protected Management Frames, PMF) を有効化する。
| 対策 | 内容 |
|---|---|
| PMF (802.11w) 有効化 | AP / クライアント両方で PMF をサポート + 有効 → Deauth フレームに MIC が付き、改ざんを検出して破棄 |
| WPA3 の採用 | WPA3 認証取得機器は PMF が義務 → 自動的に Deauth Attack 無効化 |
| PMF Required モード | "Capable" (互換) ではなく "Required" (必須) 設定で、非対応クライアントは接続拒否 |
| WIDS / 異常検知 | Wireless IDS で「特定 MAC からの Deauth 大量発生」をパターンマッチ。Aruba / Meraki / Cisco の AP は無料 / 有料で機能提供 |
| 物理シールド | RF 遮蔽 (建物の電波遮蔽塗料 / Faraday cage) は極端だが、軍事 / SCIF / データセンタの限定用途では有効 |
| 重要機器の有線化 | IP カメラ / 電子鍵 / プリンタなど**「停止が物理的影響を生む」機器は PoE Ethernet 接続**にする |
| モニタリング | 自社オフィスで定期的に airodump-ng / Kismet で未登録の AP・Deauth フレームを監視 |
AP 側の PMF 有効化 (例: hostapd):
# /etc/hostapd/hostapd.conf
wpa=2
wpa_key_mgmt=WPA-PSK
ieee80211w=2 # 0=Disabled / 1=Capable / 2=Required
# WPA3 の場合
# wpa_key_mgmt=SAE
# ieee80211w=2 (SAE では必須)
クライアント側 (Linux NetworkManager):
# /etc/NetworkManager/system-connections/MyAP.nmconnection
[wifi-security]
key-mgmt=wpa-psk
pmf=3 # 0=default / 1=disable / 2=optional / 3=required
Windows 11 / macOS / iOS / Android は近年デフォルトで PMF サポート。AP 側が "Required" なら自動で有効になる。
現実の運用上の壁:
- 古い AP (5 年以上前) は PMF 非対応のことがあり、ファームウェア更新でも対応しない場合がある
- 公衆 Wi-Fi は互換性最優先で PMF を Optional にしがち — 結果として Deauth は防げない
- WPA2 + PMF Required にすると、古い IoT 機器 (PMF 非対応) が接続できなくなる → 既存資産との互換性問題
- 企業環境では 2.4GHz 帯のレガシー機器が PMF 非対応で、5GHz と分離した SSID 運用が必要になる
「PMF Required にできるか」が、Deauth Attack に対する防御力の事実上のリトマス試験。
7. 検知 — Wireless IDS (WIDS) で見えるもの #
WIDS は Wi-Fi 上の異常を検知する仕組みで、Deauth Attack は最も検知しやすいタイプの異常:
| 検知サイン | 意味 |
|---|---|
| 同一 BSSID から短時間に大量の Deauth | Broadcast Deauth Flood (mdk4 など) |
| 特定 client MAC への Deauth が連続 | Targeted Deauth (4-way handshake 捕獲を狙う前段) |
| 複数 BSSID が同 SSID を Beacon | Evil Twin の存在示唆 |
| 電波強度が異常 (近距離からの強い信号) | 攻撃者が物理的に近い可能性 |
| PMF 必須環境で Plain text Deauth が来る | 確実に偽装 — MIC 検証失敗で破棄するが警告として記録 |
OSS の WIDS / モニタリング:
- Kismet (定番、Linux、無料) — Deauth Flood / Rogue AP / 異常パターン検知
- WAIDPS — Wifite 作者の WIDS
- Snort + Wireless preprocessor
商用:
- Cisco CleanAir / Aruba RFProtect / Meraki Wireless Health — エンタープライズ AP の付加機能として検知 + 自動防御 (= 偽 AP に対する電波妨害カウンター)
SOC 統合: Kismet の log を Splunk / Elastic に流して 「特定 SSID で 1 分間に 100 発以上の Deauth」 を SIEM ルール化するのが現代の運用。
8. 法律 — 日本電波法と米国 FCC #
日本の法的位置付け:
- 電波法 109 条 2 項 (無線設備の機能を妨害): 「他人の通信を妨害する目的で電波を発射」は 1 年以下の懲役または 100 万円以下の罰金
- 電波法 4 条 (免許主義): そもそも Wi-Fi 帯 (2.4GHz / 5GHz) の出力規制を超える妨害行為は無免許局運用にも該当しうる
- 不正アクセス禁止法: Deauth で切断 → Evil Twin 誘導 → credential 詐取まで進むと、第 5 条 (不正アクセス助長罪) / 第 4 条 (不正アクセス行為の禁止) の問題に発展
- 威力業務妨害罪 (刑法 234 条): 商業施設の Wi-Fi を意図的に妨害すれば威力業務妨害として 3 年以下の懲役または 50 万円以下の罰金
米国 FCC の立場:
- Communications Act of 1934, Section 333: 「他人の正規ライセンス通信の妨害」は連邦法違反
- Marriott / Hilton への高額罰金は本条項に基づく
- **FCC は 2015 年に「ホテル / オフィスでも個人の Wi-Fi ホットスポット妨害は違法」**と明確化
Pentest / 研究では契約と書面が必須:
- 自分が所有する AP / 自宅 LAN — 合法
- 顧客との Rules of Engagement で書面合意した範囲内 — 合法
- 上記以外で他人の Wi-Fi を Deauth → すべて違法
「技術的に簡単」と「法的に許される」の間に大きな差がある分野なので、意図せず違法行為に踏み込まないよう注意が必要。
Deauthentication Attack は 「Wi-Fi の管理フレームが歴史的に平文・無認証で送られてきた」設計欠陥を悪用して、接続を強制切断する攻撃。1997 年仕様で生まれた弱点が、2009 年 802.11w (PMF)・2018 年 WPA3 で技術的には解決したものの、実装の互換性問題で PMF 未有効の機器が大半を占める現実から、2026 年現在も「動く現役攻撃」として残っている。
Deauth 単独より、より大きな攻撃 (WPA2 4-way Handshake 捕獲 → オフラインクラック / Evil Twin 誘導 / 周波数帯ダウングレード) の Building Block として組み込まれるのが実態。ハードは数千円の Wi-Fi カード 1 枚 / ソフトは aircrack-ng / mdk4 / wifite で揃うため、学習・Pentest のハードルが極端に低く、その分実害事例 (Marriott / Hilton の FCC 罰金 / 公共 Wi-Fi credential 詐取 / IoT 物理セキュリティ停止) も累積している。
技術的な根本対策は PMF の有効化 (Required モード) + WPA3 移行。法的には日本では電波法 109 条 2 項 / 米 FCC Section 333 の対象で、他人の Wi-Fi 環境で実行すれば確実に違法。「動かしてみたい」と思ったら、自分の AP か契約済みの Pentest 対象でのみ、というのがこの攻撃を扱う上での唯一の原則。
