Note from the author: I’d be remiss not to mention the strangeness of the blog title, a simple but albeit ludicrous spin-off of a DMX song. This blog post began as a talk for the MacDevOps YVR conference in Vancouver, British Columbia. The thought of ‘dmXProtect’ kept tickling the silliest parts of my brain as I prepared it. You will sense the running theme throughout this blog, so I hope you’ll forgive me as I fulfill my dream of successfully integrating 2000s R&B/HipHop and macOS security 😂
As the adoption of macOS becomes more common within businesses - whether at the small-medium sized business (SMB) or at the large enterprise level—one of the most common questions that arises is: “Do I need a third-party security tool?”
In a blog post titled Built-In macOS Security Tools, I discussed a handful of tools that Apple ships with their devices that are designed to keep their end users safe. Two of those tools are changing rapidly, and I also think they’re valuable and interesting enough to get a whole blog dedicated to them. Those two products are XProtect and XProtect Remediator (XPR). Much of the information below was also presented at the MacDevOps YVR; however, due to time limits and the intricacies of these two tools, it’s worth taking an even deeper look into them.
When looking at the built-in macOS security tools, three play a fundamental role in protecting users of macOS: Gatekeeper, XProtect and XPR. These three map nicely to three of the core concepts of macOS security: check, block and remediate.
We will dive into Gatekeeper another day, but let’s talk about what XProtect and XPR are designed to do, which is block malicious behavior and remediate threats. We will also talk about how they interact with each other, working together for a common goal.
XProtect
First, let’s talk about XProtect. So what is it?
It’s a collection of files whose aim is to investigate files. As part of the com.apple.xprotect subsystem, it checks for malicious content when one of the following occurs: an application is first launched, changes have been made to an application, or the XProtect signatures are updated.
If we step down into where the XProtect files live, in /Library/Apple/System/Library/CoreServices, we see a few different files here, including XProtect.bundle and XProtect.app. Drilling down further, we get to five files.
XProtect.meta.plist
The original idea behind XProtect was to check for outdated software like Java and Flash, and although it still does look to detect outdated software, the main thrust of this file is to prevent malicious Safari extensions.
The extensions it blocks are identified by their bundle identifier and a corresponding developer ID.
XProtect.plist
XProtect also aims to block malware, and that is evident by the XProtect.plist. As we can see below, via the Description key, XProtect here is looking to block the Bundlore malware. In this case, it looks for the LSItemContentType of ‘application bundle’.
LegacyEntitlementAllowlist.plist
The LegacyEntitlementAllowlist is a little bit of an enigma in that it is not documented exactly what this file is used for.
Fortunately, based on the file name, speculation is relatively straightforward in that it contains an array of over 42,500 cdhashes. Based on this, in conjunction with the name of this plist, we can speculate that this refers to specific macho binaries that need a legacy entitlement in order to run properly.
XProtect.yara
The current, primary function of XProtect is to not only look for known threats, but also look for unknown threats. To do this, XProtect leverages YARA, which allows third parties to “create descriptions of malware families (or whatever you want to describe) based on textual or binary patterns.” This allows users—and in this case, Apple—to not look for malware based solely on its hash or developer ID, but instead to search for commonalities across malware. This means if malware changes its developer credentials or bundle identifier, YARA could still potentially prevent it.
All of the YARA rules within the XProtect.yara are obfuscated, making insight into what malware families each rule is aimed at blocking more difficult, especially if you aren’t actively researching macOS malware. With over two hundred rules, Apple continues to expand this rule set with updates to this file.
gk.db
This file is designed to work with Gatekeeper to check files when the quarantine bit is set. Within the gk.db, we find a few different tables called blocked_hashes and blocked_teams. The blocked_hashes table contains 546 hashes that Gatekeeper, leveraging XProtect, prevents.
If we pivot to the blocked_teams table, we can see that it contains just two columns, one listing the developer id of malicious software.
Within this table, we have 132 unique team ids (also referred to as ‘Developer IDs).
This table is only referenced by Gatekeeper, so if the quarantine flag has been marked as safe (or allowed), then XProtect will not reference this table and vice versa. To see this in action, I have included a demo.
Where My Logs At
As previously mentioned, XProtect runs out of the com.apple.xprotect subsystem, so using unified logging, we can stream the XProtect events to our Terminal or your mobile device management (MDM) if supported.
To collect these XProtect logs, you can use the command
log show -info -backtrace -debug -loss -signpost -predicate 'subsystem == "com.apple.xprotect"'
From here, we can get further information surrounding what XProtect is doing.
XProtect Remediator
XProtect Remediator (XPR) is actively replacing the Malware Removal Tool (MRT) and is now Apple’s de facto remediation tool. We won’t touch on MRT, but you can find more information in our Built-In macOS Security Tools blog.
XPR is an application bundle (XProtect.app) that lives next to the XProtect.bundle in CoreServices.
Stepping into the application to the lowest level of the bundle, we see there are twenty macho binaries.
Each of these has a unique job in remediating a specific family of malware.
The twenty XPR binaries as of XProtectRemediator version 99
Since XPR’s inception, there have been some other updates surrounding it. Apple’s Endpoint Security has expanded to capture some of the XPR events - ES_EVENT_TYPE_NOTIFY_XP_MALWARE_DETECTED and ES_EVENT_TYPE_NOTIFY_XP_MALWARE_REMEDIATED.
This is a big win for threat researchers and developers, as it gives more precise knowledge about XProtect and XPR. On the flip side, the information that these two ES events return is lacking thus far.
It provides us with a path to where it was detected, the malware name (via the XProtect.yara rule name), and that’s about the extent of the context. However, the unified logs for XPR are quite robust.
To collect the XPR unified logs, you can use the command
log show -info -backtrace -debug -loss -signpost -predicate 'subsystem == "com.apple.XProtectFramework.PluginAPI" && category == "XPEvent.structured"'
Using our demo from earlier, we can skip over the first part and immediately see the XPR logs from after our malware was blocked from executing.
Am I Enough?
One of the main questions I’m aiming to answer is: “Are XProtect and XPR good enough solutions to keep me (or my users) safe?” My approach has remained quite steadfast since XProtect’s YARA introduction. I think the combination of these two would be enough for your aunt who just uses her machine for online gambling or browsing Pinterest; however, at scale, I don’t believe these tools have the coverage you need to keep users safe.
The lack of consumable visibility into what is happening with XProtect and XPR makes it difficult to triage issues at scale. To add to this, Apple has millions of endpoints and any changes to these rules get pushed to all of those machines. That being said, they have zero wiggle room for false positives, which although it is what every EDR company aims to reduce, the truth is that casting a slightly larger net in order to capture malicious behavior, and risking the occasional false positive in lieu of this (to me) is a great tradeoff. Lastly, although YARA is helpful for capturing more samples of malware families, it doesn’t necessarily capture malicious behavior. The malware has to be from specific families in order to be prevented.
Looking Forward: macOS Sonoma
In macOS Ventura, we have seen a new SQLite database at /var/protected/xprotect/XPdb. This is a database that seems to be for behavioral detections, using rules called BastionRule-1,2,3,4.
In looking at a sample event, we can see how these map to the different columns.
In a very interesting thread by @tsunek0h, they discuss this new set of rules, how they interact with syspolicyd, and the experimental XProtectBehaviorService as a whole.
Epilogue
Malware prevention continues to be a large focus for Apple, as they continually (albeit at irregular cadences) are updating XProtect and XPR. Plus, with the early beta features of potential behavioral detections, Apple is seemingly making a push into handling malicious behavior themselves. However, until that day comes, users and administrators will likely be more secure by investing in a third-party solution.
To find out more about Huntress’s offerings on macOS, please contact us or check out this blog.
If you’re interested in more macOS content, watch this episode of Tradecraft Tuesday where we dive into some shady macOS malware.
