All DDoS Definitions
DDoS Testing Definition

Direct-to-Origin (D2O) DDoS Attack

A direct-to-origin (D2O) attack is usually filed under exotic edge cases. It is neither exotic nor rare: it is the default outcome once an origin's real IP address leaks, and a DDoS test exists to find out whether yours is reachable. Once the address is known, the attacker aims the flood straight at it, so the CDN, WAF, or scrubbing layer never sees a packet and its mitigation is simply not in the path.

Direct-to-Origin: the same flood, routed around the edge Attacker knows origin IP CDN / WAF / scrubbing edge absorbs the flood only if traffic passes through it through-edge path mostly absorbed direct-to-origin path: the edge never sees a packet Origin server origin firewall + IP allowlist the only control left The same traffic that dies at the edge succeeds when it skips it, so the edge holding proves nothing A test runs the direct path deliberately and proves the origin refuses unsolicited traffic at the network layer. BlackNeuron™
A Direct-to-Origin attack routes the flood around the CDN, WAF, and scrubbing edge straight to the origin IP, leaving the origin firewall and IP allowlist as the only control a DDoS test can validate.

Path, not payload

D2O is the technique that weaponizes origin IP exposure: the exposure is the leaked address, the attack is what you do with it. The vectors themselves are ordinary. UDP and ICMP floods at the network layer, HTTP floods and slow-rate connections at L7, the same traffic a competent edge discards without effort.

What defines a D2O attack is the route, not the payload. The identical flood that dies at a scrubbing center succeeds when it skips it, because the origin was never provisioned to absorb attack traffic on its own. That is why origin exposure sits on the critical path of the whole attack surface: an edge you cannot force the traffic through is not defending anything, no matter how well it is tuned.

Direct-to-origin: the edge is not in the path Attack flood CDN / WAF / scrubbing healthy, correctly configured Through-edge traffic filtered Aimed at the leaked origin IP: edge never sees a packet Origin server Origin firewall is the only control left Same traffic that dies at the edge succeeds when it skips it BlackNeuron™
Direct-to-origin attack in motion: through-edge traffic is filtered by a healthy CDN and WAF, while a flood aimed at the leaked origin IP routes around the edge entirely and only the origin firewall stands between it and the server.

Why "the edge held" is not an answer

A test that only drives traffic through the edge measures the edge, not the system. If the origin answers on its own address, the edge result is irrelevant, and plenty of stacks with immaculate edge configuration fail here because nobody exercised the direct path.

What a DDoS test measures

A serious test runs the D2O path on purpose. It sends the flood at the raw address and checks whether the origin drops it low in the stack, before any HTTP handler is reached. The controls that make that possible, an ingress allowlist pinned to the CDN's published ranges plus the cloud provider's own network DDoS gate, are catalogued under origin IP exposure; what this test adds is evidence they fire when the packet arrives off-path, rather than an assumption that they will.

The result is binary and it is the one that counts: the origin either rejects the direct hit or it does not. A leaked address stays leaked, so hiding it buys nothing once someone has looked for it. The channels that hand an attacker that address to begin with are worked through in how attackers bypass CDN DDoS protection.