APT29 gained its initial foothold at SolarWinds through password spraying against weak administrative accounts. Once inside the build environment, the group inserted the SUNBURST implant into signed Orion updates that thousands of customers then deployed. The real damage occurred later, when the attackers located SAML signing certificates in victim networks and used those keys to issue forged assertions that granted access across entire federated environments.
How Password Spraying Opened the Vendor
Public disclosures confirm APT29 began with ordinary credential attacks against SolarWinds infrastructure. No device-bound proof was required, so the first valid login gave the attackers a persistent position inside the software supply chain. From that position they reached the Orion build system and tampered with updates that carried SolarWinds’ legitimate digital signature.
How Stolen SAML Keys Removed Any Need for Login
After SUNBURST executed inside customer networks, APT29 hunted for Active Directory Federation Services or Azure AD instances. In several environments the group extracted the private key used to sign SAML assertions. With that key the attackers could mint valid tokens for any user or service without ever presenting a password, OTP, or push notification.
Because the forged assertion arrived already signed, services treated it as proof that authentication had succeeded. No second factor was requested. The theft happened after prior administrative access had already been obtained, so the signing material lived in memory or on disk outside the scope of any login control.
Why Federation Tokens Gave the Attack Its Reach
Customers using SSO with SAML faced an immediate expansion of access. One compromised signing key unlocked every connected application—email, cloud consoles, internal tools—without additional interaction. The same pattern appeared across both government and commercial tenants.
Server-side extraction of federation keys sits outside what login factors can block. The certificate theft presupposed the attacker already possessed administrative rights on the identity provider. Device-bound credentials would have altered the earlier stages: they would have blocked the password-spraying entry at SolarWinds and raised the bar for the lateral movement required to reach signing material inside customer environments.
The same playbook hit multiple organizations before and after SolarWinds. A full examination of why only hardware-bound signatures close both the initial access and token-reuse paths appears at mfa2point0.com.
FAQ
Could stronger passwords at SolarWinds have stopped the whole chain?
Stronger passwords would have made the initial spraying campaign harder, yet they would not have prevented later extraction of SAML signing keys once attackers already held administrative access inside victim networks.
Did SUNBURST itself exfiltrate the high-value data?
Most sensitive access occurred after forged SAML assertions were accepted. The implant primarily delivered persistence and reconnaissance; the stolen federation keys performed the actual authorization abuse.
Why did MFA prompts never appear during the SAML abuse phase?
Forged assertions bypass the login flow. Services accepted the signed token as evidence that authentication had already occurred, so no interactive factor was ever challenged.
Would device-bound credentials have changed SolarWinds customer outcomes?
They would have stopped the password-spraying entry at the vendor and made it substantially harder for the same actors to obtain the administrative rights needed to locate and steal SAML keys inside downstream environments.
