Hermes agent

Web Pentest

Авторизованное тестирование веб-приложений на проникновение: разведка, анализ уязвимостей, доказательная эксплуатация и профессиональная отчётность. Навык адаптирует методологию Шеннона «No Exploit, No Report» с жёсткими ограничениями по скоупу, авторизации и утечкам через вспомогательный клиент. Работает с живыми приложениями, которыми вы владеете или на тестирование которых есть письменное разрешение.

Метаданные навыка

ИсточникОпциональный (устанавливается по запросу) — установить командой hermes skills install official/security/web-pentest
Путьoptional-skills/security/web-pentest
Платформыlinux, macos

Справочник: полный SKILL.md

инфо

Ниже — полное определение навыка, которое Hermes Agent загружает при его активации. Именно это агент видит как инструкцию во время работы навыка.

Web Application Penetration Testing

Пошаговый воркфлоу пентеста для работающих веб-приложений. Адаптировано по пайплайну Шеннона (Keygraph, AGPL — только концепции, код не заимствован). Три базовых правила:

  1. No exploit, no report — каждая находка требует воспроизводимых доказательств.
  2. Ограниченный скоуп — каждый активный запрос идёт только к цели, заранее объявленной оператором. Хосты вне скоупа отклоняются.
  3. Перебор обходов перед признанием ложноположительным — заблокированный пейлоад не означает отсутствие уязвимости, пока не пройден полный набор обходов.

⚠️ Жёсткие ограничения — читать перед каждым тестированием

Нарушение любого из них аннулирует тест и может быть незаконным.

  1. Ворота авторизации. Перед первым активным сканом в сессии вы ОБЯЗАНЫ письменно подтвердить с пользователем, что он владеет целью или имеет письменное разрешение на её тестирование. Зафиксируйте подтверждение в engagement/authorization.md (см. шаблон). Без подтверждения — никакого активного сканирования. Читать публичные страницы через curl допустимо; отправлять пейлоады — нет.

  2. Список разрешений скоупа. Ведите engagement/scope.txt — по одному имени хоста или CIDR на строку. Каждый nmap, curl, whatweb, переход браузера или запрос с пейлоадом ДОЛЖЕН идти только к записям из скоупа. Если цель перенаправляет вас за его пределы (3xx на другой хост, ссылка в HTML) — СТОП, уточните у пользователя перед переходом.

  3. Никаких продакшн-систем без бумаги. Если пользователь явно не сказал «да, прод в скоупе и у меня есть письменное разрешение» — считайте, что нет. По умолчанию цели: стейджинг, локальный docker, выделенные тестовые инстансы.

  4. Облачные метаданные отключены по умолчанию. Не зондировать 169.254.169.254, metadata.google.internal, 100.100.100.200, [fd00:ec2::254] и аналоги, если в тестировании явно не предусмотрен SSRF до метаданных И цель под вашим контролем. Браузерный инструмент агента может достучаться до них изнутри вашей инфраструктуры — не нужно.

  5. Деструктивные пейлоады — только с одобрения. SQLi-пейлоады с DROP/DELETE, SSTI с записью в файловую систему, command injection с rm/shutdown/mkfs, всё, что меняет данные за пределами одной тестовой строки — СНАЧАЛА СПРОСИТЬ. Система approval.py отлавливает часть случаев; полагаться только на неё нельзя.

  6. Риск утечки через вспомогательный клиент (специфично для Hermes). Навык генерирует сессии, насыщенные SQLi/XSS/RCE-пейлоадами, перехваченными учётными данными и JWT-токенами. Пути сжатия и генерации заголовков в Hermes Agent прогоняют историю через вспомогательный клиент (как правило, основную модель). Всё чувствительное, записанное в переписку, может покинуть машину при следующем сжатии. Меры защиты:

    • Перехваченные токены и учётные данные перед записью в любое сообщение обрезайте до ПОСЛЕДНИХ 6 СИМВОЛОВ. Полные значения — только в файлы engagement/evidence/, никогда в историю чата.
    • Для чувствительных тестирований установите auxiliary.title_generation.enabled: false в ~/.hermes/config.yaml на время сессии.

  7. Ограничивайте частоту запросов. По умолчанию — 200 мс между активными запросами к одному хосту. Скрипт recon-scan.sh это обеспечивает. Не обходить без согласия оператора.

  8. Сила отчёта. Навык производит оценку безопасности, а не «ПРОШЁЛ». Даже чистый прогон — это «в скоупе X за время T методами Y эксплуатируемых проблем НЕ ОБНАРУЖЕНО», а не «приложение защищено». Используйте именно такие формулировки в отчёте.

Фаза 0: Подготовка тестирования

До начала любого сканирования создайте директорию тестирования и зафиксируйте авторизацию.

ENGAGEMENT=engagement-$(date +%Y%m%d-%H%M%S)
mkdir -p "$ENGAGEMENT"/{evidence,findings,reports}
cd "$ENGAGEMENT"

  1. Спросить пользователя (дословно):

    “Confirm: (a) the target URL is [X], (b) you own this application or have written authorization to test it, and (c) the engagement may run for up to [N] hours starting now. Reply ‘authorized’ to proceed.”

  2. Дождаться явного ответа authorized. Любой другой ответ — СТОП.

  3. Зафиксировать авторизацию в engagement/authorization.md по шаблону из templates/authorization.md. Включить:

    • URL(ы) и IP(ы) цели
    • Основание авторизации (владение / письменное разрешение от $name)
    • Временное окно тестирования
    • Элементы вне скоупа (продакшн, сторонние сервисы и т.п.)
    • Имя оператора (пользователь, управляющий сессией)

  4. Сформировать scope.txt:

    localhost
127.0.0.1
staging.example.com
192.168.1.0/24    # internal lab only, with operator OK

  5. Прочитать references/scope-enforcement.md перед отправкой первого активного запроса — там правила извлечения хоста, которые применяются к каждой команде/URL перед отправкой.

Фаза 1: Предварительная разведка (анализ кода, опционально)

Пропустить, если нет доступа к исходникам (тестирование методом чёрного ящика).

При наличии доступа на чтение к коду приложения:

  1. Составить карту архитектуры — фреймворк, маршрутизация, стек middleware
  2. Инвентаризировать синки — каждый execute(, os.system(, eval(, рендер шаблонов, чтение/запись файлов, цели редиректов
  3. Карта аутентификации — сессионная cookie vs JWT, OAuth-потоки, сброс пароля, привилегированные эндпоинты
  4. Определить границы доверия — что аутентифицировано, что нет, что берётся из request.*
  5. Обратный taint от каждого синка к источнику запроса. Ранний выход при обнаружении правильной санитизации (параметризованные запросы, списки разрешений, shlex.quote, проверенные эскейперы).

Результат: evidence/pre-recon.md — карта архитектуры, инвентарь синков, подозрительные уязвимые пути.

Это ОФФЛАЙН-работа. Никакого трафика к цели.

Фаза 2: Разведка (живая, только чтение)

Картирование поверхности атаки. Все запросы — GET-ы публичных страниц, пейлоадов пока нет. По-прежнему ограничено скоупом.

  1. Проверить скоуп. Резолвить каждое имя хоста → IP. Убедиться, что IP в скоупе — это страховка от случаев, когда DNS ведёт куда-то неожиданному.

  2. Сетевая поверхность (только если скоуп допускает сканирование портов):

    nmap -sT -T3 --top-ports 100 -oN evidence/nmap.txt $TARGET

    Использовать -T3 (по умолчанию), не -T4/-T5. Менее шумно и не триггерит IDS/IPS в общих средах.

  3. Отпечаток технологий:

    whatweb -v $TARGET_URL > evidence/whatweb.txt
curl -sIk $TARGET_URL > evidence/headers.txt

  4. Обнаружение эндпоинтов:

    • Обойти приложение браузерным инструментом (browser_navigate, browser_get_images, следовать ссылкам).
    • Проверить robots.txt, sitemap.xml, .well-known/*.
    • Использовать панель сети в инструментах разработчика через браузерный инструмент для перехвата XHR/fetch-вызовов.

  5. Поверхность аутентификации: Найти логин, регистрацию, сброс пароля, имена сессионных куки, форматы токенов. Учётные данные НЕ отправлять — только наблюдать.

  6. Сопоставить с предварительной разведкой (при наличии исходников). По каждой находке из evidence/pre-recon.md пометить, подтверждает ли живая поверхность её доступность.

Результат: evidence/recon.md — эндпоинты, технологии, модель аутентификации, векторы ввода.

Фаза 3: Анализ уязвимостей

Один delegate_task на класс уязвимостей. Каждый агент читает evidence/recon.md (и evidence/pre-recon.md, если есть), создаёт findings/<class>-queue.json по схеме templates/exploitation-queue.json.

Запустить delegate_task со следующими специализированными субагентами (где возможно — параллельно):

КлассЦельСправочник
injectionSQLi, command injection, path traversal, SSTI, LFI/RFI, десериализацияreferences/vuln-taxonomy.md (типы слотов)
xssReflected, stored, DOM-basedreferences/vuln-taxonomy.md (контексты рендера)
authОбход логина, JWT confusion, session fixation, уязвимости OAuthreferences/exploitation-techniques.md
authzIDOR, вертикальная/горизонтальная эскалация, бизнес-логикаreferences/exploitation-techniques.md
ssrfДоступность внутренней сети, метаданные, protocol smugglingМетаданные не зондировать без явной авторизации
infraМисконфигурации, раскрытие информации, учётные данные по умолчанию, открытый adminreferences/exploitation-techniques.md

Каждая запись очереди содержит: id, класс уязвимости, источник (файл:строка, если известно), эндпоинт, параметр, тип слота, предполагаемая защита, вердикт (identified / partial / confirmed / critical), witness payload, уверенность (0–1), заметки.

Фаза анализа вредоносных пейлоадов не отправляет — только подготавливает их. Реальная отправка — в фазе эксплуатации.

Фаза 4: Эксплуатация (доказательная, условная)

Субагент на каждый класс запускается только при наличии в очереди анализа активных записей (identified или partial).

Для каждого кандидата:

  1. Проверка перед отправкой — хост в скоупе? авторизация есть? пейлоад одобрен, если деструктивный?
  2. Отправить witness payload — минимальное доказательство. SQLi: ' AND 1=1-- затем ' AND 1=2--. XSS: безобидный маркер вроде <svg/onload=console.log("HERMES-PENTEST-XSS")>. Никогда не использовать alert(1) в stored XSS — сработает для других пользователей в общих средах.
  3. Убедиться, что witness срабатывает — для слепой инъекции использовать sleep-пробу (SLEEP(5)) и замерить время ответа. Для SSRF — callback-хост под вашим контролем (не публичные сервисы типа webhook.site для чувствительных тестирований — это путь утечки).
  4. Повысить уровень:
    • L1 Identified — паттерн найден, поведение не изменилось
    • L2 Partial — синк достигнут, но защита на месте
    • L3 Confirmed — пейлоад изменил поведение приложения наблюдаемым образом
    • L4 Critical — данные извлечены, код выполнен, доступ эскалирован
  5. Перебор обходов перед признанием ложноположительным. Для каждого заблокированного кандидата: опробовать как минимум набор обходов из references/bypass-techniques.md для данного класса. Только после исчерпания набора допустимо записать verdict: false_positive.
  6. Зафиксировать доказательства для каждого L3/L4:
    • Полный запрос (метод, URL, заголовки, тело)
    • Ответ (статус, заголовки, релевантный фрагмент тела)
    • Команда для воспроизведения (curl одной строкой)
    • Описание последствий

Результат: findings/exploitation-evidence.md

Обязательное редактирование в файлах доказательств:

  • Перехваченные учётные данные/токены → только последние 6 символов в чате; полные значения — в findings/secrets-vault.md (добавлен в .gitignore).
  • PII других пользователей → редактировать.
  • Ваши тестовые учётные данные → можно оставить.

Фаза 5: Отчётность

Сформировать итоговый отчёт по шаблону templates/pentest-report.md. Разделы:

  1. Краткое резюме для руководства
  2. Скоуп тестирования (из engagement/scope.txt)
  3. Авторизация (из engagement/authorization.md)
  4. Находки (только L3/L4 — обязательны доказательства). По каждой находке:
    • Название, критичность (CVSS 3.1), CWE
    • Затронутый(е) эндпоинт(ы)
    • Доказательство (запрос + фрагмент ответа)
    • Шаги воспроизведения
    • Последствия
    • Рекомендации по устранению
  5. Неэксплуатированные кандидаты (L1/L2 с пояснением, что их заблокировало)
  6. Наблюдения за пределами скоупа
  7. Методология / использованные инструменты
  8. Ограничения и что НЕ тестировалось

Политика критичности: CVSS только для L3/L4. L1/L2 — «кандидаты, ожидающие подтверждения» — CVSS для неподтверждённых находок не назначается.

Когда остановиться

  • Пользователь отзывает авторизацию.
  • Найденная уязвимость явно затрагивает продакшн-данные, а разрешения на деструктивное тестирование нет — СТОП, уточнить у оператора.
  • Цель начала возвращать шторм 503/429 — отступить, обсудить с оператором.
  • Обнаружено что-то вне согласованного скоупа (например, открытая база клиентов при тестировании несвязанного эндпоинта). СТОП, зафиксировать, сообщить оператору. Развивать атаку без явного одобрения нельзя — именно этот шаг делает пентест незаконным.

Что навык НЕ охватывает

  • Пентест на сетевом уровне за пределами сканирования портов (нет Metasploit, Cobalt Strike, атак на AD, фаззинга сетевых протоколов).
  • Реверс-инжиниринг / анализ бинарных файлов (см. issue #383).
  • Статический анализ только по исходникам (см. issue #382).
  • Активная социальная инженерия / фишинг.
  • Любые действия против систем, не авторизованных оператором заранее.

Если тестирование требует чего-либо из перечисленного — привлекайте профессионального пентестера. Навык дополняет профессиональный пентест, но не заменяет его.

Дополнительные материалы

  • references/scope-enforcement.md — правила ограничения каждого активного запроса
  • references/vuln-taxonomy.md — типы слотов, контексты рендера, карта OWASP
  • references/exploitation-techniques.md — паттерны пейлоадов по классам
  • references/bypass-techniques.md — распространённые обходы WAF/фильтров
  • templates/authorization.md — шаблон авторизации тестирования
  • templates/pentest-report.md — шаблон итогового отчёта
  • templates/exploitation-queue.json — схема очереди находок по классам
  • scripts/recon-scan.sh — обёртка nmap+whatweb+headers с ограничением частоты запросов
⌕ ESC