User account created from a SYSTEM or machine account context

Siemphony@siemphonymediumT1136unverified

AN1604 asks for Security EventID 4720 paired with process lineage and user context. The lineage half needs a join this corpus cannot express, so this rule keeps the account-creation event and applies the analytic's UserContext knob instead, populated here with the one context that is almost never a person: a Subject account name ending in a dollar sign, which is how a computer account and the LOCAL SYSTEM token are rendered in the Subject fields of a 4720. An operator creating an account from a management console appears as a named user; malware, a service, or a scheduled task running as SYSTEM appears as HOST$. This deliberately sits at the parent technique rather than under a child, because 4720 is emitted for a local SAM account on a member host and for a domain account on a domain controller with the same event ID and the same fields — the record itself does not say which, so it cannot be attributed to T1136.001 or T1136.002 without knowing the role of the machine that logged it. Two caveats before deploying. 4720 comes from the Audit User Account Management subcategory (Success); it is present in the shipped defaults and in the Microsoft and CIS baselines, unlike 4688's command line, but a host whose audit policy has been rewritten can still be blind, so confirm with auditpol rather than assuming. More important, the SubjectUserName clause is the whole of this rule's selectivity and it depends on how the collector renders the SYSTEM token: check one known-good 4720 from a SYSTEM-run installer and confirm the field carries the machine account rather than the literal string SYSTEM, or this rule returns zero rows and the silence will read as an absence of account creation. An operator who wants the raw audit trail instead should drop that clause and accept every account creation in the environment. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0583, not hand-written and not tested by its author. Any lab result is on this rule's own page.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 == 4720 and SubjectUserName endswith "$")

Splunk · SPL

Run this as a search.

index=* (EventID="4720" AND SubjectUserName="*$")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (event.code == 4720 AND TO_LOWER(user.name) LIKE "*$")

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)^4720$</field>    <field name="SubjectUserName" type="pcre2">(?i)\$$</field>    <description>User account created from a SYSTEM or machine account context</description>    <mitre>      <id>T1136</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: account_manipulation
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 089a3b9b-3dc5-430c-aea4-7ea97e0f2550

ATT&CKT1136

T1136Create Account

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.

Lessonaccount manipulation

account manipulationAI draft — unreviewed

01 · What this rule detects

Creating an account is the cheapest durable persistence there is, and Windows logs every one of them as Security EventID 4720. This rule, authored from MITRE's DET0583 / AN1604, keeps that event but narrows it to creations made from a SYSTEM or machine-account context — the slice where no human was at the console. It has never been executed against a log line and is a scaffold only.

02 · Telemetry you need

product: windows, service: security. 4720 comes from the Audit User Account Management subcategory (Success), which is present in the shipped defaults and in the Microsoft and CIS baselines, so unlike 4688's command line it is usually on — confirm with auditpol rather than assuming, since a rewritten policy can still blind a host. The collection scope matters as much as the policy: 4720 for a local SAM account is written only to the Security log of the host that created it. Forward Security logs from domain controllers alone and you see domain account creation only, while three of the four noise sources below are member-host events and the rule reports clean.

03 · How the logic works

A single selection with two predicates: EventID: 4720 and SubjectUserName|endswith: '$'. The Subject fields name the actor, and a computer account — and the LOCAL SYSTEM token as most collectors render it — ends in a dollar sign, so the clause keeps HOST$ and drops named users. That is the whole of the rule's selectivity, and it depends entirely on how your collector renders the SYSTEM token: pull one known-good 4720 from a SYSTEM-run installer and confirm the field carries the machine account rather than the literal string SYSTEM. Watch the translated forms too — the Elastic rendering collapses SubjectUserName onto ECS user.name, and in several pipelines user.name carries the created account, which turns the test into a question that is essentially never true.

04 · Common false positives

Everything the clause keeps is, by construction, automation. Imaging and provisioning are the real volume: sysprep, MDT and Autopilot create the initial local administrator and the autologon account from SYSTEM on every machine built, in bursts when a build wave runs. Identity provisioning connectors running as LOCAL SYSTEM create domain users in bulk on a nightly schedule. Cluster, backup and hypervisor products recreate service accounts during patching and node repair. Installers appear in the rule's false-positive list as the loudest entry, but that claim is weak — modern installers mostly use virtual (NT SERVICE\<name>) or managed service accounts, neither of which emits 4720 at all.

05 · Detection maturity

tier_1: Lowest tier. No match has ever been counted, no false positive dismissed, and the medium level rests on a volume claim about installers that is probably wrong. Verify the SYSTEM token rendering, forward member-host logs, baseline a build wave, then decide the level from what you measured.

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

MITRE names three knobs on AN1604: TimeWindow, ParentProcessName and UserContext. The first two need a join with process creation that this dialect cannot express, so the rule uses UserContext alone — and the dollar-sign test is the pipeline's chosen value for that knob, not MITRE's. Tune it by excluding the specific machine accounts of your build and provisioning infrastructure rather than by broadening the clause. Understand what you are giving up: the analytic explicitly names net user, PowerShell and MMC snap-ins, all of which log a named subject and are excluded here. An adversary inside a compromised admin session is invisible to this rule. It is a supplement to an unfiltered account-creation baseline, never a replacement, and the attack.t1136 parent tag promises more coverage than the logic delivers.

Declared by the author

Software installation that creates a local service account. MSI custom actions, SQL Server, database and monitoring agents, and anything deployed through SCCM, Intune or an RMM tool run as SYSTEM, so the local account they create is logged with the machine account as subject. During a deployment window this is the loudest source here and the reason the level is medium rather than high.
Operating-system imaging and unattended setup. Sysprep, MDT and Autopilot task sequences create the initial local administrator and the temporary autologon account from a SYSTEM context, so every machine built produces at least one match on its first boot, in a burst whenever a build wave runs.
Identity provisioning connectors on domain controllers. Joiner automation, HR-driven provisioning and directory synchronisation connectors that run as LOCAL SYSTEM or under a machine account create domain users in bulk on a nightly schedule, which can produce dozens of matches within a few minutes on a single DC.
Cluster, backup and virtualisation products that manage their own accounts. Failover clustering, backup agents and hypervisor tools create and recreate service accounts as SYSTEM during setup, patching and node repair, so routine maintenance on those roles matches without any human account involved.

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 T1136, evaluated against their — events.

Share this rule

/u/siemphony/089a3b9b-3dc5-430c-aea4-7ea97e0f2550

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.

User account created from a SYSTEM or machine account context

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it