The Art of Mac Malware — Notes & Labs

This page is my working notes through The Art of Mac Malware by Patrick Wardle — but before the chapter notes, a proper foundation: what malware analysis is, why macOS specifically, how the security model works, and how to get started yourself.

What is malware?

#

Malware (malicious software) is any program that does something the user didn’t consent to, on behalf of someone else. That definition is intentionally broad, because malware covers a huge range of behaviour:

• Ransomware — encrypts your files and demands payment for the key
• Spyware / RATs — records your screen, keystrokes, or camera and exfiltrates the data
• Adware — injects ads or redirects your browser to generate revenue
• Backdoors — open a persistent, hidden channel for remote access to your machine
• Infostealers — harvest credentials, cookies, and crypto wallets
• Rootkits — embed deep in the OS (sometimes the kernel) to hide their own presence

A single piece of malware often combines multiple of these. A dropper downloads and installs other payloads. A loader decrypts and executes malware in memory without writing it to disk.

What is malware analysis?

#

Malware analysis is the process of taking a piece of malicious software and figuring out exactly what it does — how it works, what systems it targets, what data it steals, and how to detect or stop it.

There are two fundamental approaches, and they complement each other.

Static analysis

#

Static analysis means examining the file without executing it. You’re reading the code and data as a document, not running it.

What you look for:

• Strings — URLs, file paths, registry keys, error messages embedded in the binary
• Imports — which system functions the binary calls (tells you capabilities at a high level)
• File structure — how the binary is organised, whether it’s packed or obfuscated
• Code logic — disassembling machine code back to assembly or decompiling to pseudocode

Tools for static analysis:

• strings — extracts readable text from any file
• file — identifies file type from magic bytes, not extension
• otool -L — on macOS, lists shared libraries the binary links against
• nm — lists symbols (function/variable names) in a binary
• class-dump — recovers Objective-C class structure from a macOS binary
• Hopper / Ghidra / Binary Ninja — full disassemblers and decompilers

Static analysis is safe — you’re just reading. But sophisticated malware is often packed or obfuscated: the real code is encrypted inside a loader that decrypts and runs it at runtime. Static analysis hits a wall at obfuscation; dynamic analysis continues past it.

Dynamic analysis

#

Dynamic analysis means actually running the malware in a controlled environment and observing what it does.

What you observe:

• File system activity — what files does it create, modify, or delete?
• Network traffic — what does it connect to? What data does it send?
• Process activity — what processes does it spawn? What does it inject into?
• System calls — every interaction with the OS kernel is a system call — logging these shows exactly what the malware is doing at the lowest level

Tools for dynamic analysis on macOS:

• LLDB — the macOS debugger; attach to a running process, set breakpoints, inspect memory
• dtrace / fs_usage / opensnoop — trace file system and system call activity
• Wireshark / mitmproxy — capture and inspect network traffic
• Process Monitor (Objective-See) — GUI tool showing process activity in real time
• Netiquette (Objective-See) — shows active network connections per process

Dynamic analysis requires isolation. You run malware in a virtual machine — a sandboxed environment where it can’t affect your real system. Snapshots let you restore to a clean state between runs. The malware executes thinking it’s on a real machine, and you watch everything it does.

Why macOS specifically?

#

For years, macOS had a reputation for being more secure than Windows. That reputation was partly earned and partly mythology — Mac users historically were fewer and less valuable targets, so attackers focused elsewhere. That’s changed.

Apple Silicon, growing enterprise Mac adoption, and macOS’s access to valuable credentials (iCloud, Apple ID, crypto wallets) have made it an increasingly attractive target. macOS-specific malware families now number in the hundreds.

There’s also a skills gap. Windows malware analysis is well-documented and well-tooled. macOS analysis has fewer practitioners, fewer tools, and less documentation. That scarcity makes it more valuable to understand.

The macOS security model

#

To understand how malware works on macOS, you have to understand what it’s working against — the defensive layers Apple has built in.

Gatekeeper

#

Gatekeeper checks every application before it first runs. It verifies that the app is signed with a valid Apple Developer certificate and, for apps downloaded from the internet, that it has been notarised — scanned by Apple’s automated system and approved.

Malware bypasses this by:

• Exploiting bugs in Gatekeeper itself
• Social engineering users into explicitly overriding it
• Abusing legitimate developer accounts to sign malicious code
• Targeting the period between download and first run

System Integrity Protection (SIP)

#

SIP restricts what even root can do. Certain directories (/System, /usr, /bin, /sbin) and kernel-level operations are protected even from the superuser. You cannot modify these without booting into recovery mode and explicitly disabling SIP.

SIP exists because malware historically escalated to root and then modified core system files to persist. SIP makes that category of persistence much harder.

Transparency, Consent, and Control (TCC)

#

TCC is the permissions database you see when an app asks for access to your camera, microphone, contacts, or files. Apps must declare what they need and users must explicitly grant it.

Malware targeting sensitive data must either get the user to grant permissions, exploit a TCC bypass vulnerability, or abuse an app that already has permissions.

The sandbox

#

Sandboxed apps (all Mac App Store apps, and many third-party apps) run in an isolated environment. They can only access files, network resources, and hardware capabilities explicitly declared in their entitlements. A sandboxed app cannot read another app’s data.

Notarisation

#

Before distributing outside the App Store, developers submit their apps to Apple’s notarisation service. Apple’s systems scan for known malware and obvious bad behaviour. Apps that pass get a notarisation ticket embedded in them — Gatekeeper checks for this ticket.

Persistence: how malware survives reboots

#

Most malware wants to survive reboots. The process of establishing a presence that persists across restarts is called persistence.

macOS has several legitimate mechanisms for launching software at startup — malware abuses all of them:

Launch Agents / Launch Daemons: Property list files (.plist) in specific directories that tell the OS to run a command at login or boot. The distinction: Launch Agents run in the user’s context (login), Launch Daemons run as root (boot).

~/Library/LaunchAgents/       ← user-level, runs at login
/Library/LaunchAgents/        ← all users, runs at login
/Library/LaunchDaemons/       ← root, runs at boot

A malicious LaunchAgent plist:

<key>ProgramArguments</key>
<array>
    <string>/Users/victim/.hidden/malware</string>
</array>
<key>RunAtLoad</key>
<true/>

Login Items: Applications added to System Settings → General → Login Items. Legitimate, visible, but abused.

Cron jobs: The Unix task scheduler. Malware can add cron entries to run at intervals.

Understanding these persistence mechanisms is the foundation of both writing detections and understanding what a malware sample is doing when you see it create files in these locations.

The book: The Art of Mac Malware

#

Patrick Wardle is the foremost researcher in macOS security. He’s the founder of Objective-See (free, open-source macOS security tools), a former NSA analyst, and has discovered and presented dozens of macOS vulnerabilities and malware families.

The book covers:

• File formats — Mach-O, the macOS executable format; how the kernel loads and runs programs
• Static analysis techniques — disassembly, decompilation, code analysis
• Dynamic analysis techniques — debugging, tracing, monitoring
• Persistence mechanisms — every way malware survives reboots on macOS
• Code injection and process manipulation — how malware injects into other processes
• Network-based malware — how command and control (C2) infrastructure works
• Rootkits and kernel extensions — the deepest, hardest-to-detect category
• Detection and defensive techniques — how to build tooling that catches these behaviours

The book is freely available at taomm.org. There’s no reason not to read it.

Getting started yourself

#

Install the free tools:

• Objective-See tools — free macOS security tools (Process Monitor, KnockKnock, Netiquette, and more)
• Ghidra — free, open-source reverse engineering tool from the NSA
• Hopper — macOS-native disassembler (paid, but better UX than Ghidra for Mac binaries)

Set up a VM: Download UTM (free) or VMware Fusion (free for personal use). Create a macOS VM. Take a snapshot of the clean state before doing any analysis. Restore from the snapshot between runs.

Your first sample: MalwareTraffic Analysis and VirusTotal are good sources for real samples once you’re set up in a VM. Start by running strings and file on a binary before executing anything.

# Basic static analysis workflow
file suspicious_binary          # what is it?
strings suspicious_binary       # what readable content does it have?
otool -L suspicious_binary      # what libraries does it use?

Notes and labs

#

Chapter writeups appear below as I work through the book. Each one covers the core concepts from the chapter, anything that surprised me, and practical lab exercises.

In progress — writeups added chapter by chapter.