Сергей Попов
11.04.2026, 15:20
https://forum.antichat.xyz/attachments/4951464/img_fe9040b68e.png
Корпоративный Wi-Fi на базе WPA2/WPA3-Enterprise выглядит солидно: индивидуальная аутентификация через RADIUS, туннелированные EAP-методы, сертификаты. На бумаге - крепость. На практике в большинстве проектов, которые я провожу, evil twin атака Wi-Fi позволяет перехватить доменные учётные данные, ни разу не зайдя в здание. Прямо с парковки, с ноутбуком и Alpha-адаптером на торпеде. Проблема не в криптографии - она в том, как реализована (точнее - как не реализована) цепочка доверия между клиентом и сервером аутентификации.
Здесь разберём пентест 802.1X на уровне протокольного стека: почему атака работает, как настроить hostapd-mana для перехвата EAP-хэндшейков, как крекать MSCHAPv2-хэши и что делать, когда WPA3-Enterprise стоит на пути. Всё с воспроизводимыми командами и конфигами из реальных ассессментов.
Как работает 802.1X и где ломается цепочка доверия
Прежде чем атаковать, нужно понимать, что именно мы ломаем. 802.1X - это framework порт-контролируемого доступа, где три участника обмениваются данными в строгой последовательности:
Supplicant (клиент) - ноутбук или телефон сотрудника
Authenticator (точка доступа) - пересылает EAP-фреймы между клиентом и сервером
Authentication Server (RADIUS) - принимает решение об аутентификации
Ключевой момент: точка доступа - это транспорт, она не проверяет содержимое EAP-фреймов. Подставляем свою точку (rogue access point) - и клиент начинает EAP-обмен с нашим RADIUS-сервером, даже не подозревая о подмене.
Фазы EAP-аутентификации и точка перехвата
В PEAP и EAP-TTLS аутентификация проходит в две фазы:
Phase 1 (outer) - устанавливается TLS-туннель между supplicant и RADIUS-сервером. Сервер предъявляет сертификат, клиент должен его проверить.
Phase 2 (inner) - внутри туннеля передаются учётные данные. Для PEAP это MSCHAPv2 challenge-response, для EAP-TTLS - PAP, CHAP или тот же MSCHAPv2.
Атака проходит на стыке двух фаз. Если клиент не валидирует сертификат RADIUS-сервера в Phase 1, он установит TLS-туннель с нашим evil twin и отправит credentials в Phase 2. Техника Evil Twin (T1557.004, Credential Access и Collection по MITRE ATT&CK).
По данным исследования ScienceDirect, посвящённого атакам на Wi-Fi Enterprise сети (в контексте Eduroam), именно отсутствие принудительной валидации сертификата на стороне клиента - корневая причина успешных evil twin атак на WPA-Enterprise. Не баг протокола, а баг внедрения.
Почему клиенты не проверяют сертификат
На практике я постоянно встречаю три сценария:
Android до версии 11 - по умолчанию не требует указания CA-сертификата для Enterprise-профилей. Пользователь видит предупреждение, жмёт «Подключиться» и идёт дальше. Классика.
Windows без GPO - если профиль Wi-Fi добавлен вручную, а не через групповую политику, валидация имени сервера и CA не настроена. А руками профили добавляют чаще, чем хотелось бы.
BYOD-устройства - личные телефоны и ноутбуки сотрудников, подключённые к корпоративному SSID без MDM-профиля, почти никогда не имеют правильной конфигурации.
Это не теоретическая проблема. Это причина, по которой перехват EAP учётных данных работает в большинстве корпоративных сред.
Разведка перед атакой: что искать в эфире (https://forum.antichat.xyz/threads/592416/)
Перед развёртыванием evil twin нужно понять структуру целевой сети. Этап Wi-Fi Discovery (T1016.002, Discovery по MITRE ATT&CK).
Bash:
# Переводим адаптер в monitor mode
sudo
airmon-ng start wlan0
# Пассивный сбор информации о сетях
sudo
airodump-ng wlan0mon --band abg -w recon_dump
На что смотреть в выводе:
ENC/CIPHER/AUTH - для Enterprise-сети увидите
WPA2 / CCMP / MGT
. Флаг
MGT
означает 802.1X (EAP-based authentication), а не PSK.
BSSID и ESSID - фиксируем MAC-адрес и имя целевой сети. Имя будем клонировать.
Канал - evil twin поднимаем на другом канале, чтобы снизить интерференцию с легитимной AP.
Клиенты - наличие ассоциированных станций. Без активных клиентов атака бессмысленна - не с кем взаимодействовать.
Для более глубокого анализа EAP-типов нужен Wireshark. Перехватываем трафик в monitor mode и фильтруем:
Код:
eap && wlan.bssid == AA:BB:CC:DD:EE:FF
В EAP-Response/Identity увидим username в открытом виде (если не используется анонимный outer identity). В EAP-Request - предлагаемый EAP-тип: 25 = PEAP, 21 = EAP-TTLS, 13 = EAP-TLS. Это критически важно для настройки evil twin. Если целевая сеть использует EAP-TLS с клиентскими сертификатами - перехват credentials через evil twin не сработает в классическом виде. Тут придётся менять тактику.
Настройка hostapd-mana для evil twin атаки на WPA2 Enterprise
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше (https://forum.antichat.xyz/threads/560728/)
Получить доступ просто — достаточно проявить активность на форуме
Проводите аудит безопасности Wi-Fi? Начните с проверки: какие EAP-методы используются и как настроены профили на клиентских устройствах. Попробуйте поднять evil twin в лабе против собственных устройств - результат может удивить. Именно это определяет, сработает ли атака в поле или нет.
Корпоративный Wi-Fi на базе WPA2/WPA3-Enterprise выглядит солидно: индивидуальная аутентификация через RADIUS, туннелированные EAP-методы, сертификаты. На бумаге - крепость. На практике в большинстве проектов, которые я провожу, evil twin атака Wi-Fi позволяет перехватить доменные учётные данные, ни разу не зайдя в здание. Прямо с парковки, с ноутбуком и Alpha-адаптером на торпеде. Проблема не в криптографии - она в том, как реализована (точнее - как не реализована) цепочка доверия между клиентом и сервером аутентификации.
Здесь разберём пентест 802.1X на уровне протокольного стека: почему атака работает, как настроить hostapd-mana для перехвата EAP-хэндшейков, как крекать MSCHAPv2-хэши и что делать, когда WPA3-Enterprise стоит на пути. Всё с воспроизводимыми командами и конфигами из реальных ассессментов.
Как работает 802.1X и где ломается цепочка доверия
Прежде чем атаковать, нужно понимать, что именно мы ломаем. 802.1X - это framework порт-контролируемого доступа, где три участника обмениваются данными в строгой последовательности:
Supplicant (клиент) - ноутбук или телефон сотрудника
Authenticator (точка доступа) - пересылает EAP-фреймы между клиентом и сервером
Authentication Server (RADIUS) - принимает решение об аутентификации
Ключевой момент: точка доступа - это транспорт, она не проверяет содержимое EAP-фреймов. Подставляем свою точку (rogue access point) - и клиент начинает EAP-обмен с нашим RADIUS-сервером, даже не подозревая о подмене.
Фазы EAP-аутентификации и точка перехвата
В PEAP и EAP-TTLS аутентификация проходит в две фазы:
Phase 1 (outer) - устанавливается TLS-туннель между supplicant и RADIUS-сервером. Сервер предъявляет сертификат, клиент должен его проверить.
Phase 2 (inner) - внутри туннеля передаются учётные данные. Для PEAP это MSCHAPv2 challenge-response, для EAP-TTLS - PAP, CHAP или тот же MSCHAPv2.
Атака проходит на стыке двух фаз. Если клиент не валидирует сертификат RADIUS-сервера в Phase 1, он установит TLS-туннель с нашим evil twin и отправит credentials в Phase 2. Техника Evil Twin (T1557.004, Credential Access и Collection по MITRE ATT&CK).
По данным исследования ScienceDirect, посвящённого атакам на Wi-Fi Enterprise сети (в контексте Eduroam), именно отсутствие принудительной валидации сертификата на стороне клиента - корневая причина успешных evil twin атак на WPA-Enterprise. Не баг протокола, а баг внедрения.
Почему клиенты не проверяют сертификат
На практике я постоянно встречаю три сценария:
Android до версии 11 - по умолчанию не требует указания CA-сертификата для Enterprise-профилей. Пользователь видит предупреждение, жмёт «Подключиться» и идёт дальше. Классика.
Windows без GPO - если профиль Wi-Fi добавлен вручную, а не через групповую политику, валидация имени сервера и CA не настроена. А руками профили добавляют чаще, чем хотелось бы.
BYOD-устройства - личные телефоны и ноутбуки сотрудников, подключённые к корпоративному SSID без MDM-профиля, почти никогда не имеют правильной конфигурации.
Это не теоретическая проблема. Это причина, по которой перехват EAP учётных данных работает в большинстве корпоративных сред.
Разведка перед атакой: что искать в эфире (https://forum.antichat.xyz/threads/592416/)
Перед развёртыванием evil twin нужно понять структуру целевой сети. Этап Wi-Fi Discovery (T1016.002, Discovery по MITRE ATT&CK).
Bash:
# Переводим адаптер в monitor mode
sudo
airmon-ng start wlan0
# Пассивный сбор информации о сетях
sudo
airodump-ng wlan0mon --band abg -w recon_dump
На что смотреть в выводе:
ENC/CIPHER/AUTH - для Enterprise-сети увидите
WPA2 / CCMP / MGT
. Флаг
MGT
означает 802.1X (EAP-based authentication), а не PSK.
BSSID и ESSID - фиксируем MAC-адрес и имя целевой сети. Имя будем клонировать.
Канал - evil twin поднимаем на другом канале, чтобы снизить интерференцию с легитимной AP.
Клиенты - наличие ассоциированных станций. Без активных клиентов атака бессмысленна - не с кем взаимодействовать.
Для более глубокого анализа EAP-типов нужен Wireshark. Перехватываем трафик в monitor mode и фильтруем:
Код:
eap && wlan.bssid == AA:BB:CC:DD:EE:FF
В EAP-Response/Identity увидим username в открытом виде (если не используется анонимный outer identity). В EAP-Request - предлагаемый EAP-тип: 25 = PEAP, 21 = EAP-TTLS, 13 = EAP-TLS. Это критически важно для настройки evil twin. Если целевая сеть использует EAP-TLS с клиентскими сертификатами - перехват credentials через evil twin не сработает в классическом виде. Тут придётся менять тактику.
Настройка hostapd-mana для evil twin атаки на WPA2 Enterprise
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше (https://forum.antichat.xyz/threads/560728/)
Получить доступ просто — достаточно проявить активность на форуме
Проводите аудит безопасности Wi-Fi? Начните с проверки: какие EAP-методы используются и как настроены профили на клиентских устройствах. Попробуйте поднять evil twin в лабе против собственных устройств - результат может удивить. Именно это определяет, сработает ли атака в поле или нет.