{"id":5837,"date":"2021-01-07T16:37:43","date_gmt":"2021-01-08T00:37:43","guid":{"rendered":"https:\/\/blogs.infoblox.com\/?p=5837"},"modified":"2024-04-26T13:20:59","modified_gmt":"2024-04-26T20:20:59","slug":"solarwinds-second-update","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/threat-intelligence\/cyber-threat-advisory\/solarwinds-second-update\/","title":{"rendered":"SolarWinds Second Update"},"content":{"rendered":"

Authors: Victor Sandin and Jeremy Ware<\/p>\n

TLP:WHITE<\/p>\n

1.\u00a0 Executive Summary<\/h3>\n

On 15 December, Infoblox released a Cyber Threat Advisory on the supply chain attack affecting SolarWinds\u2019 Orion IT monitoring and management software.1<\/sup> This advisory detailed FireEye\u2019s report on the campaign, including analysis on the SUNBURST backdoor, initial information on the threat actor\u2019s tactics, techniques and procedures (TTPs), as well as the mitigations and indicators of compromise (IOCs) that were most current at the time.2<\/sup><\/p>\n

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<\/sup> Known victims include government agencies, as well as private sector and critical infrastructure organizations.4<\/sup><\/p>\n

In our first update, we shared additional information about the wide-ranging effects of this campaign after conducting several internal investigations.5<\/sup> 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.<\/p>\n

Today\u2019s 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.<\/p>\n

2.\u00a0 Analysis<\/h3>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2.1.\u00a0 Updates on Supply Chain Attack and Initial Vectors<\/h4>\n

As previously reported, evidence suggests the threat actor(s) used additional initial attack vectors beyond SolarWinds\u2019 Orion software. In some incidents under investigation by CISA,6<\/sup> 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.<\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2.2.\u00a0 Anti-Analysis Blocklists<\/h4>\n

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\u2019s GitHub.7<\/sup><\/p>\n

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.<\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2.3.\u00a0 Updates on Privilege Escalation and Persistence<\/h4>\n

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.<\/p>\n

Microsoft reported8<\/sup> 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.<\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2.4.\u00a0 Compromised Azure\/Microsoft 365 Resources<\/h4>\n

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<\/sup><\/em> to check the unified audit log and detect these compromises.<\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2.5.\u00a0 Command and Control Coordinator Protocol<\/h4>\n

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<\/em>). We described both the DGA and the DNS activity in our previous report.10<\/sup><\/p>\n

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.<\/p>\n

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<\/em> 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.<\/p>\n

The C&C server uses steganography techniques to hide data within the response that attempts to appear as benign XML related to .NET assemblies.<\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2.6.\u00a0 HTTPS Backdoor<\/h4>\n

In active mode, the backdoor receives the command to execute from the HTTPS response. FireEye has analyzed the capabilities of SUNBURST, which include:11<\/sup><\/p>\n