{
	"id": "45abc873-af87-4414-8a87-2809f80c7e44",
	"created_at": "2026-04-06T00:18:23.9626Z",
	"updated_at": "2026-04-10T13:12:40.809923Z",
	"deleted_at": null,
	"sha1_hash": "1c875f87f20691d4ae4b5546b2857a4a50651e90",
	"title": "SUNBURST Additional Technical Details | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1724190,
	"plain_text": "SUNBURST Additional Technical Details | Mandiant\r\nBy Mandiant\r\nPublished: 2020-12-24 · Archived: 2026-04-02 10:35:41 UTC\r\nWritten by: Stephen Eckels, Jay Smith, William Ballenthin\r\nFireEye has discovered additional details about the SUNBURST backdoor since our initial publication on Dec. 13,\r\n2020. Before diving into the technical depth of this malware, we recommend readers familiarize themselves with\r\nour blog post about the SolarWinds supply chain compromise, which revealed a global intrusion campaign by a\r\nsophisticated threat actor we are currently tracking as UNC2452.\r\nSUNBURST is a trojanized version of a digitally signed SolarWinds Orion plugin called\r\nSolarWinds.Orion.Core.BusinessLayer.dll. The plugin contains a backdoor that communicates via HTTP to third\r\nparty servers. After an initial dormant period of up to two weeks, SUNBURST may retrieve and execute\r\ncommands that instruct the backdoor to transfer files, execute files, profile the system, reboot the system, and\r\ndisable system services. The malware's network traffic attempts to blend in with legitimate SolarWinds activity by\r\nimitating the Orion Improvement Program (OIP) protocol and persistent state data is stored within legitimate\r\nplugin configuration files. The backdoor uses multiple obfuscated blocklists to identify processes, services, and\r\ndrivers associated with forensic and anti-virus tools.\r\nIn this post, the following topics are covered in greater detail:\r\nAnti-Analysis Environment Checks and Blocklists\r\nDomain Generation Algorithm and Variations\r\nCommand and Control (C2) behaviors for DNS A and CNAME records\r\nMalware modes of operation\r\nAnti-Analysis Environment Checks\r\nBefore reaching out to its C2 server, SUNBURST performs numerous checks to ensure no analysis tools are\r\npresent. It checks process names, file write timestamps, and Active Directory (AD) domains before proceeding.\r\nWe believe that these checks helped SUNBURST evade detection by anti-virus software and forensic investigators\r\nfor seven months after its introduction to the SolarWinds Orion supply chain.\r\nFirst, the backdoor verifies that the lowercase name of the current process is solarwinds.businesslayerhost.\r\nUNC2452 avoided including this string directly in the source code by computing a hash of the string and\r\ncomparing the result to the 64-bit number 17291806236368054941. The hash value is calculated as a standard\r\nFNV-1A 64-bit hash with an additional XOR by the 64-bit number 6605813339339102567. The additional XOR\r\noperation forces malware analysts to develop custom tools to brute force the hash preimage.\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 1 of 15\n\nNext, the backdoor only executes if the filesystem last write time of the .NET assembly\r\nSolarWinds.Orion.Core.BusinessLayer.dll is at least 12 to 14 days prior to the current time. The exact threshold is\r\nselected randomly from this interval. In other words, SUNBURST lays low for almost two weeks before raising\r\nits head. If the timestamp check fails, the backdoor will execute again at a random later time when it is invoked by\r\na legitimate recurring background task. Once the threshold is met, the sample creates the named pipe 583da945-\r\n62af-10e8-4902-a8f205c72b2e to ensure only one instance of the backdoor is running. If the named pipe already\r\nexists, the malware exits.\r\nSUNBURST stores its configuration in the legitimate SolarWinds.Orion.Core.BusinessLayer.dll.config file. It\r\nrepurposes two existing settings in the appSettings section: ReportWatcherRetry and ReportWatcherPostpone.\r\nDuring initialization, the backdoor determines if the ReportWatcherRetry setting is the value 3. This value\r\nindicates the malware has been deactivated and will no longer perform any network activity. As we describe later,\r\nUNC2452 can command the backdoor to disable itself. This feature may be utilized when the operator determines\r\nthe victim is not of interest or that they’ve completed their mission. When investigating a system compromised by\r\nSUNBURST, review this setting to determine if the backdoor has been disabled. Note, the presence of this value\r\ndoes not offer proof the actor did not further compromise the environment before disabling SUNBURST.\r\nThe backdoor also determines if the system is joined to an Active Directory (AD) domain and, if so, retrieves the\r\ndomain name. Execution ceases if the system is not joined to an AD domain. SUNBURST checks the AD domain\r\nname against a blocklist and halts execution if it contains one of the following values:\r\nswdev.local emea.sales pci.local apac.lab\r\nswdev.dmz cork.lab saas.swi dmz.local\r\nlab.local dev.local lab.rio lab.brno\r\nlab.na test solarwinds  \r\nWe suspect these hard-coded AD domains may be SolarWinds internal domains that UNC2452 wanted to avoid.\r\nFinally, SUNBURST verifies the system has internet connectivity by ensuring it can resolve the DNS name\r\napi.solarwinds.com. Otherwise, execution stops and retries at a random later time.\r\nAnti-Analysis Blocklists\r\nSUNBURST's behavior is affected by the presence of malware analysis and security software. To disguise the\r\nstrings used to detect these security tools, UNC2452 calculated and embedded a hash value for each string. While\r\nit is trivial for the backdoor to check for the existence of a hashed process name, it is computationally expensive to\r\ndetermine what string a hash value corresponds to (the “preimage”). However, thanks to some hard work by\r\nmembers of the information security community, the hashes have been successfully brute-forced. The list of\r\nhashes and their corresponding strings can be viewed at this FireEye GitHub page.\r\nSUNBURST uses the aforementioned FNV-1A plus XOR algorithm to compute the hash of each process name,\r\nservice name, and driver filename on the system.\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 2 of 15\n\nIf a blocklisted process or driver name is found, SUNBURST pauses and tries again later. The backdoor continues\r\npast this check only when there are no processes nor drivers from the blocklist present.\r\nIf a blocklisted service is found, SUNBURST attempts to disable the blocklisted service by manipulating the\r\nservice configuration in the Windows Registry. It sets the registry value\r\nHKLM\\SYSTEM\\CurrentControlSet\\services\\\\Start to the value 4, which corresponds to SERVICE_DISABLED.\r\nAs a result, the blocklisted service is disabled on the next power cycle. This means the presence of a blocklisted\r\nservice on a compromised host does not make a system immune to SUNBURST.\r\nAfter the registry modification is made, SUNBURST updates the ReportWatcherPostpone configuration value to\r\nreflect the service it disabled. Then, the backdoor pauses and retries the process and service blocklist checks at a\r\nlater time.\r\nSubsequent service blocklist checks skip services already present in the ReportWatcherPostpone configuration\r\nkey. SUNBURST will not treat the services it has disabled as members of the blocklist anymore. Therefore, during\r\nan incident response, forensic teams should consider recovering and decoding this configuration key to parse out\r\nwhich services SUNBURST attempted to disable.\r\nDomain Generation Algorithm\r\nIn this section we describe how SUNBURST uses an intermediary command and control (C2) coordinator to\r\nretrieve its final C2 server. The C2 coordinator instructs the backdoor to continue or halt beaconing. It also\r\nredirects SUNBURST to its final C2 server via DNS CNAME records. We believe this enables UNC2452 to\r\ncompartmentalize their operations, limiting the network infrastructure shared among victims.\r\nThe C2 coordinator is implemented as the authoritative DNS server for the avsvmcloud[.]com domain. To\r\ncommunicate with the C2 coordinator, SUNBURST uses a Domain Generation Algorithm (DGA) to construct\r\nsubdomains of avsvmcloud[.]com and resolves the fully qualified domain names (FQDN) using the system DNS\r\nclient. The backdoor interprets the DNS responses in an unusual way to receive orders from the C2 coordinator.\r\nThe DGA generates subdomains with the following DNS suffixes to create the FQDN:\r\n.appsync-api.eu-west-1[.]avsvmcloud[.]com\r\n.appsync-api.us-west-2[.]avsvmcloud[.]com\r\n.appsync-api.us-east-1[.]avsvmcloud[.]com\r\n.appsync-api.us-east-2[.]avsvmcloud[.]com\r\nA method named Update is responsible for initializing cryptographic helpers for the generation of these random-looking C2 subdomains. Subdomains are generated by concatenating an encoded user ID with an encoding of the\r\nsystem's domain name. The C2 coordinator can recover the victim domain name from the encoded data and likely\r\nuses this to route SUNBURST to its final C2 server.\r\nA user ID is generated based on three values:\r\nMAC address of the first available, non-loopback network interface\r\nDomain name\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 3 of 15\n\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Cryptography\\MachineGuid value\r\nSUNBURST takes the MD5 hash of these combined values and encodes it using a custom XOR scheme. We\r\nbelieve this value is used by UNC2452 to track unique victims.\r\nSUNBURST uses four different forms of subdomains to signify the operating mode of the backdoor. Each form\r\ncontains slightly different information. However, in two of the forms, investigators can recover the domain names\r\nof victim organizations. We recommend reviewing DNS logs to confirm the presence of a victim’s domain in\r\nSUNBURST C2 coordinator traffic.\r\nWhen SUNBURST is in its initial mode, it embeds the domain of the victim organization in its DGA-generated\r\ndomain prefix. Once the malware transitions to an “active” mode, the malware uses the other two forms of\r\nsubdomains. These do not include the AD domain, but instead include encodings of either the list of running and\r\nstopped services or a timestamp.\r\nThe open-source community has done a fantastic job reverse engineering many of the subdomain forms. While we\r\nare not aware of any public decoder scripts that reverse all four possible encodings, most decoders focus on\r\nrecovering the most useful information: the user ID and domain name embedded in the subdomains. We\r\nrecommend that incident responders for victim organizations with access to DNS logs use these tools to confirm\r\ntheir AD domains are not embedded within SUNBURST generated DNS subdomains. Note that this does not\r\nindicate follow-on activity.\r\nThe following sources may be referenced for decoding such domains:\r\nhttps://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/\r\nhttps://github.com/RedDrip7/SunBurst_DGA_Decode\r\nhttps://blog.cloudflare.com/a-quirk-in-the-sunburst-dga-algorithm/\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 4 of 15\n\nFigure 1: Diagram of actor operations and usage of SUNBURST\r\nCommand and Control\r\nSUNBURST uses a two-part C2 protocol that involves both DNS and HTTP. In “passive” mode, the backdoor\r\ncommunicates with its C2 coordinator via DNS and receives high-level updates to its state. For example, the C2\r\ncoordinator may tell the backdoor to go to sleep or spring into action. When the backdoor is in “active” mode, it\r\ncommunicates via HTTP to its final C2 server and receives detailed commands such as “spawn a process” or\r\n“transfer a file”.\r\nDNS C2 and the C2 Coordinator Protocol\r\nWhen communicating with the C2 coordinator, the backdoor continuously generates domains via its DGA. The\r\nbackdoor delays execution for random intervals between generating domains. In some cases, this delay is up to 9\r\nhours.\r\nIf the C2 coordinator responds with a DNS A record, SUNBURST checks the resolved address against a hard-coded list of IP address blocks. If the address falls within a block, the backdoor transitions into an associated\r\nmode. The backdoor starts in the “passive” mode where it does nothing but check blocklists, sleep, and beacon via\r\nDNS until a transition is seen. Other modes are “active”, in which the malware communicates via HTTP, and\r\n“disabled”, in which the malware is permanently disabled. These modes and transitions are defined in the Modes\r\nof Operation section.\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 5 of 15\n\nThe C2 coordinator may also respond with a DNS CNAME response. In this case, the malware uses the pointed-to\r\ndomain from the CNAME response for HTTPS C2 communications. SUNBURST starts a thread to handle\r\ncommand execution and further C2 HTTP(S) callouts. As an investigator, if you see CNAME resolutions for\r\nsubdomains of avsvmcloud[.]com, it‘s possible that UNC2452 initiated follow-on C2 within the environment.\r\nNote, the malware must receive a DNS A record response pointing to one of the following subnets immediately\r\nprior to receiving a DNS CNAME response. Otherwise, the CNAME resolution will be ignored and treated as an\r\nerror. In addition, for these subnets, the least-significant bytes from the A record IP address are parsed to obtain\r\nconfiguration data such as the proxy method to use, the URI scheme to use, and a delay value used in the HTTP\r\nthread.\r\n18.130.0.0/16 99.79.0.0/16 184.72.0.0/15\r\nSubsequent DNS A record responses in the following subnet ranges cause the DGA beaconing to continue.\r\n8.18.144.0/23 18.130.0.0/16 71.152.53.0/24 99.79.0.0/16\r\n87.238.80.0/21 199.201.117.0/24 184.72.0.0/15  \r\nOtherwise, subsequent DNS A record responses in the following subnet ranges cause SUNBURST to terminate\r\nand update the configuration key ReportWatcherRetry to a value that prevents further execution. This is the\r\nkillswitch.\r\n10.0.0.0/8 fc00:: - fe00:: 96.31.172.0/24\r\n172.16.0.0/12 fec0:: - ffc0:: 131.228.12.0/22\r\n192.168.0.0/16 ff00:: - ff00:: 144.86.226.0/24\r\n224.0.0.0/3 20.140.0.0/15  \r\nWhile in “active” mode, the DGA subdomain encoding does not include victim machine domain name\r\ninformation. Instead, the DGA subdomains encode a timestamp or the list of stopped/running services. To\r\ntransition back to “passive” mode, the malware operator may set the DNS server to resolve A records within the\r\nfollowing IP ranges:\r\n41.84.159.0/24 74.114.24.0/21 154.118.140.0/24 217.163.7.0/24\r\nIf the malware is transitioned from the “active” mode back to “passive”, the C2 coordinator must repeat the\r\nactivation process if the operator wants to re-activate the sample.\r\nHTTP(S) C2\r\nAfter receiving a CNAME DNS response with a new host to communicate with, SUNBURST starts a new thread\r\nto execute the method HttpHelper.Initialize. This method is responsible for the C2 communications and\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 6 of 15\n\ndispatching. The HTTP thread begins by delaying for a configurable amount of time that is controlled by the\r\nSetTime command. The HTTP thread delays for a minimum of one minute between callouts. The malware uses\r\nHTTP GET or POST requests. The sample disables certificate verification so it is possible to decrypt HTTPS\r\ntraffic if SSL man-in-the-middle is performed.\r\nThe malware constructs HTTP GET or POST request URIs from random selections of substrings. The scheme\r\nused depends on the A record received just prior to the CNAME DNS response. When sending a GET request, the\r\nmalware adds an \"If-None-Match\" HTTP header that includes the encoded user ID. This likely allows the C2\r\nserver to determine which SUNBURST installation generated the request, further enabling multiplexing of C2\r\nstreams on a single server.\r\nIn observed traffic, the C2 server employs steganography to hide data within HTTP response bodies and attempts\r\nto appear as benign XML related to .NET assemblies. Command data is spread across many GUID and\r\nhexadecimal strings. Commands are extracted from HTTP response bodies by searching for hexadecimal strings\r\nusing the following regular expression: \"\\{[0-9a-f-]{36}\\}\"|\"[0-9a-f]{32}\"|\"[0-9a-f]{16}\". Matched substrings in\r\nthe response are filtered for non-hex characters, joined together, and hex-decoded. Depending on the mode of\r\noperation, the malware may skip the steganography and send the encoded response in an HTTP response body.\r\nFigure 2: C2 response embeds commands in XML GUIDs\r\nIn the received C2 response, the first DWORD value indicates the actual size of the message. This value is\r\nfollowed immediately by the message with optional junk bytes added. The extracted message is single-byte XOR\r\ndecoded using the first byte of the message. The result is then DEFLATE decompressed. The first character of the\r\ndecompressed data is an ASCII integer that maps to a command ID, with optional additional command arguments\r\ndelimited by space characters. The supported commands are shown in the following table.\r\nCommand ID Operation\r\nIdle 0 No operation\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 7 of 15\n\nExit 1 Terminate the current thread.\r\nSetTime 2\r\nSets the delay time between main event loop executions Delay\r\nis in seconds, and varies random between [.9 * , 1.1 * ]\r\nIf the delay is \u003c 300 it is doubled on the next execution\r\nthrough the loop, this means it should settle onto an interval of\r\naround [5, 10] minutes\r\no There is a second, unrelated delay routine that delays for a\r\nrandom interval between [16hrs, 83hrs]\r\nCollectSystemDescription 3\r\nProfile the local system including hostname, username, OS\r\nversion, MAC addresses, IP address, DHCP configuration, and\r\ndomain information.\r\nUploadSystemDescription 4\r\nPerform an HTTP request to the specified URL, parse the\r\nresults and send the response to the C2 server.\r\nRunTask 5 Starts a new process with the given file path and arguments\r\nGetProcessByDescription 6\r\nReturns a process listing. If no arguments are provided, returns\r\njust the PID and process name. If an argument is provided, it\r\nalso returns the parent PID and username and domain for the\r\nprocess owner.\r\nKillTask 7 Terminate the given process, by PID.\r\nGetFileSystemEntries 8\r\nGiven a path, and a match pattern recursively list files and\r\ndirectories.\r\nWriteFile 9\r\nGiven a file path and a Base64-encoded string write the\r\ncontents of the Base64 string to the given file path. Write using\r\nappend mode. Delay for [1s, 2s] after writing is done.\r\nFileExists 10 Tests whether the given file path exists.\r\nDeleteFile 11 Deletes the specified file path.\r\nGetFileHash 12\r\nCompute the MD5 of a file at a given path and return the result\r\nas a hex string. If an argument is provided, it is the expected\r\nMD5 hash of the file and returns an error if the calculated\r\nMD5 differs.\r\nReadRegistryValue 13 Arbitrary registry read from one of the supported hives.\r\nSetRegistryValue 14 Arbitrary registry write from one of the supported hives.\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 8 of 15\n\nDeleteRegistryValue 15 Arbitrary registry delete from one of the supported hives.\r\nGetRegistrySubKeyAndValueNames 16\r\nReturns listing of subkeys and value names beneath the given\r\nregistry path.\r\nReboot 17 Attempts to immediately trigger a system reboot.\r\nSUNBURST sends messages back to the C2 server using a protocol that consists of UTF-8 strings and an\r\nappended 4-byte error DWORD and 8-byte userID. These are bare DEFLATE compressed and single-byte XOR\r\nencoded with the XOR key prepended to the message. Message payloads of length 10,000 or less are turned into\r\nJSON documents that resemble the Orion Improvement Program (OIP) messages used legitimately by\r\nSolarWinds. Messages larger than 10,000 bytes are sent as-is in the HTTP request body.\r\nThe fake OIP document contains the following fields:\r\nuserId – a unique identifier for the victim machine\r\nsessionID – stores a new random GUID for each HTTP thread\r\nsteps – an array of objects that contain the following keys: Timestamp, Index, EventType, EventName,\r\nDurationMs, Succeeded, and Message.\r\nThe JSON key EventType is hard-coded to the value Orion and the EventName is hard-coded to EventManager.\r\nThe encoded message to send to the C2 server is split up into random ranges, Base64-encoded, and stored in the\r\nMessage field of the objects in the steps array. Not all objects in the steps array contribute to the malware\r\nresponse. The integer in the Timestamp field must have the 0x2 bit set to indicate the contents of the Message\r\nfield are used in the malware response. steps objects whose 0x2 bit is clear in the Timestamp field contain random\r\ndata and are discarded when assembling the malware response. This may be an attempt to hinder analysis in the\r\nabsence of the malware sample.\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 9 of 15\n\nFigure 3: HTTP callout masquerades as OIP protocol\r\nModes of Operation\r\nAs detailed in the DGA section, the malware has multiple modes of operation configured by the IP block that A\r\nrecords resolve to as well as depending on if CNAME records exist. These modes of operation are stored in\r\ninternal enumerations. These mappings and values are described next.\r\nInternal Modes\r\nThe following modes govern internal operations of the malware:\r\nMode\r\nName\r\nValue Description\r\nTruncate 3\r\nDisabled; the malware killswitch has been activated and the sample may never run\r\nagain without external modification to the XML configuration on-disk.\r\nNew 4 Passive mode; DGA subdomains encode the system’s domain name\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 10 of 15\n\nAppend 5\r\nActive mode; C2 beaconing will occur on next CNAME resolve or is already actively\r\noccurring. DGA domains encode either the userID or the list of services\r\nThe mode values are written into the backdoor configuration key ReportWatcherRetry. Investigators may consider\r\nrecovering the malware configuration and inspecting this configuration value to determine the last running mode\r\nof the malware.\r\nThe following transitions govern how IP block ranges are translated into running modes:\r\nTransition Name Description\r\nAtm Transition to Truncate\r\nIpx Transition from Append to New\r\nImpLink Transition to Truncate\r\nNetBios Transition to Append, either start or continue C2 beaconing\r\nUnknown Not an IPv4 or IPv6 address, exit and retry DGA later\r\nThe following diagram describes how the SUNBURST’s DGA DNS responses act as mode transitions to control\r\nthe malware before HTTP-based C2 beaconing has even begun:\r\nAdditionally, here is an annotated network log showing how a sequence of DNS resolutions can transition the\r\nmalware mode:\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 11 of 15\n\nTo end this discussion of modes and transitions, a small note about the choices of these IP blocks. In cases such as\r\nthe ImpLink IP blocks that activate the killswitch, it’s likely that the ranges were specifically chosen by the\r\nattacker to avoid being discovered by security researchers. In other cases, such as the NetBios and \"special\"\r\nNetBios IP blocks, the companies these blocks resolve to is likely irrelevant or at least beyond what can be\r\ndefinitively said without speculation.\r\nMalware Flow Diagram\r\nThe following diagram provides a full picture of the malware's execution. Internally, SUNBURST uses a set of\r\nmodes and transitions as described earlier. The names of these modes and transitions have no meaning. The\r\nmalware authors purposely chose them as a form of obfuscation. When diagraming the malware's execution, these\r\nnames were reused for clarity.\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 12 of 15\n\nFigure 4: Malware logic and decision states\r\nQ\u0026A\r\nIs a system running blocklisted processes, services, or drivers safe from compromise?\r\nSometimes, but not always. SUNBURST unconditionally exits if blocklisted processes or drivers are found and\r\nwill not run until they are no longer detected. On the other hand, services are disabled by setting a registry value\r\nthat controls startup initialization and are not explicitly stopped. As a result, a blocklisted service may still be\r\nrunning when the malware performs its service checks later. For this reason, it is possible for a victim system to be\r\ninfected while a blocklisted service is running. Additionally, SUNBURST only attempts to disable a service once\r\nand updates its configuration to mark the service as disabled. Once the configuration is updated, the service is not\r\ntreated as a blocklisted entry during subsequent execution.\r\nDoes observing one DGA encoding over another provide any information during incident response?\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 13 of 15\n\nShort answer: it provides a hint for where to look but isn’t a be-all tell-all alone. Noticing the DGA encoding\r\nchange in network logs is a hint that the malware may have moved from New to Append or Append to New. This\r\nputs the malware in a mode where if a CNAME record is seen soon after, then HTTP C2 can begin. Incident\r\nresponse should focus on trying to identify CNAME records being successfully resolved instead of focusing on\r\nDGA encodings entirely. Identifying CNAME records is easier than tracking the malware mode through logs and\r\na stronger signal.\r\nWhat is the \"killswitch\"?\r\nFireEye discovered that certain DNS responses cause the malware to disable itself and stop further network\r\nactivity. With the support and help of GoDaddy’s Abuse Team and the Microsoft Threat Intelligence Center, the\r\ndomain used for resolving DGA domains was reconfigured to point to a sinkhole server under Microsoft’s control.\r\nThe IP of this sinkhole server was specially chosen to fall into the range used by the malware to transition from its\r\ncurrent mode (New or Append) into Truncate mode where it will be permanently inactive. In other words,\r\nSUNBURST infections should now be inoculated due to the killswitch.\r\nWhen C2 communication occurs, is a CNAME record required?\r\nCNAME records are required for HTTP C2 beaconing to occur and are provided by the C2 coordinator to specify\r\nthe final C2 server. C2 activity must occur over a domain name provided via a CNAME record. It cannot occur\r\ndirectly via a raw IP. To initialize C2 beaconing, the backdoor first looks for an A record response from one of its\r\nspecial NetBios subnets and subsequently expects to receive a CNAME record.\r\nIf a DGA domain is decoded to a company domain name, is that company compromised?\r\nWhen the backdoor is in “passive” mode it uses the DGA encoding which embeds victim AD domain names. This\r\nmeans that any system where the backdoor is present may have started trying to contact DNS servers where an\r\nattacker could then activate the backdoor to begin active C2 communications. In most cases this did not occur and\r\nbackdoors for non-targets were disabled by the operator. Therefore, it cannot be assumed that an organization\r\nexperienced follow-on activity if their domain is decoded from any DNS logs. Specifically, it’s only an indicator\r\nthat the backdoor code was present and capable of being activated.\r\nPublic Contributions\r\nWe have seen substantial community contributions to our public SUNBURST GitHub repository.\r\nWe would like to publicly thank all contributors to this repository. Specifically, all FNV hashes embedded within\r\nSUNBURST have been brute-forced. This is a huge amount of compute power that members of the community\r\nprovided free-of-charge to help others. We want to thank everyone who contributed hashes and specifically callout\r\nthe Hashcat community, which organized to systematically break each hash. This was essential for breaking the\r\nfinal few hashes whose preimage were of considerable length.\r\nAcknowledgements\r\nMatthew Williams, Michael Sikorski, Alex Berry and Robert Wallace.\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 14 of 15\n\nFor additional information on UNC2452, register for our webinar, UNC2452: What We Know So Far, on Tuesday,\r\nJan. 12, at 8 a.m. PT/11 a.m. ET.\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nhttps://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html"
	],
	"report_names": [
		"sunburst-additional-technical-details.html"
	],
	"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": "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": 1775434703,
	"ts_updated_at": 1775826760,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1c875f87f20691d4ae4b5546b2857a4a50651e90.pdf",
		"text": "https://archive.orkl.eu/1c875f87f20691d4ae4b5546b2857a4a50651e90.txt",
		"img": "https://archive.orkl.eu/1c875f87f20691d4ae4b5546b2857a4a50651e90.jpg"
	}
}