T1563: Remote Service Session Hijacking
Adversaries may take control of preexisting sessions with remote services to move laterally in an environment. Users may use valid credentials to log into a service specifically designed to accept remote connections, such as telnet, SSH, and RDP. When a user logs into a service, a session will be established that will allow them to maintain a continuous interaction with that service.
Adversaries may commandeer these sessions to carry out actions on remote systems. Remote Service Session Hijacking differs from use of Remote Services because it hijacks an existing session rather than creating a new session using Valid Accounts.[1][2]
Analyst context for executives and security teams
Remote Service Session Hijacking matters because an intruder does not need to open a new remote login if they can take over a session that already exists. That makes lateral movement harder to reason about from simple “new login” evidence alone. For leaders, the risk is that legitimate remote access workflows such as SSH, telnet, or RDP can become a path for movement across Linux, macOS, and Windows environments if sessions and accounts are not tightly governed.
Executive priority
Prioritize this technique where remote administration is common, especially for privileged users and systems that support business-critical operations. The key management question is not only “who can log in remotely?” but also “who can take over, reuse, or abuse an established remote session?” Control investment should emphasize account lifecycle discipline, privileged account management, password policy, segmentation, and disabling unnecessary remote services or features. This also creates useful audit evidence around least privilege, remote access governance, and lateral-movement resistance.
Technical view
T1563 is an enterprise lateral-movement technique covering hijacking of existing remote service sessions rather than creating a new session through Remote Services or Valid Accounts. ATT&CK lists Linux, macOS, and Windows platforms, with related sub-techniques for SSH Hijacking on Linux/macOS and RDP Hijacking on Windows. Because the parent object has no official detection text, SOC and detection engineering teams should validate coverage through the related detection strategy DET0079 and by testing whether logs can distinguish expected session ownership and continuity from suspicious session takeover, reconnection, or privileged use within existing sessions.
Likely telemetry
- Remote access session logs for SSH, RDP/RDS, telnet, and other approved remote services
- Authentication and account activity logs showing user, host, source, destination, and session timing
- Privileged account usage logs, especially administrative or root/SYSTEM-equivalent activity
- Endpoint logs from Linux, macOS, and Windows systems involved in remote administration
- Network flow or segmentation enforcement logs showing lateral remote-service connections
Detection direction
- Validate whether DET0079 or local analytics cover both SSH Hijacking and RDP Hijacking scenarios rather than only alerting on new remote logons.
- Look for inconsistencies between session ownership, source host, destination host, user context, and subsequent actions performed through the session.
- Tune detections around privileged or cross-segment remote sessions, since these are more material to lateral movement than routine helpdesk or administrator activity.
- Account for false positives from legitimate remote administration, support handoffs, reconnects, and shared operational workflows; require environment-specific baselines.
- Do not rely solely on successful authentication events, because this technique concerns abuse of a preexisting session rather than creation of a new one.
Mitigation priorities
- Start with User Account Management: enforce account lifecycle controls and least privilege so fewer accounts can maintain useful remote sessions.
- Apply Privileged Account Management to restrict and monitor administrative, root, SYSTEM, or similarly powerful accounts used over remote services.
- Enforce strong Password Policies as part of reducing unauthorized access risk around accounts that can establish remote sessions.
- Use Network Segmentation to limit where remote service sessions can reach, reducing the business impact of any hijacked session.
- Disable or remove unnecessary remote access features, services, or legacy programs to reduce the number of sessions that can be abused.
Analyst notes and limits
The most important defensive distinction is that hijacking an established session can evade programs focused only on credential use or new remote logins. Glexia would treat this as a validation item for managed detection, incident response readiness, identity governance, and segmentation reviews: confirm which remote services are permitted, which users can create or maintain sessions, and whether responders can reconstruct session ownership during an investigation.
The supplied ATT&CK object does not provide official detection guidance and does not include procedure examples beyond external references. Coverage decisions require local evidence about enabled remote services, session logging depth, privileged account practices, and network segmentation. No active exploitation, attribution, or guaranteed detection is inferred from the supplied fields.
Remote Service Session Hijacking
Adversaries may take control of preexisting sessions with remote services to move laterally in an environment. Users may use valid credentials to log into a service specifically designed to accept remote connections, such as telnet, SSH, and RDP. When a user logs into a service, a session will be established that will allow them to maintain a continuous interaction with that service.
Adversaries may commandeer these sessions to carry out actions on remote systems. Remote Service Session Hijacking differs from use of Remote Services because it hijacks an existing session rather than creating a new session using Valid Accounts.[1][2]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1563.002 | RDP Hijacking Sub-technique | RDP Hijacking subtechnique of this object. |
| Enterprise | T1563.001 | SSH Hijacking Sub-technique | SSH Hijacking subtechnique of this object. |
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 4004159996ea… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
RDP Hijacking Medium
Beaumont, K. (2017, March 19). RDP hijacking — how to hijack RDS and RemoteApp sessions transparently to move through an organisation. Retrieved December 11, 2017.
Open source URL -
[2]
Breach Post-mortem SSH Hijack
Hodgson, M. (2019, May 8). Post-mortem and remediations for Apr 11 security incident. Retrieved November 17, 2024.
Open source URL -
[3]
mitre-attack T1563Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.