{ "id": "4bccf90c-e145-4868-ab4f-cf7c72c59825", "created_at": "2026-04-06T00:20:11.39347Z", "updated_at": "2026-04-10T13:11:58.785993Z", "deleted_at": null, "sha1_hash": "025a744c915643abe024e116ebb034dcf5d8e0e0", "title": "SolarWinds: Insights into Attacker Command and Control Process", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 51805, "plain_text": "SolarWinds: Insights into Attacker Command and Control Process\r\nBy About the Author\r\nArchived: 2026-04-05 23:07:43 UTC\r\nIn our most recent blog on the SolarWinds attacks, we examined the domain generation algorithm (DGA) used to\r\ninitiate contact with the attackers’ command and control (C\u0026C) servers. The control flow, what happens after that\r\ncontact is made, is also noteworthy.\r\nThe control flow of Sunburst varies depending on commands received from the attacker. However, the general\r\ncontrol flow can be reconstructed in order to understand how communications would have progressed on\r\nmachines that were of interest to the attackers.\r\nAs described in our previous blog, two types of DNS requests are used for initial communications, and both\r\nreceive DNS replies. The attackers use two fields in the DNS replies: “A records” for control flow and CNAME to\r\nhold data on a secondary C\u0026C server.\r\nIP addresses as commands\r\nNormally, when querying DNS, a hostname string is provided to be translated into a numeric IP address, e.g.,\r\ngoogle.com may translate into 142.250.72.238. The IP address is held in the A record of the response. Sunburst\r\nparses the A record for IP addresses, but they are not used as IP addresses at all, but instead are actually triggers\r\nfor different malware behavior. Instead of the attackers selecting random IP addresses to trigger different\r\nbehaviors, they have selected IP address ranges belonging to Google, Amazon, and Microsoft. These are possibly\r\nchosen in order to reduce the chances of detection. Again, these IPs are not used as IP addresses in any way and\r\nthe actual computer systems with these IP addresses are not contacted by the malware.\r\nThe IP address value received in the DNS reply represents one of five behaviors depending on the current state:\r\nContinue sending additional Windows domain name chunks\r\nSend product security status information\r\nLaunch a secondary C\u0026C channel\r\nClean up and exit\r\nReset state as if executing for the first time\r\nFor a typical infection, Sunburst will first send to the C\u0026C server the first 14 characters of the Windows domain\r\nname. This will continue for each 14 character chunk, until the entire Windows Domain name is sent.\r\nNext, the attackers will instruct Sunburst to send the current security product statuses and then send information\r\nenabling Sunburst to launch a more robust secondary HTTP-based C\u0026C.\r\nFigure 1. Example of C\u0026C control flow\r\nFigure 1. Example of C\u0026C control flow\r\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-command-control\r\nPage 1 of 4\n\nWithin any DNS reply, the attackers can also instead instruct Sunburst to restore security product service registry\r\nkeys that were previously disabled back to their believed default settings and quit or reset the internal state as if it\r\nis a fresh infection.\r\nFigure 2. IP address ranges and the behaviors they cause\r\nFigure 2. IP address ranges and the behaviors they cause\r\nIn addition, to facilitate lab environment and sandbox avoidance, if the DNS requests result in a private range IP\r\naddress, including 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, fc00::/7, fec0::/10, ff00::/8, Sunburst\r\nwill also clean up and exit.\r\nSecond stage C\u0026C\r\nVictims that were of interest to the attackers would have reached the secondary C\u0026C stage. In this case, the DNS\r\nreply would contain a hostname in the CNAME record to be used as a HTTP C\u0026C channel. The CNAME value is\r\nchecked to see if it starts with http:// or https:// and is prepended with https:// otherwise.\r\nNext, Sunburst will perform repeated HTTP GET requests to receive commands, sleeping a variable amount of\r\ntime between requests. The path portion of the URL always starts with /swip/upd/ followed by randomly selected\r\nURL patterns, in the following order.\r\nOptionally, one or more of the following:\r\nSolarWinds\r\n.CortexPlugin \r\n.Orion\r\nOptionally, followed by one of the following:\r\n.Wireless\r\n.UI\r\n.Widgets\r\n.NPM\r\n.Apollo\r\n.CloudMonitoring\r\nIf no previous string has been selected, one of the following or optionally, one of the following if a previous string\r\nhas been selected:\r\n.Nodes\r\n.Volumes\r\n.Interfaces\r\n.Components\r\nOptionally, followed by:\r\n-\u003cnumber\u003e.\u003cnumber\u003e.\u003cerror or success code of previous request\u003e\r\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-command-control\r\nPage 2 of 4\n\nFollowed by:\r\n.xml\r\nAlso, if the first character in the path is a dot (.), the dot is removed. For example, the following are example\r\nURLs that could be used:\r\nhttps[:]//infinitysoftwares.com/swip/upd/SolarWinds.CortexPlugin.Nodes-5.2.1.xml\r\nhttps[:]//infinitysoftwares.com/swip/upd/Orion.Wireless.UI-3.1.0.xml\r\nhttps[:]//infinitysoftwares.com/swip/upd/Nodes-1.2.0.xml\r\nThe final digit before the .xml extension is not a random character, but represents the return code for previous\r\ncommand requests – typically 0 means success and 1 or other values mean error. For the first 16 requests, a\r\ndifferent randomly generated path is used each time, but after that it may repeat random generations that it used\r\npreviously. If data is being sent to the attacker as a result of a command (e.g. sending system information), the\r\npath construction will be different and will be covered in a future blog.\r\nSunburst also adds the custom header “If-None-Match:” set to the previously described 8-byte userid XOR’d by a\r\nrandomly generated 8-byte sequence that is appended and then converted into lowercase ASCII hex.\r\nFigure 3. Sunburst custom header\r\nFigure 3. Sunburst custom header\r\nAfter the HTTP GET request is made, Sunburst checks for a valid response from the attacker. The response uses\r\nsteganography and is a faux, but convincing XML page of data, where only certain fields are utilized by Sunburst.\r\nThe faux XML data is searched for a sequence of:\r\n36 hexadecimal characters including dashes\r\n32 hexadecimal characters\r\n16 hexadecimal characters\r\nThese sequences are concatenated together with non-hexadecimal characters removed. The first DWORD (4\r\nbytes) of the sequence represents the size of the remaining data, which is validated and then the next byte is an\r\nXOR key. The rest of the data is then XOR decrypted by the key byte and then decompressed. After being\r\ndecompressed, the first character is a number that specifies the action to perform followed by the number of\r\nincluded arguments in the following data for the command:\r\nFigure 4. A contrived example of data received by Sunburst that is decoded to extract the\r\ncommand\r\nFigure 4. A contrived example of data received by Sunburst that is decoded to extract the command\r\nThe command number can instruct Sunburst to perform the following behaviors:\r\nFigure 5. Command numbers and corresponding behaviors\r\nFigure 5. Command numbers and corresponding behaviors\r\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-command-control\r\nPage 3 of 4\n\nIf no data needs to be sent to the attacker, the above GET request with the return code encoded in the URL\r\nfilename is sent. \r\nIf data needs to be sent to the attacker as a result of these commands (e.g. sending system information), the data\r\nwill be included in the next regular HTTP(S) communication as a POST request or a HEAD request if some error\r\noccurred where the data is missing. Details on each of these behaviors and how data is uploaded to the attacker\r\nwill be covered in an upcoming blog.\r\nProtection/Mitigation\r\nTools associated with these attacks will be detected and blocked on machines running Symantec Endpoint\r\nproducts.\r\nFile-based protection:\r\nBackdoor.Sunburst\r\nBackdoor.Sunburst!gen1\r\nBackdoor.SuperNova\r\nBackdoor.Teardrop\r\nNetwork-based protection:\r\nSystem Infected: Sunburst Malware Activity\r\nFor the latest protection updates, please visit the Symantec Protection Bulletin.\r\nSolarWinds: Insights into Attacker Command and Control Process\r\nThreat Hunter Team\r\nThreat Hunter Team\r\nSymantec and Carbon Black\r\nSource: https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-command-control\r\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-command-control\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "origins": [ "web" ], "references": [ "https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-command-control" ], "report_names": [ "solarwinds-sunburst-command-control" ], "threat_actors": [], "ts_created_at": 1775434811, "ts_updated_at": 1775826718, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/025a744c915643abe024e116ebb034dcf5d8e0e0.pdf", "text": "https://archive.orkl.eu/025a744c915643abe024e116ebb034dcf5d8e0e0.txt", "img": "https://archive.orkl.eu/025a744c915643abe024e116ebb034dcf5d8e0e0.jpg" } }