DET0404: Detect Winlogon Helper DLL Abuse via Registry and Process Artifacts on Windows
MITRE ATT&CK DET0404: Detect Winlogon Helper DLL Abuse via Registry and Process Artifacts on Windows Detection Strategy details, with detection guidance,…
Security context for executives and security teams
DET0404 is a detection strategy for identifying possible abuse of Windows Winlogon helper DLL functionality through registry and process artifacts. Its business significance is persistence and privilege-escalation risk: changes in Winlogon-related registry locations can allow code to run during user logon, making this a control area leaders should expect SOC, IR, and endpoint teams to validate rather than assume is covered.
Executive priority
Prioritize this as a Windows endpoint resilience and incident-readiness question: do we know who can modify Winlogon-related registry paths, do we collect evidence when they change, and can the SOC distinguish approved configuration from suspicious persistence? This matters for audit evidence, privileged access governance, and containment decisions during endpoint investigations.
Technical view
The supplied ATT&CK relationship maps DET0404 to T1547.004, Winlogon Helper DLL, under persistence and privilege escalation on Windows. Detection validation should focus on registry activity involving HKLM\Software[\Wow6432Node\]\Microsoft\Windows NT\CurrentVersion\Winlogon\ and HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\, plus process artifacts around logon-time execution by or near winlogon.exe. Because the official detection text is not provided, teams should treat this as a coverage-validation prompt, not a complete analytic.
Likely telemetry
- Windows registry modification telemetry for Winlogon-related HKLM and HKCU paths
- Endpoint process creation telemetry around logon events and winlogon.exe-adjacent execution
- DLL or executable load evidence where available from EDR or host logging
- User, host, and account context for the identity making registry changes
- Change-management or software deployment records to separate approved configuration from suspicious changes
Detection direction
- Baseline expected Winlogon registry values across managed Windows endpoints and alert on new, modified, or unusual entries.
- Correlate registry changes with the modifying account, parent process, endpoint role, and subsequent process or DLL execution during logon.
- Tune for legitimate administrative, imaging, or software-management activity to reduce false positives.
- Validate whether 32-bit and 64-bit registry paths, including Wow6432Node, are both monitored.
- Confirm that detections are tested against telemetry actually retained in the SOC, not only assumed EDR capability.
Mitigation priorities
- Restrict administrative write access to Winlogon-related registry locations through standard endpoint hardening and privileged access controls.
- Use change control for approved endpoint configuration changes that affect logon behavior.
- Maintain endpoint logging or EDR coverage sufficient to capture registry and process artifacts needed for investigation.
- Include Winlogon registry review in Windows persistence triage playbooks.
- Periodically audit high-value Windows systems for unexpected Winlogon helper entries.
Additional notes and limits
The object itself has no official description, detection text, tactics, or platform field populated. The practical interpretation comes from the detection strategy name and its ATT&CK relationship to T1547.004, which supplies Windows, persistence, privilege-escalation, and Winlogon registry context.
This take does not assert active exploitation, attribution, impact, or guaranteed detectability. Local validation is required to determine whether registry, process, and DLL-load evidence is collected with enough fidelity and retention to support this strategy.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Detect Winlogon Helper DLL Abuse via Registry and Process Artifacts on Windows
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1547.004 | Winlogon Helper DLLSub-technique | This object detects Winlogon Helper DLL. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Imported snapshots across ATT&CK releases(1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | a6ea6ed826b4… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
- [1]mitre-attackDET0404Open source URL
- [2]mitre-attackDET0404Open source URL
- [3]mitre-attackDET0404Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.