The Mac and macOS often gets overlooked when it comes to detection priorities. If your company uses macOS devices, it’s important to ask yourself if the existing security is enough. In most cases, the answer will be a no.
This post covers three Mac detection methods that we recommend implementing immediately to enhance your Mac security capabilities.
TCC.db
Our first detection method focuses on detecting a modification of a TCC.db file. By editing this DB, an attacker can gain wider privileges to take control of additional components.
TCC stands for transparency, consent, and control. It’s a mechanism in macOS that controls application permissions and access to certain components, such as location services, full disk access, microphone, camera, contacts, photos, accessibility, and more.
The TCC database is a sqlite3 database. There are two different databases: a global one in /Library/Application Support/com.apple.TCC/TCC.db and a per-user one located in ~/Library/Application Support/com.apple.TCC/TCC.db. The system integrity protection mechanism (SIP) is intended to keep these databases from editing, but they can be read and edited by granting your process (editor, terminal, etc.) full disk access permissions.
When SSH is enabled and you have the credentials for a target user, there is a way to bypass this restriction. The SSH process has full disk access to the target device by default. That means users can SSH locally and provide themselves with Full Disk Access and subsequently gain the ability to directly edit the TCC database.
The database contains a few tables, but the one we’re most interested in is the access table, which contains all the prevailing settings for privacy controls.
How to Detect it?
Since innocent installers modify the TCC.db file directly when asking the user for permissions and being granted, detection of this file modification by itself might raise false-positives.
- Local SSH connection, then manipulation of the TCC.db.
- Manipulation of the TCC.db (e.g. copying to another location) and then an SQLite command that inserts values to a table called Access - a common behavior by attackers, to manipulate the DB in a different location or with a different name.
The following code implements this logic:
Emond
Our next detection method focuses on a mechanism to achieve persistence with the event monitor Daemon (Emond). Emond accepts events from various services, runs them through a simple rules engine, and takes action. The actions can also run OS commands, send an email, text messages, etc..
This binary functions as a normal daemon and is executed by launchd (the service management framework for macOS) every time the OS starts up. There are a few on-disk components to Emond as well. The launchd config file is located where other system daemons reside: /System/Library/LaunchDaemons/com.apple.emond.plist.
This determines when the Emond binary is executed, along with any desired options that are regularly used with LaunchDaemons. The emond.plist config file is located in the /etc/emond.d/ directory. This file defines the locations for rules paths, UID/GID filters, error and event log paths, and a few other options.
Rules are stored in the /etc/emond.d/rules/ directory and they should be in plist format.
Emond starts during the boot process when using the run command action, so it can be leveraged as a persistence method used by adversaries.
How to Detect it?
Emond configuration files are not modified frequently. Therefore, we recommend detecting creation of new files (aka new rules) that are added to Emond rules folder /etc/emond.d/, create new client file in the /private/var/db/emondClients directory (no clients exists by default), or modifying of configuration file /System/Library/LaunchDaemons/com.apple.emond.plist.
Detection with a lower level of confidence may detect any process creation that relates the files in the/etc/emond.d/ directory (where Emond rules are stored). For example, copy to temp directory or read the configuration files using cat or ls commands. The detection should have a whitelist of backup or updated system files that manipulate Emond configuration files innocently in order to avoid false positives.
The following code implements the detection logic:
Launchctl
Our third detection method focuses on a way to load system services with a launchctl command. That will allow an attacker to get both execution and persistence if the service is defined to be loaded on boot.
Launchctl interfaces with launchd. Adversaries use launchctl to execute commands and programs as Launch Agents or Launch Daemons. Common subcommands include: launchctl load, launchctl unload, and launchctl start.
Attackers can use this method to load services that will be set to run at boot, which can aid in achieving persistence (Create or Modify System Process), or for one-time or temporary execution.
How to Detect it?
Launchctl command is commonly used; therefore, detection of every process creation will raise a lot of false-positive alerts. We suggest detecting loading of a plist file from a suspicious location, such as the home directory, current directory, /tmp or /shared. It's important to include a whitelist of processes that runs this command innocently from those locations, such as jamf. While in some environments, loading plist files using launchctl from a suspicious location can be more frequent, we developed a prevalent values scoring model that will learn from past cases and will only detect anomalies.
For further investigation, we also suggest looking into the network connections that have been done by the plist that was loaded. Any suspicious connection can indicate a C2 communication.
Summary
We have presented three different detection methods with different difficulty levels. We highly recommend implementing these detection methods today to enhance the level of macOS detection in your organization.
Follow our blog as we publish more detection methods and different researches that we conduct to help the community grow.
