Sunburst: How Will You Protect Yourself from the Next Attack?

Shay Siksik
December 21, 2020

On December 8, FireEye reported that it had been compromised by a highly sophisticated state-sponsored adversary, which stole many tools used by FireEye red-team, the team that plays the role of an attacker in penetration testing. Upon investigation, on December 13, FireEye and Microsoft published a technical report, pointing out that the adversary gained access to FireEye’s network via a trojan (named Sunburst) in SolarWinds Orion.

SolarWinds Orion is a management platform that allows organizations to monitor and manage the entire IT stack – VMs, network devices, databases and more. The Orion platform requires full administrative access to those resources, which makes compromising Orion very sensitive.

According to SolarWinds, the trojan was inserted into the Orion platform and updates between March and June 2020, through its build process. Orion’s source code was not infected. SolarWinds Orion has 33,000 customers, and SolarWinds believes that 18,000 customers may have been downloaded the trojanized Orion version. More than 425 of the US Fortune 500 companies use SolarWinds products.

Within a few minutes of identifying Sunburst’s IoCs, all Cato customers were protected against the trojan. Our detection and prevention engines were updated; all users with Sunburst on their network notified. (Read this blog to better understand the value of SASE and Cato’s response.) For non-Cato customers or those already infected with Sunburst, teams should follow Cybersecurity and Infrastructure Security Agency (CISA) guidelines and SolarWinds Security Advisory.

But here’s the question: If end-point detection (EDR) and antimalware were insufficient to protect the biggest companies in the world, how then can any enterprise expect to protect itself from such attacks in the future?

Sunburst: A Remarkably Sophisticated Attack

To answer that question, you need to understand Sunburst. The trojan managed to stay alive and hidden for roughly nine months, making it one of the most sophisticated attacks we’ve seen in the past decade. The trojan did this by using many evasive techniques and carefully choosing its targets.

Evasive techniques began at the outset. The trojanized updates were digitally signed and loaded as DLLs as part of SolarWinds Business Layer component. This is particularly important as it would render the trojan undetected by most EDR systems. The trojan also only starts running 12 or more days after the infection date, which made it hard to identify its infection channel (the update on the specific date). Finally, the trojan only runs if the system is attached to a domain, and with some registry keys set to specific values.

Once executed, the adversaries obtain administrative access to the different assets that are managed by the SolarWinds platform by gaining access to Orion’s privileges and certificates. The adversaries use these credentials to move laterally across the network and access the infected organization’s assets.

Sunburst also tries to evade detection by using a multi-stage sophisticated C&C communication. The first and main network footprint of Sunburst, is its C&C communication with avsvmcloud[.]com domain, in the following format:

(DGA).appsync-api.{region}.avsvmcloud.com

Where {region} can be one of: eu-west-1, eu-west-2, us-east-1, us-east-2.

Sunburst creates a DGA (Domain Generation Algorithm) to generate unique subdomains for C&C communication. Without one subdomain to detect and block, the adversary can better avoid detection.

What’s more, if the domain resolves to an IP on a blocked IP range (a block list), Sunburst will stop executing and add a key to the registry to avoid further runs and detection. Once the domain is resolved and initial communication is complete, the trojan understands that communication is possible, and they know the target organization. They can then move onto the next phase of exfiltrating data by communicating with C&C server in one of nine other domains.

If that’s not enough to avoid detection, Sunburst sends data to the C&C server by creating a covert channel over TLS and using SolarWinds’ Orion Improvement Program (OIP) protocol that is normally used to send telemetry data. A telemetry channel is an approved communication channel which communicates on a regular basis with its destination, like malware C&C communication.

As we’ve seen in Cobalt Strike, Sunburst uses the attributes of a legitimate protocol to communicate and avoid detection. In this case, the http patterns of Orion Improvement Program protocols have been used but with a different domain (normally, api.solarwinds.com). As an example, the URIs ‘/swip/Events’ and ‘/swip/upd/SolarWinds.CortexPlugin.Components.xml’ which are used by SolarWinds are used also in Sunburst.

Detection and Post-Infection Analysis

What should be clear is that stopping such attacks with EDR or antimalware alone is very challenging, if not impossible. However, these threats continue to require the network to exfiltrate data and propagate across the network. By looking at those properties, enterprises can at the very least detect such threats in the future and stop them before they cause harm.

Cato’s MDR team identifies trojans, like Sunburst, during threat hunting by leveraging several characteristics of the Cato platform. Sunburst C&C communication, for example, occur across HTTPS, which makes line-rate TLS inspection vital. While inspecting the traffic, the specific attribute to note is the popularity of avsvmcloud[.]com domain. Across Cato customers, the domain’s popularity was very low prior to December 08, 2020. An unfamiliar destination with questionable trust should raise alarms for anyone. Our MDR metrics would also spot DGA usage. Finally, periodic traffic to the C&C server at avsvmcloud[.]com and accessing a subdomain generated by DGA, would flag Sunburst traffic as a suspicious. You wouldn’t expect outbound Internet traffic from Orion to non-SolarWinds websites for updates, content, and sharing telemetry or your own assets.

Network-Based Threat Hunting is Crucial

As threat actors become more sophisticated, enterprises need to be more proactive about hunting threats. And it’s not just governmental organizations or financial institutions that need to be concerned with threat hunting. Every enterprise should ‘assume breach’ and act every day to identify unknown threats within their networks. Only then will you be protected from the next Sunburst.

Shay Siksik

Shay Siksik is a Security Analyst Manager in Cato Research Labs at Cato Networks. Shay served in an elite cybersecurity unit in Israel Defense Forces  (IDF) and has more than 15 years of experience in the network security area. Previously, he was the Director of Solution Architecture and Technical Enablement at Skybox Security.