Remote Desktop Protocol

Remote Desktop is the interactive remote session built into Windows: a full desktop on another machine, with a keyboard and a screen, over tcp/3389. It is the ordinary way administrators work on servers, which is exactly why it is useful to an attacker who has a working credential.

There is no exploit in this technique. If the service is listening and the account is allowed to log on remotely, RDP does what it was built to do. What the attacker gains is not access they did not have; it is a fully interactive session on a second machine, from which everything they do inherits that machine's identity and network position rather than their own.

RDP is the move an attacker makes once a stolen credential turns out to reach further than the machine it was stolen from. It is preferred over remote-execution techniques when the objective needs a human at the keyboard: browsing a file share by eye, reading somebody's mailbox, using an application that has no command-line equivalent, or simply working somewhere less watched.

Because it is administration tooling, it blends. There is nothing to install, nothing unusual on the wire, and the resulting session is the same kind of object a real administrator's session is. Attackers lean on that, and on the fact that an interactive session gives them the target host's own credentials and trust relationships to work with.

For a defender the compensating property is redundancy. An RDP session is a network event and a host event at once, so it is recorded independently by the destination, by any network sensor watching the segment, by the firewall it crossed and by a flow exporter. That is an unusually good position to be in when one of those sources cannot be trusted.

Data source: Windows Security event log on the destination host -- remote interactive logon (Event 4624, type 10) with its source address, plus network session and firewall or flow records on tcp/3389

{
  "host": {
    "name": "example-host"
  },
  "event": {
    "code": "4624",
    "action": "Logon"
  },
  "source": {
    "ip": "198.51.100.25"
  },
  "winlog": {
    "event_data": {
      "LogonType": "10",
      "TargetUserName": "j.doe",
      "LogonProcessName": "User32",
      "AuthenticationPackageName": "Negotiate"
    }
  }
}

Prebuilt Elastic rule: RDP Enabled via Registry

Elastic's prebuilt RDP coverage watches RDP being TURNED ON (a registry change, a firewall rule added), not RDP being USED. A session by an attacker who found the service already enabled is a manual hunt, so build it deliberately.

Start from the destination, not the source. List remote interactive logons by destination host and account, and look for servers that have no business accepting interactive sessions at all, and for account-and-host pairs with no history. Then pivot on the logon id to see what ran inside the session, which is where the technique stops being a login and starts being an intrusion.

Corroborate from something the destination does not control. The value of this technique to a defender is that an RDP session is written down three or four times by three or four different systems: the destination's own logon record, a network sensor's session record, the firewall that the traffic crossed, and a flow exporter. If the destination's own logging is unreliable for the window, the other three are still there and they are not the destination's to edit.

Mind the transport split. RDP can negotiate a UDP transport alongside the TCP connection. A protocol parser that only follows TCP will show you the session but never that leg; firewall and flow records carry both. If you are reconciling a session against a flow record and the byte counts do not agree, that is the usual reason.

RDP is how a great deal of legitimate administration happens, so the session itself is never the finding. Baseline it: which accounts administer which hosts, from which jump hosts, in which change windows. A named administrator reaching a server they own from the jump host, during a maintenance window, is the normal case and there will be a lot of it.

The shapes worth escalating are the ones that break a pair rather than the ones that look unusual in isolation: an account reaching a host it has never reached before, a session that crosses a network boundary the account's role does not require, a workstation-to-server session where administration normally flows through a jump host, or a session by an account whose own authentication immediately beforehand was itself anomalous.

One practical trap when you scope the search: widen the window and you will often find more than one session for the same account to the same host, including legitimate ones. The data alone will not tell you which is the incident. Anchor the window on independent evidence, not on the session list, and carry the session identifier rather than the account-and-host pair when you hand the finding on.

• MITRE ATT&CK: T1021.001 Remote Services: Remote Desktop Protocol
• Elastic Security: RDP Enabled via Registry

1 scenario in this catalog covers T1021.001. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →