BEC-3.0: как жулики подменяют банковские реквизиты в переписке с поставщиком

Ваш поставщик прислал счёт. Вы обсудили детали — три письма туда-обратно. Пятое письмо приходит от того же адресата с тем же именем: «Мы сменили банк, вот новые реквизиты». Вы платите. Реквизиты не поставщика — жуликов, которые получили доступ к его ящику неделю назад и молча читали переписку, дожидаясь момента.

Почему BEC — самая опасная категория email-атак 2025-2026

Стандартный фишинг ловится хотя бы иногда: «Претензия.zip» от незнакомого адреса вызывает подозрение. BEC-3.0 ломает эту эвристику полностью:

• Отправитель — не незнакомый, а именно тот с кем вы переписываетесь неделями.
• Тема письма — не «Срочно откройте», а продолжение обсуждения: «Re: Оплата по договору №247».
• Стиль — тот же, потому что жулик читал последние 20 писем и научился имитировать.
• Никаких подозрительных вложений — просто текст «мы сменили банк».
• SPF/DKIM/DMARC часто в порядке, потому что письмо реально идёт с реального ящика реального поставщика.

По данным Proofpoint, поведенческий анализ (не сигнатуры) сейчас блокирует ~19 миллионов BEC/фишинг-попыток в месяц у их клиентов. Абсолютное большинство — именно продолжения существующих переписок.

Три сценария BEC-3.0

Сценарий 1: реальный взлом ящика поставщика

Наиболее опасный. Жулики получают доступ к почте вашего контрагента через: слитый пароль (в компрометации базы данных стороннего сервиса), фишинг менеджера, брутфорс без rate-limit. Дальше:

1. Тихо сидят в inbox неделями, читая переписку, изучая шаблоны, обороты, стиль.
2. Отслеживают тред где обсуждается оплата ≥ 1 млн ₽.
3. В нужный момент — отправляют письмо изнутри взломанного ящика с новыми реквизитами.
4. Настраивают правило «удалять входящие с определённым subject» — чтобы владелец ящика не увидел ваш ответ «спасибо, оплачу по новым реквизитам».

Ловится: sender-домен ТОТ ЖЕ, но письмо отправлено с необычного IP (например, из другой страны), в необычное время, необычный User-Agent клиента. Мы отдельно смотрим на это сигнальное окружение — но 100% гарантии от такой атаки не даёт ни один автоматический фильтр. Единственная надёжная защита — процесс.

Сценарий 2: typosquat-домен

Более простой в исполнении. Жулики регистрируют домен, визуально почти неотличимый от домена поставщика:

• romashka.ru → romaska.ru (без «h»)
• romashka.ru → romashka.co (другой TLD)
• romashka.ru → rornashka.ru («rn» вместо «m»)
• romashka.ru → rоmashka.ru (кириллическая «о» вместо латинской — homoglyph)

Отправляют письмо, притворяющееся ответом в треде. Заголовки In-Reply-To и References копируют из легитимной цепочки (получают эту информацию заранее).

Ловится проще: sender-домен отличается от исторических в этом же треде. Плюс homoglyph/typosquat-детекторы.

Сценарий 3: display-name spoofing

Самый примитивный. Атакующий отправляет с любого случайного адреса (например, rand12@gmail.com), но в поле From ставит имя вашего контрагента: "Иван Петров, Ромашка" <rand12@gmail.com>. Многие почтовые клиенты показывают только display-name «Иван Петров, Ромашка», а сам адрес прячут.

Ловится: display-name матчится с известным контактом, а envelope-домен — незнакомый.

Реальные кейсы 2024-2025

Как защититься — процесс важнее технологий

1. Правило «смена реквизитов — только по устному подтверждению»

Самая надёжная защита. Пропишите в регламенте бухгалтерии:

Любое изменение банковских реквизитов контрагента, полученное по email, подтверждается устно по телефону на номер, взятый ИЗ ДОГОВОРА (не из подписи письма). Если устного подтверждения нет — платить по старым реквизитам, сообщить контрагенту о попытке подмены.

Это работает против всех трёх сценариев выше, включая взлом реального ящика.

2. Отдельный контроль на суммы от N ₽

Для платежей выше порога (например, 500 тыс ₽) — обязательное согласование двух подписантов, из которых один звонит контрагенту напрямую. Административные меры дешевле любых фильтров.

3. Технический детектор смены sender-домена в треде

Автоматически: для каждого треда (Message-ID из References) храним историю sender-доменов. Если приходит письмо в существующий тред с домена, которого в этом треде ещё не было, — предупреждение. Если при этом display-name совпадает с историческим — блокировка/сильный алёрт (это уже почти гарантированный typosquat).

Мы реализовали это в 2333.ru как отдельный сигнал «THREAD-HIJACK». В логах фильтра вы увидите:

ADV-PHISHING score=4 THREAD-HIJACK: display='Иван Петров, Ромашка'
same, но домен новый (romaska.ru vs [romashka.ru, romashka.moscow])

4. Homoglyph/typosquat-детектор

При регистрации нового контакта — проверять Levenshtein-дистанцию до известных доменов. romaska.ru в одну букву от romashka.ru — подозрение. rоmashka.ru с кириллической «о» — mixed-script, автоматический алёрт.

5. Аудит правил переадресации во взломанных ящиках

Если сотрудник жалуется что «не получил ваш ответ», проверьте правила автоматической переадресации/удаления в его ящике. Атакующие часто создают правило «Если From содержит [ваш адрес] — удалить» — так они скрывают от жертвы ваши сомнения.

6. MFA/2FA на всех почтовых ящиках

Банальность, но 80% BEC начинаются с брутфорса паролей ящиков без MFA. Обязательно на всех: у поставщиков, у себя, у бухгалтерии, у топ-менеджмента.

Что делать, если попались

1. Сразу — банк. В первые 24 часа шансы вернуть перевод существенно выше. Заявление на chargeback, справка о мошенничестве.
2. Заявление в полицию + Роскомнадзор (по факту фишинга).
3. Уведомить контрагента: их ящик взломан, они об этом могут не знать.
4. Аудит своих ящиков: возможно, взломали не только их, но и вашего сотрудника.
5. Смена всех паролей, включая почтовые API-ключи и токены SMTP.
6. Разбор постмортема: где точно сломался процесс. Обычно оказывается что регламент был, но менеджер поспешил.