Detect failed remote logons against commonly guessed accounts
Matches a single Security EventID 4625 failure whose target is one of the default or generic account names a password-guessing tool tries first, where the attempt arrived over the network rather than at the console and failed because the password was wrong or the account does not exist. AN1521 defines the behaviour as a *series* of failures over a TimeWindow with a SourceIPThreshold, and Sigma as this corpus constrains it models neither a count nor a window nor a join to the later success — which is why the parent T1110 is declined here outright. What one event can still carry is MITRE's `UsernamePattern` knob, populated below with generic and default account names rather than with anything MITRE supplied, so the rule sees one guess and leaves the burst to be recognised by whoever reads the alerts. Two clauses do the narrowing. `LogonType` is limited to 3 (network, so SMB and WinRM), 8 (network cleartext, so basic-auth web management) and 10 (RemoteInteractive, so RDP), which drops the console mistype that produces most benign 4625s. `SubStatus` is limited to 0xC000006A (bad password) and 0xC0000064 (no such user), which drops failures caused by lockout, a disabled or expired account and logon-hour restrictions — administrative outcomes, not guesses. If a collector normalises 4625 without preserving `SubStatus`, that clause must be removed or the rule matches nothing. The match is exact on `TargetUserName`, not a substring, so `admin1`, `administrator2` and localised names such as `administrateur` fall outside it; widening the list is the intended tuning direction. 4625 is written by the machine that performed the authentication, so guessing against a *domain* account is recorded on the domain controller as 4771/4768/4776 instead and is invisible here — this rule covers local accounts and the member-server and workstation leg only. It is written in the Security channel vocabulary (`EventID`, `LogonType`, `SubStatus`, `TargetUserName`) and none of those fields carry over to a Sysmon category. Unlike 4688, the audit subcategory behind 4625 (*Audit Logon*, Failure) is enabled in the default configuration and in the Microsoft and CIS baselines, so no extra policy is needed. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0551, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full descriptionShow less
The detection
The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.
detection.yml
title: Detect failed remote logons against commonly guessed accountsid: 96b89932-c9a8-4ec0-b741-5a9f25b00b09status: experimentaldescription: | Matches a single Security EventID 4625 failure whose target is one of the default or generic account names a password-guessing tool tries first, where the attempt arrived over the network rather than at the console and failed because the password was wrong or the account does not exist. AN1521 defines the behaviour as a *series* of failures over a TimeWindow with a SourceIPThreshold, and Sigma as this corpus constrains it models neither a count nor a window nor a join to the later success — which is why the parent T1110 is declined here outright. What one event can still carry is MITRE's `UsernamePattern` knob, populated below with generic and default account names rather than with anything MITRE supplied, so the rule sees one guess and leaves the burst to be recognised by whoever reads the alerts. Two clauses do the narrowing. `LogonType` is limited to 3 (network, so SMB and WinRM), 8 (network cleartext, so basic-auth web management) and 10 (RemoteInteractive, so RDP), which drops the console mistype that produces most benign 4625s. `SubStatus` is limited to 0xC000006A (bad password) and 0xC0000064 (no such user), which drops failures caused by lockout, a disabled or expired account and logon-hour restrictions — administrative outcomes, not guesses. If a collector normalises 4625 without preserving `SubStatus`, that clause must be removed or the rule matches nothing. The match is exact on `TargetUserName`, not a substring, so `admin1`, `administrator2` and localised names such as `administrateur` fall outside it; widening the list is the intended tuning direction. 4625 is written by the machine that performed the authentication, so guessing against a *domain* account is recorded on the domain controller as 4771/4768/4776 instead and is invisible here — this rule covers local accounts and the member-server and workstation leg only. It is written in the Security channel vocabulary (`EventID`, `LogonType`, `SubStatus`, `TargetUserName`) and none of those fields carry over to a Sysmon category. Unlike 4688, the audit subcategory behind 4625 (*Audit Logon*, Failure) is enabled in the default configuration and in the Microsoft and CIS baselines, so no extra policy is needed. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0551, not hand-written and not tested by its author. Any lab result is on this rule's own page.references: - https://attack.mitre.org/techniques/T1110/001 - https://attack.mitre.org/detectionstrategies/DET0551author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)date: 2026-08-16tags: - attack.credential-access - attack.t1110.001logsource: product: windows service: securitydetection: selection: EventID: 4625 LogonType: - 3 - 8 - 10 SubStatus: - '0xC000006A' - '0xC0000064' TargetUserName: - 'administrator' - 'admin' - 'guest' - 'root' - 'sa' - 'sysadmin' - 'oracle' - 'postgres' - 'ftp' - 'test' - 'user' - 'backup' - 'support' - 'demo' condition: selectionfalsepositives: - "A service, scheduled task or mapped drive still holding an old password for a local account named administrator, backup or support. It retries on a timer from one fixed internal address and is the densest recurring source of matches this rule will ever produce, so a source-address allowlist is the first tuning step rather than an optional one." - "Authenticated vulnerability scanners and asset-inventory tools sweeping the estate with a credential set that is wrong or expired on a subset of hosts, which produces a burst of LogonType 3 failures against administrator from the scanner's address on every scan schedule." - "A help desk engineer mistyping the local administrator password over RDP or WinRM, which writes exactly this event with LogonType 10 or 3 and is indistinguishable from a guess at the single-event level." - "Estates that genuinely operate accounts called test, user, backup, support or demo, where every ordinary forgotten password for those users matches. Trim the name list to names that do not exist in your directory before deploying it." - "Legacy line-of-business applications authenticating over LogonType 8 with a hard-coded generic account name that was missed in a password rotation, which then fails on every request until someone notices."level: mediumSentinel · KQL
Run this as a search.
SecurityEvent| where (EventID == 4625 and (LogonType == 3 or LogonType == 8 or LogonType == 10) and (SubStatus =~ "0xC000006A" or SubStatus =~ "0xC0000064") and (TargetUserName =~ "administrator" or TargetUserName =~ "admin" or TargetUserName =~ "guest" or TargetUserName =~ "root" or TargetUserName =~ "sa" or TargetUserName =~ "sysadmin" or TargetUserName =~ "oracle" or TargetUserName =~ "postgres" or TargetUserName =~ "ftp" or TargetUserName =~ "test" or TargetUserName =~ "user" or TargetUserName =~ "backup" or TargetUserName =~ "support" or TargetUserName =~ "demo"))
Splunk · SPL
Run this as a search.
index=* (EventID="4625" AND (LogonType="3" OR LogonType="8" OR LogonType="10") AND (SubStatus="0xC000006A" OR SubStatus="0xC0000064") AND (TargetUserName="administrator" OR TargetUserName="admin" OR TargetUserName="guest" OR TargetUserName="root" OR TargetUserName="sa" OR TargetUserName="sysadmin" OR TargetUserName="oracle" OR TargetUserName="postgres" OR TargetUserName="ftp" OR TargetUserName="test" OR TargetUserName="user" OR TargetUserName="backup" OR TargetUserName="support" OR TargetUserName="demo"))Elastic · ES|QL
Run this as a search.
FROM logs-*| WHERE (event.code == 4625 AND (winlog.event_data.LogonType == "3" OR winlog.event_data.LogonType == "8" OR winlog.event_data.LogonType == "10") AND (TO_LOWER(winlog.event_data.SubStatus) == "0xc000006a" OR TO_LOWER(winlog.event_data.SubStatus) == "0xc0000064") AND (TO_LOWER(winlog.event_data.TargetUserName) == "administrator" OR TO_LOWER(winlog.event_data.TargetUserName) == "admin" OR TO_LOWER(winlog.event_data.TargetUserName) == "guest" OR TO_LOWER(winlog.event_data.TargetUserName) == "root" OR TO_LOWER(winlog.event_data.TargetUserName) == "sa" OR TO_LOWER(winlog.event_data.TargetUserName) == "sysadmin" OR TO_LOWER(winlog.event_data.TargetUserName) == "oracle" OR TO_LOWER(winlog.event_data.TargetUserName) == "postgres" OR TO_LOWER(winlog.event_data.TargetUserName) == "ftp" OR TO_LOWER(winlog.event_data.TargetUserName) == "test" OR TO_LOWER(winlog.event_data.TargetUserName) == "user" OR TO_LOWER(winlog.event_data.TargetUserName) == "backup" OR TO_LOWER(winlog.event_data.TargetUserName) == "support" OR TO_LOWER(winlog.event_data.TargetUserName) == "demo"))
Wazuh · XML rule
Deploy to your manager — this is a rule, not a search.
<group name="sigma,windows,"> <!-- Rule ids must be unique on your manager; 100000+ is the user range. --> <rule id="100000" level="7"> <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. --> <field name="EventID" type="pcre2">(?i)^4625$</field> <field name="LogonType" type="pcre2">(?i)(^3$|^8$|^10$)</field> <field name="SubStatus" type="pcre2">(?i)(^0xC000006A$|^0xC0000064$)</field> <field name="TargetUserName" type="pcre2">(?i)(^administrator$|^admin$|^guest$|^root$|^sa$|^sysadmin$|^oracle$|^postgres$|^ftp$|^test$|^user$|^backup$|^support$|^demo$)</field> <description>Detect failed remote logons against commonly guessed accounts</description> <mitre> <id>T1110.001</id> </mitre> </rule></group>
Verdicts · reactions · comments
Community
Verdicts from engineers who actually deployed it, and the conversation around it.
Nobody has run this in a real environment and said what happened.
Verdicts from engineers who deployed it
0 castNo verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.
Log in to report a verdict.
Log in to join the discussion.
No comments yet. Someone who deploys this will have something to say about it.