Lateral movement is now an identity and data problem

At a glance

What this is: This is a Panther analysis of lateral movement, showing how attackers use legitimate admin tools, stolen credentials, and cloud identities to spread after initial access.

Why it matters: It matters to IAM, PAM, and security teams because lateral movement often succeeds through valid identities and permissions, so the problem is as much governance and telemetry quality as perimeter defence.

By the numbers:

• Kubernetes-related threat activity increased 282% between 2024 and 2025.
• A compromised AI inference pod yielded credentials in 86 seconds, including Azure Managed Identity tokens, Kubernetes service account tokens, and application-level secrets.

👉 Read Panther's analysis of lateral movement detection, prevention, and cloud identity abuse

Context

Lateral movement is what turns initial access into enterprise-wide compromise. Once an attacker is inside, the problem shifts from entry to how far they can travel using the same protocols, tools, and identities that administrators rely on every day. That makes lateral movement a security and identity governance issue, not just a detection problem.

In cloud and Kubernetes environments, the identity angle becomes sharper because attackers can pivot through IAM roles, service account tokens, and managed identities instead of only moving from host to host. That is why the controls that matter most are visibility, privilege scope, and identity correlation across logs, not just endpoint blocking or perimeter filters.

Key questions

Q: How should security teams detect lateral movement across SaaS applications?

A: Security teams should correlate identity, token, and API activity across connected applications, not just watch individual login events. Effective detection looks for abnormal API volume, new endpoints, unusual timing, and access patterns that do not match the integration’s normal behavior. Cross-platform baselines are essential because the attack often appears legitimate inside any single SaaS product.

Q: Why do service accounts and workload identities make lateral movement harder to stop?

A: Service accounts and workload identities often carry broad, persistent, or reusable permissions that attackers can exploit after initial access. If those credentials are not bound to segmentation boundaries, a compromise in one area can quickly become cross-zone movement. The risk is not the identity alone, but the combination of standing privilege and reusable reach.

Q: What breaks when organisations rely on detection but leave lateral movement paths open?

A: Detection can confirm compromise, but it cannot stop a compromised identity from reaching every system it is allowed to touch. When internal paths remain open, the incident becomes a breach through spread, not through the first entry point. Teams need containment controls that reduce the reachable blast radius before analysts finish triage.

Q: Which controls matter most when a lateral movement chain begins?

A: The key controls are segmentation, least privilege, token hygiene, and identity-aware monitoring. Segmenting east-west traffic limits reach, while reducing standing privilege and removing reusable credentials limits what an attacker can do if they do get inside. These controls work best together, not in isolation.

Technical breakdown

How reconnaissance sets up lateral movement

Attackers start by mapping the environment so they can choose the fastest path to valuable systems. Common discovery activity includes net view, arp, ping, nltest, and PowerShell modules that enumerate domains, hosts, and relationships. These commands are legitimate enough to blend into normal administration, which is why discovery-stage detection depends on sequence, timing, and user context rather than the command alone. Once the internal map is built, the attacker can target credentials and remote access paths with much higher efficiency.

Practical implication: monitor reconnaissance patterns as a stage-specific signal, not as isolated command alerts.

Why credential theft is the pivot point

Lateral movement usually accelerates when attackers obtain reusable authentication material. LSASS dumping, DCSync, Pass-the-Hash, Pass-the-Ticket, and Kerberoasting all convert one compromised host into credentials that work elsewhere. In cloud environments, the same pivot can come from stolen IAM role credentials, service account tokens, or secrets embedded in runtime state. The technical problem is not only theft, but the fact that modern estates contain many identities that can authenticate successfully without obvious user interaction.

Practical implication: reduce the value of stolen credentials by shrinking privilege scope and removing long-lived authentication material.

Why cloud lateral movement leaves different evidence

Cloud-native lateral movement often does not produce the Windows Event IDs defenders expect. Instead, the chain appears in cloud API calls, identity provider logs, Kubernetes telemetry, and flow data. That creates a correlation problem because the same actor may appear as an Okta identity, an AWS principal, and a host-level account across different tools. If those identities are not normalised, the movement path remains fragmented even when each log source is technically present.

Practical implication: build cross-source identity correlation before relying on detection rules to catch cloud pivots.

Threat narrative

Attacker objective: The attacker aims to turn a single compromised system into broader operational control by reusing trusted credentials and admin paths.

1. Entry occurs when an attacker gains an initial foothold, then uses built-in discovery tools to map internal systems and identify likely pivot points.
2. Credential access follows when the attacker harvests hashes, tickets, tokens, or cloud credentials that can authenticate beyond the first host.
3. Impact occurs when those credentials are used through legitimate remote access or cloud APIs to move laterally, reach higher-value systems, and expand breach scope.

NHI Mgmt Group analysis

Lateral movement is an identity abuse problem disguised as an endpoint problem. The article makes clear that attackers do not need exotic malware when PowerShell, RDP, WMI, IAM role assumptions, and service account tokens already provide valid paths. That shifts the governance question from whether a tool is blocked to whether the identity behind the tool is constrained, correlated, and continuously understood. Practitioners should treat east-west compromise as a privilege management failure, not only a detection exercise.

Cloud lateral movement exposes a verification trust gap between systems that authenticate and systems that are actually authorised. In Kubernetes and cloud environments, a token, role, or managed identity can be enough to move from one workload to another without any human action. That creates a governance gap that conventional access review processes do not always capture because the access path can be short-lived, delegated, and distributed across platforms. The practical conclusion is that identity evidence must be joined across cloud, endpoint, and directory telemetry.

Detection quality now depends on identity resolution, not just log volume. Panther's examples show that correlation breaks down when Okta, Active Directory, CloudTrail, and endpoint telemetry use different identity formats. That makes the named concept here the identity correlation gap: the space between having logs and being able to reconstruct a movement chain from them. Security teams should understand this as a governance and engineering problem, because unmanaged identity fragmentation lowers detection fidelity across the whole programme.

Zero Trust only works when the underlying identities are as tightly scoped as the architecture assumes. NIST SP 800-207 is relevant here because lateral movement is exactly what zero trust is meant to constrain, but dynamic verification loses value when service accounts, tokens, and role chains still carry broad standing privilege. The article reinforces a simple point: if the identity layer remains over-permissive, zero trust becomes a network label rather than an operational control. Practitioners should re-evaluate where their trust assumptions still depend on static privilege.

North-south security models miss the real control boundary in modern estates. The attack path now runs through cloud APIs, workload identities, and privileged automation, which means the meaningful boundary is not the firewall alone but the set of identities that can move laterally without friction. That is why NHI governance, PAM, and telemetry engineering are converging in practice. The field should expect more control frameworks to treat service account hygiene and identity correlation as core resilience issues, not niche implementation details.

What this signals

Identity correlation is becoming a core SOC requirement. As lateral movement crosses directory, cloud, and endpoint telemetry, the programme risk is no longer only missed alerts but broken reconstruction. Teams that cannot normalise identity across Okta, Active Directory, CloudTrail, and workload logs will keep paying for investigations with manual stitching and delayed containment.

Standing privilege in automation is the real blast-radius amplifier. The more cloud and Kubernetes paths rely on reusable tokens or broadly delegated roles, the easier it is for an intruder to convert one foothold into wider control. That means PAM, NHI governance, and detection engineering need to be planned together rather than as separate workstreams.

For practitioners

• Map lateral movement paths to identity owners Build an inventory of service accounts, IAM roles, Kubernetes tokens, and admin accounts that can authenticate across multiple systems, then assign clear ownership for each path. Prioritise identities that can reach crown-jewel systems or cloud control planes. Use the NHI Lifecycle Management Guide to structure ownership, rotation, and offboarding decisions.
• Correlate identity formats across telemetry Normalise Okta users, Active Directory accounts, CloudTrail principals, and endpoint usernames into a shared identity layer so analysts can follow one actor across tools. Without that mapping, valid authentication events remain disconnected even when the attack is obvious in hindsight. Use the MITRE ATT&CK Enterprise Matrix to align detections to credential access and lateral movement tactics.
• Harden cloud and workload credentials Replace long-lived secrets and broad role chaining with tightly scoped workload identities, short-lived credentials, and explicit trust boundaries for Kubernetes and cloud automation. Audit token paths that are readable by default inside pods and remove any standing access that can be reused for pivoting.
• Tune detections for behavioural sequences Watch for discovery followed by credential abuse and then remote execution, especially when the same user or host starts generating unusual east-west traffic. Build detections around sequences such as port scanning, Kerberos anomalies, and remote service creation instead of relying on single-event signatures.

Key takeaways

• Lateral movement is best understood as identity reuse across trusted tools, not as an exotic post-exploitation technique.
• The evidence points to a detection problem rooted in fragmented logs, cloud-native identity sprawl, and legitimate admin pathways.
• Teams that reduce standing privilege, improve identity correlation, and constrain east-west access will shrink the attacker’s room to manoeuvre.

Key terms

• Lateral Movement: A post-compromise technique where an attacker uses a compromised NHI to move through a network, accessing additional systems and escalating impact without triggering detection.
• Identity Correlation Gap: An identity correlation gap is the disconnect between logs that each identify the same actor differently across systems. It appears when directory, cloud, endpoint, and SaaS telemetry cannot be normalised into one investigation path, weakening detection and delaying containment.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Service Account Hygiene: Service account hygiene is the practice of controlling non-human identities so they are owned, scoped, monitored, and removed when no longer needed. Weak hygiene leaves reusable credentials and excessive permissions in place long after the original purpose has ended.

What's in the full article

Panther's full blog post covers the operational detail this post intentionally leaves for the source:

• Command-by-command examples for reconnaissance, credential theft, and remote execution across Windows and cloud environments
• Detection logic and log-source guidance for correlating Okta, CloudTrail, Active Directory, and endpoint telemetry
• Concrete examples of how Kubernetes service account theft and IAM role chaining show up in real intrusions
• Practical prevention guidance for segmentation, identity hygiene, and east-west traffic controls

👉 Panther's full post covers the attack stages, cloud-specific pivots, and detection cues in more operational detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and secrets management for practitioners who need to connect identity controls to operational risk. It helps security teams and identity leads translate governance into lifecycle discipline across modern environments.