Remote desktop is a common feature in operating systems. It allows a user to connect to a computer in another location and interact with the desktop remotely. Microsoft implemented this capability via its Remote Desktop Protocol (RDP) for Windows desktop and server operating systems. This is a powerful feature, but can be open to abuse by bad actors or malicious insiders.
Perhaps the most common question on users’ minds is who is connecting to the hosts via RDP and where are they coming from?
Enter the “TS Local Session Manager” Event log, which you can find in Event Viewer under Application and Services Logs/ Microsoft/Windows. There is an admin and an operational part of the log. Let’s explore the operational portion of the log and see how you can gain greater visibility into your RDP connection.
Examining TS Local Session Manager Event Log Data for RDP Connections
LogRhythm includes a built-in processing policy for the TS Local Session Manager Event log, which you can add as a new log source, and the data will normalize immediately.
This is where it gets interesting. We now have a very detailed view of each RDP connection that is made within the environment.
Based on this log, we can see the user login and the source IP address. However, the normalization and enrichment of collected logs also identifies the geographical location of the IP address from where the RDP connection occurred. In addition, it identifies the location of the server where the connection occurred, using the internal entity and network structure provided within LogRhythm. With this information, the LogRhythm NextGen SIEM Platform automatically infers the direction of the login. In this case, it’s external.
Once you’re armed with all the above, you can start to build out dashboards, searches, and analytics based on what you expect to see within your environment.
RDP from the internet may be prohibited by policy. In this case, an alert for any RDP session with a direction of “External” would be most relevant:
RDP from the internet may be allowed, but only within country. In this case an alert for any RDP Session with a direction of “External” where the country is not the U.K. would be useful:
To take another approach, if you have fully populated the entities and networks within LogRhythm, an alert could be created for workstations in an end-user subnet connecting to a domain controller via RDP.
Alternatively, you might just want to monitor activity over time, and a saved search would serve this purpose nicely. Here, you may be looking for external logins over a period of the last seven days.
You may wonder if collecting this log source is relevant when you are already collecting from your edge firewall, your Windows Security event logs, and maybe even from the Windows Filtering Platform. Our experience shows that there is at least some environmental dependency, and that the Windows Security event log may not always include the originating IP address. Also, your edge firewall will probably only record the fact that there was an RDP connection and not include the username. This log consistently records both the source IP and username, and is a low volume log source, so not likely to be impactful on your overall log volume.
The Risk of RDP and Threat Actors
Remote Desktop Protocol is one of the techniques in the MITRE ATT&CK framework under the Lateral Movement tactic and is associated with a range of threat actor groups. Threat actors commonly scan the internet address space looking for open RDP and Virtual Network Computing (VNC) ports.
While threat actors may try to use a brute-force attack using either default accounts, or credential stuffing, 2019 also saw the discovery of the so-called BlueKeep vulnerability that affected multiple versions of Windows operating systems. This allowed unauthenticated attackers to connect to the RDP endpoint and execute arbitrary code. Microsoft rated this vulnerability as critical, and Microsoft and government organizations charged with keeping people safe in cyberspace issued a raft of recommendations around RDP.
Some may take the “security by obscurity” view that publishing RDP on a non-standard port will help keep them safe, but experience shows that this is not the case. One test showed that it took as little as 48 hours for a redirected RDP port to start being actively attacked from a remote geography — this approach unfortunately remains ineffective.
Gain Visibility with Log Sources
Use of RDP may, of course, be legitimate in your environment. But, as always, visibility is key. Collecting these logs provides useful additional visibility into activity which may indicate suspicious or malicious behaviors.