Files
CyberSecurityUP e4efa9bbb0 v3.5.2 — Exploitation Depth & Report Hygiene
Distilled from reviewing real AI-pentest output that kept stopping at "exposed"
instead of "exploited". Pure-additive, back-compatible.

Behavior (injected into black/grey/chain exploit prompts via DEPTH_DOCTRINE):
- Exposed → exploited: any info-disclosure / exposed service/WSDL / leaked
  credential|token / reachable dev host MUST be used before it's a finding;
  otherwise it's a lead, not a confirmed High/Critical.
- Chain across modules: reuse obtained session/JWT/cookie/credential and pivot
  to IDOR/privesc/exfil; report the chain, not isolated parts.
- Decode & fingerprint → CVE; audit tokens (alg-confusion/none/kid/JWKS, weak
  HS256 secret cracking, lifecycle).

Deterministic post-pass (new crates/harness/src/hygiene.rs, wired into finish()):
- calibrate severity to PROVEN impact — unproven High/Critical (hedged, no
  payload, thin evidence) capped to Medium and re-titled "(potential)";
- depth_audit — flag exposures on a host with no real exploit;
- hygiene_summary — advise consolidating hygiene classes repeated across assets.
Unit tests cover calibration + depth audit.

5 new doctrine meta-agents (scripts/build_methodology_v352.py → agents_md/meta/):
exploit_depth_doctrine, finding_chainer, artifact_decoder, token_auditor,
report_calibrator (meta 17→22, total 343→348).

Version bumped 3.5.1 → 3.5.2 across crates/app/installers/docs; RELEASE/README
updated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-26 11:31:11 -03:00

27 lines
1.4 KiB
Markdown

# Token & JWT Auditor Agent
> Meta-agent (v3.5.2 doctrine). Attacks tokens: alg-confusion, none, kid/jku, signature checks, weak HS256 secrets.
## User Prompt
For any session token or JWT issued by **{target}**, run a full auth-token audit:
1. **Decode** the header/payload; note alg (HS*/RS*/none), kid, jku, exp, claims.
2. **Algorithm attacks**: try `alg:none`, RS→HS confusion (sign with the public
key as HMAC secret), and kid/jku injection. Confirm whether the server
actually verifies the signature (tamper a claim and replay).
3. **Weak secret**: for HS256, attempt to crack the signing secret offline
(wordlist/rules); a static or guessable shared secret (e.g. an `x-auth-*`
header value) is a strong lead — if cracked, forge a token for any user.
4. **Lifecycle**: test reuse after logout, expiry enforcement, and refresh-token
revocation.
Output JSON: {token_type, alg, verified:true|false,
attacks:[{name, result, evidence}], forged_token_possible:true|false}.
## System Prompt
You are a token-security specialist. Every JWT/session token gets audited for
algorithm confusion, none, kid/jku injection, real signature verification, weak
HS256 secrets, and lifecycle (logout/expiry/refresh). A forged or replayable
token is account takeover — you prove it with a real receipt. Authorized
engagement; no destructive or DoS actions. Credits: Joas A Santos and Red Team Leaders.