Auditing Windows Credential UI Providers: The Logon Extensions Attackers Abuse

Learn how credential providers expand the Windows pre-logon attack surface, what defenders should inventory, and how to detect unauthorized registration and drift.

Windows credential providers are COM components that collect or transform authentication material on the secure desktop. Password, smart-card, Windows Hello, and third-party MFA tiles all use this framework. That extensibility is operationally useful, but it also places vendor code at one of the most sensitive trust boundaries on the machine: before an interactive user receives a desktop.

An attacker with administrative access can register a malicious provider or filter, suppress legitimate tiles, imitate a trusted sign-in experience, or capture credentials for later use. This is usually persistence after privilege escalation, not an initial-access technique. That distinction matters: endpoint protection may remove the first payload while a quiet registry-backed logon extension survives.

What defenders should inventory

Credential provider registrations live primarily below HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers. Filters use the adjacent Credential Provider Filters key. Each child key is a CLSID that should resolve through HKCR\CLSID\{GUID} to an in-process server DLL.

A useful inventory is not merely a list of GUIDs. For every provider and filter, record:

the CLSID, friendly name, registry path, and resolved DLL path;
the DLL publisher, Authenticode status, file hash, version, and creation time;
whether the path is absolute, local, and stored in a directory writable only by administrators or TrustedInstaller;
the expected deployment source, such as Windows, an approved MFA client, VPN software, or endpoint management tooling;
whether the component exists in the organization's known-good baseline for that device role.

High-signal findings

Do not label every non-Microsoft provider malicious. Enterprises legitimately install identity products. Instead, prioritize evidence that breaks the expected trust chain. An unsigned DLL, a missing binary, a newly registered CLSID, or an InprocServer32 value pointing into ProgramData, a user profile, or a temporary directory deserves immediate review. A signed file is not automatically safe; validate the publisher against your allowlist and investigate unexpected signer changes.

Credential provider filters deserve extra scrutiny because they can decide which providers appear. A malicious or broken filter can hide password, smart-card, or recovery options and create both a security incident and an availability problem. Compare filter registrations with the approved authentication architecture, not with a generic Windows image.

Baseline the relationship, not just the file: registration CLSID → COM server path → signer → approved product → expected device population.

A safe audit workflow

Collect without loading. Read registration and file metadata; do not instantiate unknown COM objects during discovery.
Normalize paths. Expand environment variables, resolve WOW64 registry views, and reject relative or network paths.
Verify ownership and ACLs. A correctly signed DLL in a directory modifiable by standard users remains replaceable.
Diff against a role-aware baseline. A kiosk, administrator workstation, and VPN laptop may have different legitimate providers.
Correlate changes. Review software installation records, registry auditing, EDR process telemetry, and recent privileged logons.

PowerShell can support triage, but test in a lab and preserve both 64-bit and 32-bit views. A minimal registry inventory starts with:

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers' |
  Select-Object PSChildName, PSPath

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters' |
  Select-Object PSChildName, PSPath

Containment without causing a lockout

Never delete a suspicious registration blindly on a production endpoint. Capture the relevant keys and binaries, verify that another tested sign-in method exists, and maintain console or recovery access. Then quarantine the host, investigate how administrative control was obtained, and remove the component through a controlled change. Credential theft may already have occurred, so rotate exposed credentials and revoke sessions where appropriate.

From one machine to a fleet

On one Windows machine, WinSentinel Free provides the full local audit capability across all 64 modules without feature limits. Organizations need an additional layer: WinSentinel Pro centralizes agent management, fleet baselines, compliance rollups, and drift alerts. That makes a newly registered provider on three finance laptops visible as one correlated change instead of three isolated registry curiosities.

The practical control is simple: know which logon extensions belong, continuously verify the full registration-to-binary trust chain, and treat unapproved drift as privileged persistence until proven otherwise.