{ "id": "dd2c9416-62b4-46b1-aeb1-15d66324b4f1", "created_at": "2026-04-06T00:13:50.505194Z", "updated_at": "2026-04-10T13:11:19.727806Z", "deleted_at": null, "sha1_hash": "ac59c6f49194eca060714c5d016307b02d15832e", "title": "Targeting Process for the SolarWinds Backdoor", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 102233, "plain_text": "Targeting Process for the SolarWinds Backdoor\r\nBy Erik Hjelmvik\r\nPublished: 2021-02-17 · Archived: 2026-04-05 17:48:12 UTC\r\n, \r\nWednesday, 17 February 2021 20:22:00 (UTC/GMT)\r\nThe SolarWinds Orion backdoor, known as SUNBURST or Solorigate, has been analyzed by numerous experts\r\nfrom Microsoft, FireEye and several anti-virus vendors. However, we have noticed that many of the published\r\nreports are either lacking or incorrect in how they describe the steps involved when a client gets targeted by the\r\nthreat actors. We have therefore decided to publish this writeup, which is based on the analysis we did of the\r\nSolarWinds backdoor when creating our SunburstDomainDecoder tool.\r\nUPDATE March 1, 2021\r\nFixed errors in the Stage 2 beacon structure and added a CyberChef recipe link.\r\navsvmcloud.com DNS queries are not DGA related\r\nThe DNS communication between the backdoored SolarWinds Orion clients and the authoritative name server for\r\navsvmcloud.com is not caused by a Domain Generation Algorithm (DGA), it's actually a fully functional two-way\r\ncommunication C2 channel. The clients encode information, such as the internal AD domain and installed security\r\napplications into the DNS queries and the DNS responses from the name server are used to instruct the clients to\r\ncontinue beaconing, stop beaconing or to target a client by proceeding to what we call Stage 2 operation. Thus, the\r\nauthoritative name server for avsvmcloud.com was actually the C2 server for Stage 1 and 2 operation of the\r\nSolarWinds backdoor.\r\nImage: SolarWinds Backdoor State Diagram\r\nhttps://netresec.com/?b=212a6ad\r\nPage 1 of 6\n\nCommand: Continue Beaconing\r\nThe default response from the name server is the \"Continue Beaconing\" command, which indicates that the threat\r\nactors have not yet decided if the SolarWinds client is of interest for further activity. Receiving a DNS A record in\r\nany of the following net ranges instructs the SolarWinds backdoor to continue beaconing:\r\n8.18.144.0/23\r\n71.152.53.0/24\r\n87.238.80.0/21\r\n199.201.117.0/24\r\nIn \"Stage 1\" operation the SUNBURST client starts out in the \"New\" mode where it exfiltrates the internal AD\r\ndomain name. The AD domain data is often split into multiple DNS queries to reduce the length of each DNS\r\nquery. The client later proceeds to the \"Append\" mode when the full AD domain has been exfiltrated. In \"Append\"\r\nmode the client transmits a list of installed or running security applications to the DNS C2 server, as we have\r\ndescribed in our Extracting Security Products from SUNBURST DNS Beacons blog post. The client remains in\r\nAppend mode until it gets either terminated or targeted.\r\nNote: It is also possible to reset a client back to the \"New\" mode with a so-called \"Ipx\" command, but that is out\r\nof scope for this blog post.\r\nCommand: Stop Beaconing\r\nThe stop beaconing command terminates the DNS beaconing, so that the client no longer retrieves any commands\r\nfrom the C2 server. The C2 communication is stopped after receiving a DNS DNS A or AAAA record in any of\r\nthe following ranges:\r\n20.140.0.0/15\r\n96.31.172.0/24\r\n131.228.12.0/22\r\n144.86.226.0/24\r\n10.0.0.0/8\r\n172.16.0.0/12\r\n192.168.0.0/16\r\n224.0.0.0/3\r\nfc00:: - fe00::\r\nfec0:: - ffc0::\r\nff00::\r\nCommand: Target Client\r\nA SUNBURST client that has been \"targeted\" will change a flag called rec.dnssec in the source code from false to\r\ntrue. We call this flag the \"Stage 2\" flag, which must be set in order for the client to accept a CNAME record and\r\nproceed to Stage 3. Symantec refer to the Stage 2 flag as \"a bit flag representing whether the previous DNS\r\nresponse successfully contained partial or full instructions to start the secondary HTTP communication channel\".\r\nhttps://netresec.com/?b=212a6ad\r\nPage 2 of 6\n\nA DNS A record in any of the following three IP ranges can be used to set the \"Stage 2\" flag:\r\n18.130.0.0/16\r\n99.79.0.0/16\r\n184.72.0.0/15\r\nThe state of the Stage 2 flag is actually signaled in the avsvmcloud.com DNS queries, which is how we managed\r\nto identify the AD domains of 23 targeted organizations just by analyzing SUNBURST DNS queries.\r\nStage 2 DNS Request Structure\r\nThe structure of the SUNBURST DNS queries in Stage 1 is pretty well described by Prevasio and Symantec, so\r\nwe will not cover those in this blog post. Instead we will focus specifically on the structure of the DNS queries\r\ntransmitted in Stage 2 operation, where the clients request a CNAME record from the name server.\r\nAs we have explained previously the exfiltrated data gets base32 encoded, using the custom alphabet\r\n\"ph2eifo3n5utg1j8d94qrvbmk0sal76c\", in order to ensure that only valid domain name characters are used in the\r\nDNS beacons.\r\nThe structure of the Stage 2 request, before it gets base32 encoded and appended as an avsvmcloud.com\r\nsubdomain, looks like this:\r\nField Size Description\r\nXOR Key 8 bits A value between 0x01 and 0x7F used to XOR encrypt the rest of the data.\r\nGUID 64 bits\r\nClient ID encrypted using 16 bit rotating XOR with the last 15 bits of Timestamp\r\nand the Stage 2 flag.\r\nPacket Type 4 bits A value of 0x1, could in theory be 0x2 but that's very unlikely.\r\nTimestamp 19 bits Number of 30 minute periods since start of 2010 (UTC).\r\nStage 2 Flag 1 bit A flag set to \"1\" in Stage 2 operation, otherwise \"0\".\r\nhttps://netresec.com/?b=212a6ad\r\nPage 3 of 6\n\nImage: Stage 2 beacon structure of the SolarWinds backdoor\r\nThe base32 encoding not only uses a custom alphabet, it also employs a reversed endianess and byte order\r\ncompared to \"normal\" implementations. We have created a CyberChef recipe that performs this custom base32\r\ndecoding, so that the structure can be verified more easily. A list with 45 different Stage 2 avsvmcloud.com\r\nsubdomains can be found in our Finding Targeted SUNBURST Victims with pDNS blog post. Feel free to replace\r\nthe input to our CyberChef recipe with any of those subdomains.\r\nSleep Timers\r\nThe DNS responses from the name server not only controls how the SolarWinds backdoor should transition\r\nbetween the various stages, it also controls for how long the backdoor should wait before sending the next DNS\r\nbeacon.\r\nThe delay is assigned by AND-ing the last octet of the received IP address with bitmask 0x54. The result from the\r\nAND operation is then used to select a sleep interval in the table below, within which the client picks a random\r\nnumber of minutes to sleep.\r\nAND Result Name Sleep Interval\r\n0x00 1 hour 30-120 minutes\r\n0x04 4 hours 240-300 minutes\r\n0x10 8 hours 480-600 minutes\r\n0x14 1 day 1440-1560 minutes\r\n0x40 3 days 4320-5760 minutes\r\n0x44 1 week 10020-10140 minutes\r\n0x50 2 weeks 20100-20220 minutes\r\n0x54 1 month 43140-43260 minutes\r\nAn exception to the table above is clients that have entered Stage 2, which will only wait one to three minutes\r\nbefore requesting a CNAME.\r\nExample DNS C2 for a Non-Targeted Client\r\nBelow is an example of DNS queries and responses from a SUNBURST client that wasn't targeted by the threat\r\nactors. These particular queries and responses come from a post on SolarWinds' community forum.\r\n2020-07-04 00:03 UTC\r\nQuery: if9prvp9o36mhihw2hrs260g12eu1 ⇒ AD domain \"omeros.local\"\r\nResponse: 8.18.145.139 ⇒ sleep 1h, then Continue\r\nhttps://netresec.com/?b=212a6ad\r\nPage 4 of 6\n\n2020-07-04 01:08 UTC\r\nQuery: hnhb3v1b37dvv09icg0edp0 ⇒ Carbon Black is running\r\nResponse: 8.18.145.62 ⇒ sleep 1 day, then Continue\r\n2020-07-05 01:15 UTC\r\nQuery: ea99hr2sfen95nkjlc5g ⇒ Nothing new to report\r\nResponse: 8.18.144.150 ⇒ sleep 1 day, then Continue\r\n2020-07-06 02:42 UTC\r\nQuery: 707gigk9vbc923hf27fe ⇒ Nothing new to report\r\nResponse: 8.18.145.151 ⇒ sleep 1 day, then Continue\r\n2020-07-07 03:52 UTC\r\nQuery: 6eivqct649pcg0g16ol4 ⇒ Nothing new to report\r\nResponse: 20.140.84.127 ⇒ Stop DNS beacon\r\nNote: Queried domain names in this list are subdomains of appsync-api.eu-west-1.avsvmcloud.com.\r\nExample DNS C2 for a Targeted Client\r\nDisclaimer: We have very few DNS queries and responses for targeted victims, hence the transactions below are\r\nimprovised based on data from VriesHd, Joe Słowik and FireEye. Please view these transactions as an example of\r\nwhat the communication might look like for a targeted victim rather than what actually happened to this\r\nparticular target.\r\n2020-06-11 04:00 UTC\r\nQuery: r8stkst71ebqgj66ervisu10bdohu0gt ⇒ AD domain, part 1 \"central.pima.g\"\r\nResponse: 8.18.144.1 ⇒ Sleep 1h, then Continue\r\n2020-06-11 05:00 UTC\r\nQuery: ulfmcf44qd58t9e82w ⇒ AD domain, part 2 \"ov\"\r\nResponse: 8.18.144.2 ⇒ Sleep 1h, then Continue\r\n2020-06-11 06:00 UTC\r\nQuery: p50jllhvhmoti8mpbf6p2di ⇒ Nothing to report\r\nResponse: 8.18.144.16 ⇒ Sleep 8h, then Continue\r\n2020-06-11 14:00 UTC\r\nQuery: (?) ⇒ Nothing new to report\r\nResponse: 8.18.144.17 ⇒ Sleep 8h, then Continue\r\n2020-06-11 22:35 UTC\r\nQuery: j5uqlssr1hfqnn8hkf172mp ⇒ Nothing to report\r\nResponse: 184.72.181.52 ⇒ Target client for Stage 2 operation (1-3 minutes sleep)\r\n2020-06-11 22:37 UTC\r\nQuery: 7sbvaemscs0mc925tb99 ⇒ Client in Stage 2 operation, requesting CNAME\r\nResponse: deftsecurity.com ⇒ CNAME for Stage 3 HTTPS C2 server\r\nNote: Queried domains in this list are subdomains of appsync-api.us-west-2.avsvmcloud.com.\r\nConclusions\r\nhttps://netresec.com/?b=212a6ad\r\nPage 5 of 6\n\nWe hope this blog post clears up any misunderstandings regarding the targeting process of the SolarWinds\r\nbackdoor and highlights the significance of the Stage 2 flag.\r\nWe warmly welcome any feedback or questions you might have regarding this writeup, please feel free to contact\r\nus or reach out to us through Twitter.\r\nPosted by Erik Hjelmvik on Wednesday, 17 February 2021 20:22:00 (UTC/GMT)\r\nTags: #SolarWinds#backdoor#SUNBURST#Solorigate#FireEye#Microsoft#CNAME#STAGE2#Stage 2#DNS\r\n#avsvmcloud.com#C2#CyberChef#ASCII-art\r\nSource: https://netresec.com/?b=212a6ad\r\nhttps://netresec.com/?b=212a6ad\r\nPage 6 of 6\n\nGUID 64 bits and the Stage 2 flag. \nPacket Type 4 bits A value of 0x1, could in theory be 0x2 but that's very unlikely.\nTimestamp 19 bits Number of 30 minute periods since start of 2010 (UTC).\nStage 2 Flag 1 bit A flag set to \"1\" in Stage 2 operation, otherwise \"0\".\n Page 3 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://netresec.com/?b=212a6ad" ], "report_names": [ "?b=212a6ad" ], "threat_actors": [], "ts_created_at": 1775434430, "ts_updated_at": 1775826679, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/ac59c6f49194eca060714c5d016307b02d15832e.pdf", "text": "https://archive.orkl.eu/ac59c6f49194eca060714c5d016307b02d15832e.txt", "img": "https://archive.orkl.eu/ac59c6f49194eca060714c5d016307b02d15832e.jpg" } }