На wireless-аудите финтех-компании мы начали с парковки перед офисом. Alfa AWUS036ACH в monitor mode, Kismet с GPS-модулем, ноутбук на пассажирском сидении - стандартный набор для пассивной разведки. За 12 минут сбора без единого отправленного пакета: 47 BSSID, три "скрытых" сети (имена раскрылись через probe request корпоративных ноутбуков), два AP с WPA2-Personal рядом с зоной WPA2-Enterprise, принтер с открытой точкой доступа. SOC заказчика не зафиксировал ни одного алерта - WIDS не был развёрнут, а IDS на проводном сегменте не видит то, что происходит в радиоэфире. Ниже - разбор инструментов и методов беспроводной разведки Wi-Fi сетей и того, что из этого может и должен ловить SOC.
Зачем атакующему пассивная разведка беспроводных сетей
Беспроводная разведка Wi-Fi сетей - первый этап перед атакой на wireless-инфраструктуру. В kill chain это reconnaissance, предшествующий initial access. Атакующий решает три задачи:- Картирование инфраструктуры - количество точек доступа, BSSID, каналы, мощность сигнала, тип шифрования (WPA2-Personal / Enterprise / WPA3).
- Поиск слабых звеньев - AP с WPA2-Personal в корпоративном сегменте, WEP на IoT-устройствах (да, встречается в гостевых и промышленных зонах до сих пор), незащищённые точки доступа для принтеров и конференц-систем.
- Сбор метаданных клиентов - MAC-адреса устройств, probe request с именами сохранённых сетей, vendor OUI, паттерны активности.
По данным IBM X-Force Threat Intelligence Index 2025, 70% атак затронули критическую инфраструктуру. Беспроводные сети в корпоративных офисах - удобный начальный вектор: атакующий проводит RF-разведку инфраструктуры с парковки, затем разворачивает Evil Twin или перехватывает WPA2 handshake. И всё это до момента появления в логах проводного сегмента. Отдельная головная боль - инсайдер: сотрудник, развернувший личный AP ("теневую" точку доступа) для удобства, создаёт незащищённый мост в корпоративную сеть. Обнаруживается такое только при wireless-аудите.
Инструменты сканирования Wi-Fi инфраструктуры
Требования к окружению
Для воспроизведения пассивной разведки (в рамках авторизованного пентеста беспроводных сетей или проверки видимости собственной инфраструктуры):- ОС: Kali Linux 2024.x+ или Parrot OS (Debian/Ubuntu с установленным aircrack-ng suite)
- RAM: от 4 ГБ (для Kismet с веб-интерфейсом - 8 ГБ)
- Wi-Fi адаптер с поддержкой monitor mode: Alfa AWUS036ACH (чипсет RTL8812AU), Alfa AWUS036AXML (MT7921AU), TP-Link Archer T3U Plus (RTL8812BU)
- GPS для wardriving: USB GPS-приёмник, совместимый с gpsd (u-blox 7/8)
- Драйверы: для RTL8812AU на ядрах 6.x+ стоковый драйвер не поддерживает monitor mode - нужна сборка из
aircrack-ng/rtl8812au(GitHub - aircrack-ng/rtl8812au: RTL8812AU/21AU and RTL8814AU driver with monitor mode and frame injection) - Сеть: не требуется, работа полностью offline
Monitor mode беспроводного адаптера: настройка и верификация
Monitor mode - режим, при котором беспроводной адаптер принимает все 802.11-фреймы на заданном канале: management (beacon, probe request/response, deauthentication), control и data. Без monitor mode адаптер показывает только сети, к которым может ассоциироваться. Разница между тем, что выдаётiwlist wlan0 scan, и реальной картиной эфира - как между замочной скважиной и панорамным окном.Переключение через airmon-ng:
sudo airmon-ng check kill && sudo airmon-ng start wlan0. Первая команда завершает процессы, конфликтующие с monitor mode (NetworkManager, wpa_supplicant). После выполнения появляется интерфейс wlan0mon.Верификация: команда
iw dev - в поле type должно стоять monitor. Дополнительная проверка: sudo tcpdump -i wlan0mon -c 5 -e - если в выводе видны 802.11 beacon-фреймы с полями BSSID и SSID, режим работает. Если iw dev показывает type managed после airmon-ng start - драйвер не поддерживает monitor mode или менеджер сети перехватил интерфейс обратно.Типичная проблема на ядрах 6.x+ с RTL8812AU. Стоковый модуль
88XXau из ядра не поддерживает monitor mode. Решение:
Bash:
git clone https://github.com/aircrack-ng/rtl8812au.git
cd rtl8812au && sudo make dkms_install
sudo modprobe 88XXauairmon-ng start wlan0. Если airmon-ng не создаёт wlan0mon, ручной вариант: sudo iw phy phy0 interface add wlan0mon type monitor. На ядрах 6.8+ возможны ошибки компиляции - проверяйте issues в репозитории для конкретной версии.[Применимо: внешний пентест (с парковки, из соседнего помещения), внутренний пентест, аудит собственной инфраструктуры]
Airodump-ng: пассивная разведка точек доступа
Airodump-ng - часть aircrack-ng suite (GitHub: 5.5k+ звёзд, репозиторий активно поддерживается). Основной инструмент для быстрого пассивного сканирования Wi-Fi инфраструктуры. Запустил - и через минуту видишь полную картину эфира.Базовый запуск:
sudo airodump-ng wlan0mon - сканирование каналов 2.4 ГГц. Для обоих диапазонов: sudo airodump-ng --band abg wlan0mon. Целенаправленный захват конкретной AP с записью: sudo airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w capture wlan0mon.Что видно в верхней секции вывода (обнаруженные точки доступа):
- BSSID - MAC точки доступа
- PWR - мощность сигнала в dBm: -30 означает «рядом», -70 - через стену, -85 и хуже - граница приёма
- CH - канал (1-13 для 2.4 ГГц, 36-165 для 5 ГГц)
- ENC/CIPHER/AUTH - тип шифрования. Красные флаги для атакующего: WEP, OPN (открытая сеть), WPA2-Personal с CCMP (потенциальный offline-брутфорс)
- ESSID - имя сети. Для скрытых AP отображается
<length: N>- длина SSID видна из beacon, но само имя скрыто
- STATION - MAC клиентского устройства
- Probes - имена сетей, которые клиент ищет через probe request. Именно здесь раскрываются имена "скрытых" сетей
Ограничения airodump-ng: нет встроенной GPS-интеграции для wardriving, нет REST API для автоматизации, нет исторической базы обнаруженных устройств. Для wardriving с GPS-картированием сетей и долгосрочного мониторинга нужен Kismet.
Kismet - беспроводной сканер с REST API и GPS
Kismet (GitHub: 4k+ звёзд, активно поддерживается Mike Kershaw / dragorn) - фреймворк пассивного мониторинга с веб-интерфейсом, REST API, GPS-интеграцией и встроенными алертами для обнаружения аномалий. Если airodump-ng - это бинокль, то Kismet - полноценная станция радиоразведки с архивом и автоматикой. В отличие от airodump-ng, Kismet работает как полноценный WIDS.Запуск:
sudo kismet -c wlan0mon. Веб-интерфейс поднимается на http://localhost:2501 - при первом запуске создаётся аккаунт, credentials сохраняются в ~/.kismet/kismet_httpd.conf.GPS-интеграция для wardriving. В файле
/etc/kismet/kismet_site.conf (пользовательские переопределения, не правьте kismet.conf напрямую) добавьте строку gps=gpsd:host=localhost,port=2947. Перед запуском убедитесь, что gpsd работает: sudo gpsd /dev/ttyUSB0 && gpsmon - в gpsmon должны отображаться координаты. Kismet привязывает каждое обнаруженное устройство к GPS-координатам - на выходе получается карта беспроводной инфраструктуры с точностью до здания.REST API для автоматизации сбора. Kismet предоставляет JSON API для программного доступа ко всем собранным данным:
Bash:
# Все обнаруженные Wi-Fi точки доступа
curl -s -u admin:password \
'http://localhost:2501/devices/views/phydot11_accesspoints/devices.json'
# Устройства по конкретному MAC-адресу
curl -s -u admin:password \
'http://localhost:2501/devices/by-mac/AA:BB:CC:DD:EE:FF/devices.json'.kismet), пригодную для постфактум-анализа.Kismet как WIDS. Kismet детектирует аномалии в эфире: появление AP с дублирующим SSID (индикатор Evil Twin), всплески deauthentication-фреймов, смену канала AP, нетипичные beacon-интервалы. Алерты доступны через REST API и веб-интерфейс - при правильной настройке их можно пробросить в SIEM через syslog.
Ограничения Kismet: аппетит к ресурсам заметно выше, чем у airodump-ng. При >200 устройствах в эфире и включённом веб-интерфейсе на машинах с 4 ГБ RAM начинаются тормоза. REST API использует HTTP Basic Auth без поддержки токенов - при удалённом доступе обязательна TLS-обёртка через nginx reverse proxy.
Чем airodump-ng отличается от Kismet
| Критерий | airodump-ng | Kismet |
|---|---|---|
| Тип | CLI-утилита | Фреймворк с веб-UI |
| GPS-интеграция | Нет (сторонние скрипты) | Нативно через gpsd |
| REST API | Нет | Да, JSON |
| Историческая база | Нет (только pcap-файлы) | SQLite с полной историей |
| Встроенный WIDS | Нет | Да (Evil Twin, deauth flood) |
| Потребление RAM | 50-100 МБ | 200-500 МБ |
| Когда использовать | Быстрый скан, захват handshake | Wardriving, мониторинг, WIDS |
| Когда НЕ использовать | Длительный мониторинг | Одноразовый скан, low-end hardware |
Для Blue Team: если задача - разовая проверка видимости инфраструктуры с периметра, хватит airodump-ng. Нужен постоянный мониторинг RF-обстановки или open-source WIDS - Kismet. Для глубокого анализа отдельных beacon-фреймов и probe request/response - Wireshark с фильтром
wlan.fc.type_subtype == 0x08 (beacon) или wlan.fc.type_subtype == 0x04 (probe request).Обнаружение скрытых Wi-Fi сетей: почему hidden SSID не защищает
"Скрытая" сеть - это AP, у которой в beacon-фреймах поле SSID пустое или заполнено нулями. Стандарт 802.11 требует от AP отправлять beacon каждые ~100 мс, но не обязывает включать имя сети. Идея: если клиент не знает имя - подключиться не сможет.
Идея красивая. Реализация - нет. Обнаружение скрытых Wi-Fi сетей - тривиальная задача. Согласно описанию AcrylicWifi и документации Arista, раскрытие скрытого SSID происходит в двух случаях:
- Клиент отправляет probe request с именем сохранённой сети. Устройство, "помнящее" скрытую сеть, периодически рассылает probe request с её SSID - даже за пределами покрытия. Airodump-ng и Kismet в monitor mode перехватывают эти фреймы и подставляют имя в вывод.
- AP отвечает probe response с SSID при ассоциации клиента. При подключении нового устройства AP подтверждает имя сети в probe response - его перехватывает любой сниффер в monitor mode.
[Применимо: любая инфраструктура с hidden SSID, внешний и внутренний пентест]
Detection для SOC: как поймать 802.11 разведку сети
Пассивная разведка по определению не генерирует трафика - атакующий только принимает фреймы. Поймать сам факт прослушивания невозможно. Но SOC может детектировать переход к активным действиям и косвенные индикаторы.Индикаторы беспроводной разведки на уровне WIDS
Корпоративные WLC (Cisco WLC, Aruba Central, Ruckus SmartZone) имеют встроенные WIDS-модули, фиксирующие:- Rogue AP - появление AP с BSSID, не входящим в управляемый список. Индикатор Evil Twin, несанкционированной точки доступа или теневого AP от инсайдера. Для Cisco WLC: алерт
ROGUE_AP_DETECTED. Для Aruba: event ID в IDS profile. - SSID spoofing - AP с корпоративным SSID и неизвестным BSSID. Прямой индикатор Evil Twin-атаки, следующей за разведкой.
- Deauthentication flood - массовые deauth-фреймы. Атакующий использует
aireplay-ng --deauthдля принудительного отключения клиентов и захвата WPA handshake. Для Cisco WLC:AP_DEAUTH_ATTACK,IDS_SIGNATURE_MATCH. - Excessive probe response - аномальное количество probe response от AP на запросы с нетипичных MAC-адресов.
Sigma-правило для анализа беспроводного трафика в SIEM
После настройки forwarding WIDS-логов можно строить правила корреляции. Пример Sigma-правила для обнаружения deauth-атаки - активной фазы, которая обычно следует за пассивной разведкой:
YAML:
title: WIDS - Deauth Flood Detected
status: experimental
logsource:
product: wlc
service: syslog
detection:
selection:
message|contains|any:
- 'Deauthentication flood'
- 'deauth attack'
- 'DoS attack detected'
condition: selection | count() > 3
timeframe: 5m
level: highselection под syslog message ID. Для Aruba - под event ID из IDS profile. Для open-source WIDS (Kismet) - под формат алертов REST API.Корреляция с проводным сегментом. Если WIDS фиксирует rogue AP, а через 5-15 минут на коммутаторе в том же VLAN появляется новый MAC-адрес - это потенциальный индикатор успешной Evil Twin-атаки. Правило корреляции по временным окнам между wireless-алертами и логами свитчей (802.1X, MAC authentication) серьёзно повышает точность. Для Elastic 8.x+ это реализуется через EQL sequence, для MaxPatrol SIEM - через цепочку корреляций с временным окном.
Ограничение detection. Пассивная разведка (только приём фреймов) не детектируется никаким WIDS - атакующий ничего не передаёт. Обнаружить можно только переход к активным действиям: deauth flood, Evil Twin, probe injection. Поэтому hardening инфраструктуры - единственная защита от пассивного сбора данных.
Hardening-чеклист для беспроводной инфраструктуры
Нумерованный список действий для передачи сетевой команде или включения в отчёт по аудиту. Каждый пункт - конкретное действие с командой верификации.За последние пару лет wireless-аудитов я вижу одну и ту же картину: SOC мониторит проводной сегмент зрело - EDR (CrowdStrike Falcon, Kaspersky EDR Expert), SIEM (MaxPatrol SIEM, Elastic 8.x+, KUMA), NDR - а радиоэфир остаётся слепой зоной. WIDS развёрнут у единиц, и чаще сводится к rogue AP detection на WLC без forwarding в SIEM. Probe request storms, Evil Twin с корпоративным SSID, deauth flood - всё проходит мимо SOC-дашбордов, пока не станет инцидентом на проводном сегменте.
Причина простая: wireless security воспринимается как задача сетевиков, а не SOC. Сетевая команда настраивает WPA2-Enterprise и считает дело закрытым. SOC-аналитики не получают wireless-алерты и не знают, как с ними работать. В итоге атакующий с Alfa-адаптером на парковке собирает полную карту инфраструктуры за четверть часа, а SOC в это время разгребает алерты из проводного сегмента.
Если у вас есть хотя бы один корпоративный Wi-Fi AP - вам нужен WIDS с forwarding алертов в SIEM. Не в планах на следующий квартал, а в текущем спринте. Запустите
airodump-ng с парковки собственного офиса - первые 15 минут покажут, что видит атакующий. Если интересно, как другие SOC-команды выстраивают wireless detection и какие конфигурации WIDS реально работают в проде - обсуждение ведётся в тематическом треде на codeby.net.
Последнее редактирование модератором:
