wininit.exe

Windows Start-Up Application

The start-up process that launches services.exe and lsass.exe.

Normal Profile

These are the values a genuine copy shows. Treat any value that differs as a lead.

Parent
smss.exe (a value that published detection rules check for)Source: Elastic: Unusual Parent-Child Relationship (opens in a new tab)That smss.exe copy exits, so live tools and windows.pstree show no running parent, while creation records name it.
Path
System32 (a value that published detection rules check for)C:\Windows\System32\wininit.exeSources: SigmaHQ: System File Execution Location Anomaly (opens in a new tab), Velociraptor: Windows.Attack.UnexpectedImagePath (opens in a new tab)
Account
Read it from the token on a clean machine of the same build, with Get-Process -IncludeUserName live or windows.getsids in memory.
Session
0Source: Microsoft Learn (TechNet Magazine archive): Inside the Windows Vista Kernel: Part 2 (opens in a new tab)
Instances
Count copies with Get-CimInstance Win32_Process, or windows.pslist and windows.psscan in memory, on a clean machine of the same build.
Starts
Compare with the last full boot, because Fast Startup keeps the kernel session, and wininit.exe with it, through each shutdown.
Command Line
Read it elevated with Get-CimInstance Win32_Process, or windows.cmdline in memory, and compare with a clean machine of the same build.
Signed By
Check the file with Sigcheck or Get-AuthenticodeSignature, because many Windows files are signed through a catalogue, not in the file itself.

A value that published detection rules check for.No public source states this value, so compare with a clean machine of the same Windows build.

Why It Matters

It starts the Service Control Manager and the Local Security Authority, which checks every sign-in, so a wrong wininit.exe puts everything under it in doubt. As a critical process it cannot be restarted, so a second or late copy is not genuine.

What It Does

wininit.exe is the Windows Start-Up Application. It starts once, early in the boot, in session 0, the hidden session where Windows runs its own services with no desktop, and it keeps running until Windows shuts down. The copy of the Session Manager (smss.exe) that sets up session 0 starts wininit.exe and then exits, so in a live process tree wininit.exe has no running parent. wininit.exe then starts three core processes, the Service Control Manager (services.exe), the Local Security Authority (lsass.exe) and, where Credential Guard runs, the isolated LSA (LsaIso.exe). Elastic's rule expects it as the parent of all three, and accepts it, beside winlogon.exe, as a parent of LogonUI.exe, dwm.exe and fontdrvhost.exe. It starts nothing a person runs, so a shell or a script under it is out of place.

It is on Microsoft's list of critical processes, so Windows stops with bug check 0xEF (CRITICAL_PROCESS_DIED) if it ends. A critical process cannot be restarted, so a second copy, or one that started long after boot, is never genuine. Neither is a copy outside System32.

Live tools and windows.pstree therefore show wininit.exe with no running parent, while creation records written at the time, such as event 4688 in the Security log and Sysmon event 1, still name smss.exe. Windows reuses a process ID (PID) once its process exits, so a running process at wininit.exe's parent PID that started after wininit.exe is a later process with the same number, not its parent.

How Attackers Abuse It

Each line is a way this process is misused, with the page that shows how to spot it.

  • Malware takes the name wininit.exe and runs from a folder other than System32, borrowing the trust of a critical process.Wrong Path
  • A shell or script host appears under wininit.exe, which starts services.exe, lsass.exe and a few other Windows processes only.Wrong Parent

Red Flags

Each sign below links to the page that shows how to confirm it.

  • A running parent that started before it, or a child such as a shell that no detection rule expects.Wrong Parent
  • Any folder but System32.Wrong Path
  • A copy that started long after the last full boot, since a critical process cannot restart without stopping Windows.Unusual Start Time
  • A second copy beside it, judged against the count on a clean machine of the same build.Extra or Missing Instances

How to Check It

Each page shows how to check this process, on a running machine and in a memory image.

What Records It

Each record names its log and what must be switched on to get it.

Record and Where It LandsWhat to ReadHow to Turn It On
4688 A new process has been created (opens in a new tab)SecurityIt is written on the computer the process ran on.New Process Name wininit.exe with a Creator Process Name other than smss.exe, or a path outside System32.Process Trees and Call Chains shows how to read it.Turn on Audit Process Creation. For the command line, also turn on Include command line in process creation events.
1 Process creation (opens in a new tab)Microsoft-Windows-Sysmon/OperationalIt is written on any Windows computer running Sysmon.Image wininit.exe with a ParentImage other than smss.exe, or ParentImage wininit.exe on a child no rule expects.Process Trees and Call Chains shows how to read it.Run Sysmon with ProcessCreate events in its configuration.
DeviceProcessEvents (opens in a new tab)Each row is a process creation or a related event, naming the new process, the process that created it and that creator's parent.Defender XDR, advanced huntingFileName wininit.exe with an InitiatingProcessFileName other than smss.exe, or a FolderPath outside System32.The Defender for Endpoint sensor on the device

Hunt It

The same hunt is written for four tools, so pick the one you use. Defender XDR and Sentinel queries are in KQL, which you paste into Advanced hunting in the Defender portal or into Sentinel's Logs page. Splunk queries are in SPL, for its Search page, and Velociraptor queries are in VQL, which you run as a hunt.

Sees It DirectlyDeviceProcessEvents, with DeviceFileCertificateInfo (documentation, opens in a new tab)

Reads the DeviceProcessEvents table in Defender XDR advanced hunting, from devices onboarded to Defender for Endpoint, so it holds only copies started while the sensor ran. Check that a recent boot shows the genuine copy before you read no rows as clean. A hit is a lead until its file and creator are checked. A blank signature means unknown, not unsigned, because DeviceFileCertificateInfo holds only files the sensor has checked.

KQLDefender XDR, Advanced hunting
// wininit.exe copies whose creator, path or signature breaks its profileDeviceProcessEvents| where Timestamp > ago(30d)| where FileName =~ "wininit.exe"| join kind=leftouter (    DeviceFileCertificateInfo    | summarize arg_max(Timestamp, IsSigned, IsTrusted, Signer, SignatureType) by SHA1    ) on SHA1| where InitiatingProcessFileName !~ "smss.exe"    or FolderPath !in~ (@"C:\Windows\System32\wininit.exe", @"C:\Windows\System32")    or IsTrusted == false| project Timestamp, DeviceName, FolderPath, ProcessCommandLine, AccountName, CreatedProcessSessionId, InitiatingProcessFileName, IsSigned, IsTrusted, Signer, SignatureType| order by Timestamp desc

Sources