T1129 Shared modules

How to detect T1129 Shared Modules on Linux, macOS and Windows using process, network and traffic telemetry, validate the detections in a private cyber range, and respond when they fire.

Book a callTalk to us
On this page

How T1129 shared modules execution shows up in your environment

T1129 Shared Modules lets an adversary run malicious code under the Execution tactic (TA0002) by getting a system to load a shared module, such as a Windows DLL, a Linux shared object or a macOS dynamic library, that contains the attacker's code. The operating system's loader does the work, so the activity can look like ordinary software starting up. For a SOC lead, the practical question is whether a module load happened inside a process that should load it, from a location that should hold it, and whether the surrounding network activity fits that process. This page targets MITRE ATT&CK Enterprise version 20.0, released on 2026-10-13. Technique IDs, sub-technique structure and data component mappings can change between releases, so confirm the mapping against the ATT&CK version your rules cite before you tune anything.

In intrusions, the signal usually sits at the boundary between a trusted process and an unfamiliar module. On Windows, Linux and macOS, the useful pattern is a process that loads a library from a user-writable or otherwise unexpected directory, a module with no valid signature where the environment normally expects signed code, or a process that begins making outbound connections it has never made before. Process Creation (DC0032) gives the parent and child context, Network Connection Creation (DC0082) shows the new outbound paths, and Network Traffic Content (DC0085) helps where your sensors can inspect payloads. Those three sources only work together if the process inventory for key servers and workstations is known first, so a baseline of normal module locations and network behavior should exist before alerts are written.

Telemetry that reveals shared module use on Linux, macOS and Windows

This table maps Process Creation (DC0032), Network Connection Creation (DC0082) and Network Traffic Content (DC0085) to Linux, macOS and Windows, with an open-source collector for each and the gaps that appear when a source is missing. Read each row as a question: which event shows a module being loaded into a process, and which gap leaves that load invisible. Confirm the data component mapping for T1129 against the ATT&CK v20 bundle before you build rules, because shared module use is closely tied to Module Load telemetry.

Platform and data componentCollectorWhat the defender looks forGap when the source is missing
Windows, Process Creation (DC0032)Wazuh agent with Sysmon event forwarding, or VelociraptorUnexpected parent-child process pairs and command lines that load modules from unusual pathsModule loads that happen inside an already running process leave no new process event
Windows, Network Connection Creation (DC0082)Wazuh or Velociraptor with network connection collection enabledOutbound connections from processes that do not normally reach the network, following a suspicious loadConnections made after a module loads are attributed to the host process without context
Windows, Network Traffic Content (DC0085)Zeek or Suricata on a span or tap at the host segmentPayload patterns or protocol anomalies in traffic tied to a newly loaded componentEncrypted sessions hide content, so only metadata and timing remain for review
Linux, Process Creation (DC0032)Wazuh with auditd rules, or Velociraptor artifacts for process executionExecution of binaries that then pull in libraries from writable or temporary directoriesWithout process audit events, library loading from a running binary has no record
Linux, Network Connection Creation (DC0082)Wazuh or Velociraptor socket and connection collectionLong-lived connections opened by a process after it loads an unfamiliar libraryHosts without connection logging show outbound traffic with no owning process
Linux, Network Traffic Content (DC0085)Zeek on the sensor path, with Suricata rules for protocol contentUnexpected protocols or staging patterns on hosts where the process should be quietTraffic from hosts outside sensor coverage cannot be correlated with local events
macOS, Process Creation (DC0032)Wazuh agent with unified log collection, or Velociraptor where supportedProcesses that start from unusual locations and then load code from non-standard pathsCoverage depends on which log streams the agent collects, so confirm the scope in your build
macOS, Network Connection Creation and Network Traffic Content (DC0082, DC0085)Velociraptor for connection state, Zeek or Suricata for trafficConnections and traffic from applications that rarely communicate, observed near the time of a loadWithout a sensor on the segment, the network view for macOS endpoints is limited to host-side records

Detection logic for T1129 that SOC teams can tune

T1129 Shared Modules is hard to spot because loading a library is normal behavior for most processes. The four ideas below share one approach: build a baseline of normal module loads, network behavior and traffic content first, then alert on deviations from that baseline. Each card lists what to review before enabling the rule in production.

Unusual module loads by lineage

Alert when a process loads a shared module that it has never loaded in the baseline period, particularly when the parent process is a document viewer, browser, script host or a service that does not normally load that component. Process Creation telemetry gives the parent-child chain, and Module Load telemetry on Windows and comparable logging on Linux and macOS give the loaded object. Review the baseline window length, the allowlist of parent-child pairs and the score given to unknown libraries. Common false positives come from software updaters, IDE plugins and developer build tools, which load new components often and should be grouped by signed publisher or package manager before tuning.

Loads from unexpected paths

Flag shared modules loaded from user-writable directories, temporary folders, download locations or removable media, especially when the same file name exists in a trusted system path. File Creation and File Modification telemetry show where a library was written, and the load event shows where it was used from. Tune the list of trusted directories per host role, and review whether the rule covers both the write and the later load. Common false positives include per-user application installs, portable software and build output directories on developer workstations, so review those paths by host group rather than suppressing them globally.

Network activity after new component loads

Correlate a newly observed module load with Network Connection Creation events from the same process within a short window. A library that opens outbound connections to destinations the host has never contacted is a stronger signal than the load alone. Review the time window, the destination reputation source and the count of new destinations required to raise severity. Common false positives include update checks, telemetry and license validation from legitimate software, so maintain a list of known update endpoints per application and confirm it with the software owner.

Content checks on module traffic

Inspect Network Traffic Content for protocol and payload patterns that do not match the application the process is expected to run, such as an unusual protocol on a standard port or an unexpected payload type in a response. Zeek and Suricata are common open-source sources for this telemetry, and the rule logic should be written against the protocol fields they expose. Confirm which traffic is decrypted or visible at your sensors before writing rules, because encrypted traffic limits what content checks can see. Common false positives come from software that uses custom binary protocols, such as database drivers and monitoring agents, so document those protocols in the baseline before alerting.

Shared module baseline ownership

Assign an owner for the baseline of approved shared modules per host group, and review it on a fixed schedule and after each software change. Without an owner, allowlists grow until they hide real activity. The owner should confirm which libraries are signed by approved publishers, which are built internally, and which are retired. Ask the SOC to report how many alerts each tuning change removes, so that suppressions can be audited. Common false positives arise when patch cycles or new application versions change library names or paths, so tie baseline review to change management records.

How to validate T1129 detections in a lab before production

This sequence proves that the T1129 Shared Modules detections fire on the expected telemetry, on each platform in scope, before any rule reaches production. It produces a documented record of coverage, alert latency and false positive behavior that the detection team can defend in review.

  1. Fix the scope and ATT&CK version

    The detection lead defines which platforms are in scope for T1129 (Linux, macOS and Windows), which sub-techniques and detection strategies are covered, and which Enterprise ATT&CK version the mapping targets. Record the version explicitly, because releases can rename, deprecate or revoke techniques and a mapping built on an older version may not match the current technique pages. The step is done when the scope document is approved and names the version in its header.

  2. Agree expected telemetry for each platform

    The detection engineers and platform owners list the data components the rules depend on, such as Process Creation (DC0032), Network Connection Creation (DC0082) and Network Traffic Content (DC0085), and confirm that each source is collected on every in-scope host. For each platform, they write down the events that should appear if the behavior occurs, the log source that carries them and the field names the rule expects. The step closes when a reviewer can trace each planned rule to a named telemetry source and confirm that the source is actually being forwarded to the SIEM in the lab.

  3. Prepare the range and baseline the logs

    The range team builds isolated lab hosts that mirror the production build, with the same agents, logging policy and time synchronization. They capture a baseline of normal activity for a set period so the detection team knows which benign module loads and network flows already occur. The step is complete when the baseline is stored, the log pipeline is confirmed end to end and the test window is recorded in the run log.

  4. Run the planned emulation with observers

    An authorized red team or emulation operator runs the agreed scenario against the lab hosts from a written plan, while the detection team watches the SIEM and the analysts log every observation with timestamps. The plan describes outcomes to produce, not exploit steps, and the operator stops at the boundary set in the rules of engagement. The step ends when the scenario is finished and the observers have confirmed that every planned action was executed or explicitly skipped.

  5. Record alerts, latency and false positives

    The detection team compares the planned events with what the SIEM actually received and records, for each rule, whether it fired, how long after the activity the alert appeared and which benign events also matched. They separate true positives, missed detections and noisy matches, and note any platform where the expected telemetry was absent. The step is done when a results table exists for every rule and platform, with each gap assigned to an owner.

  6. Tune rules and rerun the scenario

    Engineers adjust the rules that missed or over-matched, fix any collection gaps found in the telemetry review, and document each change against the ATT&CK version and detection strategy it implements. The same scenario is rerun on the lab hosts so the before and after results can be compared directly. The step closes when the rerun shows the intended change and no new false positives appear in the baseline window.

  7. Approve and archive the evidence

    The detection lead and the security owner review the results, decide which rules are cleared for production and which remain in a monitored state with known limits. The package includes the scope, telemetry inventory, run log, alert results, tuning changes and sign-off, stored so it can be reused in later reviews or assessments. The sequence is complete when the approval is recorded and the package is linked to the rule versions deployed to production.

Preventive controls that reduce T1129 exposure

Shared Modules abuse depends on an attacker getting a library loaded into a process that is trusted to run it. The controls below reduce that exposure by limiting what can execute, what can be loaded, and whether changes to those rules are visible. Each card names what the platform team must put in place and what to confirm with the endpoint vendor or in the client's own environment.

Execution prevention policy

ATT&CK maps mitigation Execution Prevention (M1038) to T1129 because it limits which binaries and libraries an endpoint will run at all. The platform team needs an allowlisting or trusted-execution policy that covers shared object and dynamic library loading, not only executables. Confirm with the endpoint vendor whether library loads are covered on Linux, macOS and Windows, and test the policy in audit mode before enforcing it, since legitimate software updates load modules too.

Behavior prevention on endpoints

Behavior Prevention on Endpoint (M1040) addresses T1129 by blocking suspicious actions, such as a process loading a module from an unusual path or a trusted process writing and then loading a new library. This control depends on the endpoint agent's rule set rather than file signatures. Ask the vendor which module load and process injection behaviors are covered, how alerts are routed, and whether blocking can be set per host group so that build servers and developer workstations are tuned separately.

Library path and loader hygiene

Many shared module abuses rely on library search paths that include writable or user-controlled directories. The platform team should review loader configuration, such as the Linux dynamic loader search settings and Windows DLL search order policies, and remove writable locations from trusted paths. Treat this as a configuration baseline that is checked on a schedule, and record exceptions with an owner and a review date.

Audit of configuration changes

Audit (M1047) is the control that shows whether the preventive settings above were changed. Enable logging for changes to execution policies, loader configuration and endpoint agent rules, and forward those logs to the central platform. Confirm with the team that owns the configuration whether change events are captured with the user, host and time, and whether the logs are retained long enough for an investigator to compare a current state against an earlier baseline.

Privileged change control

Changes to execution policy and library paths should require elevated rights that are granted through a controlled process. Use separate administrator accounts for endpoint policy management and restrict who can alter system library directories. Confirm which roles can edit allowlists in the endpoint console and whether approvals are recorded before a change goes live.

What SOC analysts do when a shared module alert fires

When a shared module alert fires, the first job is to confirm that the alert describes a module load that the host did not expect, not just a library that happens to be common. Pull the raw event for the host, the process that loaded the module and the module path, then compare them with the software inventory and the approved build for that role. On Windows, the relevant telemetry is usually the Process Creation and Module Load records, which should show which parent process started the loading process and which DLL or shared object it pulled in. On Linux and macOS, look for the equivalent process ancestry and the dynamic library path. Record the timestamp, user context and host identifier before anything else changes, so the investigation has a fixed starting point.

Next, establish where the module came from. Check the file origin (installer package, package manager, or a path that users can write to), the digital signature or package signature and whether it chains to a publisher your organization already trusts, and the file's creation and modification times relative to the process start. A module that appeared in a temporary or user-writable directory shortly before it was loaded deserves faster escalation than one that a patch management tool placed months earlier. Then scope the same module across the fleet by hash, path and signer, and treat any other host with the same artifact as part of the same case until it is cleared. If your Wazuh or Velociraptor deployment already collects loaded module inventories, use them for this sweep and confirm the collection scope with your endpoint team before relying on the result.

For containment, prefer the least disruptive option that stops further loading, such as isolating the host from the network while keeping the process running for memory capture, or blocking the module hash at the endpoint control. Before any change, use Velociraptor or an equivalent collection tool to preserve the module file, the process memory, relevant logs and the handling record, and keep a chain of custody. Escalate to incident response when the module is unsigned or signed by an unknown publisher and loaded by a privileged or server process, when the same artifact appears on several hosts, when the module shows outbound connections or credential access activity, or when a business owner cannot explain the software. Confirm the escalation thresholds and on-call paths with your incident response provider in advance, since they vary by organization and regulatory obligation.

Rehearsing T1129 detection in a private cyber range

On Linux, the range should include hosts where ordinary binaries, interpreters and services load shared objects, so defenders can learn what normal library loading looks like before judging any event as abnormal. Build a small fleet of Linux hosts across two or more distribution families, with a web tier, a build host and an administrative jump host, all inside the isolated range network. Forward process and audit telemetry to a Wazuh manager or Security Onion, and confirm that process records carry the executable path, parent process, user and arguments.

  • Range environment: a baseline period of normal package installs, application restarts and scheduled jobs, so the detection team can tune against expected library loads.
  • Telemetry pipeline to verify: Process Creation from the audit or endpoint agent, Module Load where the platform can produce it, Network Connection Creation from Zeek connection logs, and Network Traffic Content from Suricata or Zeek where traffic is unencrypted. Confirm clocks are synchronized across all sources.
  • Injects: facilitator-planned events such as a third-party library placed in an application directory, a shared object loaded from a path outside standard system locations, and an outbound connection from a service process to an approved test destination. Describe each inject in the runbook only in terms of the expected observable.
  • Good detection: an alert that ties the library path, loading process, user and parent process together, fires inside the agreed window, and opens a case with the raw events attached.
  • Good response: triage checks the library hash against an approved inventory, isolates the host if the module is unapproved, and preserves memory and file artifacts with Velociraptor before any cleanup.

Before reviewing any alert, confirm that every inject produced a raw event in the pipeline.

Questions SOC leads ask about detecting T1129

How do we baseline legitimate module loads before we alert on T1129?

Start by recording which processes normally load which shared modules on each platform, over a period long enough to cover patching, backups and scheduled jobs. Group the results by host role, such as developer workstations, build servers and domain controllers, because the normal set differs sharply between them. Keep the baseline in version control so changes to it are reviewed, and rebuild it after major software updates. Alerts should then fire on deviations from the role baseline, such as a module loaded from a user-writable path or by a process that never loaded it before, rather than on every module load. Expect the first tuning cycle to take longer than you planned, and confirm the approach with your own endpoint team before you commit to it.

Which telemetry gaps matter most for detecting shared module abuse?

The gaps that usually hurt most are missing module load events, missing process creation records with full command lines and parent process details, and missing network connection records that tie a process to a destination. Without module load telemetry, you cannot see which libraries a process pulled in, so the technique is largely invisible. Check three things in your own environment: whether your endpoint agent records module loads on Linux, macOS and Windows, whether file paths and hashes are captured with those events, and whether retention is long enough to investigate a slow intrusion. Confirm the exact data components your ATT&CK version references for T1129 before you write rules against them.

How do we confirm which ATT&CK version a detection rule maps to?

Record the ATT&CK version in the rule metadata itself, along with the technique ID and any sub-technique ID, so the mapping can be traced later. Techniques can be renamed, deprecated or revoked between releases, so a mapping that was correct for one version may need review for another. MITRE publishes each release on its updates pages and ships the content as STIX 2.1 bundles in the attack-stix-data repository, so you can check a rule's mapping against the bundle for the version you name. This project uses Enterprise ATT&CK version 20.0 as its reference point. Review the mapping whenever you move to a newer release.

How often should we re-validate a T1129 detection?

Re-validate on a fixed schedule and after any change that could alter the telemetry or the normal module set. Common triggers include a new operating system build, a change to the endpoint agent, a new engineering tool that loads libraries, a new ATT&CK release that touches the technique, and any tuning change that suppressed alerts. The schedule itself should be set by your risk owner and written into your detection management process, since the right interval depends on how often your estate changes. Keep a record of each validation run, including the date, the test scenario and whether the expected alert fired, because auditors and internal reviewers will ask for that evidence.

Can our own team run T1129 detection exercises without an outside partner?

Yes, many SOC teams run these exercises internally, provided they have a safe lab, a documented scope and someone accountable for the test plan. The main requirements are an isolated environment that mirrors your production telemetry pipeline, written rules of engagement, and a way to confirm that alerts reach the people who will respond. Where teams lack capacity or want an independent view of coverage, an outside partner can plan and run the exercise against a written scope. DeployOpen runs private cyber ranges and security testing, and that work is scoped and agreed in writing before it starts. Ask any provider to show how they separate exercise traffic from production systems.

Which Execution Prevention controls should we check alongside detection?

Execution Prevention is the ATT&CK mitigation most closely tied to this technique, so review what your endpoint platform can block, not only what it can alert on. Check whether your controls can restrict loading of libraries from untrusted or user-writable locations, whether they enforce code signing for approved software, and whether blocking policies are tested before they are enforced. Detection and prevention should complement each other: a detection tells you when a control was bypassed or never applied, and a prevention policy reduces how often you need to respond. Document which controls are in enforce mode, which are in audit mode and why, and review that list at each validation cycle.

Official ATT&CK sources for T1129 and Execution detections

Start every T1129 Shared Modules detection project at the official MITRE ATT&CK tactic page for Execution, which defines the tactic as the adversary trying to run malicious code or instructions on a system. The tactic page gives the context for why shared module loading sits under Execution, and it links to the technique and its sub-techniques. Record the ATT&CK version you target in every rule ticket, because the Execution tactic's technique list and detection guidance change between releases. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and any of them can rename, deprecate or revoke content that your rules depend on.

Next, pull the Enterprise 20.0 STIX bundle from the mitre-attack/attack-stix-data repository and check the T1129 entry directly. The bundle is the machine-readable form of ATT&CK, so it is the reliable place to confirm which detection strategies, analytics and data components the technique currently references, along with its platforms and mitigations such as Execution Prevention. Have an engineer load the bundle into a script or a local viewer and save the output with the date and version. Compare that record against the rule metadata in your SIEM before each release of your detection content, since a rule that cites a retired data component will silently stop matching what the framework now describes.

Treat the web pages and the bundle as the baseline, then confirm the remaining details with your own platform team. Ask MITRE's update notes and your telemetry vendors whether the data components named for T1129 are available on each operating system in scope, and confirm that your Linux, macOS and Windows collectors actually emit process, module load and network fields at the fidelity your analytics assume. Assign one owner to review the ATT&CK release notes whenever a new version ships and to schedule a mapping review in the change calendar. That owner should also sign off on any decision to retire a rule, so the evidence trail shows why coverage changed.

How DeployOpen builds T1129 detections and range exercises

DeployOpen works on T1129 Shared Modules as a fixed-scope engagement inside the client's own infrastructure, with the detection logic, test cases and evidence agreed in writing before work starts. The output is a detection set and a cyber range exercise that your team can rerun and maintain.

How we scope

  • Confirm which Linux, macOS and Windows hosts and log sources are in scope for shared module loading.
  • Agree the ATT&CK version the detection mappings target, since technique content can change between releases.
  • List the telemetry available for Process Creation, Network Connection Creation and Network Traffic Content, and any gaps.

How we build

  • Write detection logic in Sigma and map it to the Wazuh, Security Onion, Suricata or Zeek pipeline already in use.
  • Tune rules against benign module loading in your environment to reduce false positives before go-live.
  • Document how Execution Prevention and Behavior Prevention on Endpoint controls are configured for shared module activity.

How we hand over

  • Deliver rule sources, mappings to the ATT&CK version agreed, and configuration files under version control.
  • Provide a cyber range runbook that replays shared module scenarios and records which detections fired.
  • Hand over a written test report listing gaps, owners and the steps to close them.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after handover.
  • Review detections when ATT&CK releases rename, deprecate or revoke related technique content.
  • Rerun the range exercise after platform upgrades or changes to endpoint controls, and update the evidence.

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com