XUnprotect: Reverse Engineering macOS XProtect Remediator

XUnprotect: Reverse Engineering macOS XProtect Remediator

Speaker: Ko — Cybersecurity Researcher, Prescotte Fedora Security

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

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

Reading Time: ~9 minutes

Type: Briefing

TL;DR

Ko, a macOS security researcher at Prescotte Fedora Security, performed a deep reverse engineering of XProtect Remediator (XPR), Apple's third-layer malware defense. The research reveals XPR's internal DSL for remediation logic, uncovers Apple-exclusive threat intelligence embedded in scanner modules, and exposes several vulnerabilities including a TOCTOU-style arbitrary file deletion primitive.

Introduction

XProtect Remediator is the component most macOS users never see — a silent, scheduled scanner that detects and removes malware after it has already executed, even if it bypassed Gatekeeper and Notarization. Despite running with full disk access and root privileges, XPR's internals have remained largely undocumented. Ko set out to change that at Black Hat USA 2025, releasing a suite of open-source tools and publishing the first detailed technical account of how XPR's scanning and remediation machinery actually works.

The research matters for both sides of security. For defenders, XPR is a hidden repository of Apple's exclusive threat intelligence — malware families identified and tracked by Apple before public researchers ever document them. For red teamers and vulnerability researchers, XPR's powerful entitlements make its bugs unusually dangerous: a flaw in XPR can translate directly into a TCC bypass, a privilege escalation from user to root, or an arbitrary file deletion primitive.

What XProtect Remediator Is — and Why It's Hard to Analyze

▶ Watch: XPR Overview (02:00)

Introduced in macOS Monterey as a replacement for the Malware Removal Tool (MRT), XPR operates as Apple's third layer of macOS malware defense, sitting behind the App Store, Notarization, Gatekeeper, and traditional XProtect. It runs both as a launch agent and a launch daemon, scheduled by dasd (the background task scheduler) based on system activity and available resources. When triggered, the XProtect binary sends an RPC request to XProtectPluginService, which then executes the XPR scanner modules one by one.

As of the research date, XPR ships with more than twenty scanning modules — each a stripped Swift binary of approximately two megabytes. The naming is self-describing: XProtectRemediatorAdLoad targets Adload adware, XProtectRemediatorBlutoop targets the Blutoop family, and so on. These binaries lack type-related symbols because they are stripped even of the Swift metadata that normally survives stripping — type metadata accessors, protocol witness tables (PWTs), and class method symbols have all been removed, making the binaries uniquely opaque.

Ko's toolchain to overcome this included:

• BinaryNinja for static analysis
• BinDiff to find shared functions between XPR scanners and XProtectPayloadDiagnostics, which retains exported symbols that could be imported back into the stripped scanners
• Binja Swift Analyzer — a new Binary Ninja plugin Ko released that extracts Swift reflection metadata (from __swift5_fieldmd and __swift5_types sections) to recover type information, annotating type metadata accessors and PWT symbols
• Custom LLDB scripts to resolve indirect branches through vtables and PWTs at runtime, export them as JSON, and import into Binary Ninja via the BinjaMissing plugin
• Custom LLDB commands to dump complex Swift objects including existential containers

The RemediationBuilder DSL: Apple's Internal Language for Malware Rules

▶ Watch: RemediationBuilder DSL Explanation (16:02)

One of Ko's most revealing findings is that Apple built a domain-specific language inside XPR, implemented using Swift result builders (introduced in Swift 5.4). Rather than writing verbose imperative logic to check file paths, sizes, formats, notarization status, and YARA rules, Apple's engineers express remediation conditions declaratively using RemediationBuilder.

The DSL offers several builder types:

• FileRemediationBuilder — for file-based detections
• ProcessRemediationBuilder — for running process remediation
• ServiceRemediationBuilder — for service-level cleanup
• SafariAppExtensionRemediationBuilder — for browser extension cleanup

A concrete example: the XProtectRemediatorAcre scanner's logic expressed in this DSL says a file is removed only if its path is /tmp/acre, its size is 68 bytes or more, and it matches the acre YARA rule. The entire rule fits in a few readable lines. Ko open-sourced OpenRemediationBuilder, a minimal reimplementation that reproduces this behavior and serves as a reference for researchers.

Not all scanners use RemediationBuilder. Several rely on a lower-level XPR Plugin API directly. Ko has documented both paths.

Encrypted Strings and Hidden Threat Intelligence

▶ Watch: String Decryption and Threat Intel (12:02)

Each XPR scanner runs a modelInitFunc0 before its entry point that decrypts sensitive strings — file paths, URL rules, regular expressions, and hash values — all encrypted at rest. Ko developed a custom LLDB script that decrypts all these strings, building on earlier partial work by Auden from Huntress.

The resulting data reveals Apple-exclusive threat intelligence. Three scanner modules warrant particular attention:

XProtectRemediatorRoachFlag contains two Cdhash values used to kill specific processes. One matches the second-stage payload from the 3CX supply chain attack (the "upgrade agent"), previously analyzed by Patrick Wardle at Black Hat. The second Cdhash belongs to an unknown variant — circumstantial evidence supporting Wardle's hypothesis that more capable versions of the upgrade agent exist beyond what has been publicly documented.

XProtectRemediatorBadCulture uses OCR against the background images of mounted disk images, scanning for strings like "right-click", "click open", and "option click" — phrases used in social engineering DMG installers that instruct users to bypass Gatekeeper. It detects disk images associated with multiple malware families including Empire Transfer and ChromeLoader, suggesting it functions as a generic threat-hunting scanner rather than a family-specific detector.

XProtectRemediatorRedPine — the most intriguing scanner — contains a YARA rule that matches the TriangleDB iOS implant from Operation Triangulation (the Kaspersky-reported campaign), along with four suspicious file paths. Kaspersky researchers had suggested a macOS version of the implant likely exists; RedPine appears designed to detect it. Uniquely, it holds the com.apple.system.taskport.read entitlement, allowing it to read arbitrary process memory — because the macOS implant, like its iOS counterpart, is believed to operate entirely in memory via a reflective loader.

Ko's analysis of RedPine's loaded library scanner revealed strange path references: FMCoreFramework (a directory), CoreLocation (a symlink), AVFoundation (a symlink), and libsqlited.dll. His hypothesis is that the macOS implant used a custom reflective loader that sets an arbitrary fake path as the backing file, explaining why directories and symlinks appear as "loaded libraries."

Provenance Sandbox: The Forensic Artifact Nobody Talks About

▶ Watch: Provenance Sandbox Mechanics (32:03)

XPR makes use of a macOS mechanism called the provenance sandbox to trace remediated files back to their originating application. When an app is first launched, syspolicyd records it in the ExecPolicy database and assigns a special provenance attribute — an 11-byte integer with 8 random bytes. Any files the app subsequently creates inherit this attribute, enabling XPR to answer: "Which app dropped this malware payload?"

This is forensically valuable beyond Apple's own use. Provenance attributes persist as an artifact on-disk: checking the provenance attribute of a persistence plist under ~/Library/LaunchAgents reveals exactly which application established it. Ko released a tool to collect and query provenance attributes and added provenance data collection support to a macOS incident response framework.

He also found provenance sandbox bypasses, noting that previous App Sandbox bypass techniques often transferred directly: launching processes via LaunchServices or through XPC both circumvented provenance tracking in configurations he tested, though Apple has since addressed these.

Vulnerability Research: Arbitrary File Deletion via TOCTOU

▶ Watch: TOCTOU Vulnerability Demo (36:04)

Ko's vulnerability research surfaces a TOCTOU (time-of-check-time-of-use) issue in XPR's remediation flow. When XPR matches a YARA rule against a file and prepares to delete it, there is a window between the rule match and the actual deletion. An attacker can monitor the unified log for the "YARA rule hit" event, then use a symlink swap to replace the target file with any other file on the system.

Because XPR operates with full disk access, this allows a non-privileged attacker with prior code execution to delete arbitrary files — a denial-of-service primitive at minimum. The vulnerability was reported to Apple. Ko notes that bugs found in Apple's App Sandbox have often proved applicable to the provenance sandbox for similar reasons.

Notable Quotes

"XPR is a treasure trove of Apple's threat intelligence. Security researchers should keep an eye on newly added scanners in future updates."

— Ko ▶ 38:04

"Vulnerabilities in XPR and provenance sandbox are surprisingly basic. Bugs found in other Apple app sandbox are often directly applicable."

— Ko ▶ 38:04

"Since Apple tends to use its own naming scheme for malware, several malware families targeted by XPR remain unknown."

— Ko ▶ 04:00

"When XPR removes malware, it fetches the provenance attribute and can ask, 'Hey, which app created these files?'"

— Ko ▶ 32:03

Key Takeaways

• XPR contains undisclosed Apple threat intel. Newly added XPR scanner modules are worth monitoring — they often target malware families that have not yet been publicly documented by the research community.
• The RemediationBuilder DSL is now documented. Ko's GitHub repository contains the specification, allowing researchers and defenders to interpret XPR's remediation conditions without reverse engineering from scratch.
• Provenance attributes are a valuable forensic artifact. Security teams on macOS can use provenance sandbox data to trace persistence mechanisms to their originating application.
• TOCTOU in XPR enables arbitrary file deletion. Post-exploitation code can monitor unified log for YARA hits and use symlink swaps to trick XPR into deleting attacker-chosen files using XPR's full disk access.
• Previous App Sandbox bypasses often apply to provenance sandbox. Researchers looking for new bypass techniques should start there.

Slides

No slides PDF was listed for this briefing. Ko's tools and reversing results are available on his GitHub repository (linked via QR code during the talk). A white paper containing full technical details was in preparation at time of presentation.