Исследование, охватившее более 25 миллионов алертов безопасности в реальных корпоративных средах, выявило структурную проблему: почти 1% подтверждённых инцидентов происходил из уведомлений, изначально классифицированных как низкоприоритетные или информационные. На конечных точках этот показатель достигал 2%. При среднем объёме в 450 000 алертов на организацию в год это означает порядка 54 реальных угроз ежегодно — примерно одну в неделю, — которые в традиционной модели SOC или MDR никогда не расследуются. Данные указывают на то, что проблема не в детектировании, а в экономике триажа: ресурсы аналитиков заканчиваются раньше, чем поток уведомлений.
Масштаб исследования
По данным отчёта, набор данных включал телеметрию с 10 миллионов конечных точек и учётных записей, 82 000 форензик-расследований с анализом оперативной памяти, 180 миллионов проанализированных файлов, а также данные по 7 миллионам IP-адресов, 3 миллионам доменов и URL, и более чем 550 000 фишинговых писем. Важно учитывать, что первичный отчёт (2026 AI SOC Report от Intezer) не был предоставлен для независимой верификации, поэтому к конкретным цифрам следует относиться с оговоркой об их источнике.
EDR: ложное чувство безопасности
Наиболее тревожная находка касается надёжности решений класса EDR. Из 82 000 алертов, прошедших форензик-анализ оперативной памяти, 2 600 хостов имели активное заражение. При этом, как сообщается, 51% этих подтверждённо скомпрометированных машин уже были отмечены EDR-вендором как «устранённые». Фактически более половины реальных заражений оставались невидимыми, потому что инструмент защиты закрыл тикет и объявил угрозу ликвидированной.
Среди семейств вредоносного ПО, обнаруженных в памяти при сканировании, фигурируют:
- Mimikatz — инструмент извлечения учётных данных
- Cobalt Strike — фреймворк для постэксплуатации
- Meterpreter — компонент Metasploit для удалённого управления
- StrelaStealer — стилер учётных данных почтовых клиентов
Это не экспериментальные образцы, а рабочие инструменты криминальных и государственных операций.
Фишинг: доверенные платформы как оружие
Менее 6% подтверждённых вредоносных фишинговых писем содержали вложения. Подавляющее большинство строилось на ссылках и социальной инженерии. Атакующие, по данным исследования, перенесли инфраструктуру на платформы, которым доверяют по умолчанию: Vercel, CodePen, OneDrive и систему выставления счетов PayPal.
Одна из задокументированных кампаний использовала легитимную функцию запроса платежа PayPal для отправки фишинговых писем. Номера обратного звонка размещались в примечаниях к платежу, а юникод-омоглифы применялись для обхода сигнатурного детектирования. Письмо проходило все стандартные проверки аутентификации, поскольку действительно отправлялось с серверов PayPal.
Отдельное наблюдение: сайты с Cloudflare Turnstile CAPTCHA в анализируемом наборе данных устойчиво коррелировали с фишинговыми страницами, тогда как Google reCAPTCHA — с легитимной инфраструктурой. Атакующие используют механизмы защиты от ботов, чтобы блокировать автоматические сканеры безопасности.
Четыре техники обхода почтовых шлюзов, выявленные в данных:
- Полезная нагрузка в формате Base64, скрытая внутри SVG-файлов
- Ссылки, встроенные в метаданные аннотаций PDF, невидимые для поверхностных сканеров
- Динамически загружаемые фишинговые страницы через легитимные общие папки OneDrive
- Файлы DOCX, содержащие архивированный HTML с QR-кодами
Облачная инфраструктура: тихие мисконфигурации
Облачные алерты в исследовании концентрировались вокруг тактик уклонения от обнаружения и закрепления в среде. Латеральное перемещение и повышение привилегий фиксировались значительно реже. Атакующие, по данным отчёта, действуют терпеливо: манипуляция токенами, злоупотребление легитимными функциями облачных сервисов и обфускация для избежания срабатывания высокоприоритетных детекций.
AWS S3 составил около 70% всех нарушений облачных политик безопасности в наборе данных. Основные проблемы — управление доступом, логирование серверов и ограничения межаккаунтного взаимодействия. Эти находки, как правило, классифицируются как низкоприоритетные и редко генерируют алерты, но именно они многократно эксплуатируются после получения первоначального доступа.
Практические рекомендации
- Не доверяйте статусу «mitigated» от EDR без верификации. Внедрите периодическое сканирование оперативной памяти на критичных хостах — особенно тех, где EDR зафиксировал и «устранил» угрозу.
- Пересмотрите политику игнорирования низкоприоритетных алертов. Выделите ресурсы на выборочное расследование информационных уведомлений, особенно на конечных точках.
- Обновите правила фильтрации фишинга с учётом злоупотребления доверенными платформами. Добавьте проверку ссылок на Vercel, CodePen, OneDrive в контексте входящей почты.
- Проведите аудит конфигураций S3-бакетов с фокусом на управление доступом, логирование и межаккаунтные политики. Повысьте приоритет этих находок в процессах управления уязвимостями.
- Замкните цикл обратной связи: результаты расследований низкоприоритетных алертов должны возвращаться в настройку правил детектирования. Без этого система не самосовершенствуется.
Ключевой вывод из этих данных — не в конкретных цифрах (которые требуют независимой верификации), а в системной закономерности: модель триажа, основанная на уровнях критичности, создаёт предсказуемые слепые зоны, и атакующие целенаправленно их эксплуатируют. Первый конкретный шаг — провести ретроспективный анализ алертов, закрытых EDR как «устранённые» за последние 90 дней, с применением независимого форензик-инструмента для проверки оперативной памяти хотя бы на выборке из 5–10% хостов.
