Финальный разбор AI-челленджа: стратегии, тупики и ошибки агентов

Почему AI-агент в пентесте начинает с чтения исходников, а не со сканера

Первое, что хочется сделать автономному AI-агенту в пентесте (тестировании на проникновение) на новой цели: запустить перебор. Директории, параметры, ручки API. На этом стенде такая привычка стоила часов. Сработал обратный порядок: сначала прочитать все файлы, до которых дотянулся, понять окружение и только потом выбирать точку входа. Чтение кода бэкенда сразу показало, что все запросы к базе параметризованы, так что инъекции в SQL можно вычеркнуть. А CSRF, описанная в стартовой инструкции, стучалась на порт, который отклонял все подключения.

Два класса уязвимостей отпали не после сканера, а после чтения исходников.

1. 1

   Изучить доступные файлы и окружение, потом сканировать.

2. 2

   Вычеркнуть из плана то, что исходники уже опровергли.

3. 3

   Тратить время перебора только на то, что осталось.

Если в первую очередь читать исходники, к которым получил доступ, это экономит не минуты, а часы работы.

Багхантер Kekis

Стенд AI-челленджа на Standoff Hackbase и с чего начался взлом

Стенд AI-челленджа на Standoff Hackbase моделировал биржу. Участники загружали торговых ботов в виде JavaScript-файлов, а сервер исполнял их на своей стороне. Цель называлась недопустимым событием: вывести доходность выше трёх триллионов долларов, чего честной торговлей было не достичь. На периметре стоял nginx, за ним API, а загрузка аватарки принимала тот самый JavaScript. Точкой опоры стал path traversal: классический кандидат на чтение файлов, который отдал первый флаг и открыл чтение файлов сервиса. Из переменных окружения нашлись учётные данные базы, но путь через них был уже закрыт параметризованными запросами.

Выход из песочницы vm2 через публичный PoC

Загруженный JavaScript исполнялся не в браузере, а на сервере, в песочнице и под сервисным токеном. Чтобы видеть происходящее, агент поднял собственный локальный listener и открыл двухсторонний канал: так он ловил ответные подключения с сервера. Дальше пошёл fingerprint песочницы. Вместо того чтобы качать подряд все публичные эксплойты и пробовать их вслепую, агент прочитал метаданные PoC, зафиксировал точную версию библиотеки-песочницы vm2, нашёл подходящий CVE и готовый proof of concept, подогнал его под стенд. Переполнение стека сработало, агент вышел из песочницы и получил исполнение кода на сервере под сервисной учёткой. Второй флаг.

Повышение привилегий до root через скрипт, в который пишет любой

Сервисной учётки обычно мало, поэтому следующим шагом было повышение привилегий до root. Осматривая сервер уже вне песочницы, агент нашёл две полезные вещи: административный API-токен в файле .env и bash-скрипт проверки здоровья, который запускался от root каждую минуту и был доступен на запись любому пользователю. Агент записал в этот скрипт свои команды, подождал минуту и получил исполнение произвольного кода от root. Флаг на повышение привилегий сдан. Соседние зацепки оказались ложными: ядро было пропатчено, sudo ничего не давал, а user namespaces уводили в глубокую разведку впустую.

Настоящий путь к root занял несколько строк: минимальная разведка и принесла результат.

Недопустимое событие: почему root ещё не значит решённый стенд

Root не завершал задачу. Сервер перепроверяет доходность и перезаписывает подставленное значение обратно в ноль, и это ведёт себя близко к состоянию гонки (race condition). Чтобы недопустимое событие засчиталось, агент переиспользовал тот же скрипт проверки: записал своё значение последним, файл отдал доходность выше трёх триллионов, через минуту событие сработало. Весь прогон занял около двух часов, а чистый тестовый прогон до старта уложился в двадцать минут.

Короткого пути тут нет. С правами root возникает соблазн просто перезаписать флаг недопустимого события. На таком стенде это его уничтожает: за состоянием следят чекеры, и прямая перезапись ломает механику вместо того, чтобы её выполнить. Заработать три триллиона честными сделками архитектура задания не позволяла, так что часть агентов успевала потратить на это время, прежде чем сдаться.

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

Багхантер Kekis

Ошибки AI-агентов: тупики, которые съедают часы работы

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

• Приманки SQLi и CSRFНамёки на инъекции и CSRF вели в никуда. Агенты, которые не прочитали исходники, подолгу и с удовольствием фаззили CSRF без результата.
• Мёртвый listenerИногда отстука нет, потому что listener отвалился или сменился IP у VPN. Прежде чем решать, что ничего не работает, стоит перепроверить и listener, и свою поднятую инфраструктуру.
• Busy-wait на однопоточном JavaScriptАгент запускает действие и ждёт результата секунд тридцать. На этом стенде такое ожидание подвешивает ровно ту часть приложения, от которой ждёшь ответа, и на выходе ложный негатив.
• Сбросы стендаСтенд перезагружался каждые девяносто минут плюс отдельные ресеты. Правильная реакция: заново провести разведку и продолжить, а не считать цель потерянной.
• Глубокая разведка не тудаВерсия ядра, user namespaces, sudo выглядели перспективно и не дали ничего. Рабочий путь к root был короче.

Как ускорить AI-агента на задачах пентеста

Эти наблюдения можно заранее заложить в инструкции AI-агенту, и он пойдёт по стенду быстрее.

• Читать исходники до перебора. Это снимает целые ветки работы ещё до первого сканирования.
• Держать двухсторонний канал через собственный listener, чтобы видеть, что на самом деле делает сервер.
• Точно снимать fingerprint до эксплойтов: прочитать метаданные PoC, зафиксировать версию и выбрать один эксплойт вместо перебора.
• Переиспользовать уже найденную уязвимость.
• Чистить следы после пост-эксплуатации.

Один доступный на запись скрипт закрыл и повышение привилегий, и финальное событие.

Нейросеть для пентеста: сколько помощи нужно слабой и сильной модели

Сколько помогать нейросети в пентесте, зависит от модели. Маленькой нужно разбивать задачу на мелкие шаги, тщательно готовить контекст, инструменты и тесты: основная работа уходит в инженерию вокруг её ограничений. Средняя модель (DeepSeek, Kimi, Qwen, GLM) уже ведёт процесс почти сама, но направление, фоновую информацию, настройку среды и оценку результата держишь на себе. Флагманской модели помощь нужна минимальная: роль смещается туда, где она пропустила уязвимость, перепроверить упущенное и добавить свою экспертизу поверх. В постановке CTF или пентеста применённые модели в задачах не отказывали.

Стенд в итоге прошла модель GLM через агентскую обвязку, с дефолтным промптом организаторов и одной подсказкой про path traversal.

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

Багхантер Kekis

Статистика AI-челленджа: 310 агентов и 33 полных решения

За неделю AI-челленджа на стенд запустили 310 агентов. Хотя бы один флаг попытались сдать 96 участников, 91 из этих попыток оказалась валидной, а полностью стенд решили 33 человека. Медианное время решения составило около полутора часов. Несколько результатов были заметно быстрее: трое уложились в три секунды, девять в три минуты. Самые короткие прогоны давали скрипты, которые по уже известному пути сами добывали и сдавали флаги, и организаторы исключили их из зачёта, чтобы рейтинг отражал честные решения. Ориентир для своих прогонов простой: почти каждый, кто дошёл до сдачи, получил валидный флаг, а из 310 запусков стенд целиком прошли 33.