explorer.exe: Windows Processes

Normal Profile

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

Parent: userinit.exeSources: Microsoft Learn: MSGina.dll Features, Userinit.exe activation (opens in a new tab), Ask the Performance Team blog: WS2008: Terminal Services Architecture (opens in a new tab), Elastic: Execution of Persistent Suspicious Program (opens in a new tab)Live tools usually show no parent, as userinit.exe has exited by then.
Path: The Windows folder (a value that published detection rules check for)C:\Windows\explorer.exeSource: Velociraptor: Windows.Attack.UnexpectedImagePath (opens in a new tab)A 32-bit copy lives in C:\Windows\SysWOW64.
Account: The person signed inSource: Microsoft Learn: MSGina.dll Features, Userinit.exe activation (opens in a new tab)
Session: The person's sessionSource: Microsoft Learn: MSGina.dll Features, Userinit.exe activation (opens in a new tab)
Instances: Count copies per person on a clean machine of the same build, with the same folder options.
Starts: At sign-in, after userinit.exeSources: Microsoft Learn: MSGina.dll Features, Userinit.exe activation (opens in a new tab), Elastic: Execution of Persistent Suspicious Program (opens in a new tab)A late start alone proves little, because the shell can be restarted without a new sign-in.
Command Line: Read it with Get-CimInstance Win32_Process on a clean machine of the same build.
Signed By: Check the file with Sigcheck, which reads catalogue signatures too, on a clean machine of the same build.

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

Programs a person starts, and programs set to run at sign-in, show explorer.exe as their parent, so a child of explorer.exe tells you how it began. A copy running as SYSTEM, or from another folder, is not the shell.

What It Does

Explorer is the default shell, the program Userinit starts once a person has signed in, from the Winlogon Shell value. The shell inherits the environment Userinit set up for the person, so it runs as that person, in their session. Shell Launcher replaces it on kiosk and single-purpose devices running Enterprise, Education or IoT Enterprise, with Eshell.exe or CustomShellHost.exe, so a machine with no explorer.exe can be normal. It runs from C:\Windows, or C:\Windows\SysWOW64 for a 32-bit copy. A copy running as SYSTEM, from another folder, or with script hosts among its first children at sign-in is the one to check.

Explorer starts what a person opens from the Start menu, the desktop or a folder, and it processes the Run key at each sign-in, so those programs show explorer.exe as their parent too. Velociraptor's parent table expects a person's cmd.exe and powershell.exe to have explorer.exe as their parent. Elastic watches the first minute after sign-in for script hosts and similar tools that explorer.exe starts with a path in a user or temporary folder.

In creation records its parent is userinit.exe, which does not stay running, so live tools show no parent. A copy that started long after sign-in is not proof on its own, as the shell can be restarted, so judge its path, account and children first.

How Attackers Abuse It

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

Code put into explorer.exe runs as the signed-in person, under a name every user trusts.Remote Thread Injection
A program set to run at sign-in starts under explorer.exe, and a Windows name running from a user folder is the one to check.Wrong Path

Red Flags

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

Any folder but C:\Windows, or C:\Windows\SysWOW64 for the 32-bit copy.Wrong Path
Running as SYSTEM, or as an account that has not signed in here.Wrong Account
Script hosts or rundll32.exe started soon after sign-in, from a path in a user or temporary folder.Wrong Parent
A child recorded under it that something else created. Splunk flags explorer.exe started with /root.Parent Process Spoofing
A Windows DLL name loaded into it from outside System32, SysWOW64 or WinSxS, or without Microsoft's signature.DLL Search Order Hijacking and Side-Loading

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
4688 `A new process has been created` (opens in a new tab)`Security`It is written on the computer the process ran on.	For New Process Name explorer.exe, a Creator Process Name of userinit.exe and an account that signed in here.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/Operational`It is written on any Windows computer running Sysmon.	Image explorer.exe with its User, and ParentImage explorer.exe for what it started.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 hunting	FolderPath and AccountName for each copy, and InitiatingProcessFileName explorer.exe for its children.	The Defender for Endpoint sensor on the device
7 `Image loaded` (opens in a new tab)`Microsoft-Windows-Sysmon/Operational`It is written on any Windows computer running Sysmon.	ImageLoaded, Signed and SignatureStatus for each module explorer.exe loads, where a Windows DLL name outside System32, SysWOW64 or WinSxS stands out.Loaded DLLs shows how to read it.	Run Sysmon with ImageLoad events in its configuration. They are off by default.
`DeviceImageLoadEvents` (opens in a new tab)Each row is a DLL load, showing which module loaded into which process. The table has no signature columns, so join it to DeviceFileCertificateInfo on SHA1 to see who signed the module.Defender XDR, advanced hunting	Modules where InitiatingProcessFileName is explorer.exe, with FolderPath. Join DeviceFileCertificateInfo on SHA1 for the signer.	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. Before you read no rows as clean, check that it recorded the genuine copy at a recent boot or sign-in. A hit is a lead, so check the file's signer and where it came from before you call it malicious.

KQLDefender XDR, Advanced hunting

// explorer.exe outside C:\Windows and C:\Windows\SysWOW64, or running as SYSTEMDeviceProcessEvents| where Timestamp > ago(30d)| where FileName =~ "explorer.exe"| where not(FolderPath matches regex @"(?i)^C:\\Windows(\\SysWOW64)?(\\explorer\.exe)?$")    or AccountSid == "S-1-5-18"| project Timestamp, DeviceName, FolderPath, AccountName, ProcessCommandLine, InitiatingProcessFileName

Check It in the Registry: Winlogon Shell and Userinit Run and RunOnce Keys WOW6432Node Run and RunOnce RunOnceEx Startup Folder Redirection StartupApproved Policies Explorer Run KnownDLLs