Join our Newsletter — 33% off our NHI Course

How do attackers abuse hdiutil?

Attackers abuse hdiutil on macOS to mount, convert, create, or manipulate disk images that contain payloads. That can help deliver malware, hide content inside image files, or stage data for later execution. Defenders should monitor unexpected image mounts, suspicious source files, and archive or disk image activity tied to untrusted paths or network downloads.

How hdiutil Becomes an Attack Utility on macOS

hdiutil is a legitimate macOS disk image utility, so abuse usually looks like normal administration at first glance. Attackers use it to work with DMG or sparse image files, which lets them package payloads, unpack them later, or place malicious content behind a file type many users and tools trust. The core problem is not the binary itself, but the execution and file-handling path it creates.

That matters because disk image activity often sits in the same operational noise as installers, software updates, and file transfers. A suspicious mount or conversion can be the first visible step in a delivery chain, especially when the image originates from a browser download, email attachment, cloud share, or an unexpected temp directory.

Living off the Land Guide is relevant here because hdiutil fits the broader pattern of trusted utilities being repurposed for execution, staging, and concealment.

What Attackers Try to Achieve with Disk Images

Attackers commonly use hdiutil for three practical outcomes. First, they mount an image to make payloads appear as ordinary files on disk. Second, they create or convert image formats to move content through channels that inspect archives more readily than mounted volumes. Third, they use disk images as a staging container so that malicious files are only exposed after a deliberate mount step.

That staging pattern helps with delivery and with user deception. A DMG can contain a launcher, a disguised application bundle, or supporting files that look harmless until the image is opened. In some cases, the image is only the transport layer, and the real objective is to get the user or another process to execute content from the mounted volume.

The defender takeaway is that the mount event itself is part of the attack path. If the image file came from an untrusted source, the mount is not a benign admin action, even if the command syntax is valid.

CISA cyber threat advisories are a useful reference point for recognising how frequently attackers rely on trusted system features and normal-looking file activity to deliver malware.

How to Detect and Respond to Suspicious hdiutil Activity

Monitor for hdiutil executions that do not fit normal software deployment patterns, especially when the source path is in Downloads, temp folders, mounted network locations, or browser cache locations. A second signal is image activity followed by execution from the mounted volume, because that often means the disk image was not just opened for inspection but used as a delivery mechanism.

Also look for unusual parent processes, such as Office apps, scripting hosts, browsers, chat clients, or archive utilities spawning hdiutil. Those parent-child relationships are often more telling than the command line alone. If the image is served from a remote host or arrives through a newly created file path, treat the event as a candidate intrusion chain rather than routine file handling.

MITRE ATT&CK Enterprise Matrix helps map the surrounding behaviour, especially file-based delivery, user execution, and follow-on payload staging after initial access.

Risk and Threat Considerations

Disk images are attractive to attackers because they combine packaging, concealment, and user trust in one object. If a security stack focuses only on executable files, a malicious DMG can bypass the earliest layers of scrutiny and shift the dangerous step to the mount or launch stage.

Failure mechanism: The attacker delivers a disk image that looks routine, then uses hdiutil or the mounted volume to expose payloads, bypass file-based suspicion, and create an execution path from a trusted-looking container.

Impact: That can enable malware delivery, staged persistence, or secondary execution from paths that users and some controls treat as low risk, especially when the image is opened from an untrusted download source.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
MITRE ATT&CK T1204 — User Execution hdiutil abuse depends on opening or mounting a user-delivered image.
T1105 — Ingress Tool Transfer Disk images can be used to stage and deliver payloads onto the endpoint.
Recommendation — Correlate suspicious image mounts with user-execution chains and isolate the originating host. Inspect download-to-mount paths and block untrusted image sources at the perimeter.
CIS Controls v8 CIS-10 — Data Recovery and Backup Processes Disk-image abuse often rides on file handling and restoration workflows that need visibility.
Recommendation — Log and review disk-image handling activity on endpoints and alert on anomalous mounts.

Practitioner Guidance

What to verify: Check whether the image came from an expected software workflow before treating the mount as benign. A signed installer, a managed software distribution path, and a known vendor location are materially different from an ad hoc DMG downloaded from the internet.

What to measure: Track image mounts, image conversions, and post-mount executions as a single chain. The useful signal is not just that hdiutil ran, but that a new volume appeared and was followed by file creation or process launch from that volume.

Common mistake: Teams often alert only on obvious malware names or executable launches and miss the disk image that delivered them. If you only inspect the payload after it runs, you lose the best opportunity to confirm the source and the staging path.

Practitioner takeaway: Treat suspicious disk image activity as an execution precursor, not a file-management detail, and investigate the mount source before you investigate the payload.