LogonUI.exe: Windows Processes

Normal Profile

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

Parent: winlogon.exeSources: Microsoft Learn: Credentials Processes in Windows Authentication (opens in a new tab), Elastic: Unusual Parent-Child Relationship (opens in a new tab)Elastic's rule also accepts wininit.exe as its parent.
Path: System32 (a value that published detection rules check for)C:\Windows\System32\LogonUI.exeSource: SigmaHQ: System File Execution Location Anomaly (opens in a new tab)
Account: SYSTEMSource: Microsoft Learn: Custom Login Experiences: Credential Providers in Windows Vista (opens in a new tab)
Session: Read its SessionId at the sign-in screen and at the lock screen, on a clean machine of the same build.
Instances: Count copies at the sign-in screen, the lock screen and the desktop, on a clean machine of the same build.
Starts: When Winlogon receives a secure attention sequenceSources: Microsoft Learn: Credentials Processes in Windows Authentication (opens in a new tab), Ask the Performance Team blog: WS2008: Startup Processes and Delayed Automatic Start (opens in a new tab)It also shows the tiles that unlock a locked session, and exits once it has passed the credentials to Winlogon.
Command Line: Read it elevated with Get-CimInstance Win32_Process while the sign-in screen shows.
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

It is where a person types their password, so a fake LogonUI.exe, or an unknown credential provider loaded into the real one, sits where credentials pass. Microsoft lists it among the built-in critical processes.

What It Does

Winlogon always starts Logon UI after it receives a secure attention sequence. A credential provider is the component that offers one way to sign in, such as a password, a smart card or biometrics. Logon UI asks each one which tiles it offers, shows them on the secure desktop, and submits the credentials a person enters through a tile. Credential providers only gather and serialise credentials, and the Local Security Authority checks them. It runs as SYSTEM and also shows the tiles that unlock a locked session. A LogonUI.exe outside System32, or one started by anything but winlogon.exe or wininit.exe, is the one to check.

Logon UI loads each registered credential provider DLL, the library of code behind a tile, and keeps it for its whole lifetime, so its loaded modules name every provider in use. One with no valid signature, or from a vendor nobody installed, deserves a look.

Microsoft lists LogonUI.exe among the built-in critical processes, whose unexpected end stops Windows with bug check 0xEF, and its description of start-up says it exits once it has passed the credentials to Winlogon. So expect it only while the sign-in or unlock tiles show. Microsoft does not document whether it stays running behind the lock screen, so check a clean machine of the same build.

How Attackers Abuse It

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

A credential provider nobody installed loads into LogonUI.exe, where people type their passwords, so check the signer of each one.Unsigned or Oddly Signed Modules
Malware takes the name LogonUI.exe and runs from another folder, where the name passes a quick look and the path does not.Wrong Path

Red Flags

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

A creator other than winlogon.exe, though Elastic's rule also allows wininit.exe.Wrong Parent
Any folder but C:\Windows\System32.Wrong Path
A credential provider DLL loaded into it with no valid signature or an unknown publisher.Unsigned or Oddly Signed Modules
A LogonUI.exe with no valid signature, embedded or through a catalogue.Renamed, Unsigned or Falsely Signed Binaries

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 a New Process Name ending in LogonUI.exe, the Creator Process Name should be winlogon.exe.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 and ParentImage for each copy, with its User.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 InitiatingProcessFileName for each copy.	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.	Each module loaded into LogonUI.exe, with its signature fields, which shows the credential providers it loads.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 LogonUI.exe. 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

// LogonUI.exe outside C:\Windows\System32, or created by anything but winlogon.exe or wininit.exeDeviceProcessEvents| where Timestamp > ago(30d)| where FileName =~ "LogonUI.exe"| where not(FolderPath matches regex @"(?i)^C:\\Windows\\System32(\\LogonUI\.exe)?$")    or InitiatingProcessFileName !in~ ("winlogon.exe", "wininit.exe")| project Timestamp, DeviceName, FolderPath, ProcessCommandLine, AccountName, CreatedProcessSessionId, InitiatingProcessFileName, InitiatingProcessFolderPath

Read with Active Directory: Credentials on a Running Machine The credentials typed into its tiles are what a sign-in leaves for LSASS to hold.