SSH Session Hijack Analytic

6 min readApr 28, 2021

While researching Linux lateral movement techniques we encountered the subject of SSH session hijacking .

SSH session hijacking is a technique used by adversaries that may lead to lateral movement and privilege escalation.

Let's start with understanding the technique :

“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” — Mitre Attack

Why would the attacker use this technique?

SSH is the most common protocol of current to communicate with Linux computers, hence if an attacker learns to exploit this technique to their advantage, they can use it in attacks against plenty of corporate networks.
Communication between two different Linux computers is less suspicious due to the fact the SSH tunneling (which works like SSH hijacking) is legitimate in the activity landscape in different companies.
This method cancels the need for a new SSH session, making the attack more difficult to detect.
In comparison with other operation systems, Linux computers do not have a wide range of SSH clients (so there is no need for different implementations per client ).
Linux endpoints and system are often less secured than their Windows equivalents, making them an easier target.
Linux systems are commonly used as servers so they may contain valuable data that the attacker could potentially take interest in.

Common Implementation Includes :

Changing the SSH configuration file to enable Control Master which allows multiplexed connections.

I recommend research on other SSH configurations that can be used in a malicious way (you can see more over here).

2. The attacker can manipulate the SSH client to save the socket file of all SSH connections accruing in the system.

3. Utilizing the socket file, the attacker can connect without acquiring any credentials, as long as the valid account is still connected to the target machine.

For full attack flows, review these excellent blogs:

This analytic example focuses on SSH sockets malicious usage.

You are welcome to add detection for the implementation based on SSH key theft from memory in your detection mechanism.

Research Environment :

In addition to detecting this specific technique, it is important to shed light regarding Linux analytics, by sharing knowledge and tools within the community. This research includes information regarding the use of Auditd sensor , analytic creation methodology and infrastructure for testing.

Auditd is one of the most common sensors for Linux monitoring due to Auditd being the native monitoring system within few Linux distributions.

For those unfamiliar with Auditd, I recommend reading this RedHat documentation for better understanding of the output and the system object monitored by the sensor.

A few words about difficulties in creating analytics for Linux computers:

There is a lack of documentation regarding which events will trigger which Auditd event types
There is no standardization regarding Auditid rules- different clients may have the same rules with different identifiers (rule keys).
Raw data need preprocess of combining each event type of the same occurrence

I will use these rules in order to simplify the example.

Please keep in mind that these rules are very generalized and are not necessarily recommended for monitoring big scale data.

For my research, I used The Helk project,

Auditd is used as a sensor and Auditbeat is utilized for shipping and session induction of varying Auditd logs.

Many of you may ask — why don’t I use network communication logs?

This was my first thought as well , but SSH traffic is fully encrypted. After implementing an SSH session hijacking attack and analyzing the recorded traffic using WireShark and Moloch, I came to the conclusion that the attack cannot be detected through network logs without fingerprinting SSH keys in advance (and profiling them) .

attack pcap example — no embedded sessions seen \ port change \ extra handshake— since it’s the same socket

Due to the complexity of the attack and lack of visibility, an analytic is required, since a simple threat hunting query is just insufficient in this case.

The Analytic Includes 4 Hypotheses:

Finding SSH sockets established by different Linux endpoints and servers in the network. This hypothesis will attempt to find all SSH socket creations of the target machine from the hop machine.

Auditd rule : -a always,exit -F arch=b64 -S socket -F a0=2 -k T1011_Exfiltration_Over_Other_Network_Medium_4

read_audit_exfil2_proc table from the code

2. SSH configuration changes:

SSH configuration change will occur in the hop machine.
Note: this stage is not always a part of an SSH session hijacking attack flow.
Auditd rule : -w /etc/ssh/sshd_config -k ssh_conf_modification
Search for SSH configuration changes over 12-hour windows.

ssh_conf_change table

3. Finding multiple connections simultaneously:

By looking at PAM (pluggable authentication module) logs, one can search unordinary login session sequence.
The hypothesis will compartmentalize logging process’ to a max of two hours.

the selected conditions distribution between benign data and malicious data

4. Finding SSH process’ command lines that indicate of authentication done by key or socket file.

Auditd rule: -w /usr/bin/ssh -p x -k T1219_Remote_Access_Tools_7
Monitoring the SSH binary execution.

5. Additional data :

To integrate the involved computer’s IP and port, I added Audit logs: “auditd_message_type” = “crypto_session”
The crypto session provides network activity of cryptographic communication information.

Final Output Example :

An attack flow without configuration modification

*Photos are divided into parts due to large amount of information

Analytic Flow

Additional explanations provided within the comments in the code.

This is a POC. It will need modification and adjustments to your environment for FP reduction. Please modify your time delta to the log shipping delays and irregularities that may occur within your specific environment.

Link to SSH-Hijack Analytic notebook

Hope you enjoyed the blog 🥰

Thanks to Harel Elkayam and Or Navri for reviewing this post, code and providing useful suggestions.