Tackling Atomic MacOS Stealer with radare2 — Part 1 — Static triage
In this three part series I will look at the infamous Atomic MacOS Stealer using an awesome reverse engineering framework known as radare2 or r2.
For those who might not have heard about radare2, then to quote the official radare2 homepage: “A free/libre toolchain for easing several low level tasks like forensics, software reverse engineering, exploiting, debugging, …”
If you want to know more about the awesome project that is radare2 (or now also known more succinctly as r2), please visit the following resources:
Before we dive into the InfoStealer then if you want to follow along, few prerequisites to cover:
- XCode Command Line Utilities
- Disabling SIP (necessary for debugging with r2) — if you’re following along on a corporate device without using virtualization (and even if using virtualization) be sure to have approval.
- (Optional) Macports — you can get it from https://macports.org/. There are other alternatives to installing r2 as well. For example, to use the freshest version available, it’s recommended to build it from Github and sign it locally. This is not something everybody might want to do or can do.
- Install radare2 with Macports, or using an alternative method.
Now after all prerequisites have been covered, let’s get in to it.
Note that the static analysis part was done on a virtual machine. I used UTM but I also set up a mac Mini with SiliconBox as a backup. This was due to frequent crashes when debugging on the VM and switching back and forth from host to guest introduced latency and sometimes the VM hung. So it’s possible I’m pivoting between the VM and our mac Mini set up with SiliconBox during the posts.
Oh, a responsible disclosure also: samples were already run in our SiliconBox sandbox so we kind of knew what we were looking for. Choosing the samples already run was a deliberate choice to speed up getting started with r2.
Okay let’s get started finally!
After installing the r2, you get a bunch of helper tools installed. So let’s grab the sha256 hash of the sample
$ rahash2 -a 256 Amos_21022024
Amos_21022024: 0x00000000-0x00073edf sha256: 0f0e38fe1a1d37a78c398134647c35e23c0da913fc5d0b2856eca7d5ac114effLet’s do one of the first things many analysts do — check it in VirusTotal:
Note this was done approximately3 months later (20052024) when the sample was discovered.
Let’s continue with opening up the sample and running full analysis:
r2 -AA Amos_21022024Now we can run various commands on the analyzed sample like fetching the metadata of the binary with i:
There is more you can get from the info command, just run i? to see all the options.
We know that AMOS is known to use XOR encryption so a simple strings command might reveal something but not the all of the juicy strings present in the sample.
Let’s try it anyway with the radare2 command for displaying strings:
We can also do a search, for example, let’s see if any plists are in play with izz~plist:
Indeed but nothing of interest, it’s the default bundled plist for most if not all MacOS applications.
Going back to the strings output, wealready see some interesting information that can guide in further investigation:
- dscl — https://ss64.com/mac/dscl.html — can be used to ask for a password from user
- passwo — likely related to dscl (see previous point)
- login- — perhaps login-keychain?
- Gecko — from a user-agent string? Indicates possible exfiltration.
- POST — HTTP method, another indication of exfiltration.
- etc
We also see that the sample has been developed on a macOS using XCode by someone who uses the alias brunch as their username.
/Users/user/brunch/soft/main/setup/
/Users/user/Library/Developer/Xcode/DerviedData/This is all good but we’d like to understand a bit more about the strings, so let’s try to see if we can grab a XOR key that would help us.
Step 1 — let’s find a function that’s getting called many times. That function is a good candidate for the “decryption function”.
Let’s list all functions with afll:
That’s quite a few, we’ll need to filter the results a bit. Notice how inside r2, I’m using the pipe command to output to commandline utility wc. We can use this feature of using r2-external cli-tools to manipulate the output.
Phil Stokes has a nice ebook on using radare2 to analyse MacOS malware (unfortunately it’s a bit dated and targeting Intel architecture samples but nevertheless, a great resource), I’m going to grab a command to sort functions by calls to them (slightly modified version though):
afll | grep "sym." | awk '{print $16 " calls: " $11" locals: "$12" args: "$13" xrefx: "$14}' | sort -k 3 -nTop three look like this:
So let’s seek to sym.task4__ and print out the disassembly with the pd command:
This one looks a bit too complicated for the XOR function so let’s find references to this function and see if we have a better candidate:
Ah, this sym.dotask__ was also in the top three called functions, let’s take a look:
Awesome, we find our first XOR hit (note in Arm architecture eor instructions is the equivalent to Intel’s xor -> https://developer.arm.com/documentation/dui0489/i/arm-and-thumb-instructions/eor).
Now we need to find the key. First candidate is 0x81 as it’s moved to the w8 register pretty early in the function.
When we looking at the strings output (7 byte strings, command: izz | awk ‘$4==7’) more closely and knowing that XOR encryption is used, we notice a repeating char, the familiar 0x81:
So let’s verify this with CyberChef (https://gchq.github.io/CyberChef/).
We can do a hexdump using the x key to get the partial strings:
Seems we hit the jackpot quite quickly, strings start become more interesting:
And that’s it for Part 1. We did a quick run through some of the more interesting static triage functions and plugins r2 has to offer and reached to a place where we were able to get to the XOR key to decrypt some strings and get some more actionable information out of the sample.
Now it’s time to ease the pain of extracting the observables and utilize the dynamic analysis features offered by r2 so stay tuned for Part 2 where we’ll get started with the reversing and debugging to see what more can we extract from the sample.
Resources
- Note if setting up your analysis environment takes too much time or you don’t have resources/time to perform manual analysis, checkout https://thesiliconbox.com/.
- r2 links mentioned in the beginning of the sample.
- https://www.sentinelone.com/blog/author/macoswriter/
