Follow

Suspicious Remote Desktop

Attack Behaviors Covered/Model Purpose

Suspicious Remote Desktop (SRD) is designed to identify attackers accessing your internal machines via Microsoft’s Remote Desktop Protocol (RDP) through compromised hosts and/or compromised credentials. The focus of this algorithm is on attacker behavior seen in several major breaches, most notably by APT 1 in the 2013 Mandiant Report[1]. The model alerts on the following discrepancies: 

  • Learned keyboard layouts/client token combinations from the client
  • Learned product IDs/client token combinations from the client
  • Learned keyboard layouts for the server
  • Learned keyboard layouts for the Network

This model provides internal-to-internal coverage only.

By using unsupervised, local learning to understand each individual environment, the detection model is able to alert on anomalous events only. As a consequence, the model acts similar to a security analyst given the sole responsibility of understanding remote execution use within your environment, auditing use of remote execution, and escalating an alert when something unusual is observed.

Why is this coverage important?

Once attackers have a foothold within an environment through a single compromised system, they will look to expand their access within the network using credentials stolen from the compromised system.

Their expansion within the environment will primarily rely on these compromised credentials. This method is preferred to exploitation of vulnerabilities as it is easier to appear like normal traffic and go for longer periods of time without being caught. Attackers can also choose to set up their own RDP stack to move laterally across the network.

Different keyboards are used throughout the world. This may be to accommodate different languages, such as French or Chinese or for different regions, such as US English vs UK English. Keyboards can have widely varying layouts and using one’s native keyboard makes working, or attacking, much easier. 

Different product IDs may indicate an attacker has changed or added their own RPD software to the client host. This may be done to mirror traffic back to the attacker, force unencrypted communication, reinfect a machine if the initial implant is removed, or allow for other behavior.

The detection model leveraged local machine learning to help reduce this noise from typical/benign activities, only alerting on activities which are anomalous to the environment. This saves your analyst team from the tedious task of auditing all remote execution activity within your environment manually.

 

Contents of the Detection Page

  

Red with Exclamation Mark: Anomaly from learned behavior
RDP Client Token: Treat as username
RDP Clientname: Name of the RDP client
Product ID: Client RDP Stack Identifier; License number
Keyboard Layout: Client’s keyboard layout. Language and Code provided when possible

  
How to Interpret Detection Details

The detection model alerts on unusual RDP session metadata as compared to the learned normal attributes associated with RDP servers and RDP tokens. Normal values are listed in blue while the anomalies will be highlighted via a red exclamation mark. These represent changes in known patterns.

A highlighted product ID may indicate a change in the RDP software normally used with the client token.

A highlighted Keyboard layout may indicate a change in language settings associated with the client token or is a keyboard layout unseen with the RDP server before. Keyboard layouts may also be observed which are unusual from a network wide perspective.

A common event that triggers this detection is the change from an encrypted keyboard to non-encrypted keyboard. Though this is often considered a benign event, it is important to remember that something is failing and causing a reversion to unencrypted communication. The client and server will negotiate encryption and will only communicate unencrypted if there is a failure in this negotiation. This is a potential sign of misconfiguration or intrusion. Likewise, a detection of a change from unencrypted to encrypted is a change that needs to be accounted for.

Context is important to consider when properly investigating these keyboard or product ID changes. Try to answer the following questions to help inform your investigation:

  • What is the role of the server?
  • What is the role of the client?
  • What is the role of the user?
  • Where is the user located and does the time of activity match with the work hours of the user? 

Understanding these pieces of information can help you identify malicious behavior, even on a heavily accessed server.

Benign Detection Scenarios

An employee has installed a new RDP client

An employee has changed their keyboard layout to their native language

Response Steps

For benign detections, it is safe to triage them in the system. It is recommended that this be done as a one-time triage.

Determine if user should be accessing the server.

Determine if the time of activity matches with the work hours of the user.

For keyboard changes between languages it is recommended to inquire if the user is fluent in the language. If the answer is no, consider the user credentials compromised and follow your internal procedures. Afterward the detection can be marked as fixed.

For product ID changes, work with the IT department to determine if there has been an update on the machine or new software installed. If the answer is no, consider the host compromised and follow your internal procedures. Afterward the detection can be marked as fixed.

Limited local admin access and strict software policies will help in limiting these events as well are ease the ability to verify updates.

[1] https://www.fireeye.com/content/dam/fireeye-www/services/pdfs/mandiant-apt1-report.pdf

Was this article helpful?
3 out of 3 found this helpful

Download PDF

Have more questions? Submit a request

0 Comments

Article is closed for comments.