How can security teams detect SUNBURST?

What to look for in endpoint and network telemetry

Detection works best when teams stop treating SUNBURST as a single signature problem and instead look for a chain of small anomalies. The earliest signals usually sit in the software trust path, then appear as unusual DNS activity, rare outbound connections, and trusted hosts beginning to behave like staging points. That pattern is easier to see when endpoint, DNS, proxy, and identity telemetry are reviewed together.

Because the backdoor lived inside a trusted update path, one useful question is whether the update mechanism behaved like it normally does. Suspicious indicators include rare parent-child process relationships, unexpected child processes from update services, abnormal service execution timing, and tampering with monitoring or security tools. A good hunt hypothesis is not “did the host get compromised?” but “did a trusted process start doing things it should never do?”

For a practical search, compare high-value servers against peers of the same role and software version. Look for domain lookups that do not fit the environment, especially if they are rare, newly seen, or clustered around a small set of hosts. If the environment has strong baselines, deviations from normal software update behavior are often more useful than a fixed IOC list because the campaign was designed to blend into trusted activity.

Why lateral movement matters after the first callback

SUNBURST detection does not end at the initial callback. Once a trusted system becomes the foothold, attackers often move into later-stage activity that looks more like internal administration than malware. That means defenders need to watch for remote execution, service creation, unusual authentication patterns, and signs that a benign-looking host is being used to reach other systems.

The most important shift is to treat post-compromise identity behavior as part of the detection problem. If a system that normally performs limited duties suddenly authenticates to many destinations, uses unusual service principals, or accesses administrative interfaces it never needed before, that can be the bridge from initial compromise to broader intrusion. Trusted hosts are especially dangerous because their activity may be allowed by default unless it is explicitly bounded and monitored.

Correlating this stage with DNS and proxy data helps separate normal enterprise chatter from attacker-driven staging. A callback to a rare external domain may be the first clue, but later use of internal tools, scheduled tasks, or remote access paths is what often confirms that the compromise has progressed beyond beaconing. The key is to follow the trusted path after the first suspicious signal, not just the outbound connection itself.

How to confirm, triage, and contain suspected SUNBURST activity

Confirmation usually comes from correlation, not from one log source. If endpoint telemetry suggests suspicious process behavior, validate it against DNS, proxy, authentication, and security-tool logs to determine whether the host also showed persistence, unusual access, or defense tampering. A single odd event may be noise; the combination of trust-path anomalies, callback behavior, and later-stage movement is what raises confidence.

Containment should focus on the systems that can still abuse trust, not only the one that first showed the alert. That means isolating suspicious hosts, preserving volatile evidence, and reviewing whether certificates, tokens, sessions, or service accounts used on those systems may need rotation or revocation. If security tools were tampered with, assume visibility gaps until logging is restored and verified.

The investigation should also answer a narrower question: did the attacker only use the host as a beacon, or did they use it to establish durable access? If you find signs of staged access, treat the incident as a broader identity and lateral-movement problem, not just a malware cleanup exercise. The most reliable closeout condition is evidence that the callback path, internal propagation path, and any abused credentials have all been addressed.

Risk and Threat Considerations

SUNBURST is dangerous because it abuses trust before defenders realise there is a problem. A compromised software update or signing path can make malicious activity look legitimate, which delays detection and gives the attacker time to stage access, move laterally, and suppress telemetry.

Failure mechanism: The compromise blends into normal update, DNS, and administrative traffic, so defenders see isolated anomalies rather than an obvious intrusion chain.

Impact: Detection latency increases, trusted systems become propagation points, and the incident can expand from one compromised host into broader internal access and monitoring loss.

Practitioner Guidance

What to prioritise: Start with hosts that sit on the software trust path or have high internal reach, because those are the systems most likely to show both the initial beaconing and the follow-on movement. If the environment has a known-good baseline, compare against that first rather than chasing generic indicators.

What to verify: Confirm whether suspicious processes, DNS lookups, and outbound connections line up on the same host and time window. If the host also shows security tool interference or unexpected authentication, treat the case as active compromise until proven otherwise.

Practitioner takeaway: The best SUNBURST hunts look for a sequence, not a single alert, because the campaign’s value came from trusted execution plus staged follow-on activity.

Related resources from NHI Mgmt Group

• Guide: Malware Guide
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?