Detecting and Mitigating Winlogon Helper DLL Abuse (T1547.004)

Winlogon.exe is the Windows component that handles logon and logoff, and the secure attention sequence you trigger with Ctrl-Alt-Delete. Because it runs at the start of every session, anything it launches gets a free ride. MITRE tracks the abuse of that behavior as T1547.004, Winlogon Helper DLL, with the tactics Persistence and Privilege Escalation on Windows.

How attackers use it

Registry entries under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ (and its Wow6432Node counterpart) and HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ manage helper programs that support Winlogon.

MITRE names three subkeys that have been known to be possibly vulnerable to abuse.

• Winlogon\Notify points to notification package DLLs that handle Winlogon events.
• Winlogon\Userinit points to userinit.exe, the user initialization program executed at logon.
• Winlogon\Shell points to explorer.exe, the system shell started at logon.

If an adversary changes one of these to add a DLL or executable, Winlogon runs it at each logon. That repeated execution is the persistence. The Userinit and Shell values are the classic trick, because they accept a list: the legitimate program stays, and a second entry rides along behind it.

MITRE lists many malware families and groups that have used these keys, which is a sign the technique is old, simple and still worked on.

How to detect it

MITRE's detection strategy has a registry half and a process half.

• Registry: watch for modifications to the Winlogon keys (Shell, Userinit, Notify) that introduce new executable or DLL paths.
• Process: correlate those changes with DLL loading, image loads or process creation that originates from winlogon.exe or userinit.exe.

Abnormal child process lineage is a strong tell, as are unauthorized binaries in C:\Windows\System32. If Sysmon is deployed, registry value set events (Event ID 13) and image load events (Event ID 7) cover most of this.

How to reduce the risk

MITRE lists two mitigations.

• Execution Prevention: use application control tools such as AppLocker that can audit or block unknown DLLs, so a planted helper does not run.
• User Account Management: limit account privileges so that only authorized administrators can change Winlogon helper settings.

Add a baseline. The legitimate values are well known (explorer.exe for Shell, and userinit.exe under System32 for Userinit), so any drift is easy to alert on.

Check your own environment

Read-only checks from a Windows command prompt. Run them on a few representative machines and compare.

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Userinit
reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell

• The HKLM Shell value should be explorer.exe and nothing more.
• The HKLM Userinit value should be the System32 path to userinit.exe, with a trailing comma.
• The HKCU Shell value is normally absent. If it exists, find out why.

Quick check

Sources

• MITRE ATT&CK, Boot or Logon Autostart Execution: Winlogon Helper DLL: https://attack.mitre.org/techniques/T1547/004