SSH Session Hijack Analytic

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 :

  1. 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).

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.

  • 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
attack pcap example — no embedded sessions seen \ port change \ extra handshake— since it’s the same socket

The Analytic Includes 4 Hypotheses:

  1. 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
  • 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
  • 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
suspicious_process table
  • Auditd rule: -w /usr/bin/ssh -p x -k T1219_Remote_Access_Tools_7
  • Monitoring the SSH binary execution.
audit_cmd_key table
  • 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

final output table part 1
final output table part 2
final output table part 3

Analytic Flow

Analytic flow (without additional data)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store