How do attackers abuse diskutil?

How attackers use diskutil to work with disks and mounted volumes

On macOS, diskutil is a legitimate administrative utility for inspecting disks, volumes, partitions, and mount state. Attackers abuse that normal capability to learn how storage is laid out, confirm which volumes are mounted, and identify places where they can stage tools or data without needing a custom binary.

That makes diskutil useful in post-compromise tradecraft because it blends into routine system administration. A command that enumerates disks or changes volume state can look ordinary unless defenders compare it with the user, session, and host context in which it ran.

Where this matters most is not the command itself, but the sequence around it. Attackers often pair storage inspection with file discovery, mount manipulation, or follow-on actions on external, removable, or network-backed volumes, which can help them move data, hide artifacts, or prepare persistence on a compromised endpoint.

What the abuse looks like in practice

Abuse usually starts with discovery. An attacker may query available disks, check volume identifiers, review mount points, or look for removable media and encrypted containers. That gives them a quick map of the host and helps them decide where to write files, what to tamper with, and whether a volume change is likely to attract attention.

It can also support staging. If an attacker can create, mount, rename, or remount storage in a way that is operationally valid but unusual for the user, they may place tools or payloads where casual inspection is less likely to notice them. On managed hosts, that can be combined with other dual-use utilities to keep activity looking like routine administration rather than intrusion activity. NHIMG’s Living off the Land Guide is useful background here because the same defender logic applies to many legitimate binaries that can be repurposed during an intrusion.

diskutil can also help an intruder manipulate storage state during persistence or cleanup. Changing what is mounted, when it is mounted, or how a volume is presented can affect visibility, script execution paths, and where evidence lands on disk. Even when the command is not the persistence mechanism itself, it can still support the access path an attacker is building.

What defenders should look for around diskutil abuse

The most useful signal is not “diskutil ran” on its own, but “diskutil ran in a context that does not fit the user, device role, or time of day.” Administrative storage work from a standard user session, especially if it is followed by unusual file creation or mount changes, deserves attention.

Review whether the command was launched from interactive shells, scripts, remote administration sessions, or post-exploitation tooling. Also compare the command line against expected help-desk, imaging, backup, or endpoint-management activity. If the host has no clear administrative task in progress, the same command can shift from benign to suspicious very quickly.

Changes to mounted volumes are especially important when they affect removable storage, external drives, disk images, or volumes that were not previously present. Watch for short-lived mounts, unexpected remounts, and storage actions that align with later process execution or data access. MITRE ATT&CK’s MITRE ATT&CK Enterprise Matrix is a strong companion reference for mapping that kind of post-compromise behavior to broader adversary technique patterns.

Risk and Threat Considerations

diskutil abuse is risky because it turns a normal macOS administration tool into a stealthy way to discover storage, prepare staging areas, and manipulate where data or tools reside. That can reduce the visibility of malicious activity and make it easier for an intruder to work inside trusted system boundaries.

Failure mechanism: The attacker relies on legitimate storage-management behavior to blend in, then uses mount-state changes, volume discovery, or disk-image handling to support staging, persistence, or concealment without introducing an obviously malicious executable.

Impact: Defenders may miss early signs of compromise, lose track of where tools or exfiltrated data were placed, or fail to notice that storage changes were part of a larger intrusion chain. If mounted volumes are abused, the attacker may also gain a cleaner path for moving data or preserving access across reboots and sessions.

Practitioner Guidance

What to verify: Confirm whether the disk-related action matches a known administrative task, approved script, or managed endpoint workflow. If it does not, treat the session as suspicious until you can tie the command to a legitimate operator and ticket.

Decision rule: If diskutil activity is paired with unexpected mount changes, unusual volume creation, or file access from a non-standard user context, prioritize compromise assessment over simple command-line review. The storage action may be the enabling step, not the end goal.

What practitioners underestimate: Legitimate utilities often matter because they sit at the boundary between discovery and persistence. diskutil rarely looks alarming by itself, but on an already-compromised macOS host it can be part of a low-noise sequence that changes where evidence lives and how long access lasts.

Practitioner takeaway: Focus on the surrounding context, user, and mount-state changes, not just the command name, because that is what separates routine storage administration from attacker tradecraft.

Related resources from NHI Mgmt Group

• What is the difference between prompt injection risk and identity abuse in agents?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• What does AI model abuse reveal about the current NHI threat surface?
• Why is the abuse of NHIs a priority for security teams?