User account marked hidden in the Windows SpecialAccounts UserList

Siemphony@siemphonymediumT1564.002unverified

AN1001 asks for account creation (Security 4720) correlated with a registry edit that marks the new account hidden, a join Sigma cannot express. This rule matches the registry edit alone: a Sysmon EventID 13 write under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\ UserList where the value name is the account and the DWORD data written is 0, the documented mechanism that removes an account from the Welcome screen and Fast User Switching list. That is a real signal on its own even without the 4720 join, since it also catches an existing account being hidden after the fact, a case the correlated version would miss entirely. Sysmon EventID 14 (registry_rename) is not used -- renaming or deleting a UserList value un-hides an account rather than hiding one, the opposite of this analytic's intent. The Linux and macOS legs in this strategy, AN1002 and AN1003, are not attempted here: AN1002's gsettings/Display-Manager mechanism toggles visibility for the entire greeter user list rather than one account, a coarser match to "hidden user" than the Windows value-per-account write; AN1003's logsource ({product: macos, service: unifiedlog}) has no established Sigma field vocabulary anywhere in this corpus. Sysmon is not installed by default, and shipped Sysmon configurations commonly allowlist which registry subtrees EventID 13 reports on -- SpecialAccounts\UserList must be in that allowlist or this rule returns zero rows, which reads as quiet when it actually means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0353, 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.

DeviceRegistryEvents| where (RegistryKey contains "\\SpecialAccounts\\UserList\\" and RegistryValueData =~ "DWORD (0x00000000)")

Splunk · SPL

Run this as a search.

index=* (TargetObject="*\\SpecialAccounts\\UserList\\*" AND Details="DWORD (0x00000000)")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(registry.path) LIKE "*\\\\specialaccounts\\\\userlist\\\\*" AND TO_LOWER(registry.data.strings) == "dword (0x00000000)")

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,registry_set,">  <!-- 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="TargetObject" type="pcre2">(?i)\\SpecialAccounts\\UserList\\</field>    <field name="Details" type="pcre2">(?i)^DWORD \(0x00000000\)$</field>    <description>User account marked hidden in the Windows SpecialAccounts UserList</description>    <mitre>      <id>T1564.002</id>    </mitre>  </rule></group>

At a glance

Logsource: registry_set / windows
Level: medium
Category: hide_artifacts
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 96a10031-fdaf-4d55-bcf7-fab8b20b65c8

ATT&CKT1564.002

T1564.002Hidden Users

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.

Lessonhide artifacts

hide artifactsAI draft — unreviewed

01 · What this rule detects

A single-account Windows registry write that hides a local user from the Welcome screen and Fast User Switching: a value under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList named for the account, set to DWORD 0. That value-per-account write is the documented mechanism behind AN1001's "hidden users" defender view, and it fires whether the account was just created or already existed and is being hidden after the fact. AN1002's Linux (gsettings/Display-Manager) and AN1003's macOS (dscl/plist) legs of this strategy are not attempted by this rule.

02 · Telemetry you need

Sysmon EventID 13 (registry_set) covering the SpecialAccounts\UserList subtree. Sysmon is not installed by default, and shipped Sysmon configs commonly allowlist which registry paths EventID 13 reports on — if SpecialAccounts\UserList isn't in that allowlist, this rule returns zero rows, which reads as quiet but actually means blind.

03 · How the logic works

A single selection, condition: selection: - TargetObject contains \SpecialAccounts\UserList\ - Details equals DWORD (0x00000000) AN1001 as MITRE describes it asks for account creation (Security 4720) correlated with this registry edit — a join Sigma's construct set cannot express. This rule matches the registry write alone, which is a real signal on its own: it also catches an existing account being hidden retroactively, a case the correlated version would miss. Sysmon EventID 14 (registry_rename) is excluded on purpose — renaming or deleting a UserList value un-hides an account, the opposite of what this analytic is looking for.

04 · Common false positives

Administrators deliberately hiding a support, service, or break-glass account from the Welcome screen for privacy or operational-security reasons — the technique's own MITRE description names this as a legitimate, common admin practice, and it produces the exact same registry write this rule matches.
Remote-support and RMM agents (helpdesk tooling, several endpoint-management suites) that provision a local service account for their own agent and hide it from the logon screen the same way, as a routine part of installation.
Kiosk-mode and shared-device imaging tooling that hides default or built-in local accounts from the Welcome screen as a standard step in a locked-down device profile.

05 · Detection maturity

tier_1: Lowest tier: authored, never executed. Before this rule is trusted beyond a scaffold, confirm Sysmon's EventID 13 allowlist actually reports on SpecialAccounts\UserList in your environment, fire a real hide-account action against it to verify the match, and populate BaselineHiddenUsers from your actual admin and RMM accounts to cut the noise this lesson describes.

Tuning & false positivesexperimental · 3 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's AN1001 names two knobs, neither populated with real values here: AccountScope (restrict monitoring to privileged or otherwise unexpected accounts, rather than firing on any account name) and BaselineHiddenUsers (an allowlist of accounts an organization intentionally hides — RMM service accounts, break-glass admins — so repeat, known-benign hides stop alerting). Both require environment-specific input the pipeline has no basis to invent, so populate them from your own admin and RMM inventory before relying on this rule. A reviewer separately flagged that the Sentinel/KQL translation of this rule (translations.json) maps TargetObject onto Defender's RegistryKey field, which does not carry the account name the way Sysmon's TargetObject does — that is inherited, accepted lossy behaviour in the translator layer, not something fixable in rule.yml itself.

Declared by the author

Administrators deliberately hiding a support, service or break-glass account from the Welcome screen for privacy or operational-security reasons -- the technique's own description names this as a legitimate, common admin practice, and it produces the identical registry write this rule matches.
Remote-support and RMM agents (helpdesk tooling, some endpoint-management suites) that provision a local service account for their own agent and hide it from the logon screen this same way as part of routine installation.
Kiosk-mode and shared-device imaging tooling that hides default or built-in local accounts from the Welcome screen as a standard step in a locked-down device profile.

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 T1564.002, evaluated against their registry_set events.

Share this rule

/u/siemphony/96a10031-fdaf-4d55-bcf7-fab8b20b65c8

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 marked hidden in the Windows SpecialAccounts UserList

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it