Understanding the Sunburst Backdoor: In-Depth Analysis of its Role in the SolarWinds Attack

Part 2 Overview of the Sunburst Backdoor

• Sunburst Design Concept and Workflow Diagram

As customary, we begin with an illustration by ABC_123 depicting the design concept and workflow diagram of the Sunburst backdoor used during the SolarWinds supply chain attack. This diagram is synthesized from numerous Sunburst backdoor sample analysis articles, and based on this diagram, we will detail the entire operation process of the backdoor.

How the Sunburst backdoor was compiled into Orion software is covered in detail in the previous article and won’t be reiterated here. Sunburst carried a legitimate SolarWinds digital signature, providing a built-in whitelist effect to effectively bypass various security measures. Ultimately, the DLL file was packaged in the update patches of the Orion network management software, and the installation of this patch by the victim triggers the Sunburst backdoor, though it is not immediately executed. It undergoes a series of complex initial condition checks to determine if the environment is a real victim computer and to check for antivirus protection and valid parent processes, among other criteria.

• Three States of the Sunburst Backdoor

The Sunburst backdoor reads the value of ReportWatcherRetry from the XML configuration file in SolarWinds’ Orion software to decide whether to continue running; it will only proceed if the value is not 3.

The ReportWatcherRetry value from the XML configuration file returns values of 3, 4, or 5, corresponding to three persistence states: Truncate, New, and Append. The default value is 4 (New). 4 (New) indicates the backdoor is running for the first time, 5 (Append) tells the backdoor it has run previously but exited due to predefined conditions (such as active antivirus software), and 3 (Truncate) signifies the backdoor should immediately cease execution.

Part 3 Eight Prerequisite Conditions for Backdoor Activation

Note: During the execution of condition checks, the Sunburst backdoor frequently uses the method OrionImprovementBusinessLayer.DelayMin() to randomly sleep/delay for 30-120 minutes, slowing down the execution speed of the code. This tactic reduces the likelihood of detection by automated analytical protection software.

1 Ensure Unique Instance Execution

The isAlive method in C# code is used to determine this.

2 Parent Process Validation

By calculating the hash of the parent process name, it checks whether the running process is SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe, using a custom hash algorithm. This step evades sandbox detection or debugging tools, preventing sandbox automation and analysis by security personnel.

3 Run after Waiting for 10 Days

The backdoor randomly sets activation timing, awaiting 12 to 14 days to gradually trigger its malicious code. This approach aims to gradually bring the controlled servers of over 18,000 Orion software users online, thus avoiding alerts from network monitoring devices due to a surge in connections, which could expose the operation. Many organizations also clear logs after 7 days, so a lengthy wait can also reduce log records.

4 Create Named Pipe to Prevent Multiple Instances

The backdoor creates a named pipe with the identifier 583da945-62af-10e8-4902-a8f205c72b2e to prevent multiple instances from running.

5 Check Configuration File Status Parameter

It checks the value of ReportWatcherRetry in the XML configuration file to ascertain the current state of the Sunburst backdoor; it continues execution if in a New or Append state.

6 Local Domain Blacklist Check

1. It retrieves the AD domain and uses hash and regex checks to see if it’s on a blacklist, such as swdev.local, swdev.dmz, or saas.swi, where “swi” indicates “SolarWinds Internal” and “swdev” denotes “SolarWinds Developed.” 2. It must not contain the keyword “solarwinds.” 3. The domain name must not match the regex (?i)([^a-z]|^)(test)([^a-z]|$), essentially ruling out test environment domains.

7 Check for Antivirus Processes, Services, and Drivers

1. Process Blacklist Check

The SearchAssemblies method checks for processes on a blacklist, including the existence of processes like Windbg, Winhex, Autoruns, Wireshark, dnSpy, apimonitor-x64, fiddler, idaq64, ollydbg, procdump64, x64dbg, etc.

2. Service Blacklist Check

The SearchServices method detects blacklist service names such as Windows Defender, Carbon Black, Crowdstrike Falcon, FireEye – EDR, among others. If these are detected, Sunburst disables the services through registry modifications.

3. Security Software Driver Blacklist Check

The SearchConfigurations method uses WMI queries with Select * From Win32_SystemDriver to check for driver blacklists, like groundling32.sys.

8 Verify Network Connectivity

The CheckServerConnection method resolves the domain api.solarwinds.com to test network connectivity; only upon successful verification will further execution proceed. Otherwise, it exits and waits for the next execution.

 

Part 4 DGA Domain Communication Phase of the Backdoor

• Prerequisite Knowledge of DGA Domain Communication Phase

1 Overview of the DGA Domain Communication Phase

After passing all preceding environmental checks, the Sunburst backdoor enters the DNS communication stage using DGA domains. DGA domain communication consists of two phases: The first phase involves reporting the victim’s computer domain information to the attacker’s C2 server, enabling the attacker to filter targets using this data. The second phase reports the status information of security protection software, providing attackers with insights into the deployment of antivirus, EDR, etc., on targets. This data is encrypted and embedded in the first segment of the DGA domain names. The Sunburst attackers identified approximately 100 valuable targets for lateral movement within networks based on domain information and security software data collected by the Sunburst backdoor.

2 Unique Identifier: userid

Some victim computers have large baseline information (e.g., lengthy computer domains), requiring multiple DGA domain requests to completely transmit domain information. To distinguish DGA domain requests from different computers, Sunburst aggregates the decrypted segments of DGA domains that originate from the same computer. Sunburst computes a unique identifier, userid, for each machine.

For each infected computer, the userid is calculated using the victim’s MAC address, Windows domain, and Windows computer unique identifier GUID (randomly generated during Windows installation and stored in HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid’s registry value). This calculation employs a custom encryption algorithm to generate a unique userid.

3 Format for Backdoor DGA Domain Generation

The DGA domains used by Sunburst are cleverly processed with a general format as follows:

*.appsync-api.eu-west-1.avsvmcloud.com (the asterisk represents the DGA subdomain)

*.appsync-api.us-west-2.avsvmcloud.com (the asterisk represents the DGA subdomain)

*.appsync-api.us-east-1.avsvmcloud.com (the asterisk represents the DGA subdomain)

*.appsync-api.us-east-2.avsvmcloud.com (the asterisk represents the DGA subdomain)

Each of the rightmost three segments of the DGA domain comes from hardcoded strings within the backdoor program, while the first segment denoted by an asterisk is dynamically generated from information on the victim’s server, such as the computer domain. Below is an example of a DGA stage domain generation algorithm.

• DGA Domain Communication Phase of the Backdoor

1 First Phase of DGA Domain Communication

During this phase, Sunburst primarily aims to encode the victim’s computer domain, masking it in the DGA domain names, which is then relayed to the C2 server. When computer domains are overly long, the Sunburst backdoor splits the information, sending it in segments of 14 characters across multiple DNS requests to complete data transfer. If the attacker is interested in this computer domain, the second phase of DGA domain communication will commence.

, the Sunburst backdoor becomes activated and transitions to the “Append” state. Conveniently, as shown in the image below, these represent traffic samples with DGA domain communications captured from Sunburst during the first phase. The second column lists domain names decrypted from Sunburst’s collected victim domains. It is through this decrypted domain information that the attackers determine whether the targeted victim entity holds any relevance. Decoding and analyzing these domains revealed that several technology companies, including Cisco and Intel, as well as various universities and government agencies in the United States, are suspected victims of this attack.

2 Phase 2 DGA Domain Communication

In this phase, the Sunburst backdoor primarily relays the status information of the victim computer’s anti-virus protection back to the C2 server. When the Sunburst backdoor is in the Append (active) state, it begins generating DGA domains for the second phase, which include a unique computer identifier, security product status information from a built-in blacklist (such as existence, active status, or deactivation status), and whether communication succeeded in the previous DNS C2 stage.

3 IP Addresses as Command Triggers to Evade Traffic Monitoring

Normally, when performing DNS queries, like accessing google.com, it converts into the IP address 142.250.*.* and is stored in the A record. Similarly, the Sunburst backdoor resolves C2 domains to obtain IP addresses, but the purpose is not to communicate through these IPs. Instead, it triggers different malicious actions based on the IP addresses derived from various IP segments returned by the C2 domain. This is a remarkably sophisticated and covert form of command and control, making it challenging to detect by traffic monitoring systems.

Attackers control the IP address range that resolves C2 domains to belong to segments such as Google’s, Amazon’s, and Microsoft’s IP addresses instead of randomly selected IPs to initiate different behaviors. This strategy minimizes the detection risk. It is essential to reiterate that malware does not establish any communication with these IP addresses.

As demonstrated above, Sunburst developers define IP addresses within an AddressFamilyEx structure. Sunburst will activate various malicious behaviors based on which IP address is returned by DNS resolution. By examining the C# code of the Sunburst backdoor, we observe that based on the C2’s resolution of domains to different categories of IP addresses, Sunburst executes approximately five distinct types of operations:

1. Continuation of sending unsent domain fragment information; 2. Transmission of target computer’s security product status; 3. Execution of the second-phase C2 channel; 4. Cleanup and exit; 5. Reset to initial state, similar to the first execution.

A comprehensive diagram is provided below:

4 C2 Domain Resolution IP Indirect Control of Sunburst Flowchart

ABC_123 has crafted a flowchart demonstrating how, in practice, the C2 server controls the Sunburst backdoor behavior through DGA domain resolution to different IPs. Given the complexity of this communication process, ABC_123 intends to write a detailed article to explain the entire process subsequently.

Part5 HTTP C2 Communication Phase (Receiving and Executing Attack Commands)

Following the initial two phases of DGA domain communication, the attackers have identified valuable targets, leading the Sunburst backdoor into the subsequent stage: the HTTP C2 Communication Phase. During this stage, the DNS response will include a CNAME record, which Sunburst will utilize for HTTP C2 communication.

In this phase, Sunburst initiates a new thread to execute the HttpHelper.Initialize method, preparing to handle HTTP C2 communication requests, receive and execute commands from attackers, and subsequently encrypt and camouflage the execution results within normal traffic packets—relaying them back to the C2 server. The developers of the Sunburst backdoor designed an ingenious traffic encryption method for this phase to evade monitoring. Next, ABC_123 will elaborate on the specifics, providing insights into this sophisticated mechanism.

Initially, three distinct URL access forms during the HTTP C2 Communication Phase are posted, each corresponding to a specific scenario:

1. Sunburst persistently accesses .xml URLs to retrieve C2 instructions, with the URL form exemplified below:

hxxps://3mu76044hgf7shjf.appsync-api.eu-west-1.avsvmcloud.com/swip/upd/Orion.Wireless.xml

2. If the command execution result exceeds 10,000 data size, the URL form is as follows:

hxxps://3mu76044hgf7shjf.appsync-ap.us-east-2.avsvmcloud.com/pki/crl/492-ca.crl

3. When the command execution result is 10,000 or less, the URL form appears as follows:

hxxps://3mu76044hgf7shjf.appsync-api.us-east-1.avsvmcloud.com/fonts/woff/6047-freefont-ExtraBold.woff2

Now, the Sunburst backdoor’s process of obtaining C2 instructions and executing them, along with returning the execution results to the C2 server, is explained through these three steps.

1 Sunburst accesses .xml URLs to receive instructions

To acquire attacker-issued commands, the Sunburst backdoor continuously sends HTTP GET requests to the C2 server’s URLs ending in .xml, implementing a sleep interval based on setTime after each request. These XML files are disguised as seemingly benign XML files related to .NET assemblies, embedding commands utilizing various steganographic techniques. Sunburst extracts the attackers’ commands from the C2 server’s XML response using proprietary decryption algorithms and proceeds with execution.

The URL path used in Sunburst’s GET request is randomly generated following a specific algorithm, purposely counteracting IOCs detection. For instance, with the following URL:

hxxps://3mu76044hgf7shjf.appsync-api.eu-west-1.avsvmcloud.com/swip/upd/Orion.Wireless.xml

The variations in Sunburst backdoor URL requests predominantly occur in the highlighted section: /swip/upd/. The have a complex selection algorithm where each segment is randomly chosen by predefined proportions. It is noteworthy that the final digit of the error code isn’t random, instead signifying the success of the prior command request—0 typically indicating success, whereas 1 or other values indicate errors; these end with the .xml suffix.

Finally, through algorithmic methodologies, Sunburst constructs random URLs to access the C2 server and acquire commands:

https[:]//infinitysoftwares.com/swip/upd/SolarWinds.CortexPlugin.Nodes-5.2.1.xml

https[:]//infinitysoftwares.com/swip/upd/Orion.Wireless.UI-3.1.0.xml

https[:]//infinitysoftwares.com/swip/upd/Nodes-1.2.0.xml

For the initial 16 requests, Sunburst always uses a newly generated random URL path, but it may subsequently reuse previously generated random URL paths. During this phase, a constant If-None-Match custom request header is employed, containing the previously encrypted userId.

As illustrated below, a GET request targeting a Sunburst access URL concluding in .xml yields the C2 server’s XML format content—encrypted commands issued by the attacker are embedded within:

2 Sunburst Decodes and Executes Commands

The Sunburst backdoor decrypts and extracts attacker-delivered commands from the XML returned text and employs the ExecuteEngine method to execute the corresponding instructions. The JobEngine values function as criteria, enabling the execution of commands composed of command-line arguments. These commands reveal that the operations executed by the Sunburst backdoor are notably limited. This constraint implies that to further extend their malicious reach, the attackers must leverage additional tools to perform more complex operations, transitioning into the third stage employing the Cobalt Strike backdoor.

1. When the instruction is interpreted as JobEngine.SetTime, it sets a delay time for each request.

2. With Job.CollectSystemDescription, information collection encompasses machine domain name, Administrator SID, local hostname, username, operating system version, system path, network adapter status, registered company, registered username, system version number, system directory, etc.

3. During JobEngine.UploadSystemDescription, an HTTP request is crafted, submitting the request results to the C2 server.

4. Initiating JobEngine.RunTask triggers a new process based on a given file path and parameters.

5.

When using JobEngine.GetProcessByDescription, it retrieves a list of processes and obtains process information based on the parameters, including the Process ID, Process Name, Parent Process ID, and the username associated with the process.

6. When using JobEngine.GetFileSystemEntries, file and directory information is listed based on the regular expression provided in the parameters.

7. When using JobEngine.KillTask, Sunburst will terminate the process with the specified PID.

8. When using JobEngine.SetTime, it sets a delay in seconds. On the second trigger, if the time set in the first instance is less than 300 seconds, there will be a doubling of the delay.

9. When using JobEngine.FileExists, it checks whether the specified path exists.

10. When using JobEngine.DeleteFile, it deletes the specified path.

11. When using JobEngine.ReadRegistryValue, it reads the value of a registry key.

12. When using JobEngine.SetRegistryValue, it sets the name, type, and path of a registry key.

13. When using JobEngine.DeleteRegistryValue, it deletes a registry key.

14. When using JobEngine.GetRegistrySubKeyAndValueNames, it retrieves all specified names and data.

15. When using JobEngine.WriteFile, it decrypts the incoming Base64 string and writes it to a file. After writing, it triggers a delay function to ensure the process, highlighting the attacker’s cautious approach to file handling.

16. When using JobEngine.Reboot, it restarts the target computer.

17. When using JobEngine.Exit, it exits the current thread, waiting for the next execution load.

18. Following the directives, it may deploy third-phase backdoor programs, TEARDROP, and RAINDROP, to load the Cobalt Strike backdoor.

Sunburst transmits command execution results back to the C2

Once the Sunburst backdoor decrypts the attacker’s instructions from an XML file, it executes according to the directives and sends the results back to the C2 server. During the data return phase, the Sunburst backdoor does not send GET requests. Instead, based on the size of the return data, it chooses to transmit the command execution results via a POST request or PUT request to the C2 server. Sunburst disguises the request as a legitimate SolarWinds request link or a static resource to confuse security personnel, misguiding them into initially assessing Sunburst’s HTTP request as legitimate traffic.

1. When the data size exceeds 10,000 bytes, Sunburst sends data through a POST request. The POST request sets the Content-type field to application/octet-stream. In this case, the URL format is as follows:

hxxps://3mu76044hgf7shjf.appsync-api.us-east-2.avsvmcloud.com/pki/crl/492-ca.crl

The request URI path format is /pki/crl/{Segment 2}{Segment 3}{Segment 4}.crl, where {Segment 2} is a random number between 100 and 10,000; {Segment 3} is randomly selected from a built-in string list; {Segment 4} denotes the error code from the last request, in some instances this value might be empty; finally, the URL ends with a .crl suffix.

2. When the data size is 10,000 bytes or less, Sunburst sends the command execution results back to the C2 server via a PUT request. The data returned in the PUT request is converted into a JSON document resembling SolarWinds’ legitimate Orion Improvement Program (OIP) messages, where the Message within the JSON data contains the data to be sent. When sending the HTTP request, it sets the request header Content-type: application/json.

At this stage, the URL format resembles the following:

hxxps://3mu76044hgf7shjf.appsync-api.us-east-1.avsvmcloud.com/fonts/woff/6047-freefont-ExtraBold.woff2

In two scenarios, the URL format varies:

1. /fonts/woff/{Segment 2}-{Segment 3}-{Segment 4}-webfont{Segment 6}.woff2

{Segment 2} is a random number between 100 and 10,000; {Segment 3} and {Segment 4} are randomly selected from a built-in string list; {Segment 6} denotes the error code from the last request.

2. /fonts/woff/{Segment 2}-{Segment 3}-{Segment 4}{Segment 5}.woff2

Here {Segment 2} is a random number between 100 and 10,000; {Segment 3} and {Segment 4} are randomly selected from a built-in string list; {Segment 5} denotes the error code from the last request.

Sunburst conceals the command execution results within the following JSON-formatted POST request packet, which is then transmitted back to the C2 server.

Sunburst Deploys the Third-Stage Weapon

Ultimately, Sunburst progresses to the third stage. It initially downloads a VBS script and Loader program, placing them in the C:\Windows\ directory disguised as legitimate files. Subsequently, Sunburst employs image hijacking techniques by altering the registry, binding the dllhost.exe command with wscript.exe C:\Windows\[folder]\[trigger].vbs. The dllhost.exe is a randomly started program on Windows. Following this, the attacker waits patiently for dllhost.exe to execute, preparing to further run the VBS script. At this point, the Sunburst backdoor has completed its mission, and subsequent operations will not concern Sunburst.

The VBS script subsequently performs the following operations: it runs rundll32.exe, loads the previously malicious DLL file (Sunburst backdoor), cleans up the dllhost.exe image hijacking registry, removes traces, and finally runs the Loader program, triggering the Cobalt Strike backdoor to commence lateral

Part 6 Summary

1. The Sunburst backdoor only proceeds to execute if it meets the attacker’s conditions, and the security software acts as anticipated; otherwise, it will halt or retry the previous modification to revert the security software’s state. This aspect is one of the key distinctions between APT attackers and regular criminals.

2. To counter IOCs detection, the Sunburst backdoor creators devised a clever DGA domain generation algorithm and a URL path randomization algorithm, with DGA domain request intervals potentially spanning an entire day, making the attack process extremely stealthy.

3. During the HTTP C2 communication phase, Sunburst encrypts sensitive data from the victim’s computer and stores it in XML assemblies or JSON documents, sometimes mimicking SolarWinds’ proprietary protocol traffic. This approach is challenging to identify during traffic audits.

4. The APT group indirectly controls the Sunburst backdoor’s actions by resolving the C2 domain to different IP address ranges, making this attack behavior difficult to detect during traffic audits.

5. The attackers write different numbers 3, 4, or 5 into the Orion software’s XML configuration file, indicating the different states of the Sunburst backdoor, which reads these values to perform distinct operations. This process is also highly covert.

APT Supply Chain Design Communication Domain Name