Recon commands BETA

Send `recon` for the menu. `recon <target>` runs the whole chain: host/IP → ports → web per service; domain → subdomains → hosts → web; URL → web; `.onion` → web over Tor.

These commands are new and may have bugs.

Every recon adds to the target's record

Findings are stored per target on the machine, not per run: each new recon first reads what earlier runs recorded (last 7 days), reuses it, skips tools that already ran, and writes its own results back. Attack commands read the same record. Nothing is erased between runs.

recon:domain <domain>

Example: recon:domain example.com

Maps a domain's whole external attack surface — its subdomains, which hosts are live and what they run, open ports and services, and known-vulnerability signals — then runs the full web-app scan on every live web host.

subfindercrt.shdighttpxwafw00fnaabunmapnucleikatanagauarjunwhatwebcve_matchphpjwt_toolsqlmapsecretfinder

How it works

#	Step	What it does
1	`subfinder`	Passive subdomain discovery
2	`crtsh`	Subdomains from certificate-transparency logs (crt.sh)
3	`dig`	DNS records (A, MX, NS, TXT)
4	`httpx`	Live-host probe: title, status, detected technologies
5	`wafw00f`	Detects a web application firewall
6	`naabu`	Fast open-port scan
7	`nmap`	Service and version on each open port
8	`nuclei`	Known-CVE / misconfiguration template scan
9	`katana`	Crawls the app; captures every response
10	`gau`	Historical URLs from public archives
11	`arjun`	Discovers hidden HTTP parameters
12	`whatweb`	Web stack fingerprinting
13	`cve_match`	Matches the detected product versions against the platform's vuln/exploit DB (NVD + Exploit-DB + CISA KEV, refreshed every 6h) and records each hit as a candidate. It claims a version match only when the entry's text carries the version; otherwise it says 'product match, version unverified'.
14	`php`custom	PHP: markers, version label, SAPI, upload-progress posture
15	`jwt_tool`	Weak / default JWT signing keys
16	`sqlmap`	SQL injection
17	`secretfinder`	Inline secrets in scripts

recon:host <ip|hostname>

Example: recon:host 203.0.113.10

Discovers a single host's NETWORK surface only — its open ports, the service and version on each, and which ports speak HTTP/HTTPS. It does not scan the web apps itself: run "recon <host>" (the umbrella) to chain straight into a full web-app scan on each web service, or recon:web on a specific URL.

naabunmaphttpxkatanagauwhatwebwafw00fphpjs_deobfcontent_scansqlmapparam_scannucleiauthz_scanarjunjwt_toolsecretfinder

How it works

#	Step	What it does
1	`naabu`	Fast open-port scan
2	`nmap`	Service and version on each open port
3	`httpx`	Live-host probe: title, status, detected technologies
4	`katana`	Crawls the app; captures every response
5	`gau`	Historical URLs from public archives
6	`whatweb`	Web stack fingerprinting
7	`wafw00f`	Detects a web application firewall
8	`php`custom	PHP: markers, version label, SAPI, upload-progress posture
9	`js_deobf`custom	Deobfuscates scripts; extracts endpoints + secrets
10	`content_scan`custom	Hidden files: backups, .git, .env, admin panels
11	`sqlmap`	SQL injection
12	`param_scan`custom	Per-parameter injection (SQLi, XSS, cmd, LFI, redirect)
13	`nuclei`	Known-CVE / misconfiguration template scan
14	`authz_scan`custom	Authorization: guest vs session, IDOR candidates
15	`arjun`	Discovers hidden HTTP parameters
16	`jwt_tool`	Weak / default JWT signing keys
17	`secretfinder`	Inline secrets in scripts

recon:web <url>

Example: recon:web https://example.com

The full scan of a single web application: maps its surface, then flags SQL-injection, XSS and exposed secrets, checks JWTs for weak keys, template-scans for known CVEs, and maps the people and social-engineering surface — recon and possibility-flagging, never exploitation. It can also scan signed-in with --sign-in.

katanagauhttpxwhatwebcve_matchwafw00fphpjs_deobfcontent_scansqlmapparam_scannucleiauthz_scanarjunjwt_toolsecretfinder

How it works

#	Step	What it does
1	`katana`	Crawls the app; captures every response
2	`gau`	Historical URLs from public archives
3	`httpx`	Live-host probe: title, status, detected technologies
4	`whatweb`	Web stack fingerprinting
5	`cve_match`	Matches the detected product versions against the platform's vuln/exploit DB (NVD + Exploit-DB + CISA KEV, refreshed every 6h) and records each hit as a candidate. It claims a version match only when the entry's text carries the version; otherwise it says 'product match, version unverified'.
6	`wafw00f`	Detects a web application firewall
7	`php`custom	PHP: markers, version label, SAPI, upload-progress posture
8	`js_deobf`custom	Deobfuscates scripts; extracts endpoints + secrets
9	`content_scan`custom	Hidden files: backups, .git, .env, admin panels
10	`sqlmap`	SQL injection
11	`param_scan`custom	Per-parameter injection (SQLi, XSS, cmd, LFI, redirect)
12	`nuclei`	Known-CVE / misconfiguration template scan
13	`authz_scan`custom	Authorization: guest vs session, IDOR candidates
14	`arjun`	Discovers hidden HTTP parameters
15	`jwt_tool`	Weak / default JWT signing keys
16	`secretfinder`	Inline secrets in scripts

recon:ports <ip|hostname>
Example: recon:ports 203.0.113.10
Fast port and service discovery on a host, and nothing else.
naabunmap
How it works
# Step What it does
1 naabu Fast open-port scan
2 nmap Service and version on each open port

Steps tagged "custom" are my own custom tools, built by me for this platform. The rest are third-party tools.

Run only some steps

Every run executes all steps in order by default — you never have to name them. The --steps flag is OPTIONAL: use it only when you want a subset (handy for re-checking one gap without paying for the full scan):

Flag: recon:web https://example.com --steps sqlmap,param_scan

Or ask in chat: re-check only sqlmap and param_scan on example.com

`--steps a,b,c` runs exactly these, in order. Results land under the same target; a re-check adds, never replaces. Names are tool codes (`crtsh`, not crt.sh); a mistyped name is refused with the valid list.

Also runs: `logic_scan` (business rules, auth policy: negative quantities, weak passwords, registration, roles, logout, reset, 2FA) · `supply_scan` (image GPS, dependency advisories, typosquats, prompt injection) · `infra_scan` (management endpoints, IaC, buckets, TLS). Untested = gap.

Guest vs signed-in

Two separate runs. Guest (default): reads only what needs no session, never asks, records gated areas as gaps. `--sign-in`: asks for a session first, scans only the signed-in state.

Social-engineering surface

`recon:web` also extracts people and contacts from the captured pages (names, roles, emails, phones, handles, forum members) and offers the matching `osint:*` command for each. Nothing chains automatically.

Lists

Lists are general: `recon:domain a.com b.com`, or `--list <name|id>` on any command. See Lists.

Tor (.onion)

Same plan over Tor; see the onion section above.

Kali machine

Each command needs an active Kali Linux machine — the whole toolkit (subfinder, naabu, nmap, httpx, nuclei, katana, arjun, jwt_tool, gau and more) is pre-installed on it, so the model runs everything live. Rent one in the Virtual Machines section.

Multiple machines

Have more than one machine? Add --machine <name> (or -m <name>) to the end of any command — e.g. recon:domain example.com --machine kali-recon — to pin every command to that machine. Without it, your active machine is used.

Coverage — what a recon run actually proves

A module pass is worth only its evidence. Below: `recon:web:onion` against DVWA. proven = shown by a command or the browser · N/A = module absent · not proven = no signal, reported as a gap.

Module / class	Status	How it was established
`OS command injection`	proven	echo/id output returned by the ip parameter
`Local file inclusion`	proven	contents of a system file returned through page
`File upload to code execution`	proven	the uploaded PHP file answered and executed on the server
`SQL injection`	proven	boolean differential on id, confirmed by sqlmap
`XSS reflected`	proven	payload reflected unescaped (name, include)
`XSS stored`	proven	canary persisted and returned on re-fetch (txtName)
`XSS DOM`	proven	payload executed in a real browser session
`CSRF`	proven	state-changing forms without an anti-CSRF token (3 forms)
`Weak session IDs`	proven	predictable session value after the module's own generate press
`CSP / script include`	proven	submitted URL written into a script src attribute
`Client-side-only token`	proven	token ships empty and is filled in by JavaScript
`Brute force`	proven	the documented default credential was accepted on the first attempt, verified with a fresh session
`Open redirect`	N/A	the module does not exist on the build (404)
`Authorization bypass / IDOR`	N/A	no such module on the build
`Remote file inclusion`	not proven	the target never fetched a remote URL served by the scan, and emitted no error: remote includes are off on this build (local inclusion is proven)
`Insecure CAPTCHA`	proven	the password was changed through step 2 with no CAPTCHA at all, proven by logging in with the new value, then restored

Coverage is stated per run, not per product: a step that fails, is skipped, or returns nothing is reported as such. Not proven never becomes clean — the report names it as a gap and says which tool or manual step would close it.

Give a port and only that service is scanned

`http://68.183.109.200:3000` is one HTTP service: `recon:web` on exactly that endpoint, no port scan of the host. A bare IP is a host (`recon:host`), a bare domain maps subdomains (`recon:domain`).

Protected targets

Walls (Cloudflare, DataDome, a JS check), logins and consent pages are cleared with you — never scanned silently and never reported as empty.

Wall detection — One model call on the first response names the wall and the action: continue, park for you, or ask for a session.
Live browser — A check that needs a human parks the run as waiting_user. You clear it in the pod's browser (over noVNC); the run captures the cookies + User-Agent and resumes.
Login discovery — A real browser records the login request it sends, modal or API. If it cannot, the model names the login from the page and the static regex is the last resort.
Deep proofs — Opt-in: RFI, CAPTCHA skip-step (proven by a real change, then reverted), bounded brute force, open redirect.
Tools with their own HTTP stack — `sqlmap` and `dalfox` pass a session wall (cookie + UA), not a fingerprint wall; time-based blind SQLi degrades under latency.
Report — Written from one evidence block — findings, step results, coverage — and refused if it names a finding that block does not contain.

Vulnerabilities

Every finding a scan produces is stored as a vulnerability for that target — on the target page, under the Vulns tab, with a short handle like 3kd9xqa.

What is recorded — Class (CWE, OWASP), what the attacker ends up holding, impact, blast radius, what the exploit needs first, the payload, whether it was found as a guest or signed in, the evidence, and the fix.
How to get in with it — Each vulnerability carries a step-by-step an agent can execute: commands in order, what output proves success, where to stop. The model writes it; otherwise it comes from the bug class.
Kept, not lost with the machine — The record is synced from the machine when a run finishes and stays when the machine is gone. Re-read the machine any time with one button.

Reports

The report is written to `/root/recon/` on your machine; the reply gives the path. Download it from the machine card or over SSH. It ends with *Verified findings* (evidence per vuln, or none) and *Coverage gaps* (what was not tested).