Shared Modules
Shared-module abuse loads malicious code into another application's process.
What it means
Shared-module abuse loads malicious code into another application's process. The relevant boundary is which module was selected and why, not only the executable's identity.
An investigation example
A legitimate application loads a previously unseen library from a user-writable directory.
Evidence to examine
Review module path, provenance, hash, load order, application search behavior, and resulting actions.
A common analytical pitfall
An unfamiliar library is not automatically malicious; updates and optional plugins change module inventories.
Response considerations
Preserve the module and loading context, verify installation provenance, and correct unauthorized or unsafe loading paths.
A legitimate process can execute additional code
Applications load shared libraries to reuse functionality rather than contain every function in one executable. The loaded module executes within a process context, so trusting only the main program's name or signature can miss important behavior. The module's origin, integrity, path, and expected relationship to the application matter too.
Module loading is normal and frequent. A library from an unfamiliar location may warrant review, but legitimate plugins and development environments can also use nonstandard paths. Investigators should compare a known-good application configuration and examine the surrounding file and process events. An unsigned module is a clue, not a complete verdict.
A fictional application add-on
An academy's reporting application begins making unexpected network requests. Endpoint evidence shows that it loaded a newly created library from a user-writable folder shortly beforehand. Analysts preserve the library identity, load event, application context, file creation history, and later activity. They ask whether an approved update or plugin installation explains the change.
A library being present on disk does not establish that it loaded successfully, while a load event does not describe every action it performed. Memory, execution, and network records may add context. Do not run the recovered module on a personal machine or place it into a trusted application's directory to experiment. Use an authorized analysis route.
Follow the code boundary
Draw a fictional application with its expected libraries and one newly observed module. Mark which source controls each file and which identities can modify the directories. Explain the evidence needed to connect the new module to the unexpected behavior. A prepared event list is sufficient.
Defensive review should consider code-loading policy and writable locations along with executable allowlists. A trusted host process can still consume untrusted code if the surrounding boundary is weak. Remediation should preserve legitimate extension needs while correcting the observed loading path and the access that introduced the module.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
MITRE ATT&CK T1129: Shared Modules