Киберпреступники все чаще атакуют компании через их же партнеров. Фишинговые письма, приходящие со взломанных аккаунтов доверенных поставщиков, становятся практически неотличимыми от настоящей корреспонденции. Это создает серьезные проблемы как для сотрудников, вынужденных постоянно быть начеку, так и для систем безопасности, которые не всегда способны распознать умелую подделку. Решением может стать переход от поиска известных угроз к обнаружению аномального поведения, что и продемонстрировали недавние инциденты, выявленные системой Darktrace.
Описание
Что такое компрометация почты поставщика (VEC)?
Vendor Email Compromise (VEC), или компрометация почты поставщика, - это вид атаки, при которой злоумышленники взламывают систему стороннего поставщика, чтобы использовать его доступ, деловые отношения или инфраструктуру в злонамеренных целях. Изначально атакованные организации часто являются действующими партнерами цели, но это может распространиться на любую компанию или частное лицо, пользующееся доверием жертвы.
Эта тактика находится на стыке атак на цепочку поставок и компрометации деловой переписки (Business Email Compromise, BEC), сочетая техническую эксплуатацию с обманом, основанным на доверии. Злоумышленники часто внедряются в существующие переписки, используя искусственный интеллект для имитации стиля общения и избегая грамматических ошибок, которые обычно выдают фишинг. Злонамеренный контент, как правило, размещается на репутационных файлообменных платформах, из-за чего любые передаваемые ссылки изначально кажутся безопасными.
Хотя методы получения первоначального доступа эволюционировали, цели остаются прежними: сбор учетных данных, запуск последующих фишинговых кампаний, попытки перенаправления платежей по счетам для финансовой выгоды и кража конфиденциальных корпоративных данных.
Почему традиционная защита не справляется
Эти тонкие и изощренные атаки создают уникальные проблемы для защитников. Мало кто из занятых сотрудников будет с таким же подозрением относиться к письму в рамках текущей переписки с trusted-контактом, как к сообщению от генерального директора с пометкой «СРОЧНАЯ ПОМОЩЬ!». К сожалению, многие традиционные системы защищенных почтовых шлюзов (SEG) сталкиваются с той же проблемой. Обнаружить «несвойственное» письмо, когда оно не выглядит таковым, - сложная задача. Неудивительно, что 83% организаций сталкивались с инцидентами безопасности, связанными со сторонними поставщиками.
Четыре кампании за две недели: кейс Darktrace
В течение двух недель 2025 года система Darktrace обнаружила для одного клиента четыре различные кампании, связанные с компрометацией поставщиков. Модуль Darktrace/EMAIL успешно идентифицировал тонкие индикаторы того, что эти, казалось бы, безобидные письма от доверенных отправителей на самом деле были злонамеренными. В данной конфигурации система не могла autonomously (автономно) заблокировать вредоносные письма, однако при полном подключении функции Autonomous Response она удержала бы все идентифицированные опасные сообщения.
Разные кампании, общие черты
Наблюдался широкий спектр подходов. Целями становились частные лица, общие почтовые ящики и внешние подрядчики. Два письма исходили от скомпрометированных текущих поставщиков, а два - от неизвестных взломанных организаций, одна из которых работала в смежной отрасли. Организации-отправители были либо знакомы получателям, либо, по крайней мере, выглядели профессионально, без необычных буквенно-цифровых строк или подозрительных доменных зон. Тематические строки, такие как «Новая одобренная выписка от » и «Документ с предложением», казались ничем не примечательными и не были предназначены для провокации сильных эмоций, как это бывает в типичных BEC-атаках.
Все письма получили от Microsoft уровень достоверности спама (Spam Confidence Level), равный 1, что означало, что Microsoft не считала их спамом или вредоносными. Они также проходили проверки аутентификации (включая SPF, а в некоторых случаях DKIM и DMARC), то есть выглядели так, как будто исходили из аутентичного источника для домена отправителя и не были изменены в пути.
Все наблюдаемые фишинговые письма содержали ссылку, размещенную на легитимном и широко используемом файлообменном сайте. Эти страницы часто были убедительно стилизованы, нередко с указанием названия доверенного поставщика либо на самой странице, либо в URL-адресе, чтобы казаться аутентичными и не вызывать подозрений. Однако эти ссылки служили лишь первым шагом в более сложном, многоэтапном фишинговом процессе.
Если бы получатель перешел по такой ссылке, его перенаправили бы, иногда через CAPTCHA, на поддельные страницы входа в Microsoft, предназначенные для перехвата учетных данных. В одном из случаев использовались омоглифы для обмана пользователя: ссылка содержала отсылку к ‘s3cure0line’, а не к ‘secureonline’. Последующее расследование с использованием данных открытых источников (OSINT) подтвердило, что домены были связаны с вредоносными фишинговыми точками.
Ключевые выводы для защитников
Фишинг остается прибыльным бизнесом, и по мере развития ландшафта современные кампании часто сильно отличаются от своих предшественников. Как и в случае с сетевыми атаками, злоумышленники все чаще используют легитимные инструменты и эксплуатируют доверительные отношения для достижения своих целей, зачастую оставаясь незамеченными для команд безопасности и традиционных систем защиты почты.
Поскольку атакующие продолжают использовать доверительные отношения между организациями и их сторонними партнерами, командам безопасности необходимо сохранять бдительность в отношении неожиданной или подозрительной почтовой активности. Защита цифрового пространства требует почтового решения, способного идентифицировать вредоносные характеристики, даже когда они исходят от, казалось бы, доверенных отправителей. Подход, основанный на обнаружении аномалий и анализе поведения, становится не просто полезным, а необходимым элементом современной кибербезопасности.
Индикаторы компрометации
URLs
- http://pub-ac94c05b39aa4f75ad1df88d384932b8.r2.dev/offline.html#p
- https://s3.us-east-1.amazonaws.com/s3cure0line-0365cql0.19db86c3-b2b9-44cc-b339-36da233a3be2ml0qin/s3cccql0.19db86c3-b2b9-44cc-b339-36da233a3be2%26l0qn.html#
