Кейс RED Security: как отличить ИИ от человека в автоматизированной кибератаке

Хабр, привет! 

На связи Никита Полосухин, ведущий аналитик центра мониторинга и реагирования на кибератаки RED Security SOC. В этом посте расскажу о недавней атаке на крупную российскую коммерческую компанию. В расследовании атаки участвовала наша команда. Атакующий прошел через цепочку уязвимостей внешнего и внутреннего периметра, полностью скомпрометировал домен организации — и все с помощью ИИ. Не буду разливать воду, сразу к делу.

Как развивалась атака

Самый ранний след в доступных журналах — GET /.git/config к одному из публичных ресурсов заказчика. Примерно через четыре с половиной часа активной разведки злоумышленник получил административный доступ к двум инсталляциям веб-приложения через административные креды по умолчанию (поверьте, подобрать их было несложно). Через штатную загрузку файлов он разместил PHP-вебшеллы и начал выполнять команды в контейнерах приложения.

Дальше злоумышленник перешел ко внутренней разведке. В конфигурациях приложения нашлись реквизиты для LDAP, SSO и других систем. Через сервис управления метаданными OpenMetadata атакующий получил параметры SQL-подключений к серверам MSSQL, а затем использовал связи linked server для выполнения xp_cmdshell на других серверах. Этот путь привел к выполнению команд на Windows и последующему получению SYSTEM.

Параллельно злоумышленник разбирался с доменной инфраструктурой. В SYSVOL он нашел групповую политику с полем cpassword. Из нее восстановил пароль учетной записи и использовал для дальнейших подключений. Отдельная ветка атаки прошла через ошибку настройки AD CS, приводящую к эксплуатации ESC1: атакующий получил сертификаты администратора домена и выполнил DCSync.

Дамп базы данных положили в публичный каталог захваченного веб-приложения и скачали. Таким образом, от начала разведки до компрометации домена прошло 7 часов 40 минут, а от первого успешного POST к вебшеллу — 2 часа 14 минут.

Помимо доменной ветки были скомпрометированы отдельные приложения: 

• повышались роли в различных приложениях;

• создавались новые учетные записи администраторов;

• менялись интеграции;

• проверялось чтение файлов через API.

Некоторые из этих сценариев продолжались несколько часов.

Казалось бы, что тут интересного — инцидент как инцидент. В нашей практике бывали кейсы захвата домена менее чем за 20 минут. Да и пути злоумышленников бывали запутаннее. Но все изменилось, как только мы получили контейнеры точки входа.

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

Проведя глубокий анализ всех находок, мы обнаружили немало артефактов, которые явно указывали на то, что атаковали полностью (не частично, и не на разных этапах, а именно полностью) с помощью ИИ. Такое в нашей практике впервые.

Разведка на нескольких направлениях

По каким же признакам мы опознали ИИ? Рассказываю подробно. 

Ручной скан обычно выглядит последовательно: выбрать эндпоинт, параметр, отправить запрос, посмотреть ответ и решить, как действовать дальше. Массовые сканирования известными утилитами также быстро выявляются по признакам, например User-Agent. Во всех расследованиях ранее мы видели, как злоумышленники автоматизируют ранние этапы атаки, а дальше эксплуатируют найденные уязвимости вручную. 

В нашем случае признаки «осознанной ручной» эксплуатации обнаружились сразу на нескольких внешних приложениях. В одном месте перебирались способы загрузки файлов и расширения, специфичные для приложения, в другом — параметры получения документов, в третьем — входные данные API. При этом такие проверки шли параллельно сразу на нескольких целях.

Для всех внутренних сканирований и атак злоумышленник использовал скомпрометированные контейнеры Приложения А. При этом все HTTP-запросы шли с User-Agent curl или python requests. За примерно три с половиной часа в журналах веб-шелла набралось около 1600 POST-запросов на выполнение различных команд. Разнообразие действий раскрывалось уже по телам запросов и оставшимся на диске программам. Во внешней разведке встречались также браузероподобные User-Agent для обхода WAF.

Примечательно, что внешнее сканирование и попытки эксплуатации внешних уязвимостей продолжались и после получения прав администратора домена, что нелогично с точки зрения достижения какого-то прикладного результата. По характеру работы злоумышленника складывалось ощущение, что он хочет найти как можно больше независимых точек проникновения, а не достичь конкретной цели.

Закрепление и основной канал управления

У оператора атаки следующий логичный шаг после входа в инфраструктуру — организовать доступ ко внутренней сети: поднять туннель, проксировать нужные соединения, развернуть средства управления. Для этого подходят разные тулзы: от стандартных chisel и sliver до чего-то экзотического и самописного.

Но в нашем случае злоумышленник решил так не делать. Он закрепился только в скомпрометированном веб-приложении, а весь код создавался (в виде отдельных скриптов) и выполнялся внутри контейнеров.

При этом атакующий пробовал расширять и способы выполнения команд. Среди ВПО был файл i1553.php (про нейминг еще поговорю ниже) с функциями проксирования трафика, а не только опцией выполнения команд. На внутренних Windows-серверах размещались CGI- и ASP.NET-вебшеллы, выполнение на которых тоже «проксировалось» через начальный вебшелл. Для одного из вариантов сделали даже отдельный IIS pool и открыли правило для TCP/8888 на локальном firewall.

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

Выполнение через множество небольших скриптов

Переходим к, наверное, самому жирному поведенческому признаку ИИ.

Очевидно, что работать через инструменты типа bloodhound или certipy удобнее, чем каждый раз писать отдельную команду. В нашем кейсе готовые средства тоже присутствовали — Impacket, Certipy, инструменты повышения привилегий типа PrintSpoofer или GodPotato. Но устанавливались они не на машину атакующего, а в скомпрометированный контейнер веб-приложения. Вокруг них также оказалось множество небольших программ и обвязок под конкретные задачи.

В контейнерах остались скрипты на Python, PHP, shell и PowerShell, скрипты BAT. Часто PowerShell-команда была встроена прямо в Python-скрипт или BAT-файл. Рядом лежали выгрузки, результаты запросов, промежуточные ответы и следующие версии проверок.

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

По меткам времени файлов удалось определить скорость их создания. За минуту злоумышленник создавал до 13 скриптов на различных языках программирования, а вместе с результатами и прочими вспомогательными файлами — 25 файлов. Впечатляет, не правда ли?! И здесь палка о двух концах. С одной стороны, мы видим этапы выполнения, что само по себе редкость, и по ним можно восстановить карту атаки. С другой — все файлы нужно исследовать, пропустить через себя и скоррелировать.

Например, такой цикл исправлений мы можем отследить на базе создания скриптов probe.py:

Бросалось в глаза и оформление результатов. Вывод разбивался по целям и отдельным проверкам: заголовки с ##########, разделители ---, статусные строки, итоговый маркер успешного выполнения команды. Это напоминало привычное структурирование ответа AI-ассистента. 

Работа в ширину после получения привилегий

Что делает злодей, получив привилегии? Закрепляется и начинает свою задачу. Есть разные сценарии: кража данных, кража и уничтожение, вымогательство или использование для последующих атак. Таким образом, мы ожидаем от злодея после получения привилегий внутреннюю разведку и сбор данных об инфраструктуре, что обычно и видим на практике.

Как я описал, наш злодей развивал параллельно несколько сценариев взлома разных систем. Что особенно интересно: после получения учетной записи администратора домена и проведения DCSync злоумышленник не остановил параллельные сценарии, а продолжили работу над ними, в том числе над получением доступа к системам, куда уже мог добраться по учетке админа домена. Кажется, чьи-то субагенты не договорились друг с другом.

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

Внешний взлом после захвата домена

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

В журналах backend мы нашли выдачу win.ini, а позднее — крупные ответы на запросы файлов из каталогов базы данных. К тому времени дамп NTDS.dit уже был получен, и попытаться получить доступ к этим данным через внутреннюю инфраструктуру было явно проще, чем искать уязвимость публичного API.

VirusTotal и номера в именах файлов

Проверка внешнего адреса на VirusTotal дала еще одну зацепку. В Community нашлась отметка ARTEX Found с портом 8787. ARTEX — инструмент для атак с помощью AI-агентов. Теперь можно было сопоставить наблюдаемую работу с конкретной реализацией.

Вернусь к именам. В разных частях атаки повторялся префикс i с числом. Номер 1696 встретился в созданной УЗ testadm1696 в одном из атакованных веб-приложений, загружаемых файлах i1696.php.xml и i1696probe.xlsx. Создание администратора, загрузки и обращения к соседней цели укладывались в несколько минут.

Другой номер, 1603, связывал этапы атаки внутри Linux-контейнера и атакованного Windows-сервера. На обоих нашли одинаковый командный файл, записывавший i1603_test.txt. Та же метка встречалась в ответах I1603_OK и HELLO_I1603 из запросов к ASPX-вебшеллам.

Третий номер, 1793, прошел через три внешних приложения за 26 секунд. На каждой цели проверялся файл i1793test.php или его вариации. Менялись системы и способы проверки, а номер оставался связан с одним сценарием.

На протяжении расследования мы видели много таких паттернов, и это стало характерным отпечатком злоумышленников. Так как по VT у нас была гипотеза про ИИ-агента ARTEX, мы решили сходить в репозиторий на GitHub.

Планировщик агента формирует специальные сущности — intent. Субагент получает такую подзадачу, выполняет, записывает результат и завершает работу. Несколько субагентов могут работать параллельно, а внутри одной подзадачи может выполняться целая последовательность команд.

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

Таким образом, высока вероятность гипотезы, что инфраструктуру нашего заказчика скомпрометировали с помощью ИИ-агента ARTEX.

Что мы выделили в этом кейсе

Для следующих расследований у нас остался короткий список наблюдений:

• Много небольших скриптов и команд, их вариантов и сохраненных результатов.

• Исправление проверок по полученным ответам.

• Высокий темп изменений при разнообразии задач.

• Несколько развивающихся направлений в одном временном окне.

• Продолжение независимых прикладных цепочек после захвата домена.

• Сквозные номера задач в файлах, УЗ и запросах к разным системам.

Такой набор файлов позволил достаточно детально восстановить картину атаки и общий kill chain злоумышленника.

Что это меняет для расследования

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

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

Количество данных быстро упирается в возможности внимания и рабочей памяти. Можно последовательно прочитать сотни файлов. Гораздо сложнее помнить, какой пароль откуда появился, в каких подключениях сработал, какой вариант проверки был удачным и где продолжалась другая ветка атаки. Возвращаясь к ней через несколько часов, аналитик вынужден погружаться заново в ее контекст.

Еще интереснее готовить отчет о реагировании. Здесь тот же подход работает уже не для отдельных скриптов и файлов, а для всей картины инцидента, что явно усложняет задачу. Успешный побочный сценарий легко потерять, когда ты уже увидел захват домена. 

Такие кейсы бросают вызов всем направлениям защиты. И с этим вызовом мы в RED Security SOC справились. Однако ожидаем умножения таких атак и обязательно будем приспосабливать методы не только реагирования и форензики, но и мониторинга и проактивной защиты от атак такой интенсивности.

Всем хорошего настроения и крепкого здоровья, на дворе осень, а ИИ-агенты уже вовсю бдят за вашими уязвимостями.