T1110 Google Chronicle · YARA-L

Detect Brute Force in Google Chronicle

Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password hashes are obtained. Without knowledge of the password for an account or set of accounts, an adversary may systematically guess the password using a repetitive or iterative mechanism. Brute forcing passwords can take place via interaction with a service that will check the validity of those credentials or offline against previously acquired credential data, such as password hashes. Threat actors including Fox Kitten, APT38, APT41, OilRig, and Turla have used brute force techniques against RDP, SSH, SMB, and web services.

MITRE ATT&CK

Tactic
Credential Access
Technique
T1110 Brute Force
Canonical reference
https://attack.mitre.org/techniques/T1110/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule t1110_brute_force_compromise {
  meta:
    author = "df00tech"
    description = "Detects brute force: 10+ failed USER_LOGIN events from same source IP within 10 minutes followed by a successful login, indicating potential account compromise"
    severity = "CRITICAL"
    mitre_tactic = "TA0006 - Credential Access"
    mitre_technique = "T1110"
    platforms = "Windows"
    false_positives = "SSO proxies, load testers, helpdesk resets"
    version = "1.0"

  events:
    $failed.metadata.event_type = "USER_LOGIN"
    $failed.security_result.action = "BLOCK"
    $failed.principal.ip = $source_ip
    $failed.target.hostname = $target_host
    $failed.principal.ip != ""
    $failed.target.hostname != ""

    $success.metadata.event_type = "USER_LOGIN"
    $success.security_result.action = "ALLOW"
    $success.principal.ip = $source_ip
    $success.target.hostname = $target_host
    $success.metadata.event_timestamp.seconds > $failed.metadata.event_timestamp.seconds

  match:
    $source_ip, $target_host over 10m

  condition:
    #failed >= 10 and #success >= 1
}
critical severity high confidence

YARA-L 2.0 rule correlating USER_LOGIN BLOCK events (failed authentications) with a subsequent USER_LOGIN ALLOW event (success) from the same source IP to the same target host within a 10-minute sliding window. The temporal constraint `$success.metadata.event_timestamp.seconds > $failed.metadata.event_timestamp.seconds` ensures success occurs after failures. Triggers at the Critical severity indicating likely compromise.

Data Sources

Google Chronicle UDM USER_LOGIN eventsChronicle ingested Windows Security Event Log (normalized to UDM)

Required Tables

USER_LOGIN UDM events

False Positives & Tuning

  • Corporate VPN concentrators performing NAT that map many remote employees' authentication attempts to a single egress IP, causing per-IP failure counts to exceed the threshold during high-traffic periods such as Monday mornings
  • Automated provisioning systems using Active Directory accounts for machine enrollment that attempt Kerberos pre-authentication multiple times before domain join completes, followed by successful enrollment
  • Security awareness training platforms that simulate brute force as part of phishing simulations, triggering controlled failure sequences from a known training infrastructure IP before a successful test-user login
Download portable Sigma rule (.yml)

Other platforms for T1110


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1RDP Brute Force Simulation with Crowbar

    Expected signal: On the target Windows host: Security Event ID 4625 (LogonType=10, RemoteInteractive) for each failed attempt, with IpAddress showing the attacker IP. If lockout policy is enabled and threshold exceeded: Event ID 4740 (account locked out). Network logs: multiple TCP connections to port 3389 from attacker IP in rapid succession.

  2. Test 2SSH Brute Force with Hydra

    Expected signal: On the target Linux host: /var/log/auth.log entries 'Failed password for root from <attacker-ip> port <port> ssh2'. If using auditd: type=USER_AUTH msg entries with res=failed. Sysmon for Linux (if deployed): Event ID 3 (network connection) on the attacker side. SIEM via Syslog forwarder: linux_secure sourcetype or syslog with 'Failed password' pattern.

  3. Test 3Active Directory Password Spray with PowerShell

    Expected signal: On Domain Controller: Security Event ID 4625 (LogonType=3, Network) for each failed account, SubStatus 0xC000006D (wrong password) or 0xC000006A (wrong password for correct username). Caller IP address will be the workstation running the spray. Security Event ID 4771 (Kerberos pre-auth failure) if using Kerberos authentication. Timing will show evenly spaced failures 500ms apart — distinctive automated tool pattern.

  4. Test 4NTLM Brute Force via SMB with CrackMapExec

    Expected signal: Target Windows host: Security Event ID 4625 (LogonType=3, Network, AuthenticationPackageName=NTLM) for each failed credential. Domain Controller: Security Event ID 4776 (NTLM authentication attempt, error code 0xC000006A for wrong password) with Workstation field showing attacker hostname. Network: multiple TCP connections to port 445 (SMB) from attacker IP. CME results show [*] for failure and [+] for success in its output.

Unlock Pro Content

Get the full detection package for T1110 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections