A Honeypot Analysis
Introduction
The setup of this project began with configuring a virtual private cloud (VPC) and launching an elastic cloud compute (EC2) instance on AWS. Then, from GitHub the honeypot was uploaded to the instance via the Linux command line. Next, the security groups were configured to allow inbound access from only my IP address over two specific ports, one for the command line access and the other for browser access to a GUI. Lastly, inbound access was given to 0.0.0.0/0 over ports 1 through 64,000 to let the attackers have access. Outbound access for leaving the honeypot was configured to allow all traffic out of the honeypot.
Overview
The objective of this report is to analyze attacks against an intentionally vulnerable machine to shed light on the type of attacks happening in the real world. This report will focus on an eight hour time period beginning November 3, 2021 at 16:00 and ending November 4, 2021 at 00:00. In the end, I would like to give some insight on how to protect against these attacks.
Cowrie Honeypot
The first honeypot to examine is Cowrie, which is a medium to high interaction SSH and Telnet honeypot that logs brute force attacks and the shell interaction performed by the attacker. In the eight hour period between November 3, 2021 at 16:00 and ending November 4, 2021 at 00:00 there were 1,428 cowrie attacks including shell interactions, login attempts, and commands run. These attacks look decentralized, but the attacks came from a cluster of regions with Southeast Asia leading the way followed by the Southwest US, and Eastern Europe.
While nearly all attacks were against SSH and Telnet, one conflicting data point showed a handful of attacks against HTTP and HTTPS shown in the “Attacks by Destination Ports Histogram” above. However, in the pie chart below “Attacks by Port” it shows the only ports attacked were SSH and Telnet. This leads me to believe either the data sample for HTTP and HTTPS were such a small percentage that it did not register or those attacks may have been false positives.
In the Cowrie dashboard, at first glance the results are unsurprising. There were many brute force password attempts tried over the 8 hour period. These attempts used SSH on port 22 (53%) and Telnet on port 23 (47%). As displayed in the chart “Attacks by Country” the highest percentage of attacks came from the United States at 35%. According to the “Attacker Src IP Reputation” chart an overwhelming majority of the source IPs were known attackers. However when looking at these attackers’ IP addresses I could not pinpoint whether they were a part of some organized crime or APTs.
Brute Force Username and Password Attacks
As expected the top three usernames tried were root, user, and admin. These usernames are very common default usernames. Root had the most login attempts at 60, followed by user, and admin with 33, and 13 respectively. It makes sense that the majority of the attackers go straight for the root account which has the greatest privileges.
Some other interesting usernames used were miner, postgres, and xerox. These usernames seem to indicate the attacker’s target is a cryptominer, SQL database, and printer. One thing I would have expected is attempts to use SQL injection to bypass the login, but there were no username or password attempts using SQL injection.
As for passwords, the top three passwords tried were “1”, “123456”, and “1234” with 42 different login attempts tried among the three passwords. One IP (209.141.60.103) that was seen with a lot of activity throughout the cowrie honeypot tried and succeeded at gaining access with the credentials user=root password=1.
Successful Logins
While there were many unsuccessful attempts to login into Cowrie there were a small number of attempts (13 in total) that succeeded in gaining access. After researching on google I found that many of the successful username/password combinations could be found online. This makes me think that there must be some updated password list on the dark web that attackers use.
Commands Run
The first command came from a known attacker whose IP address (209.141.60.103) is located in Las Vegas. However a quick check of the IP reputation reveals it was likely a bot and the location was the VPN endpoint. Also after looking into the service provider it was found that FranTech solutions offers cloud computing VMs. This further indicates that this attacker is either a machine infected by a bot or was intentionally set up with scripts to search for vulnerable machines and attack them.
After doing some research, it looks like this command downloads and installs a crypto miner that mines a cryptocurrency named Monero (XMR). After I ran the command in kali, sure enough the miner automatically started working after installation.
According to Kaspersky, this sort of malicious behavior is defined as Cryptojacking which is a type of cybercrime that involves the unauthorized use of people’s devices (computers, smartphones, tablets, or even servers) by cybercriminals to mine for cryptocurrency.
One thing that came as a surprise to me was that the cryptocurrency being mined was not a more major and expensive one like Bitcoin or Ethereum. Although after looking into Monero it has developed into a fairly profitable cryptocurrency over time listed at $243.59 per coin at the time I checked (November 17, 2021 12:00).
Analysis
The command does indeed download and installs a cryptominer. The “492cUvVMbMsKpWGoSkTSbzix9Pk2Ho6XUid9vRSFALXjfQS76gyNGjnTh6DTpPHwnBAHDztwbWUGiCfZgkbndYtAMuekPcA” input looks to be the wallet where the mined cryptocurrency will go.
Executing the ./miner.sh binary runs the miner although it starts automatically by default. The ./xmrig binary gives more information about the processes of the miner.
Here is a snapshot just to show the drain on the cpu due to the miner running using 99% of the cpu. Followed by the screenshot showing cpu usage after the miner process was killed.
Russia Command Line Attack
The next attacks via command line came from Moscow, Russia. The IP (213.141.154.246) reputation came back as a known attacker and the location of the IP address checked out. Here the attacker ran a few commands trying to enable commands, check system info and open a shell. The command beginning with “dd” failed because the command is not supported in cowrie shell emulation. After googling the commands “tftp; wget; /bin/busybox KBIKH” and “dd bs=52 count=1 if=.s || cat .s || while read i; do echo $i; done < .s” it looks like this attack is coming from a machine that may have been infected by the Mirai botnet.
Lithuania Command Line Attack
Another interesting command that captured my attention attempted to change the default password, kill two processes and reveal all usernames. This came from a known attacker in Lithuania according to an IP reputation check. This IP checked out and looked like it came from Lithuania. The new password the attacker tried to use looks like it was meant to be encoded. I found it odd that this attacker came back a few hours later to run the same command, but this time it was properly encoded as base64. The attacker even has base64 behind the encoding to indicate it is base64.
South Korea Command Line Attack
The next attack came from a known attacker in South Korea (203.253.68.244) listed at Hankuk University of Foreign Studies Computer Center. Here the attacker ran several commands to find information about the system and to identify and capture any cryptocurrency miners that may exist.
Campbell Command Line Attack
Here it looks like the attacker checked if the echo command will work. The command argument is the word ok encoded as hex.
San Jose Command Line Attack
Only a few hours later there are more attacks just like the earlier attack to change the default password, coming from an attacker in San Jose, California associated with the FranTech service provider (205.185.120.180).
Another Command Line Attack from Russia
The other attack from the IP (195.133.18.210) had multiple locations associated with it. The cowrie dashboard tracked it back to Russia however, I looked up the IP which placed it in Los Angeles, California. Talos intelligence associated it with the Czech Republic. Another one pinpointed it to a gas station in Walnut, California, illustrating how elusive it can be to figure out where an attack is coming from. This attack is pretty similar to the attack from Lithuania where they tried to change the default password, kill two processes and reveal all usernames. However, one difference noticed between the earlier attacks from Lithuania was that at the end of this command it looks like it is searching if there is a cryptocurrency miner on the machine.
ADB Honeypot
The ADB Honeypot is a low interaction honeypot designed to look like a vulnerable android device. At a first glance the attacks look decentralized coming from all around the world.
Over the eight hour period between November 3, 2021 at 16:00 and ending November 4, 2021 at 00:00 there were 102 total attacks coming from 37 different IP addresses. The top places where attacks came from were the United States (43%), South Korea (15%) and Canada, China, Hong Kong, Netherlands, and Venezuela tied at (7%). All attacks came from known attackers with bad IP reputations.
Commands Run
The ADB honeypot found 8 commands ran over the eight hour period. The first attacker with the IP (209.141.37.52) goes to the tmp directory to create a new directory “.dev” and changes to that directory. Then a wget command is run to download a file from the http server with the -q option for silent. Next the curl command is run to get some file or download from that http server followed by chmod777 to change privileges to all. The files being downloaded are likely some kind of malicious file. Then the last commands run is to force delete everything and clear the history with rm -rf and history -c. A similar attack almost identical to this one comes from several different IPs. They were all are trying to download files from those IPs and run them on the ADB Honeypot.
Analysis
After putting the URL in virus total in came back malicious.
When I went to the address in Kali this is the commands that were being downloaded and ran. Whatever it was being downloaded and ran I can imagine it is not anything you would volunteer to have on your device.
The Attackers
One point of interest I discovered about the attackers running the above commands was that their attacks all used the same host, Frantech. Each and every one of these eight IPs were hosted by Frantech and all of them came back as malicious. Again, it is likely that the attack came from bots running scripted attacks. Because the host used a proxy server or vpn it is difficult to say where this attack really came from.
Seeing this much activity from IPs associated with FranTech solutions further strengthened my earlier hypothesis that an attacker either compromised a cloud compute VM or used FranTech to run scripts that will attack vulnerable machines. Further research on shodan.io leads me to believe the device was compromised and was being used as a scripted bot attack.
Preventative Measures
Usernames — It is a good practice not to use default or common usernames for login purposes because that makes brute force attacks easier for attackers. If the attacker can easily guess the username the attack is easier because then all they have to do is input the username and run a password attack using hydra and a password list like rockyou.txt. However, if the username is not easily figured out this makes the attacker’s job much harder to successfully gain access through brute force password attacks.
Passwords — Of course other ways to prevent unwanted access is to maintain strong password policies, create a lockout policy after 3 failed attempts, enable multi factor authentication, and practice rotating passwords every 3 months.
Port Filtering — Any ports that are not used should be filtered because as demonstrated by the honeypot, having unnecessary ports open can lead to all kinds of trouble that can be prevented by simply filtering ports.
Whitelisting IPs — If there is a need to keep a certain service open the organization’s cidr range could be whitelisted to allow only those IPs to use the service.
Per usual, feel free to comment and make suggestions as I am always happy to take constructive criticism. Thanks for reading!
-Zer0rigin
