What happened

SolarWinds, a well-known IT managed services provider, has recently become a victim of a cyberattack. Their product Orion Platform, a solution for monitoring and managing their customers’ IT infrastructure, was compromised by threat actors. This resulted in the deployment of a custom Sunburst backdoor on the networks of more than 18,000 SolarWinds customers, with many large corporations and government entities among the victims.

According to our Threat Intelligence data, the victims of this sophisticated supply-chain attack were located all around the globe: the Americas, Europe, Middle East, Africa and Asia.

After the initial compromise, the attackers appear to have chosen the most valuable targets among their victims. The companies that appeared to be of special interest to the malicious actors may have been subjected to deployment of additional persistent malware.

Overall, the evidence available to date suggests that the SolarWinds supply-chain attack was designed in a professional manner. The perpetrators behind the attack made it a priority to stay undetected for as long as possible: after the installation, the Sunburst malware lies dormant for an extended period of time, keeping a low profile and thwarting automated sandbox-type analysis and detection. Additionally, the backdoor utilizes a sophisticated scheme for victim reporting, validation and upgrading which resembles methods involved in some other notorious supply-chain attacks.

Read more about our research on Sunburst malware here. Additional reports and indicators of compromise are available to our Threat Intelligence Portal customers.

How to protect your organization against this threat

The detection logic has been improved in all our solutions to ensure that our customers remain protected. We continue to investigate this attack using our Threat Intelligence and we will add additional detection logic once they are required.

Our products protect against this threat and detect it with the following names:

• Backdoor.MSIL.Sunburst.a
• Backdoor.MSIL.Sunburst.b
• HEUR:Trojan.MSIL.Sunburst.gen
• HEUR:Backdoor.MSIL.Sunburst.gen
• Backdoor.MSIL.Sunburst.b

Our Behavior Detection component detects activity of the trojanized library as PDM:Trojan.Win32.Generic.

Our Endpoint Detection and Response (Expert) platform can be helpful in looking for and identifying traces of this attack. The customer can search for Indicators of Compromise (such as hashes or domain names) with an .ioc file or directly with the Threat Hunting interface:

Or, customers can use the IoA Tag, which we have added specifically for this attack:

This rule marks endpoint detections for Sunburst to make it more clearly visible to security officers:

Our Kaspersky Anti-Targeted Attack Platform detects Sunburst traffic with a set of IDS rules with the following verdicts:

• Trojan.Sunburst.HTTP.C&C
• Backdoor.Sunburst.SSL.C&C
• Backdoor.Sunburst.HTTP.C&C
• Backdoor.Sunburst.UDP.C&C
• Backdoor.Beacon.SSL.C&C
• Backdoor.Beacon.HTTP.C&C
• Backdoor.Beacon.UDP.C&C

Our Managed Detection and Response service is also able to identify and stop this attack by using threat hunting rules to spot various activities that can be performed by the Sunburst backdoor as well as detections from Kaspersky Endpoint Security.

Sunburst / UNC2452 / DarkHalo FAQ

1. Who is behind this attack? I read that some people say APT29/Dukes?
   At the moment, there are no technical links with previous attacks, so it may be an entirely new actor, or a previously known one that evolved their TTPs and opsec to the point where they can’t be linked anymore. Volexity, who previously worked on other incidents related to this, named the actor DarkHalo. FireEye named them “UNC2452”, suggesting an unknown actor. While some media sources linked this with APT29/Dukes, this appears to be either speculation or based on some other, unavailable data, or weak TTPs such as legitimate domain re-use.
2. I use Orion IT! Was I a target of this attack?
   First of all, we recommend scanning your system with an updated security suite, capable of detecting the compromised packages from SolarWinds. Check your network traffic for all the publicly known IOCs – see https://github.com/fireeye/sunburst_countermeasures. The fact that someone downloaded the trojanized packages doesn’t also mean they were selected as a target of interest and received further malware, or suffered data exfiltration. It would appear, based on our observations and common sense, that only a handful of the 18,000 Orion IT customers were flagged by the attackers as interesting as were further exploited.
3. Was this just espionage or did you observe destructive activities, such as ransomware?
   While the vast majority of the high-profile incidents nowadays include ransomware or some sort of destructive payload (see NotPetya, Wannacry) in this case, it would appear the main goal was espionage. The attackers showed a deep understanding and knowledge of Office365, Azure, Exchange, Powershell and leveraged it in many creative ways to constantly monitor and extract e-mails from their true victims’ systems.
4. How many victims have been identified?
   Several publicly available data sets, such as the one from John Bambenek, include DNS requests encoding the victim names. It should be noted that these victim names are just the “first stage” recipients, not necessarily the ones the attackers deemed interesting. For instance, out of the ~100 Kaspersky users with the trojanized package, it would appear that none were interesting to the attackers to receive the 2nd stage of the attack.
5. What are the most affected countries?
   To date, we observed users with the trojanized Orion IT package in 17 countries. However, the total number is likely to be larger, considering the official numbers from SolarWinds.
6. Why are you calling this an attack, when it’s just exploitation? (CNA vs CNE)
   Sorry for the terminology, we simply refer to it as a “supply chain attack”. It would be odd to describe it as a “supply chain exploitation”.
7. Out of the 18,000 first stage victims, how many were interesting to the attackers?
   This is difficult to estimate, mostly because of the lack of visibility and because the attackers were really careful in hiding their traces. Based on the CNAME records published by FireEye, we identified only two entities, a US government organization and a telecommunications company, who were tagged and “promoted” to dedicated C2s for additional exploitation.
8. Why didn’t you catch this supply chain attack in the first place?
   That’s a good question! In particular, two things made it really stealthy. The slow communication method, in which the malware lies dormant for up to two weeks, is one of them. The other one is the lack of x86 shellcode; the attackers used a .NET injected module. Last but not least, there was no significant change in the file size of the module when the malicious code was added. We observed two suspicious modules in 2019, which jumped from the usual 500k to 900k for SolarWinds.Orion.Core.BusinessLayer.dll. When the malicious code was first added, in February 2020, the file didn’t change size in a significant manner. If the attackers did this on purpose, to avoid future detections, then it’s a pretty impressive thing.
9. What is Teardrop?
   According to FireEye, Teardrop is malware delivered by the attackers to some of the victims. It is an unknown memory-only dropper suspected to deliver a customized version of the well-known CobaltStrike BEACON. To date, we haven’t detected any Teardrop samples anywhere.
10. What made this such a successful operation?
    Probably, a combination of things – a supply chain attack, coupled with a very well thought first stage implant, careful victim selection strategies and last but not least, no obvious connections to any previously observed TTPs.