How do attackers use Slowloris?

How Slowloris Works as a Resource Exhaustion Attack

Slowloris is an application-layer denial-of-service technique built around connection hoarding, not bandwidth flooding. The attacker opens many HTTP sessions and then dribbles headers or requests so slowly that the server keeps each connection alive while waiting for completion. The practical effect is that the server's concurrency pool is consumed long before normal traffic volume looks abnormal.

This matters because the bottleneck is often expensive state, not raw packet rate. Depending on the web stack, that state may be worker threads, request queues, reverse proxy slots, or per-client connection limits. A small amount of traffic can therefore create disproportionate service degradation if timeout and concurrency controls are weak.

Why Slowloris Disrupts Web Servers So Effectively

Slowloris works best where the server holds resources open while it waits for a request to finish. If the platform treats incomplete requests as legitimate in-flight work, each slow connection ties up capacity that would otherwise serve real users. That makes the attack attractive against servers or intermediaries that allow many long-lived partial requests from the same source.

The key operational lesson is that effectiveness depends on how the server enforces progress. Short read timeouts, request-header deadlines, and per-connection caps reduce the attack surface, while front-end components such as load balancers, CDNs, and WAFs can absorb or terminate suspiciously idle sessions before they reach the origin. The attacker is exploiting timeout policy, not a flaw in HTTP itself.

Defensive Signals and Practical Limits on Slowloris

Detection is usually about behaviour, not payload content. Look for many open connections with little data transferred, repeated incomplete requests from the same client or subnet, and a growing gap between accepted connections and completed responses. At scale, the signal is often saturation of connection slots or workers with very low throughput per session.

Mitigation works best when layered. Tune idle and header timeouts, enforce minimum data rates where supported, cap concurrent connections per client, and offload HTTP termination to infrastructure that can shed slow sessions early. For critical services, the most important question is whether the origin server can fail closed under prolonged partial-request load without collapsing legitimate traffic.

Risk and Threat Considerations

Slowloris is dangerous because it converts a modest number of connections into a service outage by consuming scarce request-processing capacity. The risk is greatest where front-end controls are weak, timeout settings are lenient, or the server architecture keeps worker resources tied to each incomplete request.

Failure mechanism: The attacker keeps many HTTP requests intentionally incomplete so the server retains threads, sockets, or queue slots until normal users are blocked.

Impact: Legitimate traffic slows down or fails entirely, availability drops, and a low-bandwidth attacker can create disproportionate disruption against poorly tuned web services.

Practitioner Guidance

What to prioritise: Prioritise the controls that shorten resource retention, because Slowloris is won or lost on how quickly the server abandons idle or incomplete work. A secure configuration that still waits too long for request completion remains vulnerable even if total bandwidth is high.

What to verify: Confirm that your edge tier, reverse proxy, and origin all enforce compatible timeout and connection limits. A common mistake is hardening only one layer while another still allows slow sessions to accumulate and exhaust capacity.

Practitioner takeaway: Treat Slowloris as a capacity-management problem with attacker intent behind it, and verify that every layer can stop holding state for requests that are progressing too slowly.

Related resources from NHI Mgmt Group

• Guide: DDoS Protection Guide
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?