Running Reconnaissance

The reconnaissance pipeline is RedAmon's core scanning engine — a fully automated, parallelized process that maps your target's entire attack surface using a fan-out / fan-in architecture. Independent modules run concurrently via ThreadPoolExecutor, while data-dependent steps run sequentially. This page explains how to launch a scan, monitor its progress, and understand the results.

Before You Start

Make sure you have:

1. A user selected (see User Management)
2. A project created with a target domain, IP/CIDR targets, or a Domain batch hostname list configured (see Creating a Project and Domain batch below)
3. The Red Zone open with your project selected (see Red Zone)

Tip: Use a Recon Preset when creating your project to quickly configure the pipeline for your use case (e.g., bug bounty, stealth recon, API security audit).

Step 1: Start the Reconnaissance

1. On the Red Zone, locate the Recon Actions group (blue) in the toolbar
2. Click the "Start Recon" button

A confirmation modal appears showing:

• Your project name and target domain
• Current graph statistics (how many nodes of each type already exist, if any)
• If a graph already exists, an Existing Data Found notice with a scan mode choice: Create a new version (recommended) (snapshot the current graph before the scan overwrites it, confirm button Save Version & Start) or Overwrite current version (Discard & Start). This is part of Scan Timeline; "Create a new version" freezes the outgoing graph first (fail-closed) so nothing is lost.

3. Click "Confirm" to start the scan

The "Start Recon" button changes to a spinner while the scan is running.

Step 2: Monitor Real-Time Logs

Once the scan starts, a Logs button (terminal icon) appears in the Recon Actions group.

1. Click the Logs button to open the Logs Drawer on the right side
2. Watch the real-time output as each phase progresses

The logs drawer shows:

• Current phase with phase number (e.g., "Phase 3: HTTP Probing")
• Log messages streaming in real-time as the scan progresses
• A Clear button to reset the log display

Step 3: Watch the Graph Build

While the reconnaissance runs, the graph canvas auto-refreshes every 5 seconds. You'll see nodes appearing and connecting in real-time:

• First, Domain and Subdomain nodes appear (GROUP 1 -- parallel: WHOIS + 5 discovery tools + URLScan)
• Then IP nodes connect to subdomains (GROUP 1 -- DNS with 20 parallel workers)
• ExternalDomain nodes appear from URLScan enrichment (GROUP 1)
• New Subdomain, IP, Port, and Endpoint nodes appear from multi-engine search (GROUP 2b -- Uncover queries up to 13 search engines)
• Port nodes attach to IPs, Shodan enrichment data merges in (GROUP 3 -- parallel: Naabu + Shodan)
• Threat intelligence properties populate on IP and Domain nodes -- OTX pulse data, VirusTotal reputation scores, Censys service data, FOFA/ZoomEye/Netlas/CriminalIP host intelligence (GROUP 3b -- 7 tools parallel)
• Port nodes get enriched with product/version/CPE, Technology and Vulnerability nodes appear from NSE scripts (GROUP 3.5 — Nmap service detection)
• BaseURL, Service, and Technology nodes appear (GROUP 4 — HTTP Probe)
• Endpoint and Parameter nodes branch out (GROUP 5 -- parallel: Katana + Hakrawler + GAU + Kiterunner, then jsluice + FFuf + ZAP Ajax Spider + Arjun)
• Secret, Endpoint, and JsReconFinding nodes appear from JavaScript analysis (GROUP 5b -- JS Recon: 6 modules parallel)
• Vulnerability and CVE nodes connect to affected resources (GROUP 6 Phase A -- Nuclei || GraphQL Security || Subdomain Takeover || VHost & SNI || Web Cache Poisoning run in parallel; Phase B -- MITRE enrichment)
• GraphQL Endpoint capability flags (graphql_graphiql_exposed, graphql_tracing_enabled, graphql_get_allowed, etc.) populate on Endpoint nodes discovered as GraphQL services

Step 4: Download Results

When the scan completes:

1. The spinner stops and the "Start Recon" button reappears
2. A Download button (download icon) appears in the Recon Actions group
3. Click it to download the complete results as a JSON file (recon_{projectId}.json)

Pipeline Architecture (Fan-Out / Fan-In)

The pipeline is organized into execution groups. Modules within each group run concurrently; groups execute sequentially because later groups depend on earlier results. Graph DB updates run in a dedicated background thread so the main pipeline is never blocked.

_{*Amass can run in active mode when configured. Knockpy performs active DNS probing.}

Each phase builds on the previous group's output. You can control which modules run via the Scan Modules setting in your project configuration.

Targeting Modes and the Pipeline

The groups below describe the Single Domain pipeline (the default). The other two targeting modes change only where GROUP 1 gets its input:

In IP mode, each target IP is resolved via PTR to discover its hostname. When no PTR record exists, a mock hostname is generated (e.g., 192-168-1-1). The remaining groups (port scan through MITRE enrichment) run identically.

Domain batch runs this same Single-Domain pipeline once per domain group, one group after another, accumulating every group into a single graph and a single version. Subdomain discovery is off, so only the hostnames you listed are scanned. See Domain batch below for the full walkthrough.

GROUP 1: Domain Discovery + WHOIS + URLScan (parallel)

Purpose: Map the target's subdomain landscape. All three top-level tasks (WHOIS, discovery, URLScan) run concurrently. Within discovery, all 5 tools run in parallel.

Techniques used (all concurrent):

• Certificate Transparency via crt.sh — finds certificates issued for the domain
• HackerTarget API — passive DNS lookup
• Subfinder — passive subdomain enumeration using 50+ online sources (certificate logs, DNS databases, web archives)
• Amass — OWASP Amass subdomain enumeration using 50+ data sources (certificate logs, DNS databases, web archives, WHOIS). Supports optional active mode (zone transfers, certificate grabs) and DNS brute forcing
• Knockpy — active subdomain brute-forcing (if useBruteforceForSubdomains is enabled)
• WHOIS Lookup — registrar, dates, contacts, name servers (runs in parallel with discovery)
• URLScan.io — historical scan data, subdomains, IPs, TLS metadata (runs in parallel with discovery)
• DNS Resolution — A, AAAA, MX, NS, TXT, CNAME, SOA records for every discovered subdomain (20 parallel workers)

Output: Domain, Subdomain, IP, and DNSRecord nodes in the graph.

If a specific subdomainList is configured, the pipeline skips active discovery and only resolves those subdomains (WHOIS + URLScan still run in parallel). In IP mode, this group is replaced by reverse DNS lookups and IP WHOIS — see above.

Shodan enrichment (runs in GROUP 3 alongside port scan):

• Host Lookup — OS, ISP, organization, geolocation, and known vulnerabilities per IP
• Reverse DNS — discover hostnames missed by standard enumeration
• Domain DNS — subdomain enumeration via Shodan's DNS records (paid plan required)
• Passive CVEs — extract known CVEs from host data without active scanning

URLScan.io enrichment (runs in GROUP 1 alongside discovery):

• Queries historical scan data from URLScan.io's Search API
• Discovers subdomains, IP addresses, URL paths, TLS metadata, server technologies, and domain age
• Collects external domains encountered in historical scans for situational awareness
• Works without API key (public results) or with key (higher rate limits)

ExternalDomain nodes: Throughout the pipeline, multiple modules collect out-of-scope domains (URLScan historical data, HTTP probe redirects, Katana/GAU crawling). At the end of the pipeline, these are aggregated, deduplicated, and stored as ExternalDomain nodes linked to the root Domain.

Both modules are independently toggleable in the Discovery & OSINT tab of project settings. If URLScan enrichment runs, the urlscan provider is automatically removed from GAU to avoid duplicate data.

GROUP 2b: Uncover Target Expansion (before port scan)

Purpose: Expand the target surface by querying up to 13 search engines via ProjectDiscovery's uncover tool. Runs before Shodan and port scanning so newly discovered assets are processed by all downstream modules.

How it works:

1. Builds a provider-config.yaml with only engines that have valid API keys
2. Runs the projectdiscovery/uncover Docker container with domain-based and SSL cert queries
3. Deduplicates results by (IP, port), handles engine quirks (Google URL-in-IP, PublicWWW host-only)
4. Filters non-routable and CDN IPs via ip_filter.py
5. Merges discovered subdomains into dns.subdomains and IPs into metadata.expanded_ips

Engines (only those with configured keys are used):

No extra keys needed if you already have Shodan, Censys, FOFA, etc. configured -- uncover reuses them automatically. The 7 uncover-specific engines are optional extras for broader coverage.

IP filtering: Non-routable IPs (RFC 1918, CGNAT, loopback) and CDN IPs are automatically filtered before results enter the pipeline. This prevents wasting API credits on downstream enrichment of unusable addresses.

Output: Subdomain, IP, Port, and Endpoint nodes in the graph. Discovered hosts are injected into the pipeline so GROUP 3+ modules process them.

GROUP 3: Shodan + Port Scanning (parallel)

Purpose: Discover open ports and enrich IPs with Shodan intelligence. Both tasks run concurrently.

Port Scan (Naabu) capabilities:

• SYN scanning (default) with CONNECT fallback
• Top-N port selection (100, 1000, or custom ranges)
• CDN/WAF detection (Cloudflare, Akamai, AWS CloudFront)
• Passive mode via Shodan InternetDB (no packets sent)
• IANA service name mapping (15,000+ entries)

Output: Port nodes linked to IP nodes. Enriched IP nodes from Shodan (OS, ISP, geolocation, passive CVEs).

GROUP 3b: Threat Intelligence Enrichment (parallel with GROUP 3)

Purpose: Passively enrich discovered IPs and domains with threat intelligence from seven specialized OSINT platforms. All seven tools run concurrently via ThreadPoolExecutor(max_workers=5). This group runs in parallel with GROUP 3 (port scanning) — neither blocks the other.

Tools (all concurrent):

OTX is enabled by default — it supports anonymous requests (1,000 req/hr) without an API key. All other tools require an API key configured in Global Settings > API Keys.

Rate limiting: Each tool detects HTTP 429 responses and stops further queries for that scan. VirusTotal free-tier users are limited to 4 requests/minute; the pipeline automatically waits 65 seconds and retries on rate limit. CriminalIP retries after 2 seconds.

Key rotation: FOFA, OTX, Netlas, VirusTotal, ZoomEye, and CriminalIP support automatic round-robin key rotation. Configure additional keys in Global Settings to multiply effective rate limits.

Output: Threat intelligence properties added to existing IP and Domain nodes in Neo4j. Data from each tool is stored as properties on the relevant node (no new node types). Results are also included in the recon_domain.json output file under per-tool keys.

GROUP 3.5: Nmap Service Detection (after port scan merge)

Purpose: Deep service version detection and NSE vulnerability script scanning on all discovered open ports. Runs after port_scan merge (Masscan + Naabu results combined) so it only probes ports already confirmed as open.

Capabilities:

• Service version detection (-sV) -- identifies product name, version, and CPE for services running on open ports (e.g. vsftpd 2.3.4, Apache Tomcat/8.5.19)
• NSE vulnerability scripts (--script vuln) -- runs Nmap Scripting Engine vulnerability checks against discovered services, extracting CVE IDs from script output
• Configurable timing -- T1 (Sneaky) through T5 (Insane), with per-host and total timeout controls
• Stealth mode -- automatically reduces timing to T2 (Polite) and disables NSE scripts

Graph enrichment:

• Port nodes enriched with product, version, cpe, nmap_scanned flag
• Technology nodes created from detected services ((Service)-[:USES_TECHNOLOGY]->(Technology), (Port)-[:HAS_TECHNOLOGY]->(Technology))
• Vulnerability nodes created from NSE findings ((Vulnerability)-[:AFFECTS]->(Port), (Vulnerability)-[:FOUND_ON]->(Technology))
• CVE nodes created from NSE-detected CVEs ((Vulnerability)-[:HAS_CVE]->(CVE), (Technology)-[:HAS_KNOWN_CVE]->(CVE))

Output: Enriched Port and Service nodes, new Technology/Vulnerability/CVE nodes from Nmap. Detected service versions also feed into the CVE lookup pipeline (GROUP 6) for NVD/Vulners enrichment.

Only runs when NMAP_ENABLED is true and port scan results contain discovered ports. Configure in the Nmap Service Detection tab of project settings.

GROUP 4: HTTP Probing & Technology Detection

Purpose: Determine which services are live and what software they run.

httpx probing:

• Status codes, content types, page titles, server headers
• TLS certificate inspection (subject, issuer, expiry, ciphers, JARM)
• Response times, word counts, line counts

Technology detection (dual engine):

• httpx built-in fingerprinting for major frameworks
• Wappalyzer second pass (6,000+ fingerprints) for CMS plugins, JS libraries, analytics tools

Banner grabbing:

• Raw socket connections for non-HTTP services (SSH, FTP, SMTP, MySQL, Redis)
• Protocol-specific probe strings for version extraction

Output: BaseURL, Service, Technology, Certificate, Header nodes.

GROUP 5: Resource Enumeration (internally parallel + sequential)

Purpose: Discover every reachable endpoint and hidden parameter. Four tools run simultaneously, then jsluice, FFuf, ZAP Ajax Spider, and Arjun run sequentially.

Katana, Hakrawler, GAU, and Kiterunner run in parallel. Once crawling completes, jsluice analyzes the discovered JavaScript files sequentially, FFuf brute-forces directory paths using wordlists, ZAP Ajax Spider drives a real browser through the discovered endpoints to capture JS-only XHRs and SPA routes (its own per-seed Docker containers run in parallel up to Parallelism), then Arjun discovers hidden parameters on the discovered endpoints (with selected methods running in parallel).

Results are merged, deduplicated, and classified:

• Categories: auth, file_access, api, dynamic, static, admin
• Parameter typing: id, file, search, auth_param

Output: Endpoint, Parameter, and Secret nodes linked to BaseURL nodes.

GROUP 5b: JS Reconnaissance (after resource enumeration)

Purpose: Deep JavaScript analysis to extract secrets, endpoints, dependency confusion risks, source map exposures, DOM XSS sinks, and framework fingerprints from client-side code. Runs whenever JS_RECON_ENABLED is true, independently of resource enumeration. When resource_enum is active, JS Recon analyzes its discovered JS files; when resource_enum is disabled, JS Recon analyzes manually uploaded files only.

How it works:

1. Collects all JS URLs discovered by Katana, Hakrawler, ZAP Ajax Spider, GAU, and jsluice in GROUP 5
2. Downloads up to 500 JS files concurrently (10 threads), skipping third-party libraries
3. Merges with any manually uploaded JS files
4. Runs six analysis modules in parallel (4-worker thread pool):

5. Extracts new in-scope subdomains from discovered endpoints and feeds them back into the pipeline
6. Updates Neo4j graph in a background thread

Subdomain feedback loop: JS Recon discovers subdomains embedded in JavaScript code (API base URLs, CDN references, cloud asset URLs) and merges them back into the pipeline's subdomain list. These new subdomains become available for downstream processing.

Output: Secret, Endpoint, and JsReconFinding nodes linked to BaseURL nodes. New subdomains merged into the pipeline.

Full details: See JS Reconnaissance for module details, output structure, API endpoints, and frontend components.

GROUP 5.5: Supply-Chain Recon (after JS Recon)

Purpose: Black-box detection of known-malicious (MAL-) and known-vulnerable (CVE / GHSA) dependencies the live target actually serves. Runs whenever supplyChainReconEnabled is true, immediately after JS Recon (whose downloaded JS and detected technologies it reuses). Off by default.

How it works: it harvests npm package names and versions from JS Recon's source maps, the http_probe technologies, and a retire.js pass; synthesizes a CycloneDX SBOM; and verdicts it offline against the local OSV database (zero egress, no new fetch to the target). Version-bearing packages are verdicted; names harvested without a version are recorded as inventory but flagged unverdictable. An optional GuardDog deep-analysis pass adds suspicious behavioural findings on the OSV-flagged packages.

Output: Package and MalPackageFinding nodes plus Vulnerability{source='osv'}, anchored to the target's BaseURL nodes via DEPENDS_ON. Read them in the Supply-Chain SCA table. Needs the offline OSV database populated once (./redamon.sh supply-chain-sync npm).

Full details: See Supply-Chain Scanning for the three layers, the tools (OSV-Scanner, GuardDog, retire.js), and the standalone Other-Scans variant.

GROUP 5c: AI Surface Recon (after resource enumeration)

Purpose: Confirm and characterize AI/LLM/MCP/vector-DB infrastructure that generic web recon can't see. Runs as Phase 4.5 whenever AI_SURFACE_RECON_ENABLED is true (gated on its own toggle, not SCAN_MODULES), after resource enumeration. It is black-box and benign — it sends a 1-token chat "ping", a standard MCP initialize, OpenAPI GETs, declarative fingerprint probes, and vector-DB health reads. It never jailbreaks, injects, fuzzes, or presents credentials, and treats a 401 as a positive signal.

How it works:

1. Gathers candidate hosts (crawled AI endpoints + http_probe AI flags + AI/vector-DB ports), drops RoE-excluded hosts
2. Fans candidates across a thread pool (hosts in parallel, workloads sequential per host); runs seven workloads:

3. Updates the Neo4j graph in a background thread (annotates Endpoint/Parameter/Technology, adds MCP tool-poisoning Vulnerability nodes)

Output: combined_result["ai_surface_recon"]; graph enrichment via update_graph_from_ai_surface_recon.

Full details: See Adversarial AI Recon.

GROUP 6 Phase A: Nuclei + GraphQL Security + Subdomain Takeover + VHost & SNI + Web Cache Poisoning (parallel)

Purpose: Test discovered endpoints for security vulnerabilities and uncover hidden infrastructure. All five scanners read from the same combined_result dict (each pulls a different slice - BaseURL/Endpoint/Technology for Nuclei + GraphQL + Web Cache Poisoning, Subdomain/DNS/alive URLs for Takeover, IP/Port/SAN list for VHost & SNI) and write Vulnerability nodes, but have zero data dependency on each other - so they run concurrently via ThreadPoolExecutor using _isolated wrappers that deep-copy the shared result dict to avoid race conditions. Wall-time is dominated by Nuclei (5-30 min) and Web Cache Poisoning (WCVS is thorough and slow - hundreds of requests/URL, 1800 s default budget); the other three complete within minutes (Takeover) or seconds (VHost & SNI).

Nuclei capabilities:

• 9,000+ community templates for known CVEs, misconfigurations, exposed panels
• DAST mode — active fuzzing with XSS, SQLi, RCE, LFI, SSRF, SSTI payloads
• Severity filtering — scan for critical, high, medium, and/or low findings
• Interactsh — out-of-band detection for blind vulnerabilities
• CVE enrichment — cross-references findings against NVD for CVSS scores

30+ custom security checks (configurable individually):

• Direct IP access, missing security headers (CSP, HSTS, etc.)
• TLS certificate expiry, DNS security (SPF, DMARC, DNSSEC, zone transfer)
• Open services (Redis no-auth, Kubernetes API, SMTP open relay)
• Insecure form actions, missing rate limiting

GraphQL security scanner capabilities:

• Endpoint auto-discovery — merges user-specified endpoints with candidates from HTTP probe, resource enumeration, JS Recon, and pattern probing (/graphql, /api/graphql, /v1/graphql, /v2/graphql as primary patterns; /query, /gql, /graphiql, /playground as secondary patterns only on bases with existing GraphQL evidence)
• Introspection test — probes each endpoint for exposed __schema/__type, extracts the full schema at a configurable TypeRef recursion depth (1-20), counts queries/mutations/subscriptions, and computes a schema hash for change detection
• Sensitive-field detection — flags schema fields matching password, token, secret, key, api, private, credential, auth, ssn, credit, card, cvv, salary, medical, etc.
• graphql-cop (opt-in Docker-in-Docker) — runs dolevf/graphql-cop:1.14 for 12 additional checks: alias overloading, batch query DoS, directive overloading, circular introspection DoS, GraphiQL/Playground detection, trace mode, GET-based queries/mutations, POST url-encoded CSRF, field suggestions, unhandled error leakage
• 5 authentication modes — Bearer, Cookie, custom header, Basic (base64), API key
• Rate limiting + retries — global RPS cap (0-100), retry with exponential backoff on 429/5xx, configurable concurrency (1-20)
• RoE enforcement — out-of-scope endpoints (wildcards supported) are skipped and counted in endpoints_skipped
• Endpoint capability flags — booleans like graphql_graphiql_exposed, graphql_tracing_enabled, graphql_get_allowed, graphql_batching_enabled are persisted on the Endpoint node even for negative results

Web Cache Poisoning scanner capabilities:

• Two-engine detection - the third-party WCVS (Hackmanit, Docker-in-Docker) sweeps 10+ technique classes for breadth ("find suspects"), then a RedAmon-native 5-phase confirmation engine re-proves every suspect with a safe baseline→poison→clean→persistence sequence ("prove it")
• Cache oracle - confirms a URL is actually served through a cache via X-Cache/CF-Cache-Status/Age/Via headers, with a behavioural fallback (frozen-Date probe) for silent caches that emit no cache headers; non-cacheable URLs are skipped
• Isolated, benign testing - every test mints a unique cache-buster so it lands in its own slot and never poisons the real page; payloads are non-resolving .invalid canaries, never live XSS or real domains
• Native hypotheses - generic unkeyed-header families (X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-For, URL-override, …) plus fingerprint-gated framework packs for Next.js / Nuxt / Remix
• Reflected + non-reflective detection - confirms both an echoed canary and a persisted behavioural change (status flip, Location redirect, body diff), the latter guarded against false positives by requiring stability across two clean baselines
• Confidence scoring - findings are tiered Confirmed / Strong / Tentative / Rejected; only those at or above the Min confidence gate (default 0.8) become Vulnerability {source:'cache_poisoning'} nodes

Output: Vulnerability and CVE nodes linked to Endpoints and Parameters. GraphQL adds: introspection findings (with sensitive field lists), graphql-cop misconfiguration findings, and capability flags on the Endpoint nodes. Web Cache Poisoning adds: scored cache_poisoning Vulnerability nodes carrying the unkeyed vector, cache signals, impact, and a clickable PoC link + curl verification command.

Stealth mode overrides (GraphQL): rate limit forced to 2/s, concurrency to 1 (sequential), timeout to 60s, and the four DoS-class graphql-cop tests (alias overloading, batch query, directive overloading, circular introspection) are forced off.

Stealth mode (Web Cache Poisoning): the module is disabled entirely - active poisoning probes are loud and high-volume, incompatible with stealth. CPDoS stays force-off regardless.

GROUP 6 Phase B: MITRE Enrichment

MITRE Enrichment (runs automatically after Phase A completes — depends on Nuclei CVEs):

• Maps every CVE to its corresponding CWE weakness and CAPEC attack patterns
• Uses the CVE2CAPEC repository (auto-updated with 24-hour cache TTL)
• Provides attack pattern classification for every vulnerability found

Additional MITRE output: MitreData (CWE) and Capec nodes linked to CVE nodes.

Domain batch: scanning many domains in one run

A project set to Domain batch targets a list of hostnames spanning several domains instead of a single target. RedAmon groups the list by domain and scans the groups one after another.

How the list is grouped

The domain is the last two labels of a hostname. So suba.sub3.domain3.com belongs to domain3.com with the prefix suba.sub3.

This is the same thing you would do by hand in a single-domain project: the domain goes in Target Domain, everything in front of it goes in Subdomain Prefixes. A batch therefore scans exactly as a hand-built project would.

One consequence is worth knowing: foo.example.co.uk groups under co.uk, because the rule counts labels rather than consulting a public-suffix list. The project form shows you the computed groups before you save, so you always see the grouping before it runs.

What happens when you run it

• It is one scan, not many. The batch takes a single row in the Scan queue, one memory reservation and one container. Stop it and the whole batch stops.
• The graph fills in as it goes. The previous recon data is cleared once, at the start. Each group then finishes its whole pipeline and writes to the graph before the next one begins, so every group accumulates into one graph.
• You get one new version covering all the domains, exactly as a single-domain scan produces one version. Run it again for a second version.
• Only your hostnames are scanned. Subdomain discovery is off for a batch.
• A failing domain does not stop the rest. Failures are listed at the end.

The recon drawer shows Group 2/3 alongside the usual phase progress, since the six phases restart for each group.

Limits

500 hostnames and 50 domains per project. Remember that a batch holds the project's single scan slot until every group is done, so a long list is a long scan.

Scan Duration Estimates

Duration varies based on target size, network conditions, and scan settings:

Key factors affecting duration:

• Bruteforce for subdomains adds significant time for large domains
• Katana depth > 2 increases crawling time exponentially
• DAST mode doubles vulnerability scanning time
• GAU with verification adds 30-60 seconds per domain

After Reconnaissance

Once the scan is complete, you can:

1. Explore the graph — click nodes to inspect their properties, filter by type using the bottom bar
2. Switch to Data Table — view all findings in a searchable, sortable table with Excel export
3. Run GVM scan — complement web-layer findings with network-level vulnerability testing (see GVM Vulnerability Scanning)
4. Run GitHub Hunt — search for leaked secrets (see GitHub Secret Hunting)
5. Run the Secret Multiscanner - scan repositories, registries, buckets and CI systems with 1060 secret detectors and live API verification (see Secret Multiscanner)
6. Use the AI Agent — ask the agent to analyze findings, identify attack paths, and exploit vulnerabilities (see AI Agent Guide)
7. Compare scans over time — with Scan Timeline, diff this scan against a previous version (Recon Delta) to see new ports, new CVEs, and resolved findings, or schedule scans to run automatically

Next Steps

• GVM Vulnerability Scanning — add network-level vulnerability testing
• AI Agent Guide — let the AI analyze and act on your findings
• AI in the Recon Pipeline — let the LLM sharpen individual scan steps (ffuf extensions, nuclei tags, WAF and takeover calls)
• Scan Timeline — version your graph, diff scans over time, and schedule recurring scans