Статья Атака Evil Twin на точку доступа: detection-playbook от deauth до алерта в SIEM

SOC-аналитик видит в консоли WIDS алерт: точка доступа с корпоративным SSID появилась на третьем этаже, но BSSID не совпадает ни с одним из inventory. Через 14 минут к ней подключились шесть устройств. Через 22 - в AD пошли запросы на сброс паролей. Postmortem показал: атакующий развернул Evil Twin с captive portal с парковки за 12 минут, а WIDS был отключён после последнего обновления инфраструктуры два месяца назад. Шесть комплектов доменных учётных данных ушли через поддельную форму авторизации.

На авторизованных wireless-пентестах я разворачиваю такую атаку за 10–15 минут, и в трёх случаях из пяти SOC не фиксирует появление поддельной точки доступа WiFi в первый час. Не потому что техника сложная - потому что wireless-мониторинг у большинства стоит в режиме "вроде работает".

Ниже - разбор того, что именно происходит в эфире, какие артефакты оставляет атака Evil Twin, и конкретные корреляционные правила, по которым её можно поймать.

Бизнес-логика атаки: зачем злоумышленнику создание поддельной точки доступа​

Evil Twin - техника, которую MITRE ATT&CK классифицирует как T1557.004 (тактики Credential Access и Collection). Атакующий поднимает точку доступа с тем же SSID, что и целевая сеть, вынуждает клиентские устройства подключиться к ней и пропускает весь трафик через свою инфраструктуру.

Три конкретных результата, ради которых это делается:

1. Credential harvesting через captive portal фишинг (T1056.003, Web Portal Capture). Пользователь видит привычную страницу авторизации корпоративного Wi-Fi, вводит логин и пароль - данные уходят атакующему.
2. Перехват трафика (T1040, Network Sniffing). Всё, что идёт через Rogue AP без end-to-end шифрования, читается в открытом виде.
3. MitM для развития атаки: DNS spoofing, перехват cookies, инъекция вредоносного кода в HTTP-ответы, перехват MFA-токенов (T1111) через Evilginx-прокси.

Позиция в kill chain: Evil Twin - это initial access или credential access, дающий атакующему валидные учётные данные для входа в корпоративную инфраструктуру. Дальше - lateral movement, доступ к внутренним сервисам, эксфильтрация. Для организации финал цепочки - утечка персональных данных или коммерческой тайны: штрафы по 152-ФЗ (включая оборотные), нотификация Роскомнадзора, репутационный ущерб. По данным Bitdefender, организации несут ответственность, если базовые меры защиты беспроводной сети не были реализованы.

Для SOC-аналитика это значит одно: детект Evil Twin - не "wireless security ради wireless security", а отсечение kill chain на самом раннем этапе.

Анатомия атаки Evil Twin: что происходит в эфире​

Чтобы детектировать атаку, нужно понимать, что именно видит эфир. Цепочка:

Разведка -> Rogue AP setup -> Deauthentication -> Client reconnection -> Captive portal -> Credential harvest

Разведка эфира. Адаптер переводится в monitor mode, собираются beacon frames всех точек доступа: SSID, BSSID, канал, тип шифрования, MAC-адреса подключённых клиентов. Инструменты - airodump-ng или Kismet. Тут ничего хитрого: пять минут в эфире - и полная карта.

Развёртывание Rogue AP. Клонируется SSID (и часто BSSID) целевой сети. Поддельная точка доступа поднимается через hostapd (для WPA2 PSK) или hostapd-wpe (для WPA Enterprise). Мощность сигнала выставляется выше легитимной - или атакующий физически подходит ближе к цели.

Deauthentication. Атакующий шлёт deauth-фреймы от имени легитимной точки доступа, вынуждая клиентов отключиться. В WPA2-сетях без PMF (802.11w) это тривиально - пара команд в aireplay-ng. Для WPA3 с PMF прямой deauth не работает, но, согласно данным HTB Academy, атакующий может создать collision: одноимённый Rogue AP с WPA2-аутентификацией и MANA, вызывающий DoS-условие, после чего клиенты ищут любую доступную альтернативу.

Captive portal фишинг. Подключившийся клиент перенаправляется на поддельную страницу авторизации. Перенаправление - через dnsmasq (DNS spoofing) и iptables (перехват HTTP/HTTPS). Как указывает Varonis, dnsmasq одновременно решает задачу captive portal и спуфинга DNS-серверов, усиливая иллюзию легитимности.

Credential harvest. Введённые данные сохраняются. В enterprise-сценарии с hostapd-wpe атакующий захватывает MSCHAP/MSCHAPv2-хеши через поддельный RADIUS-сервер, принимающий любые запросы аутентификации. Дальше - hashcat и вопрос времени.

[Применимо: внутренний пентест, red team engagement, физический доступ к зоне Wi-Fi покрытия. Не работает удалённо без направленной антенны.]

KARMA-атака на беспроводные сети: поддельные точки доступа на автопилоте​

Классический Evil Twin требует знания конкретного SSID. KARMA масштабируется шире - и опаснее.

Большинство устройств непрерывно рассылают probe requests - запросы "Есть ли поблизости сеть X?" ко всем ранее сохранённым профилям. KARMA-AP перехватывает эти запросы и отвечает "Да, я - сеть X" на каждый из них, автоматически создавая поддельную точку доступа для каждого клиента. По сути - ловушка на автопилоте.

MANA - усовершенствование KARMA. Отличие: KARMA отвечает адресно на каждый probe request, а MANA (в режиме mana-loud) дополнительно широковещательно рекламирует все запрошенные SSID, привлекая даже те устройства, которые не отправляли probe request в этот момент. Результат - в эфире одновременно всплывает десяток "новых" точек доступа с разными SSID, но одним физическим источником.

Паттерн для SOC: множество SSID с одного MAC-адреса - сигнатура KARMA/MANA. Легитимная инфраструктура так не работает: один BSSID = один SSID (максимум - несколько VLAN-ов при Multi-SSID).

Когда техника НЕ работает: iOS 14+ и Android 9+ рандомизируют MAC-адреса probe requests и не подключаются автоматически к открытым сетям, которые ранее не были сохранены явно. А вот корпоративные ноутбуки с Windows 10/11 и устаревшими политиками Wi-Fi по-прежнему уязвимы - особенно если в профилях сохранены открытые сети из командировок и конференций. На пентестах я регулярно вижу по 5–8 сохранённых открытых сетей на одном ноутбуке.

Evil Twin инструменты: что знать защитнику для обнаружения Rogue AP​

Каждый атакующий инструмент оставляет характерные артефакты в эфире. Знание этих артефактов определяет, какие правила писать в WIDS и SIEM.

Инструмент	Сценарий	Артефакты для детектирования	Статус
hostapd / hostapd-wpe	Enterprise Evil Twin, WPA2/WPA3	Новый BSSID с корпоративным SSID, RADIUS accept-all	Активно поддерживается
Fluxion	Автоматизированный captive portal (WPA2 PSK)	Deauth flood + открытая сеть с идентичным SSID + DNS redirect	GitHub, требует проверки статуса
Airgeddon	Evil Twin с поддержкой MANA	Deauth flood, множественные SSID с одного BSSID	Активно поддерживается
Wifiphisher	KARMA + кастомные фишинговые сценарии	Множественные SSID одного MAC, специфичные captive portal шаблоны	Активно поддерживается
WiFi Pineapple (Hak5)	KARMA/MANA в полевых условиях (T1200, Hardware Additions)	Аппаратное устройство, один MAC - десятки SSID	Коммерческий продукт
EAPHammer	Enterprise WPA Evil Twin с захватом хешей	Поддельный RADIUS, MSCHAPv2 challenges	GitHub, активный

Ограничение всех перечисленных инструментов: они требуют Wi-Fi адаптера с поддержкой monitor mode и packet injection. В корпоративном контексте атакующему нужен физический доступ к зоне покрытия или направленная антенна. Удалённая эксплуатация через интернет невозможна - это сценарий внутреннего пентеста, red team и атакующего с физическим присутствием.

Обнаружение Rogue AP: от WIDS до корреляции в SIEM​

WIDS и enterprise-решения​

Wireless Intrusion Detection System - первый рубеж обнаружения. Что конкретно фиксирует грамотно настроенный WIDS:

• Появление нового BSSID с известным корпоративным SSID, не зарегистрированным в inventory AP
• Одновременная активность двух точек доступа с одним SSID на разных каналах или с разными BSSID
• Всплеск deauthentication-фреймов - предшественник Evil Twin в подавляющем большинстве сценариев
• Множественные SSID с одного BSSID - сигнатура KARMA/MANA-атаки

Вендор-специфика: Cisco Adaptive wIPS (интегрирован в WLC) детектирует rogue AP по несовпадению BSSID и мониторит deauth floods, но требует dedicated sensor или переключения AP в monitor mode - а это снижает throughput. Kismet (open source, активно поддерживается) работает как WIDS, записывает все beacon frames и probe responses, но только алертит - не блокирует. Для enterprise-инфраструктуры на оборудовании Aruba или Ruckus - их встроенные WIPS-модули с RF fingerprinting.

Ограничение: если атакующий клонирует и BSSID (MAC-адрес точки доступа), WIDS на основе MAC-сравнения бесполезен. По данным Bitdefender, даже идеальный клон SSID и BSSID не может полностью имитировать радиочастотные характеристики оригинального оборудования: timing-интервалы beacon frames, Clock Skew Analysis и паттерны модуляции позволяют различить Rogue AP. Но это уровень зрелости enterprise WIPS, а не базового open source. На практике я видел такой уровень настройки в двух организациях из пары десятков.

Корреляционные правила для SIEM​

Предусловия: WIDS-алерты должны попадать в SIEM как источник событий. Для MaxPatrol SIEM - настройка коннектора к WLC. Для Elastic SIEM 8.x+ - кастомный парсер WIDS-логов (штатной интеграции нет, придётся писать самим). Для Splunk - Cisco WLC App (только Cisco-инфраструктура).

WIDS-алерты без корреляции - шум. Вот логика корреляционных правил:

# Правило 1: Evil Twin + Deauth (WPA2 без PMF)
IF wids_alert.type == "rogue_ap_detected"
  AND wids_alert.ssid IN corporate_ssid_list
  AND deauth_count(target_bssid, 5min) > 50
  AND new_bssid NOT IN registered_ap_inventory
THEN severity=HIGH, tag="T1557.004_Evil_Twin"

# Правило 2: KARMA/MANA detection
IF count(DISTINCT ssid WHERE src_bssid == X, 10min) > 5
  AND src_bssid NOT IN registered_ap_inventory
THEN severity=CRITICAL, tag="KARMA_MANA_attack"

Третье правило - корреляция с DNS-логами и proxy для обнаружения captive portal фишинга: клиент подключился к неизвестному BSSID (событие WIDS) + в течение 60 секунд DNS-запрос к нехарактерному домену или HTTP-redirect на IP из нелегитимного диапазона. Severity: HIGH, тег: T1056.003.

Это перекликается с OWASP A09:2021 (Security Logging and Monitoring Failures): без корреляции wireless-событий с остальной телеметрией обнаружение атаки невозможно в принципе.

Detection-чеклист: пентест беспроводных сетей глазами SOC​

Готовый чеклист - можно распечатать и повесить в SOC или включить в playbook:

1. Поддерживать актуальный inventory всех легитимных BSSID и SSID. Обновлять при каждом изменении инфраструктуры
2. WIDS - минимум один сенсор на каждый физический этаж или зону. Не отключать при обновлениях, использовать maintenance mode
3. Мониторить deauth floods: порог - более 50 deauth-фреймов за 5 минут от одного BSSID
4. Корреляция WIDS + DNS + proxy: алерт rogue AP + DNS-аномалия в пределах 60 секунд = captive portal фишинг
5. Политикой MDM запретить автоподключение к открытым сетям на корпоративных устройствах
6. Аудит профилей Wi-Fi на endpoints: удалить сохранённые открытые сети (кофейни, отели, аэропорты) - они превращают устройство в мишень для KARMA-атаки
7. PMF (802.11w): включить Protected Management Frames на всех корпоративных AP. Не останавливает Evil Twin полностью, но исключает тривиальный deauth
8. Certificate pinning для Enterprise Wi-Fi: настроить клиенты на проверку сертификата RADIUS-сервера. Без этого EAPHammer-атака захватывает MSCHAP-хеши тихо
9. Ежеквартальный wireless-пентест: не формальный скан, а полноценная Evil Twin-симуляция с captive portal
10. Все wireless-события - в SIEM. Если WIDS-алерты не доходят до SOC - считайте, что WIDS нет

Insider threat: скомпрометированный легитимный хост как Rogue AP​

Сценарий, который чаще всего упускают - и который я считаю самым неприятным. Атакующему не нужно приносить своё оборудование. Скомпрометированный корпоративный ноутбук превращается в Rogue AP программно - через hostapd или встроенную функцию Mobile Hotspot в Windows 10/11, доступную без повышения привилегий.

Проблема для детектирования: WIDS видит новый AP, но MAC-адрес совпадает с зарегистрированным корпоративным устройством. Детект по MAC-сравнению не сработает. Нужна корреляция: появление нового AP + совпадение MAC с endpoint из MDM + отсутствие записи о развёртывании AP в change management + аномальный сетевой трафик с этого хоста.

Это один из худших сценариев: атакующий уже внутри периметра, а Evil Twin служит инструментом lateral movement и сбора дополнительных credentials через беспроводной фишинг. Wireless detection тут пересекается с endpoint detection - EDR на хосте должен фиксировать запуск hostapd или активацию Mobile Hotspot как аномалию. На CrowdStrike Falcon и SentinelOne можно настроить кастомное правило на создание виртуального сетевого адаптера; в Elastic 8.x+ - отслеживать события netsh wlan set hostednetwork через Sysmon.

Ограничения: когда стандартные методы обнаружения Rogue AP не работают​

Ни один метод детектирования не универсален. Вот где стандартные подходы ломаются:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Из всего стека wireless detection меня больше всего настораживает не техническая сложность - она решаемая. Проблема в том, что в большинстве SOC беспроводная безопасность стоит где-то между "мы этим не занимаемся" и "у нас есть WIDS, он вроде работает". На пяти из последних десяти wireless-пентестов WIDS был физически выключен или не интегрирован с SIEM. Корреляционных правил для wireless-событий не было ни в одном из десяти.

При этом развернуть Evil Twin с captive portal - дело пятнадцати минут, а получить первый комплект учётных данных - вопрос получаса.

Wireless threat hunting должен стоять отдельной строкой в чеклисте SOC, а не существовать как подраздел "сетевой безопасности", который де-факто означает только файрволл и сегментацию. Пока wireless-алерты не попадают в ту же консоль, где анализируются логи AD и endpoint-телеметрия, атака Evil Twin на точку доступа остаётся одной из самых дешёвых и результативных точек входа. По свежим кейсам Evil Twin и wireless-инцидентам на codeby.net идёт живое обсуждение - коллеги делятся postmortem'ами и конфигурациями детекта под конкретные SOC-стеки.