What Does a Brute Force Campaign Actually Look Like From Inside the Authentication Infrastructure?

A Login Storm Nobody Noticed Until the Third Day

A regional financial services firm running a hybrid Active Directory environment noticed something unremarkable on a Monday morning: a slight uptick in failed login attempts against their VPN gateway. The security operations team flagged it briefly, confirmed the lockout policy was active, and moved on. By Wednesday afternoon, four privileged accounts had been compromised. The attacker had not hammered a single account. Instead, they distributed attempts across hundreds of usernames at a rate just below the lockout threshold, rotating source IPs through residential proxies. The lockout policy did exactly what it was configured to do and stopped nothing meaningful.

That scenario plays out repeatedly across enterprise environments, and it illustrates the central problem with brute force defense: most organizations build controls around the mechanics of a decade-old attack style while adversaries have adapted. Understanding what modern brute force infrastructure actually looks like, how detection should be layered, and where response actions need to land is the starting point for building something that holds.

How Modern Brute Force Campaigns Are Structured

Classic brute force attacks are straightforward: an automated tool fires rapid, sequential password guesses against a single account or authentication endpoint. Modern campaigns have evolved far beyond that pattern, and the threat landscape in mid-2026 reflects that complexity. The emergence of botnet frameworks like TuxBot v3, which incorporates LLM-assisted development for evasion logic, signals that attack tooling is increasingly sophisticated. Adversaries are using language model assistance to generate more human-looking timing patterns and to adapt request structures in real time.

Contemporary brute force operations typically fall into a few structural categories:

• Threshold-aware distributed attacks: Attempts are spread across thousands of source IPs, often residential or mobile proxies, keeping per-account attempt rates below lockout thresholds. Each source IP may make only one or two attempts globally.
• Credential stuffing hybrids: Attackers seed brute force attempts with breached credentials from prior data sets, reducing the search space dramatically. The OkoBot malware framework targeting cryptocurrency users specifically combines credential harvesting with automated authentication probing.
• Protocol-layer targeting: Rather than attacking web login portals with active protections, campaigns target legacy protocols like NTLM, SMB, RDP, IMAP, or POP3 that may lack modern rate limiting or MFA enforcement.
• Service-specific tooling: Ransomware groups, including Inc Ransomware which recently exploited SonicWall SMA zero-days, frequently use brute force as a secondary access technique after initial exploitation fails or to expand lateral access once inside.

Ransomware operators like The Gentlemen group have been documented using brute force credential access specifically against remote management interfaces and VPN endpoints as a persistence and lateral movement mechanism after initial access. Treating brute force as a purely perimeter concern misses how deeply it integrates into post-exploitation workflows.

Where Detection Actually Needs to Live

Detection architecture matters more than any single detection rule. Organizations that centralize detection logic in a single control point, typically a firewall or a single SIEM rule, create a detection gap at every other layer. Effective brute force detection requires visibility across multiple data sources simultaneously.

Authentication Log Analysis

Authentication logs are the most direct signal source. The key is moving beyond simple failed-login counts toward behavioral analysis of authentication patterns. Specific fields to monitor and correlate include:

• Event IDs 4625 (failed logon) and 4771 (Kerberos pre-auth failure) on Windows domain controllers, correlated with 4624 (successful logon) to identify eventual success following failure bursts
• Source IP address diversity per username over rolling time windows (15-minute, 1-hour, 24-hour)
• User agent strings and client fingerprints on web-facing authentication endpoints
• Authentication protocol used, specifically flagging NTLM and basic auth attempts against accounts that normally use Kerberos or modern authentication
• Timing deltas between attempts, looking for artificially regularized intervals that suggest automation

A practical detection rule: alert when any username accumulates successful authentication within 24 hours of more than eight failed attempts, regardless of source IP diversity. Most lockout policies protect individual accounts at a single source, but this correlation catches distributed success-after-failure patterns.

Network-Layer Signals

Authentication logs alone miss campaigns that never generate application-layer logs because they target exposed services directly. Network-layer signals complement authentication visibility:

• TCP SYN patterns to authentication ports (22, 3389, 5900, 636, 389, 993, 995) from new or infrequent source IPs
• Connection volume anomalies on RDP and SSH ports, especially from IP ranges with no prior communication history with the environment
• DNS query patterns for authentication infrastructure hostnames from unexpected geographic regions or ASNs
• NetFlow data showing short-lived connections to authentication services that terminate without completing a full handshake

The Xdr33 variant of the CIA HIVE attack kit that emerged recently demonstrates why network-layer visibility matters: sophisticated implants actively avoid generating application-layer authentication noise while still probing authentication infrastructure at the network level.

Endpoint and Directory Signals

On Active Directory domain controllers, specific events complement network and authentication log analysis:

• Event ID 4740 (account lockout) correlated with the caller computer name to identify which system triggered the lockout
• Event ID 4776 (credential validation) failures on domain controllers, which capture NTLM authentication attempts that may not appear in standard workstation logs
• Directory service audit logs for enumeration activity (Event IDs 4661, 4662) that often precedes targeted brute force against specific privileged accounts

Building Detection Logic That Accounts for Distributed Patterns

The critical gap in most brute force detection is the failure to correlate attempts across source IPs. An attacker using 500 residential proxy IPs, each making one attempt per hour against different accounts, generates no per-IP alert. Building detection logic that closes this gap requires cross-source correlation.

A practical SIEM detection approach uses a sliding window query that groups failed authentication events by target username across all source IPs within a configurable time window. A threshold of eight or more unique source IPs generating failed authentication attempts against the same username within a six-hour window is a reliable signal of distributed brute force targeting, with a low false positive rate in most enterprise environments. The threshold should be tuned based on baseline authentication diversity for each environment.

For environments running Splunk, a simplified version of this logic groups authentication failure events by target user, counts distinct source IPs, and alerts when that count exceeds the threshold within the time window. Similar queries translate directly to Elastic SIEM, Microsoft Sentinel, and Chronicle. The specific query syntax matters less than ensuring the detection logic runs continuously against real-time data rather than as a scheduled batch job. Distributed brute force campaigns often complete account compromise in under two hours once the correct credential is found.

For web-facing authentication endpoints, JavaScript fingerprinting and behavioral biometrics signals from the browser session layer add detection capability that IP-based analysis misses. Headless browser characteristics, missing or inconsistent browser headers, and timing patterns inconsistent with human typing all serve as secondary signals when combined with authentication failure data.

Prevention Controls That Hold Under Realistic Attack Conditions

Prevention architecture needs to account for attacker adaptation. Controls that work against simple, high-volume attacks often provide no measurable protection against distributed, threshold-aware campaigns.

Authentication Rate Limiting at Multiple Layers

Rate limiting needs to operate at the username level, the source IP level, and the session level simultaneously. IP-only rate limiting is trivially bypassed with proxy rotation. Username-level rate limiting alone creates a denial-of-service risk against legitimate users. The combination, applied progressively, creates meaningful friction without significant legitimate user impact.

A tiered rate limiting implementation for a web authentication endpoint looks like this in practice:

1. After three failures from a single IP for any username within five minutes: introduce a CAPTCHA challenge
2. After five failures for a specific username from any IP combination within one hour: require a secondary verification step (email or SMS challenge)
3. After ten failures for a specific username across any sources within four hours: temporarily suspend authentication attempts for that username and alert the security team
4. After 50 failed attempts from a single IP within any 10-minute window regardless of target: block the source IP and feed it to the threat intelligence platform

Each tier serves a different attack pattern. Tier one addresses simple automated attacks. Tier two addresses distributed attacks targeting specific accounts. Tier three catches persistent targeted campaigns. Tier four addresses volume-based scanning.

Protocol-Level Hardening

Legacy authentication protocols represent the highest-risk attack surface for brute force campaigns because they typically lack modern rate limiting, MFA support, and behavioral analytics integration. Specific actions with measurable impact:

• Disable NTLM authentication where Kerberos is available. Where NTLM cannot be fully disabled, enable NTLM auditing (Event ID 4776) and alert on NTLM authentication attempts for privileged accounts.
• Block basic authentication on Exchange, Office 365, and other email platforms. Microsoft's own guidance on Conditional Access policies supports blocking legacy authentication as a distinct policy condition.
• Restrict RDP access to internal IP ranges or VPN-connected clients only. Exposed RDP remains one of the most commonly targeted services in ransomware precursor campaigns.
• Implement SSH key-based authentication and disable password authentication on all externally accessible SSH services. This eliminates brute force as an attack vector for those services entirely.
• Audit and restrict LDAP and LDAPS exposure. Directory bind attacks against LDAP are a common technique for account enumeration that often precedes targeted brute force.

Multi-Factor Authentication as a Structural Control

MFA reduces the practical value of successful credential brute force by requiring a second factor the attacker does not possess. The protection is meaningful but not absolute. Device code phishing attacks, including techniques recently documented against Microsoft's own infrastructure, demonstrate that MFA can be bypassed through social engineering of the authentication flow rather than the credential itself. MFA is a necessary control, not a sufficient one.

For environments where full MFA deployment is not yet complete, prioritizing coverage by account risk tier delivers the highest return: privileged accounts first, then accounts with access to sensitive data systems, then all remote access accounts, then general workforce accounts.

Account Lockout Policy Design

Account lockout policies require careful calibration. An overly aggressive policy creates a denial-of-service risk where an attacker intentionally locks all accounts. An insufficiently aggressive policy provides no protection against low-rate attacks.

A practical lockout policy for most enterprise environments: lock after ten failed attempts within a 30-minute window, with a 15-minute automatic unlock or administrative unlock requirement for privileged accounts. This threshold is high enough to avoid accidental lockout of legitimate users during password changes and low enough to limit credential guessing space to a practically unusable range for common password attacks. Fine Grained Password Policies in Active Directory allow applying stricter thresholds to privileged accounts without affecting the general user population.

Incident Response When Brute Force Succeeds

Detection and prevention controls reduce but do not eliminate risk. When a brute force campaign successfully compromises an account, response speed and completeness determine the extent of the resulting incident.

Immediate Containment Steps

The first 30 minutes after detecting a successful compromise following brute force activity are critical:

1. Disable the compromised account immediately, before attempting to understand the full scope. Speed matters more than elegance at this stage.
2. Force token revocation for all active sessions associated with the compromised account, including OAuth tokens, SAML assertions, and Kerberos tickets. In Azure AD and Entra ID environments, the Revoke-AzureADUserAllRefreshToken command handles token invalidation.
3. Preserve authentication logs, network connection logs, and any endpoint telemetry associated with the compromised account before any remediation activity that might overwrite forensic evidence.
4. Identify all resources accessed by the compromised account in the period following the first successful authentication after the brute force activity. This defines the minimum scope of potential data exposure.
5. Search for persistence mechanisms created during the access window: new account creations, group membership changes, scheduled tasks, registry modifications, and new OAuth application authorizations.

Forensic Analysis of the Attack Chain

Understanding how the attack succeeded informs both immediate remediation and longer-term control improvements. Specific questions to answer during forensic analysis:

• Which source IPs were involved in the brute force phase, and what is their threat intelligence profile? Residential proxy infrastructure, VPN exit nodes, and Tor exit nodes carry different implications for attacker sophistication and likely campaign scope.
• What was the timing pattern of the brute force attempts? Highly regularized timing suggests commodity tooling. Variable, human-like timing suggests more sophisticated tooling or manual activity.
• Was the successful credential the actual account password or a credential from a previous breach? Password reuse across the successful credential and other accounts in the environment needs immediate investigation.
• Did the attack target this account specifically or was it caught in a broader sweep? Evidence of prior enumeration activity in directory logs suggests a targeted campaign.

Post-Incident Control Improvements

Each brute force incident provides specific information about which controls failed and why. A structured post-incident process should produce concrete control changes rather than general recommendations. If distributed source IP rotation bypassed IP-based rate limiting, the specific improvement is username-level rate limiting, not a general recommendation to improve monitoring. If the lockout threshold was too high, the specific improvement is a policy change with defined new thresholds.

Operationalizing Detection at Scale

Individual detection rules and controls are necessary but insufficient for organizations managing complex, multi-tenant, or geographically distributed environments. Operational maturity requires building detection workflows that can process authentication telemetry at scale without generating alert fatigue.

Practical operational improvements that move detection programs forward:

• Build a baseline authentication profile for every user account that captures normal source IP ranges, typical authentication times, usual client types, and expected geographic patterns. Deviations from this baseline carry higher alert weight than absolute thresholds.
• Integrate threat intelligence feeds into authentication log analysis in real time so that source IPs with known malicious history trigger immediate escalation rather than waiting for threshold-based alerts.
• Implement automated triage playbooks for common brute force scenarios that handle initial containment steps without requiring analyst intervention, reserving human attention for complex or ambiguous cases.
• Run regular simulations of distributed brute force attacks against your own authentication infrastructure using tools like Medusa, Hydra, or purpose-built red team tooling under controlled conditions to validate that detection logic fires correctly and response playbooks execute as designed.

The threat environment around authentication attacks continues to shift. The integration of LLM capabilities into attack frameworks like TuxBot v3 means that timing patterns, user agent strings, and behavioral signals that currently serve as reliable indicators will become increasingly difficult to distinguish from legitimate traffic. Detection logic built today needs a maintenance cadence that accounts for adversary adaptation, not just a deployment and monitoring model.

Building Controls That Outlast the Attack

Brute force detection and prevention is not a configuration problem that gets solved once. It is an operational discipline that requires continuous attention to attacker technique evolution, infrastructure change management, and detection logic maintenance. The organizations that maintain effective brute force defenses treat authentication telemetry as a first-class data source, invest in cross-source correlation capability, and design prevention controls with the assumption that any single control will eventually be bypassed.

The financial services firm from the opening scenario ultimately implemented username-level distributed attempt correlation, restricted legacy authentication protocols, and deployed Fine Grained Password Policies for privileged accounts. Six months later, a similar campaign targeting their VPN endpoint generated alerts within 40 minutes of the first distributed attempt. The controls did not prevent the campaign. They prevented the compromise. That distinction defines what effective brute force defense actually delivers.