How to detect brute force attacks

Threat snapshot

Brute force attacks are among the most consistently successful initial access techniques in enterprise environments, not because they are sophisticated, but because they are patient. A modern password spraying campaign against a 10,000-user organization might attempt one login per account per hour, staying comfortably below lockout thresholds while systematically testing the most common passwords in use. The failure to detect this is rarely a technology problem. The data is there in the authentication logs. What is missing is the detection logic to recognize the pattern.

The challenge is that brute force looks different depending on where it is happening. Against on-premises Active Directory it appears as clustered Event 4625 failures from a single source IP. Against Microsoft 365 it appears as distributed authentication failures from multiple IPs targeting the same accounts. Against VPN gateways it generates its own vendor-specific failure codes. Against SQL Server it shows up in database audit logs. Each surface has its own signal, and an attacker who understands this deliberately spreads attempts across surfaces to stay below per-source thresholds.

This page covers the full range of brute force variants, maps each to the specific detection rules Log360 uses to catch them, and provides the investigation workflow for converting a failed logon pattern into a confirmed attack.

Brute force attacks, at a glance

How brute force attacks work

The term "brute force" covers a family of credential attacks that share the same goal but differ significantly in their approach, the log signals they generate, and the threshold-based detection logic required to catch them.

Classic brute force (T1110.001)

The attacker targets a specific account and cycles through a list of passwords as fast as the target system allows. Against Active Directory this is easy to detect because the burst of Event 4625 failures against a single account from a single source IP is unmistakable, and account lockout kicks in quickly. The more dangerous variants slow the attempt rate to one try every few minutes, staying below the lockout observation window. Against web applications and VPN gateways, lockout policies are often absent entirely, allowing unlimited attempts.

Log signals: Windows Security Event 4625 (failed logon, SubStatus 0xC000006A for wrong password), Event 4740 (account lockout), vendor-specific VPN authentication failure logs (SonicWall, Fortinet, Cisco).

Password spraying (T1110.003)

The attacker inverts the classic approach: instead of many passwords against one account, they try one or two common passwords against every account in the directory. Because each account receives only one or two failed attempts, no individual account ever reaches the lockout threshold. The attack is slow by design, often operating at one attempt per account per hour across a full working day. It is particularly effective against organizations that have not enforced strong password policies, where passwords like "Winter2024!" or "Company@123" remain in active use across large user populations.

Against Kerberos environments, Kerbrute performs AS-REQ pre-authentication spraying without generating Event 4625 at all, instead producing Event 4768 with result code 0x18. This is a deliberate OPSEC choice to avoid triggering standard brute force detection.

Log signals: Event 4625 distributed across many accounts from the same source IP in a consistent time pattern, Event 4768 with KrbError 0x18 (Kerbrute), M365 sign-in failure logs showing low-volume failures across many UPNs.

Credential stuffing (T1110.004)

Unlike brute force or spraying, credential stuffing uses real username/password pairs harvested from prior data breaches and replayed against new targets. The success rate is much higher because a significant percentage of users reuse passwords across services. The attack is typically automated at scale using tools like Hydra, and the authentication attempts often originate from residential proxy networks or rotating cloud IPs, making source IP blocking ineffective. Detection depends on recognizing the pattern of valid-format credentials producing authentication failures at a rate inconsistent with legitimate user behavior.

Log signals: Authentication failures where the username format is valid (matching real accounts) but the password is wrong, geographically diverse source IPs, high volume in a compressed time window, Fortinet and other perimeter device credential stuffing signatures.

Offline password cracking (T1110.002)

Once an attacker has extracted password hashes (from LSASS, the SAM registry hive, NTDS.DIT, or a captured network challenge), they crack them offline using tools like Hashcat or John the Ripper. This generates no authentication log events on the target system, so the only detection opportunity is catching the hash extraction itself or detecting the cracking tool execution. Hashcat and Hydra have distinctive process creation signatures that Log360's detection rules identify from Sysmon event logs.

Log signals: Sysmon Event 1 (process creation) with Hashcat, John, or Hydra binary signatures or command-line patterns. Combined with prior LSASS access events, this constitutes a credential theft chain.

Real-world campaigns and CVEs

Brute force remains a top initial access vector across every major threat intelligence report. The following campaigns illustrate how each variant is used in practice by real threat actors.

APT28 (Fancy Bear): Large-scale password spraying against government and defense targets

APT28, the Russian GRU-affiliated threat group, has conducted sustained password spraying campaigns against government agencies, defense contractors, and critical infrastructure organizations across NATO member states. The group's approach targets Microsoft 365 and on-premises Exchange environments, using a short list of seasonally updated common passwords sprayed at scale. The key operational characteristic is a deliberate attempt rate of one to two tries per account per day, designed to stay below both lockout thresholds and anomaly detection baselines. Attacks typically originate from Tor exit nodes or compromised residential routers to distribute source IPs.

Scattered Spider: Credential stuffing and MFA fatigue combined

The Scattered Spider group (also tracked as UNC3944) has combined credential stuffing against enterprise VPN portals with real-time social engineering of IT helpdesks. The stuffing component uses credentials from prior consumer data breaches replayed against corporate SSO and VPN gateways. When a valid credential is found but blocked by MFA, the group pivots to calling the helpdesk while impersonating the account owner to reset MFA. Detection of the stuffing phase, before the social engineering escalation, is the earliest available intervention point.

CVE reference table

Business impact

• Initial access at scale: Credential-based attacks account for the initial access vector in the majority of confirmed data breaches. A single successful brute force against an account with broad permissions can provide full network access within minutes, particularly where MFA is absent or inconsistently enforced.
• Long dwell time when undetected: Password spraying campaigns that stay below lockout thresholds can operate undetected for weeks. An account compromised through a spray in week one may not be used for lateral movement or data access until week four, after the attacker has confirmed access and planned their next steps.
• Downstream attack enablement: Brute force is rarely the end goal. It is the mechanism for obtaining credentials that enable everything that follows: domain enumeration, lateral movement, privilege escalation, and data exfiltration. Stopping the brute force attack stops the entire downstream chain.
• Regulatory exposure: Account compromise resulting from a failure to detect brute force activity can constitute a control failure under PCI-DSS Requirement 8.3 (requiring account lockout after a defined number of failed attempts) and HIPAA Section 164.312(d) (requiring person authentication). Demonstrating that detection controls were in place and functioning is a key component of any post-incident regulatory response.

Detecting brute force attacks with Log360

Log360's 20 brute force detection rules span five platforms and all major attack variants. For these rules to fire, the relevant log sources must be forwarding to Log360: Windows Security event logs (Events 4625, 4740, 4768) from domain controllers and member servers, Sysmon process creation logs (Event 1) from endpoints, Microsoft 365 sign-in logs, VPN authentication logs (SonicWall, Fortinet), and SQL Server audit logs. Rules are grouped below by the variant they target.

Classic brute force and account lockout

Password spraying and Kerberos-based attacks

Credential stuffing

Offline cracking tool detection

VPN and remote access brute force

Attack chain visibility

Brute force is rarely isolated. It is the opening move in a sequence that ends in credential compromise and account takeover. The sequences below show the two most operationally significant attack chains and the log signals at each step.

Sequence A: Password spray to account takeover (Active Directory)

Sequence B: Kerbrute spray (Kerberos, no Event 4625)

Investigation playbook

When a brute force detection rule fires in Log360, the first question is always the same: did any attempt succeed? A detected brute force that produced zero successful authentications is a failed attack. A detected brute force followed by a successful logon from the same source is an account compromise in progress. The playbook below structures the investigation from that initial triage through to scope determination and evidence collection.

Step 1: Triage - identify the variant and platform

Step 2: Determine if any attempt succeeded

• Using Log360's log search, query for Event 4624 (successful logon) from the same source IP or targeting the same accounts as the brute force alert, within the same time window and the 24 hours following it. A successful logon from the spray source is the most important finding in the entire investigation.
• For M365 attacks, query the M365 sign-in logs for successful authentications from the source IPs identified in the alert. Pay attention to the authentication method (password vs. MFA vs. token), as a successful password authentication without MFA confirmation is the clearest compromise signal.
• For Kerbrute: check Event 4768 logs on domain controllers for TGT issuances (result code 0x0, indicating success) from the same source IP as the Kerbrute execution, in the hour following the spray.

Step 3: Investigate using the Incident Workbench

• If a successful logon is found, click on the compromised username in the alert or log search results to open the Incident Workbench. Use the User analytics tab to pull a full activity overview for that account: recent logons, resources accessed, and UEBA risk score. A normal user account suddenly authenticating from a new country or accessing sensitive file shares for the first time is a strong confirmation of compromise.
• Use the Process analytics tab if the brute force originated from an internal host (indicating Hashcat, Hydra, or Kerbrute running on a compromised machine). The process tree will show what spawned the cracking tool and what actions followed it.
• Use Advanced Threat Analytics on the source IP to check threat feed risk scores. External IPs used for credential attacks frequently appear in threat intelligence feeds as known attack infrastructure or compromised hosts.
• Save the Incident Workbench session to an incident for tracking, preserving the user activity timeline and process tree as the evidence record.

Step 4: Determine scope

• How many accounts were targeted? List all accounts that received authentication failures from the spray source. This is your full exposure surface, not just the accounts that were locked out.
• How many accounts were successfully compromised? Each successful logon from the spray source in the failure window is a separate compromised account requiring its own investigation and remediation.
• Did the attacker authenticate from the compromised account after gaining access? Check for downstream activity: LDAP queries, file access, Group Policy reads, email access (M365). Each activity type indicates how far post-compromise activity has progressed.
• Are there multiple source IPs? Distributed spraying from many IPs targeting the same accounts indicates a more sophisticated, infrastructure-backed campaign rather than a single-host opportunistic attack.

Step 5: Collect evidence and build the timeline

• Export the Event 4625 and 4624 timeline for all affected accounts from Log360's log search. This is your primary forensic record showing the attack window, the accounts targeted, and the moment of compromise.
• Record all source IPs involved. For external IPs, note the geographic location, ASN (hosting provider vs. residential), and any threat intelligence context from the Incident Workbench Advanced Threat Analytics tab.
• If Hashcat or Hydra were detected, preserve the Sysmon Event 1 log with full command-line arguments, as this shows which hash format was being cracked or which protocol was being attacked.
• Export the investigation timeline from Log360 as the compliance artifact for PCI-DSS Requirement 10.7 (detecting failures of critical security controls) and NIST CSF DE.AE-5 (incident analysis documentation).

Response and remediation

Immediate containment

• Disable compromised accounts immediately. If a successful logon from the brute force source is confirmed, disable the account in Active Directory or suspend it in M365 before any further investigation. An active compromised account can be used for lateral movement while the investigation is still in progress.
• Block the source IP at the perimeter. For external brute force sources, add the IP (and its subnet if it is cloud infrastructure) to the deny list on the perimeter firewall or VPN gateway. For distributed spray campaigns using many IPs, consider rate-limiting authentication attempts by geography if the attack originates from unexpected regions.
• Force password reset for all targeted accounts, not just the ones that produced successful logons. Any account that received spray attempts may have been successfully authenticated using credentials not captured in the local log window, particularly if the spray operated across a longer time period.
• Revoke active sessions for compromised M365 accounts using the Revoke-AzureADUserAllRefreshToken cmdlet or the equivalent M365 admin action. Session tokens remain valid after a password reset unless explicitly revoked.

Response actions by trigger

Hardening

• Enforce MFA on all remote access and cloud authentication. Brute force succeeds when a correct password is sufficient for access. MFA breaks this by requiring a second factor the attacker does not have. For M365, Conditional Access policies enforcing MFA on all authentication except trusted named locations address both spray and stuffing campaigns.
• Implement Smart Lockout for M365 (available in Azure AD) which locks out attacks from unfamiliar locations at lower thresholds while allowing familiar IPs more attempts, reducing false positives from legitimate user mistakes while tightening controls against external attackers.
• Deploy account lockout policy in Active Directory Group Policy (typically 5 to 10 failures over 30 minutes) and set the observation window equal to the lockout duration to prevent rapid retry after unlock.
• Disable NTLM authentication where Kerberos is available to eliminate a class of relay and brute force attacks that depend on NTLM challenge-response capture.

False positive tuning