DET0018: Behavior-chain, platform-aware detection strategy for T1129 Shared Modules
DET0018 is a MITRE detection strategy for T1129 Shared Modules, where adversaries may execute payloads by loading shared code modules into processes. The b...
Analyst context for executives and security teams
DET0018 is a MITRE detection strategy for T1129 Shared Modules, where adversaries may execute payloads by loading shared code modules into processes. The business significance is that this behavior can make malicious execution look like normal application or operating-system activity, so coverage depends less on a single alert and more on whether teams can connect process behavior, module-loading evidence, and file context across Windows, Linux, and macOS environments supported by the related technique.
Executive priority
Prioritize this as an execution-detection validation item rather than a standalone control. Leaders should ask whether endpoint telemetry, SOC procedures, and incident response playbooks can explain suspicious module loads across critical servers, workstations, and developer or production systems. It is especially relevant to resilience and audit readiness because investigations may need evidence showing what process loaded what module, from where, and under what user or service context.
Technical view
The supplied object has no official description, detection logic, platforms, or tactics, but it detects ATT&CK T1129 Shared Modules, which is an enterprise execution technique on Linux, macOS, and Windows. SOC and detection teams should validate behavior-chain detection around module load events tied to process ancestry, file path, signer or trust context where available, user/session context, and subsequent process or network behavior. Because shared modules are normal OS and application behavior, detections should be platform-aware and tuned against expected software, update mechanisms, and administrative tooling.
Likely telemetry
- Endpoint process creation and process ancestry records
- Module/library load telemetry, where available
- File creation, modification, and rename activity for shared libraries such as Windows DLLs, Linux shared objects, and macOS dynamic libraries
- Command-line, parent process, user, and service context
- File metadata such as path, hash, permissions, and signing or trust information where collected
Detection direction
- Validate that telemetry can associate a loaded shared module with the responsible process, user, host, path, and time window.
- Tune for unusual or untrusted module locations, unexpected module loads by sensitive processes, and module-load activity followed by suspicious execution behavior, while accounting for legitimate software updates and plugins.
- Use relationship-driven context: this strategy is for T1129 Shared Modules under execution, so detection should focus on execution evidence rather than only file presence.
- Check platform blind spots separately for Windows, Linux, and macOS because the related technique spans all three, while the detection strategy itself does not specify platform details.
- Avoid over-reliance on hash or filename matching; shared-module behavior is common and requires environmental baselining to reduce false positives.
Mitigation priorities
- Inventory where module-load telemetry is available and retained for high-value endpoints and servers.
- Harden endpoint logging and EDR configuration so investigations can reconstruct process-to-module relationships.
- Apply least privilege and software control policies where appropriate to reduce unauthorized code execution opportunities.
- Maintain allowlists or baselines for expected application libraries, plugins, and update paths, especially on critical systems.
- Ensure IR playbooks include collection of running process module lists and related file metadata during execution investigations.
Analyst notes and limits
This take is based on a sparse MITRE detection-strategy object and its relationship to T1129 Shared Modules. The practical value is in validating whether defenders can distinguish normal shared-module use from suspicious execution chains. Local baselines, business-critical application knowledge, and endpoint telemetry quality will determine whether this can be made operational.
The official object provides no description, detection text, tactics, or platforms. Platform and tactic context comes only from the related T1129 technique. No active exploitation, adversary attribution, impact level, or guaranteed detection coverage is implied by the supplied data.
Behavior-chain, platform-aware detection strategy for T1129 Shared Modules
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 | T1129 | Shared Modules | This object detects Shared Modules. |
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 | e2749ea2167f… |
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 DET0018Open 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.