Mac Admins | Why Apple’s Silent Approach to Endpoint Security Should be a Wake-Up Call

If there’s one thing that everyone should be able to agree on about Apple, it is that the company really does think different when it comes to the design of its products, and this is nowhere more obvious than in the company’s approach to endpoint security. Users will find no Defender-like security center built into macOS, and admins and IT teams will search in vain for Apple web portals to log into or extra licenses to buy for ‘top tier’ telemetry.

Unlike rival OS vendors, Apple does endpoint security when – and where – admins and users aren’t looking. This approach has served Apple well from a marketing perspective – there’s a widespread if somewhat misplaced belief that macOS is more secure than Windows – but for small to medium-sized enterprises relying entirely on Apple to keep them safe, this lack of visibility is something to be addressed.

In this post, we’ll shed light on three areas of macOS security that are crucial to understand for businesses that do not currently deploy additional endpoint protection on their macOS devices.

Apple’s Approach to Platform Security

Last updated in May 2022, Apple’s most recent public documentation about protecting against malware on macOS states that its malware defenses are structured in three layers:

None of the technologies responsible in these layers has much in the way of user or admin-controlled granularity: it’s not possible, for example, to allow or exclude specific applications or code across users or devices. On a single device, a user can make extremely broad system policy decisions (such as allow or deny all apps sourced from outside the App Store), but even then – unless the system is administered by an MDM solution – that policy can be overridden by local users, even without administrator rights.

More concerning from an enterprise security perspective is that there is little visibility into what code has been blocked, when and why, nor is it obvious when these scans are being performed or how effective they have been.

This is a particular worry in terms of malware remediation, which happens silently in the background without warning to the user. In an enterprise setting, this is simply not sufficient: security teams need to understand when malware was introduced to the system, how long it was there and where malware came from if they are to adequately defend the enterprise.

1. XProtect Signatures | Missing Out On the Latest Malware

According to Apple,

The last update to Apple’s XProtect.bundle which contains these YARA signatures was made on June 29th, though the update may have not been released till some days later depending on location of the device.

Unfortunately, this update did not include any changes to the file signatures that Apple says power XProtect’s blocking abilities. The YARA file bears the same hash as version 2166, updated last February.

If one were to go by the version numbers, there should have been 7 updates to XProtect’s YARA rules in the last 12 months, but in fact only three have actually been observed in our test machines. Moreover, the difference between version 2165 released last November and the version available today is a mere three additional rules for only two malware families: one for Keysteal and two for a cryptominer known to Apple as Honkbox.

Since both SentinelOne and many other vendors have reported on multiple new macOS malware strains in the last few months alone, it should be concerning to users and admins relying entirely on XProtect’s rules that they are so far behind the rest of the industry.

2. XProtectRemediator | Hiding Infections After-the-Fact

Despite the lack of updates to Apple’s primary malware blocking tool, the company has been updating its MRT-replacement tool XProtectRemediator more regularly. XProtectRemediator runs at intervals of around 6 hours per day, looking for a small collection of known malware families.

While the increased attention there is an improvement on the old MRT.app, the focus on remediation rather than blocking should be of concern to enterprise security teams. 6 hours is far too long for infostealers to be in the organization, particularly as they take only seconds to do their work. Session cookies are primary targets for threat actors to worm their way further into organizations and turn compromises from a single Mac into a serious breach, such as happened recently at CircleCI.

As noted above, there is no user interface on macOS for understanding what malware has been remediated, when or how it was introduced into the system. However, as of macOS Ventura, system administrators without 3rd party visibility tools can attempt to leverage the eslogger tool introduced with macOS 13.

Unfortunately, eslogger was not built with enterprise scale in mind. It will require some building of infrastructure and external tools in order to bring results from across a fleet into a central database that could be monitored and mined for data. There are better 3rd party tools built for the job that will require less investment and give greater return.

In either case, unless security teams are proactive, Apple’s XProtectRemediator will silently remove malware that it discovers without alerting the user or the administrator that an infection had ever occurred. Similarly, the tool will neither warn of nor log suspicious or malicious activity that it hasn’t been explicitly programmed to detect.

Relying on silent remediation is a high-risk strategy for both enterprises and Apple. A risk of a false positive in this situation could cause serious harm to users and businesses, so it is likely that Apple has designed the tool extremely conservatively in terms of what it will detect and silently remove.

For enterprises, the inability to receive alerts and the difficulty of inspecting logs means there is little chance of catching infections missed by XProtectRemediator, of tracking down the root cause of those that it removes, or of further investigating the incident and its impact on the organization.

3. XProtectBehaviorService | Hidden Behavioral Detections

A recent addition to Apple’s malware detection technologies which the company has not publicly documented yet goes by the name of XProtectBehaviorService.

At present, the service merely silently logs details of applications that violate certain pre-programmed behavioral rules, currently defined in /usr/libexec/syspolicyd.

These rules, internally referred to as “bastion rules”, log violations in a hidden sqlite database located at /var/protected/xprotect/XPdb. It is commendable that Apple is logging access to data held in enterprise applications like Slack and Teams, as well as various browser and chat apps. The question remains, however, as to what access Apple intends to give users – and more importantly admin, IT and security teams – to this service and the information it gathers as it develops further.

For example, those logs were put to good use recently by incident responders investigating an APT intrusion that infected four macOS Ventura systems and which was neither blocked by XProtect nor removed by XProtectRemediator.

Although that data is now there to be found by incident responders, it falls on those responsible for security to gather it and learn how to use it. It serves as a case in point of how IT teams that continue to rely entirely on Apple for protection must still proactively engage with the macOS devices in their fleet and mine them for the hidden logs and telemetry that Apple stashes away.

Conclusion

Apple’s approach to security is, like many other things it does, different to other OS vendors. That’s neither a good thing nor a bad thing in itself; what matters is that admins are aware of how their OS is dealing with security events. A nice, quiet system doesn’t necessarily mean a safe and secure system.

Knowing what’s happening on the company’s endpoints is the first step to securing them, and there are a lot more security-related events occurring under the hood of macOS than is obvious to the casual observer.

As a vendor, it should come as no surprise that we urge organizations to deploy additional security on their macoS devices: naturally, we believe in what we do and the reasons for doing it. But even those that are not yet ready to heed that message can take away a vital lesson from this discussion: actively engage with the Macs in the fleet, mine them for logs and ensure that the in-house security team knows at least as much as Apple does about what’s happening on the organization’s Macs.

To learn more about how SentinelOne can help protect the Macs in your fleet, contact us or request a free demo.