Breaking down an XMRIG dropper

I want to learn Malware Analysis and dip my toes into security research so I have been learning the ins and outs of assembly, architecture and windows internals but someone can only take so much of that ya feel me.

So i decided to head over to our favorite website MalwareBazaar and try my hand at hunting some samples.

Now admittedly I AM NOT at the level needed to analyze some windows binaries no sir.

We are going to stick with some linux stuff to get our feet wet because most of it is shell scripting anyway 🙂

I downloaded this sample from MalwareBazaar

0dc71107e3965df98aa4ce5843c7436a95a203f56bfc6f5647f68b41131ef1c0

Part 1: The Dropper

Some interesting things to point out directly.

Enumerating running processes and killing anything running out of postgresql, /dev/shm, /var/tmp:

/var/lib/postgresql/*|/dev/shm/*|/var/tmp/*|/tmp/*) kill -9

But also leaving any processes running that are named rediserver (foreshadowing)

Right into the first function __curl

This basically guarantees no matter what, this script can execute a request using /dev/tcp.

the TA brought their own curl

Before the script goes any further it checks everything in /proc to see if anything is running named rediserver If there is it skips everything and exits.. because the miner already exists on this machine.

Next is some directory manipulation, and one of these is weird: it rm -rf's, recreates, then chmod 000's a directory literally named curl inside /var/lib/postgresql/.

Zero permissions, nobody gets in or out. That's not a decoy folder, that reads more like it's actively trying to break something else that expects to write there. Still forming a theory on this one.

Then it wipes /tmp completely (rm -rf /tmp/*) before creating two directories: /tmp/postgresql and /tmp/javavmx64

There's a second kill sweep here, same idea as the first, but this time it's hunting by working directory instead of executable path, killing anything running with a CWD under /tmp

Then the script sets a variable TMNAME where a random 8 character directory will be created and the payloads will be staged.

Calling the __curl function, it pulls config.json, x.rar, p225.sh all from 119.194.153[.]12.

One thing that actually fooled me at first was that x.rar wasnt actually a rar file.

Lets check it.

ELF 64 Bit Stripped. who wouldve guessed.

Once the payloads are on disk the script chmods and executes with nohup

And finally removing the bash history for some anti forensics.

Part 2. Pulling down to config

In part one we saw that this script attempts to pull files down from 119.194.153[.]12

Lets take a look at config.json

There wasnt much interesting here but it can tell us a few things

This randomx config block helps us confirm that this is mining Monero via RandomX

The mining pool

pool.supportxmr[.]com

and the username

49dVFmT3jJZD5Dfg8raCjnjHe1ukvPfdfVmW6HvfTmjzWYaWdFxxeXBFnaRpZ1XrZU5nSACQA4pEJZQP1bGXqJauBkcHhW1

max-threads-hint: 100 This thing would burn your CPU... it does not care about stealth.

This is actually looking pretty similar to XMRig Schemas I have found doing IRs in the past.

Part 3: X.RAR (rediserver)

Reminder we already ran file here so we know this is a 64-bit static-pie linked executable that has been stripped. There is no symbol table here. Reading function names is basically a moot point as IDA or GHIDRA will basically just have made up names for them and trying to understand context from function names alone is relatively impossible

And like I said earlier, me? use a disassembler? Good Joke.

Lets run strings

We have a few things we want to search for just from our IOCs above

• rediserver
• xmrig
• version

From this grep we can actually find a few interesting things.

We were correct and x.rar is in fact XMRig V. 6.18.1

but what was even more interesting is we found some potential directory leakage here

I actually got curious to see if this was something unique to the TA so I downloaded the latest version of XMRIG for linux and ran strings and unfortunately I found the same in the official build. ☹️

Lets recap, this looks like an unmodified, stock version of XMRig with everything set to max let it rip or die trying.

Honestly, not much investment went into the mining component itself just the real XMRig release, pointed at a public pool, with a couple of config values tweaked to maximize payout.

There's still one more script we need to check out that was pulled down from our dropper

Part 4: 2nd shell script

Looks like there is an infinite loop. 1 always evaluates as true.

This is always running and looks to be another sweep that we mentioned in the first line here. Killing anything in the same directories except rediserver.

This loop is repeating about 10 times a second which seems... aggressive

If you go back to Part 1, remember the dropper generated that random 8-character staging directory ($TMNAME) and downloaded everything into it. When it launched this watchdog, it passed that same directory name in as $1 so this script knows exactly where to cd back to in order to find and relaunch rediserver if it ever goes down.

Part 5: The thing thats missing

We pulled down everything there was to pull but I have one lingering question. What happens if this compromised machine reboots or something interferes with the miner. In my DFIR experience if I know one thing is certain PERSISTENCE IS KEY, but we havent found any here yet?

I turned my sights to virustotal and some other OSINT to see what I could find.

Checking our IP on VT shows us the relations. We can see another file here that is related to this IP that we didnt actually notice in our script. startup.sh

Another infinite loop that is checking for interactive sessions, if it finds one it kills the miner, if not checks on the miner and sees if a relaunch is needed.

Looks like we also have some more kill commands for other miners and whitelisting of an IP containing 210.97 interesting. another piece of infrastructure maybe.

is startup.sh our persistence?

Honestly, I can't say for sure It never showed up in anything I actually traced not in the dropper, not in p225.sh, nowhere in the execution chain I pulled apart. I only found it because VT's relations tab linked it to the same IP. It's sitting on the same infrastructure, using the same rediserver naming convention, and it's clearly built by someone who thinks the same way but I have no evidence for how it actually lands on a victim machine. No script I found calls it, downloads it, or references it at all.

A few possibilities, and I genuinely don't know which is true:

• It's part of a different infection vector entirely maybe a different exploit path against the same target profile (Redis/Postgres) drops this instead of the dropper I analyzed
• It's an older or newer version of the toolkit, staged on the same server for a different campaign wave
• It's just unused/leftover staged but not currently in rotation

Part 6: OSINT

We found the wallet earlier... lets check that out using the xmr api.

https://supportxmr.com/api/miner/49dVFmT3jJZD5Dfg8raCjnjHe1ukvPfdfVmW6HvfTmjzWYaWdFxxeXBFnaRpZ1XrZU5nSACQA4pEJZQP1bGXqJauBkcHhW1/stats

Here you can see the hash rate and other details for the user.

• ~24.16 XMR already paid out to this wallet
• 0.031 XMR currently owed/pending, not yet paid
• ~97% valid rate
• almost 28 trillion hashes submitted cumulatively

Shodan Lookup

https://www.shodan.io/host/119.194.153.12

Nothing too interesting outside of what we already knew.

WHOIS info

Pivot on the /26 range

The sibling hosts in this range weren't running anything related to this campaign mostly legitimate looking services, including a few exposed Prometheus instances.

Wrapping Up

Stepping back across the whole thing: nothing about this campaign is technically impressive on its own. The miner is a completely stock, unmodified XMRig binary. The hosting is a normal, unremarkable VPS block sitting right next to legitimate services, including a few exposed Prometheus instances that have nothing to do with this at all. Nobody wrote custom malware here.

What did get real engineering effort is the shell scripting wrapped around all of it. I found the competitor killing checks, the /dev/tcp curl workaround, the randomized staging directories, the human-presence detection in startup.sh, the hardcoded targeting of rival families like kinsing pretty fascinating to check out.

And the payout backs up that it's working: ~24.16 XMR paid out to this one wallet which is roughly $8,700+ at today's price off almost 28 trillion submitted hashes. Cheap tooling, low investment, real money.

If you enjoyed this consider subscribing to The Hunt Report. Its free and I write about cyber security and what im learning (malware analysis + Security Research)