At the last internal pentest, fintech companies 14 of the 18 workstations were on macOS Sequoia with M3 chips. Cobalt Strike beacon, SharpHound, Rubus - all familiar arsenal was useless in the first two days. Just don't start. It was necessary to rebuild the whole kill chain for a platform that most pentesters still bypass - they say, "there are no points in". It's happening. And more and more. This article is the result of that project: a full chain of attack on macOS, from fingerprinting hosts to fixing in the system, with specific commands and an honest indication where the equipment works and where it no longer is.
Fingerprinting macOS host: recon to the first payload
[Applicable: internal pentest, grey/black box]
Before sending payload, you need to know what you are dealing with. On macOS fingerprinting solves three tasks: to determine the architecture of the processor (arm64 vs x86_64), the exact version of macOS and the presence of Rosetta 2. On these three parameters depends the choice of payload, C2-agent and the envoice vector. You are mistaken in architecture - you will lose time on binary cars that will not even start.
Bash:
With Rosetta 2 there is a nuance: process oahd lazily is launched (only when x86_64-code is executed), so pgrep can give false negative. More reliable - arch -x86_64 /usr/bin/true 2>/dev/null or pkgutil --pkgs | grep -i Rosetta. Without Rosetta 2, no x86_64 C2 agent will run. The Point.
From the network, without shell, fingerprinting is more complex. macOS responds to ICMP by default, but when the Firewall setup is silent; on enterprise machines with a managed firewall profile, ICMP is often blocked. But Bonjour/mDNS can reveal the host name and services - dns-sd -B _services._dns-sd._udp local. with other macOS-machine or nmap with --script=dns-service-discovery. Limitation: mDNS works only in one L2-segment. In segmented networks (and fintech is usually well segmented) will have to work through ARP-scan.
Place in kill chain: fingerprinting is the precursor to initial access. Without knowledge of architecture and macOS version, you will spend time on payloads that will not start.
Initial access: payload, Gatekeeper and Apple Silicon
Initial access to macOS comes through: malicious documents, scripts (osascript, Python, shell), binary payloads or installer packages (.pkg). Each of these vectors stumbles upon Gatekeeper - the first line of defense macOS.
Bypass Gatekeeper (T1553.001, Defense Evasion)
Gatekeeper checks the attribute com.apple.quarantine downloaded files and blocks unsigned or non-tarated code. Here it is interesting: the attribute is put automatically when downloading through the browser. When delivered through curl, scp or rsync - not put it, and Gatekeeper is silent. AirDrop, like browsers, puts a quarantine attribute via the LaunchServices API; but when unpacking the archive with third-party utilities, the attribute may not be used to the content (and this is already an interesting vector).
Check the presence of the flag: xattr -l <файл>. Removal: xattr -d com.apple.quarantine <файл> - but for this you need access to the terminal. On an internal pentest, where the file is delivered through a corporate file server or MDM profile, quarantine-attribute is often not originally available initially. Consider a gift.
When the technique is NOT working: Starting with macOS Ventura, the notarization test has become stricter for applications from .dmg/.zip quarantine - unsigned app bundle will be blocked when running through Finder. Without quarantine unsigned, the binary starts normally. Launch via Terminal (chmod +x && ./binary) bypass the Gatekeeper-check, but requires interaction with the user or already available shell.
Apple Silicon and Compatibility of Payloads
Most C2 frames still generate x86_64-binarnes. On the Apple Silicon (M1-M4) without the installed Rosetta 2 such payload just will not start - and this breaks the standard approach "generated msfennom -> delivered -> received shell."
According to the study Schellman, with the macOS pentest on M1 payload poseidon From Mythic C2, compiled for x86_64, refused to start without Rosetta 2. The work solution – apfellAn agent that works through osascript (AppleScript, T1059.002, Execution) and does not depend on the processor architecture. Callback through the osascript passes on the arm64 without problems - it's a native interpreter of macOS, it is on every poppy.
If Rosetta 2 is installed, you can accelerate the architecture: arch -x86_64 ./poseidon. And when delivered via a installer-package (.pkg) in the postintsall script, you can quietly put Rosetta 2 with one line: /usr/sbin/softwareupdate --install-rosetta --agree-to-license. The user will not see anything.
Another nuance of .pkg-packages: the Distribution file contains a field hostArchitectures. Many packages only indicate x86_64 - on the Apple Silicon installer will refuse to run such .pkg. Addition arm64 solves the problem in this field. According to Schellman, this is the only modification necessary for compatibility.
Place in kill chain: initial access -> primary callback on C2 -> enumeration and privilege escalation.
TCC and SIP: two barriers that are not on Windows
[Applicable: internal pentest, Apple Silicon and Intel]
If you’re used to Windows, where UAC is the only popup between you and SYSTEM, there are more surprises on macOS. Two mechanisms radically change the approach to macOS post-exploitation: TCC and SIP. On the Windows pentest, I would have been in the domain for a long time, and here you sit and deal with the rights to access the microphone.
TCC Manipulation (T1548.006, Privilege Escalation / Defense Evasion)
TCC (Transparency, Consent, and Control) monitors the access of applications to sensitive resources: camera, microphone, contacts, Full Disk Access, automation via AppleScript. And here’s the important thing: root process does not automatically receive TCC permits (FDA, camera, etc.) through the API – to access secure resources, you need a clear record in TCC.db. At the same time, system TCC.db is protected by SIP and is not available for modification even root. Closed circle.
User base: ~/Library/Application Support/com.apple.TCC/TCC.db. Reading: sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db "SELECT service, client FROM access". The system base is protected by SIP and requires the FDA for reading – every pentester faces this at the first attempt to work with TCC.
Manipulation of TCC in 2026 is one of the hottest themes in macOS offensive security. Direct modification of TCC.db is impossible when SIP is included. Current approaches are in operation of applications that already have TCC permits (for example, Terminal with the FDA), and use them as proxies to access secure resources. Each macOS update closes several such paths - on Sequoia most of the known bypasses of outdated versions no longer work.
System Integrity Protection and AMFI
SIP protects system directories (/System, /usr with the exception of /usr/local, /bin, /sbin) and critical processes from modification even root. Status: csrutil status. On corporate machines, SIP is almost always included.
For the SIP pencilator, it means: system binaries cannot be replaced, unsigned kexts cannot be downloaded, system TCC.db cannot be modified. You have to work in the user space - and you need to get used to it.
AMFI (Apple Mobile File Integrity) is a related mechanism that checks the signatures of the code when downloading. On the Apple Silicon AMFI, it works more aggressively than on Intel: unsigned, the code loaded into memory is blocked at the core level. This directly hits dylib injection and runtime hooking - techniques that worked on Intel-machoms without a signature.
macOS post-exploitation: enumeration and credential access
After callback on C2 - first of all: list users, check your belonging to the AD domain and assemble credentials.
dscl . ls /Users lists all users, including system - there may be more than 140 on a clean macOS (don't be afraid, it's normal). Detailed information for the user: dscl . cat /Users/<username> - displays the attributes of OpenDirectory, including UniqueID (UID) and GeneratedUID, and for AD-conjungunate hosts - SMBSID, useful when working with Active Directory.
If macOS is entered into the AD domain (verification: dsconfigad -show), through dscl Listed domain objects: dscl "/Active Directory/<DOMAIN>/All Domains" ls /Users - users, ls /Groups - groups, ls /Computers - cars in the domain. From the inference, you can set password policies and domain structure.
OPSEC-warning: On large domains (10k+ objects), these commands generate noticeable traffic to DC, can lead to timeouts and trigger AD-monitoring alerates. Better - targeted queries for specific OU or attributes (dscl ... read /Users/<username>)
osquery is a good tool for host-based intelligence, often already installed as part of fleetmanagement (Kolide, FleetDM). Request SELECT FROM user_ssh_keys show the SSH keys, SELECT FROM disk_encryption status FileVault, SELECT * FROM browser_plugins - browser extensions. Low profile: Osquery does not create new processes and does not modify the file system.
Keychain: access to stored accounts ([URL='https://attack.mitre.org/T1555/001, Credential Access)[/URL]
macOS Keychain - centralized storage of passwords, certificates and tokens. From the context of the current user security find-generic-password -wa "<service_name>" will remove the password for a particular service if the call process has an ACL-permission in Keychain. Mass Damp through security dump-keychain -d will require confirmation through the GUI-dialogue for each element - dreary, but otherwise in any way. In the SSH/headless session without an active GUI-session of the user prompt - the command freezes will freeze or return errSecAuthFailed. You need an active user session with unlocked Keychain.
When the technique is NOT working: starting with macOS Sonoma, Apple has strengthened interactive verification when accessing Keychain. Automated extraction without user interaction has become much more difficult. In practice - a targeted attack on specific records through the name of the service, and not an attempt at a mass dump. There is no complete Mimikatz for Keychain - there are point utilities, but not a single complex tool.
Plist configuration files (T1647, Plist File Modification, Defense Evasion) - another source of data. defaults read <domain> reads the parameters of applications, and plutil -convert xml1 <file.plist> converts binary plist to read XML. Corporate VPN configurations, email client settings, and MDM profiles are stored in plist and may contain sensitive data.
Persistence at macOS: LaunchAgents, LaunchDaemons and Dylib Hijacking
[Applicable to: Internal Pumption, After Foothold and POWER Scalation]
The three main persistence mechanisms on macOS, each with different levels of privilege and visibility.
LaunchAgent (T1543.001, Persistence / Privilege Escalation) is launched in the context of the current user with a login. Plist files are placed in ~/Library/LaunchAgents/ (user) or /Library/LaunchAgents/ (for all users). Does not require root for the user directory - and this is its main advantage.
LaunchDaemon (T1543.004, Persistence / Privilege Escalation) starts from root when the system is loaded. Plist-files - in /Library/LaunchDaemons/. Requires root for placement, but gives maximum privileges.
Restriction against EDR: LaunchAgents/LaunchDamons are monitored by all serious endpoint solutions. CrowdStrike Falcon through the Endpoint Security Framework receives notifications about the creation of plist files in these directories. SentinelOne tracks behavioral anomalies: the new LaunchDaemon with unsigned binary will cause an alterth. Neoming for legitimate Apple services (com.apple.*) will attract less attention in manual analysis, but the automatic correlation with the whitelist of real services Apple can issue a fake.
Dylib Hijacking (T1574.004, Persistence / Privilege Escalation / Defense Evasion)
macOS-applications download dynamic libraries (.dylib) from the paths specified in the Mach-O header. If the app is looking for dylib on the way where the file is missing or the directory is available for a record, here's the vector for hijacking.
Search for vulnerable applications: otool -L /path/to/binary will show all downloaded dylibs. A non-existent path or directory with access to entry is a potential point of implementation.
When the technique is NOT working: Apps from the App Store use Hardened Runtime, which blocks the download of dylib from non-standard ways. System applications are protected by SIP. On the Apple Silicon AMFI blocks unsigned dylib - a minimum ad-hoc signature is required (codesign -s - <dylib>) The technique is relevant for third-party applications installed outside the App Store - they are usually enough in the corporate environment.
Lateral movement and evasion: macOS as a point of entry into the domain
[Applicable to: internal pentest, post-exploitation, AD-conjugate environments]
Lateral movement from the macOS host most often goes through: SSH (embedded client, keys in ~/.ssh/), SMB for Windows hosts (smbclient or impacket), VNC for other poppies. Kerberos-tickettes, if macOS in AD-domain, are available through klist.
To move to Windows domain - impacket It works for macOS native through Python. Through proxychains You can route traffic via the Mythic C2 channel to access the internal segments.
Endpoint Security Framework and bypassing the protection of macOS
The Apple Endpoint Security Framework (ESF) is a user-space API through which EDR access file system events, processes, networks and authentication. Replacing outited kext-based mechanisms, and the main reason why evasion on macOS has become more difficult in the last couple of years.
OPSEC-recommendations when working with macOS-targets:
• osascript-based payloads (appell in Mythic) leave fewer artifacts on the file system than compiled binary
• LaunchAgent (User context) less than triggerite alertes than LaunchDaemon, but both monitor the ESF-based EDR
• Pattern curl | bash- antipattern: ESF logs the link network request + exec as a single chain. Don't do that
• Avoid mass-enumberation through dsclin the cycle - a pack of the same type of requests to Directory Services generates noise, which is visible to the naked eye
Fingerprinting macOS host: recon to the first payload
[Applicable: internal pentest, grey/black box]
Before sending payload, you need to know what you are dealing with. On macOS fingerprinting solves three tasks: to determine the architecture of the processor (arm64 vs x86_64), the exact version of macOS and the presence of Rosetta 2. On these three parameters depends the choice of payload, C2-agent and the envoice vector. You are mistaken in architecture - you will lose time on binary cars that will not even start.
Bash:
With Rosetta 2 there is a nuance: process oahd lazily is launched (only when x86_64-code is executed), so pgrep can give false negative. More reliable - arch -x86_64 /usr/bin/true 2>/dev/null or pkgutil --pkgs | grep -i Rosetta. Without Rosetta 2, no x86_64 C2 agent will run. The Point.
From the network, without shell, fingerprinting is more complex. macOS responds to ICMP by default, but when the Firewall setup is silent; on enterprise machines with a managed firewall profile, ICMP is often blocked. But Bonjour/mDNS can reveal the host name and services - dns-sd -B _services._dns-sd._udp local. with other macOS-machine or nmap with --script=dns-service-discovery. Limitation: mDNS works only in one L2-segment. In segmented networks (and fintech is usually well segmented) will have to work through ARP-scan.
Place in kill chain: fingerprinting is the precursor to initial access. Without knowledge of architecture and macOS version, you will spend time on payloads that will not start.
Initial access: payload, Gatekeeper and Apple Silicon
Initial access to macOS comes through: malicious documents, scripts (osascript, Python, shell), binary payloads or installer packages (.pkg). Each of these vectors stumbles upon Gatekeeper - the first line of defense macOS.
Bypass Gatekeeper (T1553.001, Defense Evasion)
Gatekeeper checks the attribute com.apple.quarantine downloaded files and blocks unsigned or non-tarated code. Here it is interesting: the attribute is put automatically when downloading through the browser. When delivered through curl, scp or rsync - not put it, and Gatekeeper is silent. AirDrop, like browsers, puts a quarantine attribute via the LaunchServices API; but when unpacking the archive with third-party utilities, the attribute may not be used to the content (and this is already an interesting vector).
Check the presence of the flag: xattr -l <файл>. Removal: xattr -d com.apple.quarantine <файл> - but for this you need access to the terminal. On an internal pentest, where the file is delivered through a corporate file server or MDM profile, quarantine-attribute is often not originally available initially. Consider a gift.
When the technique is NOT working: Starting with macOS Ventura, the notarization test has become stricter for applications from .dmg/.zip quarantine - unsigned app bundle will be blocked when running through Finder. Without quarantine unsigned, the binary starts normally. Launch via Terminal (chmod +x && ./binary) bypass the Gatekeeper-check, but requires interaction with the user or already available shell.
Apple Silicon and Compatibility of Payloads
Most C2 frames still generate x86_64-binarnes. On the Apple Silicon (M1-M4) without the installed Rosetta 2 such payload just will not start - and this breaks the standard approach "generated msfennom -> delivered -> received shell."
According to the study Schellman, with the macOS pentest on M1 payload poseidon From Mythic C2, compiled for x86_64, refused to start without Rosetta 2. The work solution – apfellAn agent that works through osascript (AppleScript, T1059.002, Execution) and does not depend on the processor architecture. Callback through the osascript passes on the arm64 without problems - it's a native interpreter of macOS, it is on every poppy.
If Rosetta 2 is installed, you can accelerate the architecture: arch -x86_64 ./poseidon. And when delivered via a installer-package (.pkg) in the postintsall script, you can quietly put Rosetta 2 with one line: /usr/sbin/softwareupdate --install-rosetta --agree-to-license. The user will not see anything.
Another nuance of .pkg-packages: the Distribution file contains a field hostArchitectures. Many packages only indicate x86_64 - on the Apple Silicon installer will refuse to run such .pkg. Addition arm64 solves the problem in this field. According to Schellman, this is the only modification necessary for compatibility.
Place in kill chain: initial access -> primary callback on C2 -> enumeration and privilege escalation.
TCC and SIP: two barriers that are not on Windows
[Applicable: internal pentest, Apple Silicon and Intel]
If you’re used to Windows, where UAC is the only popup between you and SYSTEM, there are more surprises on macOS. Two mechanisms radically change the approach to macOS post-exploitation: TCC and SIP. On the Windows pentest, I would have been in the domain for a long time, and here you sit and deal with the rights to access the microphone.
TCC Manipulation (T1548.006, Privilege Escalation / Defense Evasion)
TCC (Transparency, Consent, and Control) monitors the access of applications to sensitive resources: camera, microphone, contacts, Full Disk Access, automation via AppleScript. And here’s the important thing: root process does not automatically receive TCC permits (FDA, camera, etc.) through the API – to access secure resources, you need a clear record in TCC.db. At the same time, system TCC.db is protected by SIP and is not available for modification even root. Closed circle.
User base: ~/Library/Application Support/com.apple.TCC/TCC.db. Reading: sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db "SELECT service, client FROM access". The system base is protected by SIP and requires the FDA for reading – every pentester faces this at the first attempt to work with TCC.
Manipulation of TCC in 2026 is one of the hottest themes in macOS offensive security. Direct modification of TCC.db is impossible when SIP is included. Current approaches are in operation of applications that already have TCC permits (for example, Terminal with the FDA), and use them as proxies to access secure resources. Each macOS update closes several such paths - on Sequoia most of the known bypasses of outdated versions no longer work.
System Integrity Protection and AMFI
SIP protects system directories (/System, /usr with the exception of /usr/local, /bin, /sbin) and critical processes from modification even root. Status: csrutil status. On corporate machines, SIP is almost always included.
For the SIP pencilator, it means: system binaries cannot be replaced, unsigned kexts cannot be downloaded, system TCC.db cannot be modified. You have to work in the user space - and you need to get used to it.
AMFI (Apple Mobile File Integrity) is a related mechanism that checks the signatures of the code when downloading. On the Apple Silicon AMFI, it works more aggressively than on Intel: unsigned, the code loaded into memory is blocked at the core level. This directly hits dylib injection and runtime hooking - techniques that worked on Intel-machoms without a signature.
macOS post-exploitation: enumeration and credential access
After callback on C2 - first of all: list users, check your belonging to the AD domain and assemble credentials.
dscl . ls /Users lists all users, including system - there may be more than 140 on a clean macOS (don't be afraid, it's normal). Detailed information for the user: dscl . cat /Users/<username> - displays the attributes of OpenDirectory, including UniqueID (UID) and GeneratedUID, and for AD-conjungunate hosts - SMBSID, useful when working with Active Directory.
If macOS is entered into the AD domain (verification: dsconfigad -show), through dscl Listed domain objects: dscl "/Active Directory/<DOMAIN>/All Domains" ls /Users - users, ls /Groups - groups, ls /Computers - cars in the domain. From the inference, you can set password policies and domain structure.
OPSEC-warning: On large domains (10k+ objects), these commands generate noticeable traffic to DC, can lead to timeouts and trigger AD-monitoring alerates. Better - targeted queries for specific OU or attributes (dscl ... read /Users/<username>)
osquery is a good tool for host-based intelligence, often already installed as part of fleetmanagement (Kolide, FleetDM). Request SELECT FROM user_ssh_keys show the SSH keys, SELECT FROM disk_encryption status FileVault, SELECT * FROM browser_plugins - browser extensions. Low profile: Osquery does not create new processes and does not modify the file system.
Keychain: access to stored accounts ([URL='https://attack.mitre.org/T1555/001, Credential Access)[/URL]
macOS Keychain - centralized storage of passwords, certificates and tokens. From the context of the current user security find-generic-password -wa "<service_name>" will remove the password for a particular service if the call process has an ACL-permission in Keychain. Mass Damp through security dump-keychain -d will require confirmation through the GUI-dialogue for each element - dreary, but otherwise in any way. In the SSH/headless session without an active GUI-session of the user prompt - the command freezes will freeze or return errSecAuthFailed. You need an active user session with unlocked Keychain.
When the technique is NOT working: starting with macOS Sonoma, Apple has strengthened interactive verification when accessing Keychain. Automated extraction without user interaction has become much more difficult. In practice - a targeted attack on specific records through the name of the service, and not an attempt at a mass dump. There is no complete Mimikatz for Keychain - there are point utilities, but not a single complex tool.
Plist configuration files (T1647, Plist File Modification, Defense Evasion) - another source of data. defaults read <domain> reads the parameters of applications, and plutil -convert xml1 <file.plist> converts binary plist to read XML. Corporate VPN configurations, email client settings, and MDM profiles are stored in plist and may contain sensitive data.
Persistence at macOS: LaunchAgents, LaunchDaemons and Dylib Hijacking
[Applicable to: Internal Pumption, After Foothold and POWER Scalation]
The three main persistence mechanisms on macOS, each with different levels of privilege and visibility.
LaunchAgent (T1543.001, Persistence / Privilege Escalation) is launched in the context of the current user with a login. Plist files are placed in ~/Library/LaunchAgents/ (user) or /Library/LaunchAgents/ (for all users). Does not require root for the user directory - and this is its main advantage.
LaunchDaemon (T1543.004, Persistence / Privilege Escalation) starts from root when the system is loaded. Plist-files - in /Library/LaunchDaemons/. Requires root for placement, but gives maximum privileges.
According to Schellman, installer-packages (.pkg) allow you to simultaneously create LaunchDaemon (rot) and LaunchAgent (user), copy payload to the target directory and set up the host sleep-parameters - all through the post-starall script. This makes .pkg the most versatile vector for initial access + persistence on macOS in one bottle.
Restriction against EDR: LaunchAgents/LaunchDamons are monitored by all serious endpoint solutions. CrowdStrike Falcon through the Endpoint Security Framework receives notifications about the creation of plist files in these directories. SentinelOne tracks behavioral anomalies: the new LaunchDaemon with unsigned binary will cause an alterth. Neoming for legitimate Apple services (com.apple.*) will attract less attention in manual analysis, but the automatic correlation with the whitelist of real services Apple can issue a fake.
Dylib Hijacking (T1574.004, Persistence / Privilege Escalation / Defense Evasion)
macOS-applications download dynamic libraries (.dylib) from the paths specified in the Mach-O header. If the app is looking for dylib on the way where the file is missing or the directory is available for a record, here's the vector for hijacking.
Search for vulnerable applications: otool -L /path/to/binary will show all downloaded dylibs. A non-existent path or directory with access to entry is a potential point of implementation.
When the technique is NOT working: Apps from the App Store use Hardened Runtime, which blocks the download of dylib from non-standard ways. System applications are protected by SIP. On the Apple Silicon AMFI blocks unsigned dylib - a minimum ad-hoc signature is required (codesign -s - <dylib>) The technique is relevant for third-party applications installed outside the App Store - they are usually enough in the corporate environment.
Lateral movement and evasion: macOS as a point of entry into the domain
[Applicable to: internal pentest, post-exploitation, AD-conjugate environments]
Lateral movement from the macOS host most often goes through: SSH (embedded client, keys in ~/.ssh/), SMB for Windows hosts (smbclient or impacket), VNC for other poppies. Kerberos-tickettes, if macOS in AD-domain, are available through klist.
To move to Windows domain - impacket It works for macOS native through Python. Through proxychains You can route traffic via the Mythic C2 channel to access the internal segments.
Endpoint Security Framework and bypassing the protection of macOS
The Apple Endpoint Security Framework (ESF) is a user-space API through which EDR access file system events, processes, networks and authentication. Replacing outited kext-based mechanisms, and the main reason why evasion on macOS has become more difficult in the last couple of years.
OPSEC-recommendations when working with macOS-targets:
• osascript-based payloads (appell in Mythic) leave fewer artifacts on the file system than compiled binary
• LaunchAgent (User context) less than triggerite alertes than LaunchDaemon, but both monitor the ESF-based EDR
• Pattern curl | bash- antipattern: ESF logs the link network request + exec as a single chain. Don't do that
• Avoid mass-enumberation through dsclin the cycle - a pack of the same type of requests to Directory Services generates noise, which is visible to the naked eye
