Virus analysts and computer security researchers strive to collect as many samples of new botnets as possible. They use honeypots for their purposes.… But what if you want to observe malicious software in real conditions? Should you sacrifice your server or router? What if the right device is not available? These questions led me to create bhunter — a tool for gaining access to botnet nodes.

Glavna ideja

There are many ways to spread malware to expand botnets: from phishing to exploiting 0-day vulnerabilities. However, the most common method remains brute-forcing SSH passwords.

The idea is very simple. If a node from a botnet is brute-forcing passwords to your server, it’s likely that this node itself was compromised by brute-forcing simple passwords. Thus, to gain access to it, you just need to respond with 'like for like.'

This is exactly how bhunter works. It listens on port 22 (SSH service) and collects all the logins and passwords it attempts to connect with. Then, using the gathered passwords, it tries to connect to the attacking nodes.

Operating Algorithm

The program can be conditionally divided into two main parts, which operate in separate threads. The first is the honeypot. It processes login attempts, collects unique logins and passwords (in this case, a login+password pair is considered as a whole), and adds to a queue for further attacks the IP addresses that attempted to connect.

The second part is responsible for the attack itself. The attack is carried out in two modes: BurstAttack (queue-based attack) — brute-forcing logins and passwords from a general list and SingleShotAttack (single shot attacks) — brute-forcing passwords that have been 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 right after launch, bhunter is initialized with a list from the file /etc/bhunter/defaultLoginPairs.

Vmesnik

Several ways to launch bhunter are provided:

Simply using the command

sudo bhunter

With this launch, there is an opportunity to manage bhunter through its text menu: adding logins and passwords for attacks, exporting the database of logins and passwords, specifying the target for the attack. All hacked nodes can be seen in the file /var/log/bhunter/hacked.log.

Uporabite tmux

sudo bhunter-ts # ukaz za zagon bhunter preko tmux  
sudo tmux attach -t bhunter # povezovanje s sejo, kjer je zagnan bhunter

Tmux je terminalni multiplexer, zelo priročno orodje. Omogoča ustvarjanje več oken znotraj enega terminala, okna pa je mogoče razdeliti na panele. Njegova uporaba omogoča izhod iz terminala in kasnejši vstop brez prekinitev potečenih procesov.

Skripta bhunter-ts ustvari tmux-sejo in razdeli okno na tri panele. V prvem, največjem, se nahaja besedilni meni. V zgornjem desnem kotu so shranjeni dnevniki honeypota, kjer lahko vidite sporočila o poskusih dostopa do honeypota. V spodnjem desnem panelu se prikažejo informacije o napadih na vozlišča bot mrež in o uspešnih vdorih.

Prednost te metode pred prvo je v tem, da lahko mirno zaprete terminal in se mu pozneje vrnete, pri čemer bhunter ne bo ustavil delovanja. Tistim, ki niso dobro seznanjeni s tmux, priporočam tole pomočnico.

Kot storitev

systemctl enable bhunter
systemctl start bhunter

V tem primeru omogočamo samodejni zagon bhunter ob zagonu sistema. Ta metoda ne predvideva interakcije z bhunter, seznam vkradenih vozlišč pa je mogoče pridobiti iz /var/log/bhunter/hacked.log

Učinkovitost

Med delom na bhunterju sem uspel najti in dostopati do povsem različnih naprav: raspberry pi, usmerjevalnikov (zlasti mikrotik), spletnih strežnikov, enkrat pa tudi do rudarskega sistema (žal je bil dostop do njega le čez dan, zato ni bilo zanimive zgodbe). Tukaj je posnetek programa, na katerem je prikazan seznam vkradenih vozlišč po nekaj dneh dela:

Žal učinkovitost tega orodja ni dosegla mojih pričakovanj: bhunter lahko dni preizkuša gesla na vozliščih brez rezultatov ali pa lahko vdrne več ciljev v dveh urah. A za redno pridobivanje novih vzorcev botnetov je to dovolj.

Na učinkovitost vplivajo taki parametri kot so: država, v kateri je strežnik s bhunterjem, gostovanje in obseg, iz katerega je dodeljena IP-naslov. Z mojimi izkušnjami je bil primer, ko sem najel dva virtualna strežnika pri enem gostitelju, in eden od njiju je bil tarča napadov bot mrež dvakrat pogosteje.

Bagi, ki jih še nisem popravil

Pri napadu na okužena vozlišča v nekaterih situacijah ni mogoče nedvoumno določiti, ali geslo ustreza ali ne. Evidenca takih primerov se vodi v datoteki /var/log/debug.log.

Modul Paramiko, ki se uporablja za delo z SSH, včasih nepravilno deluje: pri povezovanju z vozliščem vstopi v neskončno čakanje na odgovor. Eksperimentiral sem s časovniki, a želenega rezultata nisem dosegel.

Na čem še moramo delati?

Ime storitve

Po RFC-4253 se stranka in strežnik pred vzpostavitvijo povezave izmenjata imena storitev, ki uresničujejo protokol SSH. To ime je vsebovano v polju »SERVICE NAME«, ki je prisotno tako v zahtevku stranke kot v odgovoru strežnika. Polje je niz in njegovo vrednost lahko pridobite s pomočjo wireshark ali nmap. Tukaj je primer za OpenSSH:

$ nmap -p 22 ***.**.***.** -sV
Zagon Nmap ...
PORT   STANJE  STORITEV        VERZIJA
22/tcp odprto  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protokol 2.0)
Nmap končano: 1 IP naslov (1 gost aktiven) skeniran v 0.47 sekundah

Vendar pa v primeru Paramiko to polje vsebuje niz v obliki «Paramiko Python sshd 2.4.2», kar lahko odvrne botnete, ki imajo vgrajeno taktiko »izogibanja« pastem. Zato menim, da je potrebno to besedilo zamenjati z nečim bolj nevtralnim.