In traditional Active Directory networks, corporate attacks repeat the process of escalating local privileges, retrieving cached credentials, and pivoting to additional hosts.
In decentralized networks, corporate attacks focus on compromising IAM administrators or targeting sensitive data directly. In addition, developers and other power users are often granted access to code repositories, CI/CD pipelines, or cloud resources which may indirectly expose unintended information to a compromised account.
The macOS Pivot extends the C2 with sensitive information discovery, attempted lateral movement, and environmental privilege escalation. Generally, the goals of the macOS Pivot can be summarized in the following three items.
Pivot to MDM or SSO Administrator
Exfiltrate Custom Code or Other Proprietary Data
Elevate Access to Control Public-Facing Endpoints
Command and Control
There are a couple of C2 frameworks that support macOS. I recommend the Mythic with the Apfell or poseidon agent.
Mythic C2 Setup
Mythic is a cross-platform C2 framework created by SpecterOps. There are several Mythic Agents available, many of which target macOS. The teamserver is implemented as a set of Docker containers. The repo includes a CLI tool for easy deployment:
TCC is a security control in macOS that prevents applications (even running as root) from accessing sensitive data and capabilities. The list of protected folders includes Documents, Desktop, and Downloads. The list of protected capabilities includes camera and microphone usage.
Applications are granted access to TCC-protected resources in their signature (Calendar.app is allowed to access the calendar) or by user prompts:
TCC cannot be “bypassed” without a vulnerability in the OS, but it can be avoided or circumvented.
Unprotected, Valuable Directories
Browser credentials and cookies:
~/Library/Application Support/Google/Chrome/Default~/Library/Application Support/Firefox/Profiles/[Random ID].default-release/cookies.sqlite
Various third-party applications and installers modify default directory permissions to create vulnerable scenarios. Our ability to escalation privileges depends on the applications installed on the system. There are three file permission scenarios we can quickly look for:
1. Direct Write Privileges
Directory privileges can extend or override file permissions. Even if a target file is owned by a different user, directory privileges may allow us to modify the file. Modifying files that applications don’t expect may allow us to replace binaries, change configurations, etc. For static analysis, try using enum_file_permissions.py or enum_file_permissions.sh to quickly discover potential issues (the Python script has been tested more, but th Bash script is a good fallback if Python is removed or blocked).
2. Path Hijacking
The directories listed it the PATH env var dictate how macOS searches for executables on the system. If we can write executables to a directory at the beginning of the path, it may be possible to trick a process running as root to execute the wrong file.
The default PATH, even for root, begins with /usr/local/bin. This is fine initially because only root can write to it, but third-party applications often misuse this directory. For example, the Brew package manager changes the permissions of the directory so the developer can install packages without root.
Common developer tools (Gcloud SDK, Node) may also prefix the root path with user-writeable directories.
3. Privileged Write
Applications with root privileges may copy or write files to an accessible path. If we can execute code before this write, we may be able to create a symlink at the write target that points to a file we want to overwrite. This technique can be used to overwrite service or startup scripts execute as root. For dynamic analysis, try using FileMonitor on a test machine with the same applications installed.
Exploitation of these vulnerabilities typically involves creating a symlink at the location a privileged application writes to. This symlink can create a new LaunchAgent/LaunchDaemon or potentially modify sensitive PAM config files.
I haven’t found a way to escalate using arbitrary file deletion.
Find a privileged helper tool in /Library/PrivilegedHelperTools/.
Use codesign -dv --entitlements :- /Applications/someapp.App/Contents/MacOS/someapp to check for injection opportunities in an XPC client (no hardened runtime, get-task-allow).
Open the helper tool in a dissassembler (Hopper, Ghidra), look for the shouldAcceptNewConnection method and check for validation.
If there is no signature validation, or there is signature validation but the PID validation uses processIdentifier instead of connection.auditToken you may be able to send data as an arbitrary client, or use PID reuse attack.
Use class-dump -C <PROTOCOL NAME> <PATH TO HELPER> to view the available methods. If any appear to be capable of code execution, file creation, or file copy/move, there may be an LPE. Open the associated function in the dissassebler and determine the usage.
If there are code repositories accessible by your account, look for plaintext secrets using TruffleHog
In addition, check in the settings for each repo to see if you can view CI/CD environment vairables. These often contain database credentials, API keys, etc. If you can get a registration token to register new runners, use this to create a new runner that builds the app. This can be used to steal source code and any environment variables used by the pipeline. More details here and here.
Similarly, you may be able to find renner tokens in the metadata of cloud resources. Popular IaaC templates like terraform-aws-gitlab-runner store runner registration tokens in EC2 user data. See AWS Recon & Exploitation from Mike Felch for more ideas.
Keychain Access
Keychain Access is Apple’s recommended method of storing sensitive data. It is comparable to DPAPI on Windows. Applications can store data in the default Keychain database without handling encryption themselves, reducing the chance of vulnerability.
The Keychain API verifies the code signature of any application that attempts to read secrets – owning a user session is not enough! Access can be achieved by injecting into a pemitted application. For more information, see Dylib Injection.
Jamf Password Spraying
Jamf is the the most common MDM solution for macOS - even Apple uses it! You can check whether your test device has Jamf in Settings under Profiles. Additionally, there should be a Jamf binary at /usr/local/jamf/jamf. Looking in settings has the added benefit of displaying the server URL (e.g., company.jamfcloud.com).
If the server is public, JamfSniper.py can be used to perform password spraying.
Kerberos Authentication
You can check to see whether Kerberos authentication is used with the klist command. If used, you should see at least one ticket for your user account.
You can use any existing tickets to access SMB shares in the environmont, without knowing the user’s password.
mount -t smbfs "//computer/share" /local/path
With a tool like Bifrost, we can even Kerberoast without knowing the user’s password.
# Get the kirbi-formatted TGT(s) from the hostbifrost -action dump -source tickets# Request a service ticket for offline crackingbifrost -action asktgs -service <SPN> -kerberoast true -ticket <BASE64 ENCODED TGT>
The first command will output a base64-encoded TGT in the .kirbi format tha Rubeus uses. You can convert it to a ccache file for use with Impacket using Impacket’s ticketConverter.py:
# Decode the TGT and save to diskecho -n "<BASE64 ENCODED TGT>" | base64 -d > tgt.kirbi# Convert the .kirbi to a .ccacheticketConverter.py tgt.kirbi tgt.ccache
Lateral movement on macOS can look very different than on Windows. There may not be a LAN you can pivot in. There is no concept of “pass-the-hash”, although you may be able to find Kerberos tickets, depending on the configuration. There are a few areas we can look for lateral movement opportunities.
macOS Devices
If there is a VPN or the device is connected to a company LAN, you may be able to pivot to other macOS systems. There are primarily three services that could allow remote control:
SSH - TCP/22. Often granted “Full Disk Access” in TCC.
VNC - TCP/5900. Will warn the user (Your screen is being observed).
AppleEvent - TCP/3031. Less common. Example usage in ahhh/AppleScripts.
You can also try MacHound to automate the discovery process, but I haven’t used it myself.
Another area of interest is Jamf remote management. If the environment uses Jamf, there is a management UI that allows administrators to install packages and change settings. All the Jamf management commands run as root and he management panel is usually public. You may be able to reuse credentials or password spray this endpoint. See macOS Credential Access for more details.
If the provided user account has cloud accounts, perform a quick triage for exposed credentials that you can try elsewhere. I’ve had good luck with the following in AWS:
EC2 User Data
# Get a list of EC2 instances and their IDsaws ec2 describe-instances# Replace <INSTANCE ID> with each returned valueaws ec2 describe-instance-attribute --instance-id <INSTANCE ID> --attribute userData | jq -r '.UserData.Value'
Lambda Environment Variables
# List all environment variablesaws lambda list-functions | jq -r '.Functions[].Environment.Variables'
CloudFormation Stack Parameters
# List all stack parametersaws cloudformation describe-stacks | jq -r '.Stacks[].Parameters'
As time permits, follow any remaining/relevant cloud recon methodologies:
/.././artifacts/macOS---TCC-Prompt.png)
If the server is public, JamfSniper.py can be used to perform password spraying.
