Agent Lateral Movement and Pivoting

How the attack works

The agent first does something that reads or accesses a credential (a config file, key, or token) or spawns a process. Shortly afterward, in the same short time window, it connects out to a different host — a new SSH-style session, an HTTP request, or a network connection that wasn't there before. Seeing both a credential read and a fresh outbound connection close together is treated as evidence the agent used what it found on host A to reach host B. A single isolated command, like one ssh call, is not enough to trigger this — that's normal developer or automation behavior.

Netzilo detection

Why it matters

An agent that pivots between hosts can spread an initial compromise or an over-broad task into systems outside its intended scope, potentially using credentials it was never supposed to touch to reach infrastructure the operator didn't expect it to access.

What you can do

• →Restrict the credentials and SSH keys available to agent sessions to only the single host they need, not fleet-wide access.
• →Review agent task definitions so multi-host operations (deployments, backups, fleet-wide config changes) are explicit and expected rather than incidental.
• →When this fires, check whether the second-host connection was part of the original task; deployment tools, config management, and rsync backups are common legitimate causes.
• →Log and time-correlate credential access with outbound connections from agent sessions so real pivots are distinguishable from routine multi-host automation.

Known benign look-alikes

• Developers using ssh or kubectl exec to reach internal infrastructure as part of the task they asked the agent to do — this is the dominant false positive and the reason the verdict is report
• Deployment and configuration-management runs that ssh to a fleet
• Backup jobs using rsync between internal hosts

References

• https://attack.mitre.org/techniques/T1021/
• https://attack.mitre.org/techniques/T1078/

Related threats