When the Locks Held But the Alarms Never Fired
A regional healthcare organization running a patient portal discovered, during a routine quarterly audit, that a single externally-facing authentication endpoint had received over 400,000 login attempts across a three-week period. The attempts came from 1,200 distinct IP addresses, each contributing a modest volume of requests — carefully throttled to stay beneath the organization's rate-limiting threshold of 20 attempts per minute per IP. No alerts fired. No accounts were locked. Twelve patient accounts were successfully compromised before anyone reviewed the aggregate authentication logs.
This scenario plays out repeatedly across industries. The brute force attack itself was not sophisticated. What failed was the detection architecture: threshold-based rules written for a single-source flood, applied against a distributed campaign that had been deliberately engineered to avoid exactly that trigger. Understanding why detection failed — and how to rebuild the approach — is the core problem this article addresses.
What Brute Force Attacks Actually Look Like in 2026
The term brute force covers a spectrum of behaviors that differ significantly in how they should be detected and mitigated. Classic exhaustive brute force, where one attacker cycles through every password permutation against a single account, is now rare against well-defended systems. Modern attackers use distributed architectures, acquired credential lists, and low-and-slow pacing strategies that make the attack surface much harder to identify at the perimeter.
The 911 S5 botnet, which was dismantled by law enforcement but whose infrastructure and operational patterns continue to influence successor networks, demonstrated how residential proxy pools could distribute authentication attempts across tens of thousands of unique IP addresses. Each IP appeared benign in isolation. The attack signature only emerged when attempts were correlated against the target usernames rather than the source addresses.
Credential stuffing, often conflated with brute force, deserves separate treatment. In credential stuffing, attackers use validated username-password pairs from previous breaches. The attack volume per account is low — sometimes a single attempt per account — but the success rate is dramatically higher than pure brute force. The WeedHack malware campaign that infected over 116,000 Minecraft systems in early 2026 demonstrated how gaming credentials harvested at scale flow directly into credential lists used against financial services, healthcare portals, and enterprise VPNs. The ecosystem connecting initial infection, credential harvest, and downstream abuse is mature and well-organized.
Password spraying, where a small set of common passwords gets tested against a large number of accounts, sits between the two. It avoids account lockout by staying under per-account attempt thresholds. Detection requires cross-account correlation rather than per-account monitoring.
Why Threshold-Based Detection Keeps Failing
Most organizations implement brute force detection through two mechanisms: account lockout policies and rate limiting at the network or application layer. Both have well-documented weaknesses that attackers actively exploit.
Account lockout creates a denial-of-service opportunity. An attacker who understands that an organization locks accounts after five failed attempts can intentionally trigger lockouts across thousands of accounts, disrupting legitimate users while the actual credential theft proceeds through a separate, slower campaign. Several threat actors documented in the ESET APT Activity Report covering Q4 2025 through Q1 2026 incorporated deliberate lockout triggering as a distraction technique during more complex intrusion operations.
Rate limiting based on source IP addresses is defeated by botnet distribution. When the attack load is spread across hundreds or thousands of source addresses, no individual source crosses the threshold. The aggregate attack volume can be enormous while each contributing node appears within normal parameters.
Time-based thresholds suffer from window manipulation. If detection logic looks for ten failed attempts within a five-minute window, an attacker pacing at nine attempts per five minutes evades the trigger indefinitely. The attempts accumulate in logs but no alert fires until someone reviews the data manually.
Building Detection That Catches What Thresholds Miss
Effective brute force detection requires shifting from source-centric to behavior-centric analysis. The following approaches address the specific weaknesses that distributed campaigns exploit.
Cross-Account Failed Authentication Analysis
Rather than alerting when a single account receives multiple failed logins, alert when the same source IP — or the same ASN, user agent, or TLS fingerprint — generates failed authentications across multiple distinct accounts within a defined time window. This directly detects password spraying and distributed credential stuffing that source-based thresholds miss entirely.
The implementation requires that authentication events include account identifiers in a queryable format, and that the detection query runs at an interval short enough to be actionable. A query that runs once per hour against hourly log aggregates will not detect a campaign that completes its initial access phase in 45 minutes. Running cross-account correlation every five minutes against a streaming event source is operationally achievable with most SIEM platforms and provides meaningful detection latency.
Velocity Analysis on Successful Authentications
Failed authentication monitoring catches attempts. Monitoring the ratio of failures to successes, segmented by source, catches compromises in progress. When an IP address or IP cluster shifts from a high failure rate to a sudden successful authentication, that transition is a high-confidence signal. A source that failed 200 times then succeeded once is more suspicious than a source that failed once.
This ratio-based approach also handles the case where attackers rotate through a large credential list and achieve a low but nonzero success rate across many accounts. Each success is preceded by a pattern of failures from related infrastructure that becomes visible when analyzed together.
User Agent and TLS Fingerprint Clustering
Automated credential attacks use consistent tooling. Even when source IPs vary widely, the HTTP user agent strings, TLS client hello fingerprints (JA3 or JA4 hashes), and request timing patterns produced by a single tool or campaign remain consistent. Clustering authentication attempts by these attributes reveals campaigns that IP diversity would otherwise obscure.
A cluster of 800 authentication attempts sharing an identical JA3 fingerprint, arriving from 400 different IP addresses, is a credential stuffing campaign regardless of how clean each individual source address appears in reputation databases. This detection approach requires that your application logs capture TLS fingerprints and that your detection pipeline can perform approximate clustering, but the infrastructure investment is modest relative to the detection value.
Geographic and ASN Behavioral Baselines
For services with identifiable user populations, authentication attempts arriving from unexpected geographic regions or ASNs carry elevated risk scores even before any failure threshold is crossed. A healthcare portal whose users are geographically concentrated in two US states should treat authentication attempts from Eastern European hosting ASNs with heightened suspicion, regardless of the per-source attempt count.
This approach requires building and maintaining baselines, which involves ongoing operational effort. The baseline needs to account for VPN usage by legitimate users, business travel, and workforce distribution changes. Hard blocking based on geography introduces false positive risk; risk-scoring that triggers additional verification for flagged attempts is more operationally sustainable. The tradeoff is that risk-scoring requires a functioning step-up authentication flow, which some applications lack.
Prevention Controls That Hold Under Real Attack Conditions
Detection identifies attacks in progress. Prevention controls reduce the attack surface before the attempt volume builds. The two categories are complementary and both are necessary.
CAPTCHA and Proof-of-Work Challenges
Challenge mechanisms increase the per-attempt cost for automated campaigns. Modern CAPTCHA implementations that analyze behavioral signals rather than relying solely on image recognition provide friction against automated tools while maintaining usability for legitimate users. The limitation is that well-resourced attackers use human CAPTCHA-solving services or machine learning models capable of defeating many challenge implementations. CAPTCHA slows campaigns and raises their cost; it does not stop determined attackers with adequate resources.
Proof-of-work challenges, where the client must complete a computational task before the authentication attempt is accepted, impose a direct resource cost on high-volume attacks. This approach is more resistant to human-solving workarounds but introduces latency for legitimate users and may be inappropriate for latency-sensitive applications.
Multi-Factor Authentication as a Structural Control
MFA fundamentally changes the risk profile of credential compromise. Even when a brute force or credential stuffing attack successfully identifies a valid password, the attacker cannot complete authentication without the second factor. For high-value systems, MFA is the single most effective control against the downstream impact of authentication attacks.
The practical caveat is MFA implementation quality. Push notification fatigue attacks, where the attacker generates repeated MFA push requests until the user approves one accidentally, have been documented in multiple 2025 and 2026 breach reports. Number matching, phishing-resistant FIDO2 keys, and app-based TOTP with limited notification retries mitigate push fatigue. Organizations that deployed basic push MFA and considered the problem solved are still vulnerable to this class of attack.
Adaptive Authentication Based on Risk Signals
Rather than applying uniform authentication requirements to all login attempts, adaptive authentication systems elevate the authentication requirements when risk signals indicate elevated risk. A login attempt from a known user's registered device, from their usual geographic location, at a typical time of day, receives the standard authentication flow. A login attempt from an unrecognized device, an unfamiliar location, and an unusual time triggers step-up authentication or human review.
The risk signals that feed adaptive authentication systems benefit from the same cross-account correlation discussed in the detection section. If 50 accounts are currently being targeted by a credential campaign and one of those accounts is now receiving an authentication attempt from a source involved in that campaign, that context should inform the authentication decision in real time.
Credential Monitoring and Proactive Password Rotation
Credential stuffing attacks succeed because users reuse passwords across services, and breach databases provide attackers with valid credentials before the targeted organization is even aware they are exposed. Organizations can integrate with services that monitor breach databases for employee or customer credentials and prompt proactive password rotation when matches are found. This removes the exposed credentials from the attack surface before they are exploited.
For internal enterprise accounts, comparing password hashes against known-breached hash lists (as Microsoft's Active Directory Banned Password List approach does) prevents users from setting passwords that are already in attacker credential lists, regardless of whether that specific user's account was in a breach.
Specific Scenarios Worth Preparing For
The April 2026 CVE landscape included multiple authentication-related vulnerabilities in web application frameworks and identity providers. Patching CVEs in authentication endpoints is directly relevant to brute force prevention because attackers combine credential attacks with exploitation of authentication bypass vulnerabilities. A target that has not patched a known authentication flaw may experience credential attacks against an endpoint that has reduced or eliminated its lockout and challenge enforcement due to the vulnerability.
The DriveSurge campaign that hijacked thousands of websites for ClickFix and FakeUpdate attacks in mid-2026 illustrates how compromised web infrastructure becomes a distribution platform for malware that harvests credentials. Sites compromised through administrative authentication attacks feed into the same credential ecosystem that powers downstream brute force campaigns elsewhere. Securing your own administrative authentication endpoints is also a responsibility to the broader ecosystem.
The critical flaw in the Kirki WordPress plugin, exploited to hijack WordPress admin accounts, demonstrates that brute force is not the only path to administrative compromise. Attackers combine authentication attacks with vulnerability exploitation based on whichever path of least resistance is available. Detection and prevention controls for brute force should be layered with patching discipline and application-layer vulnerability monitoring rather than treated as a standalone program.
Operational Response When an Attack Is Already Underway
When detection fires and a credential attack is confirmed in progress, the immediate response priorities are containment, assessment, and notification — roughly in that order, with the exact sequence depending on the attack's apparent progress.
Containment options include emergency rate limiting at the load balancer or WAF, temporary CAPTCHA enforcement on the targeted authentication endpoint, geographic or ASN-based filtering if the attack shows clear infrastructure concentration, and temporary lockout of accounts that have reached a defined failure threshold regardless of normal lockout policy. Each of these options carries false positive risk. CAPTCHA enforcement will disrupt legitimate users. Geographic filtering will block legitimate users traveling or using VPNs. The response team needs authority to make these tradeoffs quickly, which means the escalation path and decision authority should be established before the attack arrives.
Assessment determines whether any accounts were successfully compromised during the attack period. This requires reviewing not just failed authentication events but successful events, session activity following successful authentication, and any privilege escalation or data access events following login. Confirmed compromises trigger account disablement, password reset, and session revocation as immediate actions, followed by incident documentation and, where applicable, regulatory notification.
Notification to affected account holders when credentials may have been exposed is both a legal obligation in many jurisdictions and an opportunity to prompt protective action. The messaging should be specific about what occurred, what the organization has done in response, and what actions the user should take, including reviewing activity in other services where they may have reused the compromised password.
Logging Requirements That Make All of This Possible
Detection and response capabilities are bounded by what gets logged. The following authentication event attributes should be captured for every authentication attempt, whether successful or failed: timestamp with millisecond precision, source IP address, authenticated username or account identifier, authentication outcome, user agent string, session or request identifier, application or service name, authentication method used, and where available, TLS fingerprint or device identifier.
Logs should be written to a centralized, tamper-resistant destination. An attacker who gains access to an authentication server should not be able to modify or delete authentication logs. Write-once log forwarding to a SIEM or log management platform with restricted delete permissions provides this protection. Log retention periods should be sufficient to support incident investigations, which typically require at least 90 days of authentication log history and often more for complex intrusions.
Log volume from high-traffic authentication endpoints can be substantial. Organizations sometimes implement sampling to reduce storage costs, capturing only a percentage of authentication events. Sampling destroys the ability to perform accurate cross-account correlation and failure ratio analysis. Authentication logs should not be sampled. If storage cost is a constraint, tiered storage that keeps recent logs in fast, queryable storage and archives older logs at lower cost is a better approach than sampling.
Metrics That Tell You Whether Your Controls Are Working
A brute force detection and prevention program needs measurable outcomes to demonstrate effectiveness and identify gaps. Useful metrics include the mean time to detection for simulated credential attacks in tabletop exercises, the false positive rate for brute force alerts measured by the percentage of alerts that on investigation turn out to be legitimate user behavior, the percentage of successful authentications that were preceded by more than a defined number of failures from the same source cluster, and the coverage rate for MFA across high-value accounts and services.
Organizations that run regular purple team exercises simulating distributed credential attacks against their own authentication endpoints generate the most actionable data for improving these metrics. A simulated campaign using the same distributed, low-velocity techniques that real attackers use validates whether detection rules fire, how long detection takes, and whether response procedures work under realistic conditions. The gap between theoretical detection capability and demonstrated detection capability is often significant and only becomes visible through testing.
