\\
Author Eric Tsang
Introduction
A honeypot is a great tool used to detect and gain insights into hacking attempts by setting up a decoy to lure in cyber attackers. There are many details that can be analyzed using a honeypot including origin of attack, how many attempts from a specific ip, input used in a terminal, and many other interesting factors. Telekom-Security has a great pre-built honeypot called Tpotce.
I used Amazon Web Services to spin up an instance that hosted Tpotce in Bahrain to monitor and analyze traffic to the honeypot. The platform is great because it is easy to deploy and simple to use; the current version includes 23 honeypots. The Elk stack makes it easy to visualize the data collected and Spiderfoot consolidates many OSINT activities into one place. For this analysis I will be focusing my findings using the Cowrie honeypot over a 24-hour period, Oct 18, 2021, 12:00:00 → Oct 19, 2021, 12:00:00. Cowrie is a medium to high interaction SSH and Telnet honeypot designed to log brute force attacks and shell interaction once a system is accessed.
Attack Input
The Cowrie Dashboard overview shows 12,029 attempts from 158 unique IPs, which may seem like a lot, but many of these attempts, as previously stated, are logged brute force attempts into SSH. Over the 24-hour period 85% of attacks were aimed at SSH. On the other hand, only 15% were aimed at Telnet.
Nine out of the top ten IP addresses came from the Viettel Group in Vietnam. According to Talos Intelligence and virustotal.com, many of the results upon look up appear like the images below:
The Viettel Group is a state-owned, multinational, telecommunications company headquartered in Hanoi, Vietnam. It is the largest telecommunications service provider in Vietnam operated by the Ministry of Defence. The company has evolved from a construction company to a complex of 5 business lines including IT (Information Technology), research and manufacture of electronic and telecommunications equipment, defense, and cyber security and digital services.
The top usernames and passwords seem pretty consistent with someone using brute force to attempt to log in. Many of the passwords can be found in common password text files, like rockyou.txt. There is a good mix of usernames of people just trying to gain access, opposed to gaining access with elevated privileges.
Next, I wanted to look at unique attacks that used command line input once Telnet had been exploited. The inputs shown below are examples of different ways attackers were trying to exploit the server.
Even though the attacks are coming from various sources, many of them have had similar but different goals. This first attack demonstrates the second stage of an attack, as if the device is compromised. Once the attackers gain access, they’re looking to obtain basic information using simple linux commands.
The command “enable” provides attackers with a list of available commands when executed without any parameters. Executing commands like “shell” “sh” “linuxshell” “/bin/busybox” the attacker is trying to find the shell executable to spawn a shell when it’s available.
Here, the attacker gains access to the /tmp folder. Then they remove all files and folders recursively in there and unlinks the files. They then download i and through the next series of commands gains more information in the systemd directory that could lead to persistence.
Attackers execute commands to check if they’re available or not in order to download or transfer files
wget (non-interactive network downloader)
tftp — (IPv4 Trivial File Transfer Protocol client)
To learn information about the CPU such as processor, model name, features, and other characteristics:
cat/proc/cpuinfo
Attackers may look at available storage devices on the systems to obtain persistence with commands like:
Cat /proc/mounts
cd /tmp; cat .s || cp /bin/echo .s;
Attackers are trying to gather information by targeting the binary echo. The aim is to cat the header of an existing binary on the system and parse the ELF header.
dd bs=52 count=1 if=.s || cat .s || while read i; do echo $i; done < .s
It appears that this attacker is downloading a crypto mining script from a URL.
This attacker is downloading a file from a specific IP address. They proceed to change the permissions to allow access for the user, group, and anyone else. Once the file is downloaded they try to execute the file.
It seemed like the attackers that used a lot of input were more interested in seeing what was accessible. I found it interesting that the attackers that only had one or two occurrences of input were more concentrated on downloading files quickly and efficiently using more complex input.
MALWARE ANALYSIS
In order to test some of the downloaded files, I set up a sandbox environment by spinning up a new instance of SIFT workstation. The first download I looked into was the setup_c3pool_miner.sh.
136.144.138.169
Using hybrid-analysis.com gave me a quick overview that this file is definitely malicious with a threat score of 97/100. Many of the anti-virus scan results show that it is a trojan/shell miner.This malware has the potential to infect many computers because it runs the curl command with the -s option, making it silent so it won’t show the progress meter or error messages. It provides how many threads the host CPU has and projects the hashrate. It proceeds to remove any previous c3pool miner (if any) then unzips the downloaded file. Many victims wouldn’t know anything is even happening because once downloaded the mining script initiates and runs in the background.Checking the file created on the home directory shows .json config files, a miner.sh script, xmrig executable, and the xmrig.log.
There seems to be some persistence in the config.json file. I tried to kill the process several times. However, every time I killed the process, the config.json file would be up again with a different PID. The log shows that it receives a signal to terminate, but starts right back up immediately. There is also a url in the config file — mine.c3pool.com:17777, but the connection was refused when navigating to the url; this also appears in the xmrig.log
I used the command find / -name *c3pool* 2>/dev/null to find any other directories or folders pertaining to c3pool. In the /etc/systemd/system directory was a c3pool_miner.service file.
This is interesting because this directory stores unit files that extend a service and will take precedence over unit files located anywhere else in the system. It seems though, this malware doesn’t self install after deletion. I deleted the c3pool directory from my home page, and the associated files in the /etc/systemd/ system directory. Then, I restarted the virtual box and searched for remnants of c3pool but couldn’t find any evidence of reinstallation.
Unfortunately, the other attackers that tried downloading files from another IP address all returned 404 errors.
Summary
Analyzing the attacks from the honey pot opened my eyes to the incredible amount of attacks occurring daily all over the world. I wish I could have seen what the attackers were doing when they were downloading and executing files from an IP address instead of a URL, but next time I will try to monitor attacks live in an attempt to see what the executable files do. From looking at the honey pot I’ve learned that no matter how big or small an entity you are, anyone can be a target. Attackers can constantly running scripts or botnets trying to compromise devices; within seconds of spinning up the instance the server was under attack.
In order to prevent brute force login attempts, make sure to turn off SSH services if you don’t need them. Also, Telenet is provides a command line interface on the remote host and information is unencrypted so disable this service as well so attackers don’t have a way to run commands. Having a good IPS/IDS like antivirus/antimalware software is recommended for anyone. For example, Norton antivirus software blocked requests coming from the crypto miner because my sandbox was connected to my host network. Protect yourself from ransomware, malware, and other cyber attacks by following good security practices.
About the Author: Eric Tsang has recently broken into the cybersecurity industry as a Penetration Tester focusing on web applications and APIs. I spend most of my time trying to improve my knowledge and skills through various cyber ranges and am interested in all things Red and Purple teaming. Passionate about helping educate others about the importance of having good security posture.