Logon initialisation spawns a process other than the shell

Siemphony@siemphonylowT1037.001unverified

T1037.001 is the `HKCU\Environment\UserInitMprLogonScript` value, and the process that runs whatever that value points at is `userinit.exe` — so this rule gates on `userinit.exe` as the parent and treats any child that is not the shell as the hit, rather than listing script interpreters, because the value can name an executable directly. The same gate also covers AN0199's other configuration path, a script named by the user object's `scriptPath` attribute. Two exclusions shape it: the shell, pinned to `\Windows\explorer.exe` rather than to any file named explorer.exe so that a payload dropped under that name elsewhere is still a hit, and a command line naming one of the domain script shares, because `scriptPath` resolves against NETLOGON and the ordinary domain logon script would otherwise match at every logon. MITRE's `script_path_keywords` knob names NETLOGON and SYSVOL as paths to tune on; it is used inversely here, populated with those two share names as a suppression rather than a selection, and the cost of that choice is that a script an adversary stages on either share is outside this rule's reach. The exclusion is the two share names rather than "any UNC prefix" on purpose: the command line is written by whoever set the registry value, so a blanket contains-`\\` filter would let any value carrying a UNC-shaped string — `\\127.0.0.1\C$\Users\Public\p.bat` for a purely local file — silence the whole rule. The brief maps Security EventID 4688 onto Sigma's `process_creation` category, which is Sysmon-shaped — this rule is written in that vocabulary (`Image`, `ParentImage`, `CommandLine`), and a raw 4688 feed, whose native names are `NewProcessName` and `ParentProcessName`, needs the usual field mapping applied before it can match. 4688 also needs *Audit Process Creation*, and the share exclusion additionally needs the separate *Include command line in process creation events* policy; without it `CommandLine` is absent, nothing is suppressed and the rule gets noisier rather than quieter. AN0199's Group Policy half — `gpscript.exe` and System 1502/1503 — is not used: those scripts run from the local Group Policy cache at every logon, and configuring them is Group Policy modification rather than the per-user registry value this technique defines. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0072, 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.

DeviceProcessEvents| where ((InitiatingProcessFolderPath endswith "\\userinit.exe" and not (FolderPath endswith "\\Windows\\explorer.exe")) and not ((ProcessCommandLine contains "\\netlogon\\" or ProcessCommandLine contains "\\sysvol\\")))

Splunk · SPL

Run this as a search.

index=* ((ParentImage="*\\userinit.exe" AND NOT (Image="*\\Windows\\explorer.exe")) AND NOT ((CommandLine="*\\netlogon\\*" OR CommandLine="*\\sysvol\\*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.parent.executable) LIKE "*\\\\userinit.exe" AND NOT (TO_LOWER(process.executable) LIKE "*\\\\windows\\\\explorer.exe")) AND NOT ((TO_LOWER(process.command_line) LIKE "*\\\\netlogon\\\\*" OR TO_LOWER(process.command_line) LIKE "*\\\\sysvol\\\\*")))

Wazuh · XML rule

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

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="ParentImage" type="pcre2">(?i)\\userinit\.exe$</field>    <field name="Image" negate="yes" type="pcre2">(?i)\\Windows\\explorer\.exe$</field>    <field name="CommandLine" negate="yes" type="pcre2">(?i)(\\netlogon\\|\\sysvol\\)</field>    <description>Logon initialisation spawns a process other than the shell</description>    <mitre>      <id>T1037.001</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: low
Category: registry_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 8df64ad3-948c-45d0-9443-b86f4ae096a5

ATT&CKT1037.001

T1037.001Logon Script (Windows)

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.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

T1037.001 is the HKCU\Environment\UserInitMprLogonScript value. Windows runs whatever that value names through userinit.exe at logon, so this rule does not hunt for the registry write — it watches the consequence. Any process created with userinit.exe as its parent, other than the shell, is the hit. The same gate covers AN0199's second configuration path, a script named by the user object's scriptPath attribute, because that also runs under userinit.exe. Framing it as "parent is userinit, child is not explorer" rather than as a list of script interpreters is deliberate: the registry value can name an executable directly, so an interpreter list would miss the simplest case.

02 · Telemetry you need

category: process_creation, product: windows, copied verbatim from AN0199, and written in the Sysmon EventID 1 vocabulary — Image, ParentImage, CommandLine. A Security 4688 feed carries the same behaviour under NewProcessName and ParentProcessName and needs that mapping applied first. 4688 also requires Audit Process Creation, and the share suppression needs the separate Include command line in process creation events policy on top. Miss that second policy and CommandLine is empty, nothing is suppressed, and the rule gets louder rather than quieter. Neither policy is on by default.

03 · How the logic works

One selection and two filters. selection_logon_init is ParentImage|endswith: '\userinit.exe' — the entire positive condition. filter_shell removes the normal case, and it is pinned to '\Windows\explorer.exe', not to '\explorer.exe'. That detail matters: an actor who can write HKCU can name their payload explorer.exe and drop it in C:\Users\Public, and an unanchored filter would have the rule excluding its own target. Anchoring on the directory keeps non-C: system drives working while refusing a decoy staged elsewhere. filter_domain_share drops command lines containing \netlogon\ or \sysvol\, because scriptPath resolves against NETLOGON and the ordinary domain logon script would otherwise fire at every logon on the estate. MITRE's script_path_keywords knob names NETLOGON and SYSVOL as script locations to tune on; here it is used inversely, populated with those two share names as a suppression, and the cost is that a script staged on either share is out of reach. It is the two share names and not "any UNC-shaped string" on purpose — the command line is adversary-written, so a blanket filter would let \\127.0.0.1\C$\Users\Public\p.bat silence the rule for a purely local file.

04 · Common false positives

Loudest by a wide margin: endpoint-management, drive-mapping and printer-deployment products that hook logon through the same registry value or a local logon script. That is the same mechanism as the technique, it fires at every logon on every host carrying the agent, and it is why the rule ships at low rather than medium. Behind it: estates running a per-user script from an ordinary file share or a local path where the share filter does not apply; kiosk and task-station builds with a replaced shell, so the configured application starts under userinit.exe on every logon; and installers queuing work for next logon, which produce a single match.

05 · Detection maturity

tier_1: , and it stays there until it is run against real data. The logic is derived from a MITRE scaffold containing no query logic and has never touched a log line. Tracing it on paper says a registry-set payload appears as a child of `userinit.exe` — analysis, not evidence, and silent about the volume underneath.
tier_2: is a fortnight read-only, producing the allowlist. Tier 3** is correlating the child process against the registry write that configured it.

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

Baseline Image for every child of userinit.exe for a fortnight, then convert the top of that list into an allowlist filter — that is where the volume dies, not in more clever matching. Apply MITRE's user_context knob to scope the rule to privileged or remote-access users, and execution_time_window to the first minutes after authentication. Pair it with a registry_set rule on the UserInitMprLogonScript value: the write is the technique, this is the echo.

Declared by the author

Endpoint-management, drive-mapping and printer-deployment products that hook logon by writing UserInitMprLogonScript or a local logon script themselves, which is the same mechanism this technique uses and fires at every logon on every host carrying the agent. This is the highest-volume match by a wide margin and is why the rule is low rather than medium.
Estates that still run a per-user logon script served from an ordinary file share or copied to a local path such as C:\ProgramData rather than from NETLOGON or SYSVOL, where the share exclusion does not apply and userinit.exe launches the script at each affected user's logon.
Kiosk and task-station builds that replace the shell, so the configured application starts under userinit.exe instead of explorer.exe and falls outside the shell exclusion on every logon.
Software installers and repair tasks that queue work to run at next logon through the same per-user logon script value, producing a single match on the following logon.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 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.

Verification2 runs

Not verified

Security Datasets — Logon script persistence via UserInitMprLogonScript
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.
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 T1037.001, evaluated against their process_creation events.

Share this rule

/u/siemphony/8df64ad3-948c-45d0-9443-b86f4ae096a5

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 initialisation spawns a process other than the shell

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it