background image,
Blog DomainTools Research

Unraveling Network Infrastructure Linked to the SolarWinds Hack

Background

On 13 December 2020, multiple media reports emerged first identifying network intrusions at several US government agencies. Subsequent reporting indicated these intrusions, along with a previously-identified breach at information security giant FireEye, were linked to a compromise at IT management and remote monitoring software provider SolarWinds.

FireEye and Microsoft followed up media reporting with in-depth technical reports on a complex supply chain attack focusing on SolarWinds’ Orion IT monitoring software. The attack focuses on a malicious Dynamic Linked Library (DLL) included in the legitimate Orion installer package, referred to as SUNBURST or Solorigate by FireEye and Microsoft, respectively. Network defenders, threat researchers, and other interested parties are strongly encouraged to review the linked reports from FireEye and Microsoft to understand these campaigns in detail.

However, as part of the overall intrusion via the compromise at SolarWinds, several interesting network-based observations emerge. This includes both behaviors related to the Command and Control (C2) activity of SUNBURST and the characteristics of the network infrastructure used to facilitate the campaign.

Observed Command and Control Behavior

SUNBURST uses a complex, multi-staged mechanism for identifying a controlling C2 server, and performing subsequent communication. This is summarized in the following chart.

Diagram of Attacker Modified Solarwinds Installer Executes

C2 behavior is first dependent on resolving a subdomain of the first-stage C2 domain:

Avsvmcloud[.]com

The primary domain is interesting, as it first appears long before the Spring 2020 timeframe when SUNBURST is believed to have started (Spring 2020), in July 2018. A closer view of Whois history via DomainTools Iris shows a noticeable change in the domain in late 2019:

Whois History in DomainTools Iris of avsvmcloud.com

Initially, the domain was registered via Namecheap with PrivacyGuardian anonymization, but then shifted to completely different services (GoDaddy and Domains by Proxy) in December 2019. This change in registration information is reflected in hosting and related characteristics:

DomainTools Iris table inspecting the Name Server History

The two images above capture alterations in hosting and authoritative name server:

  • The domain shifted to GoDaddy parking infrastructure on 20 December 2019, roughly the same time as the change in registration.
  • The domain remains on GoDaddy parking infrastructure until 27 February 2020, when it shifts to Microsoft cloud hosting (52.171.135[.]15, then 13.65.251[.]83)
  • At the same time hosting shifts to Microsoft, the domain changes authoritative name server to self-hosting at Avsvmcloud[.]com.
DomainTools Iris Table inspecting the avsvmcloud.com

  • The primary domain ceases to resolve to an IP address on 30 October 2020.

While the primary domain ceases to resolve on 30 October 2020, subdomains remained active through early December 2020 as shown in DomainTools Passive DNS (pDNS) data:

DomainTools Passive DNS showing activity on avsvmcloud.com

With the above, we have some initial observations related to this campaign:

  1. Primary C2 infrastructure was acquired and initially provisioned in December 2019 using an existing but likely expired domain that superficially resembles a domain for cloud hosting services.
  2. Hosting, name server, and other items necessary for operational use were established on 27 February 2020.
  3. If Avsvmcloud[.]com is the only primary C2 domain, the SUNBURST campaign was operational no earlier than 27 February 2020, with a significant change in aspect on 30 October 2020.

Yet, operations do not end here. Provided the subdomain of Avsvmcloud[.]com resolves to a value not in an internally-stored blocklist of IP address ranges, C2 behavior looks for a returned Canonical Name (CNAME) record. This value is used for subsequent C2 activity, sent via HTTP but using the Orion Improvement Program format to “blend in” to network communications. Observed domains linked to second-stage C2 include the following items:

DomainCreate DateIP AddressISPRegistrar
databasegalore[.]com2019-12-145.252.177.21MivoCloud SRLNAMECHEAP INC
deftsecurity[.]com2019-02-1113.59.205.66Amazon Technologies Inc.NAMESILO, LLC
freescanonline[.]com2014-08-1454.193.127.66Amazon.com Inc.NAMECHEAP INC
highdatabase[.]com2019-03-07139.99.115.204OVH Singapore Pte. LtdNAMESILO, LLC
incomeupdate[.]com2016-10-025.252.177.25MivoCloud SRLNameCheap, Inc.
panhardware[.]com2019-05-30204.188.205.176SharkTechNameSilo, LLC
thedoccloud[.]com2013-07-0754.215.192.52Amazon.com Inc.NameSilo, LLC
virtualwebdata[.]com2014-03-2218.217.225.111Amazon Technologies Inc.NameSilo, LLC
websitetheme[.]com2006-07-2818.253.52.187Amazon Technologies Inc.NAMESILO, LLC
zupertech[.]com2016-08-1651.89.125.18OVH SASNameSilo, LLC

Understanding Network Infrastructure

Based on the dataset of eleven domains—one initial C2 item that works to resolve a second C2 domain for adversary use—we can derive several lessons about the responsible adversary and their infrastructure tendencies.

First and foremost, the adversary relies overwhelmingly on cloud-based providers such as Amazon and Microsoft for hosting purposes, with smaller or less-reputable providers also used for the second-stage C2 domains. While not well reflected in the pattern of second-stage domains, pDNS information for subdomain resolutions on Avsvmcloud[.]com show an overwhelming use of major cloud providers in returned responses, captured in DomainTools Iris output here. This hosting tendency makes infrastructure pivoting difficult, but also presents problems for defenders as such infrastructure can be shared by additional, non-malicious entities or reallocated quickly to other parties which muddies forensic analysis.

Second, naming themes as one component of domain characteristics show a tendency toward technology or IT service names. Although somewhat difficult to track and filter, identifying naming themes in new, previously unobserved network traffic can serve as a way to flag suspicious infrastructure for follow-on investigation. Looking for “technology adjacent” domains newly resolving can serve as a tripwire for possible malicious activity.

Third, the domains in question appear to represent a combination of likely adversary created (such as Databasegalore[.]com, which was created roughly the same time Avsvmcloud[.]com was provisioned), opportunistic re-registration of existing domains, and possible compromise of legitimate infrastructure. In the second case, Deftsecurity[.]com changes registrar and privacy provider in February 2019 despite existing for several years prior indicating likely re-registration by the adversary. More concerning are cases such as Freescanonline[.]com, which appears to have been a legitimate site for Search Engine Optimization (SEO) analysis as late as August 2019:

Iris Screenshot of Freescanonline.com's website

Of note, this domain was resolving to 108.179.242[.]236 until mid-February 2020, when it shifted to Amazon hosting inline with other network items observed in this campaign. This item therefore is somewhat ambiguous, either representing adversary take-over (given how recently it appears to have been used for legitimate purposes) or opportunistic re-registration on expiration.

Overall, the attacker leveraged domains with some degree of “history” behind them to evade filters or algorithms that flag network infrastructure due to “newness”. By having several months of creation time before either taking control over or modifying hosting for use in the SUNBURST campaign between December 2019 and March 2020 (based on analysis of DomainTools data), the attacker could build a false sense of trust in the network infrastructure used to potentially evade some security solutions and analysis.

Lessons for Defenders

Overall, the SUNBURST campaign represents a highly complex, operationally savvy, and technically patient campaign. As detailed by FireEye and Microsoft, this extends to subsequent lateral movement operations within victim networks, which relied overwhelmingly on capturing credentials within victim environments and mimicking user activity to evade detection. We as network defenders are thus presented with an exceptionally difficult attack to detect, defeat, and recover from—or are we?

As documented in this posting, there are a number of network observables that are critical to attacker success for C2 purposes as part of SUNBURST operations. While certainly not without its own difficulties, Network Security Monitoring (NSM) and DNS analysis can identify new, unusual, or outright suspicious network communication patterns. 

Monitoring is even more powerful when tracking external communications is combined with internal system awareness to quickly disposition what hosts are communicating to outside entities. In the case of the SolarWinds Orion software, identifying traffic from this service or its hosting device to new, unusual domains—even if using communication patterns similar to Orion telemetry—can rapidly identify connections that are abnormal and worth further scrutiny.

While much work would remain to properly disposition the event in question and discover something as complex and evasive as a malicious, signed update package, at least initial detection that something is “wrong” can be readily achieved. Next steps would require further analysis, review of system behaviors and configurations, and subsequent investigation—but at a minimum defenders are now alert and aware that something is amiss within the monitored environment.

Conclusion

The SUNBURST campaign represents a uniquely distressing intrusion event with implications for multiple industries and network operators. The ubiquity of SolarWinds in large networks, combined with the potentially long dwell time of intrusions facilitated by this compromise, mean victims of this campaign need not only recover their SolarWinds instance, but may need to perform widespread password resets, device recovery, and similar restoration activity to completely evict an intruder.

While this is concerning and unfortunate for the present circumstances, future supply chain attacks—as this will not be the last such incident to impact network defenders and operators—can be met with and detected by aggressive NSM and communication visibility. So long as even the most complex backdoor or implant requires communication to or instructions from a controlling entity, defenders have opportunities to detect and disrupt operations. Through continuous monitoring of network traffic and an understanding of what hosts are communicating, defenders can leverage attacker weaknesses and dependencies to overcome these otherwise daunting challenges.

Read our next blog in series on the SolarWinds Supply Chain Incident.