Help detecting and blocking repeated RDP failed logins

[ejensenscs]

I'm wondering if anyone has found a way to detect (and then effectivly block) repeated failed RDP login attempts.  I assume it's difficult because these are legitimate connection attempts that we don't want to block normally.  We run many terminal servers, and (correlating with a new RDP based virus recently announced) we've seen many failed connection attmepts via RDP over the last few months. 

I found a similar question that didn't have a clear answer.  Does anyone know how to setup a flood detection for repeated RDP connections? 

https://supportforums.cisco.com/message/3365703#3365703

I'd like to figure out how to block repeated attempts, but not block all attempts, I need the blocking mechanism to keep other source IPs unblocked.

Erick

[BEHowardGRDA]

As long as you have implemented a strong password policy and the related items such as max attempts, etc on the Windows side you should be ok.  We just added a rule on our SIEM to notify us on any RDP hosts that have repeated failed attempts.  Just my two cents, hope it helps some.

[ejensenscs]

Based on the usernames that are getting brute forced, I suspect logging in is not the end goal.  They use names like 123, 1234, Steve, David, etc.  The usernames vary with each attempt, so it hardly seems like a brute force, unless somebody has a pretty poor concept of a brute force attack.  There was a virus recently that starting using things like that as the password for the Administrator account, but not as the user name.  Rarely are the logins looking for the admnistrator account.  I'm wondering if the goal is to overload the server with TCP sessions and get some sort of buffer overflow, maybe some zero day that isn't public yet.

So we do have strong passwords, and there's been no known breach yet, but I'd like to do away with the attempts if possible.

[praprama · Accepted solution]

You can try an aotmic IP engine signature that matches on port 3389. You can set the event count key to attacker and victim address pair and event count to a suitable number (say 5) and event count interval to a suitable interval (say 30 seconds).

You can also match on additional details (like a RST flag as well in theTCP header which ideally should follow a failed login attempt). If you do this, you will want to sepcify the source port as TCP 3389 and also enable swap attacker-victim addresses so that destination IP address is detected as the attacker.

You can then set the action to "deny attacker victim pair inline" and any traffic between these 2 guys will be blocked for a period of time (default is 30 miniutes if i remember correct).

Effectively, the signature will try to match 5 TCP packets in 30 seconds with a source port of 3389 and between the same set of IP addresses. If that condition matches, it will stop all traffic between these 2 hosts for a defined period of time.

Again, the numbers i mentioned above may not suit your requirement. You might have to run wireshark and see the pattern and match accordingly.

Hope this helps!

Regards,

Prapanch

[ejensenscs]

I think I have this working the way I want.  Thanks for all the help! 

I'm going to summarize what I did for anyone looking to do this:

I made an atomic IP type of alert, and I'm looking to match the destination port of 3389 with the RST flag in the TCP Flag and TCP Mask, 2 spots.  Later under the Event Counter, I'm using the event count of 5 and Alert Interval of 30 (seconds).  I figure nobody will be manually logging in wrong, 5 times within 30 seconds.  Our default lockout is after 6 failed attempts (on valid AD accounts).  I'm also using "attacker and victim addresses and ports" for the summary key.   My results have been pretty valid, I don't think I'm getting any false positives.  I do however get a false positive when I do a host scan from NMAP.  I assume because NMAP is trying to pull the banner off that service and kicks off a failed login, not sure there, still needs tweaks.  My desired action will be to Deny Attacker Inline because the attacker will be trying other servers during this time, I'd rather block out the attacker from everything not just the server and/or the service.

If I have any other revelations, I'll add it to this thread.

Thanks everybody,

Erick

[albertmimo]

Erick I have tried this but no success.

Did this work for you?

Have a terminal server that is constantly hammered on by hackers with brute force rdp logins - have an example of how sig should look?

Thx