logonui.exe

LogonUI.exe presents the credential interface during interactive logon and at the lock screen. It does not authenticate anyone itself: winlogon.exe owns the secure logon sequence and starts LogonUI.exe to gather credentials, which then go to lsass.exe for validation. The genuine binary lives at C:\Windows\System32\LogonUI.exe, runs as NT AUTHORITY\SYSTEM, and is started by the session's winlogon.exe.

The actual sign-in tiles, password, PIN, picture password, smartcard, Windows Hello, and any third-party method, are drawn by credential providers: COM DLLs registered in the registry and loaded into LogonUI.exe. When winlogon asks for credentials, LogonUI queries each registered provider for its tiles and shows them. This is the supported way to add smartcard or MFA logon, so a non-Microsoft credential provider can be entirely legitimate.

LogonUI.exe appears whenever a credential prompt is on screen, at the sign-in screen and when the workstation is locked, and exits once the user is authenticated and the desktop is up. It comes and goes with the lock state and does not start other programs.

Like the other logon-screen processes, LogonUI.exe is mostly a baseline: a fixed identity with winlogon.exe as parent, SYSTEM as its account, and no child processes, so a deviation is easy to spot. The basic abuse is impersonation (T1036.005) from the wrong path or under the wrong account.

Its real risk is the credential provider model (T1556). Because LogonUI loads registered credential provider DLLs to draw the sign-in fields, an attacker who installs a rogue provider can capture credentials as the user types them at the logon or lock screen, running inside a SYSTEM process at the most sensitive moment. A credential provider DLL outside System32, from an unknown publisher, or freshly added to the registry deserves scrutiny.

The sign-in screen is also reachable before anyone logs in, which is what makes the accessibility-tool hijack so durable: swapping sethc.exe or utilman.exe for cmd.exe yields a SYSTEM shell at the lock screen. That shell appears as a child of winlogon.exe rather than LogonUI, but LogonUI is the screen in play when it happens.