Extracting Security Products from SUNBURST DNS Beacons

The latest version of our
SunburstDomainDecoder (v1.7)
can be used to reveal which endpoint protection applications that are installed on
trojanized SolarWinds Orion deployments.
The security application info is extracted from DNS queries for “avsvmcloud.com” subdomains,
which is used by SUNBURST as a beacon and C2 channel.

Here’s an example showing that City of Kingston, Ontario, Canada
were running Windows Defender on their trojanized SolarWinds deployment back in June:

The “F9A9387F7D252842” value is the victim’s unique SUNBURST GUID.

See our blog post Reassembling Victim Domain Fragments from SUNBURST DNS
for more info about how the GUID value is encoded into the DNS traffic.

You can also run SunburstDomainDecoder in Linux, with help of
Mono, like this:

The file “uniq-hostnames.txt” is a publicly available SUNBURST passive DNS repository created by Bambenek Consulting.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Time Analysis of SUNBURST Beacons

This bash one-liner indicates that the passive DNS data shared by Bambenek
contains queries posted between April and October 2020.

The April 4 date here might indicate that this is when the first backdoored installer was released in the wild,
but we only see SUNBURST DNS queries from a single GUID (CB28867A08967B43) on that date.
The second victim doesn’t appear until April 11, with additional victims starting beaconing on April 13, 14 and 15.

The first known SolarWinds Orion update containing the SUNBURST backdoor was
“SolarWinds-Core-v2019.4.5220-Hotfix5.msp” (02af7cec58b9a5da1c542b5a32151ba1),
which was signed on March 24.
This hotfix was released publicly on March 26, according to SolarWind’s
Orion Platform Hotfix Release Notes.
Both these dates are well before April 4, but the SUNBURST code was actually hardcoded not to start until at least 288 hours (12 days)
have passed since the executing assembly was written to disk (it actually picks a random wait interval between 288 and 336 hours).

This means that an organization installing the trojanized Hotfix 5 update, when it was released on March 26,
will not start sending SUNBURST DNS beacons until at least April 7.
Hence the mystery GUID CB28867A08967B43, which was sendng SUNBURST DNS beacons already on April 4, is most likely not a regular SolarWinds customer.

We did unfortunately not find any SUNBURST DNS beacon with an encoded domain name for the mystery CB28867A08967B43 GUID.
Nevertheless, here’s a list of victim GUIDs, with corresponding domain names, that were sent in SUNBURST DNS beacons during April this year:

Security Product Statistics

It is also possible to use the passive DNS data shared by Bambenek, Joe Słowik and others
to compute statistics of which security products that are popular among SolarWinds’ customers.

It is worth mentioning that SUNBURST does not report status for several other major endpoint protection vendors, such as Kaspersky, McAfee and Symantec, Sophos and Trend Micro.

Download SunburstDomainDecoder

Our tool SunburstDomainDecoder is released under a Creative Commons CC-BY license,
and can be downloaded here:
https://www.netresec.com/files/SunburstDomainDecoder.zip

You can also read more about SunburstDomainDecoder in our blog post
Reassembling Victim Domain Fragments from SUNBURST DNS.

 Share on Facebook   Tweet   Submit to reddit.com

Recent Articles By Author

• Network Forensics Training – Spring 2024
• CapLoader 1.9.6 Released
• Forensic Timeline of an IcedID Infection

More from Erik Hjelmvik

*** This is a Security Bloggers Network syndicated blog from NETRESEC Network Security Blog authored by Erik Hjelmvik. Read the original post at: https://www.netresec.com/?page=Blog&month=2020-12&post=Extracting-Security-Products-from-SUNBURST-DNS-Beacons