D3-RTSD Remote Terminal Session Detection: What It Detects, Which ATT&CK Techniques It Counters and How to Verify It

Once attackers are inside, much of their work is done by hand over an interactive session, and the network pattern of a person typing into a remote console differs from the pattern of software talking to software. MITRE D3FEND names this countermeasure Remote Terminal Session Detection (D3-RTSD) and defines it as "Detection of an unauthorized remote live terminal console session by examining network traffic to a network host." It sits under the Detect tactic as a child of Network Traffic Analysis and analyses the Network Traffic artefact. This card explains the two detection approaches behind D3-RTSD, session timing analysis and remote access connection analytics, the ATT&CK techniques D3FEND relates to it, how to deploy and verify it and where it fails. It is written for detection engineers and SOC leads; the wider discipline is in the NDR Guide.

Key takeaways

• It looks for a human at the keyboard. D3FEND's description analyses rapid exchanges, packet timing, cadence and silent periods in a session to decide whether a person is manually directing a host, including the reverse case where an internal host's outbound session is used to control it from outside.
• Remote access protocol analytics are the practical start. MITRE's CAR analytics mapped to D3-RTSD detect RDP by network flows to TCP 3389 and by Windows logon events with logon type 10, compared against approved source hosts.
• The ATT&CK mapping is broad and inferred. Because D3-RTSD analyzes Network Traffic, D3FEND relates it to dozens of techniques that also touch network traffic; the direct fit is Remote Services such as Remote Desktop Protocol (T1021.001) and SSH (T1021.004).
• Allow lists make it work. Remote sessions are normal for administrators and support staff, so the analytic value comes from knowing which sources, accounts and tools are approved.
• Low and slow defeats it. D3FEND notes that full packet capture is processing intensive and that attackers who move slowly can blend into normal traffic.

D3-RTSD at a glance

How it works

Approach 1: timing analysis of session traffic

D3FEND's knowledge base article describes the method in the Vectra patent it cites. Traffic from internal hosts is grouped into flow pairs and sessions; only sessions originated from inside the network are inspected. The engine then groups packets into "rapid-exchange instances", bursts of back-and-forth traffic with little silence, and analyses their number, the intervals between them and which side starts each one. D3FEND's analysis of the patent states the key case: a session the internal host initiated, where the external host is controlling the internal host in the opposite direction. That is the shape of a reverse shell or a remote access tool calling home and then being driven by an operator. Human typing produces irregular gaps; automated beacons produce fixed cadence. The same pattern analysis can also flag relays, bot activity and cryptocurrency mining, according to D3FEND.

This approach is protocol agnostic and works on encrypted traffic, because it uses timing and size, not content. It is mostly found in network detection and response products and requires per-session packet metadata rather than summary flow records.

Approach 2: remote access protocol analytics

The two MITRE Cyber Analytics Repository (CAR) entries that list D3-RTSD take a simpler, protocol-specific route:

• CAR-2013-07-002 RDP Connection Detection: network flows to TCP 3389 grouped by source and destination address and port, outputting connection time, source, destination and username. CAR also lists packet capture, Windows logon events 4624, 4634, 4647 and 4778, network connections from mstsc.exe and rdpclip.exe execution on the target as further sources.
• CAR-2016-04-005 Remote Desktop Logon: Windows event 4624 with LogonType 10 and authentication package Negotiate, compared against the workstations approved to originate RDP. Microsoft documents logon type 10 as RemoteInteractive, a logon through Terminal Services or Remote Desktop, with the source address in IpAddress and the client name in WorkstationName.

Network sensors add context the host does not have. Zeek's rdp.log, for example, records the client cookie (usually a username, often truncated), client name, client build, keyboard layout, the security protocol chosen and the result of negotiation. Windows event 4778 records a reconnection to an existing RDP session, including Client Name and Client Address; Microsoft's guidance suggests checking that Client Address falls in internal ranges and that RDP-Tcp sessions do not appear for users or computers where RDP is disallowed.

Where identity fits

Remote sessions are opened by an account. Detections gain most of their precision from identity context: is this an administrator account that normally uses RDP from a jump host, a service account that should never log on interactively, or a vendor support account outside its window? Service accounts with logon type 10 are a strong signal on their own. Pair D3-RTSD with privileged access controls so approved sessions arrive from known jump hosts; see the Remote Desktop (RDP) Security Guide for hardening.

ATT&CK techniques D3FEND relates to D3-RTSD

Relationship type: inferred only. D3FEND derives every relation from the shared Network Traffic artefact (D3-RTSD analyzes Network Traffic) and labels them inferred and experimental (D3FEND 1.6.0, checked November 2026). Because so many techniques touch network traffic, the list is long; the table groups it by tactic and the last column gives our view, labelled as NHI Mgmt Group judgement, of how directly a remote terminal detection helps. Each ID was checked against ATT&CK v20.

D3FEND also lists Remote System Discovery (T1018), shown on its page without an ID. Network Service Discovery (T1046) and Network Share Discovery (T1135) often precede interactive access but were not in D3FEND's list when checked, so they are not mapped here. Remote Access Tools (T1219) is the closest ATT&CK technique for operator-driven reverse sessions; D3FEND did not list it either, and this pairing is our view. See MITRE ATT&CK T1219 Remote Access Tools, T1018 Remote System Discovery, MITRE ATT&CK T1205 Traffic Signaling and MITRE ATT&CK T1550 Use Alternate Authentication Material Guide.

Where it is implemented

Implementation steps

1. Define approved remote access. Record which jump hosts, subnets, accounts and tools may open RDP, SSH and remote support sessions, and to what. Without this list every rule is noisy.
2. Collect the logs. Enable Windows Security logging for event 4624 and the Audit Other Logon/Logoff Events subcategory for 4778; collect sensor logs for RDP and SSH and flow logs at egress.
3. Deploy the protocol rules first. Alert on RDP and SSH from non-approved sources, logon type 10 by service accounts, internal hosts initiating RDP or SSH outbound to the internet, and RDP on non-standard ports seen in sensor logs.
4. Add behavioural session analysis. Where an NDR or timing model is available, enable reverse-control detections for outbound sessions from servers, and run in alert-only mode for two to four weeks.
5. Tune with owners. Resolve each benign hit by adding the source to the approved list with an owner and review date, not by widening the rule.
6. Write the response. Confirm with the account owner, isolate the target host if the session is not recognised, and capture session and host evidence before termination.
7. Roll back safely. These are detection rules; disabling a noisy rule is the rollback, but keep the underlying logs so it can be re-run once fixed.

How to verify it works

• Approved and unapproved test sessions: monthly, open an RDP session from an approved jump host (expect no alert) and from a test workstation outside the list (expect an alert with source, target and account).
• Reverse session test: in an authorised exercise, have the red team establish an outbound interactive session from a test server and drive it by hand; confirm the behavioural detection fires.
• Log path check: confirm 4624 type 10 and 4778 events, sensor RDP logs and flow logs all arrive for a sample of hosts each week.
• Non-standard port test: run RDP or SSH on an unusual port in the lab and confirm protocol identification still labels it.

Limits, bypasses and failure patterns

• Legitimate tools used by attackers: commercial remote support tools over HTTPS look like normal web traffic to protocol rules. Only timing analysis or an allow list of tools catches them.
• Low and slow operators: D3FEND notes attackers who move slowly can blend in and produce false negatives.
• Processing cost: D3FEND notes full packet capture is required for its timing method and is processing intensive, so coverage is often limited to egress points, missing internal lateral sessions.
• Allow lists that only grow: sources added during an incident or a project are never removed, and the attacker eventually operates from one.
• Exposed remote services: detecting sessions does not replace closing internet-facing RDP. See Exposed RDP Compromise.
• Host logs alone: 4624 type 10 shows a remote interactive logon, but on its own it cannot tell an approved administrator from an attacker using stolen credentials from the same subnet; network context and identity context are both needed.

Framework mapping

Practitioner checklist

• Keep an approved list of remote access sources, accounts and tools with owners and review dates.
• Collect 4624 and 4778 events, sensor RDP and SSH logs and egress flow logs.
• Alert on RDP and SSH from non-approved sources and on interactive logons by service accounts.
• Alert on internal servers initiating interactive or remote control sessions to the internet.
• Use timing based session analysis where available to cover encrypted and non-standard channels.
• Run approved and unapproved test sessions every month and record results.
• Route administration through brokered jump hosts so anything else stands out.

Standards and references

• MITRE D3FEND: Remote Terminal Session Detection (D3-RTSD)
• MITRE CAR: CAR-2013-07-002 RDP Connection Detection
• MITRE CAR: CAR-2016-04-005 Remote Desktop Logon
• Microsoft Learn: Event 4624, an account was successfully logged on
• Microsoft Learn: Event 4778, a session was reconnected to a Window Station
• Zeek documentation: base/protocols/rdp/main.zeek (rdp.log)
• Google Patents: US9407647B2 Method and system for detecting external control of compromised hosts

Related NHI Mgmt Group resources: Remote Desktop (RDP) Security Guide · NDR Guide · Network Monitoring and Packet Capture Guide · MITRE ATT&CK T1219 Remote Access Tools · MITRE D3FEND Guide