Over a two-year period (January 2011 to January 2013) [Mandiant] confirmed 1,905 instances of APT1 actors logging into their attack infrastructure from 832 different IP addresses with Remote Desktop …In 1,849 of the 1,905 (97%) of the Remote Desktop sessions APT1 conducted under [Mandiant’s] observation, the APT1 operator’s keyboard layout setting was ‘Chinese (Simplified) — US Keyboard’. Microsoft’s Remote Desktop client configures this setting automatically based on the selected language on the client system. Therefore, the APT1 attackers likely have their Microsoft operating system configured to display Simplified Chinese fonts.This finding by Mandiant is unfortunately not unique – gaining unauthorized access to RDP-enabled machines has been and continues to be an effective attacker technique. It’s especially effective when the credentials used by the attackers are stolen without the user’s knowledge, so they can pretend to be a remote user without raising suspicion. So if attackers can use stolen credentials to remotely access machines’ desktops, how can defenders detect this kind of activity when it starts? One approach has been to monitor user account activity and alert when it deviates from a typical baseline pattern of innocent activity. While this can be effective, it has a very high false positive rate. False alarms will be thrown when a user decides to remotely access their machine late at night or on the weekend to complete a critical task, causing the security team to spin up and investigate innocent activity. An alternate approach that is rooted in ground truth network data analysis is to look for anomalies in the characteristics or metadata of the RDP session being conducted by the remote user. By observing the raw packet capture on a network, a network traffic monitoring and analysis system can identify the RDP service, parse out specific metadata, and detect the presence of network anomalies such as RDP traffic with non-English keyboard layouts. This approach does not rely on analysis of user behavior, but instead inspects the traffic itself for a specific attacker technique. How, then, do current solutions get access to this RDP metadata? Traditionally forensics-based solutions that perform full packet capture and full deep packet inspection (DPI) will identify, parse, and unravel all traffic on a network. They will extract the RDP metadata, but also extract a metric ton of other data. On small or simple networks this isn’t an issue due to the low volume of traffic – they can successfully boil the ocean because the ocean is small. On larger more complex enterprise networks, however, the approach starts to fall down due to the sheer volume and variety of the traffic. Applying full DPI and content extraction to all packet capture is computationally expensive and these forensics-focused solutions can get overwhelmed. There is, however, an alternative… A more measured approach on large networks is to perform full packet capture and selective packet inspection with an advanced network-traffic analytics solution so that analysts can review a smaller set of data in an interactive query-based fashion. This analytics-based approach differs from a forensics-based approach in that analysts can hunt and search through a smaller set of selected metadata fields to find behavioral anomalies like non-standard RDP keyboard layouts. This approach strikes the right balance between having no metadata to analyze at all and attempting to boil a very large ocean of data. When traffic with unexpected RDP keyboard layouts is discovered with an advanced solution, through manual hunting or automated scanning, analysts can see the full context around the session, what hosts were communicating, where the remote user is located, and, critically, the full packet capture behind the session. This session metadata and full packet capture can then be the basis for timeline reconstruction, attacker identification, and a complete forensic investigation. Like some of the other analytical searches in this series, false alarms are possible with this type of search. For example, for organizations that use the “follow-the-sun” approach to IT support, they may have administrators accessing corporate resources from all over the world. These combinations of network locations and keyboard layouts can be whitelisted, however, so that they can be ruled out as suspicious activity. That concludes how to derive intelligence out of observed RDP traffic! Stay tuned for more powerful searches that can reveal malicious behavior as we move through this entire advanced analytics series. Read the next post in this series: Relay Finder.
Visit the Series Intro to see a complete list of the analytics covered.