federal-homelab

Local Account Creation

Field	Value
ATT&CK technique	T1136.001 — Create Account: Local Account
Tactic	Persistence
Log source	Windows Security event log, member hosts (WS01)
Index	`lab_win`
Severity	Medium
Status	Validated — 2026-09-24
Author	Samuel Emerson
Created	2026-09-22
Validated	2026-09-24 — evidence

Hypothesis

An adversary who has gained execution on a workstation frequently creates a local account to survive credential resets and to hold access independent of the compromised user. Windows records local account creation as Security event 4720 on the machine where it happened. In a managed environment, accounts are provisioned in the domain, not in a workstation’s local SAM — a 4720 on a member host is either a technician working outside process or an adversary, and both are worth a look.

The follow-on action, adding that account to a privileged local group, generates 4732. Correlating the two in a short window separates routine account creation from privilege establishment.

A 4720 on DC01 records a domain account, which is T1136.002 and out of scope for this detection.

Detection logic

Written against XML-rendered Security events (renderXml = true, source XmlWinEventLog:Security), whose field names are the EventData names in the table below. Field names are confirmed against indexed data before validation.

index=lab_win source="XmlWinEventLog:Security" EventCode=4720 host!="DC01"
| rename TargetUserName as new_account, TargetSid as new_account_sid, SubjectUserName as created_by
| search NOT created_by IN ("*$", "SYSTEM")
| table _time, host, new_account, new_account_sid, created_by, SubjectDomainName
| sort - _time

Correlated version — creation followed by membership in a privileged local group within 10 minutes. The two events share no account name: in 4732, TargetUserName is the group, and the account added appears only as MemberSid. The join is therefore on SID, 4720 TargetSid to 4732 MemberSid.

net user /add also places every new account in the local Users group, which raises its own 4732. Restricting the 4732 side to privileged built-in groups by well-known SID keeps that from matching.

index=lab_win source="XmlWinEventLog:Security" host!="DC01"
    (EventCode=4720 OR (EventCode=4732 TargetSid IN ("S-1-5-32-544", "S-1-5-32-551", "S-1-5-32-555", "S-1-5-32-580")))
| eval account_sid = if(EventCode=4720, TargetSid, MemberSid)
| eval created   = if(EventCode=4720, _time, null()),
       added      = if(EventCode=4732, _time, null()),
       new_account = if(EventCode=4720, TargetUserName, null()),
       group      = if(EventCode=4732, TargetUserName, null())
| stats min(created) as created, min(added) as added, values(new_account) as new_account,
        values(group) as group, values(SubjectUserName) as actor, values(host) as host by account_sid
| where isnotnull(created) AND isnotnull(added) AND added >= created AND added - created <= 600
| eval seconds_to_privilege = added - created
| convert ctime(created) ctime(added)
| table host, new_account, account_sid, group, actor, created, added, seconds_to_privilege

SID	Group
`S-1-5-32-544`	Administrators
`S-1-5-32-551`	Backup Operators
`S-1-5-32-555`	Remote Desktop Users
`S-1-5-32-580`	Remote Management Users

Field reference

Field	Source	Meaning
`EventCode=4720`	Security log	A user account was created
`EventCode=4732`	Security log	A member was added to a security-enabled local group
`TargetUserName`	4720	The account that was created
`TargetSid`	4720	SID of the account that was created
`SubjectUserName`	4720, 4732	The account that performed the action
`SubjectDomainName`	4720	Domain or local machine context of the creator
`TargetUserName`	4732	The group the member was added to — not the account
`TargetSid`	4732	SID of the group
`MemberSid`	4732	SID of the account added. `MemberName` is typically `-` for local accounts

Validation

Tests are selected by GUID, not number. Test numbers are positional and shift as tests are added upstream; test 1 in this technique is the Linux useradd test. Atomics are pinned to a commit, recorded here at execution.

Item	Detail
Atomics	Atomic Red Team `master`, downloaded 2026-09-24; commit not recorded
Test — bare creation	#4 Create a new user in a command prompt · `6657864e-0323-4206-9344-ac9cd7265a4f`
Test — correlated	#8 Create a new Windows admin user · `fda74566-a604-4581-a4cc-fbbe21d66559`
Password input	Both test defaults fail WS01’s password policy, so each run passes a generated 14-character value instead. Longer values stall `net user` at an interactive prompt
Executed at	2026-09-24 14:15:44–14:15:45 CDT (execution log)
Events produced	#4: 4720. #8: 4720, then 4732 with `TargetSid` `S-1-5-32-544`
Detection fired	Yes — scheduled run at 14:20:01, 2 results (alert log)
Time to detect	4 min 17 s (first 4720 at 14:15:45.058 to alert run)
Evidence	4720/4732 events · screenshot · alert screenshot
Correlation	The Administrators 4732 (`S-1-5-32-544`) carries `MemberSid` …-1005, the `TargetSid` of `T1136.001_Admin`’s 4720 — the SID join in the correlated search holds. Both accounts also produced a Users-group 4732, which that search excludes
Blocked attempts	The first runs, with the default passwords, were rejected by the password policy — yet each still wrote a 4720, followed milliseconds later by a 4726 (account deleted). The alert fired on them at 13:50:01. A policy-blocked creation is visible to this detection
Cleanup	`-Cleanup` with the same GUIDs; both accounts removed (4726 at 14:31:56–57) and `net user` back to its original five accounts

$pw = 'Ar1' + [guid]::NewGuid().ToString('N').Substring(0,11)   # exactly 14 chars: upper, lower, digit; throwaway
foreach ($g in '6657864e-0323-4206-9344-ac9cd7265a4f', 'fda74566-a604-4581-a4cc-fbbe21d66559') {
    Invoke-AtomicTest T1136.001 -TestGuids $g -InputArgs @{ password = $pw } `
        -ExecutionLogPath .\T1136.001-execution.csv
}
# after results are exported:
foreach ($g in '6657864e-0323-4206-9344-ac9cd7265a4f', 'fda74566-a604-4581-a4cc-fbbe21d66559') {
    Invoke-AtomicTest T1136.001 -TestGuids $g -Cleanup
}

False positives

Scenario	Likelihood	Tuning
Helpdesk creating a local admin during a break-fix	Medium in production, low in this lab	Allowlist known technician accounts; alert on the correlation rather than bare 4720
Software installers creating service accounts	Medium	Allowlist specific account name patterns after observing a baseline
Your own lab setup work	High	Filter your build window by time, or baseline after the lab is built

Response guidance

Identify the creating account and whether it should have that capability at all.
Check for a preceding 4688 or Sysmon EID 1 showing net user or New-LocalUser, and look at the parent process.
Determine whether 4732 followed — group membership turns this from suspicious into urgent.
Check whether the new account has logged on (4624) and from where.
If unexplained: disable the account, preserve the host, and pivot to the originating process tree.

Gaps

Domain account creation (T1136.002) is out of scope: it produces 4720 on DC01, not on the member host, and needs its own detection with DC01 forwarding.
The correlated search covers four privileged built-in groups by SID. Membership in a custom or domain group that carries local admin rights through Group Policy is not matched.
An adversary using an existing dormant account creates no 4720 at all. Pair this with a dormant-account-reactivation detection for real coverage.
Local account creation with auditing disabled generates nothing — which is why the STIG audit-policy settings and a detection for 1102 (log cleared) matter alongside this.

NIST 800-53 mapping

Control	Relevance
AC-2	Account management — detecting accounts created outside the approved process
AU-6	Audit record review, analysis, and reporting
SI-4	System monitoring — detecting indicators of unauthorized activity