The chain
Machine boots → LogonUI consumes credentials → Winlogon starts userinit.exe → userinit runs the machine …\Winlogon\Userinit list (normally just userinit.exe itself) → launches the shell from Shell value (explorer.exe) → then your Run keys fire inside the shell session.
Why it matters
HKLM\…\Winlogon\Userinit
comma-separated list before shell; admin to write; ancient but legitimate extension point
HKLM\…\Winlogon\Shell
what gets launched as shell; custom-shelling (kiosk/POS) lives here
HKCU mirrors
same names exist under HKCU — they're honored for per-user setups; per-account persistence tooling sometimes uses them honestly
The audit position
- Skim them on every baseline:
Winlogonchanges are one of the oldest persistence classes and first-class in DFIR triage — don't leave them unqueried. - Untouched default is the signal: Userinit=
userinit.exeand Shell=explorer.exe. Any string following the default in the machine view is an intentional deviation documented somewhere, or it’s your finding. - Out of bounds for per-account tools: anything a client tuner did here would require admin and persist machine-wide — the smell-test post is why your chosen tool never needed it.
ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.