The $2.72 Heist - When Testing CVEs Backfires

So we all know the drill: you’re in the middle of a pentest or a red team activity, and you stumble upon an application vulnerable to a known CVE. The obvious next move is to find a working POC and try to exploit the machine. You run a search on GitHub and quickly find a code repository with an RCE exploit for that vulnerability. Looks promising!

I spin up my Kali machine and download the repo. Attempting to compile the exploit, I hit a roadblock — an error message about a missing library. Despite my efforts to work around it, I eventually give up and move on to my next task, defeated.

It’s just part of a pentester’s daily routine, right?

Later that day, I return to find my computer working overtime, its fan running at full power, making noise impossible to ignore. A quick check of Activity Monitor reveals the Kali VM running at max capacity. Switching to the VM, I see the CPU grinding at 100%, which suspiciously drops the second I open Task Manager.

I start investigating and quickly find a known Monero cryptominer (xmrig) running on the machine, complete with a malicious service installed to manage its startup. My mind immediately jumps to the "not working" CVE I tested earlier. Returning to the repo and source code (https://github.com/masm3264/poc-CVE-2019–11248), I start digging.

After some effort, I uncover the malicious dropper code hidden and obfuscated within the configure file:

Deobfuscation proves relatively simple, leading me to the malicious repository where the cryptominer is downloaded from: https://codeberg.org/k0rn66/xmrdropper

This new repo had a bunch of shell code files, including the unencoded dropper shell and valuable information such as:

• The wallet ID used for the mining pool
• An API key for file.io, leveraged by the malicious application for file transfer
• A convenient cleanup code

Diving deeper into the code reveals that beyond installing the cryptominer, the threat actor also harvests machine information, including system info, bash history and folder mappings. It uploads the harvested data to file.io using their hardcoded API key.

Additionally, it drops a public SSH key in the authorized_keys file on the machine. For internet-exposed victim servers, this means they're now backdoored.

Intrigued, I use the attacker's API key to check the uploaded victim data files and the Wallet ID to view their current balance:

The results? After a couple of weeks and 13 Active Miners running (hacked machines), our malicious actor has accumulated a staggering balance of... $2.72 in Monero (XMR).

The attacker's repo also includes a list of popular CVEs, suggesting their efforts to upload fake exploits under these titles on GitHub:

I found a few other repos using the same infection technique:

• https://github.com/enter0x13/poc-CVE-2024-5057/
• https://github.com/masm3264/poc-CVE-2001-1473/

These repositories are still active, and I believe they're just the tip of the iceberg when it comes to malware-spreading repositories.

While I won't delve into the details of how I tracked down the Russian individual behind this campaign, I can say it was surprisingly easy. With enough digging, one can uncover their VK and Instagram profiles, Telegram channel, and even personal phone number.

Moral of the story: Always check the code you are running and always run it on a disposable VM machine!

Stay safe out there.