Logon by the built-in Administrator or Guest account

Siemphony@siemphonymediumT1078.001unverified

AN1283 asks for the built-in default accounts — the technique's own text names Administrator and Guest specifically — performing "interactive or remote logons." This rule matches EventID 4624 (a completed logon), restricted to LogonType 2 (interactive), 3 (network — the ADMIN$/C$ and named-pipe path most PsExec-style tooling and remote admin actually takes) or 10 (RemoteInteractive, RDP), or EventID 4648 (a logon attempted with explicitly supplied credentials, the shape a runas, a mapped drive or a scheduled task under an alternate account takes), in both cases where TargetUserName is one of those two names. The LogonType filter applies only to the 4624 branch: 4648 has no LogonType field on the raw event at all — it records that alternate credentials were supplied, not what kind of session they were then used to open — so an earlier draft of this rule ANDed LogonType across both event IDs and silently killed the entire 4648 branch, the same trap this corpus's T1021 rule sidesteps by filtering 4648 on ProcessName instead. Batch and service logons (4, 5) are excluded from the 4624 branch on purpose: a scheduled task or a Windows service legitimately running as a local account is a configuration choice, not the "someone logged into this box as Guest" behaviour the analytic describes. MITRE's own knob concedes the largest hole in this rule before it is even deployed: "Default usernames like 'Administrator' or 'Guest' may be renamed or disabled by the organization. Detection logic should account for name changes" — a literal TargetUserName match cannot account for a rename, because at that point the account's SID is the only thing still tying it to its default-account identity, and 4624/4648 do not carry the well-known SID suffix (-500 for the built-in Administrator, -501 for Guest) in a field this pipeline can bind to; TargetSid is present on the raw event but is rendered as a full SID string with the RID at the end, which needs an endswith rather than an equality match and is not attempted here since no rule in this corpus has established that field. An estate that renames its defaults per Microsoft's own guidance is therefore invisible to this rule entirely, and a quiet result there means the mitigation worked, not that the technique failed to fire. The TimeWindow knob — restricting matches to outside installation or maintenance windows — needs a schedule baseline lib/sigma has no construct for, so every match here carries equal weight regardless of when it happened. The Linux leg, AN1284, is not attempted in this file: lib/sigma renders one logsource per rule, and 4624/4648 is the better-established of the two vocabularies in this corpus. For the record, AN1284's {product: linux, service: auditd} USER_LOGIN source is real but its SSHMethod knob — password versus key-based authentication — is not a field raw auditd's USER_LOGIN record carries; that distinction lives in a separate USER_AUTH record keyed to the PAM module that ran, which this pipeline has not established a vocabulary for. Prerequisite: 4624 and 4648 are both written by the Logon/Logoff audit category, on by default and in both the Microsoft and CIS baselines, but a host whose audit policy was rewritten can still be blind — confirm with auditpol rather than assuming. UNVERIFIED — derived from MITRE ATT&CK DET0465 and never executed against logs.Full description

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

Sentinel · KQL

Run this as a search.

SecurityEvent| where (((EventID == 4624 and (LogonType == 2 or LogonType == 3 or LogonType == 10)) or EventID == 4648) and (TargetUserName =~ "Administrator" or TargetUserName =~ "Guest"))

Splunk · SPL

Run this as a search.

index=* (((EventID="4624" AND (LogonType="2" OR LogonType="3" OR LogonType="10")) OR EventID="4648") AND (TargetUserName="Administrator" OR TargetUserName="Guest"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((event.code == 4624 AND (LogonType == 2 OR LogonType == 3 OR LogonType == 10)) OR event.code == 4648) AND (TO_LOWER(TargetUserName) == "administrator" OR TO_LOWER(TargetUserName) == "guest"))

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. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <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)^4624$</field>    <field name="LogonType" type="pcre2">(?i)(^2$|^3$|^10$)</field>    <field name="TargetUserName" type="pcre2">(?i)(^Administrator$|^Guest$)</field>    <description>Logon by the built-in Administrator or Guest account (1/2)</description>    <mitre>      <id>T1078.001</id>    </mitre>  </rule>   <rule id="100001" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4648$</field>    <field name="TargetUserName" type="pcre2">(?i)(^Administrator$|^Guest$)</field>    <description>Logon by the built-in Administrator or Guest account (2/2)</description>    <mitre>      <id>T1078.001</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: default_account_use
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 3 Sept 2026
Rule ID: 24807dd6-6b60-43dd-90c1-67b7b4199c24

ATT&CKT1078.001

T1078.001Default Accounts

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessondefault account use

default account useAI draft — unreviewed

01 · What this rule detects

A logon by the built-in Administrator or Guest account, matched two ways: EventID 4624 (a completed logon) restricted to LogonType 2 (interactive), 3 (network — the ADMIN$/C$ and named-pipe path most PsExec-style tooling takes), or 10 (RemoteInteractive/RDP); or EventID 4648 (a logon attempted with explicitly supplied credentials, the shape a runas, mapped drive, or scheduled task under an alternate account takes). AN1283 asks for these two default accounts performing interactive or remote logons — this rule matches the completed and the attempted forms of that.

02 · Telemetry you need

windows/security, EventID 4624 and 4648. Both are written by the Logon/Logoff audit category, on by default and present in both the Microsoft and CIS baselines — but a host whose audit policy has been rewritten can still be blind, so confirm with auditpol rather than assuming.

03 · How the logic works

condition: (selection_4624_typed or selection_4648_explicit) and selection_default_account. The two logon-event selectors are ORed, then both are ANDed against TargetUserName in ['Administrator', 'Guest']. selection_4624_typed filters EventID: 4624 to LogonType: [2, 3, 10]; selection_4648_explicit filters EventID: 4648 alone, with no LogonType constraint. Batch and service logons (4, 5) are excluded from the 4624 branch on purpose — a scheduled task legitimately running as a local account is a configuration choice, not the behaviour AN1283 describes. That LogonType split exists because the rule was caught and fixed during review. As first authored, one LogonType selector was ANDed across both event IDs — but Security 4648 carries no LogonType field at all; it records that alternate credentials were supplied, not what kind of session they opened. Every 4648 record would have failed that filter, silently killing the entire 4648 branch of the rule while it still parsed and rendered clean in all four backends. The fix splits the two event IDs into separate selectors, the same pattern this corpus's T1021 rule already uses for 4648 (filtering on ProcessName instead of LogonType). MITRE's own knob concedes the rule's biggest remaining hole before deployment: "Default usernames like 'Administrator' or 'Guest' may be renamed... Detection logic should account for name changes." A literal TargetUserName match cannot — the well-known SID suffix (-500 for Administrator, -501 for Guest) is the only thing tying a renamed account back to its default identity, and while TargetSid is present on both events, matching it needs an endswith against a full SID string that no rule in this corpus has yet established. An estate that renames its defaults is invisible to this rule; a quiet result there means the mitigation worked, not that the account was never targeted.

04 · Common false positives

The rule's own list names the loudest source: legacy or third-party remote tooling authenticating as local Administrator over LogonType 3 to reach ADMIN$/C$ — older PsExec-style deployment tools, some vulnerability scanners, unmigrated backup or imaging agents — which is why level is medium rather than high. Also expected: break-glass use of local Administrator during a domain-controller outage; freshly imaged, not-yet-domain-joined servers where local Administrator is the only account that exists; and kiosk or lab systems where Guest is deliberately left enabled.

05 · Detection maturity

tier_1: . UNVERIFIED — derived from DET0465 and never run against real 4624/4648 output. The LogonType fix was caught by review, not by execution, which is the entire limit of static review: it confirms the rule can fire, not that it fires correctly against real traffic.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Exclude known deployment-tool source hosts and process names from the 4624 branch. Suppress the provisioning window MITRE's own TimeWindow knob is aimed at — new, not-yet-joined hosts — since this corpus has no schedule construct to express it directly. If the estate renames its defaults, this rule needs a TargetSid|endswith leg before it covers anything at all.

Declared by the author

Legacy or third-party remote-administration tooling that authenticates as the built-in local Administrator over LogonType 3 to reach ADMIN$ or C$ — older PsExec-style deployment tools, some vulnerability scanners, and backup or imaging agents that were never migrated to a dedicated service account. On an estate still running any of these this is the loudest source here, which is why the level is medium rather than high.
Break-glass use of the built-in local Administrator account during a domain-controller or authentication outage, when it is the only account guaranteed to still work — a rare but entirely legitimate and expected trigger of this rule.
Freshly imaged or newly provisioned, not-yet-domain-joined servers where the local Administrator account is the only one that exists until provisioning finishes and named admin accounts are granted access — MITRE's own TimeWindow knob is aimed at exactly this window.
Kiosk, lab or legacy line-of-business systems where the Guest account has been deliberately left enabled for compatibility, producing routine interactive or network logons that are sanctioned rather than adversarial.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1078.001, evaluated against their — events.

Share this rule

/u/siemphony/24807dd6-6b60-43dd-90c1-67b7b4199c24

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Logon by the built-in Administrator or Guest account

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it