A Summary of FireEye’s Detailed Analysis on the SUNBURST Malware
Backdoor: “An undocumented way of gaining access to a computer system.”
Hello, Reader! In this article, I will give a high-level summary of FireEye’s detailed report on the SUNBURST malware — the malware used as the payload for the trojanized update that was rolled out for SolarWind’s Orion software. Before diving into the inner workings of the malware, let’s discuss how this malware was distributed to thousands of SolarWind’s Orion customers via a supply chain attack.
The SolarWind’s Supply Chain Attack
The hackers (currently being tracked as UNC2452 by FireEye) behind SolarWind’s supply chain attack compromised the update servers responsible for storing and distributing the updates for SolarWind’s Orion software product. The successful compromise of the update server’s allowed the adversaries to quickly spread their trojanized updates to thousands of SolarWind’s Orion customers. And because these updates were digitally signed with a SolarWind’s certificate signed by Symantec, which sold its certificate authority business to DigiCert back in 2018, there were very few chances that detection tools would flag this update as malicious. According to this SolarWind SEC filing report, there were potentially 18,000 customers who were infected with the trojanized Orion software update. This list of customers includes several U.S. federal government agencies and over 80% of Fortune 500 companies. Due to the level of sophistication of SolarWind’s supply chain attack and the SUNBURST malware, cybersecurity professionals are, without a doubt, claiming this to be the work of an Advanced Persistent Threat (APT). If you wish to read more about the supply chain attack, check out this article.
SUNBURST: Advanced Anti-Analysis Techniques
The anti-analysis techniques used by the SUNBURST malware are very sophisticated and according to FireEye, is the reason the malware was able to “evade detection by anti-virus software and forensic investigators for seven months” (!!!). SUNBURST checks to see if a certain set of requirements are met before taking any steps to further infect the system. For example, SUNBURST confirms that the name of the process containing the malicious code is
solarwinds.businesslayerhost. To further thwart the efforts of malware analysts, the designers of this malware did not directly include the name of the process in plaintext but instead included the hash of the process name and XORed the resulting hash, forcing malware analyst’s to brute force the hashes preimage (For more on what the preimage of a hash is, check out my article about hashing). After confirming that the name of the running process is
solarwinds.businesslayerhost , SUNBURST waits approximately two weeks before continuing execution by checking that the last write time of the DLL,
SolarWinds.Orion.Core.BusinessLayer.dll, is about two weeks after the initial execution of the malware. After the two weeks, the malware creates a named pipe identified by
The configuration of SUNBURST is stored in a config file belonging to the Orion software named
SolarWinds.Orion.Core.BusinessLayer.dll.config. Several settings of the config file (
ReportWatcherPostpone), have been altered to allow the adversaries to command the malware remotely.
SUNBURST stops further infection if the system is not joined to an Active Directory (AD) domain. The malware also contains a blacklist, which specifies a collection of AD domain names of systems it does not wish to infect. The final check SUNBURST does is check if it has Internet connectivity by resolving the domain,
SUNBURST: Domain Generation Algorithm
SUNBURST deploys an intermediary command and control (C2) server, under the domain
avsvmcloud[.]com , for sending information about the final C2 server and for setting SUNBURST’s mode of operation. To prevent blue teamers from quickly blocking domain names or IP addresses that statically appear within the backdoor, SUNBURST utilizes a custom Domain Generation Algorithm (DGA) that includes several pieces of information from the victim to randomly create domain names for C2 communications. The information about the victims include:
- MAC address of the non-loopback address
- Domain name
- The value of the
This information is crucial for the adversaries to correctly identify the communicating victim organization. The generated FQDN’s are suffixed with the domain of the intermediary C2 DNS server:
SUNBURST has four different subdomains,each used to signify SUNBURST’s mode of operation. Two of the subdomains can be used to recover information about victim organizations. The open-source community has reversed engineered the DGA and has provided scripts that can be used to decode victim domain names generated by the DGA.
For more on Domain Generation Algorithms, check out this Malwarebytes article. And here is the link to the MITRE ATT&CK C2 sub technique defining DGA’s, https://attack.mitre.org/techniques/T1568/002/.
SUNBURST: Command and Control (C2) Operations
SUNBURST uses two modes for C2 communications that use both the DNS and HTTP protocols. There is an active and a passive mode. The active mode of SUNBURST uses HTTP to communicate to the final C2 server where it retrieves direct commands from the adversaries and the passive mode of SUNBURST uses DNS to retrieve status information and performing beaconing via DNS.
The DNS C2 protocol communicates several pieces of information via DNS records. When the intermediary DNS C2 server sends DNS A record responses to SUNBURST, SUNBURST checks against a hard-coded list of IP addresses that will determine SUNBURST’s mode of operation (the mode of operation section specifies the different mode SUNBURST can be set to). For example, DNS A record responses within the following IP ranges will instruct SUNBURST to continue beaconing:
If DNS A record responses fall within the following IP ranges, SUNBURST is instructed to terminate by updating the
ReportWatcherRetry value within SUNBURST’s configuration file to a value that will act as the killswitch for the malware,
fc00:: — fe00::
fec0:: — ffc0::
ff00:: — ff00::
If SUNBURST receives a DNS CNAME response from the intermediary C2 DNS server, it uses the domain pointed to within the response to initiate the HTTPS communication channel to the final C2 server. SUNBURST utilizes the
HttpHelper.Initialize method for HTTP C2 communications. HTTP GET and POST requests are used and certificate verification is also disabled so a MITM attack can be used to decrypt the traffic. Steganography is used within the body of these HTTP requests to hide commands in what looks like innocuous XML text. Hexadecimal and GUID values can be found within the XML data containing the commands that will be executed on the target machine.
The following images show a table containing the available commands that can be issued to SUNBURST and their corresponding operation:
The responses sent to the HTTP C2 server that are 10,000 bytes or less, use JSON formatting similar to the messages generated by the Orion Improvement Program (OIP) used by SolarWinds. And responses that are greater than 10,000 bytes are sent as normal HTTP responses. The information contained within the JSON responses includes information such as a unique identifier for the infected victim machine, a GUID representing the session ID for the HTTP thread created for executing the
HttpHelper.Initialize function, and other relevant key-value JSON pairs containing the following keys:
Timestamp, Index, EventType, EventName, DurationMs, Succeeded, and
SUNBURST: Modes of Operation
As previously mentioned, SUNBURST behaves differently according to the IP address specified in the DNS A record response from the intermediary DNS C2 server. Depending on the IP address, the configuration key
ReportWatcherRetry is set to a unique value that alters the malware's mode of operation. The following image shows the three different modes the malware can be set to:
Knowing that SUNBURST’s mode of operation is represented by the value of the configuration key
ReportWatcherRetry , blue teamers simply have to look at the value of this key to determine the last mode the malware was in before its detection.
The SolarWinds supply chain attack is, in my opinion, the biggest hack of 2020 and it is, without a doubt, the work of a nation-state actor. As the investigation on the attack is still ongoing, there is still a ton of information to be disclosed regarding this hack, so follow me on Medium if you would like more updates on the SolarWinds hack.
For more details on the SUNBURST malware, please read the actual FireEye report on SUNBURST, which is the primary source of information for this article. Also, here is the link to FireEye’s SUNBURST countermeasures that includes YARA rules, Snort rules, Indicators of Compromise, and more.
If you have learned anything from this article, please follow me on Medium for more cybersecurity-related articles, and on GitHub (link below) for more cybersecurity-related projects. Thanks for reading. Happy Holidays!
binexisHATT - Overview
My name is ✨ Alexis Rodriguez ✨ and I am a cybersecurity professional currently looking for a cybersecurity analyst or…