On Dec. 12, 2020, FireEye provided detailed information on a widespread attack campaign involving a backdoored component of the SolarWinds Orion platform, which is used by organizations to monitor and manage IT infrastructure. FireEye has given the campaign an identifier of UNC2452 and is further naming the trojanized version of the SolarWinds Orion component SUNBURST (Microsoft has used the “Solorigate” identifier for the malware and added detection rules to its Defender antivirus). SolarWinds has issued a separate advisory for the incident.
In this blog post, we will focus on answering specific questions organizations may have regarding this situation.
What is Rapid7 doing as a result of the disclosure of the SUNBURST/Solorigate disclosure?
For InsightIDR customers
Rapid7 has deployed detections in InsightIDR for activity related to vulnerable versions of SolarWinds Orion and will continue to add additional IOCs/TTPs as they become available. We recommend that all customers running SolarWinds Orion versions 2019.4 through 2020.2.1 should upgrade to the Orion platform to version 2020.2.1 HF 1 ASAP.
We will also publish queries you can perform in your environment to look for this vulnerability.
For our MDR customers
We are analyzing your agent, DNS, firewall, and other log data that exists in IDR for IOCs/TTPs related to this threat, and specifically the IOCs released by FireEye.
For InsightVM customers
InsightVM and Nexpose customers can scan their environments for affected versions of SolarWinds Orion using the remote checks published in the December 16 content release (update ID
Rapid7 Nexpose customers can create a Dynamic Asset Group based on a filtered asset search for “Software name contains Solarwinds Orion”.
InsightVM and Nexpose customers can also assess their exposure to SolarWinds Orion CVE-2020-10148 with a remote check as of 2020-12-29.
For MVM customers
Rapid7 MVM customers will see a report in their InsightVM console “Solarwinds_assets_20201214” to assist organizations in identifying any asset that we can see that contains any software with “Solarwinds'' in the name. There is a specific report, “SolarWinds Orion”, that you will see in your console to narrow it down to the “Orion” software.
If my organization uses SolarWinds components but does not use the Orion platform, are we at risk?
Right now, the only known compromised SolarWinds components are one library file,
SolarWinds.Orion.Core.BusinessLayer.dll, in the Orion platform. If you are not running a version of Orion that has installed updates between March and June 2020, you are likely not running compromised SolarWinds software. Affected versions are 2019.4 through 2020.2.1 HF1. The specific statements from SolarWinds’ Dec. 14, 2020 8-K filing indicate that:
- Orion products downloaded, implemented, or updated during the Relevant Period contained the vulnerability;
- Orion products downloaded and implemented before the Relevant Period and not updated during the Relevant Period did not contain the vulnerability;
- Orion products downloaded and implemented after the Relevant Period did not contain the vulnerability; and
- Previously affected versions of the Orion products that were updated with a build released after the Relevant Period no longer contained the vulnerability; however, the server on which the affected Orion products ran may have been compromised during the period in which the vulnerability existed.
SolarWinds further estimated a potential of up to 18,000 organizations may have installed the compromised component.
How can my organization detect whether attackers used this backdoor against us?
If you were one of the 18,000 organizations potentially running compromised Orion components, FireEye has provided a number of countermeasures and indicators of compromise that you can deploy in detection (looking at future events) and forensics (going back through firewall/intrusion detection logs, system/network events, and cybersecurity monitoring alerts) contexts.
Be aware that if you are running a backdoored version of this Orion component, your detection and forensics efforts will show beacon activity to the attacker infrastructure. This does not mean you are under active attack. It just means that the command and control components of the backdoor are functional. Now that the attacker campaign has been brought into public awareness, it is very likely that they will rapidly tear down all of the infrastructure they were using and any operations they had in play.
Apart from deploying the provided detections, what else should my organization do if we were running a compromised version of SolarWinds Orion?
The most proactive and cautious response would be to assume all hosts monitored by compromised Orion systems are, themselves, compromised. Restoring operations to a known-good state would involve:
- Resetting all credentials used by or stored in SolarWinds Orion.
- Rebuilding all hosts monitored by SolarWinds Orion from trusted sources (SolarWinds currently expects to release a public hotfix on or prior to Dec. 15, 2020).
Since it appears that the campaign was highly targeted, another, less disruptive approach should start with referring to the guidance from the SolarWinds advisory. Specifically, consider upgrading to the current hotfix (2020.2.1 HF 1) as soon as possible and monitoring communications from SolarWinds for the release of version 2020.2.1 HF 2 hotfix.
Once patched, organizations taking a less disruptive approach should ensure that SolarWinds servers are isolated and consider applying the following actions:
- Restrict the scope of accounts that have local administrator privileges on SolarWinds servers.
- Block internet egress from servers or other endpoints with SolarWinds software.
- Change passwords for accounts that have access to SolarWinds servers/infrastructure.
For either scenario (cautious or less disruptive), if SolarWinds is used to manage networking infrastructure, consider conducting a review of network device configurations for unexpected/unauthorized modifications.
Active Directory administrators should also review account creation and deletion activity, since the organization deployed compromised versions of Orion, and pay close attention to anomalous patterns, especially around accounts with privileged/admin access.
All secret keys associated with multi-factor authentication or application integrations housed on devices managed or monitored by Orion should be considered compromised and reset.
Will Rapid7 be providing updates as new information becomes available?
Rapid7 is actively monitoring all SolarWinds and FireEye updates as well as threat intelligence feeds and breaking news reports and will both update the blog and notify customers of significant events as they arise.
Dec. 15, 2020
In light of information published by researchers at Volexity, the section of the blog post identifying post-event actions organizations can/should take has been updated to include guidance on resetting secret keys associated with multi-factor authentication and/or application integrations.
Dec. 16, 2020
Late Tuesday evening, SolarWinds issues the second hotfix for their Orion platform and are urging affected customers on Orion Platform v2020.2 with no hotfix or 2020.2 HF 1 to upgrade to Orion Platform version 2020.2.1 HF 2 and those on Orion Platform v2019.4 HF 5 to update to 2019.4 HF 6 as soon as possible.
Dec. 16, 2020
InsightVM and Nexpose customers can now scan their environments for affected versions of SolarWinds Orion using the remote checks published in the December 16 content release (update ID
Dec. 23, 2020
Harley Geiger, Scott King, and Bob Rudis have put together a webcast that provides a timeline of key events associated with the SolarWinds compromise and provides guidance on how organizations can effectively respond to the incident, especially those that were directly impacted by the adversarial campaign. Content also includes insights on regulatory-impacting aspects of the incident and further presents response coverage areas that might be overlooked in some organizations.
Dec. 29, 2020
SolarWinds has updated their advisory again to provide guidance following the release of CVE-2020-10148 which identifies an unauthenticated, remote code execution weakness in the SolarWinds Orion API. This API is a central part of the Orion platform with highly privileged access to all Orion platform components. Attackers need only craft specific parameters within the
Request.PathInfo URI component. Attackers may further bypass authentication by setting the
CVE-2020-10148 was reported as a zero-day and is an active threat. Patches are available and as of 2020-12-24 organizations should be on one of the following versions to mitigate this weakness:
- 2019.4 HF 6 (released December 14, 2020)
- 2020.2.1 HF 2 (released December 15, 2020)
- 2019.2 SUPERNOVA Patch (released December 23, 2020)
- 2018.4 SUPERNOVA Patch (released December 23, 2020)
- 2018.2 SUPERNOVA Patch (released December 23, 2020)
InsightVM and Nexpose customers can assess their exposure to CVE-2020-10148 with a remote check as of 2020-12-29.
Jan. 6, 2021
CISA has updated their supplemental guidance indicating that Federal agencies who utilize SolarWinds Orion platform in the cloud should segment oversight and control operations of cloud-based assets to cloud-only hosted SolarWinds Orion platform installations and establish a control framework on both cloud and internal, organizational networks to prohibit SolarWinds Orion platform servers and agents from engaging in communications to/from the internet.
Furthermore, CISA stated that organizations who still utilize SolarWinds Orion platform components update their installations immediately after SolarWinds issues additional updates in 2021.
More information can be found at "CISA Updates Emergency Directive 21-01 Supplemental Guidance and Activity Alert on SolarWinds Orion Compromise | CISA".
Jan. 12, 2021
We've published a new blog post, Update on SolarWinds Supply-Chain Attack: SUNSPOT and New Malware Family Associations, covering new developments in the ongoing investigations of the SolarWinds supply-chain attack. CrowdStrike provided a detailed exposition of the malware component used to inject their compromised code and artifacts into the SolarWinds build process and Kaspersky has identified characteristics of SUNBURST that suggest it may have the Kazuar backdoor as part of its lineage.
Jan. 19, 2020
On Monday, Jan. 18, 2021, Symantec researchers disclosed findings that point to a new, additional malware component that has been found in select victims associated with the SolarWinds attacks. This new malware backdoor has been christened “Raindrop” (we told you we’d run out of ☀️-themed names) or, more formally,
“Backdoor.Raindrop” and is a loader—software that is designed to retrieve additional components for use further attacker operations—that delivers a Cobalt Strike payload.
Raindrop is similar to Teardrop (revealed by FireEye back in December 2020), but appears to be geared toward post-compromise lateral movement, enabling it to spread across a victim’s network. Unlike Teardrop, Symantec has asserted that Raindrop is not being delivered by SUNBURST, but has appeared after a victim has been compromised with SUNBURST.
Symantec chronicles a timeline of many victims, detailing numerous installed components, PowerShell commands, and diverse command and control techniques ranging from HTTP-based interaction to SMB named network pipes. When focusing solely on HTTP interaction, Raindrop shares many features and characteristics with Teardrop, including the HTTP
POST form setup used to retrieve components.
Symantec has provided YARA rules and other indicators of compromise (IoCs) that defenders can use to identify older Raindrop activity and detect current use.