The Attack Pattern Your Thresholds Were Designed to Miss
In August 2026, updated threat briefs from SANS ISC and multiple commercial intelligence providers flagged a sustained wave of large-scale credential attacks targeting cloud-hosted identity providers, enterprise VPNs, and administrative panels. The campaigns share a recognizable structure: low-volume, high-distribution probing that deliberately stays below account lockout thresholds, rotates source IPs across residential proxy networks, and times requests to blend into normal business-hours traffic. This is not brute force in the traditional sense of hammering a single account until it opens. It is brute force engineered around the defenses most organizations actually deployed.
Ransomware operators and espionage groups both rely on this initial access vector. The connection between credential compromise and downstream ransomware delivery has been documented repeatedly, and as ransomware attacks continue to trend upward heading into late 2026, the pressure on authentication infrastructure has intensified. When the Canadian plea agreement in the Snowflake extortion cases surfaced details about how attacker access was first obtained, stolen credentials and credential-stuffing infrastructure were central to the narrative. Brute force detection is not a solved problem. It is an active battleground.
Why Traditional Lockout Logic Fails Against Modern Campaigns
Account lockout thresholds exist as a blunt instrument. Set lockout at five failed attempts, and an attacker running a distributed campaign simply fires four attempts per account across thousands of accounts before rotating to a fresh IP range. The attacker gets thousands of probes. Your detection stack sees nothing because no single account hit the threshold.
The math here works entirely in the attacker's favor. A credential list of 100,000 usernames with four attempts per account before cycling gives an attacker 400,000 authentication probes against your infrastructure, and none of them trigger a lockout. If even 0.5 percent of those credentials are valid and reused, the attacker has 500 working sessions before you have a single lockout alert.
Residential proxy networks compound this further. When authentication attempts originate from thousands of distinct IP addresses associated with legitimate ISPs and geographic regions, IP-based blocking rules struggle to distinguish attack traffic from normal user logins. The telemetry looks like a mildly elevated volume of failed logins scattered across a wide user population and a wide geographic distribution. That pattern describes both a credential stuffing campaign and a Monday morning when half your remote workforce forgot their passwords over the weekend.
What the Authentication Telemetry Actually Contains
Effective brute force detection starts with understanding what authentication logs actually record and what they omit by default. Most organizations collect failed login events and successful login events. Fewer organizations collect the full context around each authentication event, and that context is where distributed brute force campaigns leave their most readable fingerprints.
The fields that matter most for detection are source IP, user agent string, authentication protocol, time between attempts, geographic origin, ASN of the originating IP, device fingerprint if your identity provider captures it, and the specific error code returned by the authentication system. An attacker rotating IPs through a residential proxy pool will still tend to use a narrow set of user agents, show unusual timing patterns between attempts, authenticate against accounts in alphabetical or sequential order, and generate a specific pattern of error codes that differs from genuine user errors.
Genuine users who forget their password typically fail once or twice against their own account, then either recover through self-service or call the helpdesk. A brute force probe fails against one account, then moves on. That behavioral signature, one or two failures per account spread across a large number of distinct accounts from a structured IP rotation, is far more diagnostic than raw failed-login counts.
Implementing Telemetry Collection That Captures the Right Fields
If you are running Microsoft Entra ID, sign-in logs capture most of the fields described above, but you need to verify that your diagnostic settings are shipping those logs to your SIEM at sufficient retention depth. The recent ISC advisory highlighting admin rights exposure in Entra ID environments is a useful reminder that identity infrastructure configuration drift is common. Pull a sample of your authentication logs and confirm that IP address, user agent, authentication method, and conditional access policy outcomes are all present. If you are missing any of those fields, you are working with partial telemetry.
For on-premises Active Directory environments, Windows Security Event ID 4625 captures failed logons, but the default audit policy on many domain controllers does not log the source workstation accurately for network logon types. Enabling detailed authentication audit logging through Group Policy and shipping those events to a central log aggregator is a prerequisite for any meaningful brute force detection. The audit subcategory you need is Audit Logon Events under the Account Logon category, and you need it enabled for both success and failure.
For Linux SSH environments, /var/log/auth.log or /var/log/secure depending on your distribution records failed authentication attempts, but the default verbosity omits details useful for correlation. Set LogLevel to VERBOSE in sshd_config to capture additional session context, and ensure your log shipping agent is not dropping lines under volume conditions.
Detection Logic That Works Below the Lockout Threshold
The detection rules that catch sub-threshold brute force campaigns look different from rules built around lockout counts. The core detection logic needs to operate at the aggregate level rather than the per-account level.
A practical starting rule: alert when a single source IP generates authentication failures against more than 10 distinct user accounts within a 60-minute window, regardless of failure count per account. This catches the horizontal sweep pattern while ignoring the vertical spike that lockout thresholds already handle. The threshold numbers here are starting points; tune them against your own baseline failure distribution before deploying to production.
A second rule layer should address distributed source campaigns. Alert when authentication failures against your environment originate from more than 50 distinct IP addresses within a single /24 or adjacent ASN block over a 6-hour window, with each IP generating failures against a disjoint set of user accounts. This pattern indicates coordinated infrastructure use rather than independent individual attackers.
A third detection layer should track velocity of successful authentications following a sequence of failures. An account that experiences three failed login attempts and then a successful login from a new IP, new device, and new geographic region within the same session window is a high-confidence indicator of a credential compromise, even if none of the individual events triggered a threshold on their own.
Applying These Rules in Practice
In a Splunk environment, the first rule translates to a search grouping failed authentication events by source IP and counting distinct user accounts over the sliding window, then alerting where that count exceeds your threshold. The query structure uses stats count(distinct user) by src_ip over the time window, filtered to authentication failure event types.
In Microsoft Sentinel, the equivalent uses KQL against the SigninLogs table. You group by IPAddress, count distinct UserPrincipalName where ResultType is not 0 (success), and add a where clause to surface IPs that exceed your account-count threshold within the window. Sentinel's built-in analytics rule templates include some starting points, but the default templates are set to thresholds that most distributed campaigns stay below. Review and adjust them.
Elastic Security users can build these detections as threshold rules in the SIEM's detection engine, using the distinct count of user.name grouped by source.ip over a sliding window. The same logic applies; the implementation syntax differs.
Prevention Controls That Complement Detection
Detection without prevention is an observation. The controls that actually reduce attacker success rates operate at several layers simultaneously.
Multi-factor authentication remains the highest-impact single control for making brute force success operationally irrelevant. Even when an attacker obtains a valid credential through a sub-threshold campaign, MFA prevents session establishment without the second factor. The caveat is MFA fatigue attacks, where attackers repeatedly push MFA prompts to valid accounts until a user accepts out of frustration. Mitigate this by implementing number matching in your MFA configuration and enabling fraud reporting so users can flag unexpected prompts.
Adaptive authentication policies that evaluate login risk at the time of authentication add a friction layer that distributed brute force campaigns struggle against. Microsoft Entra ID Conditional Access, Okta Adaptive MFA, and Duo's risk-based policies all use signals including unfamiliar location, new device, and anomalous IP reputation to require step-up authentication or block the session. These controls are particularly effective because they catch the post-compromise session, even when the credential validation itself succeeded.
CAPTCHA and bot challenge mechanisms at the authentication endpoint intercept automated credential submissions without requiring any account-level state. Implement them on publicly exposed login pages, VPN portals, and any authentication endpoint reachable from the internet. The challenge here is that sophisticated attackers use CAPTCHA-solving services, but these services add cost and latency to the campaign, which reduces the attacker's effective throughput and makes the traffic more detectable through timing analysis.
SSH-Specific Hardening
For SSH infrastructure, the most effective brute force prevention is disabling password authentication entirely and requiring key-based authentication. This makes credential-based brute force attacks structurally impossible against those endpoints. If operational requirements prevent disabling password authentication, move SSH to a non-standard port, implement port knocking or a jump host architecture, and deploy fail2ban or equivalent tools to apply dynamic IP blocking after threshold failures.
Fail2ban configuration for SSH should include both the standard authentication failure pattern and the connection rate pattern. A single IP connecting to port 22 more than 10 times per minute is anomalous even if the credentials have not yet been tested. The connection attempt itself is the signal.
Responding to an Active Campaign
When your detection rules fire on an active sub-threshold brute force campaign, the immediate response priorities are containment, scope assessment, and credential validation.
Containment options depend on your infrastructure. For cloud identity providers, Conditional Access policies can be scoped to block authentication from the identified IP ranges or ASN clusters within minutes. For on-premises systems, firewall rules or WAF policies can block identified source ranges at the perimeter. Be aware that blocking individual IPs in a residential proxy campaign is low-value work; attackers rotate faster than manual IP blocks can chase them. Focus blocks on ASN ranges or IP reputation categories rather than individual addresses.
Scope assessment means determining how many accounts were probed and whether any of the probed accounts show successful authentication following the failed attempts. Pull the list of accounts that appeared in failed authentication events during the campaign window, then cross-reference with successful authentication events in the same window from different source IPs or devices. Accounts appearing in both sets are your highest-priority investigation targets.
Credential validation for potentially compromised accounts means forcing password resets and invalidating active sessions for any account in the high-priority set. Do this before you complete the full investigation, because time between compromise and detection is the attacker's most valuable resource. The reset may inconvenience legitimate users, but it closes the access window for any session the attacker established during the campaign.
Longer-Term Defensive Architecture
The campaigns documented in the August 2026 threat briefs demonstrate that attackers have refined their techniques against the specific defenses most organizations deployed in response to earlier campaigns. That iteration cycle means defensive architecture needs to anticipate adaptation rather than respond to it.
Consider deploying authentication honeypot accounts: valid-looking usernames that no real user would authenticate with. Any authentication attempt against a honeypot account, whether successful or failed, is a high-confidence indicator of credential scanning activity. Because no legitimate user knows these accounts exist, there are no false positives. This technique surfaces scanning activity before attackers reach real user accounts.
Invest in authentication telemetry enrichment. Raw log data tells you what happened. Enriched data tells you what it means. Enriching authentication events with IP reputation scores, ASN threat history, device risk scores, and user behavioral baselines transforms a high-volume log stream into a prioritized signal stream. The enrichment infrastructure has a cost, but it reduces the analyst time required to triage alerts by an order of magnitude.
Finally, establish a regular review cadence for your authentication policies and detection thresholds. The adaptive campaigns documented in 2026 are specifically calibrated against detection systems that were configured and then left static. A quarterly review of your authentication telemetry, comparing current distributions against baseline, reveals threshold drift before attackers exploit it. The work is operational housekeeping, but it is the kind of housekeeping that determines whether your defenses stay relevant against the campaigns currently running against your sector.
