When the Botnet Arrives Politely
In mid-2026, researchers tracking the Kimwolf v7 botnet documented something that should reset assumptions about what automated API abuse actually looks like in the wild. Unlike earlier variants that hammered endpoints with obvious flood traffic, Kimwolf v7 distributed its request load across thousands of residential proxy nodes, keeping per-IP request rates below common alert thresholds. Each node sent fewer than 30 requests per minute. The aggregate effect was a coordinated extraction campaign that peeled data from target APIs over days without triggering a single rate limit alert on systems configured around per-IP counting.
This is not an edge case. It is the current state of API abuse, and it exposes a gap that most rate limiting deployments share: the controls are built around a threat model that attackers retired years ago. Understanding where rate limiting works, where it breaks, and what needs to surround it is one of the more practical investments a security team can make before the next campaign lands.
What Rate Limiting Is Actually Measuring
Rate limiting answers a specific question: how many requests has this identifier sent in this time window? The quality of that answer depends entirely on what you chose as the identifier and how you defined the window. Most deployments default to IP address plus a rolling one-minute counter. That configuration is useful against unsophisticated scanners and basic brute force attempts. Against anything more deliberate, it requires support from every layer around it.
The identifier problem runs deeper than many teams realize. An IP address is not a user. A single IP can represent thousands of users behind a corporate NAT, a large university network, or a carrier-grade NAT deployment from a mobile provider. Conversely, as the Kimwolf v7 campaign demonstrated, a single attacker can represent thousands of IP addresses when operating through residential proxy infrastructure. Treating IP-to-user as a one-to-one relationship produces both false positives that block legitimate traffic and false negatives that let coordinated campaigns through.
Authentication tokens, session identifiers, API keys, and device fingerprints each offer a tighter binding between the rate limit counter and the actual entity generating requests. None of them are perfect, and sophisticated attackers rotate these too, but requiring an attacker to burn through authenticated credentials at scale introduces friction that raw IP rotation does not.
The Token Jacking Problem Changes the Stakes
Recent reporting on token jacking campaigns targeting AI APIs illustrates how rate limiting interacts with credential theft in ways that most teams have not fully accounted for. When attackers steal valid API keys or session tokens, they inherit the rate limit budget of the legitimate credential holder. If your rate limiting grants authenticated users 10,000 requests per hour, a stolen token grants an attacker 10,000 requests per hour, with no flag raised at the rate limiting layer because the request volume appears normal for that credential.
This means rate limiting on authenticated APIs needs a behavioral dimension. A credential that historically generates 200 requests per hour and suddenly generates 9,800 requests per hour in a two-hour window represents an anomaly even if it stays technically within the configured limit. Building velocity baselines per credential and alerting on sharp deviations catches this class of abuse where a static limit does not.
The practical implementation here involves storing a rolling average of request volume per API key over a lookback window of seven to thirty days and comparing current activity against that baseline. A threshold like three standard deviations above the credential's historical mean provides a reasonable starting point, with the sensitivity tuned based on your false positive tolerance and the sensitivity of the data the API exposes.
Distributed Abuse and Aggregate Counting
The distributed nature of modern botnet infrastructure requires rate limiting that counts across sources, not just at the source level. This is the architectural shift that most per-IP configurations miss entirely.
Consider a credential stuffing campaign using a botnet similar to the 911 S5 infrastructure that was disrupted but whose operational model has been replicated by successor networks. The campaign assigns each botnet node a fixed number of authentication attempts per hour, keeping every individual node well below typical lockout thresholds. The aggregate attempt volume against your authentication endpoint might reach 50,000 attempts per hour while no single IP exceeds 10 attempts.
Catching this requires counting at the endpoint level across all sources simultaneously. If your /auth endpoint normally receives 500 requests per minute and suddenly receives 3,000 requests per minute, that aggregate spike is a signal regardless of whether any individual IP is misbehaving. Endpoint-level rate limits that trigger on total incoming volume provide a circuit breaker that distributed attacks cannot route around as easily.
Implementation typically happens at the API gateway or load balancer layer, where you maintain a counter per endpoint per time window across all traffic. When the aggregate counter crosses a threshold, you have several response options: return 429 responses universally, introduce CAPTCHA challenges, increase authentication friction, or route traffic through additional inspection. Which response you apply depends on the endpoint's sensitivity and the business cost of disrupting legitimate traffic.
Window Size and the Burst Allowance Problem
Fixed windows introduce a boundary condition that attackers exploit reliably. A one-minute fixed window that allows 100 requests means an attacker can send 100 requests in the last second of one window and 100 requests in the first second of the next, achieving 200 requests in two seconds without violating the limit. This boundary exploitation is predictable and trivially automated.
Sliding window algorithms eliminate the boundary by evaluating the request count over a continuous trailing window rather than discrete time buckets. The implementation requires slightly more storage because you need to track individual request timestamps rather than just an aggregate counter, but the defense against boundary exploitation is worth the overhead for sensitive endpoints.
Token bucket and leaky bucket algorithms offer a different set of tradeoffs. Token bucket allows controlled bursting: a bucket that refills at 10 tokens per second can accumulate up to a maximum capacity, allowing a legitimate user to send a burst of requests after a quiet period. This accommodates real user behavior, where someone might send 50 requests quickly after a period of inactivity, without granting the same burst capacity to a constant-rate automated scanner. The key parameter to tune is the maximum bucket size, which should reflect what legitimate burst traffic actually looks like for your specific user population.
Where Ransomware Groups and API Reconnaissance Intersect
Ransomware groups increasingly treat API reconnaissance as a standard phase of their pre-encryption campaigns. With ransomware attacks continuing to rise through 2026, the API attack surface has become a common initial access vector, specifically because APIs often expose data and functionality without the authentication logging density that endpoint systems carry.
Reconnaissance against APIs typically involves slow enumeration: probing endpoint structures, testing parameter ranges, mapping response patterns, and identifying data boundaries. These probes often arrive at rates that look like normal curious browsing. A rate limit configured to catch floods will not catch an attacker sending 200 requests over four hours to methodically map your API's data model.
Catching reconnaissance requires pattern detection alongside volume detection. An IP or credential that requests a high diversity of unique endpoints within a session is behaving differently from a user navigating known application flows. Measuring endpoint entropy per session, flagging sessions that touch an unusually high number of distinct paths, and correlating those sessions with other weak signals like 404 rates and parameter fuzzing patterns catches reconnaissance traffic that volume-based limits miss entirely.
Implementing this in practice means instrumenting your API gateway to track unique endpoint paths per session alongside request counts. A session that hits 80 different endpoints in 30 minutes, regardless of rate, warrants investigation even if every individual request returns a 200.
Response Strategies Beyond the 429
Returning a 429 status immediately tells an attacker they have been detected and gives them a clear signal to adjust. For many threat actors, especially those using automated tooling, a 429 response triggers a backoff routine that reduces their rate slightly and resumes, eventually finding a pace your rate limiter accepts.
Slowing down responses rather than rejecting them is a more operationally effective response in many scenarios. Introducing artificial latency, sometimes called tarpitting, for clients that exceed soft thresholds forces automated tools to spend time waiting. A scanner that would complete 10,000 requests in an hour now takes 50 hours. This degrades the attacker's ROI without revealing the detection.
Soft limits that trigger increased scrutiny without blocking allow you to route suspicious traffic through additional inspection layers. A request that hits a soft threshold gets subjected to more aggressive fingerprinting, stricter response filtering, or CAPTCHA challenges before receiving full API responses. Requests well within normal behavior flow through the fast path unaffected, preserving performance for legitimate users.
Challenge-response mechanisms calibrated to the endpoint's sensitivity also provide a middle ground. An authentication endpoint that hits a moderate abuse signal might require solving a proof-of-work challenge before proceeding, adding computational cost to automated attacks without fully blocking access. This is particularly effective against credential stuffing because the per-attempt cost increase is paid entirely by the attacker.
Configuration Drift and the Maintenance Reality
Rate limit configurations set during initial deployment drift out of alignment with actual traffic patterns as applications evolve. An API that launched handling 500 requests per minute per endpoint may now handle 50,000 under normal conditions following a product launch or user base expansion. Limits set at deployment that were meaningful then may now be so far above normal traffic that they provide no practical protection against realistic attack volumes.
Quarterly reviews of rate limit thresholds against actual traffic baselines should be a standard operational task. This review compares configured limits against observed normal traffic peaks, identifies endpoints where the gap between normal and limit is so large that the limit provides no realistic protection, and adjusts accordingly. The goal is limits that sit close enough to normal traffic peaks to catch anomalies without being so tight that organic growth triggers alerts.
Automated baselining that continuously tracks p95 and p99 request rates per endpoint and per credential class provides the data needed to keep configurations current without requiring manual log analysis. When the p99 for an endpoint rises above a configured fraction of the rate limit threshold, an alert recommends reviewing the limit rather than waiting for the next scheduled review cycle.
The Architectural Placement Question
Where rate limiting lives in your stack determines what it can and cannot see. Rate limiting enforced at the CDN or edge layer acts on traffic before it reaches your origin infrastructure, which protects origin capacity but may miss attacks that target authenticated API paths requiring session state. Rate limiting enforced at the API gateway has access to authentication context, making per-credential limits possible, but operates closer to origin and absorbs more processing overhead.
Most production environments benefit from layered enforcement: coarse volume limits at the edge to absorb obvious floods, finer behavioral limits at the API gateway with access to authentication context, and application-layer checks for business logic abuse that neither the edge nor the gateway can evaluate. Each layer handles the threat category it is best positioned to detect.
LG's announced policy to ban residential proxies from smart TV apps reflects a recognition that edge identification has become unreliable enough that additional signal beyond IP address is necessary. The same recognition applies to API rate limiting: the IP address is one input, and building controls that function when that input is unreliable requires combining it with session behavior, credential history, device signals, and endpoint-level aggregate counting.
Practical Starting Points for Teams Without Mature Configurations
For organizations that need to establish a functional baseline quickly, a tiered approach provides coverage across the most common attack patterns without requiring a full behavioral analytics platform on day one.
- Authentication endpoints: Apply tight per-IP limits (10 to 20 requests per minute), strict per-credential limits (5 to 10 failed attempts per hour), and aggregate endpoint limits that trigger at three to five times normal peak volume. Log all 429 responses with full context for review.
- Data retrieval endpoints: Apply per-credential limits based on observed normal usage plus a reasonable burst allowance. Flag credentials that request more than twice their seven-day average in any single hour.
- Public or unauthenticated endpoints: Apply per-IP limits using a sliding window to prevent boundary exploitation, with aggregate limits to catch distributed enumeration.
- Administrative or high-privilege endpoints: Apply the strictest limits and log all access regardless of whether limits are triggered. Any anomalous volume here warrants immediate review.
Start with limits set generously above current normal traffic to avoid disrupting legitimate use, instrument everything to collect actual traffic data, and tighten limits as your understanding of normal behavior improves over the first 60 to 90 days.
Translating Telemetry Into Response
Rate limiting generates signal only if someone acts on it. The operational value comes from integrating rate limit events into your detection workflow rather than treating 429 responses as routine noise. Credentials that repeatedly hit rate limits across different endpoints, IP addresses that appear in rate limit logs across multiple customer accounts, and endpoints that repeatedly hit aggregate thresholds at the same time each day are all patterns worth investigating.
Correlating rate limit telemetry with other signals, authentication failures, unusual geographic origins, requests matching known malicious user agent strings, and high 404 rates in the same session, produces higher-confidence detections than any single signal provides alone. Building this correlation into your SIEM or security data lake, even at a basic level, transforms rate limiting from a blunt traffic control mechanism into a detection layer with investigative value.
The campaigns being documented in mid-2026, from botnet-driven data extraction to token jacking targeting AI APIs, share a common characteristic: they are designed to look unremarkable at the individual request level. Rate limiting that measures individual requests against static thresholds will continue to miss them. Rate limiting that measures behavior across time, credentials, and endpoints, and feeds that measurement into active monitoring, provides the coverage these threat patterns actually require.
