Cross-domain attacks show why identity controls need unification

At a glance

What this is: This analysis looks at how cross-domain attacks use compromised identities and legitimate tools to traverse endpoint, identity, and cloud boundaries.

Why it matters: For IAM and NHI teams, the lesson is that fragmented controls leave service accounts and other non-human identities exposed to rapid privilege escalation and lateral movement.

By the numbers:

• The CrowdStrike 2024 Global Threat Report states 75% of intrusions begin without malware, enabling attackers to operate under the radar and seamlessly navigate between the endpoint and cloud domains.
• In December 2024, CrowdStrike said the average eCrime breakout time was 62 minutes, giving defenders a narrow window to detect lateral movement before impact.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read CrowdStrike's analysis of cross-domain attacks and identity-driven movement

Context

Cross-domain attacks are intrusions that move across endpoint, identity, and cloud layers instead of staying inside one control plane. That matters for NHI governance because service accounts, tokens, and other machine identities often become the bridge between those domains, especially when access rights are broader than the task requires.

CrowdStrike’s example shows a familiar defender problem: once an attacker reaches a valid account or service account, normal administrative tooling can look routine until privilege changes, credential access, or data staging begin. That starting position is typical in modern enterprise intrusions, not an edge case.

For security leaders, the practical issue is not just stopping initial entry. It is constraining what an identity can do after it is used, which is where least privilege, session oversight, and cross-domain telemetry become decisive.

Key questions

Q: How should security teams reduce the impact of a compromised service account?

A: Reduce the impact by narrowing what the account can reach, shortening how long it can be used, and removing any reuse across environments. Pair least privilege with session monitoring and approval for sensitive actions. If the account can traverse multiple domains, assume compromise will spread unless reachability is segmented.

Q: Why do cross-domain attacks create more risk than single-domain intrusions?

A: Cross-domain attacks are harder to contain because a valid foothold can be reused across endpoint, identity, and cloud controls. Attackers can blend into normal administration, which delays detection and expands the blast radius. The risk is not only access, but the speed at which that access can be repurposed.

Q: What is the difference between secret rotation and session governance?

A: Secret rotation changes the credential material, while session governance controls what a live authenticated session can do after login. Rotation helps if a secret is stolen, but it does not stop a valid session from moving laterally or invoking administrative tools. Effective programmes need both controls.

Q: Should organisations prioritise Zero Trust or least privilege first for NHI risk?

A: Prioritise least privilege first if identities are over-scoped, shared, or reusable across domains. Zero Trust becomes more effective when the identity itself has limited reach and every session must be re-evaluated. The two controls work together, but blast-radius reduction usually delivers faster risk reduction.

Technical breakdown

How cross-domain attacks turn identity into a movement layer

Cross-domain attacks succeed when identity boundaries are weaker than network boundaries. An attacker may begin with an exposed appliance, stolen credentials, or an unmanaged account, then use legitimate protocols such as RDP, SSO-backed logins, or admin tooling to move into adjacent systems. The key issue is that these actions often blend into normal operations because they are authenticated, authorized, and operationally plausible. In NHI environments, service accounts and tokens can become high-speed transit mechanisms when they are shared, long-lived, or over-scoped. Practical detection needs identity context, not just endpoint telemetry.

Practical implication: Correlate identity events with endpoint and cloud activity so one compromised account cannot traverse domains unnoticed.

Why legitimate tools create the hardest detection problem

Adversaries increasingly use native utilities, remote management products, archiving tools, and data transfer software because they reduce noise. This is a classic living-off-the-land pattern, but in cross-domain attacks it is amplified by identity reuse. A valid session or service account can make tool use look administrative even when the objective is credential dumping, privilege escalation, or staging for exfiltration. The architectural lesson is that tool choice matters less than authorization context. If a session can reach too many systems, the attacker inherits that reach with very little friction.

Practical implication: Treat high-risk administrative tools as conditional access events and require stricter session controls around them.

What identity blast radius means in practice

Identity blast radius is the amount of infrastructure, data, and privilege reachable after one credential or session is compromised. In cross-domain environments, blast radius expands when identities are reused across domains, when service accounts are not segmented, or when access is not time-bound. That is why Zero Trust Architecture and Zero Standing Privilege matter here: they reduce the distance an attacker can travel after the first foothold. The mechanism is not perfect prevention. It is containment that makes lateral movement slower, noisier, and easier to interrupt.

Practical implication: Map every high-value identity to its reachable systems and reduce standing privilege before attackers do it for you.

Threat narrative

Attacker objective: The objective is to pivot from initial foothold into privileged access, then stage data theft or ransomware while blending in with legitimate administrative activity.

1. Entry via an unmanaged GlobalProtect VPN appliance vulnerable to CVE-2024-3400, which gave the attacker a foothold in the target environment.
2. Escalation through a service account used to access another host, followed by attempted credential dumping and privilege elevation into administrator groups.
3. Impact through attempted reconnaissance, ransomware deployment, and exfiltration tooling, with the goal of broader operational disruption and data theft.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity is now the primary routing layer for cross-domain attacks. Once an adversary holds a legitimate session or service account, they no longer need to “break” every boundary in the traditional sense. They simply move through whatever the identity can already reach. That makes NHI governance a control-plane problem, not just an account hygiene problem. Practitioners should assume the attacker will inherit the permissions graph unless those permissions are tightly segmented.

Cross-domain defense fails when teams measure compromise at the endpoint but govern privilege at the directory. The article’s attack pattern shows how quickly endpoint compromise becomes identity misuse, then cloud or application risk. Security programmes that separate EDR, IAM, and cloud governance will miss the speed of this chain. Practitioners need shared control objectives across these domains, especially for service accounts, admin tooling, and remote access paths.

Identity blast radius is the right named concept for this class of risk. It captures how far one compromised NHI can travel before containment starts. The more reusable and over-scoped the identity, the larger the blast radius and the harder it is to distinguish legitimate from malicious action. That means access reviews should focus on reachability, not just entitlement counts. Practitioners should shrink blast radius before they rely on detection to catch abuse.

Zero Trust only works here when identity is continuously re-evaluated in context. Static trust decisions are too slow for the pace of cross-domain movement described in the source material. Continuous verification, device context, and session-level policy are what limit an attacker’s ability to reuse a foothold. The practical conclusion is simple: cross-domain defense needs continuous authorization, not periodic approval.

NHI governance must extend beyond secrets rotation to session governance. The attacker value in these cases comes from valid use, not only stolen material. Rotating secrets is necessary, but it does not address what a live session can do once issued. Practitioners should treat session scope, duration, and cross-system reach as first-class controls.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For a broader control perspective, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that reduce the same exposure window.

What this signals

With 6 distinct secrets manager instances on average across organisations, the operational problem is not just leaked credentials, but fragmented control of where those credentials live and who can use them. That fragmentation makes cross-domain containment harder and is why Top 10 NHI Issues remains a useful lens for programme prioritisation.

Identity blast radius: the next stage of NHI governance is to measure how far one valid credential can travel before a control interrupts it. That includes service accounts, operator sessions, and automation tokens, all of which should be mapped against the paths they can actually reach. For a standards anchor, align the review process to NIST Cybersecurity Framework 2.0 and the identity control expectations in the NIST SP 800-63 Digital Identity Guidelines.

If your programme still treats authentication, endpoint response, and cloud authorization as separate tracks, cross-domain attacks will keep exposing the seams. The practical pivot is to treat NHI governance as a continuous control loop: discover, constrain, observe, and revoke. That is the operating model that makes lateral movement slower than defenders can react.

For practitioners

• Map identity reach across domains Build a reachability inventory for service accounts, admin users, API tokens, and remote access accounts. Include endpoint, cloud, directory, and application paths so you can see where one identity can move if compromised.
• Segment service accounts by task and environment Stop reusing service accounts across hosts or domains. Assign task-scoped identities with narrow permissions, and separate production, staging, and administrative functions so compromise does not cascade.
• Tighten session controls on privileged tools Require stronger checks for RDP, remote management, archiving, and file transfer tools when they are used by elevated accounts. Session monitoring should flag unusual host-to-host access, especially when identity context changes quickly.
• Correlate endpoint and IAM telemetry Feed sign-in events, token use, account changes, and endpoint process activity into a shared detection view. The goal is to identify when legitimate authentication is being used to drive abnormal lateral movement.
• Adopt Zero Standing Privilege for high-risk identities Provision elevated access only when a task requires it, then remove it immediately after use. For service accounts and operator identities, pair time-bound access with approval and audit logging.

Key takeaways

• Cross-domain attacks turn valid identity into the attacker’s shortest path across endpoint, cloud, and application controls.
• The exposure problem is measured in blast radius, not just in initial compromise or secret theft.
• Teams need segmented service accounts, tighter session governance, and shared telemetry before containment can keep pace.

Key terms

• Cross-domain attack: An attack that moves across identity, endpoint, cloud, and application boundaries rather than staying in one control domain. It succeeds when defenders treat those layers separately and allow a compromised identity or session to carry trust from one environment into another.
• Identity blast radius: The total reach of a compromised identity, including systems, data, and administrative actions it can access before containment occurs. In NHI governance, this is the most practical way to measure how dangerous a credential or session really is.
• Service account: A non-human identity used by software, infrastructure, or operations processes to authenticate and perform tasks. Service accounts often become high-risk when they are shared, long-lived, or granted broad access that exceeds the task they were created to perform.
• Zero standing privilege: A control model in which elevated access is not persistent and is granted only when needed for a specific task. For non-human identities, it reduces the time window in which a stolen credential or session can be abused for escalation or lateral movement.

Deepen your knowledge

Cross-domain attack defense and identity blast radius control are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to connect IAM, endpoint, and cloud controls, this is a strong starting point.

This post draws on content published by CrowdStrike: The Rise of Cross-Domain Attacks Demands a Unified Defense. Read the original.