Cyberattackers progressively move through a network as they search for key data and assets that ultimately fulfill their mission. This is referred to as lateral movement.

When an attacker compromises a cloud asset, usually that machine is not their target, but rather the path to it.

After successful infiltration, they perform reconnaissance—exploring not just that machine, but also its network for information (risks) that might provide them with escalated privileges and access to other assets.

So armed, they then use their gathered information to move from the initially compromised machine across the cloud estate until their mission is fulfilled.

A difference exists between detecting actual lateral movement and detecting the risk of lateral movement.

  • Actual Lateral Movement: Existing security tools can analyze the movement of network traffic between assets; anomalies can be indicative of malicious intent.
  • Risk of Lateral Movement: Information stored in a manner that, if discovered, could be leveraged to access other machines or allow a further foothold in an environment.

Existing solutions can detect actual lateral movement, but can’t detect private keys, passwords in shell history, or other information that could be leveraged by an attacker to move laterally on your environment.

Consider the following example. Servers A and B never communicate with one another, but A has a key that allows root access to B.

Existing tools would inform you there is no lateral movement. They would be correct because there is no traffic between the two machines. But they would completely miss an insecurely stored SSH key on server A that provides root access to server B.

This poses a lateral movement risk. For an attacker to stumble upon an insecurely stored key is like finding gold. They now test to learn which machines the key provides access to and voila, they now have access to both A and B.

To prevent an attacker from moving laterally, it’s essential to know where sensitive information, such as insecurely stored keys, is located across your entire cloud environment.

Orca Security scans your entire cloud account in a holistic manner. It peers into each machine’s filesystem for private keys, such as on server A, taking a hash of each found.

It then checks the authorized key configuration across all other assets for public keys. If any are found, such as on server B, Orca calculates hashes and compares the private key hash to find a match. If there is, Orca sends an alert as seen in the image below:

From the image above we see that Orca provides:

  • The path to the insecurely stored key: /var/lib/jenkins/plugins/mailer/mailer.js/dev_keys.pem
  • A recommended solution
  • The identity of the machines the key allows access to e.g., (Web-Nginx, WEB-PRD, DEV-RND)
  • The user account on the machine in this case (root user for all machines in this example)

Other lateral movement risks Orca finds are:

  • Passwords in Shell History
  • Sensitive Info in Git Repository
  • Sensitive AWS Keys on Systems

For another perspective, check out my colleague Patrick Pushor’s presentation below on Lateral Movement Attacks that he presented at the Cobolt.io Sec Talks Virtual Conference.