T1021.004
SSH
What it is
SSH is the standard, trusted way administrators manage Linux and Unix systems remotely, which is exactly why it's such a useful tool for an attacker who's already gained a foothold. Rather than deploying new malware that might get flagged, an attacker with valid credentials or a working key can simply SSH from one compromised host to the next, using the exact same mechanism a legitimate administrator would.
This is a lateral movement technique: it's not about getting in initially, it's about spreading out once inside, turning one compromised machine into access to several.
How adversaries use it
Once an attacker has credentials or an SSH key valid on other systems, whether stolen from the first compromised host, guessed, or reused from a weak password policy, they connect outward to additional machines the same way any administrator would. Because the traffic looks like ordinary remote administration, it often blends into a large amount of completely legitimate SSH activity on any network of real size.
The real tell is rarely the connection itself, since SSH traffic between internal hosts is routine. It's the pattern: which hosts are connecting to which, whether that pairing has ever happened before, and whether it lines up with a host that was already known to be compromised.
Detect it in Elastic
Data source: Linux auditd authentication and session-start records from the SSH daemon, plus network-sensor SSH records; a session id links the login to later commands
Key fields
Network connection logs carry the actual session: source.ip and destination.ip for which hosts talked to each other, destination.port (22 by default, though not always), and network.transport. On the host itself, process and authentication logs (auditd, or Windows Security/Sysmon equivalents for cross-platform environments) show the actual login and the session it opened. Neither signal alone tells the whole story, an SSH connection between two hosts that have never talked before is a much stronger signal than the connection itself.
Example event
{
"event": {
"type": "connection",
"category": "network"
},
"source": {
"ip": "10.10.30.104"
},
"network": {
"transport": "tcp"
},
"destination": {
"ip": "10.10.30.112",
"port": 22
}
}Prebuilt Elastic rule: Potential Network Scan Detected (related discovery activity often precedes this technique)
Hunt guidance
Hunt this as a graph problem, not a single event: build a picture of which hosts normally connect to which over SSH, then look for a new edge, a pairing that's never happened before, especially from a host already suspected of compromise. A single new SSH connection from an unusual source is a much stronger signal than trying to judge any one connection as inherently suspicious.
Correlating with authentication logs on the destination host matters too: a successful login immediately following the connection, especially from an account that doesn't normally use that host, is worth far more attention than the network connection alone.
Ruling out legitimate activity
SSH between internal hosts is completely ordinary in most environments, administrators, automated deployment tools, and monitoring systems all use it constantly, so the connection itself is rarely unusual on its own.
The distinguishing signal is whether the specific pairing of hosts, and the account making the connection, matches established, expected administrative patterns. A connection from a known jump host or administrator's own machine reads very differently from the same connection originating from a user workstation or a host with no prior reason to reach that destination.
References
Practice it
1 scenario in this catalog covers T1021.004. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →