One week ago, on December 8, FireEye disclosed that it had been breached by a sophisticated actor and that its red-team tools were taken. On Sunday, December 13, the other shoe dropped: the intrusion vector was a trojanized update to SolarWinds Orion — the network monitoring platform running inside a substantial fraction of enterprise and government networks — and FireEye was one victim among what SolarWinds' own SEC filing suggests could be up to 18,000 organizations that installed the poisoned builds. CISA issued Emergency Directive 21-01 the same night, ordering federal agencies to disconnect Orion. Microsoft published detection guidance and is calling the campaign Solorigate; FireEye calls the implant SUNBURST.
We have spent the week since Sunday doing what most infrastructure teams serving government and enterprise clients have been doing: establishing which estates run Orion, isolating what needed isolating, and — more importantly for a Microsoft-centric practice like ours — working through what this campaign's tradecraft means for the identity infrastructure we build and operate. Because the sobering part of the public reporting is not the supply-chain entry. It is what the actor did after landing: they went for the federation trust.
This post is our week-one field notes. It will be partially wrong in the ways all week-one notes are; the public picture is still developing daily. But the defensive priorities are already clear enough to act on, and waiting for the complete story is not a strategy.
What we know a week in, and what we did first
The facts as of today, December 15, from the FireEye analysis, Microsoft's guidance, and the SolarWinds advisory: Orion platform builds from versions 2019.4 HF5 through 2020.2.1 released between March and June 2020 contained a backdoored DLL, signed with SolarWinds' legitimate certificate, delivered through the vendor's own update channel. The implant slept for up to two weeks, then used steganographic C2 traffic disguised as Orion's own telemetry. This was patient, disciplined tradecraft aimed at a carefully chosen point of maximum trust: a monitoring platform that, by design, holds privileged credentials to everything it watches.
Our first 72 hours across client estates, in order:
- Inventory, not assumption. Which estates have Orion, at which build. Software inventory from SCCM answered this in hours; the estates without current inventory took days — a lesson in itself.
- Isolate first, investigate second. Affected builds got network isolation per the CISA directive logic — Orion servers talk to everything, so a compromised one cannot be triaged in place. Snapshot, isolate, preserve logs.
- Rotate what Orion could see. Every credential stored in a potentially affected Orion instance — SNMP strings, WMI service accounts, network device logins — is treated as exposed. This is the painful, unglamorous bulk of the response, and there is no shortcut.
- Then start the identity hunt, which is the rest of this post.
Most of our managed estates monitor with SCOM rather than Orion, which spared us the worst of step three. That is luck, not virtue. The same supply-chain logic applies to every agent we deploy with system privileges — a point we return to below.
Why this is a Microsoft-estate problem, not a SolarWinds problem
If your organization does not run Orion, the temptation is to file this week under someone else's incident. Resist it. The publicly documented post-compromise activity is a playbook aimed squarely at hybrid Microsoft identity, and it works regardless of how the actor gets in:
- Steal or misuse the ADFS token-signing certificate, then forge SAML tokens for any user, with any claims, for any relying party that trusts the federation — including Azure AD and therefore Microsoft 365. This is the Golden SAML technique, described publicly by CyberArk back in 2017 and now observed in anger at scale.
- Modify federation trust settings — adding rogue token-signing certificates or altering domain federation configuration — so access survives credential resets.
- Add credentials to existing OAuth applications and service principals in Azure AD, creating durable API access that looks like a legitimate application and bypasses interactive sign-in controls entirely, including MFA.
Read that list again with an operator's eye. None of it requires SolarWinds. All of it requires what most hybrid estates have: an ADFS farm whose token-signing key is, in practice, guarded like an application secret rather than like the domain-admin-equivalent it is; and an Azure AD application landscape nobody has reviewed since it accreted.
Forged SAML tokens are particularly ugly to detect because the authentication is valid — correctly signed by the trusted certificate. Your controls at the credential layer, MFA included, never see it. Detection has to move to anomalies: tokens with unusual lifetimes, SAML assertions for accounts that never touched ADFS, sign-ins from infrastructure that skipped the expected on-prem authentication events.
What we audited across client estates this week
The concrete sweep we ran, and recommend running, on every hybrid estate — Orion or no Orion:
Federation configuration integrity. Enumerate every federated domain and verify the token-signing certificates match what your ADFS farm actually holds. Get-MsolDomainFederationSettings against each domain; on the farm, Get-AdfsCertificate -CertificateType Token-Signing. Any certificate you cannot account for, any domain federated to infrastructure you do not recognize, is an incident, not a finding. We also pulled the Azure AD audit log for any recent set-federation events — that operation should be rare enough to explain each occurrence by name and change ticket.
Service principal and OAuth app credentials. Enumerate credentials on service principals and app registrations, sorted by creation date. Newly added secrets or certificates on long-established apps — especially apps with Mail.Read, Directory-level, or EWS permissions — got a same-day phone call. On one estate we found four service principals with credentials nobody could attribute; all four turned out to be legitimate but undocumented, which took two days to prove. That cost is the price of years of ungoverned app consent, now due.
Privileged access review. Every Global Admin, every Application Administrator (a role that can add credentials to apps — treat it as tier-0), every AD account in the ADFS service and management path. Stale privileged accounts were disabled this week, not scheduled for cleanup.
ADFS server posture. Who can log on to the federation servers, where the DKM container's access list stands, whether the token-signing certificate has ever left the farm in an export. Most estates could not answer the last question with evidence. That silence is itself the finding.
Sign-in telemetry. Hunting for the patterns Microsoft's guidance describes: anomalous token lifetimes, sign-ins asserting MFA from unfamiliar infrastructure, mailbox access by applications rather than users.
Hardening that outlives this incident
Week-one response is triage. The durable work, which we are now scheduling into Q1 for every estate we manage:
- Treat the ADFS farm as tier-0 or leave. Same protection scope as domain controllers — restricted logon, dedicated patching, no co-tenanting with utility workloads. Better: for every client where our pass-through authentication decision tree already pointed away from ADFS, this is the quarter to finally decommission the farm. You cannot lose a token-signing certificate you do not have.
- Rotate token-signing certificates deliberately, with a documented procedure, so that an emergency rotation under incident conditions is a rehearsed act rather than a first attempt. If compromise is suspected, rotation must be done twice in immediate succession to invalidate cached material.
- Govern application consent. Admin-consent workflows, a review cadence for service principal credentials, alerts on credential additions to privileged apps. The app layer is now a first-class attack surface; most tenants govern it like a junk drawer.
- Audit your own supply chain honestly. Every monitoring agent, every RMM tool, every appliance with a privileged service account is an Orion-shaped trust decision. The question is not whether to trust vendors — we all must — but whether you know what each trusted component can reach, and whether you would detect it behaving out of character. Network egress control and baselining for management infrastructure moved several places up our standard architecture this week.
We hold no illusions that a determined nation-state actor is stopped by a hardening checklist. The defensive goal is narrower and achievable: raise the cost, shrink the blast radius, and make the identity layer — the layer this campaign has put beyond argument — auditable enough that you can answer "are we affected?" with evidence instead of hope.
If you're facing this
If your estate runs Orion, or runs ADFS, or simply cannot currently prove the integrity of its federation trust and application credentials, this is the week to close that gap — calmly, methodically, and with findings documented as you go. We are running these identity-layer sweeps for clients now and can help you scope one, or sanity-check the one you have already started. Get in touch; this is not a season for working from assumptions.