Definition
Detection of an unauthorized remote live terminal console session by examining network traffic to a network host.
How it works
An external attacker takes remote control of a host inside a company or organization's network and manually directs offensive techniques. Nonstandard terminal sessions and abnormal behaviors are analyzed in this technique. Abnormal behavior detection includes analysis of user input patterns in the real-time session, keyboard output and packet inspection.
Network Traffic Inspection
Network traffic from internal hosts is the main concern and focus for the traffic inspection. The network traffic is collected into inspection groups. The groups of traffic are assembled into distinct pair flows (outbound/inbound) and the pair flows are further divided into sessions. Only sessions originated inside of the network are considered for the inspection. Traffic inspection includes analysis to determine if a human is involved in the session exchanges. Time-based statistics are captured for each session being analyzed by the detection engine.
Algorithm Analysis Description
Analysis algorithms look for patterns in the network traffic captured from the session data. A detection engine groups the session traffic data, between the hosts, into rapid exchange instances. Analysis of rapid exchange traffic patterns can lead to the discovery of abnormal behavior which is indicative of a compromised internal host. The analysis algorithms look for patterns in the traffic which correlate to known activity (e.g., relay attacks, bot activity, bitcoin mining). Some metrics used during inspection include the following.
- Number of rapid-exchange instances
- Time interval between packets
- Fixed cadence of traffic
- Rhythm and direction of the initiation of instances
- Volume of data flowing from internal to external controlling host
- Data transfer characteristics
- Variability in length of silent periods
Considerations
- Full packet capture is required which can be process intensive to analyze
- Attackers that move low and slow may blend in with existing traffic resulting in false negatives
Implementation perspective
Remote Terminal Session Detection should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes Network Traffic.
Use the technique to identify suspicious, unauthorized, or abnormal activity through observable evidence and repeatable analysis.
Questions to ask
- Which events, states, or artifacts must be observed for the analysis to work?
- What analytic logic, threshold, comparison, or signature turns observations into a finding?
- How are expected false positives, blind spots, and environmental variations documented?
- Who receives the result, and what action is expected when the technique produces a finding?
Evidence and validation
- Telemetry and data-source configuration records
- Analytic logic, thresholds, signatures, and version history
- Test cases demonstrating expected positive and negative results
- Alert, triage, escalation, and tuning records
Common failure patterns
- Required telemetry is missing, delayed, or transformed in a way that invalidates the analysis.
- The technique produces alerts without an accountable triage and response process.
- Detection coverage is claimed from product deployment without testing the relevant analytic behavior.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
Show inferred artifact relationship paths (1)
Offensive-technique relationships
These relationships are generated from D3FEND graph paths and are explicitly experimental. They should be treated as hypotheses for defensive analysis—not as proof that the technique prevents, detects, or removes an offensive behavior.
ATT&CK Enterprise (72)
Showing the first 60 of 72 source-derived relationships. Open the official D3FEND technique for the current graph view.
ATT&CK for ICS (18)
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- Method and system for detecting external control of compromised hosts ↗VECTRA NETWORKS Inc · Nicolas BEAUCHESNE; Ryan James PRENGER · PatentReference
- CAR-2013-07-002: RDP Connection Detection ↗MITRE · MITRE · ExternalKnowledgeBase
- CAR-2016-04-005: Remote Desktop Logon ↗MITRE · MITRE · ExternalKnowledgeBase
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.