CloudChat Cashes Out: Who Needs a C2 Anyways

Summary

#

In April 2024, Kandji released a report detailing the functionality of a new macOS stealer called CloudChat. It featured several stages, and was primarily focused on stealing cryptocurrency.

This post examines an additional variant that has a significantly reduced feature set. So much so that it that almost makes it not a stealer anymore. The malware no longer exports files using a C2, Telegram bot, or FTP, and instead solely relies on replacing wallet addresses in the users clipboard.

In addition to looking at the new sample, I also quickly look at some of the activity in several of the attacker controlled TRON wallets. It can be observed that the attacker is likely using OKX and Binance exchanges to cash out funds stolen using CloudChat.

The structure of the malware is the same as before:

Dropper Analysis: libCloudchat.dylib

#

As was the case in the previous CloudChat sample, most of the malicious functionality is found in a dylib. The primary change with this version is that the second stage downloaded by the malicious dylib is compressed and encrypted.

First the dylib checks if the second stage is already running by calling isProcessRunning(), which is just a wrapper for ps -ef. If it finds the name .apple.finder in that output it will just return and do nothing.

isProcRunning, err = _main.isProcessRunning(arg1)
if (isProcRunning.b == 0) {
    ...
}

Next, it’ll query ip-api.com by running curl http://ip-api.com and check if China is in the response. If this is the case it will also return and do nothing. Once all of these checks are complete, it will proceed with downloading and running the next stage, which is a macho containing the actual stealer(?) code.

To actually download the second stage it runs:

curl http[:]//104.156.239[.]74/api/products

saving the output to .apple.finder or .Safari_V8_config depending on the sample. This is where the primary difference between this version and the previous sample comes in as it calls decryptAndDecompressFile() before executeFileInBackground().

The AES key is stored in a global variable _main.key, with a value of b9rFGCQHMoYycDRs2fwOvnpi5StI70Eq. The payload is first decompressed using gzip, the first 16 bytes are pulled out as the IV (initialization vector). Then AES CFB is used to decrypt the actual malicious dylib.

Will all of this in mind, we can use a simple CyberChef recipe to replicate that routine.

A quick explanation of what this is doing:

1. Decompress using gunzip
2. Convert the file to hex, just for ease of extracting the IV
3. Extract the first 16 bytes (IV) and store in register R0
4. Drop the the first 16 bytes from the start of the decompressed blob
5. Decrypt the content using the key and the IV stored in R0

In the output window, you can see the section names for a macho written in Go - alternatively you can use Detect File Type to confirm that the output is a dylib.

Second Stage: .apple.finder

#

The binary that gets dropped by libCloudChat.dylib is what contains the actual stealer portion of the code. Compared to the version that was analyzed by Kandji it is very slimmed down, missing much of the impressive functionality. Quickly diffing the symbols from both shows how much the new binary has been slimmed:

The functionality that does remain is almost identical, with just a few obvious changes (like the staging server address). Main is just a while loop, which frequently reads the contents of the clipboard, looking for BTC, ETH, or TRON wallet strings using this regular expression:

0x[a-fA-F0-9]{0,40}\\b|T[a-zA-Z0-9]{0,33}\\b|bc1[qp][a-zA-Z0-9]{0,38}\\b

If a match is found, CloudChat will replace the clipboard contents with an attacker controlled wallet string picked at random from a list embedded in the binary. Since the binary is written in Go, there is some funkiness when it comes to identifying string structures. The wallet addresses referenced by symbols like _main.ethAddresses should point to an array of string structures but by default looks like this:

In Go, strings are stored in a blob, and then referenced using something like the following:

type string struct {
	str_ptr *byte // actual chars in the string
	str_len int   // how long the string is
}

To clean up our decompilation, we can define a new type that accounts for this. After defining the type, we can create an array of Go strings, which gives us much prettier output 🥰:

To programmatically dump the wallet addresses, we can just reference the members of the structure and extract the content from the blob:

def dump_string_table(addr: int, size: int):
	head = bv.get_data_var_at(addr)
	if head.type.name == "wallet_addresses":
		table = head["array"].value
		for i in table:
			print(bv.read(i["str_ptr"], i["str_size"]).decode("utf8"))

Then to use this we can simply call the function with the addresses referenced by the constants!

wallet_symbols = ["_main.ethAddresses", "_main.tronAddresses", "_main.btcAddresses"]
for i in wallet_symbols:
	symbol_addr = bv.get_symbols_by_name(i)[0].address
	table_addr = bv.get_data_var_at(symbol_addr).value

	print(f"{i.split('.')[-1]}")
	dump_string_table(table_addr, 0x28)

Since both .apple.finder and .Safari_V8_config aren’t garbled this will extract the attacker controlled wallets from both (they’re the same but w/e). You could also just use regex but where’s the fun in that :)

That’s pretty much all there is to the binary! If I was guessing, the reason for the reduced functionality is that the attackers probably realized that there isn’t a huge need to maintain infra or exfil content when the clipboard polling approach is similarly effective and slightly more stealthy.

Crypto Investigation

#

Since we have a good number of attacker controlled wallet strings, I figured it’d be worth seeing if any of them have any activity. None of the Ethereum or Bitcoin addresses had any transfer activity, which is good! TRON though, is where stuff starts to get interesting. Of the 40 potential wallets, 8 have significant amounts of activity. Most transactions are USDT transfers, with small amounts of TRON getting moved around as well.

I’ll preface the rest of this analysis with, I generally avoid crypto like the plague, so don’t take this analysis as gospel and do your due diligence.

• TRTjayycvyoWVTmuaL7SJwXi9nGMnU3MEK
• TDWLFcXV9RnVDTgXq8ZvawiHhPxE8Udgf7
• TEYm6wiTW9LkoBtb1whYP8xz2mBtaARuxT
• TZ3utnnqVLFisFeC7Uhw1Jp3xL1DAnMGfL
• TMsbDvf8RX4zXf3Q47Ab5Zy5Y4S41f24FH
• TYwfG4KPt6NVgGtghMeM1MshD3nKSpf5gY
• TCXsxTnWH3CkS39w3SN9bK6CcxUr5pYyVy
• TWEjBmmoYRypov1WPfwX28N5QEkvqMdt1U

Using tools like OKLink and TronScan we can look at the activity for these wallets. Many of them have both TRON transactions:

Several of the wallets end up dumping their funds into just two addresses: TWF213NdW7YYYpMECzqtd4yeNFwXCf8vub and TU4PKA5fzWbdSTyBuso9ATGfTcVwd3Js4r. From there, the funds deposited into the first address were converted out per OKX. The second address, deposits into several Binance accounts, as well as sending other funds into less obvious endpoints.

Interestingly, on some of these wallets, the attacker can be seen (presumably) buying small amounts of TRON to cover the gas fees for the USDT token transfers.

The largest single example of the attacker cashing out is on the address TWF213NdW7YYYpMECzqtd4yeNFwXCf8vub where they move $1,300 of USDT to OKX’s deposit pool.

Most of this analysis is entirely based on the accuracy of the claims made by OKLink so as with most things crypto, it’s probable but not provable.

Conclusion

#

Overall this was a weird development – rarely, if ever, do you see malware get less advanced (and that’s usually in cases where something gets leaked and skids make a mess of it). I’m definitely curious to see if future samples embrace malware minimalism or they return to the more complex version.

Note: At the time of writing, the “C2”/staging server is no longer active and I wasn’t able to identify any new servers.

As always, if anything in this post was incorrect, or you just have thoughts, please don’t hesitate to reach out @birchb0y on twitter :D!

IOCs

#

Files

#

Sample 1:

Infrastructure

#

Wallet Addresses

#