AN0052: Analytic 0052
A process (often LOLBin or user-launched program) loads a DLL from a user-writable/UNC/Temp path or unsigned/invalid signer. Within a short window the DLL is (a) newly written to disk, (b) spawned as follow-on execution (rundll32/regsvr32), or (c) establishes outbound C2.
Analyst context for executives and security teams
This analytic focuses on a Windows risk pattern where a process loads a DLL from a location that should be treated as suspicious, such as a user-writable, UNC, or Temp path, or where the DLL has an unsigned or invalid signer. The business value is in catching potentially unauthorized code execution early, especially when the DLL was just written, is followed by execution through tools such as rundll32 or regsvr32, or is associated with outbound command-and-control-like network activity.
Executive priority
Prioritize this as a Windows endpoint and SOC validation item because DLL load behavior can be a gap between prevention, logging, and response. Leaders should ask whether endpoint telemetry captures DLL load path, file creation timing, signer status, child process activity, and outbound network context in a way analysts can correlate quickly. This is useful for incident decision-making and audit evidence around endpoint monitoring quality, but the supplied ATT&CK object does not specify active exploitation, affected industries, or guaranteed detection outcomes.
Technical view
For SOC, detection engineering, and IR teams, validate whether Windows endpoint data can correlate a process loading a DLL from user-writable, UNC, or Temp paths, or loading a DLL with unsigned or invalid signer status, with nearby file-write events, follow-on execution such as rundll32 or regsvr32, or outbound network activity. Because ATT&CK provides no official detection logic for this analytic and no relationship context, teams should treat it as a detection design pattern and tune it against local software behavior, administrator workflows, software deployment tools, and legitimate applications that load DLLs from nonstandard paths.
Likely telemetry
- Windows process execution telemetry, including parent-child process relationships
- DLL/image load telemetry with loaded module path and signing status where available
- File creation or modification events for newly written DLLs
- Process command-line telemetry for follow-on execution through rundll32 or regsvr32
- Network connection telemetry tied to process identity for outbound activity
Detection direction
- Confirm whether DLL load events are collected at sufficient fidelity; many environments collect process starts but not module loads.
- Correlate suspicious DLL load path or signer conditions with short-window file creation, follow-on execution, or outbound network activity rather than alerting on path alone.
- Tune for legitimate software installers, update agents, development tools, scripts, and line-of-business applications that may load DLLs from Temp or user-writable paths.
- Validate visibility for UNC-based DLL loads, which may require endpoint and network/file-share telemetry to investigate confidently.
- Use signer status carefully: unsigned or invalid signer can raise risk, but local baselining is needed to reduce noise.
Mitigation priorities
- Improve endpoint telemetry coverage first, especially DLL/image load, file creation, process lineage, command line, signer status, and process-scoped network activity.
- Reduce unnecessary execution and DLL loading from user-writable, Temp, or remote paths where business operations allow.
- Harden software deployment and administrative workflows so legitimate DLL staging behavior is known and can be allowlisted or baselined.
- Use application control or execution policy controls where feasible to limit untrusted code from nonstandard locations.
- Ensure incident response playbooks include triage of loaded DLL path, signer validity, file creation time, parent process, child process activity, and network connections.
Analyst notes and limits
This is a detection analytic object for Windows with no supplied tactics, relationships, aliases, or official detection text. The strongest use is as a validation checklist for whether the SOC can join module-load behavior with file, process, signer, and network context. Local baselining is essential because the ATT&CK object identifies suspicious conditions but does not define a complete query or threshold.
The supplied fields do not provide an ATT&CK tactic, technique relationship, data sources, detection pseudocode, known adversary use, impact, prevalence, or mitigation references. Any assessment of coverage, severity, or exposure requires local telemetry and environment context.
Analytic 0052
A process (often LOLBin or user-launched program) loads a DLL from a user-writable/UNC/Temp path or unsigned/invalid signer. Within a short window the DLL is (a) newly written to disk, (b) spawned as follow-on execution (rundll32/regsvr32), or (c) establishes outbound C2.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 20e46171a5b1… |
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-attack AN0052Open 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.