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

Атака «директор в WhatsApp»: разбор мошеннической схемы на 4,2 млн рублей с техническими деталями

Разбираем по шагам, как злоумышленники готовят и проводят BEC-атаку через мессенджер: от OSINT-разведки и клонирования профиля до deepfake-голоса — и что реально останавливает такие переводы, кроме здравого смысла.

5 сентября 2026 г. Разбор CIOlogia

Короткая версия истории уже разошлась: главбух получила сообщение «от директора» с требованием срочно и тайно перевести 4,2 млн рублей за «конфиденциальную сделку». Перевод не ушёл только из-за случайного технического сбоя в банке. Это классическая схема CEO Fraud (Business Email/Messenger Compromise), которая последние два года массово мигрировала из корпоративной почты в мессенджеры — WhatsApp, Telegram, VK Teams. Разберём, как именно такие атаки готовятся технически, почему они обходят «здравый смысл» сотрудников и что реально закрывает эту дыру.

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

Схема выглядит как «просто написали в чат», но за ней обычно стоит от нескольких часов до нескольких дней подготовки. Разложим по шагам.

Шаг 1. OSINT — сбор данных о жертве и руководителе

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

# Сбор публичных данных о компании и сотрудниках
theHarvester -d company-domain.ru -b google,linkedin,vk -l 200

# Поиск профилей руководителя по нику/имени в соцсетях
sherlock "ivan_petrov_director"

# Извлечение метаданных из открытого фото профиля (иногда там остаются GPS/дата съёмки)
exiftool director_photo.jpg

Из корпоративного сайта, VK, отраслевых конференций и старых постов в общих чатах поставщиков собирается стиль общения директора: короткие фразы, характерные сокращения, любимые эмодзи. Этого достаточно, чтобы имитировать «голос» в переписке — техника не сложнее копирайтинга.

Шаг 2. Подготовка «фейкового» номера и профиля WhatsApp

Дальше нужен номер, который выглядит правдоподобно: похожий код региона, отсутствие истории в спам-базах. Такие номера покупаются пачками через сервисы виртуальных SIM/VoIP-активации, либо используется классический SIM-своп через оператора (тут в ход идут утечки паспортных баз и социальная инженерия против саппорта оператора).

# Проверка номера на "чистоту" перед использованием
curl "https://api.numlookupapi.com/v1/validate/+7XXXXXXXXXX?apikey=API_KEY"

# Ответ обычно содержит carrier, line_type, country — 
# мошенники отсеивают номера, которые уже засвечены как VoIP/спам

Фото профиля берётся из шага 1 и просто загружается в WhatsApp/Telegram — никакого взлома аккаунта директора чаще всего не требуется. Отдельно фиксируем: в части похожих кейсов используется угон реальной WhatsApp-сессии через клонирование QR-кода (техника, знакомая по инструментам вроде whatsapp-web.js и по нашумевшим уязвимостям типа CVE-2019-3568 — переполнение буфера в VOIP-стеке WhatsApp, эксплуатировавшееся для установки шпионского ПО через один пропущенный звонок). Но для банальной социальной инженерии это избыточно: проще и дешевле просто «представиться».

Шаг 3. Психологическая накачка — конфиденциальность + срочность

Технически тут ничего не «ломается», ломается процесс принятия решений. Ключевые триггеры в сообщении не случайны, это отработанный скрипт социальной инженерии:

«Никому не говори» — блокирует второй канал проверки;
«Я на встрече/не могу говорить» — закрывает путь к голосовому подтверждению;
Подключение второго «персонажа» (юрист/нотариус), который поддакивает в переписке — создаёт эффект подтверждённости с двух сторон.

В более продвинутых версиях этой схемы для «подтверждения личности» используют клонированный голос — 15–20 секунд публичного видео директора достаточно, чтобы синтезировать короткую голосовую реплику через нейросетевые сервисы клонирования голоса:

# Условный пример пайплайна клонирования голоса (RVC / voice-cloning API)
curl -X POST https://api.voice-clone-service.example/v1/tts \
  -H "Authorization: Bearer API_KEY" \
  -F "voice_model=director_sample.wav" \
  -F "text=Да, переводи, я подтверждаю, потом объясню" \
  -o fake_voice.mp3

Такое голосовое сообщение, присланное «в довесок» к тексту, резко повышает доверие — большинство сотрудников не готовы критически анализировать аудио на артефакты синтеза.

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

Формальных «уязвимостей ПО» в этой схеме нет — эксплуатируется процесс, а не софт. Но есть набор технических индикаторов, по которым инцидент можно распознать постфактум или предотвратить в моменте:

Номер WhatsApp зарегистрирован недавно — проверяется через сервисы вроде numlookupapi, Truecaller API или банальный запрос в поддержку оператора;
У аккаунта нет истории «был в сети» в характерное для директора время (часовой пояс не совпадает с его обычной активностью);
Сообщение приходит не в существующий тред переписки, а как новый диалог/с нового номера — это стоит вносить в чек-лист бухгалтерии как обязательный красный флаг;
В логах банк-клиента — платёж создаётся и подтверждается одним и тем же сотрудником без второй подписи, вне обычного времени и графика контрагентов;
Если атака идёт через угон сессии WhatsApp Web — в логах у самого директора будет висеть незнакомое активное устройство (Settings → Linked Devices), это тоже стоит проверять регулярно.

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

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

Деньги уходят на счёт «юриста» — по факту это счёт дропа, компании-однодневки или P2P-обменника, откуда средства за 1–2 часа дробятся на десятки мелких переводов и уходят в криптовалюту — отследить и вернуть их после этого крайне сложно;
Через 1–3 дня приходит повторный запрос «на вторую часть сделки» — мошенники эксплуатируют уже установленное доверие и то, что первый перевод «сработал»;
Если бухгалтер начинает сомневаться, в переписку добавляется давление статусом: «ты подводишь всю компанию», «директор будет недоволен» — это классическая эскалация социальной инженерии;
В более развитых атаках параллельно готовится фишинговое письмо «от банка» с просьбой подтвердить операцию — если у компании включена дополнительная защита, её тоже пытаются обойти отдельным вектором.

Как закрыть

Технической «заплатки» здесь нет, но есть набор процессных и технических барьеров, которые снижают вероятность успеха почти до нуля. Это и есть то, что реально настраивается за один визит консультанта, без закупки дорогого оборудования.

Callback-верификация. Любое распоряжение о переводе выше установленного порога (например, 100–300 тыс. рублей) подтверждается звонком на заранее сохранённый в CRM номер директора — не на тот, с которого пришло сообщение;
Правило «второй канал». Если в переписке звучит «никому не говори» или «не могу говорить» — это триггер для обязательной проверки через второй, независимый канал связи (звонок, видеозвонок, второй мессенджер);
Двойная подпись платежей. В банк-клиенте настраивается обязательное подтверждение вторым сотрудником для сумм выше лимита — даже если первое распоряжение пришло «от директора лично»;
Алерты в корпоративный чат. Настройка автоматического уведомления (например, в VK Teams или Mattermost) о любом исходящем переводе выше порога — чтобы решение видел не один человек;
Кодовое слово. Простой, но рабочий приём: заранее согласованное между директором и финансовой службой кодовое слово для подтверждения нестандартных распоряжений — не попадает ни в один публичный источник и не поддаётся OSINT-сбору;
Мониторинг связанных устройств. Регулярная проверка активных сессий в WhatsApp/Telegram руководителей (Linked Devices), особенно после командировок и смены SIM;
Обучение через симуляцию. Раз в квартал — контролируемая имитация подобной атаки на бухгалтерию и финдиректора, с разбором реакции, без наказаний, но с фиксацией результата;
SIEM-правило для банк-клиента (если используется корпоративный интернет-банк с API): алерт на транзакции выше порога, созданные и подтверждённые одним и тем же пользователем в нерабочее время.

# Пример условного правила детекции в SIEM (Splunk SPL)
index=bank_transactions amount>300000 
| stats count by initiator, approver, timestamp 
| where initiator=approver 
| eval alert="single_person_high_value_transfer"

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