Attack Detection Fundamentals 2021: macOS - Lab #3

As we enter the final Lab of F-Secure Consulting's Attack Detection Fundamental's macOS workshop we must reflect on what we have a covered so far. To this point we have analysed potential initial access techniques, how attackers may then persist on compromised devices, and how these attacks may be detected. 

A recording of this workshop series can be found here and the slides are available here.

Now within this workshop we are going to take an alternative angle - what can an attacker do once on the device? This post exploitation workshop focusses on bypassing certain security and privacy controls that Apple has included within macOS. The objective of this lab will be to demonstrate the background behind the target control, how it benefits users and importantly how it can be bypassed. Following the theme of this series, we will then highlight key events within this type of attack that we can develop detection points around.


Picture the scene - you've popped a shell on your target's box, compromised their credentials and yet you're still getting permission denied when attempting to access their documents. This would be the work of Apple's Transparency, Consent & Control (TCC) security mechanism. In short, TCC utilises a database file on disk that keeps track of the functionality and storage locations within a device a given program is able to access. For example, within the Security & Privacy settings of a macOS device you can view the applications that are permitted to access functionality such as the camera:

workshop3 7

For those of us familiar with macOS devices we have all seen plenty of these access requests:

workshop3 6

Upon permitting or denying an application access to a certain component of your device e.g. your webcam, or alternatively a storage location such as your "Documents" folder, TCC stores this response within one of the following databases:

  • ~/Library/ApplicationSupport/
  • /Library/ApplicationSupport/ 


For the purpose of this workshop, let's assume that we have a Terminal/iTerm instance on our target machine, and we are unable to access our user's documents. In an attempt to avoid raising suspicion, we want to find an alternative method of gaining access to these documents without prompting the user.

What about directly editing the "~/Library/ApplicationSupport/" file we mentioned earlier? Unfortunately, to edit the contents of this file, the interacting program must have full disk access. Given that we're unable to access the "Documents" folder, we can infer this is something that we do not have. It's also worth noting that attempting to access a component/storage area that has not previously been requested by the program may trigger a prompt for the user, thus alerting them to something suspicious.

Thankfully for offensive operators however, there are ways to bypass this restriction, given that SSH is enabled and we have the credentials for our target user.

By default when enabled, the SSH process is provided with full disk access to the target device:

workshop3 8

Consequently, given we have valid credentials for the device, we can SSH locally and provide ourselves with Full Disk Access; subsequently gaining the ability to directly edit the TCC database. To demonstrate the ability to directly interact with the TCC database, we are going to try and provide iTerm with the permissions required to access the "Documents" folder, which as we can see it currently does not possess:

> ls /Users/calumhall/Documents
ls: Documents: Operation not permitted

Firstly, SSH into the device locally (e.g. ssh calumhall@localhost) and utilise macOS's inbuilt sqlite3 tool to alter the ~/Library/Application Support/ database. This can be done using one of the following commands depending on whether a permissions entry has already been created within the database:

INSERT INTO access values('kTCCServiceSystemPolicyDocumentsFolder', 'com.googlecode.iterm2', '0', '2', '2', '1', '', '', '0', 'UNUSED', '', '0', '1617801709');

UPDATE access SET auth_value=2, auth_reason=2 WHERE client="com.googlecode.iterm2" AND service="kTCCServiceSystemPolicyDocumentsFolder";

At which point, upon restarting the application, iTerm will have been provided access to the "Documents" folder:

> ls /Users/calumhall/Documents/

$RECYCLE.BIN Hackfu Reading Business Documents Presentations Tools Detection Work Research Training

Detection Methods

When we break down the attack we just performed, there are two key points of interest that we are able to gather accurate telemetry for:

  • Local SSH connection
  • Directly editing the TCC database

As you will notice throughout this workshop we employ a variety of open source tools to analyse and gather telemetry. This is largely to encourage you to use whatever solution works best for your environment, here we have predominantly used Objective-See's tools as they are open source and easy to use. The telemetry these tools gather is largely collected from Apple's inbuilt utilities, and hence these events should be solution agnostic.

Local SSH Connection

Detecting an SSH connection, something we've done a thousand times with other operating systems, easy right? Well kind of. As with many of the attacks discussed within this workshop there are plenty of detection methods, here let's discuss the pros and cons of each of the following:

  • Network connection monitoring
  • Process monitoring (ESF)
  • SSH logging
  • Unified log entries

Now firstly prior to hopping into analysing any networking activity from the device it is important to call out the challenges we face with macOS devices. To fully utilise networking telemetry on macOS, you must be using software that uses a network extension. As this can be a challenge to acquire, this is not something we will cover in this workshop, however most EDR solutions should have this capability. Hence, that is likely to be the greatest source of telemetry for detecting local SSH connections.

For the purpose of this workshop let's use Objective-See's NetIQuette network monitoring tool (, to identify our SSH connection (ssh calumhall@localhost):

workshop3 9

Interestingly, localhost in this instance has resolved to the host's IPv6 local address ::1 rather than Not that this makes a difference, as I'm sure we are capable of monitoring for connections to both local addresses. This tool however is designed for individual users, not to aid detection at scale, and as such we must investigate alternative methods.

So how about ProcessMonitoring? We've seen so far throughout this workshop that process monitoring via the ESF has proved successful, let's hope it is once more. Realistically all we are interested in with this scenario is any SSH connection that is being performed against the local device. Hence, we don't need to worry all that much around the behaviour of anything past the initial SSH connection. The following event is generated by the ESF upon a local user initiating an SSH connection:

> ./ -pretty

{ "event": "ES_EVENT_TYPE_NOTIFY_EXEC", "timestamp": "2021-04-08 15:11:46 +0000", "process": { "pid": 11838, "name": "ssh", "path": "/usr/bin/ssh", "uid": 501, "architecture": "Intel", "arguments": [ "ssh", "calumhall@localhost" ], "ppid": 10555, "rpid": 5205, "ancestors": [ 5205, 1 ], "signing info (reported)": { "csFlags": 570522385, "platformBinary": 1, "signingID": "", "teamID": "", "cdHash": "B40199DE8184503EAD472866D76DFD98D319BE56" }, "signing info (computed)": { "signatureID": "", "signatureStatus": 0, "signatureSigner": "Apple", "signatureAuthorities": [ "Software Signing", "Apple Code Signing Certification Authority", "Apple Root CA" ] } } }

Of interest to ourselves in this scenario is the arguments included in the SSH event. We can see the destination this user is connecting to is 'localhost', hence we can filter for instances such as:

  • localhost
  • ::1

However, whilst we can use process monitoring, surely there has got to be some inbuilt logging for SSH that we can gather this telemetry from? Well if we look at /var/log/system.log after a successful local SSH attempt we can see that something happened however, it's not of much use:

Apr  8 16:44:43 Calums-MacBook-Pro sshd: calumhall [priv][12162]: USER_PROCESS: 12165 ttys003

Similarly, the entries within the Unified Log do not appear to provide any great amount of value.

To summarise, we are able to detect certain indicators from process monitoring, however the most valuable form of telemetry is going to come from monitoring network activity. Whilst we were not able to fully demonstrate this type of telemetry within this lab, for those of you deploying EDR solutions to your devices you should be able to gather this telemetry with ease.

Alternatively, the likes of Objective-See's Netiquette can be periodically executed from the command line on target devices. This way we can periodically gather information about the active network connections on the target devices.

Directly Editing the TCC Database

Secondly, let us once more investigate the ESF's ability to monitor files activity on device.

> sudo ./ -pretty

{ "event": "ES_EVENT_TYPE_NOTIFY_WRITE", "timestamp": "2021-04-07 21:36:08 +0000", "file": { "destination": "/Users/calumhall/Library/Application Support/", "process": { "pid": 6088, "name": "sqlite3", "path": "/usr/bin/sqlite3", "uid": 501, "architecture": "Intel", "arguments": [], "ppid": 5902, "rpid": 5897, "ancestors": [ 5897, 1 ], "signing info (reported)": { "csFlags": 570522385, "platformBinary": 1, "signingID": "", "teamID": "", "cdHash": "1D70249C9DFE22B9A20903424ACE0C010B630CA0" }, "signing info (computed)": { "signatureID": "", "signatureStatus": 0, "signatureSigner": "Apple", "signatureAuthorities": [ "Software Signing", "Apple Code Signing Certification Authority", "Apple Root CA" ] } } } }

As observed from the event generated above, we can create a high fidelity detection point by monitoring for the SQLite3 tool directly accessing the TCC.db file. Given that the Apple ecosystem interacts with the TCC.db database using the TCC Daemon (tccd). We can safely say that any direct access of the TCC.db file in this manner is likely malicious.


Within this lab we have demonstrated that the TCC mechanism may prove to be a sufficient security control against attackers with low privileged accounts on a device without SSH enabled. However, we have also shown that whilst TCC may prove a hurdle to offensive operators, it can be trivially bypassed given the necessary pre-requisites are met.

By investigating the telemetry for such an attack we have found the following detection points to be likely indicators:

  • Local SSH connections
  • Direct editing of the TCC database


Special shoutout to the following researchers whose work has formed the basis of this workshop series:

  • Patrick Wardle
  • Cody Thomas
  • Michael Jack
  • Cedric Owens
  • Csaba Fitzl
  • Jaron Bradley
  • Guillaume Ross
  • Howard Oakley
  • Phil Stokes
  • Madhav Bhatt
  • Adam Chester

And to anyone else that we have inevitably forgotten to mention.