Before a DDoS attack launches, there is a reconnaissance phase. Attackers do not flood random IPs. They identify the most vulnerable target within your perimeter -- the endpoint with the highest processing cost, the lowest rate limit, or the IP that bypasses your CDN. The DDactic scan pipeline replicates this reconnaissance phase from the attacker's perspective, using the same data sources and techniques, to surface the same target list before the attacker does.
Understanding the attacker's methodology is useful for two reasons. First, it explains why DDactic findings are ordered the way they are -- by attacker value, not by CVSS score. Second, it explains why defenses focused only on the primary production domain miss the most vulnerable targets, which are typically on forgotten subdomains or staging environments.
Stage 1: SLD and Subdomain Enumeration
Attackers start from the company name and derive the set of registered domains. They use certificate transparency logs (crt.sh), passive DNS databases (SecurityTrails, DNSDB), and WHOIS reverse lookups on the known organization name. This yields all second-level domains registered by the target, including acquisitions, regional variants, and development domains. DDactic's Stage 1 replicates this using the same data sources plus ASN lookup to find all IP prefixes owned by the organization.
Stage 2: Live Host and Port Discovery
From the SLD list, attackers perform DNS resolution and port scanning to identify live hosts. They prioritize ports 80, 443, 8080, 8443, and gRPC port 50051. For each live host, they check whether the response comes from a CDN or directly from an origin IP. Direct origin IPs are the most valuable targets: they bypass CDN-level protection entirely. CDN detection uses TLS certificate fingerprinting and HTTP response header analysis.
Stage 3: Attack Surface Profiling
For each live host, attackers identify the technology stack from HTTP headers, TLS attributes, and response body characteristics. They look for: version disclosures in Server or X-Powered-By headers, framework identifiers in error responses, CMS identifiers in HTML comments, and API documentation endpoints (/swagger.json, /openapi.yaml, /graphql). API documentation is particularly valuable because it lists every endpoint and its input schema -- an attack planning resource provided by the target.
Stage 4: Rate Limit and Defense Profiling
Attackers probe for rate limit thresholds by sending request sequences at increasing rates and observing when 429 responses appear (or do not). They also check for WAF vendor signatures in error pages, challenge page formats, and HTTP response headers. Knowing whether the target uses Cloudflare, AWS WAF, or Akamai tells the attacker which bypass techniques to attempt. They probe for request parameters that WAF rules do not match (custom headers, non-standard content types, HTTP/2 multiplexing behavior).
How DDactic Mirrors This
DDactic's six-stage pipeline performs the same discovery steps with the same techniques, but with two additions the attacker lacks: breadth of historical comparison across hundreds of assessed organizations, and a structured output format designed to produce actionable hardening recommendations rather than an attack plan. The findings are ordered by attacker value -- the highest-OPI-impact gaps first -- because those are the gaps the attacker would exploit first.
The reconnaissance output is the same regardless of who is running it. The difference is what you do with it. DDactic delivers the attacker's view of your perimeter before the attacker acts on it.
See Your Perimeter Through the Attacker's Eyes
DDactic's scan produces the same target map an attacker would build -- and tells you how to remove the highest-value targets from it.
Run a Free Scan