← Все разборы Информационная безопасность

BEC-атака на 640 000 ₽: как поддельное письмо «от директора» чуть не прошло мимо всех проверок

Технический разбор реального кейса: почему спуфинг e-mail до сих пор проходит через 80% почтовых серверов малого и среднего бизнеса, и как три DNS-записи закрывают дыру за один рабочий день.

15 июля 2026 г. Разбор CIOlogia

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

При разборе выяснилось: почтовый ящик директора не взломан. Письмо пришло с чужого SMTP-сервера, который просто подставил в поле «От» адрес директора компании. Технически это классический email spoofing, а инфраструктура компании была устроена так, что подделку никто не проверял и не блокировал.

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

Схема BEC (Business Email Compromise) через spoofing не требует взлома почты жертвы вообще — атакующему достаточно, чтобы у домена компании отсутствовали или были неправильно настроены механизмы проверки отправителя. Разберём шаги, которые проходит атакующий.

Шаг 1. Разведка домена

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

dig txt company.ru +short
"v=spf1 include:_spf.google.com ~all"

dig txt _dmarc.company.ru +short
;; ответ пустой — записи нет

dig txt selector1._domainkey.company.ru +short
;; ответ пустой — DKIM не настроен

Ключевой момент здесь — политика SPF ~all (softfail) вместо -all (hardfail), и полное отсутствие DMARC-записи. Это значит: даже если получатель проверит SPF и увидит несовпадение, письмо не будет отклонено — максимум помечено как подозрительное, да и то не всегда, если принимающий сервер вообще смотрит на этот заголовок.

Шаг 2. Проверка возможности отправки от чужого имени

Дальше атакующий проверяет, пройдёт ли поддельное письмо технически. Для этого используется инструмент swaks — стандартный SMTP-тестер, который легально применяется пентестерами и точно так же — мошенниками.

swaks --to buhgalter@company.ru \
      --from "Иванов Иван Иванович " \
      --header "Subject: Срочно! Оплата новому поставщику" \
      --body "Прошу срочно перевести 640000 руб. по реквизитам во вложении" \
      --server smtp.attacker-relay.com --port 25

=== Trying smtp.attacker-relay.com:25...
=== Connected to smtp.attacker-relay.com.
<-  220 relay ESMTP ready
 -> EHLO test
<-  250-relay Hello
 -> MAIL FROM:
<-  250 OK
 -> RCPT TO:
<-  250 OK
 -> DATA
<-  354 Go ahead
 -> ... письмо отправлено ...
<-  250 Message accepted

Обратите внимание: сервер-релей принял MAIL FROM с чужим доменом без каких-либо проверок — потому что открытые или слабо настроенные SMTP-релеи (в том числе специально арендуемые в даркнете «спуф-панели») этим и торгуют. Стоимость такого сервиса на теневых форумах — от 15 до 50 долларов за подписку с готовым веб-интерфейсом: вставляешь «от кого», «кому», текст — получаешь письмо с любым Return-Path.

Шаг 3. Социальная инженерия в теле письма

Дальше в дело идёт не техника, а сценарий: срочность, ссылка на реального контрагента компании (имя которого легко взять из открытых источников — сайта, тендерной площадки, соцсетей), просьба «оплатить сейчас, я на встрече, не могу говорить». Часто копируется реальная подпись директора из его прошлых писем, если переписка утекала ранее или бралась из открытого LinkedIn/VK-профиля.

Полутехнические пруфы

Если открыть заголовки такого письма (в Gmail — «Показать оригинал», в других клиентах — «view source»), видно расхождение между тем, что показано пользователю, и тем, что реально произошло на уровне протокола:

Return-Path: 
Received: from mail.attacker-relay.com (185.220.xxx.xxx)
    by mx.company.ru with SMTP id 7f3a...
Authentication-Results: mx.company.ru;
    spf=softfail (domain owner discourages use of this host) smtp.mailfrom=company.ru;
    dkim=none (message not signed);
    dmarc=none (p=none)

Три строки в Authentication-Results — это и есть диагноз. spf=softfail означает, что письмо пришло не с разрешённого IP, но политика домена не запрещает его доставку. dkim=none — цифровая подпись письма отсутствует в принципе, значит подтвердить целостность и подлинность нечем. dmarc=none — самое важное: нет правила, что делать с письмами, которые провалили проверки, поэтому почтовый сервер компании просто доставил письмо во «Входящие» как обычное.

В логах почтового сервера компании (Postfix/Exim/Exchange) такие попытки выглядят характерно — resolving IP отправителя не принадлежит диапазону, заявленному в SPF-записи домена, и обычно повторяется пачками в течение короткого времени, если атака автоматизирована:

Oct 03 09:14:02 mx postfix/smtpd[22841]: NOQUEUE: reject: RCPT from unknown[185.220.xxx.xxx]:
  554 5.7.1 Sender address rejected: Domain not permitted to send from this IP;
  from= to=

Именно такую строчку «reject» и должен выдавать сервер после включения строгой политики — до настройки в логах компании была тишина: письма просто проходили.

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

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

Деньги уходят на счёт «нового поставщика» — обычно это счёт дропа, который обналичивается в течение 2-4 часов после зачисления, что делает возврат через банк технически возможным только в первые минуты после платежа.
Атакующий, видя, что схема сработала, повторяет её через 2-3 недели — уже от имени «постоянного поставщика» с письмом о смене реквизитов (ещё более правдоподобный вариант, потому что такие письма компании действительно получают регулярно).
Параллельно может использоваться перехват реальной деловой переписки — если ранее была скомпрометирована почта одного из контрагентов (не обязательно самой компании), атакующий видит реальные суммы, сроки и стиль общения, что делает поддельные письма ещё точнее.
При отсутствии DMARC у компании нет и отчётов (aggregate reports), поэтому она даже не узнаёт, сколько раз её домен уже использовался для рассылки поддельных писем другим — партнёрам, клиентам, банку.

Как закрыли дыру

Решение полностью укладывается в стандарт email-аутентификации, который существует больше десяти лет, но в малом и среднем бизнесе почти никогда не включён до первого инцидента.

1. SPF — список серверов, которым разрешено отправлять письма от имени домена

; DNS TXT-запись для company.ru
v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

Ключевое отличие от того, что было — механизм -all (hardfail) вместо ~all. Это прямое указание принимающим серверам: письма не из перечисленных источников должны отклоняться, а не просто помечаться.

2. DKIM — цифровая подпись каждого письма

# Postfix + OpenDKIM, генерация ключа
opendkim-genkey -s selector1 -d company.ru
cat selector1.txt
selector1._domainkey.company.ru IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Публичный ключ публикуется в DNS, приватный подписывает исходящие письма на сервере. Теперь любое письмо от company.ru либо подписано корректно, либо подпись отсутствует/не совпадает — и это видно принимающей стороне.

3. DMARC — политика «что делать с письмами, провалившими проверки»

_dmarc.company.ru IN TXT
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@company.ru; pct=100"

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

Дополнительно к DNS-записям было сделано:

Настроена автоматическая маркировка писем с dmarc=fail красным флагом прямо в почтовом клиенте — визуальный сигнал для сотрудников до открытия письма.
Введено короткое правило: любой платёж по «срочному» письму от директора, поставщика или в обход обычного порядка согласования подтверждается звонком на уже известный номер, а не тот, что указан в письме.
Настроено уведомление директору в мессенджер при каждой попытке отправки писем от его имени, не прошедшей DMARC-проверку, — это даёт видимость атак ещё до того, как они дойдут до сотрудников.

Дыра, из-за которой компания чуть не потеряла 640 000 ₽, закрывалась тремя DNS-записями и правкой конфига почтового сервера — на всё ушло меньше рабочего дня.

Важный нюанс: SPF, DKIM и DMARC не защищают от компрометации самого ящика директора (взлом пароля, фишинг с кражей сессии) — это другой класс атак с другими методами защиты (MFA, мониторинг входов, EDR на рабочих станциях). Но именно спуфинг — самый дешёвый и массовый инструмент для BEC-схем, потому что не требует ни взлома, ни доступа к инфраструктуре жертвы, только знания её домена и того факта, что защита не включена.