Spear phishing: когда письмо пришло от директора

В конце марта бухгалтер одного из наших клиентов открыла вложение из письма. Письмо пришло с адреса генерального директора, в теме было что-то про акт сверки, во вложении - файл с расширением .doc. Ничего подозрительного. Через двадцать минут антивирус на её машине поднял тревогу.

Это был spear phishing - целевая атака, заточенная под конкретную компанию и конкретного получателя. Не массовая рассылка про выигрыш в лотерею, а аккуратно собранное письмо с реальными именами, реальным контекстом и рабочим эксплойтом внутри.

Как выглядела цепочка

Мы разобрали инцидент вместе с клиентом. Картина получилась неприятно стройная.

Сбор информации. На сайте компании был раздел «О нас» с именами и должностями руководителей. В LinkedIn - профили нескольких сотрудников с указанием места работы. В открытых источниках - пара пресс-релизов, из которых понятна структура бизнеса. Ничего экстраординарного, всё это есть у половины компаний. Атакующему хватило часа-двух, чтобы собрать достаточно для правдоподобного письма.

Подмена отправителя. Письмо пришло с адреса, который выглядел как корпоративный домен клиента - один символ отличался от настоящего, и заметить это можно было только если смотреть внимательно. SPF-записи у домена не было вообще. DKIM - тоже. Почтовый сервер принял письмо без каких-либо возражений и доставил его в ящик. Никакого предупреждения, никакого «внешний отправитель», ничего.

Эксплойт во вложении. Файл .doc эксплуатировал уязвимость в Microsoft Word - не нулевой день, патч для неё был выпущен ещё в феврале, но на машинах клиента Office обновлялся вручную и несистематично. Документ при открытии запускал макрос, который пытался загрузить следующую ступень с внешнего адреса. Антивирус поймал именно эту загрузку, а не сам документ - вложение прошло сканер на почтовом шлюзе чисто.

Что успело произойти. Соединение с внешним адресом антивирус заблокировал, полезная нагрузка не загрузилась. Повезло - или, точнее, антивирус сделал своё дело на нужном этапе. Но это скорее удача, чем система.

Почему именно бухгалтер

Не случайность. Финансовый персонал - стандартная цель для таких атак: доступ к платёжным системам, 1С, банк-клиенту. Письмо про акт сверки от директора - ровно то, что такой сотрудник получает регулярно и открывает не задумываясь. Атакующий это понимает не хуже нас.

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

Аудит показал три слоя проблем, и чинили все три.

Первое - почтовая аутентификация. Настроили SPF для домена: запись в DNS, которая явно перечисляет, с каких серверов можно отправлять почту от имени домена. Всё остальное - подозрительно. Дополнительно настроили DKIM: каждое исходящее письмо теперь подписывается ключом, и получатель может проверить подпись. Это не останавливает атакующего от использования похожего домена, но сильно сужает пространство для манёвра и даёт почтовым фильтрам на принимающей стороне больше оснований для скептицизма.

Отдельно попросили клиента включить проверку SPF и DKIM на входящих - у них стоял Exchange 2010, и там это настраивается через транспортные агенты. Письма с неудачной проверкой не отбрасываются сразу, но получают метку и складываются в папку для проверки, а не в основной ящик.

Второе - обновления. Office на машинах перевели на централизованное обновление через WSUS. Уязвимость, которую использовал документ, закрыта в феврале - три месяца с открытым патчем это слишком долго. Именно такие задержки и закрывает нормальный патч-менеджмент.

Третье - инструктаж. Это самая неудобная часть, потому что её сложнее всего оцифровать. Собрали сотрудников и разобрали прямо на примере этого письма: вот что пришло, вот как выглядит нормальный адрес отправителя, вот как выглядит подозрительный, вот что надо сделать перед тем как открыть вложение от руководителя - позвонить и спросить. Не потому что руководитель не мог отправить этот файл, а потому что одна минута на звонок дешевле разбора инцидента.

Отдельно проговорили про вложения с двойными расширениями, про то что .doc с макросами это не то же самое что .docx, и про кнопку «Включить содержимое» в Word - именно она разрешает запуск макросов и именно на неё нажала бухгалтер.

Где граница

SPF и DKIM не защищают от письма, отправленного с реального взломанного ящика. Инструктаж не защищает от идеально сделанной атаки, где всё выглядит абсолютно нормально. Антивирус не поймает неизвестный эксплойт. Каждый из этих слоёв закрывает часть векторов, ни один не закрывает все.

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

Клиент, кстати, после этого случая сам спросил, нет ли смысла проверить остальные почтовые ящики на предмет похожих писем. Нашли ещё два - к счастью, нераскрытых. Атака была не единичной.