The Operator Pain Point Nobody Talks About Honestly
Brute force attacks remain one of the most persistent threats in enterprise environments, yet security teams consistently underestimate how far a determined attacker can get before detection kicks in. The problem is rarely a lack of tooling. Most organizations have firewalls, SIEMs, and authentication logging in place. The gap lives in the space between data collection and actionable response, and attackers have learned to exploit exactly that lag.
Recent threat activity makes this concrete. The 'Popa' botnet, linked by researchers to a publicly-traded Israeli firm, demonstrated how commercial botnet infrastructure can be repurposed for sustained credential attacks against enterprise targets. Healthcare organizations have seen a surge in targeted intrusion attempts in 2025, with attackers cycling through patient portal login pages using distributed brute force tooling specifically designed to stay under rate-limiting thresholds. These are not unsophisticated campaigns. They are engineered to defeat the exact defenses most organizations have deployed.
This article walks through how brute force attacks actually operate in the wild, what detection logic reliably catches them, and what prevention controls hold up when attackers already understand your environment.
How Modern Brute Force Campaigns Actually Work
Brute force in 2025 looks very different from the single-IP, rapid-fire login attempts that older detection rules were built to catch. Modern campaigns distribute authentication attempts across thousands of IP addresses, rotate user agents, introduce randomized delays between attempts, and target a broad list of usernames before cycling back to any individual account. This approach keeps per-IP and per-account attempt counts low enough to avoid triggering most threshold-based alerts.
Botnets provide the infrastructure backbone for this technique. A botnet with 50,000 compromised residential nodes can spread 500,000 login attempts across so many source IPs that no single address generates enough volume to trigger an alert. The WSzero DDoS family, now in its fourth development cycle, illustrates how threat actors iterate botnet infrastructure specifically to defeat detection logic. The same engineering discipline applies to credential attack infrastructure.
Attackers also time their campaigns carefully. Authentication attempts often cluster during business hours in the target organization's timezone, blending into legitimate login traffic. After-hours spikes are now less common in sophisticated campaigns, because defenders have trained alert rules to catch them.
Target Selection and Credential Sources
Brute force campaigns require either wordlist-based guessing or credential lists sourced from prior breaches. The most effective modern attacks use hybrid approaches: common password lists filtered against the target organization's known password policy, combined with breach credential pairs that have not yet been flagged as compromised in public databases. Healthcare organizations are particularly exposed because their systems often run legacy authentication stacks with weaker lockout policies, and breach data tied to patient-facing portals circulates in underground markets for extended periods.
Attackers research targets before launching. Publicly visible information about an organization's authentication infrastructure, whether it runs Microsoft 365, a VPN portal, a custom web application, or a combination of these, shapes the credential list and timing of the attack. Organizations that expose login portals without secondary authentication controls give attackers a clean target surface.
Detection Logic That Produces Signal Instead of Noise
Effective brute force detection requires moving past single-dimension thresholds. A rule that fires when any IP generates more than ten failed logins in sixty seconds will miss distributed campaigns and generate false positives against legitimate users with password issues. Detection logic needs to operate across multiple dimensions simultaneously.
Velocity Tracking Across Accounts
Track failed authentication attempts aggregated at the username level, not just the source IP level. A distributed brute force campaign targeting fifty accounts will generate two or three failed attempts per account from any given IP, but the aggregate failure rate across accounts from a coordinated source cluster will be statistically abnormal. Your SIEM or detection platform should be correlating authentication failures by username across all source IPs within a rolling time window.
Implement a sliding window calculation that looks at failed attempt counts per username across the last fifteen minutes, one hour, and twenty-four hours simultaneously. An account that accumulates eight failed attempts from eight different IP addresses over six hours presents a very different risk profile from eight failed attempts from a single IP in two minutes. Both warrant investigation; only the first pattern suggests a distributed campaign.
Ratio-Based Alerting
Calculate the ratio of failed authentication attempts to successful ones for each application or service. A ratio that shifts significantly from the baseline during any time window, even when absolute volumes remain low, indicates that something has changed. Establish a per-application baseline over thirty days and alert on deviations greater than two standard deviations from the historical mean. This catches low-and-slow campaigns that stay below absolute volume thresholds.
Source IP Clustering
When multiple source IPs attempt authentication against the same set of usernames within a short window, group those IPs and analyze them as a cluster. Look for shared ASN ranges, consistent geographic spread patterns, or timing correlations that suggest coordinated automation. Residential proxy networks are harder to cluster by ASN, but timing analysis often reveals the underlying automation: attempts that arrive with unnaturally regular intervals or that share identical HTTP header fingerprints across different source IPs.
Tools like IP reputation feeds contribute context here, but treat them as supporting evidence rather than primary detection signals. A source IP that does not appear on any known bad list can still be part of an active brute force campaign. Behavioral analysis of the authentication attempt pattern carries more weight than reputation lookup alone.
Behavioral Anomalies in Successful Logins
Detection should extend to successful authentications as well. An account that succeeds after a series of failures deserves immediate scrutiny, particularly if the successful login originates from a device, browser fingerprint, or geographic region inconsistent with the account's history. Post-authentication behavior analysis, looking at what the account does in the first fifteen minutes after a suspicious login, can catch account takeover before significant damage occurs.
Prevention Controls: What to Deploy and in What Order
Prevention requires a layered approach. No single control stops all brute force variants, but the right combination raises the cost of an attack to the point where most campaigns move to softer targets.
This Week: Immediate Hardening Actions
The first priority is enforcing multi-factor authentication across all externally-facing authentication surfaces. MFA does not make brute force impossible, particularly when attackers pivot to MFA fatigue techniques, but it eliminates the primary payoff of a successful credential guess. Organizations that have not yet achieved universal MFA coverage should prioritize VPN portals, email platforms, and any application with access to sensitive data.
Implement account lockout policies with care. Hard lockouts after five failed attempts create a denial-of-service opportunity for attackers who can lock out legitimate users by intentionally triggering lockouts. A progressive lockout approach works better: temporary delays that increase with each failed attempt, combined with CAPTCHA challenges after a configurable failure threshold, without permanently locking accounts after a fixed number of attempts. Thirty-second delays after the third failure, two-minute delays after the fifth, and fifteen-minute delays after the eighth catch automated tools while keeping legitimate users functional.
Audit which services expose authentication endpoints to the public internet. VPN portals, RDP, SSH, and web application login pages all represent attack surface. Any service that does not require external access should be placed behind a VPN or access gateway immediately. For services that must remain publicly accessible, ensure that the login endpoint is protected by rate limiting at the application layer, independent of any upstream firewall rules.
This Week: Logging and Visibility
Verify that authentication logs from every system are flowing into a central SIEM with accurate timestamps and complete source IP data. Gaps in log collection are common, particularly for legacy applications and network devices that use syslog with inconsistent formatting. Run a log completeness audit against your asset inventory. Any system that generates authentication events but does not appear in your SIEM authentication dashboards is a blind spot that an attacker can exploit.
Enable verbose authentication logging on Microsoft Active Directory, Azure AD, Okta, or whatever identity platform your organization uses as its primary directory. Ensure that both success and failure events are captured, along with the source IP, device identifier, and user agent where available. Many default logging configurations capture failures but truncate the detail needed for analysis.
This Month: Architectural Controls
Deploy a Web Application Firewall in front of all externally-facing login pages if one is not already in place. Configure it specifically to enforce rate limiting per IP and per session on authentication endpoints. Thresholds should be tuned to your baseline traffic: a login page that typically sees fifty successful authentications per minute from any given IP range should trigger alerts and temporary blocks if that figure climbs above three hundred within the same window.
Implement IP reputation scoring as a pre-authentication filter. Requests arriving from known Tor exit nodes, commercial VPN providers with high abuse histories, or data center ranges that have no legitimate reason to be accessing your consumer-facing portals warrant additional friction: CAPTCHA challenges, step-up authentication requirements, or temporary blocking. The Progress ShareFile situation, where admins were recently urged to shut down servers over credible threat intelligence, underscores how quickly threat actors move from reconnaissance to exploitation when authentication controls are weak. Pre-authentication IP scoring adds a layer of friction that slows that progression.
Consider implementing device fingerprinting or browser fingerprinting on login pages. Automated brute force tools often share fingerprint characteristics across attempts even when source IPs rotate. Consistent canvas fingerprint values, identical TLS client hello patterns, or missing JavaScript execution signals that suggest headless browser automation can trigger additional authentication challenges before the login attempt reaches your identity platform.
This Quarter: Systemic Improvements
Build or refine a behavioral baseline for every authentication endpoint in your environment. This means collecting thirty to sixty days of clean authentication telemetry, analyzing it to understand normal patterns by time of day, day of week, source geography, and device type, and then configuring automated alerting based on meaningful deviations from that baseline. This investment pays off primarily in detecting low-and-slow campaigns that slip past threshold-based rules.
Evaluate passwordless authentication for high-value accounts and applications. FIDO2-based authentication using hardware security keys or platform authenticators eliminates the credential guessing attack entirely for enrolled accounts. Brute force requires something to brute force; removing the password removes the target. Deployments in highly regulated sectors, including healthcare and financial services, have demonstrated that passwordless adoption reduces authentication-related incidents significantly without degrading user experience for enrolled users.
Establish a process for regularly testing your detection controls against simulated brute force activity. Purple team exercises that generate realistic distributed brute force traffic, including low-and-slow variants and distributed source IP patterns, validate whether your detection logic produces alerts at the right threshold and whether those alerts route to responders with the right context to act. Many organizations discover during these exercises that their SIEM rules fire at the correct time but the alerts contain insufficient context for an analyst to determine whether the activity warrants an immediate response.
Responding to an Active Brute Force Campaign
When detection confirms an active brute force campaign, the response sequence matters as much as the prevention controls.
Start by determining the scope. Identify every username being targeted, every source IP cluster involved, and every authentication endpoint under attack. This scope assessment drives the response. A campaign targeting twenty accounts from a botnet of five hundred IPs requires a different response than a campaign targeting two hundred accounts from a handful of shared infrastructure IPs.
For the targeted accounts, enforce a password reset requirement for any account that experienced a successful login following a series of failures, even if the account appears to be in legitimate use. Attackers who successfully authenticate often wait before taking visible action, and a login that looks normal in isolation may represent a compromised session.
For the source IP clusters, implement temporary blocks at the network edge and at the WAF layer. Share the identified IP ranges with your threat intelligence platform and upstream ISP if the volume warrants it. If the source infrastructure shows signs of being a commercial botnet, as in the Popa botnet case where infrastructure was tied to a specific organization, that attribution context can inform legal and law enforcement escalation paths.
Notify affected users proactively if their accounts were targeted, regardless of whether the attacker succeeded. User awareness of ongoing campaigns reduces the likelihood that users fall for follow-on social engineering attempts that attackers may use if brute force does not succeed.
Metrics That Tell You Whether Your Controls Are Working
Define success through measurable outcomes rather than control deployment. Track the following metrics on a monthly basis and review trends quarterly.
- Mean time to detect (MTTD) for brute force campaigns: How long from the first abnormal authentication event until your detection system generates an actionable alert. Target under fifteen minutes for high-volume campaigns and under four hours for low-and-slow variants.
- Account takeover rate: The number of accounts that were successfully compromised following a brute force sequence, measured per quarter. A downward trend confirms that your prevention controls are effective.
- Alert fidelity rate: The percentage of brute force alerts that correspond to confirmed malicious activity versus false positives. High false positive rates indicate that detection thresholds need tuning. Low fidelity erodes analyst trust and leads to alert fatigue that lets real campaigns go uninvestigated.
- MFA coverage percentage: The fraction of authentication endpoints and accounts protected by MFA. Track this separately for external-facing and internal systems, and report upward to leadership as a risk indicator when coverage falls below your target threshold.
Where Teams Consistently Stumble
Several patterns appear repeatedly across organizations that have suffered successful brute force compromises.
Authentication logging that covers primary identity platforms but misses secondary applications is the most common gap. Web applications, network devices, and cloud services that authenticate independently of the main identity provider create blind spots where brute force activity goes undetected. Inventory every authentication surface in your environment and verify log coverage for each one.
Rate limiting that applies only to the login page but not to the password reset flow is a structural weakness attackers routinely exploit. Password reset endpoints often have weaker controls because they are designed for user convenience, but they represent an equivalent attack surface. Apply the same rate limiting, CAPTCHA, and behavioral analysis controls to password reset and account recovery flows that you apply to primary login endpoints.
Detection rules that were tuned for the previous year's attack patterns and never updated allow current campaigns to pass undetected. The Dutch hackers implicated in the Odido breach, and campaigns like it, succeed partly because defenders are watching for yesterday's techniques. Schedule quarterly detection rule reviews as a standing calendar item and run them against current threat intelligence about active brute force tooling and infrastructure.
Finally, organizations that invest heavily in prevention controls but do not test them regularly operate on assumptions that may be incorrect. A WAF rate limiting rule that was correctly configured eighteen months ago may have been modified, bypassed by a configuration change, or rendered ineffective by an infrastructure update. Test your controls actively. Assume they have drifted and verify that they have not.
Building Toward Durable Resilience
Brute force detection and prevention is not a project with a completion date. Threat actors continuously adjust their techniques to defeat the controls defenders deploy, and the infrastructure they use, from botnets to residential proxies to compromised cloud instances, evolves in response to takedowns and blocklist updates. The organizations that fare best treat brute force defense as an ongoing operational discipline rather than a configuration task.
That means investing in detection quality alongside prevention technology, establishing regular testing cycles, maintaining accurate inventory of authentication surfaces, and ensuring that when an alert fires, the analyst who receives it has the context and authority to act immediately. The technical controls are necessary but the operational discipline around them determines whether they actually stop attacks before accounts fall.
