A lesson in home network security
There’s been a lot of buzz about RDP vulnerabilities of late, and one tweet in particular publicly shamed companies who in 2019 were still using port forwarding to remotely access machines on their corporate LANs. I thought, they’re talking about companies, not regular joes. But the tweet stuck with me and eventually motivated me to take a small step towards improved security. I’ll admit it! I’ve had a random (non-3389) port forwarded to a machine on my LAN to facilitate RDP connections for some time, really just for the sheer convenience and cost effectiveness of it. I selected a port that isn’t commonly used for anything, to help prevent it from showing up on Shodan or any common-only type port scans. It gave me a ‘security through obscurity’ level of confidence that others probably share about their home LANs. I googled easy ways to improve RDP security and came across this guide which walks you through how to set local policy that automatically locks accounts out after so many failed login attempts. I went ahead and set this up on the box I RDP to. On that box, I had only 1 local account which was part of the Administrator group. Today, I went to login to the machine and got this (image from Google images):
OK, I thought, there could be a non-scary explanation for this — maybe a scheduled task I created with stored credentials and completely forgot about or something?
Side note — when you are literally the only user that can login on a machine and get locked out, it’s a pain in the ass to fix! The login screen won’t let you login as any other user and even password resets do not unlock it. I booted to recovery and launched a command prompt, but wasn’t able to see my locked out account from there using net user — it listed other accounts but not the problem one. The fix I finally used was to replace utilman.exe with cmd.exe in the recovery command prompt and boot normally, then clicked the ‘ease of access’ to have an administrator command prompt on a normal boot, which was able to set the user account to active again.
Alright so, we’re unlocked now and all is back to normal, right? As a forensics guy I really wanted to discover what caused the lockout. I opened up Event viewer and checked out the Security logs. What I observed next stunned me. In the 12 days before all this happened, I had over 14,000 failed attempts to logon via RDP. Further inspection showed that the failed attempts were often coupled with random account names that could only be part of a dictionary attack. I exported the list and wrote a C# script to itemize the names used, and put them in a pastebin here if anyone is interested. ADMINISTRATOR is the clear winner with over 9611 failed logins.
This led me on a ‘security improvement’ rabbit hole that included:
- Disabling port forwarding altogether on my router
- Running nmap on my machine and finding ports open somehow.
- Discovering that UPnP was enabled on my router and disabling it – really?
- Going through the ASUS Security Checklist and turning everything green, such as changing my ‘admin’ username to something else, disabling WPS, enabling HTTPS-only access to the router, updating router firmware to the latest version, etc.
While there’s no evidence at this point of successful access to my machine, I felt like this was an excellent wakeup call. As for remoting, I am going to disable RDP and instead use a third party remoting service — one which allows me to use 2FA and has ‘login attempt from X.X.X.X’ notification emails, etc.