Logging in leaves something behind: an open session. Anyone who can take over that session inherits everything the user was already trusted to do. Remote Service Session Hijacking (T1563) is a Lateral Movement technique for Linux, macOS and Windows.
How attackers use it
MITRE explains that users log into services built for remote connections, such as telnet, SSH and RDP, with valid credentials. That establishes a session for continuous interaction. Adversaries may commandeer these sessions to act on remote systems and move laterally.
MITRE draws a line between this and Remote Services (T1021). Using Remote Services creates a new session with Valid Accounts. Session hijacking takes over one that already exists, so there may be no new logon event to find. The subtechniques are SSH Hijacking and RDP Hijacking.
How to detect it
MITRE's detection strategy compares what authentication logs say with what is actually happening in sessions.
- Windows. Mismatched user credentials against active session tokens, session takeovers with no matching successful logon, and RDP shadowing without user consent.
- Linux. Differences between authentication logs and active session tables, reuse of PTY sessions, or attaching to screen or tmux sessions, with commands issued without a login event.
- macOS. Hijacked VNC or SSH sessions, shown by process execution from sessions that have no new logon, manipulation of TTY sessions, and unusual network activity tied to dormant sessions.
The unifying signal is activity that has no corresponding authentication event.
How to reduce the risk
MITRE lists five mitigations.
- Network segmentation. Block unnecessary traffic between network zones with firewall rules.
- Disable or remove feature or program. Turn off remote services such as SSH or RDP where they are not needed.
- Password policies. Set and enforce strong password policies.
- User account management. Limit remote user permissions where remote access is necessary.
- Privileged account management. Do not allow remote access as a privileged account unless it is necessary.
The common thread across remote services
Whether the service is SSH, RDP, telnet or VNC, the same principle applies: a session is a bearer credential. Whoever can reach it can act as the user. The controls follow from that.
- Fewer sessions. Disable remote services you do not need, and shorten the life of the ones you do.
- Fewer reachable sessions. Segment the network so that a compromised host cannot reach every other host's remote services.
- Less privilege in the session. Keep privileged accounts out of ordinary remote sessions, so a hijacked session carries less power.
- A record of who is logged in. If you can list active and disconnected sessions and compare them to what you expect, a stray one stands out.
MITRE's mitigations for this technique map to exactly these four ideas.
Check your own environment
- Which systems accept SSH or RDP, and from where? Does that match what you intend?
- Which accounts can log in remotely with administrative rights?
- Do you review idle and disconnected sessions, and end them on a schedule?
Quick check
How does session hijacking differ from using Remote Services, according to MITRE?
Remote Services creates a new session using valid accounts. Session hijacking takes over an existing session, so there may be no new logon.
