smss.exe: Windows Processes

Normal Profile

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

Parent: System (a value that published detection rules check for)Source: Elastic: Unusual Parent-Child Relationship (opens in a new tab)Each session's copy is started by the first smss.exe, a self-spawn Elastic's rule also allows.
Path: System32 (a value that published detection rules check for)C:\Windows\System32\smss.exeSources: SigmaHQ: System File Execution Location Anomaly (opens in a new tab), Velociraptor: Windows.Attack.UnexpectedImagePath (opens in a new tab)Some records write the folder as \SystemRoot\System32, a form SigmaHQ's rule also accepts.
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: Read its SessionId with Get-CimInstance Win32_Process, or windows.pslist in memory, on a clean machine of the same build.
Instances: Count copies with Get-CimInstance Win32_Process, or windows.pslist and windows.psscan in memory, on a clean machine of the same build.The copies it starts to set up each new session exit once that session is ready, and on a server hosting remote sessions several can run at once while people sign in.
Starts: At boot, straight after the kernelSource: Microsoft Learn: Windows startup issues troubleshooting (opens in a new tab)Fast Startup hibernates the kernel session when Windows shuts down, so its start dates from the last full boot, such as a restart.
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

Each session's first processes come from it, so an smss.exe outside System32, or started by anything but System or itself, is an impostor, and an unexpected child of it needs explaining. It is one of Windows' critical processes, so a genuine copy cannot be restarted without stopping Windows.

What It Does

Once the kernel has loaded the system registry hive and its boot drivers, it passes control to smss.exe, which sets up the system session and then starts the drivers not marked to start at boot. That makes it the first program the kernel runs, with System as its parent, the process that started it. During boot it runs the programs its BootExecute value lists, by default only autochk.exe, which checks the disks after an unclean shutdown. A session is the separate space Windows sets up for its own services, session 0, or for each person who signs in. The first copy stays running until Windows shuts down, while the copy it starts for each session exits once that session is set up. A second copy that stays running, or a child no detection rule expects, is the odd thing to look for.

It starts only a few programs. Elastic's rule expects autochk.exe, csrss.exe, wininit.exe, winlogon.exe, setupcl.exe, WerFault.exe, wpbbin.exe and poqexec.exe, plus a handful of named vendor tools. A shell, a script host or anything from a user folder under smss.exe is out of place.

For each session a copy of smss.exe starts that session's csrss.exe and either wininit.exe, in session 0, or winlogon.exe, in a person's session, then exits. Live tools and windows.pstree therefore show those processes with no running parent, while creation records written as the copy ran, such as event 4688 in the Security log and Sysmon event 1, still name smss.exe.

The parent PID of each session's processes, the PID of the copy that started them, can later belong to another process once that copy exits, so a live tool may name the wrong parent. Microsoft's Win32_Process page warns of exactly this and says to compare creation times. The Session Manager's registry key also holds KnownDLLs, the system DLLs Windows always loads from its own copies.

smss.exe starts a copy of itself for each session, and that copy starts the session's first processes and then exits. This table shows what each copy starts, which is why those processes show no running parent in a live tool.

Session Copies

Session	What Its smss.exe Copy Starts	What the Copy Does Next
Session 0	csrss.exe and wininit.exe	Exits
A person's session	csrss.exe and winlogon.exe	Exits

How Attackers Abuse It

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

A program added to the Session Manager's BootExecute value starts at boot under smss.exe, where only autochk.exe belongs by default.Wrong Parent
Malware takes the name smss.exe, the first program Windows starts, and runs from a folder other than System32.Wrong Path

In the Process Tree

These are the rows of the process list that this page explains.

smss.exeSession ManagerOpen it in the tree: smss.exe

smss.exeCopy for session 0ExitedStarts session 0's csrss.exe and wininit.exe, then exitsOpen it in the tree: smss.exe
smss.exeCopy for the person's sessionExitedStarts that session's csrss.exe and winlogon.exe, then exitsOpen it in the tree: smss.exe

Red Flags

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

Any parent but System, or smss.exe for a session copy, or a child it never starts, such as a shell.Wrong Parent
Any folder but System32, which some records write as \SystemRoot\System32.Wrong Path
A copy that is still running beside the first after its session is set up.Extra or Missing Instances
A copy that started long after boot with no new session to explain it.Unusual Start Time

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 Lands	What to Read	How to Turn It On
1 `Process creation` (opens in a new tab)`Microsoft-Windows-Sysmon/Operational`It is written on any Windows computer running Sysmon.	Image smss.exe with an unexpected ParentImage, or ParentImage smss.exe on a child it never starts. Sysmon logs from early in the boot.Process Trees and Call Chains shows how to read it.	Run Sysmon with ProcessCreate events in its configuration.
4688 `A new process has been created` (opens in a new tab)`Security`It is written on the computer the process ran on.	Creator Process Name smss.exe on each session's first processes. Any other process it creates needs explaining.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.
`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 hunting	InitiatingProcessFileName smss.exe on a FileName other than the few it starts, or an smss.exe 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

Reads the DeviceProcessEvents table in Defender XDR advanced hunting, from devices onboarded to Defender for Endpoint, so it covers only what starts while the sensor runs. Check that a recent boot shows smss.exe's children before you read no rows as clean. The list follows Elastic's rule, which also names a few vendor tools as normal children, so add the ones your estate runs before you read a hit as an impostor.

KQLDefender XDR, Advanced hunting

// smss.exe outside System32, and anything smss.exe starts beyond the few it shouldDeviceProcessEvents| where Timestamp > ago(30d)| where (FileName =~ "smss.exe" and FolderPath !in~ (@"C:\Windows\System32\smss.exe", @"C:\Windows\System32"))    or (InitiatingProcessFileName =~ "smss.exe"        and FileName !in~ ("smss.exe", "autochk.exe", "csrss.exe", "wininit.exe", "winlogon.exe", "setupcl.exe", "WerFault.exe", "poqexec.exe", "wpbbin.exe"))| project Timestamp, DeviceName, FileName, FolderPath, ProcessCommandLine, AccountName, InitiatingProcessFileName, InitiatingProcessFolderPath| order by Timestamp desc

Check It in the Registry: BootExecute KnownDLLs