title: Shared Modules (T1129)
id: df00tech-t1129
status: experimental
description: "Adversaries may execute malicious payloads by loading shared modules into running processes. Shared modules are executable files (DLLs on Windows, .so on Linux, .dylib on macOS) loaded at runtime to provide reusable code or access OS API functions. Adversaries abuse this by loading malicious shared objects from arbitrary local paths or UNC network paths, allowing payload execution within the memory space of a legitimate host process. Windows uses LoadLibrary/LoadLibraryEx (via NTDLL.dll Native API), Linux uses dlopen/dlsym from dlfcn.h, and macOS uses both dlopen and Objective-C runtime calls. This technique enables modular malware architectures where the main dropper loads additional capability modules — seen in gh0st RAT, Astaroth, RotaJakiro, FoggyWeb, and BLINDINGCAN."
references:
  - https://attack.mitre.org/techniques/T1129/
  - https://df00tech.com/detections/T1129
author: df00tech
date: 2026/04/18
tags:
  - attack.t1129
# NOTE: logsource is auto-derived and may need adjustment for your environment
logsource:
  category: process_creation
  product: windows
detection:
  # This detection logic could not be auto-translated; see the KQL/SPL query on df00tech.
  selection:
    EventID: '*'
  condition: selection
falsepositives:
  - "Legitimate software installers temporarily staging DLLs in %TEMP% before moving them to installation directories"
  - "Developer tools (Visual Studio, JetBrains IDEs) loading debug or test assemblies from user-writable paths during development builds"
  - "Enterprise software with non-standard installation paths (e.g., installed to C:\\Tools or user home directories by portable apps)"
  - Security tools and EDR agents loading kernel modules or helper DLLs from non-standard paths during startup
  - "Virtualization software (VMware Tools, VirtualBox Guest Additions) loading drivers from paths outside System32"
level: high