# Change in Perspective on the Utility of SUNBURST- related Network Indicators **[domaintools.com/resources/blog/change-in-perspective-on-the-utility-of-sunburst-related-network-indicators](https://www.domaintools.com/resources/blog/change-in-perspective-on-the-utility-of-sunburst-related-network-indicators#)** If you would prefer to listen to The DomainTools Research team discuss their [analysis, it is featured in our recent episode of Breaking Badness,](https://www.domaintools.com/resources/podcasts/73-sunburst-on-the-scene) which is included at the bottom of this post. ## Background [Since initial disclosure first by FireEye then](https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html) [Microsoft in mid-December 2020, additional](https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/) entities from [Volexity to](https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/) [Symantec to](https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/sunburst-supply-chain-attack-solarwinds) [CrowdStrike (among others) have released further](https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/) details on a campaign variously referred to as “the SolarWinds event,” “SUNBURST,” or [“Solorigate.” DomainTools provided an independent analysis of](https://www.domaintools.com/resources/blog/continuous-eruption-further-analysis-of-the-solarwinds-supply-incident?utm_campaign=change-in-perspective-on-the-utility-of-sunburst-related-network-indicators&utm_source=Blog) [network infrastructure,](https://www.domaintools.com/resources/blog/unraveling-network-infrastructure-linked-to-the-solarwinds-hack?utm_campaign=change-in-perspective-on-the-utility-of-sunburst-related-network-indicators&utm_source=Blog) [defensive recommendations, and possible attribution items in this time period as well.](https://www.domaintools.com/resources/blog/protecting-against-supply-chain-attacks-by-profiling-suppliers?utm_campaign=change-in-perspective-on-the-utility-of-sunburst-related-network-indicators&utm_source=Blog) Yet, perhaps the most [in-depth analysis of the intrusion at the time of this writing was](https://www.microsoft.com/security/blog/2021/01/20/deep-dive-into-the-solorigate-second-stage-activation-from-sunburst-to-teardrop-and-raindrop/) published by Microsoft on 20 January 2021. Among other interesting observations, Microsoft’s most-recent reporting identified the following items: Incredibly high levels of Operational Security (OPSEC) displayed by the attackers to avoid identification or ultimate discovery of the SUNBURST backdoor. ----- Narrowly-tailored operations with not only per-victim but even per-host unique Cobalt Strike configurations, file naming conventions, and other artifacts of adversary behaviors. Likely use of victim-specific Command and Control (C2) infrastructure, including unique domains and hosting IPs, to further obfuscate operations while limiting the efficacy of indicator-based analysis and alerting. The above discoveries emphasize that an indicator-centric approach to defending against a SUNBURST-like attack will fail given this adversary’s ability and willingness to avoid [indicator reuse. Furthermore, as revealed by CrowdStrike,](https://www.crowdstrike.com/blog/crowdstrike-launches-free-tool-to-identify-and-help-mitigate-risks-in-azure-active-directory/) [MalwareBytes, and potentially](https://blog.malwarebytes.com/malwarebytes-news/2021/01/malwarebytes-targeted-by-nation-state-actor-implicated-in-solarwinds-breach-evidence-suggests-abuse-of-privileged-access-to-microsoft-office-365-and-azure-environments/) [Mimecast, we also know that the “SolarWinds actor” leverages additional initial infection](https://www.cyberscoop.com/mimecast-email-breach-solarwinds-russia/) vectors (most notably abuse of Office365, Azure Active Directory, and related Microsoftbased cloud services). Therefore, multiple entities aside from those using the affected versions of SolarWinds Orion software must be cognizant of and actively defending against this actor’s operations—yet a defense based on indicator alerting and blocking will fail given this actor’s OPSEC capabilities. ## SUNBURST-Related Command and Control Overview Based on reporting from multiple vendors, there was already strong suspicion that SUNBURST and related campaign network infrastructure was likely victim-specific at least during certain stages of the intrusion. As seen in the image below, for the SUNBURSTspecific infection vector, C2 behaviors move through three distinct stages: the initial DNS communication to the common first-stage C2 node (avsvmcloud[.]com); the follow-on receipt and communication to a second-stage C2 node passed via a Canonical Name (CNAME) response to the initial DNS request; and finally a third-stage C2 corresponding to the Cobalt Strike Beacon payload installed on victim machines. In Microsoft’s reporting from 20 January 2021, we see confirmation that while first and second stage C2 activity likely feature commonality among victims, third stage Cobalt Strike Beacon-related activity includes not only per-victim uniqueness but potentially per-host uniqueness as well: ----- In this scenario, individual indicators (domains or IP addresses) are effectively useless after the initial SUNBURST stages, and potentially completely impractical for non-SolarWinds infection vectors used by this adversary. Instead of Indicator of Compromise (IOC)-based defense, defenders need to migrate to identifying behavioral and infrastructure patterns to flag infrastructure potentially related to this incident. ### Patterns, or the Lack Thereof At the time of this writing, across multiple vendors, there are 29 domains with associated IP addresses linked to SUNBURST and related activity with high confidence. **Hosting** **Provider** **SSL/TLS Certific** **Domain** **Create** **Date** **IP** aimsecurity[.]net 202001-23 avsvmcloud[.]com 201807-25 databasegalore[.]com 201912-14 datazr[.]com 201909-03 deftsecurity[.]com 201902-11 199.241.143.102 VegasNap LLC Various Various Azure 5.252.177.21 MivoCloud SRL 45.150.4.10 Buzoianu Marian 13.59.205.66 Amazon Technologies Inc. 6a448007f05bd50 N/A d400021536d712 8387c1ca2d3a5a 12d986a7f4a7d2f ----- **Hosting** **Provider** **SSL/TLS Certific** **Domain** **Create** **Date** **IP** digitalcollege[.]org 201903-24 ervsystem[.]com 201802-04 financialmarket[.]org 200110-02 freescanonline[.]com 201408-14 gallerycenter[.]org 201910-10 globalnetworkissues[.]com 202012-16 highdatabase[.]com 201903-18 incomeupdate[.]com 201610-02 infinitysoftwares[.]com 201901-28 kubecloud[.]com 201504-20 lcomputers[.]com 200201-27 mobilnweb[.]com 201909-28 olapdatabase[.]com 201907-01 panhardware[.]com 201905-30 13.57.184.217 Amazon Technologies Inc. fdb879a2ce7e2cd 198.12.75.112 ColoCrossing 0548eedb3d1f45f 23.92.211.15 John George a9300b3607a11b 54.193.127.66 Amazon Technologies Inc. 135.181.10.254 Hetzner Online GmbH 18.220.219.143 Amazon Technologies Inc. 139.99.115.204 OVH Singapore 5.252.177.25 MivoCloud SRL 107.152.35.77 ServerCheap INC 3.87.182.149 Amazon Data Services NoVa 162.223.31.184 QuickPacket LLC 172.97.71.162 OwnedNetworks LLC 8296028c0ee552 a30c95b105d0c1 ff883db5cb023ea 35aeff24dfa2f3e9 4909da6d3c809a e70b6be2940821 1123340c94ab0fd 7f9ec0c7f7a23e5 2c2ce936dd512b 192.3.31.210 ColoCrossing 05c05e19875c1d 204.188.205.176 SharkTech 3418c877b4ff052 ----- **Hosting** **Provider** **SSL/TLS Certific** **Domain** **Create** **Date** **IP** seobundlekit[.]com 201907-14 solartrackingsystem[.]net 200912-05 swipeservice[.]com 201509-03 techiefly[.]com 201909-24 thedoccloud[.]com 201307-07 virtualdataserver[.]com 201905-30 virtualwebdata[.]com 201403-22 webcodez[.]com 200508-12 websitetheme[.]com 200607-28 zupertech[.]com 201608-16 3.16.81.254 Amazon Technologies Inc. 34.219.234.134 Amazon Technologies Inc. e7f2ec0d868d84a 91b9991c10b1db 162.241.124.32 Unified Layer 9aeed2008652c3 93.119.106.69 Tennet Telecom SRL 54.215.192.52 Amazon Technologies Inc. ab94a07823d8bb 849296c5f8a28c3 Various Various 4359513fe78c5c8 18.217.225.111 Amazon Technologies Inc. 45.141.152.18 M247 Europe SRL 34.203.203.23 Amazon Technologies Inc. ab93a66c401be7 2667db3592ac39 66576709a11544 51.89.125.18 OVH SAS d33ec5d35d7b0c [Using previous DomainTools research as a guide, we can identify some “weak” patterns,](https://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects?utm_campaign=change-in-perspective-on-the-utility-of-sunburst-related-network-indicators&utm_source=Blog) such as clustering around certain registrars, authoritative name servers, and hosting providers when these items were active—note that most of the items on this list are currently sinkholed. Yet the identified patterns are somewhat weak and overlap with a number of other activities, both legitimate and malicious, making pivoting and further infrastructure discovery very difficult, if not outright impossible. From a Cyber Threat Intelligence (CTI) perspective, pivoting and indicator analysis may seem to be a dead-end. The following items hold, to a greater or lesser extent, for all observed domains in this campaign: ----- The use of what appear to be older domains (re-registered, potentially taken over by the threat actor, or potentially part of a “stockpile” of infrastructure kept for later use). Reliance on cloud hosting providers (such as Amazon Web Services and Microsoft Azure) for domain hosting. Use of relatively common (if also typically suspicious) registration patterns to likely “hide” in the noise of domain registration activity. Combined, these observations make enrichment seem, on its face, somewhat pointless. However, while these items may be difficult or impossible to use from either a predictive (identifying new infrastructure) or historical (identifying infrastructure used by the adversary, but not previously associated to it in an identified incident) external CTI analysis perspective, there remain options for network defenders. Most significantly, the patterns identified in the items observed to date, though insufficient for external discovery on its own, may be more than sufficient for internal defensive response and alerting purposes. ## Operationalizing Network Observables for Active Defense Changing our perspective from external analysis to internal enrichment of observables yields interesting and powerful detection scenarios. In the case of SUNBURST and related intrusions, the adversary succeeds in subverting critical trust relationships (with SolarWinds Orion or Microsoft cloud services) to attain initial access to victim environments. But in order to actually take advantage of this subversion, the adversary requires some mechanism of communicating with and controlling the deployed capability. At this stage, defenders can take advantage of this critical attacker dependency to identify that something is amiss. One simple way of approaching the subject would be to flag new, unknown domains referenced in network communications for further scrutiny. This may sound potentially useful at first, but given the vast diversity of domains and the likely noise generated by user activity (or even programmatic actions), such an approach dooms itself rapidly to alert fatigue and failure. Yet this just represents a barely enriched, minimal context way of observing network infrastructure items referenced in an organization’s overall network communication activity. If we, as defenders and responders, can add additional context and nuance to observed items and utilize this for alerting purposes, powerful possibilities emerge. Combining internal network understanding with automated observable or indicator enrichment enables rapid, contextual network defense which can quickly identify suspicious communication patterns. For example, rather than simply responding to any instance of “new” network items observed, organizations may limit this response to critical services, servers, or network enclaves (e.g., the subnet containing various infrastructure devices). Proper network segmentation, asset identification and asset tagging to identify critical items, such as ----- SolarWinds Orion servers or various items such as email servers or Domain Controllers, can allow for focused response when a significant asset initiates a previously unseen external connection. From a network observable perspective, just identifying that something is “new” can be replaced with enrichment to identify observable characteristics of interest: hosting provider, hosting location, registrar, authoritative name server, or SSL/TLS certificate characteristics. Identifying and alerting on combinations of these through automated enrichment—such as through [DomainTools Iris Enrich or security monitoring plugins such as DomainTools](https://www.domaintools.com/resources/api-documentation/iris-enrich?utm_campaign=change-in-perspective-on-the-utility-of-sunburst-related-network-indicators&utm_source=Blog) integration with Splunk—can allow for higher fidelity, higher confidence alarms related to observed network communications. In the case of the SUNBURST-related items, even the per-victim unique items associated with follow-on CobaltStrike activity, identifying domains matching certain criteria in terms of name server and registrar associated with historical suspicious activity combined with the new observation can enable security teams to vector resources for follow-on investigation based on the greater level of detail provided. For a truly game-changing defensive posture that fully amplifies defender advantages in both owning the network and monitoring activity emerging from it, these perspectives can be combined. In this scenario, high-confidence alerting on suspicious external network items post-enrichment is fused with internal asset identification to narrow this communication to a high-value asset or sensitive enclave within the network. The subsequent alert represents a truly critical alarm enriching on both target and adversary infrastructure aspects to focus response and drive an ensuing investigation. ----- ## Conclusion The 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 tradecraft, it represents where we as defenders must drive operations. Although initially difficult to create, given both the network engineering and segmentation requirements for an accurate asset or network enclave detection, as well as the establishment of logging and enrichment pipelines for observed network indicators, once in place, an organization will find itself on a much more robust and powerful security footing. Once attained, even the most complex and stealthy attacks such as the trust-abusing intrusions linked to SolarWinds and Microsoft services can be detected. While subsequent investigation and analysis may remain hard, as highlighted in Microsoft’s January 2021 analysis, at the very least defenders now have an opportunity to investigate and search for further signs 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 or migration away from high-OPSEC activity is necessary to enable detection and response. By combining own-network understanding and identification with automated indicator enrichment through services such as DomainTools, defenders can take back the initiative from intruders and detect or even cut off initial C2 beacon activity. In this manner, defenders not only adapt to but can disadvantage intruders to shift the landscape of network defense back in the network owner’s favor. ## The DomainTools Security Research Team Discusses Their Analysis: -----