The current Solarwinds/Sunburst/Fireeye incident and its associated command&control (C2) traffic to avsvmcloud[.]com domains [1] have spurred potentially affected Solarwinds customers to searching their logs and data for any presence of this C2 domain. While the Snort IDS rules published by FireEye [2] would detect any currently ongoing traffic to the C2 domain, they are of no use in an attempt to answer the question if any such connections were made in the past. Given the timeline of the incident, ranging as currently known from March 2020 to today, this isn't a straight forward search.

What helps in such a scenario are:
a) Full packet captures on the Internet uplink
b) Logs of the DNS resolver
c) Logs of any proxy server or gateway used to connect to the Internet

With today's bandwidths and data volumes, full packet capture is probably not practical except for deep-pocketed institutions. And I'm guessing that even for them, >6 months of retention will be a stretch. Logs of the DNS resolver can be retained more readily, because they usually compress nicely, and can even be indexed into a first seen / last seen database for use as a "Passive DNS" [3]. And lastly, proxy or firewall logs, are only a partial indicator at best in this scenario, because these logs likely wouldn't register if the C2 domain was just DNS-resolved by the implant, but the malware then subsequently remained dormant.

And in any case, all of these network forensics countermeasures mentioned so far describe what many companies have available in their "legacy IT" environment or on-premises network. Fast forward to "The Cloud", and things begin to look a lot more murky. Unless significant architectural effort has been spent on network design and egress filtering, virtual machines (VMs) in both Azure and AWS have direct connectivity to the Internet, and make use of a Microsoft / Amazon provided DNS resolver.

In Azure, a VM can be configured to have a Private DNS Zone, but the ability for Azure Firewall to log any DNS name resolution is a feature that only became available very recently [4,5]. The same is the case for Amazon, where Resolver Query Logging from private VNets is an equally recent feature [6].

Consequently, it is fair to assume that most Azure and AWS deployments today won't have DNS resolver logs available, and therefore don't have any straight forward way to determine if their Azure/AWS environment ever reached out to the SUNBURST domains in the recent months. While there are developments like DNS-over-HTTPS (DoH) that may render DNS logs less useful in future, for the time being, passive DNS / DNS resolver logs are still a must-have. The pivot points this provides for network forensics and timeline analysis are just too valuable. Hence, if your on-premises network has such DNS resolver logs available, but your Cloud doesn't, maybe this is one of the items that should make it onto your to-do list for 2021.

[1] https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
[2] https://github.com/fireeye/sunburst_countermeasures/blob/main/all-snort.rules
[3] https://isc.sans.edu/diary/Running+your+Own+Passive+DNS+Service/24784
[4] https://azure.microsoft.com/en-us/blog/new-enhanced-dns-features-in-azure-firewall-now-generally-available/
[5] https://docs.microsoft.com/en-us/azure/firewall/logs-and-metrics
[6] https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-route-53-resolver-supports-vpc-dns-query-logging/