How a Missed Pattern Became a Confirmed Compromise
A mid-sized financial services firm running Microsoft 365 and an on-premises Active Directory environment noticed unusual behavior during a routine compromise assessment. The assessment team, reviewing data from the previous two weeks, found a consistent pattern of failed authentication attempts against employee accounts spread across roughly 300 unique source IPs. The attempts had been running for four days before the security team was engaged. The SIEM had been generating low-severity alerts the entire time, but the alert thresholds had been set to escalate only after 50 failed attempts from a single IP within a 10-minute window. The attacker was generating 3 to 5 attempts per IP across a rotating pool, staying well below the threshold on every individual source.
This scenario is not unusual. The compromise assessment findings referenced in recent threat intelligence reports continue to show that response gaps and missed incidents are common across organizations that have detection tooling in place but have not tuned it to reflect how attacks actually behave. The tooling worked. The logic behind the thresholds did not.
This article focuses on the detection and prevention side of brute force attacks with an emphasis on where standard configurations fail, what more effective architectures look like, and the tradeoffs involved in each approach.
Why Single-Source Thresholds Keep Failing
The intuitive model of a brute force attack involves a single source hammering a login endpoint until a password succeeds or the attacker gives up. That model was accurate in the early 2000s. Modern brute force infrastructure operates very differently.
Attackers using botnet infrastructure or residential proxy networks distribute authentication attempts across hundreds or thousands of IPs. Each individual IP touches a target account only a few times, which keeps it below per-source rate limits and avoids triggering IP-based lockout policies. The attack is still a brute force attack in terms of its goal and behavior, but the signal is horizontally distributed rather than vertically concentrated.
The ARToken PhaaS toolkit and similar services, which have been active in recent Microsoft 365 targeting campaigns, demonstrate how commercially available attack infrastructure now includes credential stuffing and password spray capabilities built on rotating proxy pools. These are not sophisticated nation-state tools. They are services available at low cost that abstract away the infrastructure management entirely. The attacker specifies a target domain, uploads a credential list, and lets the service handle IP rotation, timing randomization, and retry logic.
Detection logic that focuses on per-IP failed attempt counts will miss these campaigns almost entirely unless supplementary signals are incorporated.
Aggregate-Level Detection Signals That Actually Hold
Effective brute force detection requires shifting from per-source analysis to aggregate pattern analysis. The following signals are significantly more reliable when dealing with distributed authentication attacks.
Account-Level Failure Rate Across All Sources
Rather than asking how many times a single IP has failed, ask how many unique sources have failed against a single account within a given time window. An account receiving failed authentication attempts from 15 different IPs within 30 minutes represents an anomaly regardless of whether any individual IP has crossed a threshold. This detection logic is straightforward to implement in most SIEM platforms and surfaces distributed password spray campaigns that per-source logic misses entirely.
Organization-Wide Authentication Failure Velocity
Distributed attacks against many accounts simultaneously will show up as an elevated organization-wide authentication failure rate even when no individual account or IP triggers an alert. Establishing a baseline failure rate for the environment and alerting on deviations of 2 to 3 standard deviations above the mean provides early warning of spray campaigns that are spread thin across both accounts and sources. This requires enough historical data to establish a reliable baseline, which means this detection should be enabled and allowed to build history before it is relied upon operationally.
User-Agent and Behavioral Consistency
Authentication requests from legitimate users show consistent patterns in terms of client application, device, and access time. Requests from attack tools often use generic or malformed user-agent strings, access times that do not align with the user's historical patterns, and geographic locations inconsistent with prior access. None of these signals is individually conclusive, but weighted together they provide meaningful enrichment for authentication anomaly alerts.
Success Following Failure Pattern
A successful authentication from a source that has previously generated failures against the same account, or from an IP that has generated failures against other accounts in the same organization, is a high-confidence indicator of credential compromise. This pattern should generate an immediate alert and ideally trigger an automated response such as requiring MFA step-up verification before the session proceeds.
MFA Configuration Realities
Multi-factor authentication is widely understood to be the most effective single control against credential-based attacks, and that remains true. However, the way MFA is implemented significantly affects how much protection it actually provides.
Push notification MFA is vulnerable to fatigue attacks, where an attacker with valid credentials sends repeated authentication push requests until the user approves one by accident or out of frustration. This technique has been used by groups including those associated with the Scattered Spider activity cluster, whose members recently entered guilty pleas on day one of their trial after a series of high-profile social engineering and credential attacks against enterprise targets. Number matching and additional context in push notifications reduce the effectiveness of fatigue attacks but require configuration changes that many organizations have not yet made.
FIDO2 and passkey-based authentication eliminates the phishing and fatigue attack surface entirely because the authenticator is bound to the legitimate origin domain. For environments where this is deployable, it represents a meaningful security improvement over TOTP or push-based MFA. The practical barriers to FIDO2 adoption include hardware costs, enrollment workflows for large user populations, and compatibility with legacy applications that cannot support modern authentication protocols.
Organizations that cannot immediately move to FIDO2 should prioritize enabling number matching on push MFA, configuring conditional access policies that require stronger authentication factors for high-risk sign-ins, and auditing which accounts and applications still allow legacy authentication protocols that bypass MFA entirely. Legacy authentication bypass is one of the most consistently exploited gaps in Microsoft 365 environments and continues to appear in compromise assessment findings.
Account Lockout Policy Design
Account lockout policies create a direct tradeoff between attack friction and availability impact. Aggressive lockout policies make brute force attacks more difficult but also create a denial-of-service condition if an attacker deliberately triggers lockouts against many accounts simultaneously.
The design question is not simply how many failed attempts to allow before locking an account, but what the lockout means operationally and how quickly accounts can be unlocked. Organizations with 24/7 help desk coverage may be able to tolerate a lower threshold than those where account unlocks require waiting for business hours. Service accounts that run automated processes should be handled separately from user accounts, with monitoring rather than automatic lockout where possible, because locking a service account can cause cascading failures in production systems.
Progressive delay policies, sometimes called increasing lockout duration or tarpitting, impose increasing authentication delays after repeated failures rather than immediate full lockouts. This approach maintains usability for legitimate users who have forgotten a password while significantly increasing the cost of automated attacks. Implementation support varies by identity platform, so this is worth evaluating based on what the environment actually supports.
Protecting Externally Exposed Authentication Endpoints
Every externally accessible application with an authentication endpoint is a potential brute force target. This includes web applications, VPN portals, RDP gateways, SMTP servers with authentication, and API endpoints that accept credentials.
VPN and remote access portals deserve particular attention because successful authentication grants network access rather than just application access. Recent threat intelligence reports have consistently flagged VPN credential attacks as a primary initial access vector. Fortinet, Cisco, and Pulse Secure VPN endpoints have all been targeted at scale in the past 18 months. These endpoints should be behind MFA unconditionally, should log all authentication attempts with enough detail to support analysis, and should have rate limiting configured at the infrastructure level to add a layer of protection independent of the application's own lockout logic.
Web application firewalls can provide centralized enforcement of authentication rate limiting across multiple applications, including applications where the underlying platform has limited native controls. The value here is consistency. An organization with 40 web-facing applications is unlikely to have tuned authentication protections on every one of them. A WAF policy applied at the perimeter provides a baseline even where application-level controls are incomplete.
API endpoints that accept credentials require their own consideration. API authentication attacks are often automated and high-volume, and API endpoints sometimes have different error-handling behavior than web UIs that can make detection harder. Authentication failures from APIs should flow into the same SIEM detection logic as other authentication events, and API-specific rate limiting should be implemented at the API gateway layer.
Credential Exposure Monitoring
Brute force attacks against real accounts become significantly more efficient when the attacker has access to a compromised credential list. The dark web market for corporate credential lists is active and growing. Credentials exposed in third-party breaches where users have reused passwords are a primary source of material for targeted spray campaigns.
Integrating a compromised credential feed into the authentication pipeline allows organizations to identify and force password resets for accounts whose credentials appear in known breach datasets before those credentials are used in an attack. Microsoft's Active Directory Password Protection service includes a basic version of this for on-premises AD, and similar capabilities are available through identity security platforms such as CrowdStrike Falcon Identity Protection, Semperis, and others. HIBP's enterprise API provides another option for integration into custom authentication workflows.
The operational process around credential exposure monitoring matters as much as the technical integration. A credential exposure detection is only valuable if it triggers a defined response. Organizations should document what happens when a match is detected, who gets notified, and what the user experience looks like for the forced reset workflow.
Log Retention and Detection Coverage Gaps
One finding that recurs in compromise assessment engagements is that organizations discover they cannot reconstruct the timeline of an attack because authentication logs were either not retained long enough or were not being forwarded to the SIEM at all. The financial services case described at the opening of this article was actually in a better position than many organizations because the logs existed. In cases where authentication events are only retained for 30 days in the identity platform and the SIEM was not ingesting them, investigators have nothing to work with.
Authentication logs should be retained for a minimum of 90 days in a queryable format, with longer retention for regulated environments where breach notification timelines may require reconstructing events from months prior. For Microsoft 365 environments, this means configuring audit log retention in the Purview compliance portal and confirming that unified audit log events are flowing into the SIEM. The default audit log retention period in Microsoft 365 is 90 days for most license tiers, which is adequate as a floor but may not be sufficient for all incident response scenarios.
Organizations should also verify that authentication events from all relevant sources are actually being ingested. VPN authentication events, cloud identity provider logs, and on-premises AD security events all need to be part of the picture. Gaps in ingestion are common and are often discovered during incident response rather than in advance.
Detection Testing and Tuning Cadence
Detection logic that has never been tested against realistic attack patterns should not be relied upon. This sounds obvious but detection testing is one of the most consistently deferred activities in security operations. Thresholds get set during initial deployment, alerts generate noise or silence, and the configuration drifts away from anything that would catch a real attack.
Adversary simulation exercises that include credential attack techniques are the most direct way to validate that brute force detection is working. These can range from a dedicated red team engagement to a tabletop exercise where the team walks through what the SIEM would see given a specific attack pattern. The goal is to identify whether the detection logic would generate an actionable alert before the attack succeeded, and if not, to understand exactly why.
Detection tuning should be treated as an ongoing activity rather than a one-time configuration task. Changes in user authentication behavior, new applications, and new attack techniques all affect whether existing detection logic remains effective. A quarterly review of authentication-related detection rules, including a check against recent threat intelligence on active attack methods, is a reasonable minimum cadence for most environments.
Response Automation Considerations
Automated response to brute force indicators can significantly reduce the window between detection and containment. Common automated response actions include IP blocking at the WAF or firewall, account suspension pending investigation, requiring MFA step-up for a session, and generating a high-priority ticket for analyst review.
Each of these carries a false positive risk that needs to be accounted for in the automation design. Automated IP blocking based on authentication failure counts can block legitimate users sharing a NAT gateway. Account suspension based on failure patterns can lock out employees. These outcomes need to be weighed against the alternative of a slower manual response that allows a compromised session to persist.
A tiered approach generally performs better in practice than binary automated blocking. At lower confidence levels, the automated response adds friction such as requiring MFA step-up rather than fully blocking access. At higher confidence levels, where multiple signals converge, automated suspension or blocking is appropriate. This design requires more upfront configuration work but produces fewer false positives that damage user trust in the security team's operations.
Where This Leaves Security Teams Operationally
Brute force attacks are among the most well-understood threat categories in cybersecurity, yet they continue to succeed at scale against enterprise environments. The gap is not usually in awareness of the problem. It is in the mismatch between how detection is configured and how attacks actually operate, combined with log coverage gaps that make retrospective analysis impossible.
The practical starting point for most teams is an honest audit of what authentication events are being ingested, whether detection thresholds reflect distributed attack patterns or only single-source patterns, and whether MFA is enforced across all externally accessible authentication endpoints including legacy protocol access. Those three questions, answered accurately, will surface the most significant gaps faster than any broader assessment.
The threat landscape as reflected in recent June and July 2026 threat intelligence reporting shows no sign that credential-based attacks are decreasing in frequency or sophistication. Commercial phishing and credential attack services lower the barrier to entry for attackers, and the volume of exposed credentials available from prior breaches continues to grow. Detection and prevention logic built for an earlier era of attack behavior needs to be revisited against what the threat actually looks like today.
