Reversing approaches to extract embedded scripts in macOS malware

Reversing Approaches to Extract Embedded Scripts in macOS Malware

Speakers: Patrick Wardle

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=BvRZHRlMsoU

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Patrick%20Wardle%20-%20Binary%20Facades%20Reversing%20Approaches%20to%20Extract%20Embedded%20Scripts%20in%20Compiled%20macOS%20Malware.pdf

Overview

Malware analysis is fundamentally a triage and classification problem. When a new sample arrives, the analyst's first goal is to determine whether it is benign, known-malicious (already documented and not worth re-analyzing), or novel-malicious — the category that demands full reverse engineering effort. A critical but underappreciated complication arises when the malicious logic is not implemented in compiled native code, but is instead a script that has been wrapped inside a native executable binary to improve its delivery and execution characteristics.

Patrick Wardle, founder of the Objective-See Foundation and co-founder of DoubleYou, presents a systematic field guide to identifying, classifying, and extracting scripts from "script-wrapped binaries" — macOS applications that present themselves as native executables but actually function as execution hosts for embedded Python, Bash, Ruby, JavaScript, AppleScript, or other interpreted payloads. The talk covers five major packaging tools that malware authors regularly abuse — Platypus, PyInstaller, Electron, JXA, and Automator — detailing the identification fingerprints and extraction methodology for each.

Background

▶ Watch: Aloha and welcome to my talk. (0:11)

Why Malware Authors Wrap Scripts in Binaries

Karimi notes three primary reasons behind this packaging pattern, and they all come down to operational practicality:

Scripts are easier to write. Most initial-access and post-exploitation malware does not require the performance or complexity of compiled code. A Python or Bash script can perform keylogging, credential theft, persistence installation, and C2 communication with a fraction of the development effort of a native binary. The script-wrapping step is a delivery mechanism added on top.

Scripts offer cross-platform portability. A Python script can target both Windows and macOS with minimal modification. Malware authors who want to hit multiple platforms can maintain a single codebase and wrap it differently for each OS.

macOS users do not know how to run scripts directly. This is the most important reason from a social engineering perspective. The macOS GUI presents a significant barrier to script execution — users must navigate to Terminal, understand UNIX path semantics, and issue a command to run a Python or Bash file. By contrast, users will readily double-click an application bundle (a .app directory), because that is the native macOS interaction paradigm. Wrapping the malicious script in an app means the victim can "run" the malware naturally, with no unusual interaction required.

Why This Matters for Analysts

The problem for the malware analyst is that script-wrapped binaries are taxonomically confusing. The file presents as a native macOS executable (Mach-O binary). Standard binary analysis tools — disassemblers, debuggers, hex editors — can be brought to bear on it. But the analyst may spend hours or days reverse engineering what turns out to be a benign loader binary that simply invokes a script payload located elsewhere in the application bundle. That script payload is almost always far simpler to analyze because it is human-readable interpreted code.

A second and more serious complication arises when the script is directly embedded inside the binary rather than written to disk. In this case, running the sample in a sandboxed virtual machine will not produce a filesystem artifact of the script — it never touches disk. The analyst who does not know to look for an embedded script will never find the malicious payload through dynamic analysis alone.

Key Findings

▶ Watch: Adversaries hacked uh the popular macupdate.com website and distributed Troja... (18:05)

Wardle documents a taxonomy of five major script-packaging utilities, each with a distinct binary signature, and demonstrates that all five have been actively abused by macOS malware authors:

1. Platypus — open source tool for wrapping command-line scripts into macOS apps; detectable via disassembler symbol names and application delegate method names.
2. PyInstaller — widely used Python-to-executable packager; detectable via Mach-O binary magic and specific embedded archive structures.
3. Electron — JavaScript/Node.js application framework; identifiable via characteristic framework directory structure and app.asar archive format.
4. JXA (JavaScript for Automation) — Apple's built-in JavaScript automation framework; scripts compiled to binary via osacompile but extractable.
5. Automator — Apple's visual workflow tool; workflows stored as XML within application bundles, often minimally obfuscated.

In all five cases, an analyst who recognizes the packaging tool can extract the actual malicious script in minutes, skipping the need for low-level binary analysis of the loader component.

Technical Deep Dive

▶ Watch: we can see indeed the application bundle does both drop and execute this script. (19:20)

Platypus

Platypus is an open-source macOS utility that creates native application bundles from command-line scripts. Because its source code is publicly available, analysts can examine the loader binary's code directly.

Identification: When a Platypus-wrapped binary is loaded into a disassembler (Wardle uses Hopper in the talk), the symbol table contains function names beginning with scriptExec. The application delegate — the functional equivalent of main() for macOS apps — contains a call to a method named executeScript. These symbols are preserved in release builds because macOS application frameworks use Objective-C runtime introspection that depends on string symbol names.

Extraction: The wrapped script is stored directly in the application bundle, typically in the Resources directory, with the path hardcoded in the binary. Because the path is a plaintext string in the binary, strings output or a basic disassembler review is sufficient to locate and extract it without executing the binary.

Malware in the wild: Wardle cites documented macOS malware samples distributed as Platypus-wrapped bundles. The pattern is particularly common in North Korean-attributed APT campaigns targeting cryptocurrency developers, where Python-based backdoors are wrapped in fake applications.

PyInstaller

PyInstaller packages Python applications — including all imported modules — into a self-contained executable. The resulting binary extracts its Python runtime and modules to a temporary directory and executes them, making it superficially look like a native executable.

Identification: PyInstaller binaries contain a characteristic embedded archive (a "PKG" archive internally called CArchive) appended to the Mach-O binary. The archive begins with a specific magic string (MEI\014\013\012\013\016) that is searchable in binary editors or via grep. The main script is typically named __main__.py within the archive, alongside frozen bytecode for all imported modules.

Extraction: The tool pyinstxtractor can automatically unpack PyInstaller archives, extracting the embedded .pyc bytecode files. These bytecode files can then be decompiled back to Python source using tools like uncompyle6 or decompile3. The resulting source code is the actual malicious Python script the analyst needs to examine — and it is significantly easier to analyze than Mach-O assembly.

Complication — obfuscation layers: Sophisticated malware authors using PyInstaller sometimes add a secondary obfuscation layer, such as encrypting the Python bytecode with a key derived from a hardware fingerprint or applying PyArmor obfuscation before PyInstaller packaging. However, these are solvable problems with targeted tools, and the PyInstaller extraction step eliminates the need to reverse the binary loader regardless of what is inside.

Electron

Electron is the framework underlying a substantial fraction of modern desktop applications (Slack, VS Code, Discord). It packages Node.js JavaScript applications as native executables. Malware authors have abused Electron both by Trojanizing legitimate applications and by creating fake applications that are entirely malicious.

Identification: Electron applications are immediately recognizable by their directory structure. A legitimate or malicious Electron app will contain an Electron Framework.framework bundle within its Frameworks directory. The application's actual JavaScript logic is stored in an app.asar archive, typically located at Resources/app.asar within the bundle.

Extraction: The asar command-line tool (installable via npm) can unpack .asar archives. The result is a standard Node.js project tree with JavaScript source files, package.json, and optionally minified or obfuscated JavaScript. Even minified JavaScript is substantially more analyzable than assembly code, and JavaScript-specific deobfuscators can further clean up the code.

Malware in the wild: Electron-based malware has been documented in multiple cryptocurrency-themed attack campaigns, where fully functional — but backdoored — trading applications are distributed via social engineering. The malicious logic in the Electron app is a few dozen lines of JavaScript that, once extracted from the .asar archive, are clearly readable.

JXA (JavaScript for Automation)

JXA is Apple's implementation of JavaScript as an automation language, built on JavaScriptCore. JXA scripts can be compiled to binary format using osacompile, producing a .scpt binary that is opaque to text editors. These compiled scripts can be embedded directly in application bundles.

Identification: Applications that use JXA as their primary logic often have an unusually small native binary (the Objective-C shell that invokes the OSA runtime) alongside an .scpt resource. The binary will import OSAKit or Carbon frameworks, and otool -L output will reflect these framework linkages.

Extraction: The osadecompile command-line tool, included with macOS, can decompile compiled .scpt files back to JavaScript (or AppleScript) source. This requires no specialized tooling — the OS provides the decompiler. The resulting source code is directly readable.

Automator

Automator is Apple's visual workflow builder. Automator workflows can be saved as Application bundles (.app), making them deliver a macOS-native double-click experience. The workflow logic is stored as an XML plist file inside the bundle.

Identification: Automator-based applications contain a workflow.wflow file (or equivalent) in their Contents directory. The bundle's Info.plist references com.apple.automator as the application type. The native binary is simply the Automator runtime — completely benign code that reads and executes the workflow XML.

Extraction: The workflow XML is human-readable and self-documenting. Actions in the workflow are specified by name and parameters directly in the XML. Shell script execution actions will contain the literal script code as a text field in the XML. No disassembly required.

Demo / PoC

▶ Watch: This can support our continued analysis of this malware. (34:21)

Wardle walks through disassembly and extraction workflows for each packaging tool, using Hopper Disassembler for the binary analysis steps and command-line tools for archive extraction. For each tool, he shows a real malware sample that abused it, demonstrating both the identification step (recognizing the packaging tool from binary fingerprints) and the extraction step (obtaining the actual malicious script). The goal throughout is to show that a malware analyst who recognizes the packaging tool can extract the payload in under five minutes — versus hours or days of native binary analysis.

The talk's associated chapter in Wardle's "The Art of Mac Malware" book series (free at objective-see.org) provides extended coverage of each technique with additional sample analysis.

Defensive Implications

▶ Watch: OSA minor is persisting and executing other components. (38:45)

For security operations and detection engineering:

Script-wrapped binaries are a significant evasion challenge for file-based detection. Many EDR products apply YARA signatures or machine-learning classifiers to Mach-O binaries. A malicious Python script, when wrapped in a PyInstaller binary, will have a different binary signature than the same script wrapped in a Platypus binary — and a different signature still from the raw script. Detection engineers should develop signatures targeting both the packaging-tool identifiers (PyInstaller magic bytes, Platypus symbol names, Electron framework structure) and the extracted script content.

For macOS endpoint security tooling:

Dynamic analysis sandboxes should be configured to extract and analyze embedded script content from known packaging tools, not just execute the outer binary and observe system call behavior. If the malicious script is embedded and never touches disk, pure behavioral analysis will not capture the complete payload.

For hunting:

The packaging-tool fingerprints described in the talk are straightforward to implement in Yara rules and are effective for hunting at scale across sample repositories like VirusTotal or Malware Bazaar. Hunting for the PyInstaller magic byte sequence, Platypus symbol patterns, or Electron framework directory structure can surface script-wrapped malware that evades signature-based detection.

For threat intelligence:

Identifying which packaging tool a malware sample uses is an attribution and clustering signal. North Korean campaigns have shown consistent preferences for Platypus and PyInstaller. Tracking packaging tool usage across campaigns can help cluster related samples even when the script payloads are heavily obfuscated.

Key Takeaways

• Script-wrapped binaries are a prevalent and growing class of macOS malware, driven by script simplicity, cross-platform portability, and the social engineering advantage of delivering an application bundle.
• Five major packaging tools — Platypus, PyInstaller, Electron, JXA, and Automator — each leave distinctive, recognizable binary fingerprints.
• Extracting the embedded script from a correctly identified wrapper is typically faster than beginning low-level binary analysis of the loader.
• Critically, scripts embedded in binaries may never touch the filesystem, making dynamic analysis insufficient — static identification and extraction is required.
• Detection engineers should target both wrapper fingerprints and extracted script content for maximum coverage.

About the Speaker

Patrick Wardle is the founder of the Objective-See Foundation, the producer of free, open-source macOS security tools including BlockBlock, KnockKnock, LuLu, and RansomWhere. He is also co-founder of DoubleYou, which builds macOS security detection components for enterprise integration. Wardle is the author of "The Art of Mac Malware," a multi-volume book series on macOS malware analysis and detection that is freely available online. A former NSA analyst and longtime macOS security researcher, he has documented more macOS malware families and novel attack techniques targeting Apple platforms than any other public researcher. His Objective-See tools are relied upon by macOS users ranging from individuals to security researchers at major organizations worldwide.