{
	"id": "2e040856-22d7-4bf9-b450-ead2cdee0e67",
	"created_at": "2026-04-06T01:32:00.665182Z",
	"updated_at": "2026-04-10T13:12:32.767042Z",
	"deleted_at": null,
	"sha1_hash": "9b13ee79ae465e4c4c01a6d096bdf4f3036979d3",
	"title": "SUNBURST Indicators: A Shift in Threat Utility",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 257519,
	"plain_text": "SUNBURST Indicators: A Shift in Threat Utility\r\nBy Joe Slowik\r\nPublished: 2021-01-22 · Archived: 2026-04-06 00:20:29 UTC\r\nChange in Perspective on the Utility of SUNBURST-Related Network Indicators\r\nIf you would prefer to listen to The DomainTools Research team discuss their analysis, it is featured in our recent episode of\r\nBreaking Badness, which is included at the bottom of this post.\r\nBackground\r\nSince initial disclosure first by FireEye then Microsoft in mid-December 2020, additional entities from Volexity to Symantec\r\nto CrowdStrike (among others) have released further details on a campaign variously referred to as “the SolarWinds event,”\r\n“SUNBURST,” or “Solorigate.” DomainTools provided an independent analysis of network infrastructure, defensive\r\nrecommendations, and possible attribution items in this time period as well.\r\nYet, perhaps the most in-depth analysis of the intrusion at the time of this writing was published by Microsoft on 20 January\r\n2021. Among other interesting observations, Microsoft’s most-recent reporting identified the following items:\r\nIncredibly high levels of Operational Security (OPSEC) displayed by the attackers to avoid identification or ultimate\r\ndiscovery of the SUNBURST backdoor.\r\nNarrowly-tailored operations with not only per-victim but even per-host unique Cobalt Strike configurations, file\r\nnaming conventions, and other artifacts of adversary behaviors.\r\nLikely use of victim-specific Command and Control (C2) infrastructure, including unique domains and hosting IPs,\r\nto further obfuscate operations while limiting the efficacy of indicator-based analysis and alerting.\r\nThe above discoveries emphasize that an indicator-centric approach to defending against a SUNBURST-like attack will fail\r\ngiven this adversary’s ability and willingness to avoid indicator reuse. Furthermore, as revealed by CrowdStrike,\r\nMalwareBytes, and potentially Mimecast, we also know that the “SolarWinds actor” leverages additional initial infection\r\nvectors (most notably abuse of Office365, Azure Active Directory, and related Microsoft-based cloud services). Therefore,\r\nmultiple entities aside from those using the affected versions of SolarWinds Orion software must be cognizant of and\r\nactively defending against this actor’s operations—yet a defense based on indicator alerting and blocking will fail given this\r\nactor’s OPSEC capabilities.\r\nSUNBURST-Related Command and Control Overview\r\nBased on reporting from multiple vendors, there was already strong suspicion that SUNBURST and related campaign\r\nnetwork infrastructure was likely victim-specific at least during certain stages of the intrusion. As seen in the image below,\r\nfor the SUNBURST-specific infection vector, C2 behaviors move through three distinct stages: the initial DNS\r\ncommunication to the common first-stage C2 node (avsvmcloud[.]com); the follow-on receipt and communication to a\r\nsecond-stage C2 node passed via a Canonical Name (CNAME) response to the initial DNS request; and finally a third-stage\r\nC2 corresponding to the Cobalt Strike Beacon payload installed on victim machines.\r\nhttps://www.domaintools.com/resources/blog/change-in-perspective-on-the-utility-of-sunburst-related-network-indicators#\r\nPage 1 of 5\n\nIn Microsoft’s reporting from 20 January 2021, we see confirmation that while first and second stage C2 activity likely\r\nfeature commonality among victims, third stage Cobalt Strike Beacon-related activity includes not only per-victim\r\nuniqueness but potentially per-host uniqueness as well:\r\nIn this scenario, individual indicators (domains or IP addresses) are effectively useless after the initial SUNBURST stages,\r\nand potentially completely impractical for non-SolarWinds infection vectors used by this adversary. Instead of Indicator of\r\nCompromise (IOC)-based defense, defenders need to migrate to identifying behavioral and infrastructure patterns to flag\r\ninfrastructure potentially related to this incident.\r\nPatterns, or the Lack Thereof\r\nAt the time of this writing, across multiple vendors, there are 29 domains with associated IP addresses linked to\r\nSUNBURST and related activity with high confidence.\r\nDomain\r\nCreate\r\nDate\r\nIP\r\nHosting\r\nProvider\r\nSSL/TLS Certificate Registrar\r\naimsecurity[.]net\r\n2020-\r\n01-23\r\n199.241.143.102\r\nVegasNap\r\nLLC\r\n6a448007f05bd5069cd222611ccd1e66b4466922\r\nEPIK, INC.,EPIK\r\nINC\r\navsvmcloud[.]com\r\n2018-\r\n07-25\r\nVarious\r\nVarious\r\nAzure\r\nN/A NameSilo, LLC\r\ndatabasegalore[.]com\r\n2019-\r\n12-14\r\n5.252.177.21\r\nMivoCloud\r\nSRL\r\nd400021536d712cbe55ceab7680e9868eb70de4a NAMECHEAP INC\r\ndatazr[.]com\r\n2019-\r\n09-03\r\n45.150.4.10\r\nBuzoianu\r\nMarian\r\n8387c1ca2d3a5a34495f1e335a497f81a8be680d Epik, Inc.\r\ndeftsecurity[.]com\r\n2019-\r\n02-11\r\n13.59.205.66\r\nAmazon\r\nTechnologies\r\nInc.\r\n12d986a7f4a7d2f80aaf0883ec3231db3e368480 NameSilo, LLC\r\ndigitalcollege[.]org\r\n2019-\r\n03-24\r\n13.57.184.217\r\nAmazon\r\nTechnologies\r\nInc.\r\nfdb879a2ce7e2cda26bec8b37d2b9ec235fade44\r\nStichting Registrar\r\nof Last Resort\r\nFoundation\r\nervsystem[.]com\r\n2018-\r\n02-04\r\n198.12.75.112 ColoCrossing 0548eedb3d1f45f1f9549e09d00683f3a1292ec5 Epik, Inc.\r\nfinancialmarket[.]org\r\n2001-\r\n10-02\r\n23.92.211.15 John George a9300b3607a11b51a285dcb132e951f03974da27 Namesilo, LLC\r\nfreescanonline[.]com\r\n2014-\r\n08-14\r\n54.193.127.66\r\nAmazon\r\nTechnologies\r\nInc.\r\n8296028c0ee55235a2c8be8c65e10bf1ea9ce84f NAMECHEAP INC\r\nhttps://www.domaintools.com/resources/blog/change-in-perspective-on-the-utility-of-sunburst-related-network-indicators#\r\nPage 2 of 5\n\nDomain\r\nCreate\r\nDate\r\nIP\r\nHosting\r\nProvider\r\nSSL/TLS Certificate Registrar\r\ngallerycenter[.]org\r\n2019-\r\n10-10\r\n135.181.10.254\r\nHetzner\r\nOnline\r\nGmbH\r\na30c95b105d0c10731c368a40d5f36c778ef96e6 NAMESILO, LLC\r\nglobalnetworkissues[.]com\r\n2020-\r\n12-16\r\n18.220.219.143\r\nAmazon\r\nTechnologies\r\nInc.\r\nff883db5cb023ea6b227bee079e440a1a0c50f2b Key-Systems GmbH\r\nhighdatabase[.]com\r\n2019-\r\n03-18\r\n139.99.115.204\r\nOVH\r\nSingapore\r\n35aeff24dfa2f3e9250fc874c4e6c9f27c87c40a NAMESILO, LLC\r\nincomeupdate[.]com\r\n2016-\r\n10-02\r\n5.252.177.25\r\nMivoCloud\r\nSRL\r\n4909da6d3c809aee148b9433293a062a31517812 NAMECHEAP, INC\r\ninfinitysoftwares[.]com\r\n2019-\r\n01-28\r\n107.152.35.77\r\nServerCheap\r\nINC\r\ne70b6be294082188cbe0089dd44dbb86e365f6a2 NameSilo, LLC\r\nkubecloud[.]com\r\n2015-\r\n04-20\r\n3.87.182.149\r\nAmazon\r\nData\r\nServices\r\nNoVa\r\n1123340c94ab0fd1e213f1743f92d571937c5301 NameSilo, LLC\r\nlcomputers[.]com\r\n2002-\r\n01-27\r\n162.223.31.184\r\nQuickPacket\r\nLLC\r\n7f9ec0c7f7a23e565bf067509fbef0cbf94dfba6 NameSilo, LLC\r\nmobilnweb[.]com\r\n2019-\r\n09-28\r\n172.97.71.162\r\nOwned-Networks\r\nLLC\r\n2c2ce936dd512b70f6c3de7c0f64f361319e9690\r\nNAMECHEAP\r\nINC,NAMECHEAP\r\nINC\r\nolapdatabase[.]com\r\n2019-\r\n07-01\r\n192.3.31.210 ColoCrossing 05c05e19875c1dc718462cf4afed463dedc3d5fd NAMESILO, LLC\r\npanhardware[.]com\r\n2019-\r\n05-30\r\n204.188.205.176 SharkTech 3418c877b4ff052b6043c39964a0ee7f9d54394d NameSilo, LLC\r\nseobundlekit[.]com\r\n2019-\r\n07-14\r\n3.16.81.254\r\nAmazon\r\nTechnologies\r\nInc.\r\ne7f2ec0d868d84a331f2805da0d989ad06b825a1 NAMECHEAP INC\r\nsolartrackingsystem[.]net\r\n2009-\r\n12-05\r\n34.219.234.134\r\nAmazon\r\nTechnologies\r\nInc.\r\n91b9991c10b1db51ecaa1e097b160880f0169e0c NameSilo, LLC\r\nswipeservice[.]com\r\n2015-\r\n09-03\r\n162.241.124.32\r\nUnified\r\nLayer\r\n9aeed2008652c30afa71ff21c619082c5f228454\r\nNAMECHEAP\r\nINC,NAMECHEAP\r\nINC\r\ntechiefly[.]com\r\n2019-\r\n09-24\r\n93.119.106.69\r\nTennet\r\nTelecom\r\nSRL\r\nab94a07823d8bb6797af7634ed1466e42ff67bfb\r\nEPIK, INC.,EPIK\r\nINC\r\nthedoccloud[.]com\r\n2013-\r\n07-07\r\n54.215.192.52\r\nAmazon\r\nTechnologies\r\nInc.\r\n849296c5f8a28c3da2abe79b82f99a99b40f62ce NameSilo, LLC\r\nvirtualdataserver[.]com\r\n2019-\r\n05-30\r\nVarious Various 4359513fe78c5c8c6b02715954cfce2e3c3a20f6 Epik, Inc\r\nvirtualwebdata[.]com\r\n2014-\r\n03-22\r\n18.217.225.111\r\nAmazon\r\nTechnologies\r\nInc.\r\nab93a66c401be78a4098608d8186a13b27db8e8d NameSilo, LLC\r\nwebcodez[.]com\r\n2005-\r\n08-12\r\n45.141.152.18\r\nM247\r\nEurope SRL\r\n2667db3592ac3955e409de83f4b88fb2046386eb NAMECHEAP INC\r\nwebsitetheme[.]com 2006-\r\n07-28\r\n34.203.203.23 Amazon\r\nTechnologies\r\n66576709a11544229e83b9b4724fad485df143ad NameSilo, LLC\r\nhttps://www.domaintools.com/resources/blog/change-in-perspective-on-the-utility-of-sunburst-related-network-indicators#\r\nPage 3 of 5\n\nDomain\r\nCreate\r\nDate\r\nIP\r\nHosting\r\nProvider\r\nSSL/TLS Certificate Registrar\r\nInc.\r\nzupertech[.]com\r\n2016-\r\n08-16\r\n51.89.125.18 OVH SAS d33ec5d35d7b0c2389aa3d66f0bde763809a54a8 NameSilo, LLC\r\nUsing previous DomainTools research as a guide, we can identify some “weak” patterns, such as clustering around certain\r\nregistrars, authoritative name servers, and hosting providers when these items were active—note that most of the items on\r\nthis list are currently sinkholed. Yet the identified patterns are somewhat weak and overlap with a number of other activities,\r\nboth legitimate and malicious, making pivoting and further infrastructure discovery very difficult, if not outright impossible.\r\nFrom a Cyber Threat Intelligence (CTI) perspective, pivoting and indicator analysis may seem to be a dead-end. The\r\nfollowing items hold, to a greater or lesser extent, for all observed domains in this campaign:\r\nThe use of what appear to be older domains (re-registered, potentially “taken over” by the threat actor, or potentially\r\npart of a “stockpile” of infrastructure kept for later use).\r\nReliance on cloud hosting providers (such as Amazon Web Services and Microsoft Azure) for domain hosting.\r\nUse of relatively common (if also typically suspicious) registration patterns to likely “hide” in the noise of domain\r\nregistration activity.\r\nCombined, these observations make enrichment seem, on its face, somewhat pointless.\r\nHowever, while these items may be difficult or impossible to use from either a predictive (identifying new infrastructure) or\r\nhistorical (identifying infrastructure used by the adversary, but not previously associated to it in an identified incident)\r\nexternal CTI analysis perspective, there remain options for network defenders. Most significantly, the patterns identified in\r\nthe items observed to date, though insufficient for external discovery on its own, may be more than sufficient for internal\r\ndefensive response and alerting purposes.\r\nOperationalizing Network Observables for Active Defense\r\nChanging our perspective from external analysis to internal enrichment of observables yields interesting and powerful\r\ndetection scenarios. In the case of SUNBURST and related intrusions, the adversary succeeds in subverting critical trust\r\nrelationships (with SolarWinds Orion or Microsoft cloud services) to attain initial access to victim environments. But in\r\norder to actually take advantage of this subversion, the adversary requires some mechanism of communicating with and\r\ncontrolling the deployed capability. At this stage, defenders can take advantage of this critical attacker dependency to\r\nidentify that something is amiss.\r\nOne simple way of approaching the subject would be to flag new, unknown domains referenced in network communications\r\nfor further scrutiny. This may sound potentially useful at first, but given the vast diversity of domains and the likely noise\r\ngenerated by user activity (or even programmatic actions), such an approach dooms itself rapidly to alert fatigue and failure.\r\nYet this just represents a barely enriched, minimal context way of observing network infrastructure items referenced in an\r\norganization’s overall network communication activity. If we, as defenders and responders, can add additional context and\r\nnuance to observed items and utilize this for alerting purposes, powerful possibilities emerge. Combining internal network\r\nunderstanding with automated observable or indicator enrichment enables rapid, contextual network defense which can\r\nquickly identify suspicious communication patterns.\r\nFor example, rather than simply responding to any instance of “new” network items observed, organizations may limit this\r\nresponse to critical services, servers, or network enclaves (e.g., the subnet containing various infrastructure devices). Proper\r\nnetwork segmentation, asset identification and asset tagging to identify critical items, such as SolarWinds Orion servers or\r\nvarious items such as email servers or Domain Controllers, can allow for focused response when a significant asset initiates\r\na previously unseen external connection.\r\nFrom a network observable perspective, just identifying that something is “new” can be replaced with enrichment to identify\r\nobservable characteristics of interest: hosting provider, hosting location, registrar, authoritative name server, or SSL/TLS\r\ncertificate characteristics. Identifying and alerting on combinations of these through automated enrichment—such as through\r\nDomainTools Iris Enrich or security monitoring plugins such as DomainTools integration with Splunk—can allow for higher\r\nfidelity, higher confidence alarms related to observed network communications. In the case of the SUNBURST-related\r\nitems, even the per-victim unique items associated with follow-on CobaltStrike activity, identifying domains matching\r\ncertain criteria in terms of name server and registrar associated with historical suspicious activity combined with the new\r\nobservation can enable security teams to vector resources for follow-on investigation based on the greater level of detail\r\nprovided.\r\nFor a truly game-changing defensive posture that fully amplifies defender advantages in both owning the network and\r\nmonitoring activity emerging from it, these perspectives can be combined. In this scenario, high-confidence alerting on\r\nsuspicious external network items post-enrichment is fused with internal asset identification to narrow this communication\r\nhttps://www.domaintools.com/resources/blog/change-in-perspective-on-the-utility-of-sunburst-related-network-indicators#\r\nPage 4 of 5\n\nto a high-value asset or sensitive enclave within the network. The subsequent alert represents a truly critical alarm enriching\r\non both target and adversary infrastructure aspects to focus response and drive an ensuing investigation.\r\nConclusion\r\nThe theoretical alerting scenario described above, where internal and external enrichment are combined to yield high-confidence, high-fidelity alarms, may appear out of reach for many organizations—but given advances in adversary\r\ntradecraft, it represents where we as defenders must drive operations. Although initially difficult to create, given both the\r\nnetwork engineering and segmentation requirements for an accurate asset or network enclave detection, as well as the\r\nestablishment of logging and enrichment pipelines for observed network indicators, once in place, an organization will find\r\nitself on a much more robust and powerful security footing.\r\nOnce attained, even the most complex and stealthy attacks such as the trust-abusing intrusions linked to SolarWinds and\r\nMicrosoft services can be detected. While subsequent investigation and analysis may remain hard, as highlighted in\r\nMicrosoft’s January 2021 analysis, at the very least defenders now have an opportunity to investigate and search for further\r\nsigns of malicious activity within the network. Absent the enrichment scenarios described above, defenders yield own-network advantages and investigation initiative to intruders, and place themselves in a position where an adversary mistake\r\nor migration away from high-OPSEC activity is necessary to enable detection and response.\r\nBy combining own-network understanding and identification with automated indicator enrichment through services such as\r\nDomainTools, defenders can take back the initiative from intruders and detect or even cut off initial C2 beacon activity. In\r\nthis manner, defenders not only adapt to but can disadvantage intruders to shift the landscape of network defense back in the\r\nnetwork owner’s favor.\r\nThe DomainTools Security Research Team Discusses Their Analysis:\r\nBreaking Badness · 73. SUNBURST on the Scene\r\nNo items found.\r\nSource: https://www.domaintools.com/resources/blog/change-in-perspective-on-the-utility-of-sunburst-related-network-indicators#\r\nhttps://www.domaintools.com/resources/blog/change-in-perspective-on-the-utility-of-sunburst-related-network-indicators#\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.domaintools.com/resources/blog/change-in-perspective-on-the-utility-of-sunburst-related-network-indicators#"
	],
	"report_names": [
		"change-in-perspective-on-the-utility-of-sunburst-related-network-indicators#"
	],
	"threat_actors": [
		{
			"id": "610a7295-3139-4f34-8cec-b3da40add480",
			"created_at": "2023-01-06T13:46:38.608142Z",
			"updated_at": "2026-04-10T02:00:03.03764Z",
			"deleted_at": null,
			"main_name": "Cobalt",
			"aliases": [
				"Cobalt Group",
				"Cobalt Gang",
				"GOLD KINGSWOOD",
				"COBALT SPIDER",
				"G0080",
				"Mule Libra"
			],
			"source_name": "MISPGALAXY:Cobalt",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775439120,
	"ts_updated_at": 1775826752,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9b13ee79ae465e4c4c01a6d096bdf4f3036979d3.pdf",
		"text": "https://archive.orkl.eu/9b13ee79ae465e4c4c01a6d096bdf4f3036979d3.txt",
		"img": "https://archive.orkl.eu/9b13ee79ae465e4c4c01a6d096bdf4f3036979d3.jpg"
	}
}