Исследователи изучили более 25 млн тревог безопасности в корпоративных сетях и пришли к неприятному выводу: реальные взломы часто начинаются с событий, которые системы помечают как малозначимые. Для компаний это не теория, а риск пропустить примерно одну настоящую угрозу в неделю, если команда смотрит только на «критические» срабатывания.

Отчёт опирается на данные из рабочих корпоративных сред: 10 млн конечных устройств и учётных записей, 82 тыс. криминалистических проверок с анализом оперативной памяти, 180 млн файлов, телеметрию с 7 млн IP-адресов, 3 млн доменов и URL, а также более 550 тыс. фишинговых писем.

Низкий риск оказался удобным укрытием

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

На уровне крупной компании такие проценты быстро превращаются в десятки инцидентов. По оценке авторов отчёта, средняя организация получает около 450 тыс. тревог в год. Если 1 % из них скрывает реальную угрозу, это примерно 54 опасных события ежегодно — около одного в неделю.

Проблема не в том, что средства обнаружения полностью промахнулись. Сигнал был. Его просто никто не разобрал, потому что модель работы SOC (Security Operations Center — центр мониторинга безопасности) обычно строится вокруг жёсткой сортировки: критическое — в работу, низкий риск — в очередь или в автоматическое закрытие.

Мы уже разбирали, почему поток событий ломает даже зрелые команды безопасности, в материале «Почему новые аналитики не спасают SOC от потока тревог». Новый отчёт показывает ту же проблему с другой стороны: ярлык «низкий риск» не отменяет саму атаку.

Почему «устранено» не значит «чисто»

Отдельный блок отчёта посвящён EDR (Endpoint Detection and Response — обнаружение и реагирование на конечных устройствах). Это системы, которые следят за ноутбуками, рабочими станциями и серверами, ловят вредоносную активность и пытаются её остановить.

Из 82 тыс. тревог, которые прошли проверку с анализом оперативной памяти, исследователи нашли 2600 активных заражений. Самая тревожная деталь: 51 % этих устройств уже числились как «очищенные» или «устранённые» в системе EDR.

Иными словами, тикет закрыли, но вредоносный код всё ещё жил в памяти. Без такой проверки компания могла бы считать машину безопасной.

Среди найденных инструментов исследователи называют Mimikatz, Cobalt Strike, Meterpreter и StrelaStealer. Это не лабораторные образцы, а распространённые инструменты, которые используют преступные группы и серьёзные атакующие. Похожий риск мы видели в историях со стилерами, например в случае, когда фальшивый репозиторий OpenAI на Hugging Face раздавал вредоносную программу.

Фишинг ушёл от вложений к доверенным площадкам

Фишинг (от англ. phishing — выуживание) тоже изменился. По данным отчёта, менее 6 % подтверждённых вредоносных писем содержали вложения. Большинство атак держалось на ссылках, убедительном тексте и использовании площадок, которым почтовые фильтры часто доверяют.

Исследователи описывают кампании с инфраструктурой на Vercel, CodePen, OneDrive и даже через систему выставления счетов PayPal. В одном случае злоумышленники отправляли письма через легитимный механизм запроса оплаты, а номер для обратного звонка прятали в примечании к платежу. Домен отправителя проходил стандартные проверки, потому что письмо действительно уходило с инфраструктуры PayPal.

В отчёте также отмечены четыре техники, которые помогают письмам проходить почтовые шлюзы: Base64-нагрузка внутри SVG-файлов, ссылки в служебных метаданных PDF, динамическая загрузка страниц через общие папки OneDrive и DOCX-документы с архивированным HTML-контентом и QR-кодами.

Для обычного пользователя вывод проще: странное поведение компьютера не всегда сводится к бытовым запросам вроде «starting discord» или «как ускорить ютуб в google chrome». Иногда за тормозами браузера, всплывающими окнами и непонятными входами в аккаунт стоят расширения, поддельные страницы или украденные сессии.

Облако: злоумышленники играют в долгую

В облачной телеметрии исследователи чаще видели не громкие действия, а попытки закрепиться и скрыться. Атакующие манипулировали токенами, злоупотребляли штатными облачными функциями и маскировали активность так, чтобы не получить высокую оценку риска.

Это типичная стратегия долгого присутствия. Злоумышленнику не всегда нужно сразу повышать привилегии или перемещаться по сети. Иногда выгоднее тихо сохранить доступ и дождаться удобного момента.

Отдельно авторы выделяют AWS S3: на него пришлось около 70 % нарушений облачных правил контроля в наборе данных. Чаще всего речь шла об управлении доступом, серверных журналах и ограничениях между аккаунтами. Такие ошибки редко выглядят как срочная тревога, но после первичного проникновения они ускоряют дальнейшую атаку.

Почему людям не хватает глаз

SOC и MDR (Managed Detection and Response — управляемое обнаружение и реагирование) упираются в одну и ту же границу: людей меньше, чем событий. По данным отчёта, около 60 % тревог всё равно остаются без ручного разбора — независимо от того, работает команда внутри компании или у внешнего провайдера.

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

Авторы отчёта утверждают, что при полном разборе всех 25 млн тревог с помощью AI SOC-подхода менее 2 % событий ушли на эскалацию человеку, точность вердиктов достигла 98 %, а медианное время первичной сортировки составило меньше минуты. Это заявленные результаты поставщика технологии, поэтому воспринимать их стоит как ориентир, а не как универсальную гарантию.

Главная мысль всё равно практична: ярлык важности нельзя считать доказательством безопасности. Чем больше источников данных у компании — конечные устройства, почта, облако, учётные записи, сеть, SaaS (Software as a Service — программное обеспечение как сервис), — тем опаснее слепо отбрасывать слабые сигналы.

Практический вывод: что проверить сейчас

  • Не закрывайте тревоги низкого риска только по метке системы. Для повторяющихся событий заведите выборочную ручную проверку и смотрите, не связаны ли они с одними и теми же учётными записями или устройствами.
  • Сравните вердикты EDR с фактическим состоянием машин. Для подозрительных рабочих станций используйте анализ процессов, автозагрузки, сетевых соединений и оперативной памяти.
  • Проверьте почтовые правила: фильтры должны разбирать ссылки, QR-коды, метаданные PDF и документы, а не только вложения с очевидными исполняемыми файлами.
  • В облаке начните с доступа к хранилищам, журналирования и ограничений между аккаунтами. Ошибки S3 и похожих сервисов часто выглядят «несрочно», пока ими не воспользовались.
  • Разделяйте бытовую диагностику и признаки компрометации. Запросы вроде «дискорд бесконечный starting» могут описывать обычный сбой, но массовые жалобы сотрудников на странные входы, тормоза и всплывающие окна требуют проверки.
  • Для работы из кафе, гостиниц и коворкингов используйте сервис безопасного интернет-соединения, чтобы снизить риск перехвата данных в публичных сетях.
  • Настройте обратную связь: каждое подтверждённое расследование должно улучшать правила обнаружения, а не просто закрывать отдельный тикет.
Поделиться: