DDoS attack patterns show why layered defense still matters

At a glance

What this is: This is a guide to DDoS attack patterns and the layered defenses used to reduce service disruption across network and application layers.

Why it matters: It matters because IAM and security teams need to understand how traffic floods affect availability, control planes, and identity-dependent services even when the primary issue is not credential theft.

Context

Distributed denial-of-service attacks are an availability problem first: attackers overwhelm a target with traffic until legitimate users cannot reach the service. The security gap is not a single broken control but a failure to absorb, distinguish, and shed malicious load quickly enough across network and application layers.

For identity and access programmes, DDoS matters because login, session, API, and admin paths are often the first services to degrade under pressure. When those paths fail, availability controls, incident response, and customer-facing authentication workflows all become part of the resilience problem.

Frontegg’s article frames DDoS as a layered-defence issue rather than a one-control fix. That is the right starting point, because volumetric floods, protocol exhaustion, and application-layer abuse each stress a different part of the stack.

Key questions

Q: What breaks when a DDoS attack overwhelms layered controls?

A: The failure mode is usually not one control, but the combined loss of bandwidth, connection state, and application capacity. When traffic can no longer be filtered fast enough, legitimate users lose access and recovery becomes a coordination problem across network, application, and incident response teams.

Q: Why do volumetric DDoS attacks still cause outages even when the application is healthy?

A: Because availability depends on more than the app itself. If upstream links, packet handling, or provider capacity saturate first, the service becomes unreachable before the application can respond. That is why traffic absorption and rate management matter as much as server hardening.

Q: What are the signs that DDoS protections are failing under real attack conditions?

A: Warning signs include prolonged service degradation, inconsistent recovery across customers, and evidence that defensive systems are not absorbing or redirecting traffic as intended. If an outage lasts far longer than the attack window, or if the service improves only after manual intervention, teams should suspect control weakness. Repeated incidents after deployment changes also suggest the defensive design is not resilient enough.

Q: How should teams respond when identity or API services become the bottleneck during DDoS?

A: Treat identity and API paths as tier-one dependencies and move failover, traffic shaping, and status communications into the response plan. If authentication or token services are slow, the service is already user-impacting, even if other parts of the platform still respond.

Technical breakdown

Volumetric floods: why bandwidth is only the first constraint

Volumetric DDoS attacks try to exhaust network capacity by pushing more traffic than a service or its upstream providers can carry. UDP floods, ICMP floods, and DNS amplification all work by amplifying traffic volume, often through botnets or misconfigured reflectors. The technical problem is not only raw bandwidth. It is also packet processing, upstream filtering, and the ability to discard junk without burning resources on each packet. Once the link saturates, normal users lose access even if the application itself is healthy.

Practical implication: baseline traffic and place rate limits and upstream scrubbing in front of services that cannot survive link saturation.

Protocol exhaustion: how handshake state becomes a target

Protocol attacks abuse the way servers track connection state. SYN floods hold TCP handshakes open by sending connection requests without completing them, which consumes backlog queues and related resources. Ping of death and Smurf-style abuse exploit protocol handling errors or broadcast behaviour to force work that should never have been accepted. These attacks succeed when the target must spend state on unauthenticated or incomplete traffic before it can decide whether the traffic is real. The weakness is state exhaustion, not merely packet count.

Practical implication: harden connection handling with SYN cookies, conservative queue settings, and firewall policies that reject malformed or excessive protocol traffic.

Application-layer abuse: why legitimate-looking requests are harder to block

Application-layer DDoS is harder to filter because the traffic often looks like normal user activity. HTTP floods mimic ordinary GET or POST requests, Slowloris holds connections open with partial requests, and ReDoS drives CPU consumption through expensive regex evaluation. In each case, the server expends application work on traffic that appears syntactically valid. This is why a WAF alone is not enough. The defence also needs behavioural baselines, connection management, and code paths that avoid costly processing on untrusted input.

Practical implication: combine WAF rules with behavioural detection, connection timeouts, and input handling that avoids pathological regex or request parsing.

Threat narrative

Attacker objective: The attacker wants to make the service unreachable or unreliable for legitimate users, causing disruption, cost, and reputational damage.

1. Entry begins with a distributed botnet or reflected traffic source, often built from compromised systems or abused infrastructure that can generate large request volumes on demand.
2. Escalation occurs when the attacker shifts from raw traffic volume to protocol or application-layer pressure, forcing the target to spend state, CPU, or connection slots on junk work.
3. Impact is service unavailability for legitimate users, with degraded logins, slow APIs, failed requests, and broader operational downtime until traffic is absorbed or filtered.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Layered DDoS defence is really an availability governance problem, not a single-security-control problem. A DDoS event stresses bandwidth, connection state, application processing, and incident coordination at the same time. That means security, infrastructure, and application teams all own part of the blast radius, and none of them can solve it alone. Practitioners should treat resilience as a multi-control design requirement, not a perimeter feature.

Application-layer DDoS changes the decision point from blocking traffic to distinguishing intent. When HTTP floods and Slowloris-style attacks imitate normal behaviour, the defender has to reason about request quality, connection duration, and abnormal patterns rather than simple volume. That makes behavioural baselining and service-level thresholds central to modern availability strategy. The practical conclusion is that DDoS readiness now sits closer to runtime detection than static firewall policy.

Identity-path availability is part of the DDoS problem. Login, token, and session services are frequently the first user-facing paths to fail under load, so availability planning has to include identity workflows, not just customer-facing pages. When authentication becomes slow or unreachable, users experience a security incident even if the core issue is traffic saturation. Security teams should evaluate identity-dependent services as tier-one resilience assets.

ReDoS shows that application logic can become a denial-of-service surface. Regular expression processing that looks harmless in testing can become expensive at runtime when attackers craft inputs that force worst-case evaluation. That moves DDoS from network defence into secure coding and input-handling design. The implication for practitioners is clear: performance-sensitive validation logic belongs in security reviews, not just application QA.

What this signals

Identity, session, and API availability should be treated as resilience dependencies. DDoS planning is no longer just about web front doors because modern services often fail first at login, token exchange, or downstream API tiers. Teams that model those paths explicitly can prioritise protection where user disruption actually begins.

Baselining and behavioural thresholds matter more as attacks blend in with normal traffic. When malicious requests look valid, defenders need enough traffic history to spot abnormal connection patterns, request rates, and protocol misuse. That shifts DDoS defence from simple blocking to continuous service profiling.

ReDoS turns application logic into a denial surface. If input validation can be forced into expensive regex evaluation, then secure coding becomes part of availability engineering. The operational lesson is to review high-cost parsing paths before attackers find them.

For practitioners

• Build layered DDoS controls Place firewalls, intrusion prevention, and WAF protections at different points in the stack so each layer can absorb a different attack mode. Pair those controls with upstream cloud scrubbing for traffic that exceeds local capacity.
• Baseline normal traffic patterns Measure expected request rates, connection durations, and protocol mix so unusual spikes stand out quickly. Use those baselines to tune anomaly detection and reduce false positives during legitimate surges.
• Harden protocol handling Tune SYN backlog settings, rate-limit noisy protocols, and reject malformed packets before they consume state. This reduces exposure to handshake exhaustion and broadcast-based amplification.
• Rehearse incident response for service saturation Define who declares an attack, who communicates with users, and who shifts traffic to alternate capacity. Run the plan under realistic load so teams can act while services are still partially reachable.
• Review application code for ReDoS exposure Inspect regular expressions and other expensive parsing paths that attackers can trigger with crafted input. Replace worst-case patterns before they become a production bottleneck.

Key takeaways

• DDoS is an availability attack that can hit network capacity, protocol state, and application processing at the same time.
• The article’s attack patterns show why layered defence, traffic baselining, and upstream scrubbing are all necessary to reduce downtime.
• Practitioners should treat identity paths, connection handling, and expensive application logic as resilience dependencies, not just infrastructure details.

Key terms

• Distributed Denial-of-Service: A distributed denial-of-service attack uses many sources to send enough traffic to a target that legitimate users can no longer get through. The purpose is not theft but disruption, and the defender's problem is service exhaustion at the network or application edge.
• Volumetric Attack: A volumetric attack tries to saturate bandwidth by sending large volumes of traffic to a target. Defenders are forced to absorb or divert traffic at scale, so capacity planning and upstream scrubbing become more important than single-device blocking.
• Protocol Attack: A protocol attack targets the communication rules that systems use to establish and maintain network connections. Common examples exploit connection handshakes with forged or incomplete requests, causing servers to waste resources waiting for responses that never arrive. The goal is to exhaust stateful networking capacity and block legitimate sessions.
• Application-Layer Attack: An application-layer attack targets the service logic that sits above the network stack, often by making requests that look legitimate but force expensive processing. These attacks are harder to filter because the traffic can appear normal until the application slows or fails.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.