Update on the SolarWinds Orion Code Compromise

Last week we reported on the SolarWinds Orion Code Compromise, following our initial story additional information has been made available.

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 CISA has evidence that there are initial access vectors other than the SolarWinds Orion platform. Specifically, they are investigating incidents in which activity indicating abuse of SAML tokens consistent with this adversary’s behavior is present, yet where impacted SolarWinds instances have not been identified. CISA is working to confirm initial access vectors and identify any changes to the TTPs.

Privilege Escalation and Persistence [TA0004, TA0003]

The adversary has been observed using multiple persistence mechanisms across a variety of intrusions. CISA has observed the threat actor adding authentication tokens and credentials to highly privileged Active Directory domain accounts as a persistence and escalation mechanism. In many instances, the tokens enable access to both on-premise and hosted resources. Microsoft has released a query that can help detect this activity.[4]

Microsoft reported that the actor has added new federation trusts to existing 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.[5]

User Impersonation

The adversary’s initial objectives, as understood today, appear to be to collect information from victim environments. One of the principal ways the adversary is accomplishing this objective is by compromising the Security Assertion Markup Language (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 application programming interfaces (APIs).

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.

• Hosted email services
• Hosted business intelligence applications
• Travel systems
• Timecard systems
• File storage services (such as SharePoint)

Detection: Impossible Logins

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.

Detection: Impossible Tokens

The following conditions may indicate adversary activity.

• Most organizations have SAML tokens with 1-hour validity periods. Long SAML token validity durations, such as 24 hours, could be unusual.
• The SAML token contains different timestamps, including the time it was issued and the last time it was used. A token having the same timestamp for when it was issued and when it was used is not indicative of normal user behavior as users tend to use the token within a few seconds but not at the exact same time of issuance.
• A token that does not have an associated login with its user account within an hour of the token being generated also warrants investigation.

Mitigations

SolarWinds Orion Owners

Owners of vulnerable SolarWinds Orion products will generally fall into one of three categories.

• Category 1 (updated December 19, 2020) includes those who do not have the identified malicious binary. These owners (except federal agencies subject to ED 21-01) can patch their systems and resume use as determined by and consistent with their internal risk evaluations. 
• Category 2 includes those who have identified the presence of the malicious binary—with or without beaconing to avsvmcloud[.]com. Owners with malicious binary whose vulnerable appliances only unexplained external communications are with avsvmcloud[.]com—a fact that can be verified by comprehensive network monitoring for the device—can harden the device, re-install the updated software from a verified software supply chain, and resume use as determined by and consistent with a thorough risk evaluation.
• Category 3 includes those with the binary beaconing to avsvmcloud[.]com and secondary C2 activity to a separate domain or IP address. If you observed communications with avsvmcloud[.]com that appear to suddenly cease prior to December 14, 2020— not due to an action taken by your network defenders—you fall into this category. Assume the environment has been compromised, and initiate incident response procedures immediately.

Further information is available at – https://us-cert.cisa.gov/ncas/alerts/aa20-352a