Scattered Spider exposed vendor trust gaps in retail service desks

At a glance

What this is: This analysis shows how Scattered Spider used third-party service desk identity weaknesses and privileged access to reach retailer environments, turning inherited trust into a ransomware path.

Why it matters: It matters because IAM, PAM, and lifecycle controls must extend to vendors and service accounts, or attacker access will move faster than internal review and containment processes.

By the numbers:

• more than $400 million in lost profit
• more than 60% of consumers would stop shopping with a brand that suffered a security incident

👉 Read 1Kosmos's analysis of the Marks & Spencer supply chain identity breach

Context

Scattered Spider did not need a novel exploit chain to reach retailer environments. The core problem was identity governance across the service desk, where third-party access, privileged workflows, and weak verification created a path into client systems once trust was inherited.

In retail, the combination of outsourced support, broad administrative reach, and inconsistent privileged access checks creates a supply chain identity problem. When an attacker can impersonate support, the organisation's authentication model stops protecting the boundary that matters most.

This pattern is becoming familiar in retail, and that is the warning sign. The attack surface is not only the retailer's own IAM stack, but the verification discipline of every provider that can act on its behalf.

Key questions

Q: How should organisations handle vendor service desk access that can reset or elevate privileged accounts?

A: Treat vendor service desk access as privileged access, not ordinary support. Require fresh identity verification for each high-risk request, bind every action to an accountable operator, and limit what the vendor can do without client-side approval. If a vendor can reset credentials or approve elevation, its controls are part of your attack surface.

Q: Why do third-party support relationships increase ransomware risk?

A: Because attackers can abuse trusted support workflows to gain legitimate-looking access without breaking perimeter controls. Once inside, they can pivot from identity abuse to broader administrative reach, stage persistence, and later deploy ransomware. The danger is inherited trust, where the provider's access becomes the client's exposure.

Q: What do security teams get wrong about MFA when service providers are involved?

A: They assume MFA alone can stop abuse of trusted support paths. In reality, attackers can bypass or defeat MFA through social engineering, SIM swapping, or misuse of already-authorised provider access. MFA helps, but it does not replace re-authentication, step-up controls, and privileged workflow verification.

Q: Who is accountable when a third-party service desk is used to reach client systems?

A: Accountability is shared, but the client remains responsible for the access it accepts into its environment. Governance frameworks such as NIST CSF and zero trust require the buyer to verify that external support access is authenticated, approved, monitored, and revocable. Delegation does not transfer ownership of the risk.

Technical breakdown

How service desk identity becomes an entry point

Service desk operations often rely on delegated trust, where a third party can request resets, approvals, or account changes on behalf of a client. That model is efficient, but it becomes dangerous when the provider's own identity checks are weak. Social engineering works because the attacker does not need to defeat the full enterprise perimeter. They only need one path where help desk trust, privileged workflow access, and weak verification intersect. Once that happens, the attacker can obtain legitimate-looking access that downstream systems treat as authorised.

Practical implication: review every vendor support path that can reset credentials, approve access, or alter account state, and treat those paths as high-risk privileged entry points.

Why privileged access control failed after initial compromise

Privileged access management only works when every elevation is tied to a verified identity event. In this pattern, the attacker inherits access through a service provider and then uses that reach to move into the client environment. If privileged sessions are granted on the basis of vendor role alone, the client has effectively accepted the provider's internal controls as its own. That is the governance failure. The issue is not just who logged in, but whether the access request was re-authenticated and re-justified at the moment of elevation.

Practical implication: require step-up verification for every privileged action that originates from a third party, even when the provider is already trusted at the network layer.

How ransomware impact follows from inherited trust

Once attackers have broad system access, they can pivot from identity abuse to destructive action. In this case, the campaign culminated in ransomware encrypting VMware ESXi hosts after months of undetected persistence. That delay matters because it shows how inherited trust can create a quiet window for discovery, escalation, and staging before impact becomes visible. When identity controls do not constrain lateral movement, the attacker can convert a support relationship into full operational disruption.

Practical implication: monitor vendor-originated privileged activity for lateral movement indicators, and assume a support account can become a staging point for destructive ransomware.

Threat narrative

Attacker objective: The attacker objective was to turn trusted third-party access into broad internal control and then use that access to deploy ransomware and disrupt business operations.

1. Entry occurred when Scattered Spider targeted a third-party IT provider with weak service desk identity checks and used social engineering and SIM swapping to obtain trusted access.
2. Escalation followed when the attackers leveraged privileged access and help desk workflows to move from the provider into client environments, including Microsoft Active Directory access at the retailer.
3. Impact came when the attackers maintained access long enough to deploy DragonForce ransomware on VMware ESXi hosts and disrupt operations for months.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Supply chain identity compromise is now a primary retail attack path. The core issue is not perimeter weakness but delegated trust that allows a third party to act with the retailer's authority. When service desk processes are under-verified, attackers do not need to break in. They only need to present themselves as the trusted intermediary. Retail programmes must treat vendor identity as part of the core control plane, not as an external exception.

Inherited privilege without fresh verification is the failure mode this breach exposes. Privileged access models were designed for environments where authority could be assumed from role and session context. That assumption fails when a provider's access is enough to traverse into client systems without re-authentication at the moment of use. The implication is that clients cannot outsource trust and still claim to control privilege.

Vendor access without lifecycle offboarding: access outlives accountability when third-party credentials, resets, and support entitlements are not tightly retired as relationships change. This breach worked because the access path remained usable long enough for attackers to stage ransomware. The lesson is not only that privilege was present, but that governance allowed it to persist beyond the security boundary that should have contained it.

Retail identity programmes now need cross-boundary PAM discipline. The attacker chain crossed from help desk impersonation into broad administrative reach and then into destructive impact. That progression shows why PAM, MFA, and service desk verification must be assessed as one system across retailer and provider. A client can no longer evaluate its own controls without asking how a vendor's access is authenticated, approved, and revoked.

Modern zero trust for retailers must include the trust broker, not just the endpoint. The breach demonstrates that endpoint security and network controls do not prevent compromise when the identity broker is the target. If the entity granting support access is weakly verified, the entire trust model inherits that weakness. Practitioners should read this as a governance warning: zero trust fails if the vendor path remains implicitly trusted.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
• From our research: Read 52 NHI Breaches Analysis for the incident patterns that show how privileged identity failures become breach paths.

What this signals

Supply-chain identity control is becoming a board-level retail risk. When third-party service desks can reset, approve, or extend access, the retailer's own IAM programme is only as strong as the provider's verification discipline. That makes vendor access reviews, not just internal recertification, a standing operational requirement.

Identity blast radius now matters more than perimeter hardness. The next control conversation for retail teams is how far a single support identity can move after initial compromise. If a help desk account can touch authentication, privilege elevation, and directory administration, the blast radius is already too large for conventional review cycles to contain.

Retail security teams should expect more attacks that target support workflows instead of endpoints. The practical response is to trace every privileged pathway from vendor request to client execution and to collapse any step that depends on inherited trust rather than fresh verification.

For practitioners

• Reclassify vendor support as privileged access Map every third-party service desk action that can reset credentials, approve sessions, or change entitlements, and assign it the same review depth as administrator access.
• Require fresh identity verification for vendor-originated elevation Do not allow vendor role, VPN state, or inherited session context to authorise high-risk changes. Force re-authentication at the point of privilege use.
• Separate support identity from execution rights Ensure a help desk account cannot directly move from request handling to privileged execution without additional controls, approval logging, and traceable session binding.
• Test third-party offboarding and revocation paths Simulate a vendor relationship change and verify that access, reset authority, and privileged workflows are removed quickly enough to prevent inherited trust from persisting.

Key takeaways

• Scattered Spider succeeded by abusing trusted service desk pathways, not by defeating retail perimeter security.
• The breach shows how inherited vendor privilege can convert weak support identity checks into ransomware-scale impact.
• Client organisations need vendor-aware privileged access controls, fresh verification at elevation, and faster offboarding of delegated access.

Key terms

• Supply Chain Identity Compromise: A breach pattern where attackers abuse trusted third-party identity relationships to enter a target environment. The compromise may begin outside the buyer's boundary, but the impact lands inside it because delegated support, authentication, or privilege is treated as inherently trusted.
• Inherited Trust: Access or authority accepted from another party without fresh verification at the point of use. In identity security, inherited trust is dangerous because a vendor's approval, session, or role can become a shortcut into client systems if the receiving organisation does not re-check the identity event.
• Privileged Access Path: The sequence of accounts, workflows, and approvals that can elevate a request into high-risk administrative control. In practice, this path often crosses help desks, PAM, directory services, and vendor support tools, so any weak link can become an entry route for attackers.
• Step-up Verification: An additional identity check required when a request crosses into higher-risk action. For privileged or third-party actions, step-up verification forces the actor to re-prove identity at the moment of elevation, reducing the chance that an inherited session can be reused for destructive access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by 1Kosmos covering the Marks & Spencer and Scattered Spider supply chain identity breach: A Scattered Spider attack exploited systemic service desk flaws and weak privileged access controls. Here's how to shut the door for good. Read the original.