Социальная инженерия: методы защиты за рамками фишинга

В январе 2024 года сотрудник финансового отдела гонконгской компании перевёл $25 миллионов после видеоконференции с "руководством". Все участники звонка оказались deepfake-генерацией. Не фишинг, не вредоносная ссылка - живой видеозвонок с синтетическими лицами и голосами. По данным Verizon DBIR 2025, человеческий фактор присутствует в 60% утечек данных, а pretexting (обман с заранее подготовленной легендой) - это более 40% инцидентов социальной инженерии. Больше, чем классический email-фишинг. FBI IC3 фиксирует $2.77 млрд потерь от BEC в 2024 году, и значительная доля проходит через голосовой канал.

Русскоязычные материалы по теме обычно заканчиваются на "проверяйте отправителя" и "не нажимайте на ссылки". Здесь - три вектора, которые они игнорируют: вишинг, мессенджеры и физический доступ. С конкретными сценариями атак, маппингом на MITRE ATT&CK и detection-правилами для SOC.

Вишинг и голосовые атаки: сценарии и detection​

Вишинг - не "звонок из банка бабушке". В корпоративном контексте это Spearphishing Voice (T1566.004, Initial Access): целенаправленный звонок конкретному сотруднику с легендой, собранной через OSINT. Перед атакой идёт разведка - Spearphishing Voice (T1598.004, Reconnaissance), когда атакующий серией "безобидных" звонков в приёмную выясняет имена сотрудников, структуру отделов и названия подрядчиков.

Анатомия вишинг-звонка: разбор сценария​

Понедельник, 9:15 утра. На ресепшн звонит "инженер подрядчика", обслуживающего серверное оборудование. Caller ID показывает номер реального подрядчика - подмена через VoIP-сервис занимает пять минут. Звонящий называет имя системного администратора (T1589.003, Employee Names - reconnaissance через LinkedIn и корпоративный сайт), ссылается на "открытый тикет по замене диска" и просит соединить с IT.

Диалог с админом звучит так:

"Добрый день, это Алексей из [название подрядчика]. У вас тикет 4872 на замену диска в стойке 3. Мне нужно подтвердить серийный номер сервера перед выездом - можете продиктовать?"

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

Если серийный номер получен - атакующий использует его в следующем звонке, уже от "вендора", который попросит "обновить firmware удалённо" и запросит VPN-доступ. Цепочка выстраивается за 2-3 звонка.

Deepfake-голос масштабирует этот вектор. В гонконгском кейсе атакующие клонировали голоса и лица руководителей из публичных выступлений. Для качественного клонирования голоса хватает 3-5 минут аудио с YouTube-интервью или записи с конференции. Если у вашего CFO есть выступление на ютубе - считайте, что его голос уже скомпрометирован.

Detection для SOC: корреляция вокруг голосовых атак​

Голосовой канал сам по себе не логируется в SIEM. Но последствия успешного вишинга оставляют следы - и вот что ловить.

Правило 1 - аномальный VPN-доступ после звонка. Если в течение 30 минут после входящего звонка на номер IT-отдела (данные PBX/CDR) создаётся VPN-аккаунт или происходит подключение с нового IP - алерт. Корреляция: CDR-логи АТС + VPN-логи. Baseline (DE.AE-01 по NIST CSF 2.0): нормальные VPN-подключения идут с известных устройств и IP, новый IP требует верификации.

Правило 2 - смена реквизитов после голосового контакта. HR или бухгалтерия меняют банковские реквизиты сотрудника в течение 2 часов после входящего звонка - алерт High. BEC-атаки с подменой реквизитов после голосового "подтверждения" - один из самых частых сценариев в статистике FBI IC3.

Правило 3 - привилегированный доступ без тикета. Сброс пароля, выдача токена MFA или создание учётной записи, инициированные голосовым каналом без записи в ServiceDesk - алерт. Любое действие Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation / Defense Evasion) должно проходить через тикет-систему. Нет тикета - нет доступа. Точка.

Атаки через мессенджеры: имперсонация в Slack и Teams​

Корпоративные мессенджеры создают ложное чувство безопасности: "раз человек в нашем Teams - значит, он наш". Это Impersonation (T1656, Defense Evasion) в цифровой среде, и работает оно до неприличия хорошо.

Сценарий: поддельный аккаунт руководителя в Teams​

Атакующий регистрирует Microsoft 365 trial-тенант, создаёт аккаунт с именем и фото финансового директора (фото - с корпоративного сайта или LinkedIn). Через External Access в Teams пишет главному бухгалтеру:

"Привет, я сейчас в поездке, Teams на ноутбуке глючит - зашёл с личного. Нужно срочно оплатить счёт подрядчику, пришлю реквизиты. Сделай до 14:00, иначе сорвём дедлайн."

Триггеры: срочность (до 14:00), авторитет (CFO), объяснение аномалии (личный аккаунт - "ноутбук глючит"). Бухгалтер видит знакомое имя и фото, контекст правдоподобный. Trial-тенант M365 создаётся за 10 минут - и вот у вас в чате "CFO" с правильным именем и аватаркой.

В Slack ситуация аналогична. Если в workspace разрешён self-registration по email-домену - атакующий с доступом к одному корпоративному email (полученному через credential stuffing или предшествующий фишинг) регистрирует аккаунт с displayName руководителя и начинает переписку в DM.

Что мониторить в мессенджерах​

Для Teams: алерт на входящие сообщения от External-аккаунтов с ключевыми словами - "оплата", "перевод", "реквизиты", "пароль", "срочно". Настраивается через DLP-политики в Microsoft Purview или Defender for Office 365.

Для Slack: аудит событий регистрации новых пользователей (team_join в стандартных workspace или user_created в Enterprise Grid с SCIM). Появление нового пользователя с displayName, совпадающим с существующим членом workspace, и немедленная отправка DM - аномалия. Такое должно прилетать в SOC сразу.

Общее правило корреляции: любой запрос на финансовую операцию или передачу credentials через мессенджер, не подтверждённый вторым каналом (звонок на корпоративный номер, тикет в ServiceDesk), генерирует алерт и блокируется до верификации (RS.AN-01 по NIST CSF 2.0).

Физическое проникновение: тейлгейтинг и hardware drops​

Физическая социальная инженерия - это Hardware Additions (T1200, Initial Access) и тейлгейтинг в связке. ENISA отмечает конвергенцию физических и цифровых угроз: проникновение в здание и подключение rogue-устройства к внутренней сети - один kill chain.

Сценарий: от парковки до серверной​

Четверг, 11:40. Человек в форме курьерской службы с коробкой и планшетом подходит к входу в офис. Ждёт, пока сотрудник приложит пропуск, и проходит следом - тейлгейтинг. Сотрудник придерживает дверь: социальная норма "помочь человеку с занятыми руками" оказывается сильнее корпоративной политики. Каждый раз.

Внутри "курьер" двигается уверенно. План этажа изучен по фото из Instagram-аккаунта компании (фон снимков с корпоратива выдаёт расположение переговорных и open space). Подходит к незанятому столу в зоне IT, подключает к свободному Ethernet-порту устройство размером с зарядку для телефона - Raspberry Pi с обратным SSH-туннелем или LAN Turtle. Уходит через четыре минуты.

Устройство поднимает SSH-соединение к C2-серверу атакующего. Доступ к внутренней сети - изнутри периметра, мимо файрволов и IDS. Красота, если вы атакующий. Кошмар, если вы SOC.

Второй вариант - USB-drop (T1091, Replication Through Removable Media / Initial Access). Флешки с лейблом "Зарплатная ведомость Q4" или "Аудит - конфиденциально" оставляются на парковке, в курилке, в лифте. В реальных SE-пентестах процент подключения найденных USB - от 15% до 45% в зависимости от организации. Почти каждая вторая в худшем случае. Если флешка содержит Malicious File (T1204.002, Execution) - payload запускается при открытии "документа".

Detection на уровне SOC и физической безопасности​

Правило 1 - новое устройство в сети. NAC (Network Access Control) алертит на подключение MAC-адреса, отсутствующего в CMDB. Корреляция: DHCP-лог + NAC + отсутствие записи в asset inventory (ID.AM-01 по NIST CSF 2.0). Без NAC - мониторинг DHCP-leases на появление неизвестных хостов. Не идеально, но лучше, чем ничего.

Правило 2 - USB на привилегированной машине. EDR-событие подключения removable media на машине из группы "Finance", "IT-Admin" или "C-Level" - алерт. Sysmon Event ID 1 (Process Create) от процессов, запущенных с пути removable media (D:\, E:\), коррелированный с EDR-телеметрией.

Правило 3 - SSH/reverse tunnel из внутренней сети. Исходящие соединения на порт 22/443 от IP, который не сервер и не числится в whitelist - алерт. Baseline: легитимные SSH-сессии идут от jump-серверов, не от рабочих станций в open space. Если рабочая станция бухгалтера шлёт SSH наружу - что-то явно не так.

Физическая безопасность: видеоаналитика на tailgating (два прохода за одну карту), корреляция в журнале СКУД - если пропуск сотрудника зафиксировал вход, но выхода по предыдущей сессии нет (человек "уже внутри"), это аномалия.

Обучение сотрудников: скрипты верификации и протоколы эскалации​

Тренинг по социальной инженерии: метрики эффективности​

Тренинг без измерения - трата бюджета. Вот что стоит замерять:


Тестовые вишинг-звонки проводятся вручную (для голосовых сценариев автоматизация пока слабая) и через SET (Social-Engineer Toolkit) для подготовки pretexting-сценариев. Gophish закрывает email-симуляции, но вишинг требует живого оператора или кастомной интеграции с VoIP для caller ID spoofing.

Результаты тренингов мапятся на MITRE ATT&CK: тестовый вишинг-звонок прошёл - gap в detection на T1566.004 (Initial Access). USB-drop сработал - gap по T1091. Это позволяет приоритизировать обучение по конкретным TTP, а не "по теме социальной инженерии в целом".

Основная часть бюджетов на ИБ уходит на защиту цифрового периметра - и это правильно, но не достаточно. Три вектора из этой статьи - вишинг, мессенджеры, физический доступ - объединяет одно: они эксплуатируют не уязвимости софта, а штатное человеческое поведение. Желание помочь коллеге, привычку доверять знакомому голосу, вежливость придержать дверь. Техническими средствами это не закрывается целиком. SOC детектит последствия - аномальный VPN, новый MAC в сети, несанкционированную смену реквизитов. Но первый рубеж - сотрудник, который взял паузу и перезвонил по независимому номеру.

В SE-пентестах закономерность видна чётко: компании, где сотрудники натренированы на скрипт "спасибо, перезвоню сам", показывают заметно более низкий процент успешных вишинг-атак уже через несколько месяцев. Компании, ограничившиеся вебинаром и плакатом - остаются на прежнем уровне. Разница не в осведомлённости, а в отработанном навыке. Осведомлённость - это знать, что вишинг существует. Навык - это автоматически брать паузу и набирать номер из справочника, а не перезванивать на тот, что продиктовал звонящий. Проверьте свою команду: позвоните от "подрядчика" и попросите серийный номер сервера. Результат покажет, нужен ли вам playbook по голосовым векторам SE - а на codeby.net есть тред с разбором подобных инцидентов и обсуждением верификационных протоколов.