SUNBURST Attack: Tracking Down DNS Requests to Malicious Sites

Last month, the SUNBURST attack on SolarWinds Orion, FireEye, and various government agencies shook cybersecurity. The unprecedented attack has remained in the news consistently, despite taking place a month ago. On January 5 of this year, US intelligence officially pointed the finger at Russia being the one behind the attack.

How did we get here?

The breach occurred in March of 2020; the version of SolarWinds Orion including the backdoor was delivered to customers. FireEye describes this method in their December 13 discovery of the SolarWinds backdoor:

“Authorized system administrators fetch and install updates to SolarWinds Orion via packages distributed by SolarWinds’s website. The update package CORE-2019.4.5220.20574-SolarWinds-Core-v2019.4.5220-Hotfix5.msp (02af7cec58b9a5da1c542b5a32151ba1) contains the SolarWinds.Orion.Core.BusinessLayer.dll described in this report. After installation, the Orion software framework executes the .NET program SolarWinds.BusinessLayerHost.exe to load plugins, including SolarWinds.Orion.Core.BusinessLayer.dll. This plugin contains many legitimate namespaces, classes, and routines that implement functionality within the Orion framework. Hidden in plain sight, the class SolarWinds.Orion.Core.BusinessLayer.OrionImprovementBusinessLayer implements an HTTP-based backdoor. Code within the logically unrelated routine SolarWinds.Orion.Core.BusinessLayer.BackgroundInventory.InventoryManager.RefreshInternal invokes the backdoor code when the Inventory Manager plugin is loaded. “

On December 8, FireEye made the first announcement that they were the victim of a coordinated (and sophisticated) attack. Only days later did they discover the connection to SolarWinds, and as of December 15 Microsoft and GoDaddy were able to sinkhole the avsvmcloud[dot]com domain that served as the command & control server for the SUNBURST malware. SolarWinds also urged their customers to update their Orion platform to the latest version.

While the Microsoft sinkhole and SolarWinds update do not undo any damage that have already been done, they do protect customers from being impacted by the SUNBURST attack in the future. However, any customers who were exploited previously will need to take extra precautions.

Per FireEye:

"This killswitch will affect new and previous SUNBURST infections by disabling SUNBURST deployments that are still beaconing to avsvmcloud[.]com. However, in the intrusions FireEye has seen, this actor moved quickly to establish additional persistent mechanisms to access to victim networks beyond the SUNBURST backdoor. This killswitch will not remove the actor from victim networks where they have established other backdoors. However, it will make it more difficult to for the actor to leverage the previously distributed versions of SUNBURST."

Even though the threat has been contained, a full assessment should still be carried out. The Department of Homeland Security created a list of required actions for US government departments impacted by the breach.

Blocking Domain Generation Algorithms (DGA)

On December 14, we started blocking known DGA indicators associated with the SUNBURST attack.

DGA is an alternative to a hardcoded malware call. Usually, malware is hardcoded with a list of domains that it will send DNS requests. However, SUNBURST uses DGA, which is an algorithm that allows the malware to generate its own domain names (in this case, subdomains). This makes these domains harder to block.

The main domain associated with the SUNBURST attack is avsvmcloud[dot]com. By categorizing this domain as a threat in our system, any subdomains created via DGA would be blocked since the subdomain inherits the parent category.

The subdomain is made up of a few parts:

• The DGA (dynamically generated based on data from the machine); It is a seemingly random string that looks something like this: rikp75n8i3k0rdo5fvoe0k6jorv0ov2)
• A constant: appsync-api
• A location (such as us-east-2; there are four options in total)
• Another constant (the parent domain): avsvmcloud[dot]com

All together, a domain that the malware might call will look something like this:

ml3q39p9124ps9gvwonou0ge2h[dot]appsync-api[dot]eu-west-1[dot]avsvmcloud[dot]com

This subdomain is clever, as it looks the way an administrator would expect an AWS endpoint (or something similar) to look like. This is part of why the attack went undetected for several months.

Searching for malicious DNS requests

After blocking known DGA indicators, we wanted to go a step further for our customers. We were able to go through our DNS logs from March through December and sift through billions of DNS requests to find any DNS queries to these known threat domains associated with SUNBURST.

We identified over 600 total requests to known, malicious SUNBURST domains on our network that occurred between March 2020 and December 14, 2020. We were happy to see that a relatively small number of our customers were impacted by this breach, however, with under 30 networks affected.

Based on these requests, we reached out to these customers individually to let them know they had been impacted in some way by the SUNBURST attack and should take action to update SolarWinds Orion and perform an investigation of their network and internal devices if they have not done so already.

Stage 2 of SUNBURST

According to FireEye, the SUNBURST malware has an “active” mode and a “passive” mode. In passive mode, the malware is dormant. It waits to become “active.”

SUNBURST transitions to “active” from “passive” based on if the C2 coordinator responds with a DNS A record. If there is no DNS A record response, the CNAME resolution “will be ignored and treated as an error,” according to FireEye.  

The main question that the C2 coordinator and the SUNBURST DGA are “discussing” is whether or not this victim is “interesting to attack.”

If you believe you were the victim of SUNBURST prior to December 14, check your email for an email from DNSFilter. It was sent in December 2020. This email contains information around which of your networks were impacted.

However, anyone can use the DNSFilter query logs to check for requests to the avsvmcloud[dot]com domain. You can also review your threat reports for a list of the latest threats accessed on your network.

Make sure you’re blocking malware threats with your DNSFilter account to continue blocking known domains associated with SUNBURST. Under “Filtering” select the policy you’d like to add threat blocking to, and navigate to “Threats.” From there, make sure you’re blocking “Malware.” We have 7 total threat categories that you can choose to block that will help you protect your network.