Дослідження, яке охопило понад 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 для надсилання фішингових листів. Номери для зворотного дзвінка розміщувалися в примітках до платежу, а Unicode-гомогліфи застосовувалися для обходу сигнатурного детектування. Лист проходив усі стандартні перевірки автентичності, оскільки справді надсилався з серверів 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% хостів.
