On 8 December, 2020, US company FireEye published a press release stating that it had been targeted by malware, referred to as “Sunburst”, and that a number of its Red Team tools had been stolen. In the press release, the cybersecurity company described the actions as a sophisticated cyberattack by a threat actor “whose discipline, operational security and techniques lead us to believe it was a state-sponsored attack.” This is a newsworthy event in itself – reminding us once again that with cybersecurity, no-one is infallible – but it is also just one part of a bigger story.
Some context for the Sunburst attack
A few days later, on 13 December, we learned the extent of the damage: through FireEye, more than 18,000 companies and institutions worldwide had apparently been affected. And chief among these were some forty US government administrations, including the Department of Homeland Security and the National Nuclear Security Administration (NNSA). What do they have in common? They are all found inside the information system for the Orion software produced by SolarWinds, a developer of business software for the centralised management of networks, systems and all kinds of IT infrastructure. Preliminary investigations suggest that the APT29 (Cozy Bear) group was responsible for this attack.
Initial vector of the Sunburst attack
The initial vector of the attack seems to have been an in-depth compromise of this application for monitoring information systems. The affected Orion versions appear to date back to October 2019.
In technical terms, the malware seems to have been introduced into the application's development chain, and more specifically into the solarwinds.orion.core.businesslayer.dll library. This dll was then signed by the official SolarWinds certificate, giving it trusted status. Once installed in the target IS, the binary registers with the “Beacon” malware site by calling the avsvmcloud.com domain, imitating a legitimate SolarWinds protocol. The cyber criminals then initiate a “command and control” communication on other domains/IPs, exchanged via the initial connection.
Note that the mere fact of connection to the avsvmcloud.com URL does not therefore automatically mean that the IS has been actively compromised. It is necessary to check that it is followed by communications to other domains/IPs.
Technical details about the Sunburst attack
This malware is technologically very advanced, and uses a variety of dissimulation techniques such as:
- Use of Virtual Private Server for C&C communication, with IP addresses that geographically match those of the victim’s own country;
- Rotation of the “last mile” IP to different geographical points to limit detection;
- Steganography to conceal C&C communications, using the official “Orion Improvement Protocol” as a channel;
- Detection (and termination) of execution in a sandbox-type environment;
- Use of spoofed authentication tokens and accounts for lateral movements, as the alerts generated by such spoofing are not generally sufficiently critical to be visible.
As with most targeted attacks, one of the main goals of cyber-criminals is to obtain a certain level of persistence of access to the victim's IS. This is obviously the case here, too. A number of mechanisms have been observed:
- Creation of privileged accounts and authentication tokens in the Azure Active Directory, for example (access to the “Key Vault”);
- Addition of a new “federation trust” to the victim's domain; more specifically, of a “new Active Directory Federated Services (ADFS) TrustedRealm object” as a new root certificate;
- Installation of other Trojans, etc.
The attack's various IoCs (Indicators of Compromise) have been published by FireEye, and are available here:
- Applicable counter-measures for detecting the SunBurst malware: github.com/fireeye/sunburst_countermeasures
- Applicable countermeasures to detect the use of the Red Team tools stolen from FireEye: github.com/fireeye/red_team_tool_countermeasures
Stormshield protection methods against the Sunburst attack
Using these IoCs, we have developed detection signatures for our Stormshield Network Security (SNS) network protection and Stormshield Endpoint Security (SES) workstation protection solutions. Below are further details of these solutions, along with generic recommendations.
Protection with SNS
Several areas of protection can be activated for SNS:
- SNS's integrated antivirus database (whether basic or optional) must be updated to include the new Sunburst-related signatures (corrupted SolarWinds and FireEye Red Team files). This means the ClamAV 26018 database version and more recent, and the Kaspersky signature version of 13 December.
- The “Malware” category of our Extended Web Control option includes the malicious URLs used by Sunburst for “command and control” and “Beacon” communications. If you have not subscribed to this option, you can block the following URLs using a custom category:
- Lastly, we have developed our own IPS signatures listed below. These signatures detect the use of FireEye Red Team tools and the various exploitation phases of the Orion software vulnerability:
Protection with SES
Our version 7.2 SES solutions and version 2.0 SES Evolution solutions already provide protection against the use of FireEye Red Team tools and any other malware that the corrupted version of Orion may have created and executed using process control functions and system resources.
However, in the interests of improved incident detection and handling, we have incorporated a hash database covering all of the currently known files in FireEye's Red Team tools. A total of 103 hashes have been incorporated into this package:
In addition, specifically for SES Evolution, we have also integrated the rules required to cover early suspect behaviour by corrupt versions of the Orion software.
This represents 19 IP addresses which are now controlled, representing the servers used by these corrupt versions. For added protection, the potentially corrupted Orion host program is monitored carefully and denied the right to create malicious files. Similarly, the child processes it creates are blocked if they reference programs that are not other Orion suite programs.
This package can be configured for use in blocking or alert mode. Important: for SES Evolution, this set of rules must be inserted before the default protection set.
Recommended action against the Sunburst attack
Obviously, the main recommendation is to patch SolarWinds’ Orion application.
Next, check whether there have been any communications with the avsvmcloud.com domain since October 2019. If there have, check whether other unusual domains have been communicating with systems hosting the Orion application. In any event, we strongly recommend that you carry out an in-depth investigation on your IS, following the stages below:
- Disconnect any potentially compromised systems from the Internet;
- Open an incident with the relevant authorities;
- Conduct a review of privileged accounts and past activities for these accounts;
- Retrace security false positives from the past year to reassess the situation in light of the new available information regarding the incident;
- Trace and monitor any unusual Internet activity, and if necessary, switch to “whitelist” mode to restrict Internet access to domains that are deemed to be safe;
- And most importantly, get professional support if your teams are unable to deal with the incident.
Find out more about the Sunburst attack:
- Solarwinds Security Advisory: solarwinds.com/securityadvisory
- US government directive: cyber.dhs.gov/ed/21-01/
- The US government CERT: us-cert.cisa.gov/ncas/alerts/aa20-352a
- The FireEye press release: fireeye.com/blog/products-and-services/2020/12/fireeye-shares-details-of-recent-cyber-attack-actions-to-protect-community.html
- FireEye's detailed analysis: fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
- GitHub detection masters: github.com/Azure/Azure-Sentinel/blob/master/Detections/SigninLogs/AzureAADPowerShellAnomaly.yaml & github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/ADFSDomainTrustMods.yaml
- The Kaspersky agent’s detailed protection: securelist.com/how-we-protect-against-sunburst-backdoor/99959/