Hacking RDP with a MitM Password Attack

The other day, my friend and co-worker clued me in on a new attack he found. It worked so well, we had to share it.
As it says on their GitHub page,

Seth is a tool written in Python and Bash to MitM RDP connections by attempting to downgrade the connection in order to extract clear text credentials. It was developed to raise awareness and educate about the importance of properly configured RDP connections in the context of pentests, workshops or talks. The author is Adrian Vollmer (SySS GmbH).

Take a look how simple it is to steal an RDP credential off the network without ever having to touch the victim’s machine. Things like certificates and network level access are important security controls you should implement to protect from attacks like this.

Preventing PTH with Two Small Checks.

I read up harmj0y’s blog over the weekend and he had some killer points I wanted to share with you all. More than anything, just some major takeaways from this.

KB2871997 – Microsoft’s attempt to block pass the hash. More than anything it just complicates it, but doesn’t resolve it. It does a lot of good things to help prevent, but doesn’t resolve the issue.   The patch created two new SIDS that can be used with group policy to block local admin accounts from remote login (with one large exception). Any authenticated user to AD can enumerate policies to see if this is enabled on a client’s network.  PTH for local accounts with the exception of the RID 500 (local built in administrator) account are blocked.

The whole point of the article is twofold:

  1. It’s not the group policy that’s actually blocking the PTH of local account(though the other stuff is good), but rather “token filtering”. This is applicable to all local admin accounts with the exception of the RID 500 (built in local admin) account is it runs in a non-filtered state. Meaning, you can still PTH with the built-in local admin account.
  2. The registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy (which doesn’t exist by default) set to 1 grants high-integrity sessions to all remote connections thus enabling PTH of all local accounts. MS actually suggests doing this in a number of times (which is really a bad idea):\

So…..

KB2871997 = Good
LocalAccountTokenFilterPolicy = Bad

 

Check for these things next time you’re dealing with a client.

Oh yeah, at the end, he states that unique creds render this whole point moot. He mentions LAPS, which is fine…but whatever…

What he doesn’t mention is that PTH is still a huge issue with DOMAIN accounts.

Yes, I do work for a Privileged Account Security Company, so I am biased here. As long as domain accounts are being managed in a responsible way, that’s all I care about. This is where pushing the functional model of privileged accounts really proves its value in preventing pass the hash attacks.  I’ll probably go into further depth on that topic in a later blog post.

Also, harmj0y is the MAN. Main creator and contributor for Powershell Empire, Veil-Framework, and Bloodhound. The guy is a legend and deserves much respect.

Thanks and have a great week.