How to Deploy macOS Background Task Management (ServiceManagement) to Prevent Persistence Malware

In the macOS security landscape, one of the primary indicators of compromise (IoC) is the establishment of “persistence.” When an attacker breaches a Mac (e.g., via a malicious payload dropped by a phishing email), they must ensure their remote access trojan (RAT) survives a reboot. Historically, malware achieved this by silently dropping property list (.plist) files into specific, hidden directories like ~/Library/LaunchAgents or /Library/LaunchDaemons. When the Mac rebooted, the OS would blindly read these directories and execute the malicious binaries as background processes, often with root privileges.

For years, enterprise IT had no native way to prevent this other than writing complex EDR (Endpoint Detection and Response) scripts to constantly scan those folders and delete unauthorized files.

Starting with macOS 13 Ventura (and strictly enforced in macOS 14 Sonoma), Apple revolutionized this paradigm by introducing the ServiceManagement framework (Background Task Management). macOS now alerts the user anytime a new background task is installed. More importantly for enterprise IT, Apple introduced an MDM payload that allows security administrators to explicitly whitelist authorized background tasks and completely block users (or malware) from modifying or disabling them.

This guide explains how to architect and deploy Background Task Management configuration profiles to harden macOS endpoints.

Understanding the ServiceManagement Framework

The ServiceManagement framework centralizes how macOS tracks persistence.

1. User Notification: When an app (like Zoom or a malicious script) attempts to install a LaunchAgent, macOS intercepts the action and displays a notification: “Background Items Added.”
2. Login Items UI: Users can navigate to System Settings > General > Login Items. Here, they see a comprehensive list of every background process and can toggle them off.
3. The Enterprise Conflict: The UI presents a massive problem for IT. A standard user can now casually toggle off the company’s EDR agent (e.g., CrowdStrike), the VPN daemon (e.g., GlobalProtect), or the MDM agent itself. If the security tool is toggled off, it fails to launch on the next boot, leaving the Mac defenseless.

To solve this, MDM administrators must deploy a com.apple.servicemanagement.managedloginitems profile.

Step 1: Identifying the Developer Team ID and Rule Types

To control a background item, you must identify it cryptographically. You do not block based on the filename (which malware can easily change); you manage based on the Apple Developer Team ID or the exact bundle identifier.

You have three types of rules you can enforce:

• TeamIdentifier: Manages all background tasks signed by a specific developer (e.g., EQHXZ8M8AV for Google).
• BundleIdentifier: Manages a specific application (e.g., com.paloaltonetworks.GlobalProtect).
• Label: Manages a specific launchd .plist label.

To find the Team ID of an installed application (e.g., CrowdStrike), run this command in the terminal:

codesign -dv --verbose=4 /Applications/Falcon.app 2>&1 | grep TeamIdentifier

Step 2: Constructing the MDM Payload (The Whitelist)

The goal is to force your security tools to be ON and locked, preventing the user from disabling them.

In your MDM (Jamf Pro, Kandji, Intune, etc.), create a new Managed Login Items (or Service Management) configuration profile.

You will create rules within this payload. For example, to lock the CrowdStrike Falcon sensor:

1. Rule Type: Team Identifier
2. Rule Value: X9E956P446 (CrowdStrike’s Team ID)
3. Comment: Force CrowdStrike ON

When this profile is deployed, the toggle switch for CrowdStrike in the macOS System Settings > Login Items menu will be greyed out. The user will see a message stating “This item is managed by your organization.” The user cannot disable it.

Step 3: Blocking Unauthorized Persistence

While locking your security tools is critical, true endpoint hardening requires blocking unauthorized background tasks.

Currently, the native Apple payload is designed for management (locking approved items on), not strict whitelisting (blocking everything else by default). However, you can manage specific, known malicious or unwanted vectors by explicitly defining them in the payload and setting their state to Disabled.

If you identify a persistent threat or unwanted software (e.g., a specific crypto-miner bundle ID), you can push a ServiceManagement rule targeting that BundleIdentifier and forcefully disable it. Even if the malware rewrites the .plist file to disk, the macOS kernel will refuse to execute it because the MDM profile strictly overrides the local filesystem.

Step 4: Auditing with sfltool

To troubleshoot and audit the background tasks on a live machine, macOS provides the sfltool (Shared File List tool).

To view the current database of background tasks and their MDM-enforced status, run:

sfltool dumpbtm

This command dumps a massive diagnostic log. Look for the Disposition field for your managed items. You should see [managed] and [enabled], confirming that the ServiceManagement framework has successfully intercepted the daemon and applied your zero-trust MDM rules.

Conclusion

The days of attackers silently dropping LaunchAgents into hidden macOS directories are over. By leveraging the macOS ServiceManagement framework via MDM, security engineers can cryptographically lock mission-critical security daemons, strip standard users of the ability to disable their EDR agents, and establish a deeply integrated, kernel-level defense against persistence malware on the Apple endpoint.