{
	"id": "d9808f50-b001-40b6-baca-db4833b1747b",
	"created_at": "2026-04-10T03:20:41.94681Z",
	"updated_at": "2026-04-10T03:22:18.228601Z",
	"deleted_at": null,
	"sha1_hash": "503ad0bf4f94c35941c3715d519dcf99786d9b3d",
	"title": "SolarWinds Incident: Deeper Analysis of the Breach",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 208633,
	"plain_text": "SolarWinds Incident: Deeper Analysis of the Breach\r\nBy Joe Slowik\r\nPublished: 2020-12-18 · Archived: 2026-04-10 03:07:37 UTC\r\nContinuous Eruption: Further Analysis of the SolarWinds Supply Chain Incident\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\nMultiple entities disclosed a supply chain attack via SolarWinds Orion network monitoring software on 13 December 2020.\r\nDomainTools provided initial analysis of network infrastructure and implications on 14 December. Since then, multiple\r\nentities have released reports including additional malware analysis, Command and Control (C2) identification, and details\r\non the possible scope of the incident.\r\nThe following represent some of the more relevant items published as of this writing:\r\nDark Halo Leverages SolarWinds Compromise to Breach Organizations, Volexity.\r\nAlert AA20-352, Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and\r\nPrivate Sector Organizations, US Department of Homeland Security, Cybersecurity and Infrastructure Security\r\nAgency (CISA).\r\nSunBurst: The Next Level of Stealth, ReversingLabs.\r\nSUNBURST Backdoor: A Deeper Look into the SolarWinds’ Supply Chain Malware, Prevasio.\r\nBased on additional information released by multiple parties as well as independent DomainTools analysis, this blog adds to\r\nand updates, where applicable, previous reporting.\r\nTimeline of Events\r\nWhile SUNBURST activity was only identified in December 2020, analysis of campaign details and further analysis of\r\nSolarWinds software indicates the event may have started, at least in preparatory phases, over a year prior.\r\nhttps://www.domaintools.com/resources/blog/continuous-eruption-further-analysis-of-the-solarwinds-supply-incident\r\nPage 1 of 7\n\nWhile previous DomainTools research shows infrastructure management and staging likely started in December 2019,\r\nsubsequent analysis from ReversingLabs indicates that the operation began even earlier. Based on analysis of SolarWinds\r\nbinaries, researchers at ReversingLabs identified modifications to installer packages as early as October 2019.\r\nWhile this may appear to be an academic point for defenders aside from those remediating events at SolarWinds, this detail\r\ndoes allow us to draw several conclusions:\r\n1. The SolarWinds intrusion was a long-planned event, occurring in distinct stages: supply chain breach, software\r\nmodification testing, infrastructure development, then final deployment.\r\n2. Given that this campaign appears to have started no later than October 2019, the range of possible intrusion scenarios\r\nrelated to this threat actor expands dramatically.\r\nThe second point is significant given reporting from Volexity—on multiple intrusions tied to the entity responsible for the\r\nSUNBURST campaign. Specifically, in several incidents the adversary—referred to as “Dark Halo” by Volexity – remained\r\nin victim environments “undetected for several years.” Based on this alarming observation, DomainTools concludes with\r\nhigh confidence that post-instrusion activity identified with the SolarWinds supply chain campaign has likely been active\r\nsince prior to February 2020, and with medium confidence before October 2019—extending the timeline of investigation for\r\npotential victims far longer than the March to October (or later), 2020 timeline usually cited in public reporting.\r\nVolexity’s conclusions on alternative intrusions methods are supported by recent alerting from CISA. In AA20-352, CISA\r\nnoted that they possess “evidence of additional initial access vectors, other than the SolarWinds Orion platform.” In\r\ndiscussions with multiple parties, these vectors are beyond those detailed by Volexity, and could be related to recent\r\nreporting concerning a possible breach at Microsoft, discussed further below. As a result, organizations face an extremely\r\ndifficult defensive problem given the multiple potential ingress mechanisms available to the adversary and the significant\r\ndwell time available to them following breach based on available timelines and campaign duration estimates.\r\nAdditional Infrastructure Observations\r\nWhile DomainTools Iris Passive DNS (pDNS) information identified and confirmed second-stage C2 nodes provided as\r\nCanonical Name (CNAME) responses to DNS requests to the primary C2 domain, avsvmcloud[.]com, additional\r\ninfrastructure continues to surface linked to the campaign. As a reminder, the following represent the first and second stage\r\nbeacon domains associated with SUNBURST malicious SolarWinds Orion installer activity:\r\nhttps://www.domaintools.com/resources/blog/continuous-eruption-further-analysis-of-the-solarwinds-supply-incident\r\nPage 2 of 7\n\nDomain IP First Seen Last Seen\r\navsvmcloud[.]com [various] 2/27/2020 10/30/2020\r\ndeftsecurity[.]com 13.59.205.66 2/14/2020 12/13/2020\r\nfreescanonline[.]com 54.193.127.66 2/11/2020 12/13/2020\r\nthedoccloud[.]com 54.215.192.52 2/9/2020 12/10/2020\r\nwebsitetheme[.]com 34.203.203.23 2/4/2020 6/25/2020\r\nhighdatabase[.]com 139.99.115.204 12/28/2019 12/6/2020\r\nWhile these are reasonably well known and documented, follow-on infrastructure relates to Cobalt Strike Beacon and\r\nrelated post-exploitation payloads. Based on analysis from FireEye, Volexity, and Symantec-Broadcom, different sets of\r\ninfrastructure—including potentially unique domains per victim—are used in this phase of events. As of this writing,\r\nDomainTools is aware of the following infrastructure linked to this campaign:\r\nDomain\r\nCreate\r\nDate\r\nIP\r\nHosting\r\nProvider\r\nSSL/TLS Certificate Regi\r\ndatabasegalore[.]com\r\n2019-\r\n12-14\r\n5.252.177.21\r\nMivoCloud\r\nSR\r\nd400021536d712cbe55ceab7680e9868eb70de4a\r\nNAM\r\nINC\r\ndigitalcollege[.]org\r\n2019-\r\n03-24\r\n13.57.184.217\r\nAmazon\r\nTechnologies\r\nInc.\r\nfdb879a2ce7e2cda26bec8b37d2b9ec235fade44\r\nStich\r\nRegi\r\nLast\r\nFoun\r\nervsystem[.]com\r\n2018-\r\n02-04\r\n198.12.75.112 ColoCrossing 0548eedb3d1f45f1f9549e09d00683f3a1292ec5 Epik\r\nglobalnetworkissues[.]com\r\n2020-\r\n12-16\r\n18.220.219.143\r\nAmazon\r\nTechnologies\r\nInc.\r\nff883db5cb023ea6b227bee079e440a1a0c50f2b\r\nKey-Gmb\r\nincomeupdate[.]com\r\n2016-\r\n10-02\r\n5.252.177.25\r\nMivoCloud\r\nSRL\r\n4909da6d3c809aee148b9433293a062a31517812\r\nNAM\r\nINC\r\ninfinitysoftwares[.]com\r\n2019-\r\n01-28\r\n107.152.35.77\r\nServerCheap\r\nINC\r\ne70b6be294082188cbe0089dd44dbb86e365f6a2 Nam\r\nkubecloud[.]com\r\n2015-\r\n04-20\r\n3.87.182.149\r\nAmazon\r\nData\r\nServices\r\nNoVa\r\n1123340c94ab0fd1e213f1743f92d571937c5301 Nam\r\nlcomputers[.]com\r\n2002-\r\n01-27\r\n162.223.31.184\r\nQuickPacket\r\nLL\r\n7f9ec0c7f7a23e565bf067509fbef0cbf94dfba6 Nam\r\npanhardware[.]com\r\n2019-\r\n05-30\r\n204.188.205.176 SharkTech 3418c877b4ff052b6043c39964a0ee7f9d54394d Nam\r\nseobundlekit[.]com\r\n2019-\r\n07-14\r\n3.16.81.254\r\nAmazon\r\nTechnologies\r\nInc\r\ne7f2ec0d868d84a331f2805da0d989ad06b825a1\r\nNAM\r\nINC\r\nsolartrackingsystem[.]net\r\n2009-\r\n12-05\r\n34.219.234.13\r\nAmazon\r\nTechnologies\r\nInc.\r\n91b9991c10b1db51ecaa1e097b160880f0169e0c Nam\r\nhttps://www.domaintools.com/resources/blog/continuous-eruption-further-analysis-of-the-solarwinds-supply-incident\r\nPage 3 of 7\n\nDomain\r\nCreate\r\nDate\r\nIP\r\nHosting\r\nProvider\r\nSSL/TLS Certificate Regi\r\nvirtualwebdata[.]com\r\n2014-\r\n03-22\r\n18.217.225.111\r\nAmazon\r\nTechnologies\r\nInc.\r\nab93a66c401be78a4098608d8186a13b27db8e8d Nam\r\nwebcodez[.]com\r\n2005-\r\n08-12\r\n45.141.152.18\r\nM247\r\nEurope SRL\r\n2667db3592ac3955e409de83f4b88fb2046386eb\r\nNAM\r\nINC\r\nzupertech[.]com\r\n2016-\r\n08-16\r\n51.89.125.18 OVH SAS d33ec5d35d7b0c2389aa3d66f0bde763809a54a8 Nam\r\nThe above items are similar to the primary and secondary C2 domains used as part of the initial SolarWinds malicious\r\nupdate software, as well as other commonalities:\r\nUsing “seasoned” domains with initial registration dates typically far in advance of the campaign. In most cases, it\r\nappears the adversary re-registered expired domains of interest for use in the campaign.\r\nHosting via cloud service providers, including major platforms such as Amazon AWS.\r\nConsistent, although not exclusive, use of technology-related naming “themes” or conventions.\r\nUse of Sectigo-issued SSL/TLS certificates for encrypted communications mostly issued in 2020, well after the\r\ncreation date of the domains.\r\nGiven the possibility that these third-stage C2 domains may be unique to individual victims, their use for direct defensive\r\npurposes (e.g., incorporating into block or alarm lists) is circumscribed. However, focusing on the observations and\r\ncommonalities of the infrastructure—age, theme, hosting pattern, and significant differences between registration and\r\nSSL/TLS certificate timestamps—may work to identify similarly-structured infrastructure.\r\nFor example, an organization could use automated lookups to a resource such as DomainTools to capture information about\r\na newly-seen, unfamiliar domain in network traffic. This information can then be parsed to compare registration and\r\ncertificate times, or a combination of registrar and hosting provider or Autonomous System Number (ASN) used to identify\r\ninfrastructure linked to past malicious behaviors.\r\nVictim Identification and Defensive Notes\r\nAnother recently-popular aspect of the SolarWinds supply chain attack is victim identification through reversing the\r\nalgorithm used to encode subdomains on DNS lookups to the primary C2 domain, avsvmcloud[.]com. Multiple entities have\r\nproduced lists of both raw requests (including DomainTools researchers here) and decoded lists following the algorithm\r\npublished by Prevasio.\r\nWhile provocative, analysts must understand the nature of the SUNBURST infection chain to appropriately grasp the nature\r\nand meaning of any purported “victim list.” As shown in the following diagram, while a beacon to the primary C2 domain is\r\nnecessary for follow-on exploitation to occur, it is not sufficient given checks within the malware for network ranges and\r\nsecurity products for further functionality.\r\nhttps://www.domaintools.com/resources/blog/continuous-eruption-further-analysis-of-the-solarwinds-supply-incident\r\nPage 4 of 7\n\nA victim could download the malicious package and execute it, but fail one of several checks for follow-on execution\r\nresulting in an inert payload. Furthermore, even if a victim receives the CNAME for follow-on C2 behaviors, it remains up\r\nto the adversary’s discretion as to whether that entity will receive any follow-on payloads, such as Cobalt Strike Beacon or\r\nother post-exploitation tools.\r\nFurthermore, there is another aspect of the “victim lists” which must be clearly called out. Circulated lists of “victims” are\r\nbased on pDNS collection related to the primary domain, avsvmcloud[.]com. While a number of entities, including\r\nDomainTools, work diligently to collect as complete a picture of DNS queries as possible for multiple reasons, no provider\r\nhas a complete view into all executed DNS queries. As a result, the list is almost certainly incomplete. The significance of\r\nthis observation is that an organization not being on the list of identified victims does not mean that entity did not conduct\r\nany network traffic to campaign-related infrastructure – instead, that traffic may simply have been missed or not recorded.\r\nRather than relying on third-party data, defenders and IT personnel should instead leverage internal data sources and\r\ncontinuous DNS monitoring. These will be far more authoritative of the organization’s activity and more reliable. While\r\nthird-party datasets are extremely useful for research purposes, own-network defense is best augmented through visibility of\r\nown-network activity and traffic.\r\nA Note on Attribution\r\nShortly after initial disclosures on intrusions into the US Treasury Department and other organizations, media entities linked\r\nthe events via sources to “APT29.” APT29, also referred to as Cozy Bear (CrowdStrike), The Dukes (various), or\r\nYTTRIUM (Microsoft), has previously been associated with Russia’s Foreign Intelligence Service (SVR), a successor\r\norganization to the First Chief Directorate of the Committee for State Security (KGB). However, this link is neither definite\r\nnor undisputed, as other researchers and organizations have also linked APT29 to the Russian Federal Security Service\r\n(FSB). Notably, the last US (and other) government public reporting on APT29, concerning theft of COVID-19 information\r\nin summer 2020, only referred to APT29 as linked to “Russian intelligence services” as opposed to a specific entity.\r\nhttps://www.domaintools.com/resources/blog/continuous-eruption-further-analysis-of-the-solarwinds-supply-incident\r\nPage 5 of 7\n\nIn the case of SolarWinds and related activity, it appears US government sources, speaking with the Washington Post, linked\r\nthe activity to APT29 as an alternative way of referencing SVR. This observation is interesting, as three entities have now\r\nreported on the activity in question without associating the identified behaviors with APT29:\r\nFireEye’s report linked the intrusion to a new entity tracked as “UNC2452,” using the company’s documented\r\nactivity clustering methodology.\r\nBoth Microsoft’s customer blog and technical reporting did not mention a specific adversary responsible for events,\r\ndespite previous reporting on YTTRIUM.\r\nVolexity, which has previously published material directly attributing events to APT29, also linked identified\r\nactivities to a new entity, similar to FireEye, only in this case named “Dark Halo.”\r\nThe overall picture is therefore confusing, as government sources are using “APT29” for this intrusion, while commercial\r\nentities that have directly responded to events are associating events with different entities. While DomainTools does not\r\nengage in direct attribution, observations and analysis of publicly available information indicate likely misunderstanding\r\nbetween organizations.\r\nBased on a close reading of media reporting, it appears that sources linking activity to “APT29” may be using this term as a\r\ncatch-all for SVR activity. Meanwhile, entities responding to events and with the most data at present see clear differences\r\nbetween the current activity and legacy APT29 behaviors. If using a behavior-based attribution methodology where naming\r\nconventions are assigned to collections of activities or behaviors as opposed to distinct entities (such as, “SVR”), having a\r\nseparate naming convention for distinct behaviors makes sense\r\nOverall, current analysis indicates that entities are almost certainly using different meanings for “APT29” in this event, with\r\ncertain sources equating “APT29” with “SVR” while threat intelligence and incident response companies view possible\r\nSVR-linked cyber activities distributed among distinct groups. The one note of caution for defenders out of this confusion is\r\nthat, given security company tracking as “not APT29,” standard playbooks and assumptions on APT29 behaviors and\r\nactivity are not necessarily applicable for this campaign.\r\nDefense, Mitigation, and Recovery\r\nThe identified campaign remains a difficult problem for network defenders to both identify whether a breach has taken\r\nplace, and to then scope the extent of such an intrusion. Matters have gotten even worse as there are now indications that, in\r\naddition to SolarWinds, Microsoft may also have been breached as part of this activity (a claim which is disputed as of this\r\nwriting). The potential scope and risk of supply chain compromises remains concerning and significant—but are not\r\ninsurmountable.\r\nFor defenders and IT operators, recognizing that just deploying a capability within a monitored environment—such as the\r\nmalicious SolarWinds update—is not sufficient to achieve compromise. Instead, adversaries must be able to take some\r\nmeasure of control over infected devices, and be able to move laterally within the network to other sources of value for\r\ncollection or other objectives. All of this activity, even if initial intrusion leapfrogs a large number of controls and\r\nmonitoring points, leaves traces for detection and response.\r\nOrganizations that monitor for new, unique, or abnormal network connections can identify C2 communication schema.\r\nProper asset classification which identifies specific hosts or host-type (e.g., “server” instead of “end-user client”) can further\r\ndifferentiate communication to identify items of concern. Similar classification can also work to identify unusual\r\nauthentication activity, where servers (such as a SolarWinds Orion device) initiate logons to other clients instead of the\r\nreverse.\r\nOverall an emphasis on visibility, own-network understanding, and being able to correlate events together to identify\r\nsuspicious patterns of activity can succeed in identifying even the most complex supply chain attacks post-breach. Although\r\nattackers may still gain initial footholds within networks, being able to dramatically reduce adversary dwell time is a\r\nsignificant improvement over what many organizations impacted by this SolarWinds event will experience in the coming\r\nweeks.\r\nConclusion\r\nThe SolarWinds breach and resulting aftershocks will continue reverberating around the security community. When\r\nadditional potential supply chain intrusions—such as that allegedly taking place at Microsoft—are added in, network\r\ndefenders must be extremely vigilant in monitoring and operating their networks. While circumstances may seem dire, a\r\nhttps://www.domaintools.com/resources/blog/continuous-eruption-further-analysis-of-the-solarwinds-supply-incident\r\nPage 6 of 7\n\ncombination of enhanced network monitoring, own-network understanding, and enrichment of external observations through\r\ntools such as DomainTools Iris can work to minimize an adversary’s ability to evade detection, or minimize time to\r\ndetection to reduce the scope of an incident.\r\nDomainTools will continue to analyze this event and its implications, and provide further observations and\r\nrecommendations as appropriate.\r\nRead our previous blog on the SolarWinds Supply Chain Incident.\r\nRead More\r\nThe DomainTools Security Research Team Discusses Their Analysis:\r\nBreaking Badness · 70. Gone with the SolarWind\r\nNo items found.\r\nSource: https://www.domaintools.com/resources/blog/continuous-eruption-further-analysis-of-the-solarwinds-supply-incident\r\nhttps://www.domaintools.com/resources/blog/continuous-eruption-further-analysis-of-the-solarwinds-supply-incident\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.domaintools.com/resources/blog/continuous-eruption-further-analysis-of-the-solarwinds-supply-incident"
	],
	"report_names": [
		"continuous-eruption-further-analysis-of-the-solarwinds-supply-incident"
	],
	"threat_actors": [],
	"ts_created_at": 1775791241,
	"ts_updated_at": 1775791338,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/503ad0bf4f94c35941c3715d519dcf99786d9b3d.pdf",
		"text": "https://archive.orkl.eu/503ad0bf4f94c35941c3715d519dcf99786d9b3d.txt",
		"img": "https://archive.orkl.eu/503ad0bf4f94c35941c3715d519dcf99786d9b3d.jpg"
	}
}