11 мая 2026 года Google Threat Intelligence Group опубликовала отчёт, который стоит прочитать целиком, а не по пересказам. Суть: криминальная группировка скормила ИИ-модели исходный код open-source админки, получила zero-day - обход двухфакторной аутентификации через hardcoded trust assumption - и написала рабочий Python-эксплойт. Не PoC, не proof-of-concept «в лабораторных условиях», а боевой инструмент для массовой кампании. Вендор успел выпустить патч раньше, чем началась эксплуатация, - повезло. Для SOC-аналитиков и detection-инженеров вывод конкретный: ИИ 0-day уязвимость - задокументированный инцидент с финансовой мотивацией, и окно между обнаружением бреши и появлением боевого эксплойта сжимается до часов. Ваши SLA рассчитаны на такую скорость?
Что произошло: первый 0-day найденный ИИ
Согласно отчёту GTIG, атакующие использовали reasoning-capable LLM для анализа исходного кода open-source административной панели. Конкретная модель не названа, но GTIG явно указала - это не Gemini и не модели Anthropic. Атакующие маршрутизировали запросы через grey-market proxy-сервисы и автоматизированные пайплайны регистрации аккаунтов, обходя ограничения frontier-лабораторий. Проще говоря - купили доступ к модели через посредников, которые не задают лишних вопросов. Подробнее - в нашем материале про безопасность llm атаки.ИИ обнаружил семантическую ошибку в логике enforcement двухфакторной аутентификации: разработчик заложил жёстко закодированное исключение, которое противоречило общей политике 2FA-валидации. Это не переполнение буфера и не SQL-инъекция. Это высокоуровневый логический дефект - тот класс уязвимостей, который статические анализаторы и фаззеры системно пропускают, потому что код не падает. Он работает ровно так, как написано. Просто написано неправильно.
Бизнес-логика атаки: группировка имела финансовую мотивацию. Сценарий - обход 2FA → получение доступа с валидными учётными данными → масштабирование на множество целей в рамках массовой кампании. По данным Mandiant M-Trends 2025, эксплойты - наиболее распространённый вектор первичного доступа (38% расследований), опережающий phishing и prior compromise. AI-ускорение разработки эксплойтов сжимает то самое окно, на которое рассчитаны ваши SLA.
Маркеры AI-авторства в эксплойте
GTIG идентифицировала LLM-генерацию эксплойта по набору характерных артефактов - и вот тут интересно:- Галлюцинированный CVSS-скор. Эксплойт содержал оценку CVSS, не соответствующую ни одной записи в NVD. Модель «выдумала» метрику. Классическая галлюцинация - LLM уверенно генерирует несуществующие данные.
- Обучающие docstring'ы. Комментарии в стиле учебного материала, пошагово объясняющие логику эксплуатации. Настоящий атакующий не документирует свой инструментарий в формате tutorial - зачем ему?
- Шаблонный Python. Чистый ANSI color class, детальные help-меню, структура кода, характерная для учебных примеров из LLM training data. Код выглядит «слишком аккуратно» для боевого инструмента.
Следующий AI-crafted эксплойт таких следов не оставит. Убрать docstring'ы и подчистить CVSS-скор - задача на пару часов для любого оператора, прочитавшего тот же отчёт GTIG.
Почему ИИ для поиска уязвимостей находит то, что пропускают сканеры
Разница - в типе обнаруживаемых уязвимостей. Фаззеры (AFL++, libFuzzer) и SAST-инструменты (Semgrep, CodeQL) оптимизированы под поиск crashes, sinks и ошибок валидации ввода. Они молотят перебором: миллионы итераций с некорректными входными данными. Для memory corruption и injection - работает отлично.LLM с reasoning-способностями работают иначе. По данным отчёта GTIG, frontier-модели демонстрируют «возрастающую способность к контекстному рассуждению - эффективно читая намерение разработчика, чтобы соотнести логику применения 2FA с противоречиями жёстко закодированных исключений». Другой класс анализа: не «что сломается при неправильном вводе», а «что логически противоречит заявленной политике безопасности». Фаззер не найдёт hardcoded trust assumption, потому что код не падает - он выполняет то, что написано. Но написано неправильно.
Подтверждение из исследований: автономный поиск уязвимостей нейросетями
Anthropic в публикации о возможностях Claude в области vulnerability research сообщила об обнаружении и валидации значительного числа уязвимостей в open-source проектах (точная версия модели и количество уязвимостей требуют верификации по первоисточнику). Два кейса показывают, как LLM находит баги методами, недоступными фаззерам:GhostScript. Claude не нашёл уязвимость через фаззинг и ручной анализ, но обнаружил её, прочитав историю git-коммитов. Модель нашла патч, добавляющий проверку границ стека, затем нашла другой путь вызова той же функции (
gdevpsfx.c), где аналогичная проверка отсутствовала. По данным Anthropic, уязвимость существовала годами - в кодовой базе, которую фаззеры прогоняли миллионы CPU-часов. Годами. Миллионы CPU-часов. И не нашли.OpenSC. Claude идентифицировал последовательность вызовов
strcat без проверки длины результирующего буфера - buffer overflow в контексте, который фаззеры не покрыли.Исследование HPTSA (Fang et al., 2024) продемонстрировало мультиагентную систему на базе GPT-4, способную эксплуатировать реальные уязвимости с существенно более высокой эффективностью, чем традиционные open-source сканеры, показавшие 0% на том же наборе (точные метрики и объём бенчмарка требуют верификации по первоисточнику). Архитектура HPTSA использует иерархическое планирование: один агент исследует систему и определяет векторы атаки, затем запускает специализированных подагентов под конкретные классы уязвимостей.
Вывод для SOC прямой: если ваша модель угроз предполагает, что создание 0-day требует месяцев ручной работы квалифицированного исследователя - пора пересматривать. Автоматизация эксплуатации уязвимостей через LLM уже переходит из лабораторий в реальные кампании.
ИИ-агенты для взлома: TTPs по MITRE ATT&CK
Использование ИИ атакующими укладывается в конкретные техники MITRE ATT&CK - и это важно для построения корреляционных правил и классификации инцидентов.Resource Development:
T1588.007 - Artificial Intelligence (Resource Development). Получение или использование AI-модели как ресурса. В кейсе GTIG атакующие обходили safety-контроли через proxy-сервисы. Open-weight модели и grey-market прокси, по данным GTIG, достаточны для задач контекстного рассуждения, породивших 2FA bypass.
T1587.004 - Exploits (Resource Development). Разработка эксплойта. ИИ сгенерировал Python-скрипт с полной цепочкой эксплуатации 2FA bypass, включая те самые «обучающие» комментарии.
T1588.006 - Vulnerabilities (Resource Development). Получение информации об уязвимости. Здесь интересный момент: ИИ обнаружил уязвимость и создал эксплойт в рамках одной сессии - на мой взгляд, тут пересечение T1588.006 и T1587.004, хотя формально MITRE эти техники не связывает напрямую.
Initial Access:
T1190 - Exploit Public-Facing Application (Initial Access). Целевое приложение - веб-панель администрирования, доступная из интернета. Стандартный вектор.
Reconnaissance (отдельная активность):
T1595.002 - Vulnerability Scanning (Reconnaissance). Эта техника относится к отдельному вектору использования ИИ и не входит в описанный кейс с 2FA bypass. По данным вторичных источников, пересказывающих отчёт GTIG (точная формулировка требует верификации по первоисточнику), государственные группировки ряда стран предположительно используют публичные AI-сервисы для массового сканирования: тысячи повторяющихся запросов к моделям для рекурсивного анализа CVE и валидации PoC-эксплойтов.
Kill chain compression и масштаб
Помимо криминальных группировок, согласно отчёту GTIG, государственные акторы экспериментируют с агентными фреймворками для автономного исследования целей без постоянного участия оператора. Зафиксировано использование AI-генерированного decoy-кода в вредоносном ПО: блоки кода с LLM-авторскими комментариями, явно описывающие их как неиспользуемый filler, затрудняющий анализ. Точный маппинг в MITRE ATT&CK для этой техники не установлен - предположительно можно соотнести с T1587.001 (Malware), но это спекулятивная атрибуция. Специфического T-кода для AI-generated decoy-комментариев ATT&CK пока не выделяет (и, зная скорость обновления ATT&CK, нескоро выделит).Генеративный ИИ в кибербезопасности сжимает весь kill chain: discovery, weaponization и exploitation - в рамках одной сессии с моделью. Традиционный цикл incident response - detect, triage, contain, eradicate - рассчитан на то, что между появлением эксплойта и его массовым применением есть временной зазор. AI-assisted атакующие этот зазор ликвидируют.
Detection-чеклист при AI-ускоренных атаках: что менять в SOC
Действия расположены по приоритету - от немедленных до среднесрочных.- Пересмотреть SLA на emergency patching для web-facing сервисов. По данным IBM X-Force Threat Intelligence Index 2025, среднее время устранения CVE в организациях - 29 месяцев. Двадцать девять. При AI-ускоренной разработке эксплойтов это неприемлемо. Целевой SLA для critical web-facing приложений: часы, не дни.
- Приоритизировать мониторинг логических аномалий в authentication flows. AI-generated уязвимости чаще относятся к semantic logic flaws (обход проверок, нарушение trust assumptions), а не к injection/overflow. Создайте корреляцию на успешную аутентификацию без прохождения ожидаемых этапов MFA:
Код:
# Пример логики корреляции (требует адаптации под ваш SIEM)
# NB: поле mfa_challenge_completed не существует в SIEM из коробки -
# его нужно синтезировать корреляцией auth-success событий с логами
# MFA-провайдера (Duo, Okta, Azure MFA) по session_id/user_id.
rule auth_bypass_anomaly:
condition: auth_success AND mfa_challenge_completed == false
AND source NOT IN known_service_accounts
timeframe: 60s
severity: criticalSupply chain как второй фронт
Отдельный инцидент из того же отчёта GTIG: криминальная группировка скомпрометировала GitHub-репозитории, включая те, что связаны с AI-gateway библиотеками и инструментами сканирования уязвимостей, внедрив credential stealer в build-окружения. Компрометация AI-gateway библиотеки особенно опасна: она даёт доступ к AI-окружению организации, а значит - к данным, которые проходят через LLM, и к API-ключам, открывающим широкую поверхность атаки.В SIEM это отслеживается через мониторинг событий
git pull и pip install/npm install в CI/CD-пайплайнах, корреляцию с изменениями в dependency lock-файлах и алерты на новые outbound-соединения из build-серверов к неизвестным IP.Я наблюдаю за AI vulnerability research с позиции человека, который два года экспериментирует с LLM для анализа кода и fuzzing. Разница между «запустить Claude на open-source проект и получить десятки false positive» и «криминальная группировка прошла полный цикл от discovery до weaponization zero-day» - это разница между стрельбищем и боевыми. Неудобная правда: большинство SOC строят detection-модели, рассчитанные на human-speed атакующих. Аналитик видит новый CVE, ждёт PoC, пишет корреляцию. Когда этот цикл на стороне атакующего сжимается до одной сессии с моделью - процесс не успевает. Не потому что команда слабая, а потому что процесс проектировался под другую скорость.
Прогноз: через год мы увидим AI-generated эксплойты без тех «выдающих» маркеров, которые помогли GTIG. Docstring'ы и галлюцинированный CVSS - артефакты незрелости, устраняемые тривиально. Реальная точка приложения усилий - не forensics «какая модель сгенерировала код», а сокращение attack surface до того, как его начнут тестировать: вычистить hardcoded exceptions, свести emergency patching SLA к часам, запустить поведенческий мониторинг, работающий без сигнатур. Тематический тред с playbook'ом по detection AI-ускоренных TTP - на codeby.net.
