Finding SUNBURST victims and targets by using passive DNS, OSINT

For over a month now, the hack of SolarWinds’ Orion IT management platform has been present in the news regularly with plenty of interesting discoveries on the modus operandi of the attackers and the effects of the hack on several targeted companies and government branches. However, there’s been little information about some of the connections that SUNBURST has shared ‘in public’ and the stories of the affected organisations, while there have also been some stories that tried to grasp these connections, but ended up in providing the opposite effect; a false sense of security.

A quick summary for those who’ve not been aware of this recent hack yet; On December 13, 2020, FireEye put out a post sharing that they “discovered a supply chain attack trojanizing SolarWinds Orion business software updates in order to distribute malware”. After some research, it turned out that up to 18.000 SolarWinds customers could’ve potentially received the trojanized updates for the Orion software. These customers should be considered ‘victims’ of the attack. Only ‘high value’ organisations of interest to the attackers received additional malicious software intended for further exploitation. These customers should be considered ‘targets’ of the attack.

Decrypting SUNBURST domains

In general, the SUNBURST backdoor collects several kinds of information about the infected system, encrypts this information into a combination of strings, adds these together, and sends this information back to the attackers through the use of DNS requests for subdomains of the avsvmcloud[.]com domain. To be specific, the subdomains are always similar to the following patterns:





Even though there are four possible options for the first-subdomain, being eu-west-1/us-west-2/us-east-1/us-east-2, these do not seem to relate to any specific geographical targeting, nor does changing these domains change anything on the encoded data that’s been submitted in the third-subdomain. Their only intention so far seems to be to mimic services like AmazonAWS to give the made connections some form of legitimacy. Occasionally I’ve seen several variations on these four first-subdomains like cn-west-1, eu-west-2, and us-west-1 yet there is no indication that these subdomains have been in use by the backdoor itself.

As for the third-subdomain, this is where the transferred data comes into play. I don’t want to get too much into the actual encryption/decryption as others like RedDrip Team from QiAnXin Technology, Prevasio, Cloudflare and NETRESEC have already written detailed reports on this. In summary, these subdomains consist of the following parts: an encoded GUID, a byte that functions as the XORkey for the GUID and the hostname of the local network of the infected system or other additional information like encoded timestamps or active Antivirus-products or the confirmation to become a target instead of a victim. These are the important bits that supply both the attackers as well as the community important information about the infected systems.

Passive DNS and the post-December noise

Image for post
Image for post
a small portion of passive DNS data on avsmcloud[.]com

Fortunately, there are a few clues that helping sorting through this noise:

First of all, we know the backdoor communicates in the mentioned patterns as mentioned above so that sorts out a big part of the noise (set the odd cn-west-1, etc. subdomains aside for a bit, as their third-subdomains could still contain actual information). Second, we know the GUID and XORkey make up 16 characters and the backdoor has a 32 character limit, so the third-subdomain should be between 17 and 32 characters long. Furthermore, you can discard any subdomains that contain any symbols in the third-subdomain.

The SUNBURST Puzzles

Most of this will work out just fine, however, sometimes you will find yourself ending up missing a piece or two for a full domain. In the case of only lowercase alphanumeric domains, this ain’t too much of a problem as you will often be able to find the remaining bit by using the same passive DNS to look for similar domains with additional characters, or you can find them while simply googling for the bit you have. Do however keep some caution while doing this, as not every first result will be the one you’re looking for. E.g. uo8igvgkvslrh9b9e6vi0edsovertr2s[.]appsync-api[.]us-east-1[.] decodes to ‘csnt.princegeor’. When searching for princegeorge one of the first results ends up as princegeorge[.]ca, which seems plausible, however, with some proper research you will be able to find that princegeorge[.]com, even though seemingly unimportant at first sight, has had an actual subdomain involving ‘csnt’. If you look at who owns princegeorge[.]com, it’s fairly obvious which of the two is way more likely to use Solarwinds software.

Another bit that the tools seem to have problems with, are the domains that contain characters beyond lower alphanumeric characters and “.-_”. As the SUNBURST backdoor uses a different method of encryption for these domains (base32 encoding with a custom alphabet). There are a few options, often consisting of missing pieces or misplaced single/double 0’s when joining parts. When you do know the order of the pieces is correct based on the byte values, check for any potential overlapping/connecting 0’s. Often that solves the issue. As for the missing pieces, you can be a bit cheeky with those.

Image for post
Image for post
Example of tweaking for GUID ‘5EC540468DC722FF’

Sometimes manually joining the parts allows the tool to better understand the given input. If this fails, I prefer to just add a ‘donor’ piece. As we know the backdoor limits it’s pieces to 32 characters max, we know that when we miss the first part out of four parts, that the first part has to be 16 characters starting with 00. Add in the donor and you will get a view of what the other pieces are. Sure, you don’t have the full domain at this point, but knowing what 3/4 pieces make up for is way more information than having none. It also gives you additional options to find the potential missing part with more passive DNS/OSINT work. You could even bruteforce the connecting bit of the missing first and second piece by comparing the results to the first part of the second piece. Will it resolve your entire domain? No, but keep in mind that knowing a single extra character could mean so much more for further passive DNS/OSINT work and potential informing victims/targets.

For those seeking additional passive DNS data or just want to check whether they are a victim/target, I’ve got a sheet with 35k known public subdomains and their transmitted data over here.

Image for post
Image for post
Overview of data in the sheet mentioned above.

I do want to point out that if your domain/hostname is not in this sheet, that it does not mean you/your organisation are not affected. This is NOT the case. This is only information that is known publicly upon this point.

If anyone has additional subdomains that are not in this sheet, feel free to share them with me through Twitter(tweet/dm) or the comment section in the sheet. As I want to contradict a quote from a previous story on the SUNBURST subject;

“the full extent of this breach will most likely never be communicated to the public, and instead will be restricted to trusted parts of the intelligence community.”

The only way the public will not be able to determine the full extent of this breach on its own is by hiding the information that we as a security community have on this attack. This is not your regular hacking/leaked database incident, based on both the sophistication of the campaign and the targeted organisations. I understand that networks need to get investigated and cleaned first, but I would like to ask every affected organisation to be open about their infection(s) and the steps taken afterwards. As for those having access to more DNS data, keep in mind that this is a joint effort and that we’re all missing pieces. Sharing is caring. Follow the example of FireEye. We need subdomains to match domains with pings, we need CNAMES to match with targets, etc. Security isn’t always a business model.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store