Mark Minasi's Tech Forum
Register Calendar Latest Topics Chat
 
 
 


Reply
  Author   Comment  
bhendin

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 15
Reply with quote  #1 
Hello Minasi-ans:

So I occasionally am in transition on my home network between how my remote access is configured.  During these times I will enable RDP through my firewall (*gasp*).  I know from a security perspective this isn't a great idea - at the very least I use an uncommon NAT port, enable auditing, and ensure all my passwords are complex.

Twice over the past 6 or so months I have been attacked from an outside IP.  The account that I use to login to the server with RDP set up on it (let's call it SERVER-A) gets locked out.  If I unlock the account from the DC it is locked out again instantaneously.

This pattern continues until I either close the RDP port from the outside, or block the offending external IP.  At which point I can unlock the account and it is usable again.

While the best solution here is not to expose RDP directly, I am trying to determine how an outside attacker is able to figure out the name of a valid account on my system.  The account name is relatively uncommon (it's not 'rjones', more like 'service-account').  I find it unlikely that this username is an a brute force dictionary small enough that someone randomly targeting systems would use.

On top of that, windows (at least via RDP) doesn't seem to differentiate if you give it a bad username/bad password or a good username/bad password - it always will just say bad credentials.

I'm very interested in any known vulnerabilities or attacks that would allow an outside attacker to determine usernames *solely over RDP*.

At this point in time the only way I can figure they determine a valid username is:
1) They brute force every account multiple times trying to get a lockout message.  The fact that they get a lockout message means the account is valid.

2) (less likely) They implement some sort of timing attack to determine response time on valid vs. invalid account names.

I'm curious if anyone knows of another way - or other exploits I am not considering in a scenario like this.  I know there are ways to enumerate accounts over RPC connections etc...but none of that is exposed over the internet.

I am not looking for someone to tell me "just don't use RDP" - I already know it isn't a good way to set things up [smile] I'm asking more for general knowledge about security attacks like these.

Thanks
0
cj_berlin

Avatar / Picture

Senior Member
Registered:
Posts: 199
Reply with quote  #2 
Hi,

if everything you're exposing to the Internet is RDP there's not much more than brute force, at least to my knowledge. Now how do you secure that?

First, there is security by obscurity. Do not open port 3389 but map, say, port 18327 on the outside to port 3389 on the inside. Automated RDP brute force attacks are very likely to overlook you.

Second, there is RDS Gateway which is specifically designed for preauthentication.

Third, there is good old VPN :-) Don't use AD for VPN authentication if you don't like exposing it to the outside. Use certificates instead, or even a shared secret.

As to lockout messages being used to discern valid accounts from invalid ones, don't use lockout. Security people, at least some of them, have been preaching this for literally decades.

__________________
Evgenij Smirnov

My personal blog (German): http://www.it-pro-berlin.de/
My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/
0
donoli

Senior Member
Registered:
Posts: 497
Reply with quote  #3 
Quote:
I am trying to determine how an outside attacker is able to figure out the name of a valid account on my system.


It's called "username enumeration".  There are various programs that sometimes work.  The next question would be, Is the attacker targeting you because he knows you or did he scan for RDP either through a range of IPs or by use of a site such as shodan.io ?

Go to that site & search for RDP.  Who knows, your IP may appear?  CJ gave you some good advice especially using a high port #.  However, if the attacker is targeting YOU specifically, he may look for another opened port.

Is the source IP address of the attack the same every time?  Have you done a whois on it or scanned them for opened ports?  Post it here[smile] You can always send a cease & desist email to the owner or host of the IP.  That can't hurt.
0
bhendin

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 15
Reply with quote  #4 
Yes, the term "username enumeration" is the process of enumerating usernames... I understand that [smile].

However, I am unaware of any such methods which can be done strictly over the RDP port being exposed.  If you know of an enumeration attack other than brute force over RDP, this is what I am asking about.

I am using a high port - that's my first line of defense, but obviously someone is running scans on higher ports looking for clients.

I had about 17 IPs attempting RDP negotiation in the 30 seconds or so I took my capture.  It is obviously some sort of botnet just automating attacks based on what it finds.

VPN or SSH tunneling with keys is my preferred option, but as stated my infrastructure sometimes changes and using RDP is sometimes a quick fix for short intervals.

I think the brute force for account lockout messages is probably what is happening - I agree that disabling lockout may be safer in this respect.  I wish windows took the same approach that OpenSSH did and not provide details of why credentials fail...it would be safer this way.
0
donoli

Senior Member
Registered:
Posts: 497
Reply with quote  #5 
Quote:
However, I am unaware of any such methods which can be done strictly over the RDP port being exposed.  If you know of an enumeration attack other than brute force over RDP, this is what I am asking about.


AFAIK, the enumeration is not done on one port. It's a null session.  After the attacker has whatever usernames are found, then those names would be tried on opened ports.  Only the password is brute forced not the user name.

If you see 17 IPs, it's definitely a botnet.  As CJ said, disabling the lockout or using a VPN might help. 

0
bhendin

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 15
Reply with quote  #6 
Quote:
Originally Posted by donoli


AFAIK, the enumeration is not done on one port. It's a null session.  After the attacker has whatever usernames are found, then those names would be tried on opened ports.  Only the password is brute forced not the user name.

If you see 17 IPs, it's definitely a botnet.  As CJ said, disabling the lockout or using a VPN might help. 



Either:

1) There is some way that an attacker is enumerating usernames with only port 3389 forwarded to the server.

It sounds like we are all in agreement that this can't be happening (as in none of us is aware of a method to do this over port 3389)?

2) They are brute forcing the *username* until they find one.  As I mentioned above I believe they could be doing this either by:
- Logging in multiple times with a dictionary of names until an account lockout message is received.
- Logging in with a dictionary of names using a timing attack to determine possible valid names based on response time.

All of the above I have a handle on and understand the ways to mitigate (VPN, etc).

My major concern is that there may be someway I am not aware that the user enumeration may be happening over 3389.  It sounds like the answer is no, so unless someone says otherwise, I will assume my theories above are correct.

thanks.
0
Karl Fasick

Avatar / Picture

Still Checking the Forum Out
Registered:
Posts: 1
Reply with quote  #7 
Quote:
Originally Posted by bhendin
Hello Minasi-ans:
...I am trying to determine how an outside attacker is able to figure out the name of a valid account on my system.  The account name is relatively uncommon (it's not 'rjones', more like 'service-account').


bhendin, Your host might not require Network Level Authentication (NLA).

This blog has a concise write up and a screenshot showing what it looks like, plus instructions on how to get the newer mstsc client to show the login screen using this setting in the .rdp file via a text editor:

enablecredsspsupport:i:0

Coincidently that same setting was (might still be) the only workaround for authenticating to a Windows 10 client using an AzureAD account.

Hope it helps!

-Karl Fasick

0
bhendin

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 15
Reply with quote  #8 
Thanks Karl - I think you forgot the blog link though [smile]

In any case - I'm aware of NLA and yes the client is configured to support it.
I even tested by setting the "enablecredsspsupport:i:0" and was denied login with the NLA message.
0
donoli

Senior Member
Registered:
Posts: 497
Reply with quote  #9 
Quote:
1) There is some way that an attacker is enumerating usernames with only port 3389 forwarded to the server.


Your first guess was correct  It's right there in nmap.  I suppose you can look at the source code to see exactly how it works or you can run it against your network.

nmap -p 3389 --script rdp-enum-encryption <ip>
0
bhendin

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 15
Reply with quote  #10 

Quote:
Originally Posted by donoli

Your first guess was correct It's right there in nmap. I suppose you can look at the source code to see exactly how it works or you can run it against your network.

nmap -p 3389 --script rdp-enum-encryption <ip>

Have you ever performed this operation? This is not what that nmap script does.

https://nmap.org/nsedoc/scripts/rdp-enum-encryption.html

Quote:

Script Output:

PORT STATE SERVICE
3389/tcp open ms-wbt-server
| rdp-enum-encryption:
| Security layer
| CredSSP: SUCCESS
| Native RDP: SUCCESS
| SSL: SUCCESS
| RDP Encryption level: High
| 128-bit RC4: SUCCESS
|_ FIPS 140-1: SUCCESS

This enumerates encryption methods (just like the script is named), not users.

0
donoli

Senior Member
Registered:
Posts: 497
Reply with quote  #11 
You are correct.  That doesn't enumerate users, my mistake.  So far, I can't find anything else that enumerates usernames over the RDP port.  I don't understand why you think that the enumeration can't be a general enumeration.
A general enumeration is more common.  One of them is explained on the site below.

https://nmap.org/nsedoc/scripts/smb-enum-users.html

0
bhendin

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 15
Reply with quote  #12 
Quote:
Originally Posted by donoli
You are correct.  That doesn't enumerate users, my mistake.  So far, I can't find anything else that enumerates usernames over the RDP port.  I don't understand why you think that the enumeration can't be a general enumeration.
A general enumeration is more common.  One of them is explained on the site below.

https://nmap.org/nsedoc/scripts/smb-enum-users.html



Because all those enumerations require additional ports to be available (MS-RPC).  You can't perform those types of enumeration over 3389 (RDP).
0
jadgate

Avatar / Picture

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 27
Reply with quote  #13 
Coming late to this party..

Setting aside all the issues around usernames enumeration and everything else that have been discussed already.    RDP, or Terminal Services uses TLS version 1.0 for securing authentication sessions.  This version of TLS is no longer considered secure, primarily because it can be manipulated to set sessions to earlier versions SSL which is no longer secure and should not be used for secured authentication sessions.  Vulnerabilities in  earlier version of TLS  has been exploited with downgrade attacks several times over the last 3 - 4 years.   AFAIK, Microsoft has no plans to update the version of TLS used in RDP; I am not enough in the loop on the latest and greatest OS versions, but using a current VPN or other secured session methods mentioned above would help secure sessions.  As an example, use of RDP for server admin without some other way to secure sessions in environments where credit card data is stored or processed would be a big no no because it would not be PCI compliant.

Jim

__________________
Jim Adgate
IT Security guy concerned about vendor IT security risk management and other such stuff.....
0
wobble_wobble

Avatar / Picture

Associate Troublemaker Apprentice
Registered:
Posts: 781
Reply with quote  #14 
They use tools like RDP Brute that ustilise port scanners and then dictionary attacks.
Fast RDP Brute - https://www.rekings.com/fast-rdp-brute-gui-v2-0/

Latest version of ransomware, HakunaMatata seems to be getting into systems that way.
And thats nasty. Its carrying some old school BIOS management software and using cached creds to access server hardware management.

As Evgenij mentioned, VPN or RDS Broker

__________________
Have you tried turning it off and walking away? The next person can fix it!

New to the forum? Read this
0
bhendin

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 15
Reply with quote  #15 
Quote:
Originally Posted by wobble_wobble
They use tools like RDP Brute that ustilise port scanners and then dictionary attacks.
Fast RDP Brute - https://www.rekings.com/fast-rdp-brute-gui-v2-0/

Latest version of ransomware, HakunaMatata seems to be getting into systems that way.
And thats nasty. Its carrying some old school BIOS management software and using cached creds to access server hardware management.

As Evgenij mentioned, VPN or RDS Broker


Thanks for that - good to know there is a specific tool so easy to get one's hands on.  Though I suspect they are using a slightly more sophisticated software since it obviously a distributed attack.

I just dealt with my first ransomware on my step-father's secondary PC - Osiris is what it was called.  He opened a fake USPS attachment that was a double archive with a disguised .doc file that was really a shortcut to run a powershell script to download and execute something from online.  I scanned it with several AV products and not a single one caught it until it was too late.

Luckily he didn't have too much on this system other than a program that used .mdb databases (which got encrypted), so he lost about a days worth of work as he lost the database since his last backup.  Interestingly enough it only got the 2016 program that was installed at the root of the drive and didn't progress down the \Program Files (xxx) trees.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation: