Authors: Victor Sandin and Jeremy Ware
1. Executive Summary
On 15 December, Infoblox released a Cyber Threat Advisory on the supply chain attack affecting SolarWinds’ Orion IT monitoring and management software.1 This advisory detailed FireEye’s report on the campaign, including analysis on the SUNBURST backdoor, initial information on the threat actor’s tactics, techniques and procedures (TTPs), as well as the mitigations and indicators of compromise (IOCs) that were most current at the time.2
The threat actor behind the campaign carried out a complex attack chain and demonstrated highly sophisticated TTPs, indicating it was the work of an advanced persistent threat (APT) group. In a 5 January joint statement, the Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), the Office of the Director of National Intelligence (ONI), and the National Security Agency (NSA) indicated that based on its investigations, the APT is likely Russian in origin.3 Known victims include government agencies, as well as private sector and critical infrastructure organizations.4
In our first update, we shared additional information about the wide-ranging effects of this campaign after conducting several internal investigations.5 We summarized some of the latest information from OSINT, as well as conveyed what we were able to validate at the time and provided additional IOCs.
Today’s update includes new information provided by the latest alert from CISA and recent OSINT on additional attack vectors, use of anti-analysis blocklists, additional information in privilege escalation and persistence, compromised accounts and applications in Azure/Microsoft 365 environments, and command and control protocol. We have also updated the IOC table with new information.
2.1. Updates on Supply Chain Attack and Initial Vectors
As previously reported, evidence suggests the threat actor(s) used additional initial attack vectors beyond SolarWinds’ Orion software. In some incidents under investigation by CISA,6 threat actor(s) appeared to have obtained initial access through brute force techniques such as password guessing and password spraying, as well as compromised administrative credentials accessible via external remote access services.
2.2. Anti-Analysis Blocklists
According to CISA, to disguise the strings used to detect security products, the threat actors calculated and embedded in the code a list of custom hashes produced by the cryptographic hash function FNV-1A and an XOR operation. It is computationally expensive to determine which string a hash value corresponds to, but by joint efforts from the information security community, all of the hashes have been successfully bruteforced and published to FireEye’s GitHub.7
SUNBURST malware checks processes, services and device names against its blocklist. If a blocklisted process or driver is found, it pauses execution and attempts the process again later. If a blocklisted service is found, SUNBURST attempts to disable it by editing the service configuration in the Windows Registry. After this modification, the backdoor updates the ReportWatcherPostpone configuration value to reflect which service was disabled. Subsequent service blocklist checks skip services present in this configuration value. SUNBURST will continue past this check only when there are no processes nor drivers from the blocklist present.
2.3. Updates on Privilege Escalation and Persistence
As previously reported, the threat actors compromised the Security Assertion Markup Language (SAML) signing certificate using their escalated AD privileges to create valid tokens and present them to services that trust SAML tokens from the environment. CISA has observed that the threat actors also added authentication credentials by assigning tokens and certificates to existing Azure/Microsoft 365 application service principals. These tokens provide them programmatic management of Microsoft Cloud tenants to operate on the hosted resources. This technique allows threat actors to maintain persistence without generating significant evidence or telemetry because not all Microsoft 365 licensing levels log these events.
Microsoft reported8 that in some cases, threat actors have also added one or more new federation trusts to existing on-premises infrastructure so that authentication could possibly happen outside of the organization’s known infrastructure and therefore potentially not be visible to the legitimate system owner.
2.4. Compromised Azure/Microsoft 365 Resources
CISA also reported that the threat actor(s) could have compromised accounts and applications in Azure/Microsoft 365 environments. This would leave certain indicators of compromise (IOCs) in the unified audit log in Azure/M365, as well as changes in the Azure service principles. CISA has developed a PowerShell tool called Sparrow.ps19 to check the unified audit log and detect these compromises.
2.5. Command and Control Coordinator Protocol
SUNBURST uses a two-part C&C protocol that involves DNS and HTTPS. In passive mode, which is also the starting mode, the malware communicates using only DNS and receives high-level updates to its state from its C&C (avsvmcloud[.]com). We described both the DGA and the DNS activity in our previous report.10
When the C&C server responds with a DNS CNAME response, SUNBURST switches its mode to active and will communicate via HTTPS to its final C&C server and receives detailed commands for actions such as spawning a process or transferring a file. This transition only happens if SUNBURST receives a DNS A record response pointing to a specific subnetwork. It will then use the least significant bit from the A record IP address to determine the proxy method and Uniform Resource Identifier (URI) scheme to use, as well as a delay value used in the HTTPS thread.
Once SUNBURST is in active mode, the backdoor uses GET and POST requests to communicate with its C&C server. When sending a GET request, the malware adds an If-None-Match HTTPS header that includes the encoded user ID. This likely allows the C&C server to determine which SUNBURST installation generated the request, further enabling multiplexing of C&C streams on a single server.
The C&C server uses steganography techniques to hide data within the response that attempts to appear as benign XML related to .NET assemblies.
2.6. HTTPS Backdoor
In active mode, the backdoor receives the command to execute from the HTTPS response. FireEye has analyzed the capabilities of SUNBURST, which include:11
- Collect system information including hostname, username, OS version, MAC addresses, IP address, DHCP configuration and domain information;
- Start new processes with a given file path and arguments;
- List running processes along with their parent process PID and the user and domain of the processes owner;
- Kill processes;
- List files and directories of a given path;
- Test if a given file exists, as well as edit and remove files;
- Get MD5 of a given file and check if the hash of a given file matches a given hash;
- Read, write and delete Windows registry keys;
- List subkeys and value names beneath the given registry path; and
The results of these commands are compressed and single-byte XOR-encoded with the XOR key prepended to the message. The message is then turned into JSON documents that resemble the Orion Improvement Program (OIP) messages used legitimately by SolarWinds.
2.7. Mode of Operation
SUNBURST has three modes of operation: active, passive and disabled. The backdoor configuration key ReportWatcherRetry contains the last running mode of the malware.
As we described above, during passive mode, SUNBURST performs only DNS beaconing containing the user AD domain. In active mode, Infoblox has confirmed that the process begins once the CNAME resolves with the local resolver. The backdoor then creates the DGA domain and records a new address as the CNAME. The class triggering the HTTPS backdoor later uses this CNAME. If the specific cider ranges return, or if no CNAME is returned, SUNBURST will either attempt again later or switch to disabled mode and it stops further execution unless the backdoor configuration key is edited.
3. Prevention and Mitigation
CISA has included new guidelines for networks containing the malicious binary but with no evidence of secondary C&C activity to a separate domain or IP address, actions on objectives (AOOs) such as SAML token abuse, or any other adversary activities. In these cases, they indicate that organizations can rebuild the platform, harden the configuration based on SolarWinds secure configuration guidelines and resume use as determined by and consistent with their own thorough risk evaluation.
3.1. Indicators of Compromise
Below is a supplementary list of IOCs related to this attack, according to OSINT. CISA published an extended list of IOCs in their 17 December report on the campaign and it was updated on January 7th with new indicators. This table includes only the latter.
|Additional SUNBURST domains|
|Additional SSL hashes|
Additional SUNBURST hashes
Additional SUNBURST IPs
- https://us-cert.cisa.gov/ncas/alerts/aa20-352a CISA reported the Microsoft finding, and refers to a query to identify these cases by Microsoft, as posted in https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/ADFSDomainTrustMods.yaml