Deauthentication Attack (ディオース攻撃) は IEEE 802.11 (Wi-Fi) の管理フレーム「Deauthentication (Subtype 0x0C)」を偽装して送り、AP / クライアント間の接続を強制切断する攻撃。数千円の Wi-Fi カード 1 枚 + aircrack-ng / mdk4 / wifite で実行できる古典攻撃だが、2026 年も現役。根本原因は 1997 年の 802.11 初期仕様で「管理フレームは平文・無認証」と決められた歴史的欠陥。本稿は仕組み・4 つの攻撃シナリオ・ツール・事件・802.11w / WPA3 による防御・日本電波法 / FCC の法的位置付けまでを扱う。
難しく見えても本質は次の 3 つだけ。(1) Deauth Attack は 「Wi-Fi の切断命令を偽装して送ることで、AP とクライアントの接続を強制的に切る」攻撃。Wi-Fi の電波が届く範囲なら、パスワード不要で誰でも実行できる。(2) 防御は 「PMF (802.11w) を有効化」の 1 つだけ — これで Deauth は無効化される。WPA3 では必須。(3) 他人の Wi-Fi に撃つと電波法 109 条 2 項違反 (1 年以下の懲役)。学習は 自分の AP / 契約済みのペンテスト対象でのみ。— ここを土台に各章を順に開いていけばいい。
802.11 のフレームと管理フレームの歴史的欠陥 #
IEEE 802.11 の MAC 層では、フレームを大きく 3 種類に分ける。
1997 年の Wi-Fi 仕様策定時、エンジニアは 「ユーザのデータは暗号化、管理用の指示は平文でいい」と判断した — 当時は「制御フレームが悪用される」と想定していなかった。だが 「お前は切断しろ」という指示 (Deauth) も管理フレームの 1 つで、誰でも偽装して送れてしまう。これが 30 年経った今も Wi-Fi の典型的弱点として残っている根本理由。2009 年の 802.11w (PMF) で管理フレームに署名を付ける仕組みが追加されたが、互換性のため 有効になっていない機器がまだ多いのが現実。
| 種別 | 役割 | 暗号化 (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 に誘導したりできる
ターゲットの AP / クライアントの認証情報も WEP / WPA キーも不要。これが Deauth Attack の決定的な強さ。
Deauth フレームの構造 #
実物の Deauth フレームを見ると、ペイロードはわずか 26 バイト程度。
| フィールド | 長さ | 内容 |
|---|---|---|
| Frame Control | 2 bytes | Type=Management / Subtype=0x0C |
| Duration | 2 bytes | NAV 用 |
| Address 1 (DA) | 6 bytes | Destination MAC |
| Address 2 (SA) | 6 bytes | Source MAC ★偽装可能 |
| Address 3 (BSSID) | 6 bytes | BSSID |
| Sequence Control | 2 bytes | シーケンス番号 |
| Reason Code | 2 bytes | 切断理由 (ペイロードはこれだけ) |
| FCS | 4 bytes | CRC32 / 整合性検査のみ — 改ざん防止にはならない |
Reason Code の代表値 #
- 1 — Unspecified reason / 最も汎用、攻撃でよく使われる
- 2 — Previous authentication no longer valid
- 3 — Sending STA leaving (deauth/disassoc)
- 7 — Class 3 frame received from nonassociated STA
なぜ平文 + 認証なしで送れるのか — 仕様の歴史 #
WPA2 / Mixed Mode で動く既存機器が大半、公衆 Wi-Fi / レガシー社内 AP では PMF 無効が一般的。Address 2 (SA) を任意の MAC に書き換えれば、AP・クライアントどちらにもなりすませる。モニタモード + パケット注入対応の Wi-Fi カードで、1 秒間に数百〜数千発の Deauth を撃てる。
4 つの攻撃シナリオ — Deauth は Building Block #
「Deauth Attack」と聞いて DoS (切断攻撃) を思い浮かべる人が多いが、実際の悪用パターンは多様で、より大きな攻撃の構成要素として組み込まれることが多い。
Deauth 自体は「ドアを蹴ってクライアントを叩き出す」だけの簡単な動作。実際の悪用は 「叩き出した後、再入場のタイミングを利用する」多段攻撃が本命。① 純粋な DoS = ドアを叩き続けて誰も入れない状態にする。② Handshake 捕獲 = 再入場時の鍵交換 (4-way handshake) を盗み聞きしてオフラインでパスワード解析。③ Evil Twin 誘導 = 偽のドアを用意して再入場時にそちらに誘導 → 中間者攻撃。④ 周波数ダウングレード = 5GHz の本物を閉めて 2.4GHz の偽物に誘導。Deauth は「再接続のタイミングを攻撃者が作る」起爆装置、と理解すると見通しが良い。
| シナリオ | 内容 | 代表ツール |
|---|---|---|
| ① 純粋な DoS | Broadcast Deauth を連続送出 → 範囲内全クライアントが切断/再接続を繰り返す。電子鍵 / IP カメラ / IoT の物理影響 | aireplay-ng / mdk4 / wifite |
| ② WPA2 4-way Handshake 捕獲 | 1 度 Deauth → クライアント自動再接続 → 4-way handshake をキャプチャ → オフライン辞書攻撃 | aircrack-ng / hashcat |
| ③ Evil Twin / Rogue AP 誘導 | 同 SSID の偽 AP を立ててから Deauth で本物 AP から切断 → クライアントは強い偽 AP に再接続 → MITM | airbase-ng / WiFi-Pumpkin / EAPHammer |
| ④ 5GHz → 2.4GHz ダウングレード | 5GHz AP を Deauth で切断 → クライアントは 2.4GHz の同 SSID または偽 AP にロールバック | mdk4 |
シナリオ ② (Handshake 捕獲) のシーケンス #
aireplay-ng --deauth 1 -a [BSSID] -c [Client MAC] で 1 発だけ送る。Broadcast よりステルス。airodump-ng でこれを capture.pcap に保存。hashcat -m 22000 capture.hc22000 wordlist.txt で GPU クラック。WPA2-PSK は弱いパスワードなら数時間〜数日で破られる。WPA3 SAE はオフライン辞書耐性あり。クラック自体は handshake 取得後の話。Deauth は「正規接続を一度切ってもらう」必要条件として機能する。Deauth Attack だけが目的なケースはむしろ少数派で、より大きな侵害シナリオの最初の一手として使われるのが現実。
実装ツール — OSS で簡単に揃う #
| ツール | 用途 |
|---|---|
| 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 と組合せ) |
# (1) Wi-Fi カードをモニタモードへ
$ sudo airmon-ng start wlan0
# → wlan0mon が生成
# (2) ターゲット AP の channel / BSSID / クライアント MAC を確認
$ sudo airodump-ng wlan0mon
# → 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
KEY FOUND! [ password123 ]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 契約下のターゲットでのみ実行可能。詳細は最終セクション。
代表事件 — Deauth が実害を出した実例 #
| 年 | 事件 | 内容と教訓 |
|---|---|---|
| 2014 | Marriott Hotel ($600,000 FCC 罰金) | Marriott Gaylord Opryland (Nashville) が会議参加者の私物 Wi-Fi ホットスポットを Deauth で強制停止し、有料 Wi-Fi 利用を強制。FCC が「商業目的の Wi-Fi 妨害」として $600,000 の罰金 |
| 2014 | Hilton 系列 ($25,000 FCC 罰金) | 同様に有料 Wi-Fi 強制のため宿泊客の MiFi/ホットスポットを Deauth。$25,000 の罰金 + 公的調査協力義務 |
| 2015 | 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 を誘発する組合せ |
| 2018- | 物理セキュリティ研究 | 自社オフィスの IP カメラ / 電子鍵 / 入退室管理が Wi-Fi 上だと Deauth で容易に停止する事実が、「Wi-Fi 依存の物理セキュリティは脆弱」という業界認識を強めた |
有線 (PoE Ethernet) や 4G/5G セルラーへのフェイルオーバーを持つ製品が増えてきたのはこの認識の表れ。
防御 — 802.11w (PMF) と検知 #
技術的な根本対策は 1 つ: 802.11w (Protected Management Frames, PMF) を有効化する。
家庭の Wi-Fi ルータの管理画面に入って、次の 2 つを確認すれば家庭での Deauth Attack は基本的に防げる。(1) WPA3 (または WPA2/WPA3 mixed) に切り替える — WPA3 では PMF が義務なので自動で有効化される。(2) 「Protected Management Frames」「PMF」「802.11w」 の項目を 「Required」または「有効」に設定。古い IoT 機器が繋がらなくなる場合は、IoT 用 SSID と分けて運用するのが定石。「PMF Required にできるか」が、現代の Wi-Fi 設計のリトマス試験。スマホは iOS / Android / Windows / macOS の現行版は全部 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 が提供 |
| 物理シールド | RF 遮蔽 (建物の電波遮蔽塗料 / Faraday cage) は極端だが、軍事 / SCIF / DC の限定用途で有効 |
| 重要機器の有線化 | IP カメラ / 電子鍵 / プリンタなど停止が物理影響を生む機器は PoE Ethernet 接続にする |
| モニタリング | 自社オフィスで定期的に airodump-ng / Kismet で未登録の AP・Deauth を監視 |
# /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 では必須)# /etc/NetworkManager/system-connections/MyAP.nmconnection
[wifi-security]
key-mgmt=wpa-psk
pmf=3 # 0=default / 1=disable / 2=optional / 3=requiredWindows 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 に対する防御力の事実上のリトマス試験。
検知 — 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 #
- OSS — Kismet (定番、Linux、無料) / WAIDPS / Snort + Wireless preprocessor
- 商用 — Cisco CleanAir / Aruba RFProtect / Meraki Wireless Health — エンタープライズ AP の付加機能として検知 + 自動防御
Kismet の log を Splunk / Elastic に流して「特定 SSID で 1 分間に 100 発以上の Deauth」を SIEM ルール化するのが現代の運用。
法律 — 日本電波法と米国 FCC #
Deauth Attack は 3,000 円の Wi-Fi カードと無料の OSS だけで動くので、つい「ちょっとカフェで試してみたい」と思ってしまう。だがこれを 他人の Wi-Fi (= カフェ / ホテル / 隣家) に撃った瞬間に犯罪になる。「捕まらないだろう」は楽観的すぎる — 公衆 Wi-Fi 環境では SOC / WIDS で異常検知される確率が高く、特定された場合の社会的代償は計り知れない。合法に学ぶ場は (1) 自分が買って自宅に置いた AP / (2) HackTheBox / TryHackMe の Wi-Fi 関連マシン / (3) 書面合意済みのペンテスト案件 の 3 つだけ。技術は学べるが、撃つ相手は厳密に選ぶ。
日本の法的位置付け #
- 電波法 109 条 2 項 (無線設備の機能を妨害) — 「他人の通信を妨害する目的で電波を発射」は1 年以下の懲役または 100 万円以下の罰金
- 電波法 4 条 (免許主義) — そもそも Wi-Fi 帯の出力規制を超える妨害行為は無免許局運用にも該当しうる
- 不正アクセス禁止法 — 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 — すべて違法
まとめ #
- Deauth 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 のハードルが低い分、実害事例も累積
- 技術的な根本対策はPMF Required の有効化 + WPA3 移行。法的には日本電波法 109 条 2 項 / 米 FCC Section 333 の対象で、他人の Wi-Fi で実行すれば確実に違法。「動かしてみたい」と思ったら、自分の AP か契約済みの Pentest 対象でのみ
