Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1563.001: SSH Hijacking

Adversaries may hijack a legitimate user's SSH session to move laterally within an environment. Secure Shell (SSH) is a standard means of remote access on Linux and macOS systems. It allows a user to connect to another system via an encrypted tunnel, commonly authenticating through a password, certificate or the use of an asymmetric encryption key pair.

In order to move laterally from a compromised host, adversaries may take advantage of trust relationships established with other systems via public key authentication in active SSH sessions by hijacking an existing connection to another system. This may occur through compromising the SSH agent itself or by having access to the agent's socket. If an adversary is able to obtain root access, then hijacking SSH sessions is likely trivial.[1][2][3][4]

SSH Hijacking differs from use of SSH because it hijacks an existing SSH session rather than creating a new session using Valid Accounts.

EnterpriseT1563.001Sub-techniqueObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

SSH Hijacking matters because it can turn one compromised Linux or macOS host into a path for lateral movement without the adversary starting a clearly new SSH login. The business risk is that trusted administrative workflows, SSH agents, and active sessions may become the bridge into additional systems, especially where root access or overly broad trust relationships exist.

Executive priority

Leaders should treat this as a Unix/macOS lateral-movement readiness issue: do teams know where SSH agent use, privileged access, and SSH trust relationships exist, and can they produce audit evidence that access is least-privileged and monitored? Priority should go to systems where SSH is used for administration, operations, build/deployment workflows, or other continuity-critical access paths.

Technical view

For SOC, detection engineering, and IR teams, validate coverage around Linux and macOS SSH session activity, SSH agent/socket exposure, privileged account use, and unexpected lateral access that appears to originate from an already-compromised host. ATT&CK provides no official detection text for this sub-technique, but the relationship to DET0256 indicates a detection strategy exists. Distinguish this from ordinary SSH remote service use: the key concern is abuse of an existing session or agent trust rather than a fresh login with valid credentials.

Likely telemetry

  • Linux and macOS authentication and SSH/sshd logs
  • Process execution and parent-child process telemetry around SSH clients, shells, and privileged commands
  • File and directory permission state for SSH-related keys, agent sockets, and user runtime directories
  • Privileged account and root activity logs
  • Session correlation data showing source host, user, destination host, and timing of SSH activity

Detection direction

  • Confirm whether DET0256 or equivalent local logic is implemented and tested for SSH session hijacking scenarios.
  • Baseline expected SSH administrator paths and investigate lateral SSH activity that occurs after compromise indicators on a source host.
  • Tune for context: SSH is common in Linux/macOS administration, so detections should correlate session ownership, privilege changes, unusual destinations, and agent/socket access rather than alert on SSH alone.
  • Look for blind spots where encrypted SSH traffic is visible only as network metadata and where endpoint logging does not capture process/session relationships.
  • During IR, preserve host-level evidence from the suspected source system because the hijack may not appear as a normal new authentication event on the destination.

Mitigation priorities

  • Restrict file and directory permissions for SSH-related files, sockets, and sensitive user directories using least privilege.
  • Strengthen privileged account management, especially root and administrative access on Linux and macOS systems.
  • Review password policies where password-based SSH authentication remains in use, while recognizing this technique may also abuse public-key and agent-based trust.
  • Disable or remove unnecessary services, features, or software that expand remote access or privileged attack surface.
  • Inventory and reduce unnecessary SSH trust relationships across administration, automation, and operational workflows.
Analyst notes and limits

This object is a sub-technique of Remote Service Session Hijacking and is scoped to lateral movement on Linux and macOS. The revoked predecessor T1184 maps into this object. The MEDUSA software relationship indicates ATT&CK records at least one software entry using this behavior, but that should not be interpreted as local exposure or active exploitation without environment evidence.

MITRE did not provide official detection text in the supplied object, and the related detection strategy is named but not detailed here. Local logging depth, SSH architecture, privileged access design, and endpoint visibility will determine whether this behavior can be reliably investigated or detected.

Official MITRE ATT&CK definition

SSH Hijacking

Adversaries may hijack a legitimate user's SSH session to move laterally within an environment. Secure Shell (SSH) is a standard means of remote access on Linux and macOS systems. It allows a user to connect to another system via an encrypted tunnel, commonly authenticating through a password, certificate or the use of an asymmetric encryption key pair.

In order to move laterally from a compromised host, adversaries may take advantage of trust relationships established with other systems via public key authentication in active SSH sessions by hijacking an existing connection to another system. This may occur through compromising the SSH agent itself or by having access to the agent's socket. If an adversary is able to obtain root access, then hijacking SSH sessions is likely trivial.[1][2][3][4]

SSH Hijacking differs from use of SSH because it hijacks an existing SSH session rather than creating a new session using Valid Accounts.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1184 SSH Hijacking SSH Hijacking revoked by this object.
Enterprise T1563 Remote Service Session Hijacking This object subtechnique of Remote Service Session Hijacking.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S1220: MEDUSA

MEDUSA is an open-source rootkit that is capable of dynamic linker hijacking, command execution, and logging credentials.[1]

Linux
Relationship explorer

All related ATT&CK context

uses · Malware S1220: MEDUSA Enterprise revoked by · Technique T1184: SSH Hijacking Enterprise mitigates · Mitigation M1022: Restrict File and Directory Permissions Enterprise subtechnique of · Technique T1563: Remote Service Session Hijacking Enterprise mitigates · Mitigation M1042: Disable or Remove Feature or Program Enterprise mitigates · Mitigation M1027: Password Policies Enterprise detects · Detection Strategy DET0256: Detection Strategy for SSH Session Hijacking Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1022: Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions:

- Remove unnecessary write permissions on sensitive files and directories. - Use file ownership and groups to control access for specific roles.

Example (Windows): Right-click the shared folder → Properties → Security tab → Adjust permissions for NTFS ACLs.

Harden File Shares:

- Disable anonymous access to shared folders. - Enforce NTFS permissions for shared folders on Windows.

Example: Set permissions to restrict write access to critical files, such as system executables (e.g., `/bin` or `/sbin` on Linux). Use tools like `chown` and `chmod` to assign file ownership and limit access.

On Linux, apply: `chmod 750 /etc/sensitive.conf` `chown root:admin /etc/sensitive.conf`

File Integrity Monitoring (FIM):

- Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.

Audit File System Access:

- Enable auditing to track permission changes or unauthorized access attempts. - Use auditd (Linux) or Event Viewer (Windows) to log activities.

Restrict Startup Directories:

- Configure permissions to prevent unauthorized writes to directories like `C:\ProgramData\Microsoft\Windows\Start Menu`.

Example: Restrict write access to critical directories like `/etc/`, `/usr/local/`, and Windows directories such as `C:\Windows\System32`.

- On Windows, use icacls to modify permissions: `icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F` - On Linux, monitor permissions using tools like `lsattr` or `auditd`.

Mitigation Enterprise

M1042: Disable or Remove Feature or Program

Disable or remove unnecessary and potentially vulnerable software, features, or services to reduce the attack surface and prevent abuse by adversaries. This involves identifying software or features that are no longer needed or that could be exploited and ensuring they are either removed or properly disabled. This mitigation can be implemented through the following measures:

Remove Legacy Software:

- Use Case: Disable or remove older versions of software that no longer receive updates or security patches (e.g., legacy Java, Adobe Flash). - Implementation: A company removes Flash Player from all employee systems after it has reached its end-of-life date.

Disable Unused Features:

- Use Case: Turn off unnecessary operating system features like SMBv1, Telnet, or RDP if they are not required. - Implementation: Disable SMBv1 in a Windows environment to mitigate vulnerabilities like EternalBlue.

Control Applications Installed by Users:

- Use Case: Prevent users from installing unauthorized software via group policies or other management tools. - Implementation: Block user installations of unauthorized file-sharing applications (e.g., BitTorrent clients) in an enterprise environment.

Remove Unnecessary Services:

- Use Case: Identify and disable unnecessary default services running on endpoints, servers, or network devices. - Implementation: Disable unused administrative shares (e.g., C$, ADMIN$) on workstations.

Restrict Add-ons and Plugins:

- Use Case: Remove or disable browser plugins and add-ons that are not needed for business purposes. - Implementation: Disable Java and ActiveX plugins in web browsers to prevent drive-by attacks.

Mitigation Enterprise

M1027: Password Policies

Set and enforce secure password policies for accounts to reduce the likelihood of unauthorized access. Strong password policies include enforcing password complexity, requiring regular password changes, and preventing password reuse. This mitigation can be implemented through the following measures:

Windows Systems:

- Use Group Policy Management Console (GPMC) to configure: - Minimum password length (e.g., 12+ characters). - Password complexity requirements. - Password history (e.g., disallow last 24 passwords). - Account lockout duration and thresholds.

Linux Systems:

- Configure Pluggable Authentication Modules (PAM): - Use `pam_pwquality` to enforce complexity and length requirements. - Implement `pam_tally2` or `pam_faillock` for account lockouts. - Use `pwunconv` to disable password reuse.

Password Managers:

- Enforce usage of enterprise password managers (e.g., Bitwarden, 1Password, LastPass) to generate and store strong passwords.

Password Blacklisting:

- Use tools like Have I Been Pwned password checks or NIST-based blacklist solutions to prevent users from setting compromised passwords.

Regular Auditing:

- Periodically audit password policies and account configurations to ensure compliance using tools like LAPS (Local Admin Password Solution) and vulnerability scanners.

*Tools for Implementation*

Windows:

- Group Policy Management Console (GPMC): Enforce password policies. - Microsoft Local Administrator Password Solution (LAPS): Enforce random, unique admin passwords.

Linux/macOS:

- PAM Modules (pam_pwquality, pam_tally2, pam_faillock): Enforce password rules. - Lynis: Audit password policies and system configurations.

Cross-Platform:

- Password Managers (Bitwarden, 1Password, KeePass): Manage and enforce strong passwords. - Have I Been Pwned API: Prevent the use of breached passwords. - NIST SP 800-63B compliant tools: Enforce password guidelines and blacklisting.

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Change history

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 .

ATT&CK release
19.1
Object version
1.1
Created
Modified
Raw hash
819486deb516a5d8...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 819486deb516…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Slideshare Abusing SSH

    Duarte, H., Morrison, B. (2012). (Mis)trusting and (ab)using ssh. Retrieved January 8, 2018.

    Open source URL
  2. [2]
    SSHjack Blackhat

    Adam Boileau. (2005, August 5). Trust Transience: Post Intrusion SSH Hijacking. Retrieved December 19, 2017.

    Open source URL
  3. [3]
    Clockwork SSH Agent Hijacking

    Beuchler, B. (2012, September 28). SSH Agent Hijacking. Retrieved November 17, 2024.

    Open source URL
  4. [4]
    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
  5. [5]
    mitre-attack T1563.001
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use