When the Authentication Logs Told the Story Nobody Was Reading
A mid-sized financial services firm running a hybrid environment noticed something unusual during a routine log review: a single service account had generated 847 failed authentication attempts across three different systems over a 72-hour window. The attempts were spaced at irregular intervals, averaging one every five minutes, never triggering the account lockout policy set at 10 consecutive failures. The attacker had done the math. By the time a junior analyst flagged the pattern, the account had already been successfully authenticated twice using credentials that matched a dataset circulating in underground forums.
This scenario plays out across industries daily. Brute force attacks have grown more sophisticated, distributed, and patient. Understanding how to detect them before they succeed — and how to respond when they do — requires building detection logic that extends well beyond failed login counts.
What Modern Brute Force Looks Like in Practice
The textbook definition of a brute force attack involves rapidly cycling through password combinations until one succeeds. Real-world campaigns in 2025 and 2026 look very different. Threat actors operating P2P botnets — a category that security researchers continue to monitor closely given the persistence of infrastructure like the defunct 911 S5 botnet network — distribute authentication attempts across thousands of exit nodes. Each individual node generates a handful of requests, making per-source detection nearly useless unless defenders aggregate across the entire authentication surface.
Three primary attack patterns dominate current campaigns:
- Slow-and-low credential stuffing: Known username-password pairs from breach datasets, submitted at rates designed to stay below lockout thresholds and avoid anomaly scoring.
- Distributed password spraying from botnet infrastructure: A single password or small set of common passwords tested against a large number of accounts simultaneously, with each attempt sourced from a different IP address.
- Targeted account enumeration preceding brute force: Attackers first confirm which usernames exist on a system before investing resources in password cycling, often using timing differences in login failure responses.
The ScanBox keylogger campaigns tied to watering hole attacks demonstrate how credential harvesting feeds directly into brute force pipelines. Compromised credentials collected via keyloggers enter testing pipelines within hours, meaning defenders have a very short window between a credential appearing in attacker infrastructure and its active use against authentication endpoints.
Building Detection Logic That Covers the Full Attack Surface
Layer One: Authentication Event Aggregation
Effective detection starts with centralizing authentication logs from every source in your environment. This means Active Directory domain controllers, cloud identity providers, VPN gateways, SSH daemons, web application login endpoints, API authentication layers, and database access controls. Security teams that only monitor their primary identity provider miss the SSH brute force running against a forgotten jump host, or the API key cycling targeting a development environment with production access.
The aggregation pipeline needs to normalize event fields before analysis. A failed login in Windows Security Event Logs (Event ID 4625) looks structurally different from a failed SSH authentication in syslog, which differs again from a 401 response in an application access log. Define a common schema: timestamp, source IP, target account, authentication method, result, and service identifier. Without schema normalization, correlation rules produce false negatives at exactly the wrong moment.
Layer Two: Behavioral Thresholds Tuned to Your Environment
Generic thresholds — five failures in five minutes from a single IP — catch only the noisiest attacks. Sophisticated campaigns deliberately operate below these thresholds. Build detection rules at multiple aggregation levels:
- Per-source-IP across all target accounts: An IP generating 20 failures against 20 different accounts in an hour is more suspicious than 20 failures against a single account, even though both totals are identical.
- Per-target-account across all source IPs: A single account receiving failures from 50 different IPs over 24 hours represents distributed credential stuffing, even if no individual source crosses a threshold.
- Per-ASN or per-subnet: When multiple source IPs from the same autonomous system generate authentication failures simultaneously, the correlation often reveals botnet infrastructure.
- Velocity changes relative to baseline: An account that normally generates zero failures suddenly receiving even 3-4 failures from unfamiliar source IPs warrants investigation, regardless of absolute count.
SIEM platforms with machine learning capabilities can establish per-account and per-service baselines automatically. For teams running rule-based detection, define rolling windows (15 minutes, 1 hour, 24 hours) and flag deviations from account-specific historical norms rather than applying universal thresholds.
Layer Three: Enrichment at Alert Time
A failed authentication alert without context generates analyst fatigue. Every authentication-related alert should arrive with enrichment already attached. IP reputation data, ASN ownership, geolocation (with appropriate skepticism given its known accuracy limitations), datacenter or hosting provider identification, Tor exit node status, and VPN or proxy indicators should all populate automatically when an alert fires.
The identity layer context matters equally. Which team owns the targeted account? What systems does that account have access to? Has the account been inactive for more than 30 days? Is it a service account with elevated privileges? This information transforms a raw authentication failure count into a prioritized investigation queue. A dormant privileged account receiving credential stuffing attempts from residential proxy infrastructure deserves immediate escalation. A developer account receiving a handful of failures from a known-good corporate IP range during business hours likely doesn't.
The modern SOC increasingly treats identity as its primary defensive perimeter, and authentication telemetry sits at the center of that model. The enrichment layer is what makes authentication signals actionable rather than just voluminous.
Detection Rules Worth Implementing Immediately
The following detection patterns address the attack types currently active across enterprise environments:
Distributed Credential Stuffing Detection
Query: For each target account, count distinct source IPs generating authentication failures within a 24-hour window. Alert when that count exceeds 10 distinct sources. This catches distributed campaigns that keep per-IP failure counts low while systematically testing credentials across your user population.
Tune the threshold by account sensitivity. Service accounts and administrative accounts should alert at 3 distinct source IPs. Standard user accounts can use a higher threshold to reduce noise, but flag anything above 10 regardless of individual IP behavior.
Slow-Rate Brute Force Detection
Query: For each (source IP, target account) pair, calculate the time between consecutive authentication failures. Alert when a pair generates more than 8 failures over a 48-hour period with an average inter-attempt interval greater than 10 minutes. This targets slow-and-low campaigns that deliberately space attempts to avoid rate-based detection.
Success Following Failure Pattern
Query: Identify any successful authentication that occurs within 4 hours of 3 or more failures for the same (source IP, target account) combination, or within 12 hours of failures from 5 or more distinct source IPs against the same account. This correlation between failure patterns and eventual success catches both direct brute force completion and cases where a separate credential stuffing campaign feeds a targeted login attempt.
Off-Hours Authentication from New Sources
Query: Flag successful authentications occurring outside business hours (adjusting for time zone) where the source IP has never previously authenticated against that account. Apply extra weight when the source IP resolves to a hosting provider, VPN service, or anonymization infrastructure. Brute force campaigns often continue running when defenders are least likely to notice, making off-hours success events particularly valuable as detection signals.
Response Playbook Stages
Triage and Scope Assessment
When a brute force detection alert fires, the first 15 minutes should produce answers to four questions. First, has any authentication succeeded? A detected active attack with zero successes is a different response than a detected attack following a successful login. Second, what is the scope — single account, multiple accounts, single service, multiple services? Third, what does the source infrastructure look like — single IP, botnet distribution, known threat actor infrastructure? Fourth, is there active exfiltration or lateral movement already underway?
Query your authentication logs for the targeted account's successful sessions over the prior 72 hours, not just the past hour. Attackers may have already succeeded before your detection threshold fired. Cross-reference any successful sessions against access logs for sensitive systems and data stores.
Containment Actions
Containment decisions depend on whether the attack is ongoing, whether any accounts have been compromised, and whether the attacker appears to have established persistence beyond the authentication layer.
For active ongoing attacks with no confirmed compromise, implement temporary IP-based blocking at the perimeter or WAF layer for source infrastructure generating failures. Apply this cautiously when source IPs are residential or carrier NAT ranges, as blocking them may impact legitimate users. Add CAPTCHA challenges or step-up authentication requirements to the targeted login endpoint temporarily. Force a password reset on accounts that received high failure volumes regardless of whether a success occurred.
For attacks where successful authentication has occurred, treat the session as compromised immediately. Terminate active sessions for the affected account across all services. Reset credentials and revoke any tokens or API keys associated with the account. Disable the account temporarily while conducting post-authentication access review. Examine what the account accessed following the successful authentication, how long the session lasted, and whether any privilege escalation or data access occurred.
Post-Incident Hardening
Every brute force incident, whether stopped before success or caught after, should drive configuration changes. Audit your lockout policies across every authentication surface. The financial services scenario at the start of this article succeeded partly because lockout policies weren't consistent across systems. A 10-failure lockout on Active Directory with no equivalent policy on VPN gateway authentication creates an obvious path for patient attackers.
Evaluate MFA coverage. Accounts reachable via brute force that don't have MFA enforced represent an ongoing vulnerability regardless of how good your detection is. Prioritize MFA enforcement on accounts with access to sensitive systems, accounts with administrative privileges, and accounts accessible from external-facing services.
Review credential hygiene for service accounts specifically. Service accounts often have long-lived passwords, sometimes static credentials shared across multiple services, and frequently lack the MFA protections applied to human accounts. Attackers who target service accounts during brute force campaigns gain access to authentication paths that may never generate user-driven behavior anomalies.
The Botnet Dimension: Why Source IP Blocking Alone Fails
Security researchers monitoring P2P botnet infrastructure have documented how modern brute force campaigns rotate through residential proxy pools and compromised endpoint networks. The 911 S5 botnet infrastructure, disrupted by law enforcement in 2024 but whose operational model has been replicated by successor networks, provided attackers with access to millions of residential IP addresses across virtually every country. Blocking individual IP addresses when an attacker controls a pool of 100,000 addresses accomplishes very little.
This is why target-side detection matters more than source-side blocking. Building detection logic around the behavior of targeted accounts and services, rather than around the characteristics of source traffic, produces detection that works regardless of how distributed the attacking infrastructure becomes. An account receiving credential stuffing attempts from 500 distinct IPs over 24 hours triggers detection based on the account-centric view. The individual IP characteristics become relevant for threat intelligence and investigation, but they don't determine whether the attack gets detected.
AI-driven threat intelligence platforms are increasingly useful here. By correlating attack patterns across organizations and identifying shared infrastructure, botnet C2 patterns, and credential testing pipelines, threat intelligence feeds can provide early warning of campaigns before they reach your specific environment. The caveat is that intelligence feeds require integration with your detection layer to generate actionable alerts rather than background reports.
Honeypot Accounts as Early Warning Infrastructure
One of the most underutilized detection tools available to defenders is the honeypot account — a credential that exists in your directory but belongs to no real user and should never receive a legitimate authentication attempt. Any authentication attempt against a honeypot account is by definition suspicious.
Create honeypot accounts with realistic-looking usernames that match your naming convention, set passwords that match common breach dataset patterns or common password structures, and configure alerting so that any authentication attempt against these accounts generates an immediate high-priority alert. Deploy them across different authentication surfaces: one in Active Directory, one in your cloud identity provider, one in your VPN authentication system.
Honeypot accounts catch two things simultaneously. They detect credential stuffing campaigns that are cycling through user enumeration lists where your real accounts appear alongside the honeypot. They also detect insider threats or compromised internal systems that are systematically attempting authentications across account lists.
Operational Metrics for Ongoing Program Health
Detection programs that don't measure their own effectiveness drift over time. Define and track these metrics monthly:
- Mean time to detect (MTTD) brute force activity: From first malicious authentication attempt to alert generation. Target under 2 hours for distributed campaigns, under 15 minutes for high-velocity single-source attacks.
- Percentage of brute force attempts detected before first successful authentication: This measures whether your detection fires early enough to prevent compromise, not just document it.
- Authentication surface coverage: What percentage of your authentication endpoints feed into centralized logging and detection? Any gap is a blind spot.
- False positive rate on brute force alerts: High false positive rates cause analysts to tune out or lower alert thresholds, both of which benefit attackers.
- MFA coverage percentage by account sensitivity tier: Track progress toward full MFA enforcement across account categories.
Review these metrics in your monthly security operations review alongside incident counts. Brute force detection that works well in January may degrade as infrastructure changes accumulate, new services come online, and log sources shift format or location.
Practical Takeaways for Defenders
Brute force attacks succeed against hardened infrastructure because defenders optimize for the attack patterns they've seen before rather than the patterns active in current campaigns. The financial services account at the start of this article was compromised by a technique that bypassed every threshold the team had configured, using spacing and distribution that the existing rules couldn't aggregate properly.
Build authentication detection that aggregates at multiple levels simultaneously. Invest in schema normalization to ensure every authentication source feeds comparable data into your correlation engine. Enrich alerts automatically so analysts spend time investigating rather than gathering context. Create honeypot accounts and treat any activity against them as a priority signal. Audit lockout and MFA policies across every authentication surface, not just the primary identity provider. And measure detection performance with metrics that reflect actual attack patterns rather than just alert volume.
Brute force attacks are not going away. The infrastructure supporting them — residential proxy pools, P2P botnet networks, leaked credential databases — is abundant, inexpensive, and continuously refreshed. The defensive advantage comes from detection logic that catches campaigns based on behavior patterns an attacker cannot eliminate without abandoning the attack entirely.
