Могут ли open‑source агенты заменить пентестера? Проверяем Strix и PentAGI на реальном проекте

Пятница, вечер. Багхантер открывает пиво, пока на его мониторе автономный агент четвертый час разбирает веб‑приложение компании. За это время он нашёл с десяток уязвимостей, проверифицировал несколько IDOR, сдал XSS и написал комментарий в тикете с RCE в legacy‑сервисе. Участие человека в этом процессе ограничилось открывашкой.

Именно так я всегда представляла жизнь счастливого багхантера. Теперь, когда подписка на модель со знанием всего интернета, стоит 20 баксов в месяц, а про open‑source LLM‑агентов для пентеста рассказывают в каждом коммьюнити‑чате, казалось бы, мечте пора сбыться.

Я решила проверить, может ли open‑source дать то же самое и сколько это будет стоить. Только вместо бенчмарков я взяла реальную инфраструктуру.

Как проводилось тестирование

• Сравнивала Strix и PentAGI.

• Модель: GLM 5.3.

• Скоуп: внешний периметр заказчика, ~200 активных хостов.

Коротко о Strix и PentAGI

Strix и PentAGI — open‑source LLM‑агенты для пентеста, которые сами ставят себе задачи для достижения цели, запускают инструменты, генерируют PoC и анализируют результаты.

Оба инструмента работают в изолированной Docker‑песочнице и легко разворачиваются.

Strix больше заточен под анализ веб‑приложений и кода. Анализировать безопасность периметра, например, с ним можно, но есть свои особенности, о которых расскажу ниже. PentAGI — более комплексная система, которая сама способна проводить полноценный пентест и более оптимизирована под длинный контекст.

При этом сравнение обоих инструментов важно также с той точки зрения, что у Strix транслируется философия верификации результатов через PoC. Это значит, что хотя Strix хуже справляется с большими скоупами, доля ложных срабатываний у него должна быть ниже, чем у PentAGI (спойлер: так и есть), а иногда это важнее, чем полная автономность.

TL;DR

• Strix и PentAGI сами планируют проверки, запускают инструменты, пишут скрипты и готовят отчёты. Но полноценную разведку и сбор реестра активов лучше делать отдельно: агенты рассчитаны на работу по конкретным целям.

• Автономность требует контроля. PentAGI распознал, что часть заданного диапазона принадлежит чужой организации, но продолжил её сканировать вопреки ROE.

• Strix почти не давал ложных срабатываний, но завышал критичность. После ручной проверки его 15 находок распределились так: 1 MEDIUM, 2 LOW и 12 INFO. Единственная HIGH оказалась доступом к публичной рыночной статистике.

• PentAGI нашел 296 уязвимостей, включая 42 CRITICAL и 50 HIGH. Ни одна из этих 92 находок не оказалась фактически эксплуатируемой. Среди «подтверждённых» PoC были чужие CVE и доказательства, подставленные из шаблона отчёта.

• При этом реальные серьёзные уязвимости на периметре были: 2 CRITICAL, HIGH с раскрытием OAuth‑секрета и цепочка до исполнения кода. Их нашёл коммерческий инструмент автономного поиска уязвимостей.

• Strix израсходовал 145,1 млн токенов, PentAGI — 31,4 млн. У Strix расход раздувается из‑за повторной передачи контекста десяткам субагентов, у PentAGI агрессивное сжатие создаёт риск потери деталей и зацикливания на больших скоупах.

• В этом исследовании заменить пентестера не получилось. Оба инструмента могут помогать с проверками, но контроль скоупа, триаж фолзов и оценка реального риска остаются за человеком.

Разведка

Ни Strix, ни PentAGI НЕ умеют из коробки проводить верхнеуровневую разведку скоупа. Нельзя задать им абстрактный верхнеуровневый скоуп (название организации / ИНН / корневой домен / диапазон сетей) и получить актуальный, воспроизводимый реестр активов (IP‑адреса, домены, веб‑приложения, порты и так далее). Разведка ведётся в границах явно заданной конкретной цели, и её результат — побочный продукт пентест‑прогона, а не инвентарь активов. То есть по‑хорошему разведку нужно выполнять отдельными инструментами, а Strix/PentAGI подключать уже для работы по конкретным целям.

Я собрала примерный скоуп, и все же запустила PentAGI на разведку. Strix так не запустить, потому что он требует конкретные цели (--target / -t / --target-list); свободная инструкция у него есть (--instruction), но она не заменяет обязательную цель. У PentAGI же скоуп задаётся прямо в промпте, поэтому разведку по примерному скоупу запросить удалось.

Результаты разведки

На самом деле первая миссия PentAGI у меня не запустилась сразу, потому что PentAGI под каждую миссию поднимает Kali‑песочницу, а образ почему‑то не был скачан. В итоге флоу застрял на шаге подготовки sandbox даже до первого обращения к LLM.:)

Когда я это исправила, PentAGI сразу возобновил работу.

Длительность разведки: ~6 ч 41 мин

Детали разведки

Этапы работы PentAGI

Этап	Время
Нормализация скоупа, подготовка списка целей	4.3 мин
Резолв всех хостнеймов	23 мин
Обнаружение живых хостов + полный TCP‑скан портов по обоим CIDR	189.7 мин (~3.2 ч)
Фингерпринтинг сервисов	21.4 мин
Энумерация веб‑приложений по IP и всем резолвнутым хостам	96.6 мин (~1.6 ч)
Корреляция активов, валидация покрытия, финальный отчёт	51.7 мин

Запущенные инструменты

Инструмент	Число вызовов	Назначение
host	622	DNS‑резолв хостнеймов
python3	137	запуск собственных скриптов‑сканеров
nmap	94	сканирование портов/сервисов
curl	86	HTTP‑пробы
dig	52	DNS‑запросы (fallback, CHAOS)
whois	40	владение CIDR, RDAP/ASN
whatweb	28	фингерпринтинг веб‑технологий
openssl	28	TLS‑сертификаты
masscan	17	скан портов
ncat / nc	20	пробы сокетов
httpx	10	обнаружение живых веб‑сервисов
hping3	7	низкоуровневые пакетные пробы
ping	6	ICMP‑проверки

Помимо готовых тулз агент сам написал 23 скрипта (Python + shell) для собственной логики разведки.

Результаты разведки:

• Скоуп: 177 хостнеймов + 2 CIDR = 768 адресов;

• резолвятся in‑scope: 39 хостов → 27 уникальных in‑scope IPv4;

• живых хостов: 36, из них 32 — с ≥1 открытым TCP‑портом;

• открытых TCP‑портов: 39;

• отвечающих веб‑приложений: 280.

Глубина разведки

— Из любопытного: агент обнаружил, что прозрачный middlebox подделывает ICMP и SYN‑ACK на все адреса. В результате признал вывод SYN‑сканов невалидным и переключился на побайтовое подтверждение ответа на уровне приложения (HTTP/TLS/SIP/DNS/FTP‑баннеры).

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

Выход за границы скоупа

Несмотря на то, что я установила proof‑only проверки и жесткие Rules of engagement (ROE), которые требовали у агентов запросить разрешение на выполнение любых критичных действий, PentAGI все равно вышел за границы скоупа.

Верхняя половина заявленного CIDR — подсеть, которая по WHOIS принадлежит другой, не связанной организации. Когда агент это заметил, он переопределил эффективный скоуп, сделал пометку CRITICAL SCOPE BOUNDARY, в итоговую отчетность чужую подсеть не включил, но сканирование чужого скоупа не прекратил. Мне пришлось вручную его останавливать, чтобы он не успел просканировать несогласованную подсеть.

Поиск уязвимостей, завышение уровня риска и фолзы

На одном и том же скоупе PentAGI искал уязвимости почти в 2 раза дольше.

Сравнительная таблица результатов

Совпадение с реальной критичностью у Strix около 33%, у Pentagi — 3%.

Strix завышает severity

Ложных срабатываний у Strix почти нет. Каждая находка подкреплена конкретными доказательствами и связанным HTTP‑трафиком. Основная проблема появляется в оценке бизнес‑критичности. Я вручную перепроверила все 15 находок и выяснила, что технически Strix приводит корректные подтверждения, но крайне плохо связывает их с реальными рисками.

Показательный пример — единственная уязвимость высокой степени риска. Strix нашел API‑методы, которые отдавали финансовые данные без аутентификации. Только эти финансовые данные были публичной рыночной статистикой, которую организация и так официально раскрывает инвесторам.

Более того, раскрытие внутренних имён и единичные пробелы авторизации получают средний риск, хотя фактический impact — INFO или LOW.

Архитектура работы Strix при поиске уязвимостей

Root‑агент развернул 41 дочерних агента (итого 42). Работа была разбита на последовательные этапы:

1. Разведка (7 агентов) по блокам сетей и зонам.

2. Таргетное read‑only тестирование: API‑портал, VPN‑шлюзы/Check Point, legacy‑порталы, браузерный обход основного приложения, Bitrix‑сайты и так далее

3. Уточнение и репортинг (1 агент): дозаполнение подтверждённых находок отчётами.

Использованные CLI‑инструменты: HTTP‑пробы curl, массовый DNS‑резолв host, собственные Python‑скрипты python3, httpx, точечный nmap; + TLS‑матрицы/DNS‑CHAOS‑пробы на уровне протокола.

PentAGI фабрикует доказательства

Здесь проблема другого характера и серьёзнее.

PentAGI нашел 296 уязвимостей, включая 42 критических и 50 высоких. (Не будем представлять лицо вашего тимлида после просмотра такого отчета)

В качестве пример разберу коротко одну группу таких находок. У этой группы была метка confirmed-with-PoC, то есть «подтверждено рабочим эксплойтом».

Для CMS сайта‑визитки PentAGI нашел четыре CVE: SQL‑инъекцию, обход аутентификации, preauth SQL‑инъекцию, stored XSS.

Все четыре оказались невалидны. Вот это «доказательство» — Fingerprint‑хэш, который должен подтверждать версию уязвимого продукта — существует только как захардкоженная константа внутри генератора отчёта. При этом ни в одном файле с доказательствами его нет, то есть PoC просто не выполнялся.

На самом деле PentAGI определил продукт по баннеру, «вспомнил» похожие по названию CVE, подставил хэш из шаблона отчёта и выдал это как подтвержденный эксплойт.

Из 92 критических/высоких уязвимостей 0 фактически эксплуатируемы. Это все оказались гипотезы по результатам баннерного анализа или галлюцинации.

Архитектура работы PentAGI при поиске уязвимостей

Primary‑agent оркестрировал специализированные роли: generator (планирование подзадач), installer (подготовка окружения), pentester (основная работа), coder (написание скриптов/wrapper), searcher (OSINT‑поиск), memorist (долговременная память), refiner (уточнение), reflector, summarizer (сжатие контекста), reporter (финальный отчёт).

Использованные CLI‑инструменты: python3, host, curl,nikto, nuclei, nmap, whatweb, openssl, dig, httpx, ping, gobuster, ffuf, sqlmap, nc, dirb.

А были ли вообще на этом скоупе уязвимости?

Да, было 2 критические уязвимости, включая RCE в конверторе документов, высокая с раскрытием OAuth‑секрета, с десяток средних и другие уязвимости низкой и информационной степени риска. Причем через менее критичные уязвимости можно было построить многошаговую цепочку атак, которая приводила к исполнению кода. И да, эти находки и недопустимое событие тоже нашел ИИ, но это был коммерческий продукт по автономному поиску уязвимостей.

Затраты токенов и управление контекстом

Что такое управление контекстом и зачем оно нужно

Для того, чтобы модель выполнила задачу, ей нужен соответствующий контекст. Прошлые вызовы она не помнит, поэтому на каждом шаге агент должен заново отправлять системный промпт, описания инструментов, результаты их работы и всю историю. Без управления контекстом стоимость одного прогона начинает колоссально расти. Это не имеет большого значения, когда проверка короткая — например, когда проверили один эндпоинт. Но когда проверка занимает сотни шагов, скоуп большой или используется маленькая модель, начинает страдать качество, появляются сбои и задержки работы агентов.

Управление контекстом у Strix и PentAGI

Управление контекстом у Strix и PentAGI построено примерно одинаково:

1. Обрезать вывод инструментов до того, как он попадет в историю.

2. Сохранять полный вывод во внешнее хранилище (в файл или векторную БД), чтобы агент мог его дочитать.

3. Пересказывать старую историю в резюме.

4. Разделять контексты: подзадачи и подагенты со своей короткой историей.

5. Хранить важную информацию во внешних файлах, которые не затрагивает сжатие.

6. Кэшировать неизменный префикс: системный промпт и инструменты.

Strix хотя и показывает лучше находки, он тратит существенно больше токенов. Это происходит из‑за того, что он разбивает задачу на несколько десятков суб‑агентов и каждому заново скармливает тот же системный промпт и ROE. В итоге 97% входных токенов — повторно поданный контекст. Дробление защищает окно каждого агента от переполнения, но увеличивает общий расход токенов.

PentAGI использует агрессивное сжатие для поддержки контекста (в моем флоу агент‑суммаризатор отработал 279 раз). При этом такой подход тоже имеет свои недостатки. Чем обширнее будет скоуп, тем чаще и грубее будет сжатие, потеря точности, и соответственно, выше шансы того, что агент что‑то «забудет» и зациклится. Кстати, это зацикливание у PentAGI скорее всего произойдет раньше, чем переполнение контекста у Strix. Я бы сказала, что ~250 целей для обоих инструментов будет нормально, но когда их будет 300–500 начнутся первые сбои и взлетит расход токенов.

Что из всего этого следует

Оба инструмента неплохо ищут уязвимости (хотя Strix все‑таки справляется лучше PentAGI). Они автономно работают, сами планируют проверки, запускают инструменты и формируют отчеты. Если им задать направление анализа, возможно они даже найдут реально критичные уязвимости (в крайнем случае PentAGI их просто придумает:)), но все‑таки большая работа по контролю этих инструментов и ручному триажу остается.

Если вы собрались писать свой собственный инструмент, учитывайте архитектурные проблемы обоих решений: разрастание общей памяти у Strix и деградация сжатия у PentAGI. Ну, и если быть совсем уж честной, на самом деле таких инженерных проблем намного больше, потому что задача «найти уязвимости» отличается от задачи «стабильно находить уязвимости». Последнее должно показывать одинаково качественный результат на разных скоупах, LLM‑моделях, сроках работы и так далее

---

Если вы уже тестировали open‑source инструменты для пентеста, поделитесь в комментариях, чем все закончилось — интересно почитать, какой опыт был у вас.