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

Как поддельное письмо от «поставщика» увело со счёта компании 640 000 ₽: разбор BEC-атаки

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

Разбор CIOlogia

Владелец небольшой оптовой компании обратился с типовой на первый взгляд проблемой: деньги ушли не туда, и никто не понимает, как это произошло. Сумма — 640 000 ₽, оплата за партию товара, ушедшая на счёт, которого раньше в переписке с этим поставщиком не было.

Механика на входе выглядела банально: бухгалтеру пришло письмо якобы от постоянного контрагента — «сменили реквизиты, оплатите по новым». Стиль письма, подпись, логотип в подвале — всё совпадало с обычной перепиской. Оплата ушла в течение часа. Через три дня настоящий поставщик спросил, где деньги за отгрузку.

Это классическая атака класса BEC (Business Email Compromise), точнее её разновидность VEC (Vendor Email Compromise) — подмена не внутреннего сотрудника, а доверенного контрагента. По статистике FBI IC3, именно BEC/VEC — самая дорогая категория киберпреступлений для бизнеса, обгоняющая по суммарному ущербу шифровальщики. И для неё почти никогда не нужен взлом — нужна только невнимательность получателя и дырявая конфигурация почтового сервера.

Где была техническая дыра

При разборе письма глазами инженера, а не бухгалтера, обнаружились два независимых слоя проблемы.

Слой первый — визуальная подмена домена (typosquatting/homoglyph). Адрес отправителя не совпадал с настоящим доменом поставщика буква в букву: одна латинская буква была заменена на визуально идентичную (например, rn вместо m, кириллическая «а» вместо латинской, или лишний дефис). В потоке из полусотни писем в день такое не считывается глазом.

Слой второй — и он главный — отсутствие проверки подлинности писем на уровне почтового сервера компании. Не были настроены записи SPF, DKIM и DMARC — либо были настроены формально, без строгой политики. Это значит, что технически можно отправить письмо с произвольным полем «From», подделав любого отправителя, включая настоящий домен поставщика без единой опечатки — не только похожий, а буквально идентичный. Получатель в этом случае вообще не увидит разницы.

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

Атака делается в несколько шагов, каждый из которых занимает у злоумышленника от нескольких минут до пары часов и не требует взлома инфраструктуры жертвы.

Шаг 1. Разведка и подбор похожего домена

Злоумышленник генерирует список визуально похожих доменов на реальный домен контрагента:

dnstwist --registered postavshik-example.ru

Fuzzer          Domain                  DNS A              DNS MX
Omission        postavshikexample.ru    -                  -
Homoglyph       pоstavshik-example.ru   185.xx.xx.xx       mail.pоstavshik-example.ru
Insertion       postavshhik-example.ru -                  -
Repetition      postavshiik-example.ru -                  -

Домены с меткой «зарегистрирован» и рабочим MX — это уже потенциальная площадка для рассылки. Часть таких доменов регистрируется заранее, часть — покупается готовыми на теневых форумах вместе с уже прогретой репутацией (SPF/DKIM для нового поддельного домена настроены заранее, чтобы письма не попадали в спам).

Шаг 2. Проверка почтовой защиты жертвы

Перед атакой злоумышленник или готовая платформа-конструктор проверяет, есть ли у компании-жертвы DMARC-политика, которая может завернуть письмо:

dig txt _dmarc.company-target.ru +short

dig txt company-target.ru +short
"v=spf1 include:_spf.mail.example.com ~all"

Пустой ответ по _dmarc или политика p=none — сигнал, что письма от подделанного отправителя будут доставлены без ограничений. Это ровно тот случай, который встречается у большинства малого и среднего бизнеса: SPF есть «для галочки», DMARC не настроен вообще.

Шаг 3. Отправка письма с подделкой заголовков

Для проверки и в реальных атаках используется утилита прямой отправки через SMTP с произвольным полем From — например, swaks:

swaks --to buh@target-company.ru \
      --from "Иван Петров " \
      --header "Subject: Смена реквизитов для оплаты" \
      --body "Добрый день! Реквизиты изменились, актуальный счёт во вложении." \
      --attach счет_новый.pdf \
      --server smtp-relay.rented-vps.com

=== Trying smtp-relay.rented-vps.com:25...
=== Connected to smtp-relay.rented-vps.com.
<-  220 relay ready
 -> MAIL FROM:<бухгалтерия@postavshik-example.ru>
<-  250 OK
 -> RCPT TO:
<-  250 OK
 -> DATA
<-  354 Go ahead
 -> ... message data ...
<-  250 Queued

Если у получателя нет строгого SPF/DKIM/DMARC-контроля, сервер примет и доставит это письмо как обычное — ровно так, как и произошло в разобранном случае.

Шаг 4. Готовые платформы вместо ручной сборки

Именно про это писал источник новости: в теневых Telegram-каналах продаются готовые платформы для массового спуфинга — конструктор с шаблонами известных брендов, панелью для рассылки на тысячи адресов и встроенной проверкой «дойдёт письмо или нет» по SPF/DKIM целевого домена. Раньше это делали вручную через sendmail/swaks/самописные скрипты — теперь это SaaS с техподдержкой в чате, оплатой в криптовалюте и обновляемой базой доменов, у которых слабая почтовая защита.

Полутехнические пруфы: как это выглядит в заголовках письма

В разобранном кейсе анализ заголовков (Received, Return-Path, Authentication-Results) показал типичную для спуфинга картину:

Authentication-Results: mx.target-company.ru;
    spf=none (sender domain does not designate permitted sender hosts)
    smtp.mailfrom=postavshik-example.ru;
    dkim=none (message not signed);
    dmarc=none action=none header.from=postavshik-example.ru

Return-Path: <бухгалтерия@postavshik-example.ru>
Received: from mail-relay-185-xx-xx-xx.rented-vps.com
    by mx.target-company.ru with ESMTP

Три ключевых красных флага в одной картине: spf=none, dkim=none, dmarc=none. Ни одна из трёх проверок подлинности не прошла — но письмо всё равно попало во входящие, потому что сервер получателя не был настроен на строгую обработку таких результатов.

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

Если бы инцидент не был замечен через три дня, а бухгалтер продолжила бы работать с «новыми реквизитами», злоумышленник почти наверняка продолжил бы эксплуатацию канала:

  • Повторная атака на большую сумму. В компании были счета на закупку сырья на 2–3 млн ₽ — ровно такие суммы обычно и становятся целью второй волны, когда первая проходит незамеченной.
  • Расширение на другие роли. Тот же приём с подменой домена сработал бы и от имени директора — письмо в бухгалтерию «срочно оплатить, я на встрече, перезвонить не могу» — классический сценарий CEO Fraud.
  • Компрометация переписки. Если бы бухгалтер ответила на письмо с вопросом, а на поддельном домене был настроен автоответ или живой оператор, злоумышленник мог бы затянуть диалог, снять любые сомнения и получить дополнительные данные — ИНН, банк, контактных лиц — для следующих атак на других контрагентов компании.
  • Использование украденной легенды для фишинга сотрудников. Тот же поддельный домен поставщика хорош и для рассылки вредоносных вложений внутри компании — под видом «актов сверки» или «спецификаций».

Как закрыть эту дыру

Работа заняла два дня и не требовала закупки оборудования — только конфигурация почтового сервера и организационные правила.

1. Настройка SPF — кто имеет право отправлять от имени домена

; TXT-запись домена
company.ru.  TXT  "v=spf1 include:_spf.mail-provider.ru ip4:203.0.113.10 -all"

Важно: механизм -all (жёсткий отказ), а не ~all (мягкий, «подозрительно, но пропустить»).

2. Включение DKIM-подписи исходящих писем

; проверка публичного ключа DKIM
dig txt selector1._domainkey.company.ru +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

3. Строгая политика DMARC

_dmarc.company.ru.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@company.ru; ruf=mailto:dmarc-forensic@company.ru; pct=100; adkim=s; aspf=s"

Политику стоит внедрять поэтапно: сначала p=none с обязательным сбором отчётов (rua) в течение 2–3 недель, чтобы не сломать легитимную рассылку, затем p=quarantine, и только потом p=reject.

4. Правило для входящих писем с похожих доменов

На стороне почтового сервера/шлюза (Exchange Online, Postfix + rspamd, любой корпоративный антиспам) настраивается правило пометки писем, где домен отправителя отличается от известных контрагентов на 1–2 символа — визуально жёлтая плашка «Внешний отправитель, похожий на известный домен, проверьте адрес». В экосистеме Microsoft 365 это делается через Anti-phishing policy с включённым импersonation protection на конкретные домены поставщиков.

5. Организационное правило: смена реквизитов — только голосом

Никакие изменения банковских реквизитов не принимаются по письму без подтверждающего звонка на заранее известный, а не указанный в этом же письме номер. Это самое дешёвое и самое эффективное правило против всей категории BEC/VEC-атак — оно не требует технологий вообще.

6. Мониторинг попыток подмены собственного домена компании

Отдельно стоит настроить получение DMARC-отчётов (rua) и разбирать их — они показывают, кто и с каких IP пытается отправлять письма от имени домена компании, то есть попытки атаковать уже её собственных контрагентов под видом директора или бухгалтерии.

7. Обучение на реальных примерах

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

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