DC0016: Module Load
When a process or program dynamically attaches a shared library, module, or plugin into its memory space. This action is typically performed to extend the functionality of an application, access shared system resources, or interact with kernel-mode components.
Analyst context for executives and security teams
Module Load is a telemetry category for seeing when software dynamically attaches a shared library, module, or plugin into memory. For leaders, its value is coverage assurance: many legitimate applications use modules, but this evidence can also be essential for explaining how code was introduced into a process during an investigation. Without this visibility, SOC and IR teams may have gaps when reconstructing suspicious process behavior.
Executive priority
Prioritize this as a logging and evidence-readiness question rather than a standalone threat. Executives should ask whether critical systems produce, retain, and make searchable module-load evidence with enough context to support incident response, compliance inquiries, and control validation. The business risk is not that every module load is malicious; it is that missing or low-quality telemetry can delay root-cause analysis and weaken confidence in detection coverage.
Technical view
ATT&CK provides this object as an enterprise data component, but does not specify platforms, tactics, relationships, or detection logic. SOC and detection engineering teams should validate whether their telemetry records process-to-module relationships, timing, module or plugin identity, file location, and any available integrity metadata. IR teams should confirm that module-load records can be correlated with process execution and other endpoint evidence to reconstruct what code was present in a process memory space.
Likely telemetry
- Process module-load or library-load events
- Process identity and parent/child process context associated with the load
- Loaded module, shared library, or plugin name and path
- Timestamps for process start and module attachment
- File metadata for loaded components, where collected, such as hash, signer, or version information
Detection direction
- Validate that module-load telemetry is actually collected and retained for systems in scope; ATT&CK provides no built-in detection analytic for this data component.
- Tune analysis around context because module loading is common and often benign; suspiciousness usually depends on the process, module location, integrity metadata, timing, and surrounding activity.
- Check for blind spots where only process creation is logged but dynamic library, plugin, or kernel-interaction-related module attachment is not visible.
- Correlate module loads with process execution and file metadata rather than treating a single module-load event as sufficient evidence of malicious behavior.
Mitigation priorities
- Establish required telemetry coverage and retention for module-load evidence on assets where incident reconstruction matters most.
- Standardize collection of process, module identity, path, and available integrity metadata so SOC and IR teams can investigate consistently.
- Use application control, software inventory, and integrity validation practices where appropriate to reduce uncertainty around unexpected modules or plugins.
- Document this evidence source in incident response and compliance procedures so teams can prove what was reviewed during investigations.
Analyst notes and limits
This object is a data component, not a technique. Its primary value is defensive observability: it helps teams verify whether they can see code components being attached to running processes. Because no relationships or official detection text were supplied, detection engineering must be driven by local logging capabilities, asset criticality, and correlation with other endpoint evidence.
The supplied ATT&CK fields do not specify platforms, tactics, related techniques, mitigations, or official detection logic. This take therefore avoids claims about specific operating systems, attacker behavior, active exploitation, or guaranteed detection coverage. Local environment validation is required.
Module Load
When a process or program dynamically attaches a shared library, module, or plugin into its memory space. This action is typically performed to extend the functionality of an application, access shared system resources, or interact with kernel-mode components.
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 | 3.0 | Current bundle | f4e164330ed7… |
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 DC0016Open 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.