What are the signs that lateral movement is happening between cloud resources?

One common sign is abnormal traffic behavior between dependent resources, especially sudden bursts in lateral network traffic. Those spikes can indicate malicious movement even when endpoint or threat-hunting tools have not yet identified the compromise on the source resource. Monitoring segment behavior is useful because attackers must traverse network paths to move from one resource to another.

What lateral movement looks like in cloud environments

lateral movement in cloud resources is usually visible as activity that does not match the normal dependency pattern between services, accounts, or segments. The key signal is not simply “more traffic,” but traffic that starts reaching new peers, new ports, or new service paths that the resource does not usually touch. That often appears alongside authentication or authorization changes that let an attacker reuse one foothold to reach another system.

When cloud resources are involved, the most useful lens is the path of trust: which resources are expected to talk, which credentials are expected to work, and which control plane actions are expected to happen. If a workload, service, or admin path suddenly begins interacting with adjacent resources outside its usual role, that is more suspicious than a single isolated spike. This is especially true when the movement crosses account, subscription, project, or tenant boundaries.

A practical way to think about the pattern is that attackers try to blend into ordinary east-west traffic while quietly expanding access. That means the signal may show up in network flow data, identity logs, API calls, or cloud audit trails rather than in endpoint alerts alone. For cloud defenders, segment behavior and peer relationships matter because they show whether a new communication path was created, not just whether a resource is active.

Signs that the movement is progressing beyond the first foothold

One sign is a burst of new lateral connections between resources that normally have limited dependency on each other. Another is the appearance of access from an unusual source identity, such as a service principal, workload, or automation path that suddenly begins touching administration endpoints, storage, secrets, or management APIs it does not usually use. Repeated failed attempts followed by success can also indicate credential discovery or privilege escalation in progress.

Look for changes in behaviour across layers, not only one control. A resource that starts making outbound calls to new internal destinations, begins authenticating with a different token or key, or starts invoking cloud management operations outside its normal baseline may be following an attacker path rather than a business process. In cloud environments, lateral movement often includes both network traversal and control plane abuse, so the evidence may be split across telemetry sources.

Useful corroborating indicators include unusual session timing, new regions or IP ranges, rapid enumeration of resources, and access to management functions that were previously unused by that actor. Those patterns are stronger when they align with a dependency chain that the business does not expect. A legitimate autoscaling or deployment event should normally leave a predictable change record; attacker movement often does not.

Risk and Threat Considerations

Cloud lateral movement matters because one compromised resource can quickly become a bridge to higher-value systems, secrets, or management APIs. The main risk is blast-radius expansion: once an attacker can reuse a trusted path, they can pivot from a single workload or credential into broader infrastructure access before detection catches up.

Failure mechanism: Weak segmentation, excessive permissions, reused credentials, or poorly governed service access lets an attacker traverse from the initial compromise to adjacent resources with little friction. That movement may be hidden inside normal east-west traffic, making the compromise look like routine service communication until access is already spreading.

Impact: A successful pivot can expose data, enable privilege escalation, or lead to destructive actions across multiple cloud resources. It can also undermine confidence in logs and detections if the attacker uses legitimate identities and approved APIs to move laterally.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	TA0008 — Lateral Movement	Directly maps to attacker pivoting between cloud resources.
	T1021 — Remote Services	Cloud pivoting often uses remote services and management channels.
	T1090 — Proxy	Attackers may relay traffic to move through cloud environments covertly.
Recommendation — Map new east-west paths to TA0008 and investigate unexpected peer-to-peer access. Monitor remote service use for unusual source-to-destination combinations and abnormal auth patterns. Hunt for proxy-mediated pivots that obscure the original source of cloud access.
NIST CSF 2.0	DE.CM — Continuous Monitoring	Abnormal east-west traffic is a continuous monitoring signal in cloud environments.
Recommendation — Baseline inter-resource traffic and investigate deviations in your monitoring workflow.

Practitioner Guidance

What to prioritise: Correlate network flow anomalies with identity, token, and cloud audit events before treating a spike as benign. The most meaningful cases are where a new lateral path appears at the same time as a new authentication pattern, new API use, or access to a management surface.

What to verify: Confirm whether the source resource normally talks to the destination, whether the access path matches the declared service dependency, and whether the identity used for the connection is expected. If the resource can reach high-value systems without a strong business reason, treat that as a containment issue even if no malware alert has fired.

Practitioner takeaway: The best signal is not raw traffic volume, it is unexplained trust expansion. If cloud movement creates a new communication path or a new privilege path, assume the incident is progressing until the dependency is proven legitimate.