Tuesday, August 7, 2018

Remote Desktop and the MSTSC Workstation

I had a fun adventure recently. It actually started towards the end of 2017. A client was having a couple of their Active Directory accounts locked out in the wee hours of the morning. I didn't work on this problem at first, as this was a client of my friend's business. Until very recently, I worked regular 9-5 jobs until I figured out that I'd rather be working for my friend instead. But that's another story.

Story Time

My friend had spent a number of hours troubleshooting this issue, but it was hard to nail down when it was going to happen. Impossible, really. Eventually he couldn't keep having the client locked out, so he ended up making new login IDs for the users that were being locked out, and went on about his life. And that was the end of that.

Until about a month ago when the problem came back with a vengeance. Now something like 4 or 5 accounts were being locked out, and now I worked for my friend. In his business I have, by far, the most experience with Active Directory. I'm no fully fledged AD administrator, but I know a few tricks.

The first thing to do was enable logging on the domain controller. Because of course there's only one. Once that was in place, we could actually see the name of the workstation that was causing the lockouts. MSTSC. Well, that's obviously a bum name. I was hoping to get an IP address.

I looked around the internet to see if I could find any references to other people having this problem, and to see if I could find a penetration testing script that would also spoof the workstation name. I did find a script that would attack RDP, but it doesn't (from what I can tell) spoof the machine name.

But more importantly, I happened upon a thread regarding this issue. Several people were talking about this issue, and the things that they all had in common were:
  • They all had RDP listening on the filthy, unwashed Internet
  • They all thought that RDP listening on the filthy, unwashed Internet was an acceptable form of remote access for a business
I had to check the date the original post was made. Sure enough, in the year of our lord, 2018, we can still find people putting RDP naked on the internet. I mean, this is a process that I think many techs go through, right? You discover how to forward a port, and suddenly you have access to your network via RDP. Oh hey, you can spin up a Linux box, and tunnel that RDP session! Oh wow! You can just install OpenVPN!

Big, Damn Rant

But never before have I encountered such hostility to the mere idea that putting RDP on the Internet was a bad idea. It basically boils down to, "Getting users to understand and use a VPN is haaaaard!" Waaaaah! There is someone out there on the Internet right now that has one or more valid login IDs to your network! How are you so calm in your defense of this objectively terrible practice!?!

And really, some unknown entity out on the Internet having a valid login ID to your network is kind of a big deal. First, they're only a password away from logging into your network. Second, locking out users from being able to use their computers is an attack on your network specifically! This is significantly different from someone who just happened across your IP address, and decided to stroll down a list of common login IDs. Take it seriously!

The way I see it is similar to crypto viruses and HIPAA compliance. If a document with patient health information is encrypted by a virus, you have to report that as a breach, because you lost control of the data. Doesn't matter if you're using ZFS (and you damn well should be) and you can rollback within seconds. You lost control of the data, report it.

I would argue the same should be true for accounts that you lose control of. Not when a user enters their passwords incorrectly too many times, or something like that. When an account is locked out, and it's by an entity outside of your company's control. That should be something that gets your hackles up every. Goddamned. Time.

Back to the Story

Well, I had ruled out RDP near immediately. A few years back, this company actually had been breached, and surprise surprise, it was because RDP was used as remote access. After that breach they moved to VPN for remote access. As with any assumption, it took me longer than it should have to question it.

This client actually has 2 offices, with a site-to-site VPN between them. When they converted away from naked RDP to VPN, they closed the RDP port forwarding at one office, but not the other. At the second office, a lone desktop sit listening for connections from the internet. That was the source of the attempts.

Back to the RDP Defenders

One of the people defending RDP on the Internet wanted to understand how an event with a clearly false hostname is generated. If you're also wondering, wonder no longer.

I can replicate such an event. I spin up a VM, and I give that VM the name MSTSC, I lock out an account, and I get an event log message stating that the workstation MSTSC has locked out an account. I'm not suggesting that there are hundreds or thousands of computers out there named MSTSC. I'm suggesting that you're being General Hux'd.

Most likely, there's some script out there for attacking RDP that became popular who knows how long ago. Part of that script's claim to fame is that it also spoofs the workstation name. And whoever wrote the script originally chose the name MSTSC as the default spoof.

Maybe they did it because they thought people would fixate on it, thinking that Windows was broken and just giving them the name of the application that locked the account. Or, since mstsc.exe is the name of the typical Windows remote desktop client, maybe they just had MSTSC on the brain when they wrote the script. Naming things is one of the two hard things in programming, after all.

What do I Want You to Take Away From This?

I want to put it out there that it is not acceptable to use RDP naked on the filthy, unwashed Internet. I don't care how small your company is. I don't care if you don't think there's anything to steal (you'd be wrong about this, btw).

Learn how OpenVPN works. It's actually not that hard. I feel like people are just wary of it because it involves security certificates. Really, it's not that scary, and the client for Windows is actually really nice. Better, I would say, than the most, if not all of the other VPN clients I've ever used.

If you are in a thread where you and lots of other administrators are talking about user accounts being locked out by outside actors with the exact same evidence, be open to the idea that you're all doing something very wrong.

No comments:

Post a Comment