With the General Availability release of the Huntress macOS agent, we wanted to share some of the Apple-y stuff we’ve been up to behind the scenes. In this article, we’ll put our red team hats on, take a look at a macOS ransomware script and discuss how we improved its offensive efficacy. 

"Macs Don't Get Malware, Stupid."

An interesting urban myth of information security is that Apple products don’t get malware.

Now while this is nonsense, of course, it’s important we briefly look at what is really being said here. 

The Windows operating system has dominated the game for some time now, and if you’re an adversary, you’d likely hone your craft on the bigger ‘market’ where your tradecraft can have greater impact. 

Windows malware gives adversaries more bang for their buck. It was never the case that Macs didn’t get malware; rather, only a few were writing malicious tools to attack this tiny slice of the OS pie. 

As the OS market has started to become more multipolar, it has increasingly become more advantageous for adversaries to focus on Apple products. In 2022, a reality we must come to terms with is that Macs can be hacked, ransomed and indeed get malware. 

Finding macOS Ransomware

We’re connoisseurs of the shady. We’ve always got an eye on the various Tweets, Discords, Slack and Russian forums, so we keep our fingers on the pulse of the latest and greatest offensive security. 

In one such instance, we found a macOS ransomware script* circulating around. 

On first inspection, we found that it did not work out of the box. 

• The encrypted drive did not have a password set
• Files failed to exfiltrate to our attacker-controlled address

Okay so, there were some flaws in this script. It was most likely a ransomware script template that was supposed to be built on by the offensive operator. Nonetheless, we were able to pinpoint the particular contingent parts of the script that were causing the failure. 

• diskX: An assumption was made in the script about the disk name/number for the ransomware to target. This was largely correct in its default on the template. 
• ~/exfil/*: This is a hard-coded directory that would likely not exist on a machine—until it is created. 
• Curl: We don't have a C2 server to send the credentials to—easily remedied.

Fixing the macOS Ransomware

Once we identified the gaps in the template, we then got to work making this ransomware operational.

It was easy to remedy the issues with the hard-coded directory, as we could simply move the files into a volume and directory that we created. To fix the data exfiltration issue, we had to provide an IP or domain that we controlled (in this case, we stuck with localhost, but there’s no reason you couldn’t insert a public IP or domain).

To reliably target the correct disk to maliciously encrypt, we deployed the diskutil command and used command line text editors to specifically select the disk number that contained the Apple File System. 

`diskutil info / | grep 'APFS Container:' | awk {'print $3'}`

Once fixed, we are left with a one-liner Bash script that creates its own encrypted drive on the target’s mac, copies critical files to this drive and unmounts it. It then uses OpenSSL to send the decryption password, leaving the target with a maliciously encrypted drive, stolen files, and the knowledge they’ll have to pay $$$ to get it all back.

As you can see, we had to make quite a few modifications to get this shell script to work. This included adding the OpenSSL option.

We can skip using a C2 framework and just use OpenSSL as a fantastic alternative. The credentials are sent to the attacker's machine using OpenSSL. Not only is the data encrypted; the connection itself is secure. We also included `p=""` within the script to ensure that the credentials cannot be recovered via memory dump, and to further frustrate DFIR efforts, we modified the script to store a new random password in `p`. 😅

Breaking Down the Final Script

Let's walk through the script:

1. First, we conjure a random 64-character password as the variable  `p`, using the built in /dev/urandom, along with text editing command line tools
2. Then, we identify the APFS Container being used and create an encrypted APFS Drive named `XX` on the victim’s machine
3. We then move important files and folders, unmount the encrypted drive and send the password back  to the attacker’s machine using OpenSSL

Enough yammering! It’s time to execute this bad boy!

We can see the script has executed beautifully, and the credentials were sent to the attacker’s machine without ever touching the host.

Ransoming macOS

At Huntress, we conform to the philosophy that we can’t defend networks without understanding our adversaries. 

Emulating offensive security techniques allows us in the blue team to improve our own tradecraft and, in turn, get better at evicting threat actors who try to deploy ransomware for malicious purposes.

If you want to test this macOS ransomware discussed in this article, you can find it here along with other bits and pieces we gathered for this post. 

If you’re interested in improving your defensive chops through proactively practising red team techniques, you may find November 2022’s Tradecraft Tuesday interesting, where we discuss in more detail what proactive security entails.

‍

*This script was last known to work on macOS Monterey.