Современные атаки социальной инженерии — это не «письмо от принца» и не одиночная фишинговая ссылка, а управляемая многошаговая операция, которая сочетает психологию, OSINT-разведку, подмену идентичности и технические приёмы для обхода процессов. Главная цель — заставить человека выполнить действие, которое напрямую открывает доступ к деньгам, учётным записям или инфраструктуре: подтвердить вход, выдать секрет, изменить реквизиты, добавить доверенное устройство, согласовать платеж.
Почему социальная инженерия стала «проектной»
Раньше злоумышленник работал массово: тысячи писем, небольшой процент кликов, минимум персонализации. Сегодня доминирует гибридный подход: массовая разведка + точечная атака на конкретную роль (финансы, HR, админка, техподдержка, руководитель). Такая атака выглядит как работа проджект-менеджера: есть подготовка, сценарий, тайминг, переключение каналов, контроль реакции жертвы и план «Б».
Ключевое изменение — масштабируемая персонализация. Открытые данные (соцсети, вакансии, корпоративные новости, публичные презентации, Git-репозитории, документы подрядчиков) позволяют собрать «контекст правдоподобия»: реальные имена, должности, проекты, поставщики, термины, шаблоны писем. На этой базе атакующий строит легенду и общается так, будто уже «внутри процесса».
Архитектура современной атаки: kill chain по-человечески
Если разложить социнженерию как кибератаку, получим цепочку стадий, похожую на kill chain, но ориентированную на поведение людей и процессы компании.
1) Recon: OSINT + маппинг процессов
Атакующий ищет ответы на вопросы:
- Кто принимает решения по платежам и доступам?
- Какие системы используются (почта, CRM, таск-трекер, облака, мессенджеры)?
- Какие подрядчики и типовые документы ходят внутри (счета, акты, КП, NDA)?
- Какие точки входа самые слабые: найм, бухгалтерия, техподдержка, закупки, руководители?
Дальше строится «организационная карта» — кто кому подчиняется, кто замещает, кто «вечно занят», кто чаще отвечает в мессенджере, кто публикует личные детали. Чем точнее эта карта, тем меньше нужно технических эксплойтов: человек сам отдаст нужное.
2) Weaponization: упаковка легенды и приманки
На этом этапе создаётся «упаковка»:
- Домены-двойники (похожее написание, другая зона, подмена символов).
- Аккаунты в мессенджерах под руководителя/подрядчика/службу безопасности.
- Поддельные страницы входа (phishing kit) под SSO, корпоративную почту, CRM.
- Документы-приманки: «акт сверки», «счёт», «реестр», «техническое задание», «резюме/портфолио», «договор».
- Voice phishing (vishing) и, в продвинутых кейсах, имитация голоса/видео (deepfake) для усиления доверия.
Важно: приманка сегодня редко выглядит как «скачайте вирус». Она выглядит как обычная рабочая рутина — то, что сотрудник делает десятки раз в месяц.
3) Delivery: многоканальная доставка и прогрев доверия
Тренд последних лет — омниканальность:
- Первое касание — письмо или сообщение «в тему».
- Второе — звонок «для ускорения».
- Третье — сообщение в другом канале: «я вам в почту отправил, посмотрите, пожалуйста».
Эта техника ломает внутренний «антифишинговый фильтр»: когда человек получает подтверждение в другом канале, мозг воспринимает ситуацию как более реальную. Плюс повышается давление времени: «я на линии, давайте быстро».
4) Exploitation: психологический эксплойт
Вместо уязвимости в софте используется уязвимость в поведении:
- Авторитет (CEO/CFO/ИБ/банк/госорган).
- Срочность (deadline, «до конца часа», «иначе штраф/срыв сделки»).
- Дефицит внимания (многозадачность, конец дня, уведомления).
- Социальное доказательство («все уже согласовали», «юристы в курсе»).
- Конфиденциальность («никому не говори, проверка»).
- Эмпатия/помощь («выручите, мне неудобно просить»).
Чем сильнее атакующий управляет эмоциями, тем меньше у жертвы ресурсов на верификацию.
5) Action on Objective: «золотое действие»
Почти всегда цель сводится к одному из «золотых действий»:
- Передать секрет: пароль, одноразовый код, резервные коды, токен, приватный ключ.
- Подтвердить MFA: нажать «Approve» в push-уведомлении (MFA fatigue).
- Изменить реквизиты платежа или провести оплату.
- Выдать доступ: добавить пользователя в чат, выдать роль в CRM/облаке, включить пересылку писем, добавить доверенное устройство.
- Запустить файл/макрос/скрипт «для просмотра» или установить «сертификат/обновление».
Результат — компрометация учётной записи (Account Takeover), компрометация бизнес-процесса (Business Email Compromise) или компрометация инфраструктуры (Initial Access).
6) Persistence: закрепление
После первого успеха злоумышленники стараются закрепиться:
- Правила пересылки/скрытые фильтры в почте.
- OAuth-токены и сторонние приложения с доступом к почтовому ящику.
- Добавление второго MFA-метода или резервного адреса/номера.
- Создание «тихих» учёток, API-ключей, сервисных токенов.
Здесь важно понимать: даже если пароль поменяли, но оставили токен или правило пересылки — атака продолжается.
Типовые сценарии, которые реально встречаются сегодня
Сценарий 1: CEO fraud в мессенджере + «нестандартная просьба»
Сообщение от «руководителя»: коротко, без лишних деталей, с давлением времени. Затем — голосовое/звонок. Цель: срочная оплата, покупка сертификатов, перевод «под проект», смена реквизитов, запрос конфиденциальных данных. Отличительные признаки — просьба обойти регламент и запрет «эскалировать».
Сценарий 2: BEC и подмена реквизитов в реальной цепочке
Атакующий внедряется в переписку с подрядчиком или подделывает письмо так, будто оно продолжает цепочку. Тон, подпись, файл — «как обычно». Меняется только одно: номер счёта/ссылка на оплату. Это бьёт по бухгалтерии и закупкам, потому что выглядит как «неотличимо рабочее».
Сценарий 3: «Служба безопасности» и атаки на MFA
Жертве сообщают о «подозрительной активности» и просят подтвердить вход или назвать код «для блокировки атаки». Частый вариант — MFA fatigue: злоумышленник многократно инициирует вход, и сотрудник в усталости нажимает «Разрешить», чтобы убрать уведомления.
Сценарий 4: Атака через найм (HR-поток)
«Кандидат» присылает резюме/портфолио/тестовое. Внутри — ссылка на документ, архив, «проект на Git», иногда — просьба установить «просмотрщик» или открыть «макросы». Уязвимость здесь не техническая, а процессная: HR-поток устроен так, что доверие по умолчанию высокое, а скорость важнее проверки.
Сценарий 5: Техподдержка и «удалённое решение проблемы»
Звонок «из ИТ» или «из провайдера»: «у вас проблемы с почтой/сертификатом/доменом». Жертву ведут пошагово до установки агента удалённого доступа, выдачи временного пароля или добавления устройства. В корпоративных средах это опасно, потому что выглядит как штатная помощь.
Терминология, которая помогает говорить об этом профессионально
Внутри компании удобно описывать угрозы и меры защиты в инженерных терминах:
- Phishing — выманивание данных через поддельные страницы/сообщения.
- Spear phishing — таргетированный фишинг под конкретного человека/роль.
- Whaling — атаки на руководителей и ключевые роли.
- BEC (Business Email Compromise) — компрометация деловой переписки, часто ради платежей.
- Vishing / Smishing — голосовой фишинг / фишинг через SMS.
- Pretexting — легенда/предлог, который оправдывает просьбу.
- MFA fatigue — давление множественными push-запросами до «случайного подтверждения».
- Account Takeover (ATO) — захват учётной записи.
- Initial Access — первичный доступ в инфраструктуру.
- Persistence — закрепление после первичного доступа.
- Zero trust (в человеческом смысле) — доверяем не личности, а проверенному каналу и регламенту.
Как должна выглядеть защита: не «будь внимательнее», а системный контроль
Лучшая защита от социальной инженерии — это когда даже идеальный психологический сценарий упирается в процесс и техконтроли.
1) Двухканальная верификация (Out-of-band verification)
Любая нестандартная просьба (платёж, доступ, реквизиты, «срочно») подтверждается вторым каналом, который нельзя подменить внутри текущего диалога. Ключевой нюанс: звонить/писать нужно по номеру/контакту из корпоративного справочника, а не по тому, что прислал «руководитель».
2) Регламент «необычных действий»
Социнженерия почти всегда просит сделать «необычное». Значит, нужно формализовать:
- кто имеет право просить,
- кто обязан подтверждать,
- какой минимальный набор проверок,
- какие лимиты и какие исключения запрещены полностью.
3) Жёсткая политика по секретам и MFA
Одноразовые коды, push-подтверждения, резервные коды, токены — никогда не передаются «для проверки». Если сотрудник знает это как правило безопасности уровня «не сообщай PIN», значительная доля атак рассыпается.
4) Контроль почты и облака на признаки компрометации
Для инфраструктуры важно мониторить:
- правила пересылки,
- создание OAuth-приложений,
- аномальные входы,
- новые устройства и методы MFA,
- подозрительные изменения прав.
Это уже зона DevOps/SecOps/AIOps: даже если человек ошибся, система должна быстро обнаружить и локализовать.
5) Тренировки на сценариях, а не лекции
Классическое «не кликайте ссылки» больше не работает, потому что атака может вообще не включать ссылку: это может быть звонок, чат, просьба «подтвердить». Тренировки должны быть сценарными: «руководитель просит оплатить», «подрядчик меняет реквизиты», «ИБ просит код», «HR получает резюме».
Признаки атаки: короткий чек-лист для сотрудников
Если совпадают 2–3 пункта — это почти наверняка социнженерия:
- Срочно + секретно.
- Просьба обойти процесс («не заводи тикет», «без согласования»).
- Запрос кода/подтверждения/доступа/денег.
- Давление авторитетом или угрозами.
- «Новый контакт» в мессенджере, хотя раньше общались иначе.
- Смена реквизитов или ссылки «в последний момент».
Как AEdynasty смотрит на проблему.
Социальная инженерия — это атака на бизнес-процесс. Её нельзя победить одним антивирусом или «памяткой». Нужна связка: регламенты + технические контроли + наблюдаемость (логирование, алерты, расследование) + обучение на реальных сценариях. В такой модели даже сильная психологическая атака превращается в инцидент низкого уровня: попытка фиксируется, блокируется и становится материалом для улучшения процессов.