{
	"id": "c79bfd7a-ed61-4d52-8110-a40ca87a8ccf",
	"created_at": "2026-04-06T00:22:20.666416Z",
	"updated_at": "2026-04-10T03:21:00.996234Z",
	"deleted_at": null,
	"sha1_hash": "83012b10636dcea3319ba3a40e960eb80acac5be",
	"title": "SolarWinds: Tracing the Network Infrastructure Behind It",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 459779,
	"plain_text": "SolarWinds: Tracing the Network Infrastructure Behind It\r\nBy Joe Slowik\r\nArchived: 2026-04-05 19:43:36 UTC\r\nUnraveling Network Infrastructure Linked to the SolarWinds Hack\r\nBackground\r\nOn 13 December 2020, multiple media reports emerged first identifying network intrusions at several US\r\ngovernment agencies. Subsequent reporting indicated these intrusions, along with a previously-identified breach at\r\ninformation security giant FireEye, were linked to a compromise at IT management and remote monitoring\r\nsoftware provider SolarWinds.\r\nFireEye and Microsoft followed up media reporting with in-depth technical reports on a complex supply chain\r\nattack focusing on SolarWinds’ Orion IT monitoring software. The attack focuses on a malicious Dynamic Linked\r\nLibrary (DLL) included in the legitimate Orion installer package, referred to as SUNBURST or Solorigate by\r\nFireEye and Microsoft, respectively. Network defenders, threat researchers, and other interested parties are\r\nstrongly encouraged to review the linked reports from FireEye and Microsoft to understand these campaigns in\r\ndetail.\r\nHowever, as part of the overall intrusion via the compromise at SolarWinds, several interesting network-based\r\nobservations emerge. This includes both behaviors related to the Command and Control (C2) activity of\r\nSUNBURST and the characteristics of the network infrastructure used to facilitate the campaign.\r\nhttps://www.domaintools.com/resources/blog/unraveling-network-infrastructure-linked-to-the-solarwinds-hack\r\nPage 1 of 7\n\nObserved Command and Control Behavior\r\nSUNBURST uses a complex, multi-staged mechanism for identifying a controlling C2 server, and performing\r\nsubsequent communication. This is summarized in the following chart.\r\nC2 behavior is first dependent on resolving a subdomain of the first-stage C2 domain:\r\nAvsvmcloud[.]com\r\nThe primary domain is interesting, as it first appears long before the Spring 2020 timeframe when SUNBURST is\r\nbelieved to have started (Spring 2020), in July 2018. A closer view of Whois history via DomainTools Iris shows a\r\nnoticeable change in the domain in late 2019:\r\nInitially, the domain was registered via Namecheap with PrivacyGuardian anonymization, but then shifted to\r\ncompletely different services (GoDaddy and Domains by Proxy) in December 2019. This change in registration\r\ninformation is reflected in hosting and related characteristics:\r\nhttps://www.domaintools.com/resources/blog/unraveling-network-infrastructure-linked-to-the-solarwinds-hack\r\nPage 2 of 7\n\nThe two images above capture alterations in hosting and authoritative name server:\r\nThe domain shifted to GoDaddy parking infrastructure on 20 December 2019, roughly the same time as the\r\nchange in registration.\r\nThe domain remains on GoDaddy parking infrastructure until 27 February 2020, when it shifts to\r\nMicrosoft cloud hosting (52.171.135[.]15, then 13.65.251[.]83)\r\nAt the same time hosting shifts to Microsoft, the domain changes authoritative name server to self-hosting\r\nat Avsvmcloud[.]com.\r\nThe primary domain ceases to resolve to an IP address on 30 October 2020.\r\nWhile the primary domain ceases to resolve on 30 October 2020, subdomains remained active through early\r\nDecember 2020 as shown in DomainTools Passive DNS (pDNS) data:\r\nhttps://www.domaintools.com/resources/blog/unraveling-network-infrastructure-linked-to-the-solarwinds-hack\r\nPage 3 of 7\n\nWith the above, we have some initial observations related to this campaign:\r\n1. Primary C2 infrastructure was acquired and initially provisioned in December 2019 using an existing but\r\nlikely expired domain that superficially resembles a domain for cloud hosting services.\r\n2. Hosting, name server, and other items necessary for operational use were established on 27 February 2020.\r\n3. If Avsvmcloud[.]com is the only primary C2 domain, the SUNBURST campaign was operational no earlier\r\nthan 27 February 2020, with a significant change in aspect on 30 October 2020.\r\nYet, operations do not end here. Provided the subdomain of Avsvmcloud[.]com resolves to a value not in an\r\ninternally-stored blocklist of IP address ranges, C2 behavior looks for a returned Canonical Name (CNAME)\r\nrecord. This value is used for subsequent C2 activity, sent via HTTP but using the Orion Improvement Program\r\nformat to “blend in” to network communications. Observed domains linked to second-stage C2 include the\r\nfollowing items:\r\nDomain\r\nCreate\r\nDate\r\nIP Address ISP Registrar\r\ndatabasegalore[.]com 2019-12-14 5.252.177.21 MivoCloud SRL\r\nNAMECHEAP\r\nINC\r\ndeftsecurity[.]com 2019-02-11 13.59.205.66\r\nAmazon Technologies\r\nInc.\r\nNAMESILO, LLC\r\nfreescanonline[.]com 2014-08-14 54.193.127.66 Amazon.com Inc.\r\nNAMECHEAP\r\nINC\r\nhighdatabase[.]com 2019-03-07 139.99.115.204 OVH Singapore Pte. Ltd NAMESILO, LLC\r\nincomeupdate[.]com 2016-10-02 5.252.177.25 MivoCloud SRL NameCheap, Inc.\r\npanhardware[.]com 2019-05-30 204.188.205.176 SharkTech NameSilo, LLC\r\nthedoccloud[.]com 2013-07-07 54.215.192.52 Amazon.com Inc. NameSilo, LLC\r\nvirtualwebdata[.]com 2014-03-22 18.217.225.111\r\nAmazon Technologies\r\nInc.\r\nNameSilo, LLC\r\nwebsitetheme[.]com 2006-07-28 18.253.52.187\r\nAmazon Technologies\r\nInc.\r\nNAMESILO, LLC\r\nzupertech[.]com 2016-08-16 51.89.125.18 OVH SAS NameSilo, LLC\r\nUnderstanding Network Infrastructure\r\nBased on the dataset of eleven domains—one initial C2 item that works to resolve a second C2 domain for\r\nadversary use—we can derive several lessons about the responsible adversary and their infrastructure tendencies.\r\nhttps://www.domaintools.com/resources/blog/unraveling-network-infrastructure-linked-to-the-solarwinds-hack\r\nPage 4 of 7\n\nFirst and foremost, the adversary relies overwhelmingly on cloud-based providers such as Amazon and Microsoft\r\nfor hosting purposes, with smaller or less-reputable providers also used for the second-stage C2 domains. While\r\nnot well reflected in the pattern of second-stage domains, pDNS information for subdomain resolutions on\r\nAvsvmcloud[.]com show an overwhelming use of major cloud providers in returned responses, captured in\r\nDomainTools Iris output here. This hosting tendency makes infrastructure pivoting difficult, but also presents\r\nproblems for defenders as such infrastructure can be shared by additional, non-malicious entities or reallocated\r\nquickly to other parties which muddies forensic analysis.\r\nSecond, naming themes as one component of domain characteristics show a tendency toward technology or IT\r\nservice names. Although somewhat difficult to track and filter, identifying naming themes in new, previously\r\nunobserved network traffic can serve as a way to flag suspicious infrastructure for follow-on investigation.\r\nLooking for “technology adjacent” domains newly resolving can serve as a tripwire for possible malicious\r\nactivity.\r\nThird, the domains in question appear to represent a combination of likely adversary created (such as\r\nDatabasegalore[.]com, which was created roughly the same time Avsvmcloud[.]com was provisioned),\r\nopportunistic re-registration of existing domains, and possible compromise of legitimate infrastructure. In the\r\nsecond case, Deftsecurity[.]com changes registrar and privacy provider in February 2019 despite existing for\r\nseveral years prior indicating likely re-registration by the adversary. More concerning are cases such as\r\nFreescanonline[.]com, which appears to have been a legitimate site for Search Engine Optimization (SEO)\r\nanalysis as late as August 2019:\r\nOf note, this domain was resolving to 108.179.242[.]236 until mid-February 2020, when it shifted to Amazon\r\nhosting inline with other network items observed in this campaign. This item therefore is somewhat ambiguous,\r\neither representing adversary take-over (given how recently it appears to have been used for legitimate purposes)\r\nor opportunistic re-registration on expiration.\r\nOverall, the attacker leveraged domains with some degree of “history” behind them to evade filters or algorithms\r\nthat flag network infrastructure due to “newness”. By having several months of creation time before either taking\r\nhttps://www.domaintools.com/resources/blog/unraveling-network-infrastructure-linked-to-the-solarwinds-hack\r\nPage 5 of 7\n\ncontrol over or modifying hosting for use in the SUNBURST campaign between December 2019 and March 2020\r\n(based on analysis of DomainTools data), the attacker could build a false sense of trust in the network\r\ninfrastructure used to potentially evade some security solutions and analysis.\r\nLessons for Defenders\r\nOverall, the SUNBURST campaign represents a highly complex, operationally savvy, and technically patient\r\ncampaign. As detailed by FireEye and Microsoft, this extends to subsequent lateral movement operations within\r\nvictim networks, which relied overwhelmingly on capturing credentials within victim environments and\r\nmimicking user activity to evade detection. We as network defenders are thus presented with an exceptionally\r\ndifficult attack to detect, defeat, and recover from—or are we?\r\nAs documented in this posting, there are a number of network observables that are critical to attacker success for\r\nC2 purposes as part of SUNBURST operations. While certainly not without its own difficulties, Network Security\r\nMonitoring (NSM) and DNS analysis can identify new, unusual, or outright suspicious network communication\r\npatterns.\r\nMonitoring is even more powerful when tracking external communications is combined with internal system\r\nawareness to quickly disposition what hosts are communicating to outside entities. In the case of the SolarWinds\r\nOrion software, identifying traffic from this service or its hosting device to new, unusual domains—even if using\r\ncommunication patterns similar to Orion telemetry—can rapidly identify connections that are abnormal and worth\r\nfurther scrutiny.\r\nWhile much work would remain to properly disposition the event in question and discover something as complex\r\nand evasive as a malicious, signed update package, at least initial detection that something is “wrong” can be\r\nreadily achieved. Next steps would require further analysis, review of system behaviors and configurations, and\r\nsubsequent investigation—but at a minimum defenders are now alert and aware that something is amiss within the\r\nmonitored environment.\r\nConclusion\r\nThe SUNBURST campaign represents a uniquely distressing intrusion event with implications for multiple\r\nindustries and network operators. The ubiquity of SolarWinds in large networks, combined with the potentially\r\nlong dwell time of intrusions facilitated by this compromise, mean victims of this campaign need not only recover\r\ntheir SolarWinds instance, but may need to perform widespread password resets, device recovery, and similar\r\nrestoration activity to completely evict an intruder.\r\nWhile this is concerning and unfortunate for the present circumstances, future supply chain attacks—as this will\r\nnot be the last such incident to impact network defenders and operators—can be met with and detected by\r\naggressive NSM and communication visibility. So long as even the most complex backdoor or implant requires\r\ncommunication to or instructions from a controlling entity, defenders have opportunities to detect and disrupt\r\noperations. Through continuous monitoring of network traffic and an understanding of what hosts are\r\ncommunicating, defenders can leverage attacker weaknesses and dependencies to overcome these otherwise\r\ndaunting challenges.\r\nhttps://www.domaintools.com/resources/blog/unraveling-network-infrastructure-linked-to-the-solarwinds-hack\r\nPage 6 of 7\n\nRead our next blog in series on the SolarWinds Supply Chain Incident.\r\nRead More\r\nSource: https://www.domaintools.com/resources/blog/unraveling-network-infrastructure-linked-to-the-solarwinds-hack\r\nhttps://www.domaintools.com/resources/blog/unraveling-network-infrastructure-linked-to-the-solarwinds-hack\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.domaintools.com/resources/blog/unraveling-network-infrastructure-linked-to-the-solarwinds-hack"
	],
	"report_names": [
		"unraveling-network-infrastructure-linked-to-the-solarwinds-hack"
	],
	"threat_actors": [],
	"ts_created_at": 1775434940,
	"ts_updated_at": 1775791260,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/83012b10636dcea3319ba3a40e960eb80acac5be.pdf",
		"text": "https://archive.orkl.eu/83012b10636dcea3319ba3a40e960eb80acac5be.txt",
		"img": "https://archive.orkl.eu/83012b10636dcea3319ba3a40e960eb80acac5be.jpg"
	}
}