{ "id": "fcb6cc90-8a75-4e01-95a9-c7c616cf3a98", "created_at": "2026-04-06T00:15:50.918812Z", "updated_at": "2026-04-10T13:11:36.730158Z", "deleted_at": null, "sha1_hash": "2bac0520093458d4be7cf2309efeec3dd474afd4", "title": "SolarWinds: How Sunburst Sends Data Back to the Attackers", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 50250, "plain_text": "SolarWinds: How Sunburst Sends Data Back to the Attackers\r\nBy About the Author\r\nArchived: 2026-04-05 12:55:56 UTC\r\nIn our previous blog we described how the attackers controlled the Sunburst malware, and detailed a variety of\r\ncommands that will result in data being sent to the threat actors. The next technique to discuss is how Sunburst\r\nsends this data to the attackers.\r\nIf data is being sent to the attacker as a result of a command, instead of performing a HTTP(S) GET request,\r\nsomething we described in our last blog, Sunburst initiates a HTTP(S) POST request.\r\nSunburst uses randomly generated URL paths for HTTP(S) POST requests that are different from HTTP(S) GET\r\nrequests.\r\nIf the data to send is greater than 10,000 bytes, the URL path will be as follows:\r\n/pki/crl/{0}{1}-{2}.crl\r\nelement 0 is a number between 100 and 10,000\r\nelement 1 is optionally one of the following:\r\n-root\r\n-cert\r\n-universal_ca\r\n-ca\r\n-primary_ca\r\n-timestamp\r\n-global\r\n-secureca\r\nelement 2 is the last error code\r\nA Content-Type header is set to application/octet-stream and the POST data follows. The POST data consists of\r\nthe data to send UTF8 encoded, concatenated with the last error code, concatenated with the userid, and\r\nsubsequently compressed. Every byte of the compressed blob is then summed and the lowest byte of the sum\r\nvalue is used as a key. The compressed blob is XOR’d by the key byte and the key byte is prepended to the\r\nencrypted data.\r\nFigure 1. Structure of Sunburst POST data\r\nFigure 1. Structure of Sunburst POST data\r\nIf the data to send is less than, or equal to, 10,000 bytes, the URL path will take one of two forms as follows:\r\n/fonts/woff/{0}-{1}-{2}-webfont{3}.woff2\r\nelement 0 is a random number between 100 and 10,000\r\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-sending-data\r\nPage 1 of 4\n\nelement 1 is \"opensans\" or “noto”\r\nelement 2 is one of the following:\r\nbold\r\nbolditalic\r\nextrabold\r\nextrabolditalic\r\nitalic\r\nlight\r\nlightitalic\r\nregular\r\nsemibold\r\nsemibolditalic\r\nelement 3 is the last error code\r\nor /fonts/woff/{0}-{1}-{2}{3}.woff2\r\nelement 0 is a random number between 100 and 10,000\r\nelement 1 is one of the following:\r\nfreefont\r\nSourceCodePro\r\nSourceSerifPro\r\nSourceHanSans\r\nSourceHanSerif\r\nelement 2 is one of the following:\r\nBold\r\nBoldItalic\r\nExtraBold\r\nExtraBoldItalic\r\nItalic\r\nLight\r\nLightItalic\r\nRegular\r\nSemiBold\r\nSemiBoldItalic\r\nelement 3 is the last error code\r\nFurther, instead of sending the encrypted data directly, as when the data is greater than 10,000 bytes, the data is\r\nsteganographically sent in a faux JSON blob. \r\nThe JSON blob contains the following fields:\r\nuserId - contains the userid obfuscated into a GUID\r\nsessionId - a randomly generated GUID per HTTP session\r\nTimestamp - milliseconds since 1970/1/1 minus five minutes plus a random value between 0-512 with the\r\nsecond bit normally set to 1\r\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-sending-data\r\nPage 2 of 4\n\nIndex - an incrementing value\r\nEventType - set to Orion\r\nEventName - set to EventManager\r\nDurationMs - the same random value between 0-512 used in the Timestamp\r\nSucceeded - set to true\r\nMessage - a chunk of Base64 encoded data\r\nThe encrypted data to send is broken into multiple variable sized chunks. The size of each chunk is randomly\r\ndetermined, but generally will go from smaller to larger. If the randomly chosen size is 0, a random chunk\r\nbetween 16 and 28 bytes is generated instead and the Timestamp value is AND’d with the value\r\n18446744073709551613, which more importantly sets the second bit to 0. Each chunk is then encoded and added\r\nto the JSON blob and sent as the HTTP(S) POST data with a Content-Type header set to application/json.\r\nFigure 2. A contrived example of a JSON file that would be sent by Sunburst\r\nFigure 2. A contrived example of a JSON file that would be sent by Sunburst\r\nOn receipt, the attacker will need to decode and concatenate all the Message chunks, skipping junk chunks where\r\nthe Timestamp second bit is not set.\r\nThis blog is the final installment of our analysis series concerning the command and control (C\u0026C) process used\r\nby the actors behind the SolarWinds attacks. Previous entries have covered how the attackers used Sunburst to\r\ndisable security software and avoid detection, the malware's use of a rare domain generation algorithm (DGA) to\r\ngenerate domain names to contact for C\u0026C purposes, and Sunburst's control flow and use of IP address values as\r\ncommands. This final blog, detailing how the malware sends data back to the attackers, rounds out a\r\ncomprehensive overview of Sunburst’s C\u0026C processes.\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.Raindrop\r\nBackdoor.Teardrop\r\nBackdoor.Sunburst\r\nBackdoor.Sunburst!gen1\r\nBackdoor.SuperNova\r\nNetwork-based protection:\r\nSystem Infected: Sunburst Malware Activity\r\nFor the latest protection updates, please visit the Symantec Protection Bulletin.\r\nSolarWinds: How Sunburst Sends Data Back to the Attackers\r\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-sending-data\r\nPage 3 of 4\n\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-sending-data\r\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-sending-data\r\nPage 4 of 4\n\nIf the data to /fonts/woff/{0}-{1}-{2}-webfont{3}.woff2 send is less than, or equal to, 10,000 bytes, the URL path will take one of two forms as follows:\nelement 0 is a random number between 100 and 10,000\n Page 1 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA", "MITRE" ], "origins": [ "web" ], "references": [ "https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/solarwinds-sunburst-sending-data" ], "report_names": [ "solarwinds-sunburst-sending-data" ], "threat_actors": [], "ts_created_at": 1775434550, "ts_updated_at": 1775826696, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/2bac0520093458d4be7cf2309efeec3dd474afd4.pdf", "text": "https://archive.orkl.eu/2bac0520093458d4be7cf2309efeec3dd474afd4.txt", "img": "https://archive.orkl.eu/2bac0520093458d4be7cf2309efeec3dd474afd4.jpg" } }