{ "id": "f759a1df-599d-4136-a7b3-d4288569f899", "created_at": "2026-04-06T00:13:19.360216Z", "updated_at": "2026-04-10T03:30:33.324334Z", "deleted_at": null, "sha1_hash": "1ea434b79cbca029e874de45de644af4f66f531c", "title": "Finding SUNBURST victims and targets by using passive DNS, OSINT", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 216431, "plain_text": "Finding SUNBURST victims and targets by using passive DNS,\r\nOSINT\r\nBy VriesHD\r\nPublished: 2021-01-23 · Archived: 2026-04-05 13:37:53 UTC\r\nFor over a month now, the hack of SolarWinds’ Orion IT management platform has been present in the news\r\nregularly with plenty of interesting discoveries on the modus operandi of the attackers and the effects of the hack\r\non several targeted companies and government branches. However, there’s been little information about some of\r\nthe connections that SUNBURST has shared ‘in public’ and the stories of the affected organisations, while there\r\nhave also been some stories that tried to grasp these connections, but ended up in providing the opposite effect; a\r\nfalse sense of security.\r\nA quick summary for those who’ve not been aware of this recent hack yet; On December 13, 2020, FireEye put\r\nout a post sharing that they “discovered a supply chain attack trojanizing SolarWinds Orion business software\r\nupdates in order to distribute malware”. After some research, it turned out that up to 18.000 SolarWinds customers\r\ncould’ve potentially received the trojanized updates for the Orion software. These customers should be considered\r\n‘victims’ of the attack. Only ‘high value’ organisations of interest to the attackers received additional malicious\r\nsoftware intended for further exploitation. These customers should be considered ‘targets’ of the attack.\r\nDecrypting SUNBURST domains\r\nThere have been plenty of posts and tools on how to decrypt SUNBURST domains so I’ll try to keep this as short\r\nas possible:\r\nIn general, the SUNBURST backdoor collects several kinds of information about the infected system, encrypts\r\nthis information into a combination of strings, adds these together, and sends this information back to the attackers\r\nthrough the use of DNS requests for subdomains of the avsvmcloud[.]com domain. To be specific, the subdomains\r\nare always similar to the following patterns:\r\n[subdomain].appsync-api.eu-west-1[.]avsvmcloud[.]com\r\n[subdomain].appsync-api.us-west-2[.]avsvmcloud[.]com\r\n[subdomain].appsync-api.us-east-1[.]avsvmcloud[.]com\r\n[subdomain].appsync-api.us-east-2[.]avsvmcloud[.]com\r\nEven 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\r\nanything on the encoded data that’s been submitted in the third-subdomain. Their only intention so far seems to be\r\nto mimic services like AmazonAWS to give the made connections some form of legitimacy. Occasionally I’ve\r\nhttps://vrieshd.medium.com/finding-sunburst-victims-and-targets-by-using-passivedns-osint-68f5704a3cdc\r\nPage 1 of 4\n\nseen several variations on these four first-subdomains like cn-west-1, eu-west-2, and us-west-1 yet there is no\r\nindication that these subdomains have been in use by the backdoor itself.\r\nAs for the third-subdomain, this is where the transferred data comes into play. I don’t want to get too much into\r\nthe actual encryption/decryption as others like RedDrip Team from QiAnXin Technology, Prevasio, Cloudflare\r\nand NETRESEC have already written detailed reports on this. In summary, these subdomains consist of the\r\nfollowing parts: an encoded GUID, a byte that functions as the XORkey for the GUID and the hostname of the\r\nlocal 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\r\nthe attackers as well as the community important information about the infected systems.\r\nPassive DNS and the post-December noise\r\nAs mentioned above, the SUNBURST backdoor reports back to the avsmcloud[.]com domain with the collected\r\ndata in the shape of DNS requests for a specific subdomain. So collecting as much as these requests as possible is\r\nimportant as in a lot of cases the collected data is transferred from the backdoor to the attackers in several batches\r\n(e.g. local hostnames and timestamps are never sent together, nor do long hostnames get sent in one request but\r\nare fragmented in multiple queries based on their length as the subdomains are limited to a max length of 32\r\ncharacters). There are many ways to get passive DNS on avsmcloud[.]com, there are several pastebins with lists of\r\npassive DNS and there are several parties like RiskIQ, FarSight DNSDB, VirusTotal, and others that have big lists\r\nof records for the domain. However, after the first reports came out about the hack, the passive DNS results for\r\navsmcloud[.]com subdomains have kind of gotten out of hand as the domain accepted any request due to the lack\r\nof knowing what kind of systems were running the Solarwinds software and malicious updates, both before and\r\nafter the Microsoft takeover. Combined with the messy nature of passive DNS on its own, it turned out into a bit\r\nof a mess… And that’s an understatement with close to 200k recorded subdomains.. and probably way more as\r\nthis is only based on my findings…\r\na small portion of passive DNS data on avsmcloud[.]com\r\nFortunately, there are a few clues that helping sorting through this noise:\r\nGet VriesHD’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nhttps://vrieshd.medium.com/finding-sunburst-victims-and-targets-by-using-passivedns-osint-68f5704a3cdc\r\nPage 2 of 4\n\nRemember me for faster sign in\r\nFirst of all, we know the backdoor communicates in the mentioned patterns as mentioned above so that sorts out a\r\nbig part of the noise (set the odd cn-west-1, etc. subdomains aside for a bit, as their third-subdomains could still\r\ncontain actual information). Second, we know the GUID and XORkey make up 16 characters and the backdoor\r\nhas a 32 character limit, so the third-subdomain should be between 17 and 32 characters long. Furthermore, you\r\ncan discard any subdomains that contain any symbols in the third-subdomain.\r\nThe SUNBURST Puzzles\r\nNow that you’ve got a decent bunch of DNS requests, you can start decoding the subdomains with tools such as\r\nthe ones provided by RedDrip, FireEye, or NETRESEC. Their tools will do a lot of work for you, and sometimes\r\neven do all the work, depending on the amount of data you supply to the tools. The GUID’s come into play to help\r\nwith connecting the separate queries, as that specific GUID stays unique to the infected system regardless of the\r\nXOR’ing of the GUID. This way you’re also able to match encoded timestamps to hostnames and the other way\r\naround. The XORkey, however, is also an indicator for longer split domains on which part is based on the decoded\r\nvalue of the byte, ranging from 0 to 35. The first part of the payload will have a byte value of 0 if the domain is\r\nlong enough to require multiple requests. The last part of the payload will always have a byte value of 35. Infected\r\nsystems with short domain names will have only one request with a byte value of 35. This is kinda tricky as it’s\r\nnot always clear whether a domain is the last part of a fragmented domain, or just very short.\r\nMost of this will work out just fine, however, sometimes you will find yourself ending up missing a piece or two\r\nfor a full domain. In the case of only lowercase alphanumeric domains, this ain’t too much of a problem as you\r\nwill often be able to find the remaining bit by using the same passive DNS to look for similar domains with\r\nadditional characters, or you can find them while simply googling for the bit you have. Do however keep some\r\ncaution while doing this, as not every first result will be the one you’re looking for. E.g.\r\nuo8igvgkvslrh9b9e6vi0edsovertr2s[.]appsync-api[.]us-east-1[.]avsvmcloud.com decodes to ‘csnt.princegeor’.\r\nWhen searching for princegeorge one of the first results ends up as princegeorge[.]ca, which seems plausible,\r\nhowever, with some proper research you will be able to find that princegeorge[.]com, even though seemingly\r\nunimportant at first sight, has had an actual subdomain involving ‘csnt’. If you look at who owns\r\nprincegeorge[.]com, it’s fairly obvious which of the two is way more likely to use Solarwinds software.\r\nAnother bit that the tools seem to have problems with, are the domains that contain characters beyond lower\r\nalphanumeric characters and “.-_”. As the SUNBURST backdoor uses a different method of encryption for these\r\ndomains (base32 encoding with a custom alphabet). There are a few options, often consisting of missing pieces or\r\nmisplaced single/double 0’s when joining parts. When you do know the order of the pieces is correct based on the\r\nbyte values, check for any potential overlapping/connecting 0’s. Often that solves the issue. As for the missing\r\npieces, you can be a bit cheeky with those.\r\nSometimes manually joining the parts allows the tool to better understand the given input. If this fails, I prefer to\r\njust add a ‘donor’ piece. As we know the backdoor limits it’s pieces to 32 characters max, we know that when we\r\nmiss the first part out of four parts, that the first part has to be 16 characters starting with 00. Add in the donor and\r\nyou will get a view of what the other pieces are. Sure, you don’t have the full domain at this point, but knowing\r\nwhat 3/4 pieces make up for is way more information than having none. It also gives you additional options to\r\nhttps://vrieshd.medium.com/finding-sunburst-victims-and-targets-by-using-passivedns-osint-68f5704a3cdc\r\nPage 3 of 4\n\nfind the potential missing part with more passive DNS/OSINT work. You could even bruteforce the connecting bit\r\nof the missing first and second piece by comparing the results to the first part of the second piece. Will it resolve\r\nyour entire domain? No, but keep in mind that knowing a single extra character could mean so much more for\r\nfurther passive DNS/OSINT work and potential informing victims/targets.\r\nFor those seeking additional passive DNS data or just want to check whether they are a victim/target, I’ve got a\r\nsheet with 35k known public subdomains and their transmitted data over here.\r\nI do want to point out that if your domain/hostname is not in this sheet, that it does not mean you/your\r\norganisation are not affected. This is NOT the case. This is only information that is known publicly upon this\r\npoint.\r\nIf anyone has additional subdomains that are not in this sheet, feel free to share them with me through\r\nTwitter(tweet/dm) or the comment section in the sheet. As I want to contradict a quote from a previous story on\r\nthe SUNBURST subject;\r\n“the full extent of this breach will most likely never be communicated to the public, and instead will be\r\nrestricted to trusted parts of the intelligence community.”\r\nThe only way the public will not be able to determine the full extent of this breach on its own is by hiding the\r\ninformation that we as a security community have on this attack. This is not your regular hacking/leaked database\r\nincident, based on both the sophistication of the campaign and the targeted organisations. I understand that\r\nnetworks need to get investigated and cleaned first, but I would like to ask every affected organisation to be open\r\nabout their infection(s) and the steps taken afterwards. As for those having access to more DNS data, keep in mind\r\nthat this is a joint effort and that we’re all missing pieces. Sharing is caring. Follow the example of FireEye. We\r\nneed subdomains to match domains with pings, we need CNAMES to match with targets, etc. Security isn’t\r\nalways a business model.\r\nSource: https://vrieshd.medium.com/finding-sunburst-victims-and-targets-by-using-passivedns-osint-68f5704a3cdc\r\nhttps://vrieshd.medium.com/finding-sunburst-victims-and-targets-by-using-passivedns-osint-68f5704a3cdc\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://vrieshd.medium.com/finding-sunburst-victims-and-targets-by-using-passivedns-osint-68f5704a3cdc" ], "report_names": [ "finding-sunburst-victims-and-targets-by-using-passivedns-osint-68f5704a3cdc" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434399, "ts_updated_at": 1775791833, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/1ea434b79cbca029e874de45de644af4f66f531c.pdf", "text": "https://archive.orkl.eu/1ea434b79cbca029e874de45de644af4f66f531c.txt", "img": "https://archive.orkl.eu/1ea434b79cbca029e874de45de644af4f66f531c.jpg" } }