How do Hackers Hack – An Experiment in Open Portal Attacks
I built it – and hackers came
It’s been an eventful 12 months. With people working from home, there’s been an over 40% surge in machines accessible from the internet running RDP, with RDP attacks up over 400%.1 This site even has instructions for how to create more than one RDP instance on the same Windows 10 machine.2 There are also these instructions for Windows 2016, that create a larger attack surface that by allowing multiple RDP connections into the same endpoint.3 Lots of companies enable access to critical systems via web portals with logins requiring you pass identity authentication, but SolarWinds SUPERNOVA and Microsoft Exchange ProxyLogon showed how quickly a vulnerability compromises that security.
But are hackers really scanning the internet, looking for places to attack? Have you wondered how often an average IP address gets scanned and then attacked? I decided to find the truth in the humorous movie quote, “If you build it, he will come” by setting up a basic honeypot with a boring name in an out-of-the-way web hosting center. This, I thought, might answer the question of whether attacks are focused on the big IaaS/PaaS providers, or whether an SMB (that I’d be mimicking) might be found, scanned, and then attacked—and how quickly.
What is a honeypot, you may ask? The term comes from the world of espionage, wherein spies used romance as a way to steal secrets, which was called setting a ‘honey trap’ or ‘honeypot’. The cyber version works in a similar way – creating a sacrificial computer system that is designed to sit on the internet and look innocent and unprotected, mimicking a target for hackers. It uses their attacks to gain information about the tactics, techniques, and procedures (TTPs) used by malicious actors.
The Experiment- Setting up the honeypot trap
Here are the four simple steps I used to mimic an SMB on a budget.
- Signed up for an account with a cloud provider that isn’t one of the well-known three AWS, Azure, GCP.
- Spun up a Linux VM and deployed a multi-spectrum honeypot.
- Attached a public IP to this VM.
- Monitored the logs.
Why An Account on a Smaller Cloud Provider?
For this test, why did I not want to sign up with the top three cloud providers? I suspect their public CIDR blocks are perhaps too well known and top of the list for botnet scanning. I know people are constantly looking for insecure AWS configurations, S3 buckets with clear text passwords, and, likewise, Azure blobs for configuration errors that are easy to hack.
Deploying the Honeypot
While you could run various opensource honeypots a la carte, there is no substitute for a full spectrum package like T-Pot. It containerizes 19 honeypot projects, each specializing in a particular service, that has them working together like a complex organism. The included ELK Stack was the cherry on top to present all collected data in a beautiful dashboard. Data is broken down in multiple ways to help you visualize patterns quickly from most popular ports probed by origin country to Username/Password combos attempted most often. Every organization should have at least one T-Pot running. I can’t recommend this Github project enough.
I was expecting plenty of scanning—everyone gets scanned, all the time. If you have no services open and you are only listening to the traffic, you have little to worry about. Being port scanned, while mildly annoying from generating extra logs on your firewall, does no actual damage. At high volumes, the constant scanning could cause your threat hunting team to miss an actual attack commencement amongst the noise, but that’s a topic for another post.
I thought about spinning up a regular server with WWW/RDP/SSH/VPN services to mimic a real-world machine in the wild. However, the logging facilities are geared towards the day-to-day operations and not optimized for detecting port scans and interactive hacking attempts.
Attaching the Public IP
I purposely did not advertise my IP to the hackers with an exciting DNS record like:
Monitoring the Logs
I bet you have a number in mind for how long it took for crawlers and botnets to find my anonymous IP and start scanning it. I wondered too—would it take them an hour? 1 day? 1 week?
How about 30 seconds? Yes, within 30 seconds the scans started showing up. Within 60 seconds, I had my first login to Cowrie (SSH honeypot service). And within 3 minutes, the first exploits were being uploaded and captured by Dionaea, the malware and exploit capture honeypot. (All this visibility was achieved by running T-Pot, which will open your eyes quickly to the unseen internet.)
I let the experiment run for only two weeks, and here are my results:
Adding up the stats from all 19 honeypots, I was hit by roughly 2 million attacks against my single public IP. That’s not scans—that’s active toolkits and scans and attempts to compromise through my (fake) available services.
Doesn’t VPN or VDI Technology Make You Safer?
Yes, I introduced an attack surface to the world that looked ripe for the plucking. But this is no different than every enterprise out there who has needed to host publicly facing Web/SSH/RDP/VPN services for their employees to access internal tools they need to do their work. Working from home was not merely an option due to Covid, it was a requirement for most jobs requiring a computer.
Many organizations are attempting to minimize their IP attack surface by hiding their internal services behind the VPN Concentrator or a Secured Portal like F5’s APM. But as illustrated by F5’s recent announcement of critical vulnerability CVE-2021-22986 that allows Remote Command Execution, by just having the F5 BIG-IP exposed and listening on the internet introduces a lot of risk. And attacks against VPNs themselves are rising; Citrix and Fortinet have both had their VPN modules hacked. Virtual Desktop Interfaces (VDIs) are under siege as well.
What About Patching management?
As all long time Microsoft administrators know, patch Tuesday brings a bounty of bug announcements with their fixes from Microsoft. Exploit Wednesday quickly follows as bad actors waste no time in modifying their weapons with the newfound knowledge. Unfortunately, this is often followed by ‘Uninstall Thursday’ as patches, not just from Microsoft, have resulted in introducing other critical issues to the patched system.
When you’re patching a single node, the risks are fairly low. However, if you’re patching a VPN gateway or F5 APM that all your employees depend on daily, the risks of patching are substantially higher. As one VPN vendor support engineer once told me, “We urge you to apply the patch to your VPN ASAP, but there is a 40-50% chance you might, just might, brick the box. So be at a location where you can physically reboot the box and have access to lights out management to undo the patch.”
You can’t leave your network open, but you can’t always patch reliably; what should a responsible CISO to do? There is a better choice in a Zero Trust Network Access model. A SaaS ZTNA solution makes your old VPN attack surface disappear. Hackers can’t attack what they can’t see. The Axis Security Application Access Cloud provides complete ZTNA protection using a SASE overlay approach, so no matter where the applications live or where the users are logging in from, you get end-to-end protection from device to network to app. It even includes features like adaptive access controls, user monitoring for dangerous activity, and the ability to revoke access and end sessions if threats are identified.
2 Increase in RDP connections: https://www.thewindowsclub.com/increase-the-number-of-remote-desktop-connections-in-windows-10
3 Enable concurrent RDP sessions: https://social.technet.microsoft.com/Forums/en-US/c52b6da7-cdf2-4e1f-95d1-6471c6f2f6b0/easiest-way-to-enable-more-than-2-concurrent-rdp-sessions-on-windows-server-2016?forum=winserverTS