Deconstructing the SUNBURST C2 Protocol

Introduction

The SUNBURST incident represents a watershed moment in the history of supply-chain attacks. Executed by a highly sophisticated threat actor - variously tracked as APT29, UNC2452, NOBELIUM, or StellarParticle - the campaign demonstrated an unparalleled level of patience, operational security (OPSEC), and technical tradecraft.

This guide provides a technical deconstruction of the SUNBURST C2 protocol, intended not as a historical recounting but as a granular analysis for red team practitioners. The primary focus is on the C2 lifecycle, from its initial anti-analysis checks and DNS-based state management to its interactive HTTP communications and second-stage payload delivery.

The protocol’s design reveals a strategic prioritization of stealth and infrastructure longevity over speed, offering amazing insights into the development of resilient and low-observability offensive tooling.

Pre-Communication Phase: Anti-Analysis and Evasion Framework

Before initiating any network communications, the SUNBURST implant executes an exhaustive series of “pre-flight” checks. This is a critical component of its stealth, designed to meticulously filter out analysis environments, security applications, and non-viable targets, thereby protecting the C2 infrastructure from premature discovery and analysis.

Initial Dormancy and Time-Based Evasion

A hallmark of the SUNBURST implant is its extreme patience. The malware enforces a mandatory dormancy period, remaining completely inert for a randomized interval of 12 to 14 days following the last write-time of the trojanized DLL that provides initial access.

This long delay is a deliberate and highly effective tactic to defeat automated sandbox analysis, which typically executes samples for only a few minutes. It also serves to decouple the eventual malicious network activity from the initial software update event, significantly complicating incident response timelines and forensic analysis.

If any of the initial environmental checks fail, the implant does not terminate immediately but instead leverages the host’s own scheduling mechanisms. It will delay its execution for another random interval and re-attempt its checks the next time it is invoked by a legitimate, recurring background task within the SolarWinds Orion framework.

To prevent multiple instances of the backdoor from running simultaneously and generating duplicative network traffic, the implant creates a named pipe with the hardcoded value 583da945-62af-10e8-4902-a8f205c72b2e as a mutex. If this named pipe already exists, the new instance terminates.

Environmental and Process-Based Checks

The implant’s logic assumes a hostile environment until proven otherwise, conducting a battery of checks to validate its target.

Host Process Verification

The malware first verifies that it is running within the intended solarwinds.businesslayerhost.exe process. To evade simple string-based detection, this check is performed by comparing a custom hash of the running process name against a hardcoded value. The hash is calculated using a standard 64-bit FNV-1a algorithm with an additional, non-standard XOR operation, forcing analysts to develop custom tools to reverse it.

Blocklisting of Security and Analysis Tools

SUNBURST enumerates all running processes, loaded drivers, and active services. It calculates the same custom FNV-1a + XOR hash for each and compares them against extensive, hardcoded blocklists of common security products, forensic tools, and virtualization software.

If a blocklisted process (e.g.,wireshark.exe) or driver is found, the implant enters a dormant state and retries its checks later.

More aggressively, if a blocklisted service (e.g., Windows Defender) is detected, the malware attempts to disable it by setting its start type in the registry to SERVICE_DISABLED (HKLM\SYSTEM\CurrentControlSet\services\<service_name>\Start to 4) before going dormant.

Target Environment Vetting

The implant performs several checks to ensure it is on a legitimate enterprise target. It confirms that the machine is joined to an Active Directory domain; if not, it terminates execution. It then compares the AD domain name against a hardcoded blocklist of domains believed to be associated with SolarWinds’ internal development and testing environments (e.g.,swdev.local, test.solarwinds) to prevent self-compromise.

Connectivity Check

As a final step before beaconing, the implant performs a simple DNS resolution for api.solarwinds.com to confirm internet connectivity. If this fails, it remains dormant and retries later.

Review

The extensive nature of these checks demonstrates a clear strategy: the C2 infrastructure is a high-value asset, and the implant will only risk exposing it if it has a high degree of confidence that the target is both interesting (a real corporate network) and safe (not an analysis environment).

DNS as a State-Driven C2 Channel

After passing all pre-flight checks, SUNBURST initiates its first stage of C2 communication. This stage utilizes DNS as a low-bandwidth, high-stealth channel for victim identification and state management, allowing the attackers to triage victims without direct interaction.

The Domain Generation Algorithm (DGA)

Unlike traditional DGAs that generate pseudo-random domains, SUNBURST’s algorithm generates a unique but static subdomain for each victim that encodes specific host identifiers.

UserID Generation

A unique UserID is computed by taking the MD5 hash of a concatenated string containing the MAC address of the first operational network interface, the machine’s Active Directory domain name, and the content of the MachineGuid registry value located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography.

FQDN Construction

This UserID and the AD domain name are then encoded using a custom algorithm involving a substitution table and XOR operations to form a unique subdomain string. This victim-specific subdomain is prepended to one of four hardcoded parent domains, selected randomly, to form the final fully qualified domain name (FQDN) for the DNS query:

• [dga_subdomain].appsync-api.eu-west-1.avsvmcloud[.]com
• [dga_subdomain].appsync-api.us-west-2.avsvmcloud[.]com
• [dga_subdomain].appsync-api.us-east-1.avsvmcloud[.]com
• [dga_subdomain].appsync-api.us-east-2.avsvmcloud[.]com

This design provides a powerful, asynchronous method for victim vetting. The attackers only needed to monitor the incoming DNS queries to their authoritative server for avsvmcloud[.]com. By decoding the subdomains, they could collect intelligence on every infected host and decide which ones were of interest without ever sending a packet back, beyond a standard DNS response.

DNS Beaconing and Jitter

The malware initiates DNS queries for its generated FQDN, which serve as the primary “check-in” (heartbeat) beacon. To evade detection algorithms that rely on identifying periodic network traffic, SUNBURST introduces significant, randomized delays (jitter) between these beaconing attempts. The sleep intervals between DNS queries could be as long as nine hours, making the traffic appear sporadic and unrelated.

C2 Control via DNS Responses: A Protocol State Machine

The core of the First Stage C2 is a state machine controlled entirely by the content of the DNS response, particularly the IP address returned in the A record. The implant contains hardcoded lists of IP address blocks and classifies the response IP into different “families,” each triggering a different action. This effectively turns the attacker’s DNS zone file into a remote control for the malware.

Killswitch

If the resolved IP address falls within private IP ranges (RFC 1918), specific reserved blocks, or certain public blocks including 20.140.0.0/15 (owned by Microsoft), the implant executes a killswitch. It permanently disables itself by writing the value 3 to the ReportWatcherRetry configuration key and terminates all malicious activity.

Passive Mode

If the IP falls within a different set of predefined public ranges, it signals to the agent to stay in “passive mode”. In other words, it’s the server telling the agent it does not have any job for it. Nothing will happen until the next agent check-in.

Active Mode Transition

A precise, two-step sequence is required to escalate to the interactive HTTP C2 stage. First, the implant must receive a DNS A record resolving to an IP within a specific “pre-activation” subnet (e.g., 184.72.0.0/15). Immediately following this, the next DNS response for the same FQDN must contain a CNAME record. This CNAME record points to the domain of the second-stage C2 server. If this exact sequence is not observed, the CNAME is ignored as an error, preventing accidental activation.

Configuration Extraction

The least-significant bytes of the IP address from the pre-activation A record are parsed by the implant to extract configuration data for the Stage 2 HTTP C2, such as which proxy method to use and the initial sleep delay value.

Stage 2: The Interactive HTTP/S C2 Protocol

Once the agent has received the signal to transition to active mode, it transitions to a more traditional HTTP/S interactive C2 channel. Since this mode also represents a higher degree of risk of being discovered it was reserved for intentional moments of hands-on-keyboard activity on high-value + vetted target systems.

Activation and Second-Stage Infrastructure

As already mentioned above, the transition to Stage 2 is triggered by the specific DNS A record and CNAME response sequence. The domain provided in the CNAME record becomes the base URI for all subsequent HTTP/S communications, effectively handing the implant off to a new C2 server. This second-stage infrastructure was deliberately segregated from the primary avsvmcloud[.]com DNS server. Analysis revealed that the threat actors utilized a diverse set of virtual private servers (VPSs), often geolocated within the victim’s own country to make the C2 traffic appear as domestic network activity.

The attackers demonstrated exceptional infrastructure OPSEC. Instead of using newly registered domains, which are often flagged by security tools, they acquired aged domains with pre-existing registration histories, likely from auctions or after expiration. This allowed the domains to bypass reputation-based filters. Analysis by Volexity identified a unique, non-standard HTTP header order on these C2 servers, suggesting custom server-side configurations designed to be difficult to fingerprint and to distinguish from standard web servers like IIS.

Masquerading as Orion Improvement Program (OIP) Traffic

A core design principle of the Stage 2 C2 was to blend in with legitimate SolarWinds network traffic by mimicking the Orion Improvement Program (OIP) protocol, a telemetry feature within the Orion software. Since OIP is a proprietary, low-profile, and poorly documented protocol, defenders lack the baselines and tooling (e.g., specific IDS rules or protocol dissectors) to easily distinguish malicious traffic from benign application telemetry.

URI Generation

The malware constructs benign-looking URIs by randomly combining hardcoded path fragments. Observed patterns include /swip/upd/, /swip/Events, and /swip/Upload.ashx, which are often appended with legitimate-looking SolarWinds filenames like Orion.Wireless.xml to complete the disguise.

HTTP Body Structure

All C2 communications are encapsulated within a JSON structure to further mimic legitimate API traffic. This JSON payload includes fields such as userID and sessionID, along with a steps array populated with plausible but fabricated event data to make the traffic appear as authentic telemetry.

HTTP Method Selection

The choice of HTTP method is dictated by the direction and size of the data transfer. GET or HEAD requests are used to fetch commands from the C2 server. To send data back to the C2, PUT or POST requests are used. Specifically, PUT is used for payloads smaller than 10,000 bytes, while POST is used for larger payloads, a clear indicator of data exfiltration activity.

Command and Control “Jobs”

The C2 server issues commands, referred to internally as “Jobs,” which are parsed from the body of the HTTP response. The response payload containing the command is typically compressed and encrypted with a simple XOR cipher. The backdoor supports a comprehensive set of commands that provide the operator with full remote access and control over the compromised system.

Data Exfiltration

Data exfiltration was also performed using the Stage 2 interactive HTTP/S C2 protocol.

Data Staging and Preparation

While specific on-host staging directories are not explicitly detailed in public reporting, the implant’s command set strongly implies a standard operator workflow. An attacker would use commands like GetFileSystemEntries and RunTask to perform reconnaissance, collect target files, and package them for exfiltration, likely into a single archive.

In a further act of blending in, the malware was observed storing its own reconnaissance results within legitimate SolarWinds plugin configuration files, intermixing its operational artifacts with benign application data on the disk.

Compression and Encoding

To minimize the size of outbound data and to obfuscate its contents from network inspection, SUNBURST employed multiple layers of compression + encoding.

Data payloads were first compressed using the DEFLATE algorithm.

Following compression, the data was encoded in two stages. First using a custom XOR routine, which was then followed by standard Base64 encoding. This layering ensured that even if the traffic were intercepted, the content would not be immediately human-readable.

Exfiltration via HTTP POST

The compressed + double-encoded data was exfiltrated using HTTP POST requests. This method was specifically chosen for payloads larger than 10,000 bytes, indicating its intended use for bulk data transfer. The data was embedded within the same JSON structure used for normal C2 communications, masquerading as OIP event data to maintain the illusion of legitimate telemetry.

These POST requests were sent to the same pseudo-random URIs on the Stage 2 C2 server that were used for command polling. By reusing the established C2 channel, the exfiltration traffic benefited from the same masquerading techniques and trusted infrastructure, avoiding the creation of new, potentially suspicious network connections that could be flagged by defenders.

Post-Exploitation: Second-Stage Payload Delivery via TEARDROP

For select, high-value targets, the SUNBURST backdoor served as a stealthy delivery mechanism for a more powerful second-stage payload. This graduated approach allowed the attackers to reserve their most capable (and potentially more detectable) tools for environments where the potential reward justified the increased risk.

TEARDROP: A Memory-Only Dropper

On certain compromised systems, the attackers used SUNBURST to deploy a previously unseen, memory-only dropper named TEARDROP. The sole purpose of TEARDROP was to act as a loader for a customized Cobalt Strike BEACON implant, giving the attackers a fully interactive, hands-on-keyboard presence on the target machine.

Deployment and Execution Chain

The attackers went to extraordinary lengths to decouple the execution of the Cobalt Strike BEACON from the SolarWinds process, thereby breaking the chain of process ancestry that security tools often use for detection.

1. SUNBURST would first drop two files onto the system: a VBScript and the TEARDROP DLL. Both were given inconspicuous names designed to blend in with legitimate system files.
2. Next, the malware abused the Image File Execution Options (IFEO) feature in Windows. It created a “Debugger” registry key for a common system process, dllhost.exe, and set its value to wscript.exe.
3. The next time the operating system legitimately launched dllhost.exe for any reason, the IFEO key would intercept the execution and instead run the dropped VBScript via wscript.exe.
4. The VBScript, in turn, would execute the TEARDROP DLL using rundll32.exe. This convoluted execution chain resulted in a clean process tree (svchost.exe -> dllhost.exe -> wscript.exe -> rundll32.exe), completely detached from the initial SolarWinds.BusinessLayerHost.exe process.
5. Finally, TEARDROP would execute entirely in memory. It read an embedded payload from a file with a fake .jpg extension, decoded it using a custom rolling XOR algorithm, and manually loaded the Cobalt Strike BEACON into memory.

TEARDROP/BEACON C2 Infrastructure

The Cobalt Strike BEACONs deployed by TEARDROP communicated with their own, entirely separate C2 infrastructure, which was even more segregated than the Stage 2 SUNBURST servers.

The operational security was meticulous: every single compromised host received a BEACON implant with a unique C2 domain, a unique watermark ID, a unique User-Agent string, and a unique profile for sleep/jitter times and HTTP transaction patterns.

This extreme level of segregation was a deliberate tactic to thwart threat intelligence sharing. The discovery and analysis of one BEACON implant would provide defenders with zero actionable indicators to detect or block C2 communications on any other compromised host.

Conclusion: Implications for Red Team C2 Design

The SUNBURST C2 protocol was not merely a collection of clever techniques but a meticulously designed and considered system rooted in the core principles of high-assurance operational security. Nothing is assumed, every step forward is measured - no additional risk is ever assumed without some level of assurance regarding the value + safety of the target in question.

I hope his deconstruction serves as an insightful case study illuminating “nation state level” design principles for red team + offensive tooling devs. Before ending, I think it’s useful to synthesize the main insights, so we can reinforce these strategic principles that may help inform our design of modern offensive tooling.

Patience and Low-Observability The campaign’s success was built on a foundation of extreme patience. The multi-week initial dormancy period and the low-and-slow DNS beaconing with heavy, randomized jitter are paramount for evading both automated and human analysis.

Layered and Asynchronous Vetting The two-stage C2 architecture, which uses DNS as a passive, one-way channel for victim vetting before activating a high-interaction HTTP channel, is a powerful model for protecting high-value C2 assets. It allows for mass reconnaissance with minimal risk.

Protocol Masquerading and Environmental Blending Mimicking an obscure, legitimate, and environment-specific application protocol (like OIP) is a far superior evasion technique than using generic, heavily scrutinized protocols like standard HTTPS. The goal is to become indistinguishable from the target network’s background noise.

Infrastructure Compartmentalization The use of layered and progressively unique C2 infrastructure - from a shared Stage 1 DNS server to semi-shared Stage 2 CNAMEs to unique Stage 3 Cobalt Strike BEACON C2s - ensures that the discovery of one part of the infrastructure does not compromise the entire operation.

Graduated Capability Deployment Implants should be deployed in stages. A custom, wide-net “scout” implant should be used for initial access and automated reconnaissance, reserving more feature-rich and potentially higher-risk tools like Cobalt Strike for pre-vetted, high-value systems.

|TOC| |PREV| |NEXT|