Martin's Blog

Epilogue: The Privilege Multiplier — Orion as LocalSystem

Ten chapters of sophistication: a build pipeline implant, a dormant gated backdoor, a DGA control plane, memory-only loaders, a bespoke Go RAT. One product decision materially increased the potential impact: SolarWinds documents its platform services as running under LocalSystem, and SUNBURST deliberately arms inside SolarWinds.BusinessLayerHost.exe.

This epilogue makes one argument carefully: a trusted management service running with a powerful token gave malicious code more useful capability than a least-privilege service would have. The sloppy version (“the backdoor stole everything”) is wrong; the defensible version is about exposure and potential reach, not demonstrated use at every installation.

The one process SUNBURST cares about

Recall the very first activation gate from Chapter 4. SUNBURST refuses to arm unless it is running inside one specific process:

if (GetHash(Process.GetCurrentProcess().ProcessName.ToLower()) != 17291806236368054941uL) return;
//  17291806236368054941  ->  solarwinds.businesslayerhost   (SolarWinds.BusinessLayerHost.exe)

The implant hashes its own host process name and bails out unless that hash is exactly the value that brute-forces back to solarwinds.businesslayerhost, the Orion “Module Engine” service. Several capabilities in Chapter 4, writing protected HKLM\SYSTEM keys, taking key ownership, disabling services, and rebooting, require a privileged token. The attacker chose a host intended to provide that context: not just any Orion process, but the Module Engine service.

What establishes LocalSystem and what does not

The conclusion has two different evidence layers, and they should not be conflated.

Product documentation establishes the default. SolarWinds’ platform requirements state that all SolarWinds services run under the LocalSystem account. That is external product documentation, not a finding recovered from these installers.

The decompiled artifacts establish intent to exploit a privileged token. SUNBURST contains operations that require administrator-equivalent rights and specific privileges:

// take OWNERSHIP of an HKLM key, requires SeTakeOwnershipPrivilege (SYSTEM/admin only)
key.OpenSubKey(subKey, RegistryKeyPermissionCheck.ReadWriteSubTree, RegistryRights.TakeOwnership);
registryKey.SetAccessControl(registrySecurity);                  // rewrite the key's ACL → FullControl
// → then HKLM\SYSTEM\CurrentControlSet\services\<svc>  Start = 4   (disable a security service, Ch.4 §4.4)

OpenProcessToken(GetCurrentProcess(), TokenAccessLevels.Query | TokenAccessLevels.AdjustPrivileges, …);
AdjustTokenPrivileges(TokenHandle, false, ref NewState, …);      // e.g. SeShutdownPrivilege for the Reboot job

Read what these request:

  1. RegistryRights.TakeOwnership on an HKLM\SYSTEM key: taking ownership of a protected system key requires SeTakeOwnershipPrivilege, which an ordinary low-privilege account does not hold. SUNBURST attempts this against security service registry keys.
  2. SetAccessControl(...) → rewrite the ACL to FullControl: after taking ownership, it attempts to rewrite the key’s permissions so it can modify the service.
  3. Start = 4 on HKLM\SYSTEM\CurrentControlSet\services\<svc>, disabling a defensive service across reboot (Chapter 4 §4.4), which depends on steps 1–2 succeeding.
  4. OpenProcessToken + AdjustTokenPrivileges: the implant adjusts its own token privileges (e.g. enabling SeShutdownPrivilege for the Reboot job). You can only adjust the privileges your token actually has.

These are not low-privilege operations. They show that SUNBURST was designed to benefit from an administrator-equivalent host token. They do not, by static presence alone, prove that each operation succeeded in a particular deployment or distinguish LocalSystem from another administrator-level service account. Nor did the examined MSI tables yield a demonstrated ServiceInstall row mapping BusinessLayerHost.exe to LocalSystem; generic WIX_ACCOUNT_LOCALSYSTEM strings are insufficient. The exact default account claim therefore rests on SolarWinds’ documentation, while the code independently confirms why privilege mattered.

Why SYSTEM, in this product, is uniquely dangerous

Two consequences compound, making the default a privilege multiplier.

SUNBURST carries no local privilege escalation exploit. It runs with whatever token the trusted Orion host already has. Under the documented default configuration, that means LocalSystem: no separate exploit is needed before the implant can attempt privileged local actions. The trust that made the supply chain work (Chapter 3) also delivered a powerful execution context.

And Orion is not just any SYSTEM service. A network monitoring and management platform exists, by definition, to:

So a privileged foothold on an Orion server is not merely access to an arbitrary Windows host. It places a management platform’s credential store and network connectivity within the operator’s potential reach. How much it exposes depends on each deployment’s monitored estate, stored credentials, segmentation, and configuration.

Provenance note. SolarWinds documents its platform services as running under LocalSystem. The decompiled implant confirms the host process gate and privileged primitives, but the examined installers do not independently prove the exact service account mapping. Orion’s credential storage and network reach are likewise documented product architecture, not findings derived from these binaries.

The discipline: exposure is not the same as use

Here is where most accounts overreach, and where this book will not. The temptation is to say “the backdoor ran as SYSTEM, so it looted the credential vault and spread everywhere.” It did not, and the decompiled evidence is explicit about it:

So the precise, defensible claim is about exposure, not use. The credential vault and the network reach mattered because they were reachable from a SYSTEM foothold, not because SUNBURST itself plundered them. SUNBURST is the first stage. What actually exploited the position was the hands-on second stage (Cobalt Strike via TEARDROP/RAINDROP, Chapter 6) and the operators behind it, stealing credentials, forging identity, moving laterally. The design didn’t hand the attacker loot; it handed them a platform whose stored access and network position could become useful to a hands-on operator, depending on the deployment.

That distinction is not pedantry. It is the difference between a claim the artifacts support and one they don’t, and it makes the indictment of the design stronger, not weaker. The problem was never that SUNBURST was a credential thief. The problem is that the product placed a SYSTEM-privileged, credential-holding, network-reaching service in the path of any code that compromised it, so that whoever eventually got hands-on (and someone did) started from the best possible position, for free.

The least-privilege counterfactual

Imagine the one change: the Module Engine runs not as LocalSystem but as a scoped, least-privilege service account with only the rights it genuinely needs. Walk the book back through that lens:

None of this would have stopped the supply-chain compromise itself; SUNSPOT would still have shipped a backdoor in a signed DLL. It would, however, have reduced the first-stage implant’s immediately available capabilities and forced the operator to obtain additional rights where deeper access was needed. That is a blast radius argument, not a claim that every potentially affected customer suffered a domain-wide compromise; public reporting puts known hands-on compromises at a much smaller number.

The lesson, and the close

The attacker’s sophistication got a backdoor into the build pipeline. The product’s privilege model increased what that backdoor could attempt immediately after execution. Those are two different security questions. The policy response in Chapter 10, secure build environments, identity hardening, and Zero Trust, addresses the same general problem: do not let one breached trust boundary automatically confer another.

There is a design principle buried in all of this, and it is the note to end on. A product trusted by everything must be built as though it will, someday, be the thing that is compromised. Orion was distributed to an upper bound population of roughly 18,000 potentially affected customers, and its services were documented to run at a powerful local privilege level. When that trust was abused, as trust eventually is, the privilege was already there, waiting, inherited for free by the first malicious code to ask for it. The supply-chain attack was the masterstroke. The LocalSystem default was a privilege multiplier that increased the potential blast radius.

Sources & evidence

↑ Revisiting the SolarWinds Compromise