The monitoring platform was already trusted
FireEye's 13 December 2020 disclosure described SUNBURST inside trojanised SolarWinds Orion software updates. The software arrived through a channel customers expected to use for legitimate maintenance. Its position in a management environment made the incident more consequential than the discovery of an unfamiliar executable on an ordinary endpoint.
CISA issued Emergency Directive 21-01 that day. Subsequent guidance distinguished affected Orion releases from releases not identified as containing the backdoor and set conditions for federal agencies' continued use. Those historical requirements applied to the directive's audience; they are evidence of the response, not a current universal instruction for every organisation.
The useful architecture question is why a management application has the authority it holds, and how that authority can be replaced if the application's integrity becomes uncertain.
Four things a trusted update does not prove
A recognised download location establishes a distribution route. A valid signature can establish an authenticated signer and integrity relative to the signed artefact. An approved package establishes that an organisation accepted a release. None of those facts, alone, establishes that every action the installed software performs is benign.
This is not an argument to abandon signing or managed updates. It is an argument to keep additional boundaries after installation: constrained service identities, controlled outbound access, evidence about privileged actions and a recovery plan for the management system itself.
| Management-plane property | Question to put to the service owner |
|---|---|
| Credentials | Which secrets can the service read, and where are they accepted? |
| Reachability | Which network and cloud endpoints can it contact? |
| Administrative actions | What changes can it make without another decision? |
| Evidence | Are its actions visible somewhere it cannot rewrite? |
| Replacement | How would its authority be revoked and re-established? |
These questions apply to monitoring, backup, orchestration and remote support. The answers need not be identical for every platform, but an unknown answer represents an operational dependency.
Separate receiving the release from follow-on compromise
The presence of an affected artefact supports one finding. Evidence of activation, communication or additional attacker activity supports others. Reporting every installation as a fully developed intrusion erases distinctions that responders need for prioritisation.
Build a timeline from the records available in the environment: release installation, process execution, relevant network activity and identity events. Retain uncertainty where logs have expired. An absence of evidence in a source that did not retain the required period cannot establish that an action never happened.
When reviewing identities, look beyond the account running the service. Identify credentials it could access and integrations it could invoke. The assessment must follow the authority available in that deployment; broad claims about every Orion installation are less useful than this local map.
Rebuild from a position that can be trusted
Build a service-identity inventory without running the application
On a supported Windows host, the following query reads registered service configuration:
Get-CimInstance Win32_Service |
Select-Object Name, StartName, PathName
The output can help an authorised administrator connect a service to its configured account and executable path. It is not proof that a named binary is the file that previously ran, that the account has only the expected privileges, or that every relevant workload is registered as a Windows service.
Review the result inside the organisation. Service paths and account names can reveal infrastructure details and should not be copied wholesale into a public advisory. Select the records relevant to the management platform, then join them to directory privileges and documented integrations.
That joined record gives the response team a useful starting question: if this service identity becomes untrusted, which systems and jobs lose functionality when it is revoked? An application inventory without account reach cannot answer it.
Keep distribution evidence and execution evidence separate
Preserve the release identifier or installer digest that establishes what was delivered. Keep the endpoint and network observations used to establish what ran as separate records. This separation makes it possible to revise an execution assessment without silently changing the original artefact finding.
For an incident manager, the resulting populations may include delivered-but-not-observed, observed-executing and confirmed-follow-on activity. Those labels describe evidence coverage; they should not be presented as confidence-free estimates of the entire affected population.
The same distinction helps suppliers communicate. A release withdrawal can define an artefact cohort while investigations continue into actual execution and downstream access. Customers need both the immediate distribution decision and the conditions under which the broader assessment will change.
Removing an affected application may be a containment action. It does not independently resolve the state of identities or systems that application could reach. Establish the recovery environment and evidence requirements before reconnecting a replacement to the same privileges.
An exercise can test this without malware. Temporarily designate a synthetic management identity as untrusted, then ask the team to enumerate its dependencies and demonstrate a controlled replacement. Record where revocation would interrupt backups, monitoring or deployments. Those service impacts should be understood before an incident forces the decision.
The 3CX investigation later described one software supply-chain compromise leading into another vendor's build environment. The xz case concerned malicious release and build material. Each weakens the assumption that a familiar delivery route removes the need to understand downstream authority, but the evidence and affected artefacts differ.
The most useful management-platform inventory therefore records more than product and version. It should show privileges, connected identities, outbound paths and the independent records that could establish what happened. That is the difference between locating the software and being able to respond to its compromise.