SolarWinds-style cloud compromise exposed the cost of privileged access

At a glance

What this is: Britive explains how the SolarWinds compromise turned a software supply chain foothold into privileged cloud access across Azure and related service accounts.

Why it matters: IAM and PAM teams should treat cloud privilege, federation trust, and service-account scope as attack surface, not just administration detail.

Context

The core issue in this incident is not just software compromise but what a privileged foothold can do once it lands inside a cloud control plane. The article shows how attackers moved from SolarWinds Orion into Azure, then used trusted identities and permissions to widen their reach.

For identity programmes, this is a cloud privilege governance problem as much as a supply chain one. Existing controls often assume trusted accounts remain trustworthy and reviewable; this case shows how quickly that assumption breaks once attackers can manipulate certificates, roles, and service principals.

Key questions

Q: What breaks when a cloud vendor compromise reaches privileged identities?

A: The break is that application compromise stops being an application problem and becomes a trust problem. Once attackers can use legitimate cloud identities, they can manipulate federation, create or alter service principals, and make privileged actions look ordinary. That collapses the assumption that audit logs alone will reveal abuse.

Q: Why do overprivileged service accounts and local administrators create such a large Windows attack surface?

A: They create reusable paths to higher access. When an account has more privilege than its task requires, attackers can abuse misconfigured services, weak registry permissions, stored passwords, or insecure executables to move from initial foothold to administrative control. Excess privilege also broadens lateral movement opportunities and makes it easier to hide malicious activity inside normal administration.

Q: How do teams know whether cloud privilege controls are working?

A: Look for whether privileged changes are reviewable, short-lived, and distinguishable from normal operations. If certificate additions, permission grants, and token-related changes blend into routine logs, then the control set is not detecting the events that matter most.

Q: What should IAM teams do after a supply chain compromise affects cloud access?

A: They should re-baseline trust dependencies, revoke or rotate any credentials that could sign or validate access, and recertify cloud permissions tied to high-value service identities. The objective is to shrink the blast radius before attacker-created trust survives into the next session.

Technical breakdown

How a supply chain foothold became cloud control

The article describes a classic progression from initial compromise to privileged cloud manipulation. Attackers first exploited the Orion environment, then used that foothold to move laterally into Azure. Once there, they could alter Azure Active Directory settings, create accounts, and change permission structures. The important mechanism is not just access, but trust inheritance: once a trusted platform identity is compromised, downstream cloud actions can appear routine in logs. That makes privilege abuse harder to distinguish from normal administration and extends the blast radius well beyond the original host or application.

Practical implication: treat vendor software footholds as a route into cloud administration, not as a bounded application issue.

Why SAML tokens and service principals amplified impact

Britive notes that attackers obtained trusted SAML token signing certificates and used them to craft their own tokens. They also added privileged credentials to service principals and other applications, including OAuth applications with mail permissions. This matters because federated trust can convert one compromised identity into many accepted assertions across systems. In identity terms, the issue is not only authentication, but who can mint, sign, or validate trust artifacts. Once those trust objects are abused, access can persist and spread without needing repeated break-ins.

Practical implication: place certificates, token signing, and service-principal credentials under the same governance as direct user access.

How hidden privilege can survive in normal-looking logs

The article says the attackers were able to hide administrator privileges in logs as trusted actions and that the breach went undetected in Azure for months. That is a logging and authorization failure, not merely a detection delay. If the environment treats privileged cloud actions as routine because they are executed by a legitimate identity, then audit trails lose their value as evidence of abnormality. Effective governance must distinguish who is acting, what trust object was used, and whether the permission scope matches expected administration patterns.

Practical implication: review cloud audit data for permission changes and trust-object creation, not just for failed logins or malware alerts.

Threat narrative

Attacker objective: The attackers aimed to turn one trusted software compromise into durable administrative control over cloud identities, permissions, and data access.

1. Entry via compromise of the SolarWinds Orion platform gave attackers a foothold inside a trusted software environment.
2. Escalation followed when the attackers moved laterally into Azure and manipulated Azure Active Directory to expand control.
3. Credential abuse then centred on trusted SAML signing certificates, service principals, and elevated permissions that let attackers act as legitimate administrators.
4. Impact included hidden cloud-wide persistence, email access via Microsoft Graph or Outlook REST, and prolonged undetected privilege abuse.

Breaches seen in the wild

• SolarWinds supply chain compromise: A backdoored Orion build reached 18,000 customers; attackers then forged SAML tokens and hijacked app service principals.
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

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

NHI Mgmt Group analysis

Trusted cloud administration is only as strong as the trust objects underneath it. This incident shows that service principals, signing certificates, and inherited cloud permissions can become the real control plane once a privileged foothold is established. When those objects are compromised, normal-looking administration becomes attacker infrastructure. The practitioner conclusion is that trust artifacts need the same scrutiny as the systems they protect.

Standing privilege is the failure mode, not just a configuration preference. The article’s strongest lesson is that attackers did not need novel malware after the initial foothold if privileged accounts and certificates remained usable. That is exactly the kind of persistent access path Zero Standing Privilege is meant to remove. The practitioner conclusion is that cloud roles must be measured by exposure window, not by nominal ownership.

Hidden privilege is a governance blind spot because logs can validate the attacker’s cover story. Britive’s account shows that elevated actions can look legitimate when carried out through trusted identities and accepted federation artefacts. That means audit models built only around sign-in events or account inventories miss the abuse path. The practitioner conclusion is to govern permission changes and trust creation as first-class security events.

SolarWinds-style compromise exposed the identity blast radius of supplier trust. This is a supply chain incident, but the scale of harm came from identity, not code alone. Once the compromise crossed into Azure Active Directory and service principal control, the attack expanded into a wider trust ecosystem. The practitioner conclusion is that supplier risk reviews must include downstream identity authority, not just software provenance.

Least privilege was assumed, then bypassed through reconfiguration. The attackers were able to add credentials, elevate permissions, and reframe trusted actions as routine. That means least privilege at provisioning time was not enough because the actual control boundary moved during the attack. The practitioner conclusion is to reassess privilege as a dynamic state that can be rewritten by the identities themselves.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Identity blast radius: supply chain incidents become much harder to contain once a trusted workload can touch federation, service principals, and cloud permissions. That means supplier risk reviews need to map not only software exposure but also who can mint trust inside downstream environments.

Cloud governance teams should assume that auditability degrades as soon as an attacker can act through a legitimate identity. The practical question is no longer whether access existed, but whether the organisation can still distinguish ordinary administration from attacker-driven trust changes.

For practitioners

• Audit cloud trust objects Inventory SAML signing certificates, service principals, OAuth applications, and delegated permissions across cloud tenants so that you can identify which identities can mint or validate trust at scale.
• Enforce Zero Standing Privilege Remove persistent elevated access and require Just In Time access that expires when the session ends, especially for administrators who can modify federation, certificates, or token issuance paths.
• Separate trust creation from routine administration Treat certificate addition, federation changes, and permission grants as high-risk events that should be reviewed outside normal operational workflows and correlated in SIEM.
• Continuously review cloud permissions Generate automated reports for account, group, and permission changes so that hidden privilege escalation is visible when service principals or mail-enabled applications gain unexpected scope.
• Require strong authentication on privileged accounts Use hardware-backed multi-factor authentication for all high-value administrative identities, including those used to manage cloud trust infrastructure and cross-domain access.

Key takeaways

• The incident shows that a supply chain foothold can quickly become an identity governance failure when trusted cloud accounts and certificates are available to abuse.
• The article describes attackers manipulating Azure Active Directory, creating accounts, and operating undetected for months, which shows how durable privileged access can be.
• Cloud teams need to govern service principals, federation trust, and JIT expiry as core controls, because that is where the attack expanded beyond the original compromise.

Key terms

• Privileged identity attack surface: The privileged identity attack surface is the total set of places where high-access identities can be created, used, exposed, or abused. It includes admin accounts, service accounts, tokens, keys, certificates, and delegated permissions across cloud, applications, endpoints, and automation. Reducing it means limiting privilege, shortening access duration, and monitoring every privileged action.
• Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.
• Federation Trust: A federation trust is a relationship that allows one identity provider or signing authority to assert identity for another system. In cloud environments, mismanaged trusts can become a high-value attack path because attackers may abuse certificates, tokens, or configuration changes to impersonate legitimate access.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen 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 building or maturing an IAM programme, it is worth exploring.