The DDactic Six-Stage Scan Pipeline

A DDoS resilience assessment that starts at the API endpoint misses the infrastructure underneath it. DDactic's scan pipeline begins at the perimeter and works inward: discovering every domain and subdomain associated with an organization, mapping open ports and services, dispatching L7 probes across every protocol, intercepting application traffic to surface app-specific attack vectors, cross-referencing against breach intelligence, and finally running AI analysis to synthesize findings into a prioritized test plan with vendor-specific hardening commands.

Each stage builds on the previous one. The domain discovery in Stage 1 determines what Stage 2 scans. The port scan results from Stage 2 determine which L7 probes Stage 3 dispatches. The L7 fingerprinting from Stage 3 determines which application surfaces Stage 4 intercepts. All prior stages feed Stage 6's AI analysis. This dependency chain means the pipeline cannot be shortcut: skipping domain discovery produces an assessment of the known surface, not the actual surface.

Stage 1: Discovery

Stage 1 resolves the organization's name to its full set of second-level domains (SLDs) using a combination of WHOIS organization search, certificate transparency log queries, reverse IP lookups, and ASN enumeration. From each SLD, the stage performs subdomain enumeration using passive DNS records, certificate transparency, brute-force wordlists, and permutation of known subdomains. The output is a confirmed set of live hosts -- subdomains that resolve to an IP address and respond to a connection attempt. DDactic typically discovers 40-200% more subdomains than an organization's security team has on record, with staging, development, and internal tool subdomains being the most commonly missed.

Stage 2: Port Scan

Stage 2 runs a comprehensive TCP port scan against all discovered hosts, identifying services beyond HTTP/HTTPS: gRPC on non-standard ports, administrative interfaces, database endpoints exposed to the internet, and SSH/RDP management access. Each open port is service-fingerprinted to determine the exact software and version. CDN-proxied hosts are filtered so the scan targets origin infrastructure, not the CDN edge. This stage frequently identifies ports that are intended to be firewalled but are accessible from specific network paths -- a consequence of misconfigured security group rules or CDN-bypassed origin IPs.

Stage 3: L7 Dispatch

Stage 3 dispatches L7 probes across every protocol exposed by the asset inventory: HTTP fingerprinting (server software, WAF vendor, CDN presence, TLS configuration, baseline response times), GraphQL schema introspection, gRPC service reflection, DNS recursive resolution behavior, SMTP configuration and open relay detection, SIP gateway exposure, and direct-to-router probing for exposed network devices. The WAF and CDN identification step is particularly important because it determines which vendor syntax the hardening engine will use. Baseline response time measurements from this stage become the reference point for saturation testing.

Stage 4: Application Recon

Stage 4 intercepts web, desktop, and mobile application traffic to surface DDoS attack vectors that passive scanning cannot see. API endpoints only reachable through the mobile client, WebSocket connections that bypass WAF rate limits, authenticated flows the public-facing CDN never inspects, and gRPC streams not documented in any public schema -- these are found by observing the application as a real user, not by probing from the outside. Application Recon is handled by DDactic's app-labs system and runs in parallel with the network pipeline stages.

Stage 5: Breach DB & OSINT

Stage 5 queries breach intelligence sources -- HIBP, DeHashed, LeakCheck, LeakIX -- for credentials and API keys associated with the organization's domains. Exposed credentials are correlated with discovered login endpoints and admin panels from Stages 1-4. An attacker with valid credentials can target authenticated API endpoints that have lower rate limits than public endpoints, bypass bot detection entirely, or reach internal dashboards that rely on authentication as their only defense. Breach exposure combined with an unprotected admin panel found in Stage 1 is a materially higher risk than either finding alone.

Stage 6: AI DDoS Analysis

Stage 6 synthesizes findings from all five prior stages using AI analysis. By this point the pipeline has accumulated hundreds of subdomains, port scan results, L7 fingerprints, app-layer surfaces, WAF detection data, and breach exposure counts. The AI stage classifies each asset by type and business impact, scores protection gaps, filters parked domains and defensive registrations, and derives the attack vector set -- mapping each finding to the specific attack patterns an adversary would use. The output feeds directly into the hardening engine, which generates prioritized, vendor-specific CLI commands for every finding.

Hardening recommendations are not a pipeline stage -- they are generated as post-pipeline synthesis by the hardening engine, which reads the full output of all six stages and produces a per-endpoint matrix with commands for Cloudflare, AWS WAF, Akamai, F5, Imperva, Radware, nginx, and others.