Crypto Miner Malware Analysis

0. Introduction

Hello!
This was my first time doing a malware analysis, and I wanted to document the entire process from setting the honeypot trap to taking apart the malware. I tried to make this page understandable to everyone to the best of my abilities. I hope you will find this deep dive as interesting as it was for me. It's about a 10-15 minute read.

1. The Honeypot

A honeypot is a service, which catches incoming connections, login attempts, file uploads etc. on a specified port (port 22, SSH in this case). It emulates a complete system, pretending to be an actual computer, responding to commands, while being completely fake.
I chose Cowrie for this task, as it can handle SSH (and several others, but I didn't use them). I wanted it to be completely secure, so I used docker, while isolated from the other dockers running on my home server.
The docker-compose setup is the following (open a new yaml file using nano docker-compose.yml):

• restart: "no" - This disables automatic restart of the docker, in case of a crash, I didn't want the docker to be vulnerable.
• security_opt: -no-new-privileges: true - The docker cannot create higher privileged users than itself.
• ports - Both SSH and TELNET ports are open, but I only used SSH here. Cowrie listens to SSH on the internal 2222 port, where the outside 22 port is routed to
• volumes - The first noteworthy mount here is the fake_userdb.txt, which is a text file,
  containing only *:*:*. This allows any username:password combination to log in.
  (cowrie.cfg is also important, we will get to it in a second)
• networks - The docker is on an isolated network, called isolated_honey, which has internal: false, because we want to receive information from the outside world, and driver: bridge is the default docker setting, it just lets this docker talk to other dockers on the same network. (But currently there is none)

2. Cowrie

By default Cowrie's logs are basically unreadable, in their default form:

3. Static Analysis

Static Analysis means to analyse the file, while it's on the disk, not being run

First, we have to see what type of file this is.
After running file 59c29436755b0778e968d49feeae20ed65f5fa5e35f9f7965b8ed93420db91e5, we get the following result: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header
Let's dissect this:

• ELF 64-bit LSB executable - This just means the code is written for Linux systems, and is an executable binary (compiled machine code)
• x86-64 - written for modern 64 bit systems (This is why I chose this file, the others were written for different architectures)
• statically linked - This means that the executable can run without any external dependencies, everything is built into the executable to be able to run.
• no section header - This is the most painful one to see, it means that the data that labels parts of the code (function names, locations), has been removed. This makes reverse engineering much more difficult.

I decided I'll try to decompile it with Ghidra anyway, just to see if I could get any information. After loading the file, I tried to get the strings out of the binary. This amount of strings in a binary file is very unusual, it often has thousands, not six.
But still, this result tells us a very important detail: This file is packed with the UPX executable packer
But just in case, I checked the binary itself: And there it is! In the top right: #UPX!
I was definitely not going to unpack the file on my server, in case anything bad happens, so I created a Debian Bookworm 12 virtual machine on my host computer. I installed some tools, and got the malware on the VM.

There was a possibility of the malware author modifying the UPX header, just enough for the binary to still be able to run, but it wouldn't be possible to unpack it. Thankfully, this wasn't the case: After giving it back to Ghidra in its unpacked form, we have many more strings: We can already see the word CRYPTO, which is the first sign it's a crypto miner.
When scrolling down a little, we can find actual coin names: It uses XMRIG, which is a popular open source Monero miner. Monero coin is favorable for hackers, because it's nearly impossible to track where the mined coins are being sent, thus the attacker remains anonymous.
There are multiple coins listed, probably backup coins, if there is anything wrong with the Monero pool, or the CPU can't mine efficiently.

4. Dynamic Analysis

Dynamic Analysis means to examine a process while it's running

I couldn't get any more meaningful information from reading the insides of the binary, so I decided to switch to dynamic analysis.

First of all, let's get the malware ready:
chmod 777 malware - Sets read, write, execute permissions to every user.

We can start the debugger with gdb ./malware

Now that we have everything ready, let's start the debugger: run

While trying to work out what to do, I checked top to see what was slowing the VM down. We can see that the kworker+ is using 26.7% CPU, which is high for an empty install, which isn't doing any actual system processes.

Thankfully there is a process strace which can track a process, even if it constantly opens and closes new ones.
Running sudo strace -f -s 1000 -e trace=execve,write,connect ./malware we can see every execution, file writing and network connection attempt from the malware: A summary on what can be seen on this image:

• The malware is writing a crontab entry, which makes the malware start every time the system is restarted.
• It's trying to open a backdoor on port 38901 using iptables, but is failing, because iptables didn't come preinstalled with the system. It's goal is to be able to remotely access the system later.
• Now the most interesting part. At the bottom part of the screen, we can see a hardcoded IP address. The malware is trying to connect to 95.215.19.53 on port 853, which is DNS-over-TLS, which is an encrypted version of DNS.

Interestingly, when running nslookup 95.215.19.53 we can find an actual URL:

Running sudo ip addr add 95.215.19.53/32 dev lo reroutes that IP address to our loopback address, which means that any data sent to 95.215.19.53, just gets "sent" to us instead.

Firstly, I tried running strings on the log, which displays all text in a binary (or any other type) file. Since this is a statically linked binary, most of strings output will be system messages and error strings, which are not relevant, but I decided to include it anyway.

• stratum+tcp:// - Stratum is a protocol used in crypo mining
• selfrep - Usually means "self-replication", as in infecting other PCs, like a worm
• redtail - This is a cryptomining malware family
• masscan and zmap - These are mass scanning tools, to find other PCs

• 45.148.10.68 - Based in Netherlands, Amsterdam
• 45.148.10.112 - This one, and the ones below are all from Andorra according to IP lookup sites, but a Censys (world wide IP and port scanner) search confirms they are all from Netherlands
• 45.148.10.144
• 45.148.10.113
• 45.148.10.145
• 45.148.10.208

These IP addresses are proxies, which means they act as middlemen between the infected computers and the actual mining pools. All of the infected machines use one of these proxies, and the hacker can "collect" the hashing power in a single place.

The Censys search also confirmed, that these 6 IP addresses are the only ones open on port 2137, so they are part of the hackers network. They are also open on 21370, but the service is unknown. Probably a backup.

Upon searching a little bit more, I uncovered more urls: All of the p.2137gang.* urls lead to the same IP: 130.12.180.51

Interestingly, the address leads to Germany which is weird, since there are many mentions of the 2137 Poland meme, and one of the addresses ends with .pl, once again meaning Poland. Unless this is another proxy, or if they have their main server in Germany.

I had one last idea, to dump the entire virtual machine memory into a single file on my host PC, and scan through there, but unfortunately it yielded no results. I could only find what we already knew.

4. Conclusion

As soon as I realised this malware is a miner, my self defined goal was to find the wallet address of the hacker. This, unfortunately, didn't happen, as the wallet address is probably on one of the proxies, or on the main server, to avoid people finding it like this. It also could have been encoded somewhere, but unless I want to spend days filtering through the entire virtual machine's memory dump, I will never find it that way.

This was my first time really digging myself into these kind of investigations, and even though I couldn't find everything I wanted, it was a really satisfying process to catch a malware with a honeypot, and take it apart as much as I could, and find interesting things.

Thank you for reading!

5. IOC (Indicators of Compromise)