Taking the fileless route was unheard of with Mac malware. Until now, that is! This blog describes a brand new fileless tactic pioneered by the infamous Lazarus cybercriminal group which should set the alarm bells ringing about the continuous and evolving threats in the Mac world. 

We recently observed a Trojanized version of the UnionCryptoTrader.dmg file in the wild, which we believe is the handiwork of the Lazarus group. This sample had a solitary K7 detection at the time of writing this blog. It is a container for a Cryptocurrency trading application and a loader. The staged payload delivery mechanism used by Lazarus in this case was intriguing, the reason being that the loader had the capability to load a remote payload directly from memory rather than via a file on disk. 

What first raised our eyebrows  was the domain unioncrypto.vip, registered only for one year, serving a fake cryptocurrency trading application. The downloaded UnionCryptoTrader.dmg file had no digital signature. In fact, this campaign could have been active since June 2019 (month of  website registration) as shown in Figure 1. 

Figure 1: Whois lookup

The downloaded file UnionCryptoTrader.dmg was Trojanized in the same way as observed in the DragonEx campaign of Lazarus. Lazarus has been targeting many cryptocurrency exchanges using malicious trading applications. Their usual method of Trojanising a Mac application is quite simple. The threat actors place their backdoor and its persistence file in the resource directory of an open-source trading application, and then leverage the post-install script (as referenced in Figure 2)  to trigger their backdoor. The post-install script present within the application installer package is usually meant to aid the legitimate installation process, but is abused by Lazarus to execute their backdoor.

Figure 2: Package Info

In this campaign the post-install script is actually a shell script as shown in Figure 3 below, which executes the loader (unioncryptoupdater) and the persistence file (vip.unioncrypto.plist) residing in the resource directory.

mv /Applications/UnionCryptoTrader.app/Contents/Resources/.vip.unioncrypto.plist /Library/LaunchDaemons/vip.unioncrypto.plist
chmod 644 /Library/LaunchDaemons/vip.unioncrypto.plist
mkdir /Library/UnionCrypto
mv /Applications/UnionCryptoTrader.app/Contents/Resources/.unioncryptoupdater /Library/UnionCrypto/unioncryptoupdater
chmod +x /Library/UnionCrypto/unioncryptoupdater
/Library/UnionCrypto/unioncryptoupdater &

Figure 3: Post-install shell script

The loader collects the Mac’s serial number and OS information and posts these data to the Lazarus C&C. If the loader receives a non-zero response from the C&C,  it proceeds further and decrypts the response blob from the C&C, which is the remote payload. The response blob undergoes a base64 decode followed by AES decryption. Unfortunately, the C&C related to the executed sample was not responsive during our analysis, and so we were unable to fetch the remote payload. But analysing the loader file statically, the ProcessUpdate function is responsible for executing the decrypted remote payload either directly in memory or after writing to a file on disk with executable permissions as shown in Figure 4. 

Figure 4:. ProcessUpdate function

The load_from_memory function allocates memory using the mmap API and copies the remote payload into that allocated memory, and then invokes the memory_exec2 function to execute the decrypted content as shown in Figure 5.

Figure 5: Load_from_memory function

The memory_exec2 function is implemented based on MemoryBasedBundle which allows execution of Mach-O from memory rather than via a file on disk, provided the Mach-O is of type bundle. Then an image file is created from the buffer using the NSCreateObjectFileImageFromMemory API, and the NSLinkModule API links the “core” module from this image file to the current process and runs the constructor of the image file as shown in Figure 6 en route to  executing the remote payload.

Figure 6: Memory_exec2 function

Interestingly, the strings in the loader binary had references to its source files and build environment (Figure 7), from which we may infer certain functionality.

main.o –  “main” function for the loader binary
– C&C communication module implemented using libcurl  (inferred from the ‘get’ and ‘post’ methods)
rijndael.o – as the name suggest, an AES encryption routine
core.o – remote payload (which we were unable to fetch)

Figure 7: Source file references

This sample clearly proves that malware threats for macOS are not only very much in existence, they are evolving and becoming more sophisticated. We’ll be keeping a close eye on the Lazarus group and other threat actors deploying their malicious wares on the macOS platform.

Indicators of Compromise (IOCs)

UnionCryptoTrader.dmg – Trojan ( 0001140e1 )

Hash: 2ab58b7ce583402bf4cbc90bee643ba5f9503461f91574845264d4f7e3ccb390

Like what you're reading? Subscribe to our top stories.

If you want to subscribe to our monthly newsletter, please submit the form below.