Detecting RDP Brute Force with One Hand

One of the growing attacks we have seen has been Remote Desktop brute forcing, MITRE ATT&CK technique T1076(link, especially if you have laptops that connect directly to the internet when not at your office. We know what you are thinking…people still connect without a network firewall?...YES. There are internet providers like AT&T Uverse and Cox specifically that we have found this commonly with. We did some lab testing and found that within 60 minutes our machines on the internet were found and were seeing SSH brute force. RDP attacks started around the 90 minutes mark.



If you have endpoint logs, done! It is easy to search them for failed RDP attempts and gather the outside IP addresses where they are originating from. If you only have Domain Controller logs this can be more difficult, especially if you don’t have the more verbose NTLM logging enabled. We have found two specific searches that have worked really well in our environment.


Computer Strings

This search involves looking for specific words in the computer string, Windows7 or FreeRDP. We saw this a lot from an attack tool called Crowbar.

sourcetype="WinEventLog:Security" earliest="-12h" EventCode=4776 Keywords="Audit Failure" Source_Workstation="Windows7" OR Source_Workstation="FreeRDP" | table _time Source_Workstation Logon_Account


User Warning

This was a search that came from looking at attack behavior. We found many scripts attempting to scrape a cached username from the first screen they receive when attempting RDP. In most business settings there is a user acceptance prompt warning you this is a company computer and other legal disclaimers. The attack script accidently grabs these strings and tries to log in with them allowing you to spot a very specific anomaly.



sourcetype="WinEventLog:Security" Error_Code=0xc0000064 (Logon_Account="*users agree*" OR Logon_Account="*violation*") | timechart span=1h count by Logon_Account


If you use this search, look for something in specific in your warning prompt that will help you know.

These are super simple searches that will allow you to peer into another potential attack area even without endpoint logs. The screen capture is of an active brute force using our second search.



Now that we see a problem, how do we stop it? One solution we came up with was with our endpoint firewall. We have configured the firewall that if it ever detects a non-private IP assignment to shut down all network traffic. Once the non-private IP is removed the firewall automatically returns to the previous state.


Again simple, that's the theme. We need these approaches to continually secure and protect our resources that minimize maintenance time and effort by analysts. If you have questions or would like to implement these in your environment and stumble you can always reach out to us.