PackMyPayload: Containerized MOTW Bypass and How to Detect It

Version 2.0 | Revised 2026-10-22 | Tier-1 Detection Engineering Standard

A deep technical analysis of container-based Mark-of-the-Web evasion, from OS kernel internals and source code mechanics to behavioral telemetry, temporal chain detection, evidence fusion triage, and production-ready Sigma rules.


Author	Siddhant Mishra, Bloo SpecterForce
Published	October 2026
MITRE ATT&CK	T1553.005, T1204.002, T1566.001, T1566.002, T1218.011, T1036.005, T1564.001
Classification	Purple Team Research // Initial Access

1. What is PackMyPayload

PackMyPayload is an open-source Python tool written by Mariusz Banach (mgeeky) of Binary Offensive. It takes a file or directory as input and packages it into a container format designed to strip or bypass the Windows Mark-of-the-Web (MOTW) flag from the enclosed payload.

The tool supports eight output formats:

Format	Strips MOTW?	Native Windows Support	Elevation Required	Key Detail
`ISO`	Yes	Yes (Win 8+)	No	Auto-mounts on double-click via explorer.exe
`IMG`	Yes	Yes (Win 8+)	No	Identical to ISO internally (pycdlib Joliet)
`VHD`	Yes	Yes	Yes (build-side)	Uses DISKPART to create; victim mounts natively via VirtDisk.dll
`VHDX`	Yes	Yes	Yes (build-side)	Same DISKPART flow as VHD for building
`ZIP`	Conditional	Yes	No	Sets read-only attr on Office files (CVE-2022-41091)
`7z`	Partial	No (needs 7-Zip)	No	MOTW stripped only on manual extraction
`CAB`	No	Yes	No	Requires additional user clicks
`PDF`	Depends	Yes	No	Embeds file + JS autorun; reader-dependent

Its core value proposition for red teams: it automates the creation of container files that exploit a fundamental gap in how Windows propagates trust metadata to inner files. This is not a vulnerability in the traditional sense; it is a design limitation in how NTFS Alternate Data Streams interact with non-NTFS-aware container formats.

2. The MOTW Mechanism and Why It Breaks

How MOTW Works

When a file is downloaded from the internet (or received via email, browser, etc.), MOTW-aware applications write an NTFS Alternate Data Stream (ADS) named Zone.Identifier to the file:

[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://example.com
HostUrl=https://example.com/malware.exe

ZoneId=3 marks the file as originating from the Internet zone. This triggers downstream security controls:

Windows Defender SmartScreen scans the file against reputation databases before execution
Microsoft Office Protected View opens MOTW-tagged documents in a sandboxed read-only mode
VBA Macro Blocking (post-Feb 2022) blocks macros entirely in MOTW-tagged Office documents

User-to-Kernel Boundary: How MOTW Gets Written and Why Containers Break It

Understanding the exact API boundary is essential for grasping why the bypass persists even after Microsoft's patches.

MOTW Write Path:

When a browser or email client downloads a file, it calls the COM interface IAttachmentExecute::Save() (implemented in shdocvw.dll / shell32.dll). This function writes the :Zone.Identifier:$DATA alternate data stream onto the target file. The ADS write is an NTFS-specific operation; it calls NtCreateFile with the stream name appended to the file path and writes the [ZoneTransfer] payload via NtWriteFile.

Container Mount Path:

When a user double-clicks an ISO/IMG, explorer.exe calls into VirtDisk.dll, which invokes OpenVirtualDisk() followed by AttachVirtualDisk(). These functions send IOCTL_STORAGE_DEPENDENCY_INFO to the vhdmp.sys kernel driver, which surfaces the container as a block device: either \Device\CdRom0 (for ISO/IMG, via cdfs.sys or udfs.sys) or \Device\HarddiskVolumeX (for VHD/VHDX, via fastfat.sys or ntfs.sys).

Why the Filesystem Matters:

The mounted volume's filesystem determines whether ADS can exist on its files:

Filesystem	Supports ADS?	Used By
NTFS	Yes	VHD/VHDX (if formatted NTFS)
FAT32	No	VHD/VHDX (PackMyPayload default)
Joliet (ISO 9660)	No	ISO/IMG
UDF	No	Some ISO/IMG

When the Filter Manager (FltMgr.sys) routes a query for :Zone.Identifier through cdfs.sys (Joliet) or fastfat.sys (FAT32), the filesystem driver returns STATUS_OBJECT_NAME_NOT_FOUND because ADS is not a concept these filesystems understand. The file simply has no Zone.Identifier; it was never tainted.

The November 2022 Patch (CVE-2022-41091) and Why PackMyPayload Still Bypasses

Microsoft's November 2022 Patch Tuesday (addressing CVE-2022-41091) introduced MOTW inheritance for container-extracted files. The Windows Shell (windows.storage.dll) now attempts in-memory MOTW propagation when extracting or mounting containers: if the container itself is MOTW-tagged, the Shell tries to apply the same Zone.Identifier to files accessed from within it.

Why PackMyPayload still works post-patch:

Joliet Level 3 (ISO/IMG): PackMyPayload forces iso.new(joliet=3). The Shell's MOTW inheritance logic targets UDF and NTFS-formatted containers. When cdfs.sys handles a Joliet filesystem, the in-memory inheritance path in windows.storage.dll does not engage for all access patterns, particularly when files are accessed via non-Shell code paths (e.g., CreateFileW directly, or LOLBin execution from a mounted path).
FAT32 (VHD/VHDX): PackMyPayload formats VHD volumes as FAT32 (format fs=FAT32). Since FAT32 physically cannot store ADS, even if the Shell writes MOTW metadata in memory, any downstream check that queries the filesystem for :Zone.Identifier gets STATUS_OBJECT_NAME_NOT_FOUND from fastfat.sys.
Non-Shell execution paths: The MOTW inheritance relies on the Windows Shell COM interfaces (IFileOperation, IAttachmentExecute). Direct execution via LOLBins (rundll32.exe, regsvr32.exe) or via LNK targets that bypass the Shell's file-operation pipeline do not benefit from the in-memory MOTW propagation.

BOTTOM LINE: The November 2022 patch reduced the attack surface but did not eliminate it. Any container using a non-NTFS filesystem, which includes PackMyPayload's default configurations for every format, still bypasses MOTW in practice.

3. Container Format Deep-Dive: What the Code Actually Does

Understanding the exact mechanics of each packing method is essential for building precise detections. Here's what the source code reveals.

ISO / IMG: `packIntoISO()`

Both ISO and IMG use the same code path via pycdlib, creating a Joliet (level 3) disc image. The tool also supports backdooring existing ISOs: extracting all files from an existing image, adding the payload, and reburning to a new ISO.

# From packager.py:960-968
iso = pycdlib.PyCdlib()
iso.new(joliet=3)

# Files are added with Joliet path notation
iso.add_file(infile, joliet_path=f'/{filename};1')

# Hidden files supported via --hide flag
iso.set_hidden(joliet_path=f'/{hideFile};1')

Detection significance: On Windows 8+, double-clicking an ISO triggers explorer.exe to auto-mount it as a virtual CD-ROM via VirtDisk.dll → vhdmp.sys. This mount event is logged in the Microsoft-Windows-VHDMP-Operational log. The hidden file attribute (--hide) means directory listings won't show the payload unless "Show hidden files" is enabled, an extra evasion layer.

Byte-level forensics: When iso.set_hidden() is called, pycdlib flips Bit 0 (0x01, the Existence bit) at Offset 25 (0x19) of the ISO 9660 Directory Record for that file. This is actionable for perimeter YARA rules: scanning for ISO files where any Directory Record has the Existence bit set at byte offset 0x19 from the record start identifies ISOs with hidden files, a strong indicator of weaponization.

VHD / VHDX: `packIntoVHD()` (Builder-Side Telemetry)

CRITICAL DISTINCTION BETWEEN BUILDER AND VICTIM TELEMETRY: The packIntoVHD() function runs on the attacker's payload-building machine when generating the VHD, not on the victim's endpoint when they double-click the delivered .vhd. On the victim machine, explorer.exe mounts the VHD natively via VirtDisk.dll → AttachVirtualDisk() → vhdmp.sys; no diskpart.exe is spawned. All DISKPART and PowerShell telemetry described below is attacker build-infrastructure / insider threat / post-exploitation staging telemetry.

This is the most operationally complex format. The tool shells out to diskpart.exe, a built-in Windows utility, using scripted command files:

# DISKPART script template (diskpart-create-vhd.txt)
create vdisk file=<<<FILE>>> type=expandable maximum=<<<SIZE_IN_MB>>>
select vdisk file=<<<FILE>>>
attach vdisk
clean
create partition primary
format fs=<<<FILESYSTEM>>>
list partition
assign letter=<<<DRIVE_LETTER>>>

The flow is: create VHD → attach → format (default FAT32) → assign drive letter → copy payload → detach. The tool also uses a PowerShell helper (Get-MountedVHDDrive) that queries Win32_DiskDrive via CIM for "Microsoft Virtual Disk" captions to find the mount point.

# From packager.py:186-205: shell execution
CREATE_NO_WINDOW = 0x08000000
proc = subprocess.Popen(
    cmd,
    shell=True,
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE,
    startupinfo=si,
    creationflags=CREATE_NO_WINDOW  # Hidden window!
)

BUILDER-SIDE TELEMETRY NOTE: The CREATE_NO_WINDOW flag (0x08000000) means the DISKPART process runs without a visible console. This is a behavioral indicator on the build machine; legitimate VHD creation tools typically show progress to the user. If you see this on an endpoint that is not an attacker staging system, it indicates insider threat or post-exploitation VHD weaponization.

Detection significance (builder-side): The VHD build path generates a rich telemetry trail on the build machine: diskpart.exe process creation with /s pointing to a temp file, powershell.exe spawning for drive letter discovery, VHDMP operational log events, and the FAT32 format operation.

Victim-side telemetry: On the victim endpoint, the only telemetry from a VHD double-click is the VHDMP-Operational mount event and subsequent process execution from the mounted volume. There is no diskpart.exe activity.

ZIP: `packIntoZIP()`

The ZIP handler includes a MOTW bypass specific to CVE-2022-41091: it sets the FILE_ATTRIBUTE_READONLY (0x1) flag on Office files inside the ZIP. When Windows Explorer extracts these files, the read-only attribute prevented the extractor from writing the Zone.Identifier ADS.

# From packager.py:394-395
basename = os.path.basename(infile)
zipAttribs[basename] = 0x1  # FILE_ATTRIBUTE_READONLY

The tool acknowledges this was patched: "ZIP Read-Only MOTW bypass was fixed in MS Office 365 2208+". The --zip-noreadonly flag disables this behavior. The tool also supports hidden file attributes (0x2) within ZIP entries and password-protected ZIP via pyminizip.

7z: `packInto7ZIP()`

The 7-Zip format uses py7zr.SevenZipFile to create archives. The MOTW bypass behavior here is partial and depends on extraction method:

# From packager.py:462-479
with py7zr.SevenZipFile(outfile, mode=mode, password=pwd) as container:
    with open(infile, 'rb') as f:
        container.write(infile, local_path or os.path.basename(infile))

Why 7z partially strips MOTW: The 7-Zip application (7zFM.exe / 7zG.exe) uses raw Win32 API calls, CreateFileW / WriteFile, to extract files. It does not use the Windows Shell IFileOperation or IAttachmentExecute COM interfaces. Since IAttachmentExecute::Save() is the mechanism that propagates Zone.Identifier from the archive to extracted files, 7-Zip's direct file I/O path skips MOTW propagation entirely during manual extraction.

However, if a user extracts using Windows Explorer's built-in ZIP handler (which does use the Shell COM interfaces), MOTW is propagated. This is why the table says "Partial"; it depends on the extraction tool, not the archive format.

Detection significance: Monitor for 7zFM.exe or 7zG.exe writing executable or LNK files (Sysmon EID 11) followed by execution of those files without a corresponding Zone.Identifier (Sysmon EID 15).

PDF: `packIntoPDF()`

The PDF handler embeds files as PDF attachments and injects JavaScript autorun that attempts to launch the embedded file upon opening:

# From packager.py:1165
autorunJs = f'this.exportDataObject({{ cName: "{fname}", nLaunch: 2 }});'
fw.addJS(autorunJs)

Adobe Acrobat Reader maintains an extension blacklist (defined in registry at HKLM\SOFTWARE\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown\cDefaultLaunchAttachmentPerms) that blocks execution of common executable types. However, the code notes: ".doc/.xls work like a charm"; macro-enabled Office documents can still be embedded and auto-launched.

CAB: `packIntoCAB()`

Cabinet files are created via the cabarchive Python library. While CAB doesn't strip MOTW, it supports backdooring existing cabinet files, a technique relevant for supply chain scenarios where legitimate CABs are modified.

4. The Attack Chain in the Wild

Kill Chain Flow

The typical kill chain using container-based MOTW bypass follows this pattern:

[01 DELIVERY]          [02 MOUNT]              [03 EXECUTE]             [04 PAYLOAD]
Phishing email or  --> User double-clicks;  --> Inner .lnk/.exe/.docm --> DLL sideload,
HTML smuggling         Windows auto-mounts     runs without MOTW         macro exec, or
delivers .iso/.img     as virtual drive        restrictions              direct shellcode
                                                                         (no SmartScreen)

The most common inner payload pattern observed across campaigns: a .lnk shortcut that invokes rundll32.exe or regsvr32.exe against a co-located DLL inside the container. The LNK provides social engineering cover (custom icon, misleading name) while the DLL carries the actual malware.

Forensic Artifacts in LNK Payloads

LNK files inside weaponized containers carry forensic gold that is often overlooked:

The LinkTrackerDataBlock (block signature 0xA0000003) inside the MS-SHLLINK binary structure contains:

MachineID: The NetBIOS name of the machine where the LNK was created: this is the threat actor's build machine hostname unless they scrub it.
MAC Address: The MAC address of the build machine's primary NIC, embedded in the DROID fields (specifically the DroidVolume and Droid GUID fields, which encode a MAC per RFC 4122 v1 UUID format).

Unless the attacker explicitly scrubs these fields (e.g., using tools like lnk-cleaner or building on a VM with randomized identifiers), every LNK payload leaks attribution-quality metadata about the build infrastructure. This is valuable for threat intelligence correlation: the same MachineID across campaigns ties them to a single build environment.

5. Threat Actor Adoption

Container-based MOTW bypass is not theoretical; it is a widely adopted initial access technique across the threat landscape.

Historical Genesis (2022–2023)

The technique saw peak adoption in 2022 immediately after Microsoft's VBA macro blocking announcement, as threat actors scrambled for alternative initial access methods. ISO + LNK became the de facto replacement for macro-laden Office documents.

Threat Actor / Malware	Container Format	Payload Pattern	Period
QakBot (QBot)	ISO → ZIP → ISO	LNK + DLL sideload via regsvr32	2022-2023
IcedID	ISO, IMG	LNK + renamed system binary + DLL	2022-2023
BumbleBee (TA578/TA579)	ISO	LNK + DLL, shared entry points across actors	2022-2023
Magniber Ransomware	ZIP (CVE-2022-41091)	Read-only JS files in ZIP	2022
APT29	ISO	LNK + DLL sideload	2022+
Emotet	ZIP (password), ISO	Macro-enabled Office docs	2022
Brute Ratel C4	ISO	Cobalt Strike-style payloads in ISO containers	2022+

2024–2026 Operations

The technique has evolved. While pure ISO delivery declined as Microsoft tightened Shell-level MOTW inheritance, threat actors adapted to new bypass vectors, including SmartScreen logic bugs, chained Internet Shortcut files, and HTML smuggling with DLL sideloading.

Threat Actor / Malware	Container / Bypass Format	Payload Pattern	Period
APT29 (Midnight Blizzard)	HTML smuggling → ISO/VHD; ZIP with DLL sideload	ROOTSAW dropper → WINELOADER backdoor via DLL sideload (wine.exe); 2025: GRAPELOADER replacing ROOTSAW as initial stage	2024-2025
DarkGate (MaaS)	`.url` → WebDAV → `.url` chain (CVE-2024-21412 SmartScreen bypass)	Fake software MSI installers via Google DoubleClick open redirects; no ISO/VHD required, SmartScreen logic bug bypasses MOTW via chained Internet Shortcut files	2024
Latrodectus (TA577/TA578)	HTML/PDF attachment → ISO; JS → WebDAV MSI	IcedID successor loader; hijacked email threads, oversized JS files invoking msiexec.exe from WebDAV shares, SEO poisoning with fake IRS sites	2024-2025
Pikabot	ISO, ZIP → ISO	QakBot successor; TA577 campaigns continuing the ISO + LNK + DLL pattern	2023-2024

EVOLUTION NOTE: DarkGate's exploitation of CVE-2024-21412 represents a significant evolution in MOTW bypass techniques. The bypass moved from container-filesystem gaps (ISO/VHD with non-NTFS filesystems) to SmartScreen logic bugs via chained .url Internet Shortcut files. This is a fundamentally different bypass vector that does not require ISO/VHD at all; it abuses the Windows URL handler to chain redirects that strip the MOTW check from the final payload. Microsoft patched CVE-2024-21412 in February 2024, but it demonstrates that MOTW bypass is a moving target requiring continuous detection engineering investment.

6. Telemetry Sources for Detection

There is no single log source that gives complete visibility into container-based MOTW bypass. Detection requires layering multiple telemetry sources and correlating across them.

Sysmon Event ID 11: FileCreate

Captures container files being written to disk. Critical for detecting the delivery phase:

Browser process (chrome.exe, msedge.exe, firefox.exe) writing .iso, .img, .vhd, .vhdx to user-writable directories
Outlook or email client writing container files to temp directories
Archive extraction tools writing container files from nested archives (ZIP → ISO chain)

Sysmon Event ID 15: FileCreateStreamHash

Logs the creation of NTFS ADS, including Zone.Identifier. This is the most direct MOTW telemetry. You can correlate: a container file receives a Zone.Identifier (it was downloaded), but files subsequently created from that container do not. The absence of a Zone.Identifier on a freshly created executable is the gap this technique exploits.

Microsoft-Windows-VHDMP-Operational Log

HIGH-VALUE, UNDERUTILIZED: This is the single most valuable log source for ISO/VHD mount detection, yet it is not forwarded by default in most SIEM configurations.

ETW Provider GUID: {E2816346-87F4-4F85-95C3-0C79409AA89D}

Key Event IDs:

Event ID	Description	Detection Value
1	Virtual disk mounted	Primary mount detection: contains full `VhdFileName` path
2	Virtual disk unmounted	Useful for session bracketing
12	Surface Virtual Disk: maps `VhdFileName` to kernel disk object	Maps the container file directly to `\Device\CdRom0` or `\Device\HarddiskVolumeX`; provides the kernel-level object path for correlation with process creation events

Example event structure:

Log:       Microsoft-Windows-VHDMP-Operational
Event ID:  1
Message:   "Virtual disk 'C:\Users\victim\Downloads\invoice.iso' was mounted."
Fields:    VhdFileName, RequestType

Microsoft-Windows-Partition/Diagnostic Log

Event ID 1006 logs the mounted filesystem type when a new volume is surfaced. This is a high-signal detection source:

A Msft Virtual Disk appearing with filesystem type FAT32 is anomalous in enterprise environments where VHDs are expected to use NTFS.
PackMyPayload defaults to format fs=FAT32, catching FAT32-formatted virtual disks arriving on endpoints is a strong indicator of weaponized VHDs.
Legitimate enterprise VHDs (Hyper-V, SCCM, WDS) are almost universally NTFS-formatted.

NOTE: This log channel requires explicit forwarding configuration. The provider GUID for Microsoft-Windows-Partition is {412BDFF2-A8C4-470D-8F33-63FE0D8C20E2} and the driver is partmgr.sys.

Sysmon Event ID 1: Process Creation

Captures process execution from mounted container paths. Key patterns:

Any process where Image or CurrentDirectory is on an unusual drive letter (not C:, D: for standard installs), a Volume GUID path (\\?\Volume{...}), or a device path (\Device\CdRom)
explorer.exe spawning child processes from a newly mounted drive
rundll32.exe or regsvr32.exe loading DLLs from container-mounted paths
Builder-side only: diskpart.exe process creation with /s parameter pointing to a temp file (VHD creation via PackMyPayload)

Sysmon Event ID 12/13: Registry Events

ISO mount operations leave registry traces. Recent ISO/IMG files appear in MRU (Most Recently Used) registry keys:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.iso

Windows Security Events 4663 and 4688

Event 4663 (Object Access): With "Audit Removable Storage" policy enabled, Event 4663 captures file access on mounted ISO/VHD volumes. The existing Sigma rule win_security_iso_mount (ID: 0248a7bc) uses this to detect ISO mount activity.

Event 4688 (Process Creation): With command-line auditing enabled, captures the same process creation data as Sysmon EID 1 but through the native Windows audit subsystem. Useful in environments without Sysmon.

Byte-Level Forensics for Perimeter Rules

ISO Hidden File Detection (YARA-applicable):

When PackMyPayload's --hide flag is used, pycdlib sets the Existence bit (Bit 0, value 0x01) at Offset 25 (0x19) of the ISO 9660 Directory Record for the target file. A perimeter YARA rule can scan inbound ISO files for any Directory Record where byte 0x19 (relative to the record start) has Bit 0 set: this indicates a hidden file within the ISO, which is a strong weaponization indicator since legitimate ISO images rarely use this flag.

DO NOT DEPLOY AS WRITTEN, PSEUDOCODE ONLY: The naive linear-scan form shown below (for any i in (0x8000 .. filesize) : (uint8(i + 0x19) & 0x01 == 0x01)) will match virtually every ISO because random data at that offset frequently has bit 0 set. This produces massive false-positive volume. Use it only as a conceptual illustration of the ISO 9660 field; do not paste it into a production YARA stack.

// PSEUDOCODE: illustration of the ISO 9660 Directory Record Existence bit
// Production deployment requires structured ISO parsing, not linear scanning
rule ISO_Hidden_File_Indicator_PSEUDOCODE {
    meta:
        description = "ILLUSTRATION ONLY: ISO 9660 Directory Record Existence bit"
        author = "Siddhant Mishra, Bloo SpecterForce"
        warning = "DO NOT DEPLOY: linear scan produces massive FP volume"
    condition:
        uint16(0x8000) == 0x0143 and  // CD001 magic at sector 16 (PVD)
        for any i in (0x8800 .. filesize) : (
            uint8(i + 0x19) & 0x01 == 0x01  // Existence bit: FP-prone linear scan
        )
}

Production approach, use structured parsing instead:

Perimeter: Use isoinfo -R -J -l (via sandbox analysis pipeline) or Python's pycdlib to iterate Directory Records programmatically and flag any file where the Existence bit is set via proper structural traversal.
File gateway (Zscaler/Netskope/Palo Alto): Deploy ISO content inspection as a sandbox step. The byte-level YARA approach is only safe inside a parser that has already resolved record boundaries.
Research-grade YARA: If committed to YARA, use the cuckoo module with a dynamic analysis layer, or write a dedicated YARA module in C that parses ISO 9660 Primary Volume Descriptor + Path Table + Directory Records with correct offsets.

Nothing in this section should ship to a production YARA stack without the structural wrapper.

7. Behavioral Detection Indicators

Moving beyond individual events, the highest-fidelity detections come from behavioral chains: sequences of events that represent the full attack pattern.

Victim-Side Chains

Chain 1: Download → Mount → Execute

Container File Downloaded and Mounted Within Short Time Window | Severity: HIGH | T1553.005

Logic: Browser process writes a file with container extension (Sysmon EID 11) → within 5 minutes, VHDMP Event ID 1 logs a mount for the same file path → within 2 minutes, a process is created (Sysmon EID 1) with CurrentDirectory on the newly mounted drive letter, Volume GUID path, or \Device\CdRom path.

Why it works: Legitimate ISO/VHD usage (OS installation, backup restore) rarely follows a browser download by immediate mount and execution. The time correlation dramatically reduces false positives.

Chain 2: Container → LNK → LOLBin

Shortcut File Execution from Mounted Drive Invoking LOLBin | Severity: HIGH | T1204.002

Logic: Sysmon EID 1 where ParentImage is explorer.exe AND (Image or OriginalFileName) matches a LOLBin (rundll32.exe / RUNDLL32.EXE, regsvr32.exe / REGSVR32.EXE, mshta.exe / MSHTA.EXE, wscript.exe / WSCRIPT.EXE, cscript.exe / CSCRIPT.EXE, cmd.exe / CMD.EXE, powershell.exe / POWERSHELL.EXE) AND (CommandLine references a non-standard drive letter [E-Z]:\, a Volume GUID path \\?\Volume{, or a device path \Device\CdRom; OR CurrentDirectory is on a non-standard drive letter).

Why it works: This is the exact inner-payload execution pattern used by QakBot, IcedID, and BumbleBee. Matching OriginalFileName catches renamed LOLBins, a technique IcedID specifically uses (renaming system binaries to evade image-name-based detections).

Chain 3: MOTW Absence on Executed Files

Executable Without Zone.Identifier in User-Writable Path | Severity: MEDIUM | T1553.005

Logic: Sysmon EID 1 (process creation) where the Image path is in a user-writable directory AND no corresponding Sysmon EID 15 (FileCreateStreamHash) exists for Zone.Identifier on that file AND the file was created within the last 10 minutes.

Why it works: Freshly created executables in user directories that lack MOTW are anomalous. This requires correlating EID 1 and EID 15 in your SIEM. The time window is tunable.

Adversary Infrastructure / Insider Threat Chain

Chain 4: DISKPART VHD Creation (Builder-Side Detection)

DISKPART Scripted VHD Creation with Hidden Window | Severity: HIGH | T1553.005

SCOPE: This chain fires on attacker build infrastructure, insider threat workstations, or post-exploitation staging systems, not victim endpoints. On victim endpoints, VHD mounting is handled natively by explorer.exe → VirtDisk.dll → vhdmp.sys without spawning diskpart.exe.

Logic: Sysmon EID 1 where Image ends in diskpart.exe AND CommandLine contains /s AND the script file path is in a temp directory (TEMP, TMP, AppData\Local\Temp). Bonus: parent process is python.exe or py.exe.

Why it works: PackMyPayload writes DISKPART command scripts to temp files and executes them with /s. Legitimate DISKPART usage via scripted temp files is extremely rare in user workstation contexts.

8. Detection Rules

8.1 Victim Initial Access Telemetry (Sigma)

Rule 1: ISO/IMG/VHD Mount from User Downloads

title: Container Image Mount from User Downloads Directory
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: >
  Detects mounting of ISO, IMG, VHD, or VHDX files located in typical
  download directories, indicating potential MOTW bypass via container
  file smuggling. Fires on victim endpoints.
references:
  - https://github.com/mgeeky/PackMyPayload
  - https://attack.mitre.org/techniques/T1553/005/
  - https://attack.mitre.org/detectionstrategies/DET0257/
author: Siddhant Mishra, Bloo SpecterForce
date: 2026-10-22
tags:
  - attack.defense_evasion
  - attack.t1553.005
  - attack.initial_access
  - attack.t1566.001
logsource:
  product: windows
  service: microsoft-windows-vhdmp-operational
detection:
  selection:
    EventID:
      - 1
      - 12
    VhdFileName|contains:
      - '\Downloads\'
      - '\Desktop\'
      - '\AppData\Local\Temp\'
      - '\Content.Outlook\'
    VhdFileName|endswith:
      - '.iso'
      - '.img'
      - '.vhd'
      - '.vhdx'
  condition: selection
falsepositives:
  - Legitimate OS image mounting for installation
  - IT admin mounting backup VHDs
level: high

Rule 2: Process Execution from Mounted Container Drive

title: Suspicious LOLBin Execution from Mounted Container Volume
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: >
  Detects execution of LOLBins (including renamed variants via OriginalFileName)
  with arguments or working directories referencing mounted container volumes.
  Covers non-standard drive letters (E-Z), Volume GUID paths, and device paths.
  Fires on victim endpoints during post-mount payload execution.
references:
  - https://attack.mitre.org/techniques/T1553/005/
  - https://attack.mitre.org/techniques/T1218/011/
author: Siddhant Mishra, Bloo SpecterForce
date: 2026-10-22
tags:
  - attack.defense_evasion
  - attack.t1553.005
  - attack.execution
  - attack.t1204.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_lolbin_image:
    Image|endswith:
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\mshta.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\cmd.exe'
      - '\powershell.exe'
    ParentImage|endswith: '\explorer.exe'
  selection_lolbin_renamed:
    OriginalFileName:
      - 'RUNDLL32.EXE'
      - 'REGSVR32.EXE'
      - 'MSHTA.EXE'
      - 'WSCRIPT.EXE'
      - 'CSCRIPT.EXE'
      - 'CMD.EXE'
      - 'POWERSHELL.EXE'
    ParentImage|endswith: '\explorer.exe'
  selection_cmdline_drive:
    CommandLine|re: '[\s"''][E-Z]:\\\\'
  selection_cmdline_volume:
    CommandLine|contains:
      - '\\?\Volume{'
      - '\Device\CdRom'
  selection_currentdir:
    CurrentDirectory|re: '^[E-Z]:\\\\'
  filter_known:
    CommandLine|contains:
      - 'setup.exe'
      - 'install'
  condition: (selection_lolbin_image or selection_lolbin_renamed) and (selection_cmdline_drive or selection_cmdline_volume or selection_currentdir) and not filter_known
falsepositives:
  - Legitimate software installation from mounted ISOs
  - Network drive-mapped applications
level: high

Rule 3: Container or Shortcut File Extracted from Archive

title: Container or Shortcut File Extracted from Archive
id: d4e5f6a7-b8c9-0123-defa-234567890123
status: experimental
description: >
  Detects archive extraction tools writing ISO, IMG, VHD, VHDX, or LNK
  files to disk. Commonly observed in multi-stage delivery where a ZIP
  contains an ISO which contains the payload. Fires on victim endpoints.
references:
  - https://detection.fyi/mbabinski/sigma-rules/2022_htmlsmuggling/2_win_susp_file_extraction/
author: Siddhant Mishra, Bloo SpecterForce (adapted from Micah Babinski)
date: 2026-10-22
tags:
  - attack.defense_evasion
  - attack.t1553.005
  - attack.initial_access
  - attack.t1566.001
logsource:
  category: file_event
  product: windows
detection:
  selection_process:
    Image|endswith:
      - '\explorer.exe'
      - '\7zFM.exe'
      - '\7zG.exe'
      - '\WinRAR.exe'
      - '\winzip32.exe'
  selection_file:
    TargetFilename|endswith:
      - '.iso'
      - '.img'
      - '.vhd'
      - '.vhdx'
      - '.lnk'
  condition: selection_process and selection_file
falsepositives:
  - Legitimate ISO distribution via ZIP archives
level: medium

8.2 Adversary Infrastructure Detection (Sigma)

SCOPE: This rule fires on attacker build infrastructure, insider threat workstations, or post-exploitation staging systems. On victim endpoints, VHD mounting is handled natively by explorer.exe → VirtDisk.dll → vhdmp.sys without spawning diskpart.exe.

Rule 4: DISKPART Scripted VHD Creation (Build Infrastructure)

title: DISKPART Scripted VHD Creation via Temp File (Build Infrastructure)
id: c3d4e5f6-a7b8-9012-cdef-123456789012
status: experimental
description: >
  Detects diskpart.exe being invoked with a script file (/s) located
  in a temporary directory. PackMyPayload and similar tools use this
  pattern to create VHD/VHDX container files programmatically on the
  attacker's build machine. This is NOT victim-side telemetry; on victim
  endpoints, VHD files are mounted natively by explorer.exe via VirtDisk.dll.
author: Siddhant Mishra, Bloo SpecterForce
date: 2026-10-22
tags:
  - attack.defense_evasion
  - attack.t1553.005
  - attack.resource_development
  - attack.t1587.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\diskpart.exe'
    CommandLine|contains: '/s'
  selection_temp:
    CommandLine|contains:
      - '\Temp\'
      - '\tmp'
      - '\AppData\Local\'
  condition: selection and selection_temp
falsepositives:
  - Automated disk management scripts in server environments
level: high

9. Detection Engineering Recommendations

Telemetry Prerequisites

Before any of these detections work, ensure you have the following telemetry flowing:

Source	Config Required	Priority
Sysmon EID 1 (Process Creation)	Sysmon installed with process creation logging	Critical
Sysmon EID 11 (FileCreate)	Filter for container extensions in user directories	Critical
Sysmon EID 15 (FileCreateStreamHash)	Zone.Identifier stream logging	High
VHDMP Operational	Enable and forward this non-default log channel	High
Partition/Diagnostic	Enable and forward for filesystem-type detection	High
Sysmon EID 12/13 (Registry)	MountPoints2 and RecentDocs key monitoring	Medium
Security 4663	Enable "Audit Removable Storage" policy	Medium
Security 4688	Enable command-line auditing in process creation events	Medium (Sysmon-less)

TELEMETRY GAP ALERT: The Microsoft-Windows-VHDMP-Operational and Microsoft-Windows-Partition/Diagnostic logs are not standard Application/System/Security logs. Most SIEM forwarders (Splunk UF, Elastic Agent, etc.) do not collect them by default. If you are not explicitly forwarding these channels, you have a blind spot on every ISO/IMG/VHD/VHDX mount event and filesystem-type indicator on your endpoints. See Appendix A for a Sysmon configuration snippet that covers the file-creation side.

Layered Detection Strategy

Don't rely on a single rule. Build a detection stack that covers each phase of the attack:

Delivery Detection: Container file creation (Sysmon EID 11) from browser/email processes in user directories
Mount Detection: VHDMP operational log events correlated with recently downloaded container files
Filesystem Anomaly: Partition/Diagnostic Event ID 1006 flagging FAT32-formatted virtual disks on endpoints
Execution Detection: Process creation from non-standard drive letters / Volume GUIDs, especially LOLBins (including renamed via OriginalFileName) with explorer.exe parent
Absence Detection: Newly executed files lacking Zone.Identifier (correlate EID 1 with the absence of a matching EID 15 within the lookback window, Section 7.1 Chain 3)
Build Infrastructure Detection: DISKPART scripted execution from temp paths (catches PackMyPayload VHD creation on staging systems)

Tuning Guidance

Time windows matter. The download-to-mount-to-execute chain typically completes in under 5 minutes. Wider windows increase false positives from legitimate ISO usage.
Drive letter filtering: Exclude your organization's standard drive letters (C:, D:, and any mapped network drives) from execution detections. Container mounts typically land on E: through Z:. Also watch for Volume GUID paths (\\?\Volume{...}) which appear when containers are mounted to NTFS folder junctions instead of drive letters.
Known-good exclusions: IT teams mounting ISOs for software deployment, backup admins working with VHDs, and developers using disk images should be baselined and excluded by user/machine pair, not by blanket file path exclusions.
Nested archive detection (ZIP → ISO) is high-fidelity. There is almost no legitimate reason for a ZIP archive downloaded from the internet to contain an ISO image.

Quantitative Alert Triage: Dempster–Shafer Evidence Fusion

In large enterprise environments where developers legitimately mount ISOs and extract .lnk files daily, firing standalone alerts on any single rule causes massive alert fatigue. A Dempster–Shafer evidence fusion model combines weak signals into a high-confidence composite score, enabling SOC analysts to prioritize effectively.

Individual Sensor Probability Masses:

Each detection sensor produces a Basic Probability Assignment (BPA) across three states: M (Malicious), B (Benign), and Θ (Uncertain / frame of discernment):

Sensor	Signal	m({M})	m({B})	m(Θ)
S₁	Archive extracts ISO/IMG/VHD (Rule 3)	0.55	0.15	0.30
S₂	VHDMP mount from `\Downloads\` (Rule 1)	0.50	0.20	0.30
S₃	FAT32 VHD / Hidden file attribute (Partition EID 1006)	0.75	0.05	0.20
S₄	Child process without EID 15 within 300s (absence correlation, Section 7.1 Chain 3)	0.85	0.03	0.12

Dempster's Rule of Combination:

For two independent sensors with BPAs m₁ and m₂, the combined mass is:

m₁₂(A) = [Σ m₁(B) · m₂(C)] / (1 - K)
          where B∩C = A

K = Σ m₁(B) · m₂(C)    (conflict coefficient, where B∩C = ∅)
    where B∩C = ∅

Worked Example: Combining S₁ ⊕ S₂

K = m₁(M)·m₂(B) + m₁(B)·m₂(M) = 0.55×0.20 + 0.15×0.50 = 0.185
1-K = 0.815

m₁₂(M) = [m₁(M)·m₂(M) + m₁(M)·m₂(Θ) + m₁(Θ)·m₂(M)] / 0.815
        = [0.275 + 0.165 + 0.150] / 0.815
        = 0.590 / 0.815 = 0.72

Bel({M}) after S₁ ⊕ S₂ ≈ 0.72

Adding S₄ (MOTW absence, the strongest single sensor):

S₁ ⊕ S₂ ⊕ S₄:  Bel({M}) ≈ 0.97

Operational Impact:

Combination	Bel({M})	Triage Action
S₁ alone	0.55	Suppress: below threshold
S₂ alone	0.50	Suppress: below threshold
S₁ ⊕ S₂	0.72	Queue for review
S₁ ⊕ S₂ ⊕ S₃	0.94	Auto-escalate
S₁ ⊕ S₂ ⊕ S₄	0.97	Auto-escalate + isolate

This model ensures that developers who legitimately extract ISOs (triggering S₁ alone at 0.55) don't generate escalations, while a download-mount-execute chain with MOTW absence (S₁ ⊕ S₂ ⊕ S₄ at 0.97) triggers immediate response.

Implementation: Most SIEM platforms support risk-based alerting (Splunk Risk Framework, Elastic Risk Score, or equivalent). Map each Sigma rule to its sensor's m({M}) value and configure composite scoring thresholds at 0.90 (auto-escalate) and 0.95 (auto-isolate).

10. Hardening and Mitigation

Block at the Perimeter

Email Gateway: Block or quarantine inbound emails containing ISO, IMG, VHD, VHDX attachments, or ZIP files containing them. These have near-zero legitimate business use in email.
Web Proxy: Block or alert on downloads of container file formats from uncategorized or newly registered domains.
Content Inspection: If your proxy supports it, inspect ZIP files for nested ISO/IMG/VHD content. Also scan ISO files for the hidden-file Existence bit (see Section 6.8).

Endpoint Hardening: Enterprise Controls

Primary: GPO Device Installation Restrictions (Recommended)

Block the PnP hardware IDs at the bus layer to prevent Windows from mounting ISO/VHD containers entirely:

Hardware ID	Effect
`SCSI\CdRomMsft____Virtual_DVD-ROM_`	Blocks ISO/IMG auto-mount
`SCSI\DiskMsft____Virtual_Disk____`	Blocks VHD/VHDX auto-mount

GPO Path: Computer Configuration → Administrative Templates → System → Device Installation → Device Installation Restrictions → Prevent installation of devices that match any of these device IDs

This is the most robust endpoint control because:

It operates at the kernel level (PnP Manager) and cannot be bypassed by user-space tools
It survives Windows updates (unlike registry-based file association changes)
It blocks both double-click mounting AND PowerShell Mount-DiskImage
It provides a Group Policy audit trail

Primary: Microsoft Defender ASR Rules

Deploy these specific Attack Surface Reduction rules:

ASR Rule GUID	Rule Name	Effect
`b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4`	Block untrusted and unsigned processes that run from USB	Blocks execution of unsigned binaries from mounted ISO/VHD volumes (treated as removable media)
`d4f940ab-401b-4efc-aadc-ad5f3c50688a`	Block all Office applications from creating child processes	Kills the PDF → embedded `.doc` → macro chain used by PackMyPayload's `packIntoPDF()`

Deploy in Audit mode first to baseline, then switch to Block after validating false positives.

Secondary: Registry File Association (Legacy / Defense-in-Depth)

CAVEAT: This approach gets overwritten by Windows feature updates, does not cover VHD/VHDX (only Windows.IsoFile, not Windows.VhdFile), and does not block PowerShell Mount-DiskImage. Use as a supplementary layer, not primary control.

:: Remove Windows.IsoFile default mount association
reg delete "HKCR\Windows.IsoFile\shell\mount" /f

Application Control

AppLocker or WDAC policies that restrict execution from non-standard drive letters effectively kill the entire ISO/VHD payload execution chain. Configure path rules to deny execution from E:\ through Z:\ and Volume GUID paths (\\?\Volume{*}), with explicit exceptions for IT-managed mounted media.

MITRE ATT&CK Mapping Summary

Technique	ID	Relevance
Subvert Trust Controls: Mark-of-the-Web Bypass	T1553.005	Primary technique: MOTW stripped via container format
User Execution: Malicious File	T1204.002	User double-clicks container, then inner payload
Phishing: Spearphishing Attachment	T1566.001	Delivery mechanism for container files
Phishing: Spearphishing Link	T1566.002	HTML smuggling delivers container via link
System Binary Proxy Execution: Rundll32	T1218.011	Common inner-payload execution via LNK → rundll32
Masquerading: Match Legitimate Name	T1036.005	LNK files disguised as documents/invoices; renamed LOLBins
Hide Artifacts: Hidden Files	T1564.001	PackMyPayload's `--hide` flag sets hidden attribute
Develop Capabilities: Malware	T1587.001	DISKPART-based VHD weaponization on build infrastructure

Appendix B: Known Evasions and Coverage Gaps

Honest accounting of what the detections in this guide do not catch. This section exists so SOC leads can plan compensating controls.

B.1 Modern MOTW Bypass Vectors Not Covered

Vector	CVE / Reference	Status in This Guide
Copy2Pwn via search-ms URI	CVE-2024-38213 (DarkGate, July 2024)	Not covered. The search-ms protocol handler returns remote WebDAV files to Explorer without MOTW. No detection logic added.
RAR/ZIP SMB credential leak via .library-ms	CVE-2025-24071	Not covered.
Internet Shortcut (.url) chain	CVE-2024-21412	Mentioned in Section 5.2 as evolution, but no detection rule.
MotW stripping via `Unblock-File`	Native PowerShell cmdlet	Not covered: add Sysmon EID 13 for `:Zone.Identifier:$DATA` stream deletion events.
MOTW policy tamper	`HKCU\...\Policies\Attachments\SaveZoneInformation = 1`	Not covered. Add Sysmon EID 13 selector.
AttachmentExecute whitelist tamper	`HKLM\...\AttachmentExecute\{clsid}`	Not covered.
MOTW stripping via `clearinetzoneinformation`	ADS removal via `Clear-Content -Stream`	Not covered.

B.2 Container Techniques Not Covered

Vector	Description	Status
IMG with MBR partition table	PackMyPayload supports but defender tooling rarely parses	Partial
VHDX with ReFS	Rare but possible	Not covered
UDF Bridge (ISO 9660 + UDF dual-fs)	Allows filesystem driver choice at mount	Not covered
Nested VHD-in-VHD	Second-stage mount from already-mounted volume	Not covered

B.3 Evasion of Rules in This Guide

Rule	Evasion
Rule 1 (VHDMP mount from `\Downloads\`)	Drop container to `\AppData\Roaming\` or user-created directory; path-based filter fails
Rule 2 (LOLBin from mounted drive)	Use `conhost.exe`, `svchost.exe` with crafted command line, or custom LOLBAS binary not in list; or OneNote/Teams COM for execution
Rule 3 (Archive extracts container)	Use .wim, .cab, or 7z Self-Extracting Archive (SFX) with embedded container
Rule 4 (DISKPART build-side)	Build on bare-metal physical machine without Sysmon, use `New-VHD` cmdlet instead of DISKPART, or use `Mount-DiskImage -PassThru`
Chain 1 (temporal 5m window, Section 7.1)	Delay execution via scheduled task; chain fires after window closes
Chain 3 (MOTW absence, Section 7.1)	Attacker writes decoy Zone.Identifier via `Set-Content -Stream Zone.Identifier -Value '[ZoneTransfer]\nZoneId=3'` on the dropped file to satisfy the absence correlation

B.4 Pre-Chain Attacks Not Addressed

EDR/Sysmon tampering before payload arrival (BYOVD like RTCore64.sys, GDrv.sys; service stop via SeDebugPrivilege; ETW provider patching)
Code signing certificate theft that would make dropped binaries pass WDAC "trust Microsoft + partner" policies
Supply chain compromise of IT management tools that routinely mount VHDs (compensating control: baseline per-user-per-machine VHD usage)

B.5 Compensating Controls for Residual Risk

Risk	Control
CVE-2024-38213 (search-ms)	GPO: Disable `search-ms:` protocol handler via `HKCR\search-ms` restrictions
Direct Mount-DiskImage	WDAC/AppLocker rule blocking `Mount-DiskImage` cmdlet in non-admin PowerShell
Decoy MOTW write	Add rule for `Set-Content -Stream Zone.Identifier` command line patterns (PowerShell EID 4104)
Scheduled-task delay	Expand temporal correlation windows to 1h for high-risk users; accept higher FP
EDR tampering	VulnerableDriverBlocklist enforcement + Microsoft Driver Block Rules (WDAC base policy)

Appendix A: Sysmon v15+ Configuration Snippet

The default SwiftOnSecurity Sysmon configuration misses several container file extensions. Add the following to your Sysmon config to ensure visibility into container file creation and Zone.Identifier propagation:

<!-- Sysmon v15+ Configuration Snippet: Container File Monitoring -->
<Sysmon schemaversion="4.90">
  <EventFiltering>

    <!-- EID 11: FileCreate - Container files in user-writable paths -->
    <FileCreate onmatch="include">
      <TargetFilename condition="end with">.iso</TargetFilename>
      <TargetFilename condition="end with">.img</TargetFilename>
      <TargetFilename condition="end with">.vhd</TargetFilename>
      <TargetFilename condition="end with">.vhdx</TargetFilename>
      <TargetFilename condition="end with">.7z</TargetFilename>
    </FileCreate>

    <!-- EID 15: FileCreateStreamHash - Zone.Identifier on containers and payloads -->
    <FileCreateStreamHash onmatch="include">
      <TargetFilename condition="end with">.iso</TargetFilename>
      <TargetFilename condition="end with">.img</TargetFilename>
      <TargetFilename condition="end with">.vhd</TargetFilename>
      <TargetFilename condition="end with">.vhdx</TargetFilename>
      <TargetFilename condition="end with">.7z</TargetFilename>
      <TargetFilename condition="end with">.exe</TargetFilename>
      <TargetFilename condition="end with">.dll</TargetFilename>
      <TargetFilename condition="end with">.lnk</TargetFilename>
    </FileCreateStreamHash>

  </EventFiltering>
</Sysmon>

Deployment notes:

Merge this into your existing Sysmon configuration; do not deploy it standalone as it will override all other filtering rules.
The EID 15 rules for .exe, .dll, and .lnk are deliberately broad to enable the MOTW absence detection described in Section 7.1 (Chain 3). If volume is a concern, scope by Image (process name) to focus on browser and archiver processes.
Test in audit/logging-only mode before production deployment to validate volume impact.

References

mgeeky/PackMyPayload: Source repository (Mariusz Banach / Binary Offensive)
MITRE ATT&CK T1553.005: Subvert Trust Controls: Mark-of-the-Web Bypass
MITRE DET0257: Detect MOTW Bypass via Container and Disk Image Files
Red Canary Threat Detection Report: Mark of the Web Bypass
Red Canary: Why so, ISO?: ISO files and MOTW explained
Sigma Rule: ISO/VHD/LNK Extraction: Micah Babinski
Velociraptor ISO Mount Detection: VHDMP Operational Log artifact
Blocking ISO Mounting: VHDMP detection and registry mitigations
Proofpoint: BumbleBee: ISO delivery by TA578/TA579
Proofpoint: Latrodectus: IcedID successor loader campaigns
Check Point: APT29 GRAPELOADER: Renewed phishing campaign against European diplomats
BleepingComputer: APT29 WINELOADER: WINELOADER targeting German political parties
Trend Micro: DarkGate CVE-2024-21412: SmartScreen bypass zero-day campaign
Elastic: MOTW Removal Detection: Prebuilt detection rule
Outflank: MOTW from a Red Team's Perspective: Original container bypass research (2020)
textslashplain: MOTW Additional Guidance: Post-patch MOTW inheritance behavior