Return of the mac(OS): Transparency, Consent, and Control (TCC) Database Manipulation

Summary

Discover insights into prominent malware campaigns, their connections to Democratic People’s Republic of Korea (DPRK) adversary behaviors, and gain valuable insights on threat-hunting queries. This report will equip defenders with essential recommendations to safeguard against TCC.db abuse and stay ahead in the ever-changing cybersecurity landscape.

This technique will be included in the next MITRE ATT&CK Release scheduled for April 2024.

Preface

Historically, Windows has had a stronghold on the desktop market, and hence, security vendors focused their detection and prevention efforts primarily on Windows-based threats. However, over the years, corporations are increasingly leveraging MacBook laptops, and current trends indicate Apple is gaining market share, averaging 1% a year over the past 14 years (from 3% to 16.5%).

With macOS increasing in market presence, and in turn, eCrime and nation-state adversaries such as the Democratic People’s Republic of Korea (DPRK)-attributed Lazarus Group pivoting to macOS, awareness of current and emerging macOS techniques is crucial to ensuring holistic prevention. This report will dive into some recently observed bypasses and tactics on macOS, and how they are leveraged by adversaries and malware campaigns, with a behind-the-scenes look into my research and threat hunting, starting with the TCC database. Lastly, it will conclude with best practices and how defenders can detect or defend against these TTPs.

Primer on the TCC Database

For a deeper dive into the TCC framework, refer to Phil Stokes’ writeup. For those of us new to macOS internals, here is an abridged version: The TCC framework is responsible for user security and privacy controls on Apple devices. There are two TCC databases on Apple devices, one at the system level: /Library/Application Support/com.apple.TCC/TCC.db, and one at the user level: $HOME/Library/Application Support/com.apple.TCC/TCC.db. The system level TCC database is protected by System Integrity Protection (SIP), so it cannot be written to unless SIP is bypassed or disabled. The user level database can only be written to by a privileged process with proper entitlements, such as Full Disk Access (FDA).

If you have a keen eye, you’ll notice that TCC does not  protect all folders and data on macOS -this will be important in later discussions.

Tccd is the dedicated daemon for TCC; it exists for each logged-in user and system. This daemon is idle until it receives a request for an app to access TCC-protected data. The workflow is as follows:

What does TCC Protect?

As alluded to earlier, the TCC.db protects accessing specific folders, such as the Desktop and Documents. However, that does not prevent a user or unprivileged process from writing files to TCC “protected” areas and does not stop those files from being read. Therefore, malware authors could use these TCC protected areas as staging directories for their malware or secondary payloads.

Areas TCC does NOT protect:

We talked about areas TCC does protect, though incomplete in implementation. I would be remiss if I did not briefly mention some sensitive directories on macOS that are not protected by TCC, such as:

Problems with Full Disk Access (FDA)

One of the items encompassed by TCC is full disk access. If you are an admin, and you can grant yourself FDA, you will inherently grant ALL users (even non-admins!) the ability to read all other users’ data on disk, including your own.

Mounting Issues

In CVE-2020-9771 a disk can be mounted and read by non-admin users. Apple “patched” this issue in macOS Catalina 10.15.4 in 2019 and in macOS Mojave in 2018, but the fix is tied to restricting Full Disk Access (FDA) permissions (kTCCServiceSystemPolicyAllFiles) for Terminal. However, the challenge in this “fix” is that in many environments, Terminal may have FDA enabled for legitimate reasons, and many apps, including IT and security software agents, may leverage scripting (Terminal) and require full disk access (FDA) to properly function and protect the endpoint.

Additionally, an actor could mount over ~/Library/Application Support/com.apple.TCC with their fake TCC.db by preparing a new TCC.db file. Because TCC privacy is not enforced on mounted local snapshots, this allows an actor to mount and access any file inside. Additionally, initiating and listing APFS snapshots is available for all users, so anyone can mount local apfs snapshots if using “noowners” flag.

One Finder to Rule Them All

There is also an existing reflexive or chained “privilege escalation” via Finder. Finder, unbeknownst to the user, has access to FDA by default. If you are a keen investigator, you may notice that Finder is also not listed in your Security & Privacy permissions – it is transparent to the user. Also, if you grant Terminal access to Finder once, it is persistently granted. The user or admin would have to be aware of Finder’s access and manually revoke permission. Therefore, an actor could procure Terminal control the Finder to secure FDA.

Social Engineering

Finally, social engineering also works!

Malware authors have been observed directing users on how to override Gatekeeper step-by-step, bypassing any additional security controls that admins deployed via MDM.

Enter the Lazarus Group

During my ATT&CKCon talk, I discussed this DPRK adversary in depth, as I tracked this nation-state’s activities for a bit. The Lazarus Group is believed to operate out of North Korea, and has been active since 2009, gaining infamy over the years for high profile attacks against Sony, WannaCry, and recently JumpCloud, to name a few. With the poor state of the North Korean economy, Lazarus Group also is notable in their dual purpose of cyber espionage and nation-state financing. In 2023, they were heavily observed targeting cryptocurrency companies (no doubt, for said self-financing), and cross-platform attacks.

So why target macOS?

In recent years, Lazarus Group pivoted their targeting towards a more technical audience, having targeted security researchers in 2021 and engineers via social engineering methods using LinkedIn and email. With Operation Dream Job dating back to at least 2020, the Lazarus Group pretended to be cryptocurrency companies (as part of their cryptocurrency financing motives), targeting unsuspecting developers and engineering roles with the promise of lucrative (fake) jobs. In 2023, they continued this trend, impersonating large tech company recruiters, such as Amazon. With their targeting of engineers, I would expect their targets to be heavily leveraging macOS laptops.

Current desktop trends support this hypothesis. Stack Overflow conducted a survey in 2023, and out of over 87,000 developer responses, we see that macOS is gaining traction at 33%. With this shift, we are observing more adversaries adapting their tradecraft to be compatible with macOS (and Linux), and I would expect this trend to continue across adversaries.

Threat Hunting in VirusTotal

What do TCC interactions look like in the wild?

Important Disclaimer: I am by no means a VirusTotal query pro, and your mileage may vary depending on your subscription, date of query, etc.

Pulling on a Thread: Ties to North Korea

In tracking and researching Lazarus Group, I noted the heavy use of masquerading and TCC.db related activity. Specifically, I observed the following command line:

Lazarus Group appears to be attempting to dump the access table from the TCC.db, likely to assess what applications had access to what permissions (FDA). From this command, I tried various iterations keying off of the dumped access table:

Results: An inordinate number of hits 😮

Adding the access table as a criterion:

Results: 186 hits!

To my surprise, I received many hits for both queries, and wondered if this were a prolific but undocumented technique. However, upon examining this further, I realized VirusTotal was not using the quotes to denote a literal string, but instead treated the `.` as a wildcard, giving me thousands of unwanted results of any macOS file containing the “dump” string. Not to be defeated, I tried another angle. Knowing that the TCC.db is a SQLite3 database, that Lazarus leveraged bash and sqlite3 to run commands, and that many macOS malware will be DMG or Mach-O binaries, I searched for:

Results: 9 hits, all of which were popping up as “CloudMensis” malware. A quick google of CloudMensis gave me a Eureka moment.

CloudMensis is a macOS malware attributed to North Korean adversary APT37 (aka InkSquid, RedEyes, BadRAT, Reaper or ScarCruft). Pouring into the 9 samples I found on VT, CloudMensis consistently leverages csrutil to query the status of SIP protection, grepping for anything disabled, and proceeds to either directly INSERT into screencapture and FaceTime access or in other samples, add all relevant permissions line by line into the TCC.db. In parallel, the actor creates a new database in ~/Library/Application Support/com.apple.spotlight/Library/Application Support/com.apple.TCC/ and sets the HOME environment variable to ~/Library/Application Support/com.apple.spotlight using launchctl setenv. Lastly, it restarts tccd so that the TCC daemon loads the actor-controlled database.

Looking for command line parameters in VirusTotal, I leveraged this query:

Results: 35 hits total. Rummaging through the results, 8 hits tied back to CloudMensis.

CloudMensis uses two techniques to bypass TCC, and if successful, gains access to the screen, scans removable storage for documents of interest, and logs keyboard events. Performing screen capture requires bypassing TCC restrictions via exploiting CVE-2020-9934. Either the target hosts were known to be running macOS Catalina 10.5.6 or earlier, or the malware contained legacy code that the developers forgot to remove.

If SIP is disabled, CloudMensis adds entries to the TCC.db to grant itself permissions. If SIP is enabled but the Mac is running any version of macOS Catalina earlier than 10.15.6, CloudMensis will exploit a vulnerability to make the TCC daemon (tccd) load a database CloudMensis can write to (CVE-2020–9934)

Thankfully for defenders, CloudMensis malware seems to be mitigated if enterprises are using up-to-date MacBook’s and SIP is enabled.

Casting A Wide Net: Keyloggers, Adware, Trojans, Oh My!

It is likely (if not inevitable) that attackers within the same nation-state will share code or adversarial practices. The DPRK is clearly no stranger to TCC abuse. I was curious how often other malware authors abused the TCC framework. I decided to start broadly in my queries, looking for ANY TCC interactions.

Results: 37 hits! Less than half were confirmed malware: Bundlore, CloudMensis again, Callisto (which I will detail below), the BlueBlood keylogger, and unspecified macOS Trojans the antiviruses comprising VirusTotal have yet to label.

I am assuming the BlueBlood keylogger samples I have corresponds to the BlueBlood keylogger that has been around for years. It uses INSERT or REPLACE to add access for appID, “com.applle.blblu,” named in this fashion likely to masquerade as an Apple sanctioned appID for the accessibility list on macOS (kTCCServiceAccessibility).

Bundlore is a notorious macOS adware that has also been around since 2015 and gained notoriety in 2019. Bundlore, in older versions, will modify the TCC in a similar way to BlueBlood; i.e. if macOS version is 10.12 or older and Safari version is 10.0 or older, it modifies the TCC.db to enable AppleScript accessibility access to applications like Terminal, Safari, Apple Remote Desktop Agent, or Bash, so that it can interact with them.

In other Bundlore samples, I noted the use of the cp command to copy the entire TCC.db as a backup.

Both Bundlore and BlueBlood leveraged insert and replace logic, so I narrowed my search to home in on these tactics, starting with REPLACE.

Results: 4 hits attributed to Callisto, a different macOS backdoor that some sources state serves as the forerunner of the Proton family of malware. Notably, like Bundlore, it leveraged insert and replace commands to manipulate the TCC.db.

Note: I reran the same query without the unsigned qualifier, and still got the 4 Callisto hits, which indicates that at the very minimum, the 4 Callisto samples were all unsigned. I’ll dive into unsigned and ad hoc signed binaries in a future writeup.

It is worth noting that CoreServices folder (hidden in the System Library folder), which among other things, controls which apps have Accessibility authorization, became protected under SIP in 10.12 Sierra, so Callisto malware, like many malware that abuse TCC, will fail on SIP-protected machines running Sierra or later.

Repeating this query with INSERT commands:

Results: 11 hits, 10 of which were confirmed malware samples (but the “unconfirmed” sample looked highly suspicious).

Note: I added signature status again to test my hypothesis, and all samples were in fact unsigned.

Combining all of the observed TCC.db abuse commands:

Results: 41 hits, less than half were confirmed malware. I’ll take it!

Not on the Guest List

As I was pouring over samples and hits from my VT hunts, it dawned on me that a few malware campaigns that I know interacted with TCC were notably absent from my results.

JokerSpy is a malware leveraging SwiftBelt that targeted a cryptocurrency exchange in Japan, installing backdoors and deploying spyware.  It creates a new TCC database and replaces the existing legitimate TCC database, leveraging the binaries xcc and cp.

Interestingly enough, JokerSpy samples did not show up in my TCC.db query results. It is therefore likely that the copying of the TCC and related interactions via command line were decoupled from the JokerSpy malware itself, thus not triggering on VT.

XCSSET

While I was researching TCC bypasses, I came across XCSSET, another malware sample absent from my VT hunt results. Digging into how this campaign operates, the developers of XCSSET used three zero-days to bypass privacy protections, the last of which was used to bypass TCC framework, allowing them to take screen captures by hijacking the entitlements of other apps on the system. XCSSET malware is hardcoded with a list of apps it expects to have screen capture permissions, such as Zoom, Discord, WhatsApp, Teamviewer, etc. Using mdfind, it checks if the appIDs of those apps are present. If present, it will inject its own malicious app into the bundle of any of those apps, that way they can piggyback off the screen sharing permission granted to apps as part of their normal operation. From the XCSSET samples I found, the XCSSET AppleScript screenshot modules, downloaded from the malware author’s command and control (C2) server were responsible primarily for the TCC bypass, and did not key off any TCC.db strings or sqlite3 commands.

If XCSSET fails to find or inject into those apps, it will impersonate Finder to ask user to grant Finder access. The malicious app can take screenshots or record the screen without needing explicit consent from the user because it inherits those TCC permissions from the parent app.

Therefore, a malicious actor could do the following to bypass the user TCC:

Appendix

Other Techniques – Discovery

Adversaries performed TCC.db privacy setting enumeration and discovery by using SELECT statements in sqlite3:

On macOS 11 BIG SUR and later:
sudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db “SELECT client,auth_value FROM access WHERE service==’kTCCServiceSystemPolicyAllFiles” | grep ‘2’$

On macOS 10.15 Catalina and earlier:
sudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db “SELECT client,auth_value FROM access WHERE service==’kTCCServiceSystemPolicyAllFiles” | grep ‘1’$

Coming Back Empty Handed from the (VirusTotal) Hunt

Querying for Full Disk Access
content:kTCCServiceSystemPolicyAllFiles or behaviour:kTCCServiceSystemPolicyAllFiles
3 hits: (at the time of discovery) a day-old Pearcleaner macOS trash cleaner opensourced on Github. It is unclear if this is a viable or high-fidelity query currently.

To mount or not to mount
I investigated the apfs mounting bypass I detailed earlier, noting the “noowners” flag.

(type:dmg or type:macho) behaviour:mount behaviour:noowners
Results: 6 hits, all benign.

behaviour:attach AND behavior:mountpoint AND behavior:com.apple.TCC
Results: 1hit, an Adobe update script

(type:dmg or type:macho) AND behaviour:mount AND behavior:apfs AND behaviour:noowners
Results: 4 hits, all benign.

Keying off of “noowners” and various mounting parameters, there did not seem to be a use case for this occurring in the wild. Notably, there were very few hits, and all were false positives. It is also possible that a malicious actor could do this interactively (or hands-on-keyboard), again decoupling it from the malware/file itself. However, given the low frequency in which this type of mounting behavior occurs, it still might be a worthwhile detection opportunity in an EDR or SIEM solution.