Analyzing macOS on Apple M1 Silicon: A Penetration Tester's Take

These days, Mac-based corporate environments can be likened to the Tooth Cave Spider.

They’re rare, and though they’re not technically “endangered” like the Tooth Cave Spider, they do remain “in danger” of cyberattacks from malicious actors.

This niche nature of macOS environments has led to a common perception that they’re more secure than your typical Windows domain—less macOS targets means hackers might focus instead on breaching all the Microsoft machines that are more readily at their fingertips.

In the same vein, it might be easy to assume the latest Apple M1 Silicon system is the safest yet, but in fact, this system is vulnerable in some areas.

For your benefit, we are going to outline how.

For those who do use macOS environments, it can be difficult to find a penetration testing team experienced enough to thoroughly assess your environment. That’s due to that same niche nature we mentioned before, but at Schellman, we do have the professions capable of performing these tests on what has become a unique choice for a corporate system.

To help you understand more regarding this new Apple M1 Silicon, in this article, we will give you a pen tester’s view of approaching macOS attacks. We’ve done it before, and we want to help you understand your environment so you know where your vulnerabilities are. We’ll also provide some recommendations on how to keep your Mac environment secure.

Cybersecurity continues to grow in importance for everybody—it doesn’t matter if you use Microsoft or Mac. But for you Mac users, you shouldn’t be left behind in terms of security tips, so read on and let us help even the playing field.

How Do Hackers Find Initial Access into macOS?

Initial access to macOS can be gained in many, some of which include:

• Malicious documents
• Installer packages
• Executables or binary payloads
• Malicious scripts a user may be tricked into running

But before we get into just how all that works, let’s lay out our parameters and tools for the testing environment we’ll be using in this demonstration.

Acting as the attacker will be a standard Kali box, and it will attempt to breach a 2021 M1 MacBook Pro running macOS Monterey version 12.0.1 in a Virtual Machine. (Although we will not use M1 Pro or M1 Max, these chips would be impacted in the same way we’ll see here.) To help demonstrate how initial access and tooling can be affected, Rosetta 2 will not be installed. 

Fingerprinting a M1 Mac

As we get started, a quick word on M1 Macs and how they act out of the box.

Below is a screenshot taken from our freshly deployed virtual machine. What you see is the output from the “uname -a” command. On the left, we can verify it’s running the arm64 version of macOS, and you can see the “About this Mac” pane as well. But there in the bottom left, you see the pop-up we received since we’re trying to run an application not optimized for M1 processors.

Basically, macOS is asking us to allow Rosetta 2 to be installed, thus allowing x64 / non-M1 optimized applications to run. But how does this affect our payloads if we click “Not Now” and does this make the endpoint any more secure?

Let’s find out.

Simple Shell

We start nice and simple with a basic reverse shell–this could be hidden inside a malicious application, a script presented as required for a job function in an email, or quickly it could be run on an unlocked, unmonitored Mac.

This example is executed via Python2 which ships by default on macOS. (As we are writing this, Apple has stated that it will be removed in the future.) The payload is generated via “msfvenom” on our attacker box like below and tells the payload to call back to the attacker’s IP on port 443:

Once executed on the target Mac via Python in the top Terminal window, we see the shell calling back to the attacker without issue. We can then execute another “uname”, “whoami”, and “hostname” commands as expected. But these are only basic commands, so let’s crank up the complexity and try out some of the command-and-control (C2) tooling available for macOS.

Accessing a Mac Through Binary Payloads

Numerous C2s exist to generate an executable targeting macOS. Most also are built specifically for x64 processors–not the Apple M1 chip. This is where we hit our first obstacle for not having Rosetta 2 installed–here is the “poseidon” payload generated out of Mythic:

If Rosetta 2 were installed, we could help the payload out by specifying the architecture in Terminal by running “arch -x86_64 ./poseidon,” but we’re still avoiding compiling for M1 specifically.

Instead, let’s try out an “apfell” payload which runs through “osascript” instead. That gets us a successful callback to Mythic, and we’re able to run a “whoami” and “uname” showing we’re still running on as arm64 on the M1 Virtual Machine:

Accessing a Mac Through Malicious Documents

Now that we know apfell payloads have no issue calling back, let’s fancy this up a little and wrap it around a better pretext that an end user is more likely to run.

Using the Mystikal project along with Mythic, we generated the following payload that masquerades as a PDF (bottom square), but it really executes the same apfell payload as before. That gives us a new callback in Mythic (top square) and leaves the target unaware of the active attacker now living on the Mac.

 Accessing a Mac Through Installer Packages

We’re seeing lots of payloads gaining that initial access, but as attackers we still have two issues:

• We have no persistence, meaning we’ll lose the connection if the system gets rebooted; and
• We’re only running as the “schellman” local user.

Both issues are solved via the very flexible installer packages commonly used for more complex application installations. At Schellman, we use an internal process developed by one of our pen test managers, and so our team can generate a package that does all of the following:

• Establish persistence via a LaunchDaemon as the “root” user and a LaunchAgent as the current user executed at a defined interval
• Copy any of the created payloads to a local directory to be later called by the above persistence
• Automatically configure new sleep settings, execute the initial payload, or a secondary payload via the installer packages postinstall script to ensure the target Mac stays online for testing and a connection is received

So, we can continue attacking and demonstrating vulnerabilities.

That postinstall script also gives us the unique opportunity to fix the missing Rosetta 2 problem if we like. After working on a M1 Mac, we investigated exactly how Rosetta 2 is installed and it turns out that it’s just an argument added onto the software update program built into macOS that is only made available on M1 Macs.

Combine this with our knowledge that postinstall scripts run commands normally reserved for copying files or other installation activities, we can slide in the following line to install Rosetta 2 along with our pentest payload: “/usr/sbin/softwareupdate --install-rosetta --agree-to-license.”

One last takeaway for installation packages on M1 Macs in particular: a package that has yet to be optimized will likely fail and state that it’s not compatible with this version of macOS. That’s due to a simple precheck that the installer does when loading up a .pkg file.

The installer checks the packages Distribution file for the target architecture and non-optimized macs will list it as “hostArchitectures="x86_64.” A malicious actor can solve that issue by simply adding “arm64” to the hostArchitectures section and the install will complete successfully.

The Hacker Is In - What Information Can They Get?

Posing as said attacker, we’ve now successfully got a call back from a payload in the M1 Mac. Now, we’ll run through what we can do with our foot in the door. We’ll touch on:

• Local enumeration;
• Privilege escalation opportunities; and
• A bit of network and lateral movement investigation.

Enumeration Within MacOS

Assuming we’re running under the context of a regular user, we’ll be looking around the user’s home folder first to see what is sitting cleartext. Apple does protect Downloads, Documents, and Desktop with something called Transparency Consent and Control (TCC) framework. It forces you to allow access to a directory via the desired application in System Preferences / Security Privacy / Privacy or hitting allow on the pop-up like below:

So while we can’t touch that, anything in your actual /Users/schellman/ folder is readable by any user logged in locally, admin or not. That could be any of the following things:

• .zsh_history / .bash_history (including any commands run giving context to how a machine was set up, default deployment activity, passwords that were passed inline to another application, hints toward configuration files which may contain more sensitive information, or hints toward other hosts this endpoint has secure shelled (SSH’d) to in the past)
• .aws, .config, or .azure directories that may contain unsecured credentials
• SSH keys
• Slack cookies (which are good for social engineering co-workers into resetting passwords or general information gathering)
• Library Folder containing Messages from iCloud and then Keychains for local saved passwords
• Browser history

That’s a lot of information that’s accessible, but in fact we’re not done.

Escalation Opportunities for Attacks in MacOS

Keychains are our next point of focus because these can facilitate things getting out of hand. Apple makes it easy to save and sync passwords across multiple devices via your Keychain. Much like on Windows, these can be retrieved with the right access so let’s try to get at them.

The actual keychain database is located under each user's home folder at ~/Library/Keychain/login.keychain-db, and it can be downloaded for further analysis offline.

We can use the dump-all feature of chainbreaker to get an idea of the content of the Keychain. We’ll be able to see if it’s in use and therefore worth the time put into cracking the password for it.

This being our own test keychain, we can verify I have 1 useful password to another test machine saved but the remaining saved passwords are mostly app passwords used by iCloud and other macOS-related services. Cracking time varies depending on complexity, but retrieving the Keychain hash then unlocking it can open another valuable pivot point into a cloud-only environment.

Here we can see my very secure Keychain password of “schellman” being cracked via “hashcat -m 23100,” as well as a short wordlist of company names:

By providing the cracked password to chainbreaker again, we can see the saved password:

Network and Lateral Movement Within MacOS

Finally, we’ll explore where else we (or a malicious actor) can pivot to through lateral movement and domain reconnaissance once we’ve accessed macOS.

Assuming we’re not in a cloud-only environment or a user’s home network, nmap installs just fine on a Mac. That’ll give us a network footprint over an office internet connection or VPN which will help us find our next targets that may be hosting vulnerable services.

Also, with .NET 5.0 supporting cross compilation, we can now drop Inveigh to disk and capture SMB NTLM challenge and responses, along with various man-in-the-middle and password sniffing attacks.

If we land on a domain joined Mac, we can perform much of the same domain enumeration as we can on Windows like below:

List Users: dscl "/Active Directory/CORP/All Domains" ls /Users

List Computers: dscl "/Active Directory/CORP/All Domains" ls /Computers

List Groups: dscl "/Active Directory/CORP/All Domains" ls /Groups

List Domain Info: dsconfigad -show

From here, we can then bring in the Bifrost project to interact with AD and list out Kerberos tickets for the current user and list out kerberoastable hashes to be cracked offline later by specifying its “-kerberoast true” flag.

Next Steps for Protecting Your Mac Environment

Many of the attacks presented here can be prevented through educating the users in your environment about possible attacks. Teach them:

• To not install unsigned packages
• To not accept unsolicited prompts that want to make changes to their system.

And while awareness and education are key, we always recommend a strong monitoring platform that sends alerts on unsigned packages being installed or unsigned executables being allowed to execute by a user. Of course, we also recommend using strong passwords to prevent cracking–these can largely be assigned as requirements via most RMM solutions.

Though we tried hard to be thorough in our demonstration, the truth is, we’ve only just scratched the surface on the myriad of attack paths one can take when working through a macOS penetration test.

To help you continue learning about your own Mac environment, we’ve included some links below to some of the projects we mentioned that we used in our test here. As we’re constantly finetuning our testing practices and tooling to ensure our team brings the greatest value to all aspects of penetration tests, we’re big fans of them all where Macs are concerned.

But if you do think you’d like to speak to someone regarding testing your actual environment for these vulnerabilities and more, please reach out to us. We are happy to answer any questions you may have about securing your network and how penetration tests can help.

Projects Cited:

https://github.com/its-a-feature/Mythic

https://github.com/cedowens/SwiftBelt

https://github.com/its-a-feature/offensive_macos

https://github.com/its-a-feature/bifrost

https://github.com/D00MFist/Mystikal

https://github.com/n0fate/chainbreaker

https://github.com/Kevin-Robertson/Inveigh

https://cedowens.medium.com/initial-access-checks-on-macos-531dd2d0cee6