Web Application Penetration Testing with Hermes Agent: A Practical Guide

This skill turns Hermes Agent into an autonomous web application penetration tester. It follows a phased methodology adapted from Shannon's Keygraph pipeline, built on three rules: every finding requires reproducible proof, every request stays within a pre-declared scope, and you must exhaust bypass techniques before dismissing a blocked payload as a false positive. You would reach for this when you need a structured, repeatable, and documented pentest against a web application you own or have written authorization to test, and you want the agent to handle the reconnaissance, vulnerability analysis, exploitation, and reporting phases.

What it does

The skill implements a five-phase pentesting workflow: engagement setup, pre-recon (optional source code analysis), live reconnaissance, vulnerability analysis, proof-based exploitation, and professional report generation. It enforces hard guardrails around authorization, scope, and data leakage. The agent uses delegate_task to spawn focused sub-agents for each vulnerability class (injection, XSS, auth, authz, SSRF, infra), stages payloads during analysis, and fires them only during exploitation. Every L3/L4 finding gets a full request/response pair, a reproducer command, and an impact statement. The final report uses CVSS 3.1 for confirmed findings and explicitly states what was not tested.

Before you start

This is an optional skill, installed on demand. It runs on Linux and macOS. Before the first active scan in a session, you must confirm with the user, in writing, that they own or have written authorization to test the target. Record the acknowledgement in engagement/authorization.md. No acknowledgement means no active scanning. Reading public pages with curl is fine; sending payloads is not.

You need a target URL, an engagement window, and a clear understanding of what is in scope. The skill assumes default targets are staging, local Docker, or dedicated test instances. Do not target production systems without explicit written sign-off.

Phase 0: Engagement Setup

Create the engagement directory and authorization acknowledgement before any scanning happens.

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

1. Ask the user (verbatim):

"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. Wait for explicit authorized response. Any other answer means STOP.

3. Record authorization to engagement/authorization.md using the template in templates/authorization.md. Include:

   • Target URL(s) and IP(s)
   • Authorization basis (ownership / written authz from $name)
   • Engagement window
   • Out-of-scope items (production, third-party services, etc.)
   • Operator name (the user driving this session)

4. Build scope.txt:

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

5. Read references/scope-enforcement.md before issuing the first active request, that doc has the host-extraction rules you apply to every command/URL before it goes out.

Phase 1: Pre-Recon (Code Analysis, optional)

Skip if no source access (black-box engagement).

If you have read access to the application source:

1. Map the architecture, framework, routing, middleware stack
2. Inventory sinks, every execute(, os.system(, eval(, template render, file read/write, redirect target
3. Map auth, session cookie vs JWT, OAuth flows, password reset, privileged endpoints
4. Identify trust boundaries, what's authenticated, what's not, what comes from request.*
5. Backward taint from each sink to a request source. Early-terminate when proper sanitization is found (parameterized queries, allowlists, shlex.quote, well-known escapers).

Output: evidence/pre-recon.md, architecture map, sink inventory, suspected vulnerable code paths.

This is OFFLINE work. No traffic to the target.

Phase 2: Recon (Live, Read-Only)

Maps the attack surface. All requests are GETs of public pages, no payloads yet. Still scope-bounded.

1. Verify scope. Resolve every target hostname → IP. Confirm IPs are in scope (avoids the "DNS points somewhere unexpected" trap).
2. Network surface (only if scope permits port scanning):

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

Use -T3 (default), not -T4/-T5. Stealthier and avoids tripping IDS/IPS in shared environments. 3. Tech fingerprint:

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

4. Endpoint discovery:

   • Crawl the app with the browser tool (browser_navigate, browser_get_images, follow links).
   • Inspect robots.txt, sitemap.xml, .well-known/*.
   • Use the developer tools network panel via browser tool to capture XHR/fetch calls.

5. Auth surface: Identify login, registration, password reset, session cookie names, token formats. Do NOT send credentials yet, just observe.

6. Correlate with pre-recon (if you have source). For each evidence/pre-recon.md finding, mark whether the live surface confirms it's reachable.

Output: evidence/recon.md, endpoints, technologies, auth model, input vectors.

Phase 3: Vulnerability Analysis

One delegate_task per vulnerability class. Each agent reads evidence/recon.md (+ evidence/pre-recon.md if present), produces findings/-queue.json using templates/exploitation-queue.json.

Use delegate_task with these focused subagents (parallel where possible):

Class	Goal	Reference
injection	SQLi, command, path traversal, SSTI, LFI/RFI, deserialization	references/vuln-taxonomy.md (slot types)
xss	Reflected, stored, DOM-based	references/vuln-taxonomy.md (render contexts)
auth	Login bypass, JWT confusion, session fixation, OAuth flaws	references/exploitation-techniques.md
authz	IDOR, vertical/horizontal escalation, business logic	references/exploitation-techniques.md
ssrf	Internal reachability, metadata, protocol smuggling	Skip metadata unless explicitly authorized
infra	Misconfig, info disclosure, default creds, exposed admin	references/exploitation-techniques.md

Each queue entry has: id, vuln class, source (file:line if known), endpoint, parameter, slot type, suspected defense, verdict (identified / partial / confirmed / critical), witness payload, confidence (0-1), notes.

The analysis phase doesn't send malicious payloads yet, it stages them. The exploitation phase actually fires them.

Phase 4: Exploitation (Proof-Based, Conditional)

Only run a sub-agent per class where the analysis queue has actionable entries (identified or partial).

For each candidate:

1. Pre-send check, host in scope? auth gate satisfied? payload approved if destructive?

2. Send the witness payload, minimal proof. SQLi: ' AND 1=1-- then ' AND 1=2--. XSS: a benign marker like ``. Never alert(1) in stored XSS, it'll fire for other users in shared environments.

3. Verify the witness fires, for blind injection, use a sleep probe (SLEEP(5)) and time the response. For SSRF, use a tester-controlled callback host you own (NOT a public service like webhook.site for sensitive engagements, exfil paths).

4. Promote level:

   • L1 Identified, pattern matched, no behavior change
   • L2 Partial, sink reached, but defense in place
   • L3 Confirmed, payload changed app behavior in observable way
   • L4 Critical, data extracted, code executed, access escalated

5. Bypass exhaustion before classifying as FP. For each candidate that blocks: try at least the bypass set in references/bypass-techniques.md for that class. Only after the set is exhausted may you write verdict: false_positive.

6. Record evidence for every L3/L4:

   • Full request (method, URL, headers, body)
   • Response (status, headers, relevant body excerpt)
   • Reproducer command (curl one-liner)
   • Impact statement

Output: findings/exploitation-evidence.md

Redact in evidence files:

• Any captured credentials/tokens → last 6 chars only in chat; full value to findings/secrets-vault.md (gitignored).
• Other users' PII → redact.
• Your test credentials → fine to keep.

Phase 5: Reporting

Generate the final report using templates/pentest-report.md. Sections:

1. Executive summary

2. Engagement scope (from engagement/scope.txt)

3. Authorization (from engagement/authorization.md)

4. Findings (L3/L4 only, proof-required). Per finding:

   • Title, severity (CVSS 3.1), CWE
   • Affected endpoint(s)
   • Proof (request + response excerpt)
   • Reproduction steps
   • Impact
   • Remediation

5. Not-exploited candidates (L1/L2 with notes on what blocked them)

6. Out-of-scope observations

7. Methodology / tools used

8. Limitations and what was NOT tested

Severity policy: CVSS only for L3/L4. L1/L2 are "candidates pending verification", don't assign CVSS to unverified findings.

When to Stop

• The user revokes authorization.
• A candidate finding clearly impacts production data and you don't have approval for destructive testing, STOP and ask.
• The target starts returning 503/429 storms, back off, reconvene with the operator.
• You discover something outside the contracted scope (e.g. an exposed customer database while testing an unrelated endpoint). STOP, document, report to the operator. Do not pivot without explicit approval, that pivot is what makes pentesting illegal.

What This Skill Does NOT Cover

• Network-layer pentesting beyond port scanning (no Metasploit, Cobalt Strike, AD attacks, network protocol fuzzing).
• Reverse engineering / binary analysis (see issue #383).
• Source-only static analysis (see issue #382).
• Active social engineering / phishing.
• Anything against systems the operator hasn't pre-authorized.

If the engagement needs any of these, escalate to a professional pentester. This skill complements professional pentesting; it does not replace it.

Limits and gotchas

• Cloud metadata is off by default. Do not probe 169.254.169.254, metadata.google.internal, 100.100.100.200, [fd00:ec2::254], or equivalent unless the engagement explicitly includes SSRF-to-metadata as a goal AND the target is one you control. The agent's browser tool can reach these from inside your own infrastructure, don't.

• Destructive payloads need approval. SQLi payloads that DROP/DELETE, filesystem-write SSTI, command injection with rm/shutdown/mkfs, anything that mutates beyond a single test row → ASK FIRST. The approval.py system catches some; don't rely on it alone.

• Aux-client leakage risk (Hermes-specific). This skill produces sessions full of SQLi/XSS/RCE payloads, captured credentials, JWT tokens. Hermes' compression and title-generation paths replay history through the auxiliary client (often the main model). Anything sensitive you write to the conversation can leave the box on the next compress. Mitigation:

  • Redact captured tokens/credentials to the LAST 6 CHARS before logging them in any message. Full values go to engagement/evidence/ files, never into chat history.
  • If the engagement is sensitive, set auxiliary.title_generation.enabled: false in ~/.hermes/config.yaml for the session.

• Rate limit yourself. Default 200ms between active requests against any single host. The recon-scan.sh script enforces this. Don't bypass it without operator approval.

• Authority of the report. This skill produces a security assessment, not a "PASS." Even a clean run is "no exploitable issues FOUND in scope X within time T using methods Y", not "the application is secure." Mirror that language in the report.

Further Reading

• references/scope-enforcement.md, how to bound every active request
• references/vuln-taxonomy.md, slot types, render contexts, OWASP map
• references/exploitation-techniques.md, per-class payload patterns
• references/bypass-techniques.md, common WAF/filter bypasses
• templates/authorization.md, engagement authorization template
• templates/pentest-report.md, final report template
• templates/exploitation-queue.json, per-class finding queue schema
• scripts/recon-scan.sh, rate-limited nmap+whatweb+headers wrapper