The Cybersecurity and Infrastructure Security Agency (CISA) is aware of compromises of U.S. government agencies, critical infrastructure entities, and private sector organizations by an advanced persistent threat (APT) actor beginning in at least March 2020. This APT actor has demonstrated patience, operational security, and complex tradecraft in these intrusions. CISA expects that removing this threat actor from compromised environments will be highly complex and challenging for organizations.
(Updated January 6, 2021): One of the initial access vectors for this activity is a supply chain compromise of a Dynamic Link Library (DLL) in the following SolarWinds Orion products (see Appendix A). Note: prior versions of this Alert included a single bullet that listed two platform versions for the same DLL. For clarity, the Alert now lists these platform versions that share the same DLL version number separately, as both are considered affected versions.
Note (updated January 6, 2021): CISA has evidence that there are initial access vectors other than the SolarWinds Orion platform and has identified legitimate account abuse as one of these vectors (for details refer to Initial Access Vectors section). Specifically, we are investigating incidents in which activity indicating abuse of Security Assertion Markup Language (SAML) tokens consistent with this adversary's behavior is present, yet where impacted SolarWinds instances have not been identified. CISA is continuing to work to confirm initial access vectors and identify any changes to the tactics, techniques, and procedures (TTPs). CISA will update this Alert as new information becomes available. Refer to CISA.gov/supply-chain-compromise for additional resources.
(Updated January 6, 2021): On December 13, 2020, CISA released Emergency Directive 21-01: Mitigate SolarWinds Orion Code Compromise, ordering federal civilian executive branch departments and agencies to disconnect affected devices. CISA has subsequently issued supplemental guidance to Emergency Directive (ED) 21-01, most recently on January 6, 2021. Note: this Activity Alert does not supersede the requirements of ED 21-01 or any supplemental guidance and does not represent formal guidance to federal agencies under ED 21-01.
CISA has determined that this threat poses a grave risk to the Federal Government and state, local, tribal, and territorial governments as well as critical infrastructure entities and other private sector organizations. CISA advises stakeholders to read this Alert and review the enclosed indicators (see Appendix B).
(Updated January 7, 2021) For a downloadable list of indicators of compromise (IOCs), see the STIX file.
CISA is aware of compromises, which began at least as early as March 2020, at U.S. government agencies, critical infrastructure entities, and private sector organizations by an APT actor. This threat actor has demonstrated sophistication and complex tradecraft in these intrusions. CISA expects that removing the threat actor from compromised environments will be highly complex and challenging. This adversary has demonstrated an ability to exploit software supply chains and shown significant knowledge of Windows networks. It is likely that the adversary has additional initial access vectors and TTPs that have not yet been discovered. CISA will continue to update this Alert and the corresponding IOCs as new information becomes available.
(Updated January 6, 2021): CISA is investigating incidents that exhibit adversary TTPs consistent with this activity, including some where victims either do not leverage SolarWinds Orion or where SolarWinds Orion was present but where there was no SolarWinds exploitation activity observed. CISA incident response investigations have identified that initial access in some cases was obtained by password guessing [T1101.001], password spraying [T1101.003], and inappropriately secured administrative credentials [T1078] accessible via external remote access services [T1133]. Initial access root cause analysis is still ongoing in a number of response activities and CISA will update this section as additional initial vectors are identified.
Volexity has also reported publicly that they observed the APT using a secret key that the APT previously stole in order to generate a cookie to bypass the Duo multi-factor authentication (MFA) protecting access to Outlook Web App (OWA).[1] Volexity attributes this intrusion to the same activity as the SolarWinds Orion supply chain compromise, and the TTPs are consistent between the two. This observation indicates that there are other initial access vectors beyond SolarWinds Orion, and there may still be others that are not yet known.
SolarWinds Orion is an enterprise network management software suite that includes performance and application monitoring and network configuration management along with several different types of analyzing tools. SolarWinds Orion is used to monitor and manage on-premise and hosted infrastructures. To provide SolarWinds Orion with the necessary visibility into this diverse set of technologies, it is common for network administrators to configure SolarWinds Orion with pervasive privileges, making it a valuable target for adversary activity.
The threat actor has been observed leveraging a software supply chain compromise of SolarWinds Orion products[2] (see Appendix A). The adversary added a malicious version of the binary solarwinds.orion.core.businesslayer.dll into the SolarWinds software lifecycle, which was then signed by the legitimate SolarWinds code signing certificate. This binary, once installed, calls out to a victim-specific avsvmcloud[.]com domain using a protocol designed to mimic legitimate SolarWinds protocol traffic. After the initial check-in, the adversary can use the Domain Name System (DNS) response to selectively send back new domains or IP addresses for interactive command and control (C2) traffic. Consequently, entities that observe traffic from their SolarWinds Orion devices to avsvmcloud[.]com should not immediately conclude that the adversary leveraged the SolarWinds Orion backdoor. Instead, additional investigation is needed into whether the SolarWinds Orion device engaged in further unexplained communications. If additional Canonical Name record (CNAME) resolutions associated with the avsvmcloud[.]com domain are observed, possible additional adversary action leveraging the backdoor has occurred.
Based on coordinated actions by multiple private sector partners, as of December 15, 2020, avsvmcloud[.]com resolves to 20.140.0[.]1, which is an IP address on the Microsoft blocklist. This negates any future use of the implants and would have caused communications with this domain to cease. In the case of infections where the attacker has already moved C2 past the initial beacon, infection will likely continue notwithstanding this action.
SolarWinds Orion typically leverages a significant number of highly privileged accounts and access to perform normal business functions. Successful compromise of one of these systems can therefore enable further action and privileges in any environment where these accounts are trusted.
The adversary is making extensive use of obfuscation to hide their C2 communications. The adversary is using virtual private servers (VPSs), often with IP addresses in the home country of the victim, for most communications to hide their activity among legitimate user traffic. The attackers also frequently rotate their "last mile" IP addresses to different endpoints to obscure their activity and avoid detection.
FireEye has reported that the adversary is using steganography (Obfuscated Files or Information: Steganography [T1027.003]) to obscure C2 communications.[3] This technique negates many common defensive capabilities in detecting the activity. Note: CISA has not yet been able to independently confirm the adversary's use of this technique.
According to FireEye, the malware also checks for a list of hard-coded IPv4 and IPv6 addresses—including RFC-reserved IPv4 and IPv6 IP—in an attempt to detect if the malware is executed in an analysis environment (e.g., a malware analysis sandbox); if so, the malware will stop further execution. Additionally, FireEye analysis identified that the backdoor implemented time threshold checks to ensure that there are unpredictable delays between C2 communication attempts, further frustrating traditional network-based analysis.
While not a full anti-forensic technique, the adversary is heavily leveraging compromised or spoofed tokens for accounts for lateral movement. This will frustrate commonly used detection techniques in many environments. Since valid, but unauthorized, security tokens and accounts are utilized, detecting this activity will require the maturity to identify actions that are outside of a user's normal duties. For example, it is unlikely that an account associated with the HR department would need to access the cyber threat intelligence database.
Taken together, these observed techniques indicate an adversary who is skilled, stealthy with operational security, and is willing to expend significant resources to maintain covert presence.
(Updated January 6, 2021): The adversary has been observed using multiple persistence mechanisms across a variety of intrusions. CISA has observed the threat actor adding authentication credentials, in the form of assigning tokens and certificates, to existing Azure/Microsoft 365 (M365) application service principals. These additional credentials provide persistence and escalation mechanisms and a programmatic method of interacting with the Microsoft Cloud tenants (often with Microsoft Graph Application Programming Interface [API]) to access hosted resources without significant evidence or telemetry being generated.
(Updated January 6, 2021): Microsoft reported that the actor has added new federation trusts to existing on permises infrastructure, a technique that CISA believes was utilized by a threat actor in an incident to which CISA has responded. Where this technique is used, it is possible that authentication can occur outside of an organization's known infrastructure and may not be visible to the legitimate system owner. Microsoft has released a query to help identify this activity, as well as a Sentinel detection for identifying changes to the identity federation from a user or application.[4]
(Updated January 6, 2021): The adversary's initial objectives, as understood today, appear to be to collect information from victim environments. One method the adversary is accomplishing this objective is by compromising the SAML signing certificate using their escalated Active Directory privileges. Once this is accomplished, the adversary creates unauthorized but valid tokens and presents them to services that trust SAML tokens from the environment. These tokens can then be used to access resources in hosted environments, such as email, for data exfiltration via authorized APIs. During the persistence phase, the additional credentials being attached to service principals obfuscates the activity of user objects, because they appear to be accessed by the individual, and such individual access is normal and not logged in all M365 licensing levels.
CISA has observed in its incident response work adversaries targeting email accounts belonging to key personnel, including IT and incident response personnel.
These are some key functions and systems that commonly use SAML.
CISA created Sparrow.ps1[5] to help detect possible compromised accounts and applications in the Azure/M365 environment. Sparrow is intended for use by incident responders and focuses on the narrow scope of user and application activity endemic to identity- and authentication-based attacks seen recently in multiple sectors. It is neither comprehensive nor exhaustive of available data and is intended to narrow a larger set of available investigation modules and telemetry to those specific to recent intrusions on federated identity sources and applications. Sparrow can be found on CISA's Github page at https://github.com/cisagov/Sparrow.
The adversary is using a complex network of IP addresses to obscure their activity, which can result in a detection opportunity referred to as "impossible travel." Impossible travel occurs when a user logs in from multiple IP addresses that are a significant geographic distance apart (i.e., a person could not realistically travel between the geographic locations of the two IP addresses during the time period between the logins). Note: implementing this detection opportunity can result in false positives if legitimate users apply virtual private network (VPN) solutions before connecting into networks.
The following conditions may indicate adversary activity.
(New December 21, 2020): see the National Security Agency (NSA) Cybersecurity Advisory: Detecting Abuse of Authentication Mechanisms for additional detection methods as well as mitigation recommendations.
Due to the nature of this pattern of adversary activity—and the targeting of key personnel, incident response staff, and IT email accounts—discussion of findings and mitigations should be considered very sensitive, and should be protected by operational security measures. An operational security plan needs to be developed and socialized, via out-of-band communications, to ensure all staff are aware of the applicable handling caveats.
Operational security plans should include:
CISA assesses that the threat actor engaged in the activities described in this Alert uses the below-listed ATT&CK techniques.
Networks with SolarWinds Orion products will generally fall into one of three categories. (Note: for the purposes of mitigation analysis, a network is defined as any computer network with hosts that share either a logical trust or any account credentials with SolarWinds Orion.)
avsvmcloud[.]com. This includes networks that previously utilized affected versions of SolarWinds Orion but where the organization has forensically verified (through comprehensive network monitoring and analysis) that platforms running the affected software either:avsvmcloud[.]com and have not had any secondary C2 activity to a separate domain or IP address or other adversary activity or secondary actions on objectives (AOOs),[6] such as SAML token abuse.any:any) communications outside of the organization's device network management enclave, with additional assurance that communications to the public internet to and from hosts running SolarWinds Orion products has been blocked.avsvmcloud[.]com and secondary C2 activity to a separate domain or IP address (typically but not exclusively returned in avsvmcloud[.]com CNAME responses). Additionally, organizations that have observed communications with avsvmcloud[.]com that appear to suddenly cease prior to December 14, 2020—not due to an action taken by their network defenders—fall into this category. Assume the environment has been compromised, and initiate incident response procedures immediately. Recovery and remediation of Category 3 activity requires a complex reconstitution and mitigation plan, which may include comprehensively rebuilding the environment. This should be coordinated with an organization's leadership and incident response team.Compromise Mitigations
(Updated January 6, 2021): If the adversary has compromised administrative level credentials in an environment—or if organizations identify SAML abuse in the environment, simply mitigating individual issues, systems, servers, or specific user accounts will likely not lead to the adversary's removal from the network. In such cases, organizations should consider the entire identity trust store as compromised. In the event of a total identity compromise, a full reconstitution of identity and trust services is required to successfully remediate. In this reconstitution, it bears repeating that this threat actor is among the most capable, and in many cases, a full rebuild of the environment is the safest action. A Microsoft blog post, Advice for incident responders on recovery from systemic identity compromises outlines processes and procedures needed to remediate this type of activity and retain administrative control of an environment. In addition to the recommendations in this blog post, CISA recommends the following actions:
The following mitigations apply to networks using the SolarWinds Orion product. This includes any information system that is used by an entity or operated on its behalf.
Organizations that have the expertise to take the actions in Step 1 immediately should do so before proceeding to Step 2. Organizations without this capability should proceed to Step 2. Federal civilian executive branch agencies should ignore the below and refer instead to Emergency Directive 21-01 (and forthcoming associated guidance) for mitigation steps.
See Joint Alert on Technical Approaches to Uncovering and Remediating Malicious Activity for more information on incident investigation and mitigation steps based on best practices.
CISA will update this Alert, as information becomes available and will continue to provide technical assistance, upon request, to affected entities as they work to identify and mitigate potential compromises.
CISA encourages recipients of this report to contribute any additional information that they may have related to this threat. For any questions related to this report, please contact CISA at
CISA encourages you to report any suspicious activity, including cybersecurity incidents, possible malicious code, software vulnerabilities, and phishing-related scams. Reporting forms can be found on the CISA/US-CERT homepage at http://www.us-cert.cisa.gov/.
Table 1 identifies recent versions of SolarWinds Orion Platforms and indicates whether they have been identified as having the Sunburst backdoor present. (Updated January 6, 2021: added SHA-1 and MD5 hashes to table 1; updated SHA-256 hash for version 2019.4 HF6).
Table 1: Affected SolarWinds Orion Products
| Orion Platform Version | Sunburst Backdoor Code Present | File Version | SHA-256 | SHA-1 | MD5 |
|---|---|---|---|---|---|
| 2019.4 | Tampered but not backdoored | 2019.4.5200.8890 | a25cadd48d70f6ea0c4a241d99c5241269e6faccb4054e62d16784640f8e53bc | 5e643654179e8b4cfe1d3c1906a90a4c8d611cea | e18a6a21eb44e77ca8d739a72209c370 |
| 2019.4 HF1 | No | 2019.4.5200.8950 | 9bee4af53a8cdd7ecabe5d0c77b6011abe887ac516a5a22ad51a058830403690 | 48e84a1ed30d36f6750bce8748fe0edbfa9fb3dc | b3f7ac8215b73e73e1e184933c788759 |
| 2019.4 HF2 | No | 2019.4.5200.8996 | bb86f66d11592e3312cd03423b754f7337aeebba9204f54b745ed3821de6252d | 162bb92a18bb39ac7e9a9997369a6efe0dd74094 | 563d4d55eae72710f9419975d087fd11 |
| 2019.4 HF3 | No | 2019.4.5200.9001 | ae6694fd12679891d95b427444466f186bcdcc79bc0627b590e0cb40de1928ad | 98bb0c5d1a711472225dc1194133f37c80159664 | d22e80d03fe69389cbf3299f6f800f80 |
| 2019.4 HF4 | No | 2019.4.5200.9045 | 9d6285db647e7eeabdb85b409fad61467de1655098fec2e25aeb7770299e9fee | 2a255070160b1c6fcad4f0586b64691fe8b6d0f8 | 6b5f205d79a647b275500597975314a5 |
| 2020.2 RC1 | Yes | 2020.2.100.12219 | dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b | 1acf3108bf1e376c8848fbb25dc87424f2c2a39c | 731d724e8859ef063c03a8b1ab7f81ec |
| 2019.4 HF5 | Yes | 2019.4.5200.9083 | 32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77 | 76640508b1e7759e548771a5359eaed353bf1eec | b91ce2fa41029f6955bff20079468448 |
| 2020.2 RC2 | Yes | 2020.2.5200.12394 | 019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134 | 2f1a5a7411d015d01aaee4535835400191645023 | 2c4a910a1299cdae2a4e55988a2f102e |
2020.2 2020.2 HF1 | Yes | 2020.2.5300.12432 | ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6 | d130bd75645c2433f88ac03e73395fba172ef676 | 846e27a652a5e1bfbd0ddd38a16dc865 |
| 2019.4 HF6 | No | 2019.4.5200.9106 | 8dfe613b00d495fb8905bdf6e1317d3e3ac1f63a626032fa2bdad4750887ee8a | 00f66fc1f74b9ecabf1aafc123f2ef0f94edc258 | 1412c74537fc769b5dd34b4c1da0bf48 |
2020.2.1 2020.2.1 HF1 | No | 2020.2.15300.12766 | 143632672dcb6ef324343739636b984f5c52ece0e078cfee7c6cac4a3545403a | 8acbcc116baa80262d09635bd312018372fefca6 | 2d9b1245d42bb9f928da2528bb057de2 |
| 2020.2.1 HF2 | No | 2020.2.15300.12901 | cc870c07eeb672ab33b6c2be51b173ad5564af5d98bfc02da02367a9e349a76f | babf9af689033fa2a825528715ae6dc625619e65 | 610ec1ab7701b410df1e309240343cdf |
Due to the operational security posture of the adversary, most observable IOCs are of limited utility; however, they can be useful for quick triage. Below is a compilation of IOCs from a variety of public sources provided for convenience. CISA will be updating this list with CISA developed IOCs as our investigations evolve. Note: removed two IOCs (12.227.230[.]4, 65.153.203[.]68) and corrected typo, updated December 19, 2020; added multiple new IOCs on January 6, 2021 (new IOCs added are at the bottom of the table); corrected typos, added new IOC, and deleted duplicate hash on January 7, 2021.
Table 2: Indicators of Compromise