Module Overloading: Full PE Image Placed Inside a Carrier DLL Mapping (Malware Development Technique, cocomelonc)

Key facts for Module overloading PE mapping

Detection coverage for Module overloading PE mapping

As of 2026-11-05, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5311 across Splunk SPL, Microsoft KQL and Sigma, covering 6 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Module Overloading Carrier DLL (WsmSvc.dll) Loaded by Unexpected Process

TL-2026-5311 Module Overloading (cocomelonc trick 68) maps the WsmSvc.dll carrier DLL as a SEC_IMAGE section and then overwrites its headers and sections with a full payload PE. WsmSvc.dll is the WinRM service DLL and is normally only loaded by service hosts, so any other process mapping it is a strong carrier indicator (T1620, T1055, T1129). Behaviour-first, no hash or filename of the payload required.

• Languages: Splunk SPL, Microsoft KQL, Sigma
• ATT&CK: T1620, T1055, T1129
• Data sources: sysmon:EventCode7, DeviceImageLoadEvents, windows_image_load
• Severity: medium
• Confidence: high

Splunk SPL

index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=7 ImageLoaded="*WsmSvc.dll" earliest=-24h
| eval proc=lower(mvindex(split(Image,"\\"),-1))
```exclude service hosts that legitimately load the WSMan service DLL```
| search NOT proc IN ("svchost.exe", "wsmprovhost.exe", "services.exe", "mmc.exe")
| stats count min(_time) as first_seen max(_time) as last_seen values(Image) as process values(ImageLoaded) as module values(Signed) as module_signed by host, User, ProcessGuid
| convert ctime(first_seen) ctime(last_seen)

Microsoft KQL

DeviceImageLoadEvents
| where Timestamp > ago(24h)
| where FileName =~ "WsmSvc.dll"
| where InitiatingProcessFileName !in~ ("svchost.exe", "wsmprovhost.exe", "services.exe", "mmc.exe")
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessCommandLine, FolderPath, SHA1
| order by Timestamp desc

Sigma

title: WsmSvc.dll Carrier Module Loaded by Unexpected Process (Module Overloading)
id: 7c3e5b1a-4d2f-4e8a-9b61-0a5f2c8d1e11
status: experimental
description: Detects WsmSvc.dll being mapped into a process other than the expected WinRM service hosts. Module overloading uses WsmSvc.dll as a carrier DLL whose SEC_IMAGE mapping is overwritten with a payload PE.
references:
  - https://cocomelonc.github.io/malware/2026/11/02/malware-tricks-68.html
  - https://attack.mitre.org/techniques/T1620/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-11-05
tags:
  - attack.defense-evasion
  - attack.t1620
  - attack.t1055
  - attack.execution
  - attack.t1129
logsource:
  category: image_load
  product: windows
detection:
  selection:
    ImageLoaded|endswith: '\WsmSvc.dll'
  filter_main_service_hosts:
    Image|endswith:
      - '\svchost.exe'
      - '\wsmprovhost.exe'
      - '\services.exe'
      - '\mmc.exe'
  condition: selection and not filter_main_service_hosts
falsepositives:
  - Administrative tooling or management agents that legitimately host the WSMan service DLL
  - Security products that scan or map system DLLs
level: medium

Known false positives:

• Security or backup agents that map system DLLs for scanning
• Administrative tooling that hosts WinRM components outside svchost.exe

Tuning notes: Baseline which processes load WsmSvc.dll in your estate for 14 days and extend the exclusion list with approved hosts. Confirm Sysmon image-load logging (EventCode 7) is not filtered for system DLLs in your Sysmon config.

• 🔒 [indicator] Loaded by Process Running From User-Writable Path · unlock with TL Creds
• 🔒 Carrier DLL Load Followed by Memory Protection Change Sequence · unlock with TL Creds
• 🔒 Process Loading [indicator] Carrier Spawns Shell or Recon Child Process · unlock with TL Creds
• 🔒 [indicator] Loaded From Non-System Location (Carrier Masquerade) · unlock with TL Creds
• 🔒 Windows Debugger or MinGW Cross-Compiler Tooling Execution (PoC Development) · unlock with TL Creds
• 🔒 [indicator] Loaded With Invalid or Missing Signature (Backing-File Mismatch) · unlock with TL Creds
• 🔒 Module Overloading PoC Artifacts (hack.exe / meow.dll) · unlock with TL Creds
• 🔒 [indicator] Carrier Load Followed by Outbound Network Activity (Same Process) · unlock with TL Creds

Indicators of compromise for Module overloading PE mapping

As of 2026-11-05, Threadlinqs Intelligence tracks 6 indicators of compromise for TL-2026-5311.

How Module overloading PE mapping works

The article explicitly distinguishes it from function stomping and module stomping. No CVE, in-the-wild use, malware family, or actor attribution is claimed.

On 2026-11-02, researcher cocomelonc (GitHub Pages blog) published 'Malware development trick 68: Module overloading. Simple C example,' the 68th entry in an ongoing malware-development-technique series, and the write-up was subsequently indexed as a library entry by Malpedia the same day. The technique, termed 'module overloading' by the author, differs from the two related in-memory execution tricks it is explicitly compared against: function stomping (overwriting a single function's bytes with shellcode) and module stomping, covered as 'trick 61' in the same series (overwriting only entry-point instructions with shellcode). Module overloading instead substitutes the ENTIRE mapped PE image — headers and all sections — of a legitimately loaded carrier DLL with a different, complete PE image (a full replacement DLL payload), then performs the bookkeeping a real loader would normally do: relocation fixups and import resolution.

Mechanically, the PoC (hack.c, roughly 500 lines) opens a payload DLL (meow.c, compiled separately) as raw file data via CreateFileW rather than loading it through the Windows loader. It then creates a SEC_IMAGE-flagged file mapping of the carrier DLL, Windows' WsmSvc.dll (Web Services Management Service, a legitimate, commonly present x64 system library chosen for its size and ubiquity), and maps a view of it via MapViewOfFile without ever allowing DllMain to run for the carrier. The mapped carrier view is then made writable with VirtualProtect, the payload's PE headers are copied to the mapped base, and each payload section is placed at its virtual address (not file offset) inside the carrier's reserved image space. Only IMAGE_REL_BASED_DIR64 relocations are supported, computed as (new base − payload's declared ImageBase); the implementation explicitly rejects TLS callbacks, delay-loaded imports, CLR/.NET payloads, load-config directories, and exception-registration tables, and caps payloads at 32 imported modules and 16 MiB. Imports are resolved via LoadLibraryA/GetProcAddress and written into IAT slots, each payload section's original (not the carrier's) protections are restored via VirtualProtect, FlushInstructionCache is called to maintain cache coherency, and the payload's own entry point is finally invoked with DLL_PROCESS_ATTACH — making the payload execute from memory that Windows and most tooling will still report as backed by the legitimate carrier file.

The researcher built and validated the PoC entirely from a Linux host using the MinGW-w64 cross-compiler (x86_64-w64-mingw32-gcc), targeting Windows x64 exclusively (enforced via preprocessor checks), and validated execution flow with the x64dbg debugger. The article includes an explicit defender/blue-team note: because VirtualQuery will still report the mapped region as MEM_IMAGE and GetMappedFileNameW will still resolve the backing file to the legitimate carrier (WsmSvc.dll), detection requires correlating the address that is executing, its reported mapping type, its reported backing file, and its ACTUAL in-memory byte content/PE header identity — a mismatch between the backing file's real on-disk signature and the executing memory's contents is the core indicator. No IOCs, hashes, malware family names, campaign activity, in-the-wild exploitation, or threat-actor attribution are stated anywhere in the source material; this is a defensive-research/red-team tradecraft publication, not an observed intrusion.

MITRE ATT&CK techniques by tactic:

Defense Evasion

T1027 Obfuscated Files or Information; T1036 Masquerading; T1036.005 Match Legitimate Resource Name or Location; T1055 Process Injection; T1055.012 Process Injection: Process Hollowing; T1620 Reflective Code Loading

Execution

T1129 Shared Modules

Resource Development

T1587.001 Develop Capabilities: Malware

Remediation for Module overloading PE mapping

Immediate actions

• Hunt for processes/regions where VirtualQuery reports MEM_IMAGE and GetMappedFileNameW resolves a legitimate system DLL (e.g. WsmSvc.dll), but the in-memory PE header/signature and section bytes do not match the actual on-disk content of that backing file.
• Alert on SEC_IMAGE-backed memory mappings that transition from their original protection to PAGE_READWRITE (VirtualProtect against an image-mapped region) immediately followed by a write and a second VirtualProtect call restoring executable protections — the write/re-protect/execute sequence described in the technique.

Workarounds

• Monitor for anomalous LoadLibraryA/GetProcAddress call bursts (resolving a distinct import set) occurring immediately after a writable-SEC_IMAGE-mapping event on a system DLL such as WsmSvc.dll, as this indicates import-table rebuilding consistent with module overloading rather than normal module loading.

Longer-term hardening

• Deploy EDR or memory-integrity tooling capable of hashing and comparing on-disk module bytes against the corresponding in-memory image-backed mapping for loaded system DLLs, to catch backing-file/content mismatches regardless of reported mapping type.
• Build behavioral detections around the full API sequence evidenced in the PoC: CreateFileMappingW(SEC_IMAGE) -> MapViewOfFile -> VirtualProtect(writable) -> content overwrite -> VirtualProtect(restore original protections) -> FlushInstructionCache -> entry-point invocation.

Affected and fixed versions

• Microsoft — Windows (x64)
  Vulnerable versions: Any Windows x64 build with WsmSvc.dll present

Timeline of Module overloading PE mapping

• 2026-09-23 cocomelonc publishes 'Malware analysis part 12: Section entropy detector in C,' a related defensive-tooling article in the same series.
• 2026-10-07 cocomelonc publishes 'Malware development trick 67: Run shellcode via CreateThreadpoolWait,' the immediately preceding technique in the series.
• 2026-11-02 Malpedia library indexes the trick-68 article as a reference entry under the Threadlinqs-monitored feed.
• 2026-11-02 cocomelonc publishes 'Malware development trick 68: Module overloading. Simple C example' on their GitHub Pages blog, introducing the module overloading technique with a working C PoC (meow.c payload / hack.c host).
• 2026-11-04 The Wayback Machine (web.archive.org) captures a snapshot of the trick-68 article, preserving the PoC write-up.
• 2026-11-05 Threadlinqs threat-hunting pipeline ingests the technique write-up for tracking as TL-2026-5311 based on its public-PoC-availability criterion.

Sources cited for Module overloading PE mapping

• Malpedia library entry: Malware development trick 68: Module overloading malpedia.caad.fkie.fraunhofer.de · Research · 2026-11-02
• Wayback Machine archive snapshot of trick 68 article web.archive.org · Research · 2026-11-04
• MITRE ATT&CK T1620 - Reflective Code Loading MITRE · Research
• MITRE ATT&CK T1055 - Process Injection MITRE · Research
• MITRE ATT&CK T1055.012 - Process Hollowing MITRE · Research
• MITRE ATT&CK T1027 - Obfuscated Files or Information MITRE · Research
• MITRE ATT&CK T1036.005 - Match Legitimate Name or Location MITRE · Research
• Malware development trick 68: Module overloading. Simple C example cocomelonc.github.io · Blog · 2026-11-02
• Malware development trick 67: Run shellcode via CreateThreadpoolWait cocomelonc.github.io · Blog · 2026-10-07
• Malware analysis part 12: Section entropy detector in C cocomelonc.github.io · Blog · 2026-09-23

More in threat intel

• Praetorian Brutus: Open-Source Multi-Protocol Credential Testing Engine Expands to 14 New Protocols with People Enumeration and Credential Persistence
• ARTEX AI-Powered Pentest Platform Abused for Autonomous Cybercrime Campaigns (Apple Certificates, Crypto Draining, Gaming Credentials)
• OpenAI releases GPT-6 Cyber, an offensive-capable AI model rated Critical under its Preparedness Framework
• OpenAI Finds GPT-6 Astra Covertly Underperforming on Safety Research and Exploit Tasks
• BOSSAI: AI-Augmented Multi-Agent Attack Campaign Exposes Taiwan Emergency Dispatch and Patient Records