The Attack Has Evolved. Most Detection Hasn't.
In mid-2024, threat actors targeting Instagram accounts didn't rely on phishing links alone. Reports emerged of attackers leveraging Meta's own AI support infrastructure to gather account metadata and then launch targeted credential attacks against high-value accounts. The brute force component wasn't random noise — it was surgical, informed by harvested data, and timed to avoid lockout thresholds. The accounts fell not because defenses didn't exist, but because the detection logic was tuned for a simpler attack than the one that arrived.
That pattern repeats across industries. Ransomware groups conducting pre-encryption reconnaissance routinely use distributed brute force campaigns against RDP, VPN gateways, and SSH endpoints to establish their initial foothold. As ransomware attacks continue rising in frequency and sophistication through 2025, the credential attack surface has become the most common entry point defenders are under-monitoring. The Dutch authorities who recently seized 800 servers and arrested two individuals for aiding cyberattacks found credential compromise infrastructure running at scale inside that network — automated attack tools targeting authentication endpoints across multiple sectors.
This article walks through what modern brute force looks like at the telemetry level, where detection logic breaks down, and what concrete controls actually stop the attacks that security teams are facing right now.
What Modern Brute Force Actually Looks Like in the Wild
The term brute force covers a wide range of attack techniques, and treating them as a single threat model is one of the most common detection failures. At one end, you have traditional sequential attacks: automated tools cycling through common password lists against a single account. At the other end, you have distributed low-and-slow campaigns that operate below threshold triggers by spreading attempts across thousands of IP addresses, often sourced from residential proxy networks or compromised cloud instances.
Between those extremes, there are several variants that security teams encounter regularly:
- Reverse brute force: A single common password tested against thousands of usernames simultaneously. This never triggers per-account lockout policies because no account exceeds the attempt threshold.
- Credential stuffing scaled with stealth: Validated credential pairs from breaches — like the 2.5 million records exposed in the recent student loan data breach — tested methodically against target services. Attackers pace requests to appear as normal user traffic.
- Protocol-specific attacks: Targeting SSH, RDP, SMTP, and LDAP directly, often using tools like Hydra, Medusa, or custom tooling that mimics normal client behavior to avoid protocol-level anomaly detection.
- API endpoint hammering: Authentication APIs that lack the same controls as web login forms become the preferred target. Attackers frequently map front-end protections, then pivot to backend or mobile API authentication paths that have looser controls.
The Russian attackers who weaponized WinRAR flaws against Ukrainian organizations demonstrated a combined approach: exploit a file parsing vulnerability to drop tooling, then use that tooling to conduct internal credential attacks. The brute force component wasn't the headline, but it was the mechanism that enabled lateral movement after initial access. This is now standard operating procedure for organized threat actors — brute force as a phase, not a standalone campaign.
Reading the Telemetry Correctly
Detection starts with understanding what signals are actually meaningful versus what creates alert fatigue. The following telemetry sources provide the most actionable data when configured correctly.
Authentication Logs
Authentication failure logs are the obvious starting point, but raw failure counts without context miss the most dangerous attack patterns. The signals that matter most are velocity per source IP, velocity per target account, geographic consistency relative to the account's normal access pattern, and user-agent strings that don't match expected client behavior.
A single account seeing five failed logins from the same IP in sixty seconds looks very different from five failed logins from five different IPs across fifteen countries in the same window. Both patterns represent brute force, but only the second one bypasses standard lockout logic. Your detection rules need to aggregate across source IPs, not just count failures per account.
In environments running Active Directory, failed Kerberos pre-authentication attempts (Event ID 4771) and NTLM authentication failures (Event ID 4776) provide granular visibility. Pay particular attention to 4771 events with failure code 0x18, which indicates a wrong password, versus 0x6, which indicates an unknown username — the ratio between these two tells you whether the attacker has a validated username list or is enumerating accounts.
Network Flow Data
Authentication logs only show what reaches your identity infrastructure. Network flow data shows the full scope of the attack, including probing activity that never results in an authentication attempt because the attacker is still mapping the environment.
Look for high connection rates to authentication-related ports from single source IPs or small IP ranges. RDP (3389), SSH (22), LDAP (389/636), and SMB (445) are the most commonly targeted. Flow data that shows short-lived connections with consistent timing intervals often indicates automated tooling. Human users do not authenticate with 200-millisecond precision at 3 AM.
Attackers increasingly abuse cloud logging gaps — a technique covered in recent threat intelligence reporting — to conduct attacks while minimizing forensic visibility. Watch for authentication traffic that doesn't appear in your centralized logging despite originating from monitored segments. That gap is where distributed brute force campaigns hide.
Endpoint and Application Logs
Web application authentication endpoints generate their own telemetry that doesn't always feed into SIEM pipelines automatically. Web server access logs, application-level authentication audit logs, and WAF event logs all carry signals that correlate with brute force campaigns.
HTTP authentication attacks against web applications often appear as high-volume POST requests to login endpoints with consistent header patterns. The User-Agent field is often identical across thousands of requests, or follows a rotation pattern that cycles through a small set of values. Request timing is machine-regular. Cookie handling is often absent or minimal because automated tools don't maintain session state the way browsers do.
Where Detection Rules Break Down
Standard detection logic fails against modern brute force for several specific reasons that are worth understanding individually.
Fixed-threshold lockout policies create a known ceiling that attackers design around. If your policy locks an account after ten failures, attackers send nine and move on. Distributed campaigns send one attempt per IP across thousands of IPs. The account never locks. The failures never cluster. Without cross-source aggregation, the attack is invisible.
Time window assumptions in detection rules assume attacks are concentrated. A campaign sending one authentication attempt per hour per account across 10,000 accounts doesn't look like a brute force attack in any single hour. Over 48 hours, it's worked through hundreds of thousands of credential combinations. Detection rules with sliding windows of 15 minutes miss this entirely.
Allowlisted IP ranges inside corporate environments provide a reliable attack surface. Compromised endpoints inside the trusted network, or attackers who have established a foothold via another vector and are now conducting internal credential attacks, operate inside the perimeter where many brute force detections don't look. Internal-to-internal authentication failures warrant the same scrutiny as external-to-internal.
API endpoints with separate authentication paths from the web front-end often have fewer controls deployed. Mobile app backends, partner APIs, and legacy integration endpoints regularly lack the WAF rules, rate limiting, and MFA requirements applied to primary login pages. Attackers map these gaps specifically.
Building Detection That Actually Works
Effective brute force detection requires layered logic that accounts for distributed sourcing, time-spread campaigns, and internal attack paths. The following controls, implemented together, provide meaningful coverage.
Behavioral Baselines and Anomaly Scoring
Static thresholds alone are insufficient. Build behavioral baselines for authentication patterns per account, per service, and per source subnet. Deviation from those baselines — even if the absolute numbers don't cross static thresholds — should generate scored alerts for analyst review.
Authentication at unusual hours for a given account, from unusual geographies, against services the account doesn't normally access, or with client characteristics inconsistent with the account's typical pattern all represent anomalous signals. No single signal is definitive. Combined into a risk score, they surface attacks that threshold-based rules miss.
SIEM platforms like Splunk, Microsoft Sentinel, and Elastic SIEM support behavioral analytics through machine learning modules. These require a training period with clean data, so deploying them during an active incident has limited value. The time to configure behavioral baselines is before the campaign begins.
Cross-Source IP Aggregation
Detection logic must aggregate authentication failures across all source IPs to a single target account and across all target accounts from a single source subnet. The first catches reverse brute force and distributed credential stuffing. The second catches traditional brute force and targeted account attacks.
In SIEM query terms, this means grouping authentication failure events by destination account across a sliding time window of at least 24 hours, counting distinct source IPs, and alerting when that count exceeds a defined threshold. Separately, group by source subnet across the same window and count distinct target accounts. Both queries run continuously and feed into alert queues with appropriate priority levels.
Honeypot Accounts and Canary Credentials
Deploying dormant accounts with realistic names and no legitimate use generates zero false positives when triggered. Any authentication attempt against these accounts — successful or failed — is an unambiguous attack signal. These canary accounts in Active Directory, cloud identity providers, or web applications catch attackers working through credential lists that were compiled from old directory scrapes or breach data.
Create a small set of these accounts across different naming conventions, include them in directory listings where attackers might find them, but ensure they have no access to any resources. Every authentication event against them goes directly to a high-priority alert queue and bypasses normal threshold logic.
Progressive Friction and Adaptive Authentication
CAPTCHA, device fingerprinting, and step-up authentication challenges imposed based on risk scoring slow automated attacks without impacting legitimate users proportionally. An attacker running thousands of automated authentication attempts per minute faces compounding friction from each additional challenge layer. A legitimate user authenticating from a recognized device at a normal time faces none.
Modern identity platforms including Okta, Azure AD (Entra ID), Ping Identity, and Auth0 all support adaptive authentication policies driven by risk signals. Configuring these policies to trigger on velocity anomalies, new device fingerprints, impossible travel indicators, and known-bad IP reputation data provides automated friction that doesn't require analyst involvement for every event.
MFA Enforcement and Resilience
Multi-factor authentication remains the single highest-impact control against credential-based attacks. An attacker who successfully brute forces a password still can't authenticate without the second factor. MFA enforcement across all externally accessible services — VPN, RDP, SSH, cloud consoles, web applications — makes brute force attacks economically unattractive for most attackers.
The exception is MFA fatigue attacks, where attackers send repeated authentication push notifications to wear down users into approving access. Number matching and context-based MFA approval (requiring the user to enter a code shown on screen, not just tap approve) eliminate this vector. Configure your MFA platform to require number matching for all push-based approvals.
Operational Response When a Campaign Is Active
When brute force telemetry indicates an active campaign, the response sequence matters as much as the controls themselves.
First, determine the scope. Is the attack targeting a single account, a service, or the entire authentication infrastructure? Is the source distributed across many IPs or concentrated? Scope determines response priority and the right countermeasures. A concentrated attack from a small IP range warrants immediate IP-level blocking. A distributed campaign from thousands of IPs requires different logic.
Second, check whether any attempts have succeeded. Authentication success events interspersed with failure events, particularly from the same source IPs participating in the brute force campaign, indicate compromise. Those accounts require immediate credential reset, session termination, and forensic review of post-authentication activity.
Third, engage rate limiting at the infrastructure layer. Web Application Firewalls, API gateways, and load balancers can impose rate limits on authentication endpoints in real time without application changes. Dropping the allowed request rate to authentication endpoints to a few requests per second per source IP kills most automated attack tooling. Legitimate users don't notice.
Fourth, feed indicators into your threat intelligence pipeline. Source IPs, user-agent strings, credential patterns, and timing signatures from the active campaign all become detection rules for the next wave. Attackers frequently rotate and return. The data from this campaign improves detection against the next one.
Infrastructure-Level Hardening That Reduces Attack Surface
Detection and response handle active attacks. Hardening reduces the attack surface before campaigns begin.
RDP should not be exposed directly to the internet under any operational justification. Remote access through RDP should route through a VPN with MFA or through a dedicated remote access gateway. Direct RDP exposure on port 3389 attracts continuous automated brute force from threat actor infrastructure globally, 24 hours a day. If your asset inventory still contains internet-exposed RDP endpoints, closing that exposure is the highest-priority hardening action available.
SSH access should use key-based authentication with password authentication disabled entirely. Fail2ban or equivalent tooling should be running on all SSH-accessible systems to automatically block IPs after defined failure thresholds. The authorized keys file should be audited regularly to remove keys belonging to former employees or compromised accounts.
LDAP and Active Directory authentication endpoints should not be accessible from outside the internal network. LDAPS (LDAP over SSL) should be enforced for all internal authentication traffic. Anonymous LDAP binds should be disabled. These configurations prevent external enumeration attacks and limit the attack surface for internal lateral movement via credential attacks.
Password policies should enforce minimum length and complexity while simultaneously checking new passwords against known-breached password lists. Microsoft's Azure AD Password Protection and similar tools check candidate passwords against the HaveIBeenPwned dataset and internal banned password lists before allowing the change. A technically complex password that appears in a breach database provides no real protection. Length requirements combined with breach checking are more effective than complexity rules alone.
What Good Looks Like in Practice
An environment with mature brute force defenses has several characteristics that are worth using as a benchmark.
Authentication telemetry from all services flows into a centralized SIEM within minutes, not hours. Detection rules aggregate across source IPs and across time windows of at least 24 hours. Behavioral baselines are active and tuned to the organization's actual authentication patterns. Canary accounts exist and generate high-priority alerts on any authentication event. MFA with number matching is enforced on all externally accessible services. Rate limiting is configured on all authentication endpoints at the WAF or load balancer level. RDP, SSH, and LDAP are not directly internet-accessible. Password policies check against breach databases at the time of password change.
When a brute force campaign hits that environment, alerts fire within minutes, analysts can immediately determine scope and success status, rate limiting automatically degrades the attack's efficiency, and the indicators feed into updated detection logic before the next wave arrives.
That sequence doesn't happen by accident. It requires deliberate configuration, tested runbooks, and detection logic that has been validated against real attack patterns rather than theoretical threat models. The campaigns running right now — against Instagram accounts, against ransomware victim organizations, against VPN gateways — are sophisticated enough that partial implementation leaves meaningful gaps.
Build the full stack. Validate it against the attacks that are actually happening. Adjust based on what the telemetry tells you, not what the vendor documentation says it should tell you.
