macOS Malware Analysis - Part 1: Understanding Mach-O

If you are coming from Windows malware analysis, your muscle memory is tuned to Portable Executable (PE) headers, DOS stubs, import address tables (IAT), and Registry persistence.

When pivoting to macOS, that entire mental model changes. macOS does not use PEs or the Windows Registry. Instead, compiled executables run on the Mach-O (Mach Object) file format, interact with Apple’s dynamic linker (dyld), and leverage Mach kernel primitives and Darwin POSIX subsystems.

In this beginner-focused series, we won't get lost in abstract documentation. We are going to explore macOS internals hands-on by dissecting an actual malware sample from the wild: the second-stage payload from the RustBucket campaign (attributed to BlueNorOff).

1. Introduction & Lab Setup

Before touching live malware, ensure you are analyzing inside an isolated macOS virtual machine (such as a local VM with networking disabled).

Sample Details

Essential Toolkit

For this post, we will rely primarily on standard macOS command-line utilities bundled with Apple's Command Line Tools (xcode-select --install):

Figure: How a macOS Binary Runs Click to zoom ↗

How a macOS Binary Runs

2. Mach-O Architecture & The Universal (Fat) Binary

On Windows, an executable target is strictly one architecture (a 64-bit PE cannot natively house both x86_64 and ARM64 code).

macOS solves multi-architecture support using Universal Binaries (historically called "Fat Binaries"). A Universal Binary is simply an archive wrapper that bundles multiple architecture-specific Mach-O slices into a single file.

Figure: macho fat binary structure Click to zoom ↗

macho fat binary structure

When an analyst double-clicks an application, the macOS dynamic loader inspects the Fat Header:

Architecture Identification Cheat Sheet

Keep these magic bytes and CPU constants handy:

Hands-on Triage: Inspecting Our Specimen (.pd)

Let’s point our CLI tools at our RustBucket specimen to inspect its architecture.

Step 1: Check File Type and Slices

file .pd

Figure: file command output Click to zoom ↗

file command output

Breaking Down the Output

This single line tells us crucial details about the target:

Step 2: Peeking at the Universal (Fat) Header

Because our sample is a multi-architecture file, it doesn't start directly with raw assembly code or segment definitions. Instead, the file begins with a Fat Header—a small container directory that tells the macOS dynamic linker (dyld) where each architecture slice lives inside the file.

We can view the raw container breakdown using Apple's object file displaying tool, otool:

otool -f .pd

Figure: otool -f .pd output Click to zoom ↗

otool -f .pd output

Deconstructing the Output

Every field here serves a specific purpose in macOS execution:

Now look closely at the two architecture records:

Step 3: Splitting the Universal Container with lipo

When performing static reverse engineering in tools like Ghidra, IDA Pro, or Hopper, loading a multi-architecture binary often prompts you to choose one specific architecture to decompile. On the command line, parsing commands against a Fat binary can clutter your output by printing duplicates for every single architecture slice.

To keep our analysis clean and controlled, we use lipo - macOS’s native utility for manipulating Universal Binaries—to carve each architecture into its own standalone Mach-O file.

lipo .pd -thin x86_64 -output pd_x86 && lipo .pd -thin arm64 -output pd_arm64 && file pd_x86 pd_arm64

Figure: splitting the fat binary using lipo command Click to zoom ↗

splitting the fat binary using lipo command

What Changed Under the Hood?

By "thinning" the binary:

Step 4: Dissecting the Native Mach-O Headers

Now that both slices are separated, each file starts directly at offset 0x00 with a standard mach_header_64 structure (defined in <mach-o/loader.h>).

Let's inspect the headers of both slices side-by-side:

otool -h pd_x86 pd_arm64

Figure: otool output of both the binaries Click to zoom ↗

otool output of both the binaries

Decoding the Header Fields

Demystifying the flags Bitmask (0x00200085)

The flags tell us how the macOS kernel and dyld will treat this binary in memory:

For our next step, we need to inspect the Load Commands to see why ARM64 has 28 commands while x86_64 has 27, and how memory segments are mapped.

Figure: **Understanding Mach-O Headers** Click to zoom ↗

Understanding Mach-O Headers

Step 5: The Execution Blueprint - Load Commands

If the Mach header is the identity badge of the binary, the Load Commands are the execution blueprint. Immediately following the header, they tell the kernel and the dynamic linker (dyld):

Let's list the first 15 load commands of the pd_x86 slice using otool -l:

otool -l pd_x86 | grep "cmd " | head -n 15

Figure: terminal output Click to zoom ↗

terminal output

What These Commands Instruct the System to Do

Now let's run the exact same command on the ARM64 slice to spot the architectural differences:

Step 6: Architectural Differences in Load Commands (x8664 vs. ARM64)

Now let's inspect the first 15 load commands of the pd_arm64 slice:

otool -l pd_arm64 | grep "cmd " | head -n 15

Figure: Screenshot 2026-09-03 at 9.22.55 PM.png Click to zoom ↗

Step 7: Anatomy of Mach-O Segments

In Mach-O, a Segment is a high-level container that the kernel maps into virtual memory with a specific page protection (rwx). Inside segments reside individual Sections, which hold the actual instructions, constants, and pointers.

Let's inspect the segments declared in each slice:

otool -l pd_x86 | grep -E "(cmd LC_SEGMENT_64|segname)"
otool -l pd_arm64 | grep -E "(cmd LC_SEGMENT_64|segname)"

Figure: otool -l pd_x86 | grep -E "(cmd LC_SEGMENT_64|segname)” Click to zoom ↗

otool -l pd_x86 | grep -E "(cmd LC_SEGMENT_64|segname)”

Figure: otool -l pd_arm64 | grep -E "(cmd LC_SEGMENT_64|segname)” Click to zoom ↗

otool -l pd_arm64 | grep -E "(cmd LC_SEGMENT_64|segname)”

[pd_x86]
  cmd LC_SEGMENT_64 -> segname __PAGEZERO
  cmd LC_SEGMENT_64 -> segname __TEXT        (11 sections)
  cmd LC_SEGMENT_64 -> segname __DATA        (12 sections)
  cmd LC_SEGMENT_64 -> segname __LINKEDIT

[pd_arm64]
  cmd LC_SEGMENT_64 -> segname __PAGEZERO
  cmd LC_SEGMENT_64 -> segname __TEXT        (11 sections)
  cmd LC_SEGMENT_64 -> segname __DATA_CONST  (3 sections)
  cmd LC_SEGMENT_64 -> segname __DATA        (5 sections)
  cmd LC_SEGMENT_64 -> segname __LINKEDIT

What Each Segment Does Under the Hood

Step 8: Diving into PAGEZERO & Virtual Memory Protection

To understand how macOS protects memory at the binary level, let’s inspect the fields of the very first segment command:

otool -l pd_arm64 | grep -A 8 "segname __PAGEZERO"

Figure: otool -l pd_arm64 | grep -A 8 "segname __PAGEZERO” Click to zoom ↗

otool -l pd_arm64 | grep -A 8 "segname __PAGEZERO”

Decoding the Guard Page

The segment begins at virtual address 0x0 and extends for 0x100000000 bytes (exactly 4 GB in size). This 4 GB region covers the entire 32-bit lower address range.

It consumes zero bytes on disk. It is purely a virtual memory allocation made by the kernel at runtime.

Initial and maximum page permissions are both 0 (--, no read, no write, no execute).

If a developer or malware author introduces a NULL pointer dereference (or tries to access memory via a corrupted 32-bit integer offset inside this 4 GB window), the CPU immediately faults with EXC_BAD_ACCESS (SIGSEGV) rather than allowing an exploit to hijack execution via NULL page spraying.

Step 9: Inside TEXT & Calculating the Entry Point

Now let's inspect the __TEXT segment and the load command that points to execution: LC_MAIN.

otool -l pd_arm64 | grep -A 8 "segname __TEXT" | head -n 9
otool -l pd_arm64 | grep -A 4 "cmd LC_MAIN"

Figure: output Click to zoom ↗

output

segname __TEXT
   vmaddr 0x0000000100000000
   vmsize 0x0000000000004000
  fileoff 0
 filesize 16384
  maxprot 0x00000005
 initprot 0x00000005
   nsects 11
    flags 0x0
---
       cmd LC_MAIN
   cmdsize 24
  entryoff 9892
 stacksize 0

Deconstructing TEXT Memory Setup

****

Demystifying LCMAIN & The Entry Point

On legacy Mach-O binaries, execution entry was governed by LC_UNIXTHREAD, which explicitly supplied CPU register states (rip or pc). Modern macOS uses LC_MAIN:

    VM Base + entryoff = 0x100000000 + 9892 (0x26A4) = 0x1000026A4

When you open pd_arm64 in a disassembler like Ghidra or IDA Pro, this address (0x1000026A4) is precisely where the decompilation flow starts.

Step 10: Mapping Dynamic Dependencies (otool -L)

Before any malware code executes, the dynamic linker (dyld) walks the LC_LOAD_DYLIB commands to map shared libraries into the process address space.

Checking linked libraries is the macOS equivalent of scanning the Import Directory on a Windows PE. It immediately answers two fundamental questions:

Let's inspect the dynamic libraries loaded by pd_arm64:

otool -L pd_arm64

Figure: Screenshot 2026-09-03 at 9.48.27 PM.png Click to zoom ↗

pd_arm64:
    /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1953.255.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
    /usr/lib/swift/libswiftCore.dylib (compatibility version 1.0.0, current version 5.7.1)
    /usr/lib/swift/libswiftCoreFoundation.dylib (compatibility version 1.0.0, current version 120.100.0, weak)
    /usr/lib/swift/libswiftDarwin.dylib (compatibility version 1.0.0, current version 0.0.0)
    /usr/lib/swift/libswiftDispatch.dylib (compatibility version 1.0.0, current version 17.0.0)
    /usr/lib/swift/libswiftIOKit.dylib (compatibility version 1.0.0, current version 1.0.0, weak)
    /usr/lib/swift/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 6.0.0, weak)
    /usr/lib/swift/libswiftXPC.dylib (compatibility version 1.0.0, current version 6.0.0, weak)
    /usr/lib/swift/libswiftFoundation.dylib (compatibility version 1.0.0, current version 1.0.0)

Triage Analysis: What Does This Tell Us?

Step 11: Targeted Triage with cstring

Running strings blindly against an entire binary often returns hundreds of lines of noise, mangled symbol references, and linker metadata.

In Mach-O, real ASCII string literals embedded by the programmer sit in a dedicated section: __cstring inside the __TEXT segment. We can dump just this section with its exact virtual memory offsets using otool:

otool -v -s __TEXT __cstring pd_arm64 | head -n 35

Figure: strings Click to zoom ↗

strings

pd_arm64:
Contents of (__TEXT,__cstring) section
0000000100003d70  mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)
0000000100003db0  v32@?0@"NSData"8@"NSURLResponse"16@"NSError"24
0000000100003ddf  
0000000100003de0  HTTP Request Failed 
0000000100003df5  wb
0000000100003df8  v8@?0
0000000100003dfe  swift_getFunctionTypeMetadataGlobalActor
0000000100003e27  swift_getFunctionTypeMetadataGlobalActorStandalone

Triaging the Indicators

Even without decompiling a single line of assembly, this snippet reveals critical operational behaviors:

    mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)

This is an ancient Windows XP / Internet Explorer 8 User-Agent string. A macOS binary running natively on Apple Silicon using a legacy Windows XP User-Agent is an immediate red flag—designed to blend in with legacy network traffic or evade naive macOS detections.

    v32@?0@"NSData"8@"NSURLResponse"16@"NSError"24

This is an Objective-C / Swift type encoding string representing a block completion handler signature: (void)(NSData *data, NSURLResponse *response, NSError *error). It confirms that the binary uses Foundation's URLSession dataTaskWithRequest:completionHandler: for command-and-control (C2) communication.

Step 12: Code Signing & Gatekeeper Checks (codesign)

Every modern binary executing on Apple Silicon must have at least a baseline cryptographic signature. If an ARM64 binary completely lacks a code signature, the Mach kernel aborts execution immediately with a crash (SIGKILL / CODESIGNING).

To see how the author signed this binary, we invoke Apple’s native verification tool, codesign:

codesign -dv --verbose=4 pd_arm64

Figure: codesign output Click to zoom ↗

codesign output

Reading the Security Attributes

The binary is ad-hoc signed (signed locally with a pseudo-identity rather than an Apple Developer Certificate).

There is no Apple Developer Team ID tied to this specimen.

The Code Directory Hash (CDHash) is one of the most critical IoCs in macOS threat hunting. It is a cryptographic hash of the binary's code directory pages. macOS security subsystems (like Endpoint Security Framework, Endpoint Detection and Response tools, and XProtect) track binaries by CDHash rather than just the full file SHA-256.

Static Triage Cheat Sheet

When a new macOS specimen lands on your triage desk, this command chain gives you full architectural context within 60 seconds:

# 1. Identify container type and architectures
file sample

# 2. Inspect Fat container offsets (if Universal)
otool -f sample

# 3. Thin down to isolated architectures
lipo sample -thin arm64 -output sample_arm64

# 4. View Mach-O header flags and capabilities
otool -h sample_arm64

# 5. Extract virtual memory layouts and the entry point
otool -l sample_arm64 | grep -E "(cmd LC_MAIN|entryoff|segname)"

# 6. Map linked runtime frameworks and system libraries
otool -L sample_arm64

# 7. Dump literal ASCII strings from the code section
otool -v -s __TEXT __cstring sample_arm64

# 8. Check code signing identity and CDHash
codesign -dv --verbose=4 sample_arm64

Coming Up in Part 2: Disassembly & Dynamic Behavior

Now that we understand the basics of how a macOS binary is structured and runs, it’s time to see what happens inside the code.

In Part 2, we’ll take a closer look at the RustBucket sample and follow its behavior step by step.

See you in Part 2!