I've been working with many different honeypot implementations lately - from cowrie and WordPot, to Dionaea and WAPot. To expand on that, I decided to set up a simple docker image with SSH, running a guessable root password. The catch? I'd be capturing all the credentials used to login to the docker image, as well as the entire shell session, to a log file and the screen. The attacker wouldn't easily know what I was doing, because I'm using a docker image, instead of easily identifiable honeypot.
I let the docker image honeypot run for 24-hours, logging and tracking the attacks during that period. Almost immediately, I noticed a trend . Attackers who were using certain password combinations would use the docker image for different criminal activities. Log-in combinations of root:admin, root:root, oracle:oracle would invariably use the docker image as a SOCKS5 proxy through SSHd. The content that is being proxied? Twitch streams, google.com, netflix.com, and others. I found out from a colleague that the Twitch stream proxies were probably being used to pad a player's stream viewer count.
The logins were mostly automated, and not allocating a PTY (pseudoterminal) in SSH. The commands were likely entered this way to avoid showing up on WHO and utmp/wtmp, etc.
$ ssh -l root 192.168.1.20 "uptime"
14:47:34 up 5 days, 19:27, 0 users, load average: 0.00, 0.00, 0.00
Based on the logs, the docker image was also used for botnet installations. The first botnet infection turned out to be an instance of Xorbot net, first discussed by Akamai's SIRT team back in 2015. The installation's first task was to establish persistence via cron entries, and place copies of itself in /usr/bin, as well as startup scripts to /etc/init.d. The command and control communications were handled over domains that resolved to 188.8.131.52 on port 3309. I don't allow outbound connections from my lab to the range the control port was in, so I was unable to analyze any attack traffic.
As expected, the docker image was also infected by a Mirai IOT botnet variant. Mirai uses commonly known username and password combinations for TPLink GPON routers, ThinkPHP, HUAWEI,as well as other exploits to infect targeted systems. Once the source code for Mirai was leaked to the Internet in 2016, criminals have leveraged it to spin-off dozens of variants, and it continues to spread to this day.
Crypto Mining Malware
As also expected when this project first started, the docker image was a prime target for crypto-mining malware. An installation script is run via SSH that monitors the process tree with "top" - a process monitoring tool - checking for when the malware has successfully been executed. Once the process is detected, in this case it is "dhcpcd", the malware adds two new users to the system - test and test1. It changes the root password to ""(blank) and creates entries in cron to start the mining software up after a reboot. It also attempts to set the immutable bit (+i) on various files including /etc/shadow and the malware binary in /sbin/dhcpcd.
The mining software attempts connections to the following crypto mining pools:
The malware also adds a .ssh key to /root/.ssh/authorized_keys:
The mining software reports as XMRig v5.2.0.
SOCKS Proxy Mail Relay
One of the more unexpected uses of the docker image was an email relay. It wasn't the fact that the criminals had used the server as an email relay, because I assumed spam was a possibility from the start. No, the unexpected element was the nature of the email relay itself. Someone was using it for a work-from-home scam.
There were red flags about this email relay from the moment the connections started. The actors intentionally used root/root to log into the Dovecot mail server, something they wouldn't need to do if there was any legitimacy to the messages they were sending. However, after reading the messages and reconstructing the email attachments, the nature of their communications became clear.
There were two people communicating with a third person, who didn't respond to messages. At first, the communications were purchase reports. According to the email logs on the docker image, purchases of high-dollar items were being made at various big-box retailers, and an accounting of those purchases was sent, along with scanned receipts, to a purchasing authority. However, one of the final messages sent reported purchasing issues due to "a concern with the payments" on the cards being used.
Work-from-home scams are common, and based on the logs, it's clear the expense reports were submitted by victims using their own credit cards, or corporate cards (i.e. stolen cards) provided by the criminal, in order to obtain access to high-value retail products, including phones, laptops, and personal tablet computers.
In many cases, the buyer (victim #1) will ship the purchased items to a mule (victim #2), submit an expense report for the charges to the agent (criminal running the scam), and wait for further instructions.
The money spent procuring the items either came stolen credit cards or the personal cards maintained by the victim. The promised reimbursement will never materialize, and when investigators start working backwards, the victims are on the hook for the fraud. Items purchased for $600 via fraud and later re-sold for $400 online in a secondary criminal market will net a profit of $400 to the criminal who pockets the money and walks away.
Resources that aren't properly secured are subject to a myriad of attacks from adversaries with different intentions. In this case, a simple system with SSHd enabled was used for four different criminal campaigns in the span of 24-hours. When connecting systems to the Internet, you must follow basic security practices to ensure your system isn't hacked or used to attack other Internet hosts.