Virus analysts and computer security researchers strive to collect as many samples of new botnets as possible. They use honeypots for their own purposes... But what if you want to observe the malware in real conditions? Put your server, router under attack? But what if there is no suitable device? It was these questions that prompted me to create bhunter, a tool for gaining access to botnet nodes.

main idea

There are many ways to spread malware to expand botnets, from phishing to exploiting 0-day vulnerabilities. But the most common method is still brute-force SSH passwords.

The idea is very simple. If some node of the botnet is bruteforcing passwords to your server, then most likely this node itself was captured by brute force simple passwords. So, in order to gain access to it, you just need to answer him with “reciprocity”.

This is exactly how bhunter works. Listens on port 22 (SSH service) and collects all logins and passwords with which they try to connect to it. Then, using the collected passwords, it tries to connect to the attacking hosts.

The algorithm works

The program can be conditionally divided into 2 main parts that work in separate threads. The first is honeypot. Processes login attempts, collects unique logins and passwords (in this case, the login + password pair is considered as a single entity), and also adds to the queue for further attacks the IP addresses that tried to connect.

The second part is directly responsible for the attack. Moreover, the attack is carried out in two modes: BurstAttack (queue attack) - enumeration of logins and passwords from the general list and SingleShotAttack (single shot attack) - enumeration of passwords that were used by the attacked node, but have not yet been added to the general list.

To have at least some database of logins and passwords immediately after launch, bhunter is initialized with a list from the /etc/bhunter/defaultLoginPairs file.

Interface

There are several ways to start bhunter:

Just a team

sudo bhunter

With such a launch, it is possible to control bhunter through its text menu: add logins and passwords for an attack, export a database of logins and passwords, specify a target for an attack. All hacked nodes can be seen in /var/log/bhunter/hacked.log

Using tmux

sudo bhunter-ts # команда запуска bhunter через tmux  
sudo tmux attach -t bhunter # подключаемся к сессии, в которой запущен bhunter

Tmux is a terminal multiplexer, a very handy tool. Allows you to create several windows within one terminal, and split windows into panels. Using it, you can exit the terminal and then log in without interrupting running processes.

The bhunter-ts script creates a tmux session and splits the window into three panes. In the first - the largest, there is a text menu. The upper right contains the honeypot logs, here you can see messages about attempts to enter the honeypot. The lower right panel displays information about the progress of the attack on botnet nodes and about successful hacks.

The advantage of this method over the first is that we can safely close the terminal and return to it later without bhunter stopping the work. For those who are not familiar with tmux, I suggest this cheat sheet.

As a service

systemctl enable bhunter
systemctl start bhunter

In this case, we enable bhunter autostart at system startup. This method does not interact with bhunter, and the list of hacked nodes can be obtained from /var/log/bhunter/hacked.log

Efficiency

While working on bhunter, I managed to find and access completely different devices: raspberry pi, routers (especially mikrotik), web servers, and once a mining farm (unfortunately, I had access to it during the day, so there was no interesting story ). Here is a screenshot of the program, which shows a list of hacked nodes after several days of work:

Unfortunately, the effectiveness of this tool did not reach my expectations: bhunter can sort out passwords to nodes for several days without results, or it can crack several targets in a couple of hours. But for a regular influx of new botnet samples, this is enough.

The efficiency is influenced by such parameters as: the country in which the server with bhunter is located, hosting, and the range from which the ip-address is allocated. In my experience, there was a case when I rented two virtual servers from the same host, and one of them was attacked by botnets 2 times more often.

Bugs I haven't fixed yet

When attacking infected hosts, in some situations it is not possible to unambiguously determine whether a password has come up or not. Such cases are logged in the /var/log/debug.log file.

The Paramiko module, which is used to work with SSH, sometimes behaves incorrectly: it goes into endless waiting for a response from the host when it tries to connect to it. I experimented with timers, but did not get the desired result.

What else needs to be worked on?

Service name

According to RFC-4253, the client and server exchange the names of services that implement the SSH protocol before installation. This name is contained in the "SERVICE NAME" field contained both in the request from the client side and in the response from the server side. The field is a string, and its value can be found using wireshark or nmap. Here is an example for OpenSSH:

$ nmap -p 22 ***.**.***.** -sV
Starting Nmap ...
PORT   STATE SERVICE VERSION
22/tcp open  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protocol 2.0)
Nmap done: 1 IP address (1 host up) scanned in 0.47 seconds

However, in the case of Paramiko, this field contains a string like "Paramiko Python sshd 2.4.2", which can scare off botnets that are designed to "avoid" traps. Therefore, I consider it necessary to replace this line with something more neutral.

Other vectors

SSH is not the only means of remote control. There is also telnet, rdp. It's worth taking a look at them.

Expansion

It would be great to have several traps in different countries and centrally collect logins, passwords and hacked nodes from them into a common database

Where can I download?

At the time of this writing, only a test version is ready, which can be downloaded from repository on Github.

Source: habr.com