For this project I wanted to experiment with the consequences of putting a server directly on the internet and what attackers would do with that. So I leveraged a tool called Cowrie Honeypot which emulates a UNIX system providing SSH and Telnet access to the world. As it emulates a UNIX system, the attacker is only ever interacting with a sandboxed environment which is capturing all their moves and input. However, a clever attacker may still be able to find a vulnerability in Cowrie and escape so I still ran it on a disposable DigitalOcean machine which was terminated after the experiment.
After running Cowrie for a little bit and digging into the raw logs, I realised I’d need a better way to analyse the huge amount of data. Following this excellent guide, I managed to get a Splunk system started and fed the output of Cowrie to it.
After running it for about 13 days the system had been logged into successfully 264,000 times from around 1700 different IPs. This is a staggering amount considering that I didn’t tell anyone about this system and this is purely traffic from attackers/researchers scanning the IPv4 space.
Now having a good overview of the attacks, I could focus on the ones that dropped files that triggered VirusTotal. Once again digging into the logs, I could see attackers log into the system, pull malicious files from their C2 servers and try to run them. The Cowrie system usually stopped them from actually getting past this point (because they are only interacting with an emulated UNIX environment rather than a full one) so we can’t see what happens next but I can only assume these malicious files would either break the system with ransomeware or install some backdoors.
Also of note are the commands that start with a “/” and usually involve “.rsc” files (as can be seen in the images above). These are commands for configuring a Mikrotik router. Looking closely at the command we can see that it again follows the same pattern as above, they are gaining access to the system and then running a command to pull a script file and run it (this time as a scheduled job for persistence). It was certainly suprising to see so many attacks trying to exploit this kind of router (which I also use in my own home network).
As well as the attacker scripts we can also see what username and password combinations that were tried. It’ll probably suprise no one that the most common username seen was “root” with the most common password as “admin”. This data is really useful to understand what passwords to avoid but also may help us further understand what devices are being targetted if we see unusual passwords that are associated as the default with one particular device.
Had I have run this experiement for longer it would have also been really valuable to see changing trends of what devices are being attacked and the current payloads that are being used against them. As the payloads are often pulled from attacker controlled servers, it’d also let me track C2 server use and location. This would also give me ample amounts of payloads to reverse engineer so if I move more into reverse engineering then I’ll certainly restart this system.
Overall, this proved to be an extremely interesting experiment for gaining insight into automated attacks (techniques, credentials & payloads) that are performed on devices left on the internet and proves a cautionary tale to ensure you secure everything that is open to the internet.
