{ "id": "8b862028-03a3-4c73-ab34-ae09913e96a0", "created_at": "2026-04-06T00:19:14.702787Z", "updated_at": "2026-04-10T13:12:27.357523Z", "deleted_at": null, "sha1_hash": "611aa8ce75cf1225602b5d8542a836a0c39092fc", "title": "Sunburst: connecting the dots in the DNS requests", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 332307, "plain_text": "Sunburst: connecting the dots in the DNS requests\r\nBy Igor Kuznetsov\r\nPublished: 2020-12-18 · Archived: 2026-04-05 21:47:27 UTC\r\nOn December 13, 2020 FireEye published important details of a newly discovered supply chain attack. An\r\nunknown attacker, referred to as UNC2452 or DarkHalo planted a backdoor in the SolarWinds Orion IT software.\r\nThis backdoor, which comes in the form of a .NET module, has some really interesting and rather unique features.\r\nWe spent the past days checking our own telemetry for signs of this attack, writing additional detections and\r\nmaking sure that our users are protected. At the moment, we identified approximately ~100 customers who\r\ndownloaded the trojanized package containing the Sunburst backdoor. Further investigation is ongoing and we\r\nwill continue to update with our findings.\r\nNow, several things really stand out for this incident. This supply chain attack was designed in a very professional\r\nway – kind of putting the “A” in “APT” – with a clear focus on staying undetected for as long as possible. For\r\ninstance, before making the first internet connection to its C2s, the Sunburst malware lies dormant for a long\r\nperiod, of up to two weeks, which prevents an easy detection of this behavior in sandboxes. Other advanced threat\r\ngroups are also known to adopt similar strategies, for instance with hardware or firmware implants, which “sleep”\r\nfor weeks or months before connecting to their C2 infrastructure. This explains why this attack was so hard to\r\nspot.\r\nOne of the things that sets this apart from other cases, is the peculiar victim profiling and validation scheme.\r\nThrough the SolarWinds Orion IT packages, the attackers reached about 18,000 customers, according to the\r\nSolarWinds alert. Yet, out of these 18.000, it would appear that only a handful were interesting to them.\r\nConsidering the fact that having the resources to manually exploit 18,000 computer networks is probably outside\r\nthe reach of most if not all the attackers out there, this leads to the point that obviously some of those would have\r\nbeen a higher priority. Finding which of the 18,000 networks were further exploited, receiving more malware,\r\ninstalling persistence mechanisms and exfiltrating data is likely going to cast some light into the attacker’s\r\nmotives and priorities.\r\nIn the initial phases, the Sunburst malware talks to the C\u0026C server by sending encoded DNS requests. These\r\nrequests contain information about the infected computer; if the attackers deem it interesting enough, the DNS\r\nresponse includes a CNAME record pointing to a second level C\u0026C server.\r\nOur colleagues from FireEye published several DNS requests that supposedly led to CNAME responses on\r\nGithub:\r\nhttps://github.com/fireeye/sunburst_countermeasures/blob/main/indicator_release/Indicator_Release_NBIs.csv\r\nhttps://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/\r\nPage 1 of 8\n\nDNS CNAME request-response pairs (Copyright 2020 by FireEye, Inc.)\r\nThe goal\r\nKnowing that the DNS requests generated by Sunburst encode some of the target’s information, the obvious next\r\nstep would be to extract that information to find out who the victims are!\r\nOur colleagues from QiAnXin Technology already published a Python script to decode the domain names (on\r\nGithub, of course): https://github.com/RedDrip7/SunBurst_DGA_Decode/blob/main/decode.py . Unfortunately,\r\nthat script cannot decode all the DNS requests, besides it is always good to practice in reverse engineering\r\nanyway, so let’s look in the malware code.\r\nTL;DR\r\nThree of the requests from FireEye’s Github repository can be mapped to two domain names that belong to\r\na government organization and a telecommunications company in the US.\r\nLow-level details\r\nThe sample we’ll be analyzing is 2c4a910a1299cdae2a4e55988a2f102e. All we need is a .NET decompiler\r\n(dnSpy is a good one).\r\nThe logic that is interesting to us is located in OrionImprovementBusinessLayer.Update, which in turn calls one of\r\nthe four functions: GetCurrentString, GetPreviousString, GetNextStringEx and GetNextString.\r\nThese four functions correspond to four different DNS-based communication methods.\r\nNow, to find out what kind of data is encoded in the DNS requests (the hostname variable) we need to look closer\r\ninto each one of these functions.\r\nhttps://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/\r\nPage 2 of 8\n\nThe first function GetCurrentString generates strings that contain a supposedly unique target’s identifier\r\n(this.guid), the target’s hostname (this.dnStrLower) and the rest of the hostname that will be in form of “appsync-api.*.avsvmcloud[.]com”. The encoding of the data is done by the functions CreateSecureString and CreateString.\r\nThe function GetPreviousString is bigger, but produces a similar hostname for a DNS request. It includes a part of\r\nthe target’s hostname in the request, so that it would match the limitations on the request length. Each such request\r\nalso includes the sequence number (this.nCount) that is the offset of the current substring from the beginning of\r\nthe hostname.\r\nThe remaining two functions, GetNextStringEx and GetNextString, generate a different type of DNS requests.\r\nThey include only the target’s UID, hashes of the running processes of interest and (only in the Ex version) the list\r\nand status of these processes. The target’s UID is then encrypted, and the data is encoded with\r\nCreateSecureString.\r\nThe problem\r\nhttps://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/\r\nPage 3 of 8\n\nThe encryption used in the malware is just a simple XOR operation, and the encoding is either a substitution\r\ncipher or Base32 with a custom alphabet. However, if we reverse the sequence of operations of GetPreviousString\r\nor GetCurrentString for the known CNAME DNS requests published by FireEye, the resulting strings don’t look\r\nlike valid domain names!\r\nA possible explanation is that the requests were generated by the third or fourth communication methods,\r\ndescribed as GetNextStringEx or GetNextString. Indeed, they can be decoded without errors and the size of\r\ndecoded data fits.  However, these requests don’t have the target’s name included!\r\nThe solution\r\nAt this point, a question arises – can we match any of existing private and public DNS data for the malware root\r\nC2 domain, “avsvmcloud[.]com” with the CNAME records, to identify who was targeted for further exploitation?\r\nA list of SUNBURST-generated domain names that include the domain names were kindly shared by John\r\nBambenek on Github: https://github.com/bambenek/research/blob/main/sunburst/uniq-hostnames.txt .\r\nHere’s a few such examples:\r\nnnbggtlr1iv0v3vfnfaddfe.appsync-api.us-west-2.avsvmcloud[.]com\r\nnq97kdu88pn1qpv8f3t5.appsync-api.us-east-1.avsvmcloud[.]com\r\nnr2ia9qfa349b0q2oi60bou6iuir02rn.appsync-api.us-east-1.avsvmcloud[.]com\r\nWe complemented John’s data with our own datasets as well as other publicly available pDNS databases. Each\r\none of these DNS requests also has the Base32-encoded UID. Since the UIDs are also included in other types of\r\nrequests (types 3 and 4) in encrypted form, this allows us to match the requests!\r\nThe target’s UID is calculated in OrionImprovementBusinessLayer.GetOrCreateUserID by MD5-hashing the\r\nMAC address of the first online network adapter, then XORing it down to 64 bits.\r\nhttps://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/\r\nPage 4 of 8\n\nThe DNS requests published by FireEye on their GitHub have the following encrypted UIDs inside:\r\nDNS request UID (64 bit)\r\n6a57jk2ba1d9keg15cbg.appsync-api.eu-west-1.avsvmcloud[.]com 0xEED328E059EB07FC\r\n7sbvaemscs0mc925tb99.appsync-api.us-west-2.avsvmcloud[.]com 0x683D2C991E01711D\r\ngq1h856599gqh538acqn.appsync-api.us-west-2.avsvmcloud[.]com 0x2956497EB4DD0BF9\r\nihvpgv9psvq02ffo77et.appsync-api.us-east-2.avsvmcloud[.]com 0xF7A37335B9E57DDB\r\nk5kcubuassl3alrf7gm3.appsync-api.eu-west-1.avsvmcloud[.]com 0xA46E6E874771323C\r\nmhdosoksaccf9sni9icp.appsync-api.eu-west-1.avsvmcloud[.]com 0xA46E6E874771323C\r\nIn total, we analyzed 1722 DNS records, leading to 1026 unique target name parts and 964 unique UIDs.\r\nMatching the two lists we got the following data:\r\ndomain name part(0x2956497EB4DD0BF9)=central.****.g\r\ndomain name part(0x2956497EB4DD0BF9)=ov\r\nhttps://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/\r\nPage 5 of 8\n\ndomain name part(0x683D2C991E01711D)=central.****.g\r\ndomain name part(0x683D2C991E01711D)=ov\r\ndomain name part(0xF7A37335B9E57DDB)=***net.***.com\r\nThese steps effectively decoded 3 of the 6 CNAME records provided by FireEye into two possible domains:\r\n***net.***.com – a rather big telecommunications company from the US, serving more than 6 million\r\ncustomers\r\ncentral.***.gov – a governmental organization from the US\r\nPlease note that for ethical reasons, we do not include these exact domain names here. We notified the two\r\norganizations in question though, offering our support to discover further malicious activities, if needed.\r\nIt should also be noted that there is no way to be sure that machines in these two domains were actually further\r\nexploited. This being a probabilistic puzzle, we can assume with a high degree of certitude the two decoded\r\ndomains were interesting to the attackers, however, we cannot be 100% sure that associated organizations were\r\nthe subject of further malicious activities.\r\nTo summarize our research, the UIDs we discovered match two domain names that belong to a US government\r\norganization and a large US telecommunications company. It is likely that other interesting targets were selected\r\nby the attackers for further exploitation. If you happen to have access to large DNS databases, including CNAME\r\nreplies for any subdomain in “avsvmcloud[.]com”, please let us know! (contact: intelreports (at) kaspersky [dot]\r\ncom)\r\nIn order to help the community to potentially identify other interesting targets for the attackers, we are publishing\r\nthe source code for the decoder:\r\nhttps://github.com/2igosha/sunburst_dga\r\nStay safe!\r\nMore details and mitigations about Sunburst, UNC2452 / DarkHalo are available to customers of Kaspersky\r\nIntelligence Reporting. Contact: intelreports (at) kaspersky [dot] com\r\nSunburst / UNC2452 / DarkHalo FAQ\r\n1. 1 Who is behind this attack? I read that some people say APT29/Dukes?\r\nAt the moment, there are no technical links with previous attacks, so it may be an entirely new actor, or a\r\npreviously known one that evolved their TTPs and opsec to the point where they can’t be linked anymore.\r\nVolexity, who previously worked on other incidents related to this, named the actor DarkHalo. FireEye\r\nnamed them “UNC2452”, suggesting an unknown actor. While some media sources linked this with\r\nAPT29/Dukes, this appears to be either speculation or based on some other, unavailable data, or weak\r\nTTPs such as legitimate domain re-use.\r\n2. 2 I use Orion IT! Was I a target of this attack?\r\nFirst of all, we recommend scanning your system with an updated security suite, capable of detecting the\r\ncompromised packages from SolarWinds. Check your network traffic for all the publicly known IOCs –\r\nsee https://github.com/fireeye/sunburst_countermeasures. The fact that someone downloaded the trojanized\r\nhttps://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/\r\nPage 6 of 8\n\npackages doesn’t also mean they were selected as a target of interest and received further malware, or\r\nsuffered data exfiltration. It would appear, based on our observations and common sense, that only a\r\nhandful of the 18,000 Orion IT customers were flagged by the attackers as interesting as were further\r\nexploited.\r\n3. 3 Was this just espionage or did you observe destructive activities, such as ransomware?\r\nWhile the vast majority of the high-profile incidents nowadays include ransomware or some sort of\r\ndestructive payload (see NotPetya, Wannacry) in this case, it would appear the main goal was espionage.\r\nThe attackers showed a deep understanding and knowledge of Office365, Azure, Exchange, Powershell\r\nand leveraged it in many creative ways to constantly monitor and extract e-mails from their true victims’\r\nsystems.\r\n4. 4 How many victims have been identified?\r\nSeveral publicly available data sets, such as the one from John Bambenek, include DNS requests encoding\r\nthe victim names. It should be noted that these victim names are just the “first stage” recipients, not\r\nnecessarily the ones the attackers deemed interesting. For instance, out of the ~100 Kaspersky users with\r\nthe trojanized package, it would appear that none were interesting to the attackers to receive the 2nd stage\r\nof the attack.\r\n5. 5 What are the most affected countries?\r\nTo date, we observed users with the trojanized Orion IT package in 17 countries. However, the total\r\nnumber is likely to be larger, considering the official numbers from SolarWinds.\r\n6. 6 Why are you calling this an attack, when it’s just exploitation? (CNA vs CNE)\r\nSorry for the terminology, we simply refer to it as a “supply chain attack”. It would be odd to describe it as\r\na “supply chain exploitation”.\r\n7. 7 Out of the 18,000 first stage victims, how many were interesting to the attackers?\r\nThis is difficult to estimate, mostly because of the lack of visibility and because the attackers were really\r\ncareful in hiding their traces. Based on the CNAME records published by FireEye, we identified only two\r\nentities, a US government organization and a telecommunications company, who were tagged and\r\n“promoted” to dedicated C2s for additional exploitation.\r\n8. 8 Why didn’t you catch this supply chain attack in the first place?\r\nThat’s a good question! In particular, two things made it really stealthy. The slow communication method,\r\nin which the malware lies dormant for up to two weeks, is one of them. The other one is the lack of x86\r\nshellcode; the attackers used a .NET injected module. Last but not least, there was no significant change in\r\nthe file size of the module when the malicious code was added. We observed two suspicious modules in\r\n2019, which jumped from the usual 500k to 900k for SolarWinds.Orion.Core.BusinessLayer.dll. When the\r\nmalicious code was first added, in February 2020, the file didn’t change size in a significant manner. If the\r\nattackers did this on purpose, to avoid future detections, then it’s a pretty impressive thing.\r\n9. 9 What is Teardrop?\r\nAccording to FireEye, Teardrop is malware delivered by the attackers to some of the victims. It is an\r\nunknown memory-only dropper suspected to deliver a customized version of the well-known CobaltStrike\r\nBEACON. To date, we haven’t detected any Teardrop samples anywhere.\r\n10. 10 What made this such a successful operation?\r\nProbably, a combination of things – a supply chain attack, coupled with a very well thought first stage\r\nhttps://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/\r\nPage 7 of 8\n\nimplant, careful victim selection strategies and last but not least, no obvious connections to any previously\r\nobserved TTPs.\r\nSource: https://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/\r\nhttps://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/" ], "report_names": [ "99862" ], "threat_actors": [ { "id": "b43e5ea9-d8c8-4efa-b5bf-f1efb37174ba", "created_at": "2022-10-25T16:07:24.36191Z", "updated_at": "2026-04-10T02:00:04.954902Z", "deleted_at": null, "main_name": "UNC2452", "aliases": [ "Dark Halo", "Nobelium", "SolarStorm", "StellarParticle", "UNC2452" ], "source_name": "ETDA:UNC2452", "tools": [], "source_id": "ETDA", "reports": null }, { "id": "1d3f9dec-b033-48a5-8b1e-f67a29429e89", "created_at": "2022-10-25T15:50:23.739197Z", "updated_at": "2026-04-10T02:00:05.275809Z", "deleted_at": null, "main_name": "UNC2452", "aliases": [ "UNC2452", "NOBELIUM", "StellarParticle", "Dark Halo" ], "source_name": "MITRE:UNC2452", "tools": [ "Sibot", "Mimikatz", "Cobalt Strike", "AdFind", "GoldMax" ], "source_id": "MITRE", "reports": null }, { "id": "5b748f86-ac32-4715-be9f-6cf25ae48a4e", "created_at": "2024-06-04T02:03:07.956135Z", "updated_at": "2026-04-10T02:00:03.689959Z", "deleted_at": null, "main_name": "IRON HEMLOCK", "aliases": [ "APT29 ", "ATK7 ", "Blue Kitsune ", "Cozy Bear ", "The Dukes", "UNC2452 ", "YTTRIUM " ], "source_name": "Secureworks:IRON HEMLOCK", "tools": [ "CosmicDuke", "CozyCar", "CozyDuke", "DiefenDuke", "FatDuke", "HAMMERTOSS", "LiteDuke", "MiniDuke", "OnionDuke", "PolyglotDuke", "RegDuke", "RegDuke Loader", "SeaDuke", "Sliver" ], "source_id": "Secureworks", "reports": null }, { "id": "a241a1ca-2bc9-450b-a07b-aae747ee2710", "created_at": "2024-06-19T02:03:08.150052Z", "updated_at": "2026-04-10T02:00:03.737173Z", "deleted_at": null, "main_name": "IRON RITUAL", "aliases": [ "APT29", "Blue Dev 5 ", "BlueBravo ", "Cloaked Ursa ", "CozyLarch ", "Dark Halo ", "Midnight Blizzard ", "NOBELIUM ", "StellarParticle ", "UNC2452 " ], "source_name": "Secureworks:IRON RITUAL", "tools": [ "Brute Ratel C4", "Cobalt Strike", "EnvyScout", "GoldFinder", "GoldMax", "NativeZone", "RAINDROP", "SUNBURST", "Sibot", "TEARDROP", "VaporRage" ], "source_id": "Secureworks", "reports": null }, { "id": "46b3c0fc-fa0c-4d63-a38a-b33a524561fb", "created_at": "2023-01-06T13:46:38.393409Z", "updated_at": "2026-04-10T02:00:02.955738Z", "deleted_at": null, "main_name": "APT29", "aliases": [ "Cloaked Ursa", "TA421", "Blue Kitsune", "BlueBravo", "IRON HEMLOCK", "G0016", "Nobelium", "Group 100", "YTTRIUM", "Grizzly Steppe", "ATK7", "ITG11", "COZY BEAR", "The Dukes", "Minidionis", "UAC-0029", "SeaDuke" ], "source_name": "MISPGALAXY:APT29", "tools": [ "SNOWYAMBER", "HALFRIG", "QUARTERRIG" ], "source_id": "MISPGALAXY", "reports": null }, { "id": "70872c3a-e788-4b55-a7d6-b2df52001ad0", "created_at": "2023-01-06T13:46:39.18401Z", "updated_at": "2026-04-10T02:00:03.239111Z", "deleted_at": null, "main_name": "UNC2452", "aliases": [ "DarkHalo", "StellarParticle", "NOBELIUM", "Solar Phoenix", "Midnight Blizzard" ], "source_name": "MISPGALAXY:UNC2452", "tools": [ "SNOWYAMBER", "HALFRIG", "QUARTERRIG" ], "source_id": "MISPGALAXY", "reports": null }, { "id": "20d3a08a-3b97-4b2f-90b8-92a89089a57a", "created_at": "2022-10-25T15:50:23.548494Z", "updated_at": "2026-04-10T02:00:05.292748Z", "deleted_at": null, "main_name": "APT29", "aliases": [ "APT29", "IRON RITUAL", "IRON HEMLOCK", "NobleBaron", "Dark Halo", "NOBELIUM", "UNC2452", "YTTRIUM", "The Dukes", "Cozy Bear", "CozyDuke", "SolarStorm", "Blue Kitsune", "UNC3524", "Midnight Blizzard" ], "source_name": "MITRE:APT29", "tools": [ "PinchDuke", "ROADTools", "WellMail", "CozyCar", "Mimikatz", "Tasklist", "OnionDuke", "FatDuke", "POSHSPY", "EnvyScout", "SoreFang", "GeminiDuke", "reGeorg", "GoldMax", "FoggyWeb", "SDelete", "PolyglotDuke", "AADInternals", "MiniDuke", "SeaDuke", "Sibot", "RegDuke", "CloudDuke", "GoldFinder", "AdFind", "PsExec", "NativeZone", "Systeminfo", "ipconfig", "Impacket", "Cobalt Strike", "PowerDuke", "QUIETEXIT", "HAMMERTOSS", "BoomBox", "CosmicDuke", "WellMess", "VaporRage", "LiteDuke" ], "source_id": "MITRE", "reports": null }, { "id": "f27790ff-4ee0-40a5-9c84-2b523a9d3270", "created_at": "2022-10-25T16:07:23.341684Z", "updated_at": "2026-04-10T02:00:04.549917Z", "deleted_at": null, "main_name": "APT 29", "aliases": [ "APT 29", "ATK 7", "Blue Dev 5", "BlueBravo", "Cloaked Ursa", "CloudLook", "Cozy Bear", "Dark Halo", "Earth Koshchei", "G0016", "Grizzly Steppe", "Group 100", "ITG11", "Iron Hemlock", "Iron Ritual", "Midnight Blizzard", "Minidionis", "Nobelium", "NobleBaron", "Operation Ghost", "Operation Office monkeys", "Operation StellarParticle", "SilverFish", "Solar Phoenix", "SolarStorm", "StellarParticle", "TEMP.Monkeys", "The Dukes", "UNC2452", "UNC3524", "Yttrium" ], "source_name": "ETDA:APT 29", "tools": [ "7-Zip", "ATI-Agent", "AdFind", "Agentemis", "AtNow", "BEATDROP", "BotgenStudios", "CEELOADER", "Cloud Duke", "CloudDuke", "CloudLook", "Cobalt Strike", "CobaltStrike", "CosmicDuke", "Cozer", "CozyBear", "CozyCar", "CozyDuke", "Danfuan", "EnvyScout", "EuroAPT", "FatDuke", "FoggyWeb", "GeminiDuke", "Geppei", "GoldFinder", "GoldMax", "GraphDrop", "GraphicalNeutrino", "GraphicalProton", "HAMMERTOSS", "HammerDuke", "LOLBAS", "LOLBins", "LiteDuke", "Living off the Land", "MagicWeb", "Mimikatz", "MiniDionis", "MiniDuke", "NemesisGemina", "NetDuke", "OnionDuke", "POSHSPY", "PinchDuke", "PolyglotDuke", "PowerDuke", "QUIETEXIT", "ROOTSAW", "RegDuke", "Rubeus", "SNOWYAMBER", "SPICYBEAT", "SUNSHUTTLE", "SeaDaddy", "SeaDask", "SeaDesk", "SeaDuke", "Sharp-SMBExec", "SharpView", "Sibot", "Solorigate", "SoreFang", "TinyBaron", "WINELOADER", "WellMail", "WellMess", "cobeacon", "elf.wellmess", "reGeorg", "tDiscoverer" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434754, "ts_updated_at": 1775826747, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/611aa8ce75cf1225602b5d8542a836a0c39092fc.pdf", "text": "https://archive.orkl.eu/611aa8ce75cf1225602b5d8542a836a0c39092fc.txt", "img": "https://archive.orkl.eu/611aa8ce75cf1225602b5d8542a836a0c39092fc.jpg" } }