Finding traces of RDP hijacking - Part1
Remote Desktop is one of the favorite access means for an attacker because it allow to discover the system as well as the neighboring hosts using only a mouse and a keyboard (less footprint, no special commands or utilities). Furthermore few companies can really differentiate between a legit and a suspicious RDP activity, especially if they rely on event log 4624/4625 [Logged on the destination host and not on the DCs, and so probably no logs are being collected from all workstations and servers --> no alert is generated].
Given the above facts, Hunting for suspicious RDP activity is extremely important and can help you detect eventual compromised credentials [Many companies have publicly accessible RDP servers that can be brute-forced if not properly protected].
In this post, we will try to cover the following techniques:
Remote Desktop is one of the favorite access means for an attacker because it allow to discover the system as well as the neighboring hosts using only a mouse and a keyboard (less footprint, no special commands or utilities). Furthermore few companies can really differentiate between a legit and a suspicious RDP activity, especially if they rely on event log 4624/4625 [Logged on the destination host and not on the DCs, and so probably no logs are being collected from all workstations and servers --> no alert is generated].
Given the above facts, Hunting for suspicious RDP activity is extremely important and can help you detect eventual compromised credentials [Many companies have publicly accessible RDP servers that can be brute-forced if not properly protected].
In this post, we will try to cover the following techniques:
- Changing the default RDP tcp-port to bypass both network access controls preventing inbound connection to port 3389 (if any) or/and detection based on Netflow data (where target port is 3389 AND SourceIP is not Authorized_RDP_Subnets).
- Changing the last logged-on displayed Account Name, to avoid that SysAdmins or Help Desk Operators notice previously logged on Account.
Below is summarized illustration of both techniques:
Detection Rule examples:
- CarbonBlack: regmod:LastLoggedOn* or regmod:dontdisplaylastusername* or regmod:RDP\-tcp\PortNumber*
- Sysmon: EventID=13 and EventMessage contains "LastLoggedOn" or "dontdisplaylastusername" or "RDP-tcp\PortNumber"
In future posts we will be covering other techniques and some ideas to detect them.
Note: detection based on Netflow data and authorized/legit RDP subnets is still relevant and it's the right thing to do if you want to baseline your RDP activity without having to collect logon events from many member servers and endpoints.
References:
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
https://gist.github.com/dbirks/ec4416c9064a323b14f435ee934efd71
https://winaero.com/blog/change-rdp-port-windows-10/
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
https://gist.github.com/dbirks/ec4416c9064a323b14f435ee934efd71
https://winaero.com/blog/change-rdp-port-windows-10/
No comments:
Post a Comment