Cybersecurity Webinar — SolarWinds Sunburst: The Big Picture

The SolarWinds Sunburst attack has been in the headlines since it was first discovered in December 2020. 
As the so-called layers of the onion are peeled back, additional information regarding how the vulnerability was exploited, who was behind the attack, who is to blame for the attack, and the long-term ramifications of this type of supply chain vulnerabilities continue to be actively
The Hacker News – Read More

Another Critical RCE Flaw Discovered in SolarWinds Orion Platform

IT infrastructure management provider SolarWinds on Thursday released a new update to its Orion networking monitoring tool with fixes for four security vulnerabilities, counting two weaknesses that could be exploited by an authenticated attacker to achieve remote code execution (RCE).
Chief among them is a JSON deserialization flaw that allows an authenticated user to execute arbitrary code via
The Hacker News – Read More

AA21-077A: Detecting Post-Compromise Threat Activity Using the CHIRP IOC Detection Tool

Posted from CISA Alerts
Read More
Original release date: March 18, 2021

Summary

This Alert announces the CISA Hunt and Incident Response Program (CHIRP) tool. CHIRP is a forensics collection tool that CISA developed to help network defenders find indicators of compromise (IOCs) associated with activity detailed in the following CISA Alerts:

Similar to Sparrow—which scans for signs of APT compromise within an M365 or Azure environment—CHIRP scans for signs of APT compromise within an on-premises environment.

In this release, CHIRP, by default, searches for IOCs associated with malicious activity detailed in AA20-352A and AA21-008A that has spilled into an on-premises enterprise environment.

CHIRP is freely available on the CISA GitHub Repository. Note: CISA will continue to release plugins and IOC packages for new threats via the CISA GitHub Repository.

CISA advises organizations to use CHIRP to:

  • Examine Windows event logs for artifacts associated with this activity;
  • Examine Windows Registry for evidence of intrusion;
  • Query Windows network artifacts; and
  • Apply YARA rules to detect malware, backdoors, or implants.

Network defenders should review and confirm any post-compromise threat activity detected by the tool. CISA has provided confidence scores for each IOC and YARA rule included with CHIRP’s release. For confirmed positive hits, CISA recommends collecting a forensic image of the relevant system(s) and conducting a forensic analysis on the system(s).

If an organization does not have the capability to follow the guidance in this Alert, consider soliciting third-party IT security support. Note: Responding to confirmed positive hits is essential to evict an adversary from a compromised network.

Click here for a PDF version of this report.

Technical Details

How CHIRP Works

CHIRP is a command-line executable with a dynamic plugin and indicator system to search for signs of compromise. CHIRP has plugins to search through event logs and registry keys and run YARA rules to scan for signs of APT tactics, techniques, and procedures. CHIRP also has a YAML file that contains a list of IOCs that CISA associates with the malware and APT activity detailed in CISA Alerts AA20-352A and AA21-008A.

Currently, the tool looks for:

  • The presence of malware identified by security researchers as TEARDROP and RAINDROP;
  • Credential dumping certificate pulls;
  • Certain persistence mechanisms identified as associated with this campaign;
  • System, network, and M365 enumeration; and
  • Known observable indicators of lateral movement.

Network defenders can follow step-by-step instructions on the CISA CHIRP GitHub repository to add additional IOCs, YARA rules, or plugins to CHIRP to search for post-compromise threat activity related to the SolarWinds Orion supply chain compromise or new threat activity.

Compatibility

CHIRP currently only scans Windows operating systems.

Instructions

CHIRP is available on CISA’s GitHub repository in two forms:

  1. A compiled executable

  2. A python script

CISA recommends using the compiled version to easily scan a system for APT activity. For instructions to run, read the README.md in the CHIRP GitHub repository.

If you choose to use the native Python version, see the detailed instructions on the CHIRP GitHub repository.

Mitigations

Interpreting the Results

CHIRP provides results of its scan in JSON format. CISA encourages uploading the results into a security information and event management (SIEM) system, if available. If no SIEM system is available, results can be viewed in a compatible web browser or text editor. If CHIRP detects any post-compromise threat activity, those detections should be reviewed and confirmed. CISA has provided confidence scores for each IOC and YARA rule included with CHIRP’s release. For confirmed positive hits, CISA recommends collecting a forensic image of the relevant system(s) and conducting a forensic analysis on the system(s).

If you do not have the capability to follow the guidance in this Alert, consider soliciting third-party IT security support. Note: Responding to confirmed positive hits is essential to evict an adversary from a compromised network.

Frequently Asked Questions

  1. What systems should CHIRP run on?

    Systems running SolarWinds Orion or believed to be involved in any resulting lateral movement.

  2. What should I do with results?

    Ingest the JSON results into a SIEM system, web browser, or text editor.

  3. Are there existing tools that CHIRP complements and/or provide the same benefit as CHIRP?
    1. Antivirus software developers may have begun to roll out detections for the SolarWinds post-compromise activity. However, those products can miss historical signs of compromise. CHIRP can provide a complementary benefit to antivirus when run.

    2. CISA previously released the Sparrow tool that scans for APT activity within M365 and Azure environments related to activity detailed in CISA Alerts AA20-352A and AA21-008A. CHIRP provides a complementary capability to Sparrow by scanning for on-premises systems for similar activity.

  4. How often should I run CHIRP?

    CHIRP can be run once or routinely. Currently, CHIRP does not provide a mechanism to run repeatedly in its native format.

  5. Do I need to configure the tool before I run it?

    No.

  6. Will CHIRP change or affect anything on the system(s) it runs on?

    No, CHIRP only scans the system(s) it runs on and makes no active changes.

  7. How long will it take to run CHIRP?

    CHIRP will complete its scan in approximately 1 to 2 hours. Duration will be dependent on the level of activity, the system, and the size of the resident data sets. CHIRP will provide periodic progress updates as it runs.

  8. If I have questions, who do I contact?  

    For general questions regarding CHIRP, please contact CISA via email at [email protected] or by phone at 1-888-282-0870. For reporting indicators of potential compromise, contact us by submitting a report through our website at https://us-cert.cisa.gov/report. For all technical issues or support for CHIRP, please submit issues at the CISA CHIRP GitHub Repository

Revisions

  • March 18, 2021: Initial Publication

This product is provided subject to this Notification and this Privacy & Use policy.

Using CHIRP to Detect Post-Compromise Threat Activity in On-Premises Environments

Originally Posted from CISA Currently Activity
Read More
Original release date: March 18, 2021

CISA Hunt and Incident Response Program (CHIRP) is a new forensics collection tool that CISA developed to help network defenders find indicators of compromise (IOCs) associated with the SolarWinds and Active Directory/M365 Compromise. CHIRP is freely available on the CISA GitHub repository.

Similar to the CISA-developed Sparrow tool—which scans for signs of APT compromise within an M365 or Azure environment—CHIRP scans for signs of APT compromise within an on-premises environment.

CISA Alert AA21-077A: Detecting Post-Compromise Threat Activity using the CHIRP IOC Detection Tool provide guidance on using the new tool. This Alert is a companion to AA20-352A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations and AA21-008A: Detecting Post-Compromise Threat Activity in Microsoft Cloud.

CISA encourages users and administrations to review the Alert for more information. For more technical information on the SolarWinds Orion supply chain compromise, see CISA’s Remediating Networks Affected by the SolarWinds and Active Directory/M365 Compromise web page. For general information on CISA’s response to the supply chain compromise, refer to cisa.gov/supply-chain-compromise.

This product is provided subject to this Notification and this Privacy & Use policy.

Mimecast Finds SolarWinds Hackers Stole Some of Its Source Code

Email security firm Mimecast on Tuesday revealed that the state-sponsored SolarWinds hackers who broke into its internal network also downloaded source code out of a limited number of repositories.
“The threat actor did access a subset of email addresses and other contact information and hashed and salted credentials,” the company said in a write-up detailing its investigation, adding the
The Hacker News – Read More

TTP Table for Detecting APT Activity Related to SolarWinds and Active Directory/M365 Compromise

Originally Posted from CISA Currently Activity
Read More
Original release date: March 17, 2021

CISA has released a table of tactics, techniques, and procedures (TTPs) used by the advanced persistent threat (APT) actor involved with the recent SolarWinds and Active Directory/M365 compromise. The table uses the MITRE ATT&CK framework to identify APT TTPs and includes detection recommendations. This information will assist network defenders in detecting and responding to this activity.

CISA encourages network defenders to review SolarWinds and AD/M365 Compromise: Detecting APT Activity from Known TTPs and implement the recommendations. CISA also recommends network defenders review the following resources regarding this incident:

This product is provided subject to this Notification and this Privacy & Use policy.

Guidance on Remediating Networks Affected by the SolarWinds and Active Directory/M365 Compromise

Originally Posted from CISA Currently Activity
Read More
Original release date: March 9, 2021

Since December 2020, CISA has been responding to a significant cybersecurity incident involving an advanced persistent threat (APT) actor targeting networks of multiple U.S. government agencies, critical infrastructure entities, and private sector organizations. The APT actor added malicious code to multiple versions of the SolarWinds Orion platform and leveraged it—as well as other techniques, including—for initial access to enterprise networks. After gaining persistent, invasive access to select organizations’ enterprise networks, the APT actor targeted their federated identity solutions and their Active Directory/M365 environments. CISA has published two new resources on the follow-on activity from this compromise:

CISA encourages affected organizations to review and apply the necessary guidance in the Remediating Networks Affected by the SolarWinds and Active Directory/M365 Compromise web page and CISA Insights. For general information on CISA’s response to SolarWinds Orion compromise activity, refer to www.cisa.gov/supply-chain-compromise.

This product is provided subject to this Notification and this Privacy & Use policy.

SolarWinds Hack — New Evidence Suggests Potential Links to Chinese Hackers

A malicious web shell deployed on Windows systems by leveraging a previously undisclosed zero-day in SolarWinds’ Orion network monitoring software may have been the work of a possible Chinese threat group.
In a report published by Secureworks on Monday, the cybersecurity firm attributed the intrusions to a threat actor it calls Spiral.
Back on December 22, 2020, Microsoft disclosed that a second
The Hacker News – Read More

SolarWinds Blame Intern for Weak Password That Led to Biggest Attack in 2020

As cybersecurity researchers continue to piece together the sprawling SolarWinds supply chain attack, top executives of the Texas-based software services firm blamed an intern for a critical password lapse that went unnoticed for several years. 
The said password “solarwinds123” was originally believed to have been publicly accessible via a GitHub repository since June 17, 2018, before the
The Hacker News – Read More

SolarWinds Hackers Stole Some Source Code for Microsoft Azure, Exchange, Intune

Microsoft on Thursday said it concluded its probe into the SolarWinds hack, finding that the attackers stole some source code but confirmed there’s no evidence that they abused its internal systems to target other companies or gained access to production services or customer data.
The disclosure builds upon an earlier update on December 31, 2020, that uncovered a compromise of its own network to
The Hacker News – Read More

AA21-008A: Detecting Post-Compromise Threat Activity in Microsoft Cloud Environments

Posted from CISA Alerts
Read More
Original release date: January 8, 2021 | Last revised: February 4, 2021

Summary

This Advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques.

This Alert is a companion alert to AA20-352A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations. AA20-352A primarily focuses on an advanced persistent threat (APT) actor’s compromise of SolarWinds Orion products as an initial access vector into networks of U.S. Government agencies, critical infrastructure entities, and private network organizations. As noted in AA20-352A, the Cybersecurity and Infrastructure Security Agency (CISA) has evidence of initial access vectors in addition to the compromised SolarWinds Orion products.

This Alert also addresses activity—irrespective of the initial access vector leveraged—that CISA attributes to an APT actor. Specifically, CISA has seen an APT actor using compromised applications in a victim’s Microsoft 365 (M365)/Azure environment. CISA has also seen this APT actor utilizing additional credentials and Application Programming Interface (API) access to cloud resources of private and public sector organizations. These tactics, techniques, and procedures (TTPs) feature three key components:

  • Compromising or bypassing federated identity solutions;
  • Using forged authentication tokens to move laterally to Microsoft cloud environments; and
  • Using privileged access to a victim’s cloud environment to establish difficult-to-detect persistence mechanisms for Application Programming Interface (API)-based access.

This Alert describes these TTPs and offers an overview of, and guidance on, available open-source tools—including a CISA-developed tool, Sparrow—for network defenders to analyze their Microsoft Azure Active Directory (AD), Office 365 (O365), and M365 environments to detect potentially malicious activity.

Note: this Alert describes artifacts—presented by these attacks—from which CISA has identified detectable evidence of the threat actor’s initial objectives. CISA continues to analyze the threat actor’s follow-on objectives.

Technical Details

Frequently, CISA has observed the APT actor gaining Initial Access [TA0001] to victims’ enterprise networks via compromised SolarWinds Orion products (e.g., Solorigate, Sunburst).[1] However, CISA is investigating instances in which the threat actor may have obtained initial access by Password Guessing [T1110.001], Password Spraying [T1110.003], and/or exploiting inappropriately secured administrative or service credentials (Unsecured Credentials [T1552]) instead of utilizing the compromised SolarWinds Orion products.

CISA observed this threat actor moving from user context to administrator rights for Privilege Escalation [TA0004] within a compromised network and using native Windows tools and techniques, such as Windows Management Instrumentation (WMI), to enumerate the Microsoft Active Directory Federated Services (ADFS) certificate-signing capability. This enumeration allows threat actors to forge authentication tokens (OAuth) to issue claims to service providers—without having those claims checked against the identity provider—and then to move laterally to Microsoft Cloud environments (Lateral Movement [TA0008]).

The threat actor has also used on-premises access to manipulate and bypass identity controls and multi-factor authentication. This activity demonstrates how sophisticated adversaries can use credentials from one portion of an organization to move laterally (Lateral Movement [TA0008]) through trust boundaries, evade defenses and detection (Defense Evasion [TA0005]), and steal sensitive data (Collection [TA0009]).

This level of compromise is challenging to remediate and requires a rigorous multi-disciplinary effort to regain administrative control before recovering.

Mitigations

Detection

Guidance on identifying affected SolarWinds software is well documented.[2] However—once an organization identifies a compromise via SolarWinds Orion products or other threat actor TTPs—identifying follow-on activity for on-premises networks requires fine-tuned network and host-based forensics.

The nature of cloud forensics is unique due to the growing and rapidly evolving technology footprints of major vendors. Microsoft’s O365 and M365 environments have built-in capabilities for detecting unusual activity. Microsoft also provides premium services (Advanced Threat Protection [ATP] and Azure Sentinel), which enable network defenders to investigate TTPs specific to the Solorigate activity.[3]

Detection Tools

CISA is providing examples of detection tools for informational purposes only. CISA does not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services does not constitute or imply their endorsement, recommendation, or favoring by CISA.

There are a number of open-source tools available to investigate adversary activity in Microsoft cloud environments and to detect unusual activity, service principals, and application activity.[4] Publicly available PowerShell tools that network defenders can use to investigate M365 and Microsoft Azure include:

  • CISA’s Sparrow,
  • Open-source utility Hawk, and
  • CrowdStrike’s Azure Reporting Tool (CRT).

Additionally, Microsoft’s Office 365 Management API and Graph API provide an open interface for ingesting telemetry and evaluating service configurations for signs of anomalous activity and intrusion.

Note: these open-source tools are highlighted and explained to assist with on-site investigation and remediation in cloud environments but are not all-encompassing. Open source tools can be complemented by services such as Azure Sentinel, a Microsoft premium service that provides comprehensive analysis tools, including custom detections for the activity indicated.

General Guidance on Using Detection Tools

  1. Audit the creation and use of service principal credentials. Look for unusual application usage, such as use of dormant applications.
  2. Audit the assignment of credentials to applications that allow non-interactive sign-in by the application. Look for unexpected trust relationships added to the Azure Active Directory.
  3. Download the interactive sign-ins from the Azure admin portal or use the Microsoft Sentinel product. Review new token validation time periods with high values and investigate whether it was a legitimate change or an attempt to gain persistence by a threat actor.

Sparrow

CISA created Sparrow to help network defenders detect possible compromised accounts and applications in the Azure/M365 environment. The tool 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. It is intended to narrow a larger set of available investigation modules and telemetry to those specific to recent attacks on federated identity sources and applications.

CISA advises Sparrow users to take the following actions.

  1. Use Sparrow to detect any recent domain authentication or federation modifications.
    1. Domain and federation modification operations are uncommon and should be investigated.
  2. Examine logs for new and modified credentials applied to applications and service principals; delineate for the credential type. Sparrow can be used to detect the modification of service principals and application credentials.
    1. Create a timeline for all credential changes, focusing on recent wholesale changes.
    2. Review the “top actors” for activity in the environment and the number of credential modifications performed.
    3. Monitor changes in application and service principal credentials.
    4. Investigate any instances of excessive permissions being granted, including, but not limited to, Exchange Online, Microsoft Graph, and Azure AD Graph.
  3. Use Sparrow to detect privilege escalation, such as adding a service principal, user, or group to a privileged role.
  4. Use Sparrow to detect OAuth consent and users’ consent to applications, which is useful for interpreting changes in adversary TTPs.
  5. Use Sparrow to identify anomalous Security Assertion Markup Language (SAML) token sign-ins by pivoting on the unified audit log UserAuthenticationValue of 16457, which is an indicator of how a SAML token was built and is a potential indicator for forged SAML tokens.
    1. Note that this TTP has not been the subject of significant published security research but may indicate an unusual usage of a token, such as guest access for external partners to M365 resources.
  6. Review the PowerShell logs that Sparrow exports.
    1. Review PowerShell mailbox sign-ins and validate that the logins are legitimate actions.
    2. Review PowerShell usage for users with PowerShell in the environment.
  7. Use Sparrow to check the Graph API application permissions of all service principals and applications in M365/Azure AD.
    1. Investigate unusual activity regarding Microsoft Graph API permissions (using either the legacy https://graph.windows.net/ or https://graph.microsoft.com). Graph is used frequently as part of these TTPs, often to access and manipulate mailbox resources.
  8. Review Sparrow’s listed tenant’s Azure AD domains, to see if the domains have been modified.
  9. For customers with G5 or E5 licensing levels, review MailItemsAccessed for insight into what application identification (ID) was used for accessing users’ mailboxes. Use Sparrow to query for a specific application ID using the app id investigation capability, which will check to see if it is accessing mail or file items.
    1. The MailItemsAccessed event provides audibility for mailbox data accessed via mail protocols or clients.
    2. By analyzing the MailItemsAccessed action, incident responders can determine which user mailbox items have been accessed and potentially exfiltrated by a threat actor. This event will be recorded even in some situations where the message was not necessarily read interactively (e.g., bind or sync).[5]
    3. The resulting suspicious application ID can provide incident responders with a pivot to detect other suspicious applications that require additional analysis.
    4. Check for changes to applications with regards to the accessing of resources such as mail or file items.

Hawk

Hawk is an open-source, PowerShell-driven, community-developed tool network defenders can use to quickly and easily gather data from O365 and Azure for security investigations. Incident responders and network defenders can investigate specific user principals or the entire tenant. Data it provides include IP addresses and sign-in data. Additionally, Hawk can track IP usage for concurrent login situations.

Hawk users should review login details for administrator accounts and take the following steps.

  1.  Investigate high-value administrative accounts to detect anomalous or unusual activity (Global Admins).
  2. Enable PowerShell logging, and evaluate PowerShell activity in the environment not used for traditional or expected purposes.
    1. PowerShell logging does not reveal the exact cmdlet that was run on the tenant.
  3. Look for users with unusual sign-in locations, dates, and times.
  4. Check permissions of service principals and applications in M365/Azure AD.
  5. Detect the frequency of resource access from unusual places. Use the tool to pivot to a trusted application and see if it is accessing mail or file items.
  6. Review mailbox rules and recent mailbox rule changes.

CrowdStrike Azure Reporting Tool

CrowdStrike’s Azure Reporting Tool (CRT) can help network defenders analyze their Microsoft Azure AD and M365 environment to help organizations analyze permissions in their Azure AD tenant and service configuration. This tool has minor overlap with Sparrow; it shows unique items, but it does not cover the same areas. CISA is highlighting this tool because it is one of the only free, open-source tools available to investigate this activity and could be used to complement Sparrow.

Detection Tool Distinctions

  • Sparrow differs from CRT by looking for specific indicators of compromise associated with the recent attacks.
  • CRT focuses on the tenant’s Azure AD permissions and Exchange Online configuration settings instead of the unified audit log, which gives it a different output from Sparrow or Hawk.
  • CRT returns the same broad scope of application/delegated permissions for service principals and applications as Hawk.
  • As part of its investigation, Sparrow homes in on a narrow set of application permissions given to the Graph API, which is common to the recent attacks.
  • CRT looks at Exchange Online federation configuration and federation trust, while Sparrow focuses on listing Azure AD domains.
  • Among the items network defenders can use CRT to review are delegated permissions and application permissions, federation configurations, federation trusts, mail forwarding rules, service principals, and objects with KeyCredentials.

Detection Methods

Microsoft breaks the threat actor’s recent activity into four primary stages, which are described below along with associated detection methods. Microsoft describes these stages as beginning with all activity after the compromise of the on-premises identity solution, such as ADFS.[6]

Note: this step provides an entry vector to cloud technology environments, and is unnecessary when the threat actor has compromised an identity solution or credential that allows the APT direct access to the cloud(e.g., without leveraging the SolarWinds Orion vulnerability).

Stage 1: Forging a trusted authentication token used to access resources that trust the on-premises identity provider

These attacks (often referred to as “Golden Security Assertion Markup Language” attacks) can be analyzed using a combination of cloud-based and standard on-premises techniques.[7] For example, network defenders can use OAuth claims for specific principals made at the Azure AD level and compare them to the on-premises identity.

Export sign-in logs from the Azure AD portal and look at the Authentication Method field.

Note: at portal.azure.com, click on a user and review the authentication details (e.g., date, method, result). Without Sentinel, this is the only way to get these logs, which are critical for this effort.

Detection Method 1: Correlating service provider login events with corresponding authentication events in Active Directory Federation Services (ADFS) and Domain Controllers

Using SAML single sign-on, search for any logins to service providers that do not have corresponding event IDs 4769, 1200, and 1202 in the domain.

Detection Method 2: Identifying certificate export events in ADFS

Look for:

  1. The IP address and Activity_ID in EventCode 410 and the Activity_ID and Instance_ID in EventCode 500.
  2. Export-PfxCertificate or certutil-exportPFX in Event IDs 4103 and 4104, which may include detection of a certificate extraction technique.
  3. Deleted certificate extraction with ADFSdump performed using Sysmon Event ID 18 with the pipe name microsoft##widtsqlquery (exclude processes regularly making this pipe connection on the machine).
  4. Event ID 307 (The Federation Service configuration was changed), which can be correlated to relevant Event ID 510 with the same instance ID for change details (Event ID 510 with the same Instance ID could be more than one event per single Event ID 307 event).

Detection Method 3: Customizing SAML response to identify irregular access

This method serves as prevention for the future (and would only detect future, not past, activity), as it helps identify irregularities from the point of the change forward. Organizations can modify SAML responses to include custom elements for each service provider to monitor and detect any anomalous requests.[8]

Detection Method 4: Detecting malicious ADFS trust modification

A threat actor who gains administrative access to ADFS can add a new, trusted ADFS rather than extracting the certificate and private key as part of a standard Golden SAML attack.[9]
Network defenders should look for:

  1. Event ID 307 (The Federation Service configuration was changed), which can be correlated to relevant Event ID 510 with the same Instance ID for change details. (Event ID 510 with the same Instance ID could be more than one event per single Event ID 307 event.)
    1. Review events, particularly searching for Configuration: Type: IssuanceAuthority where Property Value references an unfamiliar domain.
  2. Possible activity of an interrogating ADFS host by using ADFS PowerShell plugins. Look for changes in the federation trust environment that would indicate new ADFS sources.

Stage 2: Using the forged authentication token to create configuration changes in the Service Provider, such as Azure AD (establishing a foothold)

After the threat actor has compromised the on-premises identity provider, they identify their next series of objectives by reviewing activity in the Microsoft Cloud activity space (Microsoft Azure and M365 tenants).

The threat actor uses the ability to forge authentication tokens to establish a presence in the cloud environment. The actor adds additional credentials to an existing service principal. Once the threat actor has impersonated a privileged Azure AD account, they are likely to further manipulate the Azure/M365 environment (action on objectives in the cloud).

Network defenders should take the following steps.

  1. Audit the creation and use of service principal and application credentials. Sparrow will detect modifications to these credentials.
    1. Look for unusual application usage, such as dormant or forgotten applications being used again.
    2. Audit the assignment of credentials to applications that allow non-interactive sign-in by the application.
  2. Look for unexpected trust relationships that have been added to Azure AD. (Download the last 30 days of non-interactive sign-ins from the Azure portal or use Azure Sentinel.).[10]
  3. Use Hawk (and any sub-modules available) to run an investigation on a specific user. Hawk will provide IP addresses, sign-in data, and other data. Hawk can also track IP usage in concurrent login situations.
  4. Review login details for administrator accounts (e.g., high-value administrative accounts, such as Global Admins). Look for unusual sign-in locations, dates, and times.
  5. Review new token validation time periods with high values and investigate whether the changes are legitimate or a threat actor’s attempts to gain persistence.

Stage 3: Acquiring an OAuth access token for the application using the forged credentials added to an existing application or service principal and calling APIs with the permissions assigned to that application

In some cases, the threat actor has been observed adding permissions to existing applications or service principals. Additionally the actor has been seen establishing new applications or service principals briefly and using them to add permissions to the existing applications or service principals, possibly to add a layer of indirection (e.g., using it to add a credential to another service principal, and then deleting it).[11]

Network defenders should use Sparrow to:

  1. Examine highly privileged accounts; specifically using sign-in logs, look for unusual sign-in locations, dates, and times.
  2. Create a timeline for all credential changes.
  3. Monitor changes in application credentials (the script will export into csv named AppUpdate_Operations_Export).
  4. Detect service principal credentials change and service principal change (e.g., if an actor adds new permissions or expands existing permissions).
    1. Export and view this activity via the ServicePrincipal_Operations_Export.
  5. Record OAuth consent and consent to applications
    1. Export and view this record via the Consent_Operations_Export file.
  6. Investigate instances of excessive high permissions, including, but not limited to Exchange Online, Microsoft Graph, and Azure AD Graph.
    1. Review Microsoft Graph API permissions granted to service principals.
    2. Export and view this activity via the ApplicationGraphPermissions csv file.
      1. Note: Hawk can also return the full list of service principal permissions for further investigation.
    3. Review top actors and the amount of credential modifications performed.
    4. Monitor changes in application credentials.
  7. Identify manipulation of custom or third-party applications.
    1. Network defenders should review the catalog of custom or third-party vendors with applications in the Microsoft tenant and perform the above interrogation principles on those applications and trusts.
  8. Review modifications to federation trust settings.
    1. Review new token validation time periods with high values and investigate whether this was a legitimate change or an attempt to gain persistence by the threat actor.
      1. The script detects the escalation of privileges, including the addition of Service Principals (SP) to privileged roles. Export this data into csv called AppRoleAssignment_Operations_Export.

Stage 4: Once access has been established, the threat actor Uses Microsoft Graph API to conduct action on objectives from an external RESTful API (queries impersonating existing applications).

Network defenders should:

  1. In MailItemsAccessed operations, found within the Unified Audit Log (UAL), review the application ID used (requires G5 or E5 license for this specific detail).
  2. Query the specific application ID, using the Sparrow script’s app ID investigation capability to interrogate mail and file items accessed for that applicationID (Use the application ID utility for any other suspicious apps that require additional analysis.).
  3. Check the permissions of an application in M365/Azure AD using Sparrow.
    1. Hawk will return Azure_Application_Audit, and Sparrow will return ApplicationGraphPermissions.
    2. Network defenders will see the IP address that Graph API uses.
    3. Note: the Microsoft IP address may not show up as a virtual private server/anonymized endpoint.
  4. Investigate a specific service principal, if it is a user-specific user account, in Hawk. This activity is challenging to see without Azure Sentinel or manually downloading and reviewing logs from the sign-in portal.

Microsoft Telemetry Nuances

The existing tools and techniques used to evaluate cloud-based telemetry sources present challenges not represented in traditional forensic techniques. Primarily, the amount of telemetry retention is far less than the traditional logging facilities of on-premises data sources. Threat actor activity that is more than 90 days old is unlikely to have been saved by traditional sources or be visible with the Microsoft M365 Management API or in the UAL.

Service principal logging is available using the Azure Portal via the “Service Principal Sign-ins” feature. Enable settings in the Azure Portal (see “Diagnostic Setting”) to ingest logs into Sentinel or a third-party security information and event management (SIEM) tool. An Azure Premium P1 or Premium P2 license is necessary to access this setting as well as other features, such as a log analytics workspace, storage account, or event hub.[12] These logs must be downloaded manually if not ingested by one of the methods listed in the Detection Methods section.

Global Administrator rights are often required by tools other than Hawk and Sparrow to evaluate M365 cloud security posture. Logging capability and visibility of data varies by licensing models and subscription to premium services, such as Microsoft Defender for O365 and Azure Sentinel. According to CrowdStrike, “There was an inability to audit via API, and there is the requirement for global admin rights to view important information which we found to be excessive. Key information should be easily accessible.”[13]

Documentation for specific event codes, such as UserAuthenticationMethod 16457, which may indicate a suspicious SAML token forgery, is no longer available in the M365 Unified Access Log. Auditing narratives on some events no longer exist as part of core Microsoft documentation sources.

The use of industry-standard SIEMs for log detection is crucial for providing historical context for threat hunting in Microsoft cloud environments. Standard G3/E3 licenses only provide 90 days of auditing; with the advanced auditing license that is provided with a G5/E5 license, audit logs can be extended to retain information for a year. CISA notes that this license change is proactive, rather than reactive: it allows enhanced visibility and features for telemetry from the moment of integration but does not provide retroactive visibility on previous events or historical context.

A properly configured SIEM can provide:

  1. Longer term storage of log data.
  2. Cross correlation of log data with endpoint data and network data (such as those produced by ADFS servers), endpoint detection and response data, and identity provider information.
  3. Ability to query use of application connectors in Azure.

Built-in tools, such as Microsoft Cloud Services and M365 applications, provide much of the same visibility available from custom tools and are mapped to the MITRE ATT&CK framework and easy-to-understand dashboards.[14] However, these tools often do not have the ability to pull historical data older than seven days. Therefore, storage solutions that appropriately meet governance standards and usability metrics for analysts for the SIEM must be carefully planned and arranged.

Contact Information

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/.

Resources

Azure Active Directory Workbook to Assess Solorigate Risk: https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-workbook-to-help-you-assess-solorigate-risk/ba-p/2010718

Volexity – Dark Halo Leverages SolarWinds Compromise to Breach Organizations: https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/

How to Find Activity with Sentinel: https://www.verboon.info/2020/10/monitoring-service-principal-sign-ins-with-azuread-and-azure-sentinel/

Third-Party Walkthrough of the Attack: https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/

National Security Agency Advisory on Detecting Abuse of Authentication Mechanisms: https://media.defense.gov/2020/Dec/17/2002554125/-1/-1/0/AUTHENTICATION_MECHANISMS_CSA_U_OO_198854_20.PDF

Microsoft 365 App for Splunk: https://splunkbase.splunk.com/app/3786/

CISA Remediation Guidance: https://us-cert.cisa.gov/ncas/alerts/aa20-352a

References

Revisions

  • Initial version: January 8, 2021
  • February 4, 2021: Removed link and section for outdated product feedback form

This product is provided subject to this Notification and this Privacy & Use policy.

AA20-352A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations

Posted from CISA Alerts
Read More
Original release date: December 17, 2020 | Last revised: February 8, 2021

Summary

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.

  • Orion Platform 2019.4 HF5, version 2019.4.5200.9083
  • Orion Platform 2020.2 RC1, version 2020.2.100.12219
  • Orion Platform 2020.2 RC2, version 2020.2.5200.12394
  • Orion Platform 2020.2, version 2020.2.5300.12432
  • Orion Platform 2020.2 HF1, version 2020.2.5300.12432

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).

Key Takeaways (updated December 18, 2020)

  • This is a patient, well-resourced, and focused adversary that has sustained long duration activity on victim networks.
  • CISA is investigating other initial access vectors in addition to the SolarWinds Orion supply chain compromise. 
  • Not all organizations that have the backdoor delivered through SolarWinds Orion have been targeted by the adversary with follow-on actions.
  • Organizations with suspected compromises need to be highly conscious of operational security, including when engaging in incident response activities and planning and implementing remediation plans. 

(Updated January 8, 2021) For a downloadable list of indicators of compromise (IOCs), see the STIX file, MAR-10318845-1.v1.stix, and MAR-10320115-1.v1.stix.

Technical Details

Overview

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.

Initial Infection Vectors [TA0001]

(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 Supply Chain Compromise [T1195.002]

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.

Anti-Forensic Techniques

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.

Privilege Escalation and Persistence [TA0004, TA0003]

(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]

User Impersonation

(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.

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

(New January 6, 2021): Detection: Identifying Compromised Azure/M365 Resources

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.

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.

  • (Updated January 6, 2021): Most organizations have SAML tokens with 1-hour validity periods. Long SAML token validity durations, such as 24 hours, could be unusual. Exact values (measured in precise seconds) is also considered 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.
  • (New January 6, 2021): Tokens with missing or unusual MFA details, when MFA is enforced, is considered an anoamaoly and should be investigated. This requires correlation of identity provider (iDP) logs with cloud access; differences in claims indicate maninpulated values. All claims should have a corresponding iDP entry.

(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.

Operational Security

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:

  • Out-of-band communications guidance for staff and leadership;
  • An outline of what “normal business” is acceptable to be conducted on the suspect network;
  • A call tree for critical contacts and decision making; and
  • Considerations for external communications to stakeholders and media.

MITRE ATT&CK® Techniques

CISA assesses that the threat actor engaged in the activities described in this Alert uses the below-listed ATT&CK techniques.

  • Query Registry [T1012]
  • Obfuscated Files or Information [T1027]
  • Obfuscated Files or Information: Steganography [T1027.003]
  • Process Discovery [T1057]
  • Indicator Removal on Host: File Deletion [T1070.004]
  • Application Layer Protocol: Web Protocols [T1071.001]
  • Application Layer Protocol: DNS [T1071.004]
  • File and Directory Discovery [T1083]
  • Ingress Tool Transfer [T1105]
  • Data Encoding: Standard Encoding [T1132.001]
  • Supply Chain Compromise: Compromise Software Dependencies and Development Tools [T1195.001]
  • Supply Chain Compromise: Compromise Software Supply Chain [T1195.002]
  • Software Discovery [T1518]
  • Software Discovery: Security Software [T1518.001]
  • Create or Modify System Process: Windows Service [T1543.003]
  • Subvert Trust Controls: Code Signing [T1553.002]
  • Dynamic Resolution: Domain Generation Algorithms [T1568.002]
  • System Services: Service Execution [T1569.002]
  • Compromise Infrastructure [T1584]

Mitigations

(Updated January 6, 2021) SolarWinds Orion Owners

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.)

  • Category 1 includes those who do not have the identified malicious binary code on their network and can forensically confirm that the binary was never present on their systems. This includes networks that do not, and never did, utilize the affected versions of SolarWinds Orion products (see Appendix A).
  • Category 2 includes networks where the presence of the malicious binary has been identified—with or without beaconing to 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:
     

    1. Had no beaconing, or
    2. Only beaconed to 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.
       
  • Category 2 organizations, after conducting appropriate forensic analysis to ensure they only have category 2 activity, can rebuild the platform, harden the configuration based on SolarWinds secure configuration guidelines, and resume use as determined by and consistent with their thorough risk evaluation. For entities not subject to ED 21-01, this can be accomplished by following the steps below. Federal agencies subject to ED 21-01 must follow the appropriate steps as outlined in the effective ED 21-01 supplemental guidance.
     

    1. Denying all incoming and outgoing (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.
    2. Cloud instances of Orion should only monitor cloud resources in that cloud infrastructure.
    3. On-premises instances of Orion should not be permissioned with any cloud/hosted identity accounts.
    4. Restoration of SolarWinds may be done from the legacy database following the SolarWinds restore guidance (http://solarwinds.com/upgrading-your-environment). Restoration for affected versions will differ from restoration for unaffected versions—agencies must ensure that they are following the correct restoration guidance.
    5. Before building SolarWinds:
      1. All account credentials, or other shared secrets (e.g., Simple Network Management Protocol [SNMP] strings) that are or had been utilized by the affected SolarWinds Orion device being rebuilt should be changed.
      2. Enable MFA for these credentials, whenever possible.
      3. Provide service accounts with the minimum privilege necessary for the role performed, whenever possible.
      4. For accounts where MFA is not possible  (e.g., service accounts), use randomly generated long and complex passwords (greater than 25 characters) and implement a maximum 90-day rotation policy for these passwords.
      5. Remove all inbound trust relationships to the SolarWinds Orion device being rebuilt.
    6. Re-building a SolarWinds Orion Platform to at least version 2020.2.1 HF2 and updating the host to the latest supported build, at least Windows 2016.
    7. Following the SolarWinds secure configuration (hardening) guidelines provided by the vendor, which can be found at: https://documentation.solarwinds.com/en/Success_Center/orionplatform/content/core-secure-configuration.htm. CISA does not recommend configuring the SolarWinds software to implement SAML-based authentication that relies on Microsoft’s Active Directory Federated Services if it has not already been configured to leverage SAML. This configuration is currently being exploited by the threat actor with this activity.
    8. Configuring logging to ensure that all logs on the host operating system and SolarWinds platform are being captured and stored for at least 180 days.
    9. Configure logging to ensure that all logs from the host OS, SolarWinds platform, and associated network logs are being captured and stored for at least 180 days in a separate, centralized log aggregation capability.
    10. Implementing subsequent SolarWinds Orion Platform updates. CISA recommends installing all updates within 48 hours of release. 
       
  • Category 3 includes those networks that used affected versions of SolarWinds Orion and have evidence of follow-on threat actor activity, such as binary beaconing to 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:

  1. Take actions to remediate kerberoasting, including, as necessary or appropriate, engaging with a 3rd party with experience eradicating APTs from enterprise networks. For Windows environments, refer to the following:
    1. See Microsoft’s documentation on kerberoasting: https://techcommunity.microsoft.com/t5/microsoft-security-and/detecting-ldap-based-kerberoasting-with-azure-atp/ba-p/462448.
    2. Change all account credentials, or other shared secrets (e.g., SNMP strings) that were potentially exposed:
      1. Enable MFA for these credentials, whenever possible;
      2. Provide service accounts with the minimum level of privilege necessary for the role performed, whenever possible; and
      3. For accounts where MFA is not possible, require use of randomly generated long and complex passwords (greater than 25 characters) and implement a maximum 90-day rotation policy for these passwords.
    3. Replace the user accounts with a Group Managed Service Account (gMSA). See https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview, and Implement Group Managed Service Accounts: https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview.
    4. Set account options for service accounts to support AES256_CTS_HMAC_SHA1_96 and not support DES, RC4, or AES128 bit encryption
    5. Define the Security Policy setting, for Network Security: Configure Encryption types allowed for Kerberos. Set the allowable encryption types to AES256_HMAC_SHA1 and Future encryption types. https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos
    6. See Microsoft’s documentation on how to reset the Kerberos Ticket Granting Ticket password, twice: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-forest-recovery-resetting-the-krbtgt-password.

SolarWinds Orion Specific Mitigations

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.

  • Step 1
    • Forensically image system memory and/or host operating systems hosting all instances of affected versions of SolarWinds Orion. Analyze for new user or service accounts, privileged or otherwise.
    • Analyze stored network traffic for indications of compromise, including new external DNS domains to which a small number of agency hosts (e.g., SolarWinds systems) have had connections.
  • Step 2
    • Affected organizations should immediately disconnect or power down affected all instances of affected versions of SolarWinds Orion from their network.
    • Additionally:
      • Block all traffic to and from hosts, external to the enterprise, where any version of SolarWinds Orion software has been installed.
      • Identify and remove all threat actor-controlled accounts and identified persistence mechanisms.  
  • Step 3  
    • Only after all known threat actor-controlled accounts and persistence mechanisms have been removed:
      • Treat all hosts monitored by the SolarWinds Orion monitoring software as compromised by threat actors and assume that the threat actor has deployed further persistence mechanisms.
      • Rebuild hosts monitored by the SolarWinds Orion monitoring software using trusted sources.
      • Reset all credentials used by or stored in SolarWinds software. Such credentials should be considered compromised.
  • (New December 19, 2020) For all network devices (routers, switches, firewalls, etc.) managed by affected SolarWinds servers that also have indications of additional adversary activity, CISA recommends the following steps:
    • Device configurations
      • Audit all network device configurations, stored or managed on the SolarWinds monitoring server, for signs of unauthorized or malicious configuration changes.
      • Audit the configurations found on network devices for signs of unauthorized or malicious configuration changes. Organizations should ensure they audit the current network device running configuration and any local configurations that could be loaded at boot time.
    • Credential and security information reset
      • Change all credentials being used to manage network devices, to include keys and strings used to secure network device functions (SNMP strings/user credentials, IPsec/IKE preshared keys, routing secrets, TACACS/RADIUS secrets, RSA keys/certificates, etc.).
    • Firmware and software validation
      • Validate all network device firmware/software which was stored or managed on the SolarWinds monitoring server. Cryptographic hash verification should be performed on such firmware/software and matched against known good hash values from the network vendor. CISA recommends that, if possible, organizations download known good versions of firmware.
  • For network devices managed by the SolarWinds monitoring server, the running firmware/software should be checked against known good hash values from the network vendor. CISA recommends that, if possible, organizations re-upload known good firmware/software to managed network devices and perform a reboot.

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.

Contact Information

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/.

Appendix A: Affected SolarWinds Orion Products

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

 

Appendix B: Indicators of Compromise

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

 IOC 

 Type   Notes  References   Source 
32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77  hash  Backdoor.Sunburst 

https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/ 

 
a25cadd48d70f6ea0c4a241d99c5241269e6faccb4054e62d16784640f8e53bc hash Backdoor.Sunburst https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-   attacks/  
d3c6785e18fba3749fb785bc313cf8346182f532c59172b69adfb31b96a5d0af hash Backdoor.Sunburst https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber- attacks/  
13.59.205[.]66 IPv4 DEFTSECURITY[.]com https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
deftsecurity[.]com domain Domain malicious on VT, registered with  Amazon, hosted on US IP address 13.59.205.66, malware repository, spyware and malware

https://www.virustotal.com/gui/domain/deftsecurity.com/details

https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/

Volexity
54.193.127[.]66 IPv4 FREESCANONLINE[.]com  https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/  
ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c hash No info available https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/  
c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77 hash No info available https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/  
dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b hash No info available https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/  
eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed hash No info available https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/  
avsvmcloud[.]com domain Reported by FireEye/ The malicious DLL calls out to a remote network infrastructure using the domains avsvmcloud[.]com. to prepare possible second-stage payloads, move laterally in the organization, and compromise or exfiltrate data. Malicious on VT. Hosted on IP address 20.140.0.1, which is registered with Microsoft.  malware callhome, command and control https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/

https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/

FireEye Report Talos

Volexity

3.87.182[.]149 IPv4 Resolves to KUBECLOUD[.]com, IP registered to Amazon. Tracked by Insikt/RF as tied to SUNBURST intrusion activity. https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
3.16.81[.]254 IPv4 Resolves to SEOBUNDLEKIT[.]com, registered to Amazon. Tracked by Insikt/RF as tied SUNBURST intrusion activity. https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
54.215.192[.]52 IPv4 THEDOCCLOUD[.]com https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134  hash Trojan.MSIL.SunBurst ttps://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber- attacks/  
ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6 hash Trojan.MSIL.SunBurst https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber- attacks/  
8.18.144[.]11 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]12 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]9 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]20 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]40 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/  Volexity
8.18.144[.]44 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]62 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]130 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]135 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]136 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]149 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]156 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]158 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]165 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]170 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]180 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]188 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]3 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]21 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]33 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]36 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]131 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]134 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]136 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]139 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]150 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]157 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]181 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
13.57.184[.]217 IPv4 (corrected typo in this IOC December 18, 2020) https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
18.217.225[.]111 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
18.220.219[.]143 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
20.141.48[.]154 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
34.219.234[.]134 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.1[.]3 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.21[.]54 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.48[.]22 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/  Volexity
184.72.101[.]22 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.113[.]55 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.145[.]34 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.209[.]33 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.212[.]52 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.224[.]3 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.229[.]1 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.240[.]3 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.245[.]1 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
196.203.11[.]89 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/  Volexity
digitalcollege[.]org domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
freescanonline[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
globalnetworkissues[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
kubecloud[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
lcomputers[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
seobundlekit[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
solartrackingsystem[.]net domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
thedoccloud[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/  Volexity
virtualwebdata[.]com domain    https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
webcodez[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600 hash   https://blog.malwarebytes.com/threat-analysis/2020/12/advanced-cyber-attack-hits-private-and-public  
c15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71 hash   https://blog.malwarebytes.com/threat-analysis/2020/12/advanced-cyber-attack-hits-private-and-public  
ervsystem[.]com domain

New January 6, 2021

Resolves to 198.12.75[.]112

 

https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/sunburst-supply-chain-attack-solarwinds Symantec
infinitysoftwares[.]com domain

New January 6, 2021

Updated January 7, 2021: corrected typo in this IOC; updated source

https://otx.alienvault.com/pulse/5fdce61ef056eff2ce0a90de  
mobilnweb[.]com domain

New January 6, 2021

Updated January 7, 2021: updated source

  CISA
02AF7CEC58B9A5DA1C542B5A32151BA1 Hash

New January 6, 2021

Sunburst Installer

File Name(s): CORE-2019.4.5220.20574-SolarWinds-Core-v2019.4.5220-Hotfix5.msp

 

  Symantec  Sunburst: Supply Chain Attack Targets Solar Winds Users
0548eedb3d1f45f1f9549e09d00683f3a1292ec5 Hash

New January 6, 2021

SSL hash for 198.12.75[.]112

 

   
0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589 Hash New January 6, 2021   CISA
1817a5bf9c01035bcf8a975c9f1d94b0ce7f6a200339485d8f93859f8f6d730c Hash

New January 6, 2021

Sunburst Backdoor

https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/sunburst-supply-chain-attack-solarwinds Symantec
1b476f58ca366b54f34d714ffce3fd73cc30db1a Hash

New January 6, 2021

Sunburst Installer
File Name(s):

CORE-2019.4.5220.20574-SolarWinds-Core-v2019.4.5220-Hotfix5.msp

  Symantec  Sunburst: Supply Chain Attack Targets Solar Winds Users
20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9 Hash New January 6, 2021   CISA
2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d Hash New January 6, 2021 https://otx.alienvault.com/pulse/5fd6df943558e0b56eaf3da8 CISA
2dafddbfb0981c5aa31f27a298b9c804e553c7bc Hash New January 6, 2021    
6e4050c6a2d2e5e49606d96dd2922da480f2e0c70082cc7e54449a7dc0d20f8d Hash New January 6, 2021   CrowdStrike
92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690 Hash New January 6, 2021   CISA
a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d Hash New January 6, 2021   CISA
a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2 Hash New January 6, 2021   CISA
b820e8a2057112d0ed73bd7995201dbed79a79e13c79d4bdad81a22f12387e07 Hash

New January 6, 2021

Sunburst Backdoor

https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/sunburst-supply-chain-attack-solarwinds Symantec
b8a05cc492f70ffa4adcd446b693d5aa2b71dc4fa2bf5022bf60d7b13884f666 Hash New January 6, 2021

https://otx.alienvault.com/pulse/5fd6df943558e0b56eaf3da8

 
cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6 Hash New January 6, 2021   CISA
e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d Hash New January 6, 2021   CISA
e70b6be294082188cbe0089dd44dbb86e365f6a2 Hash

New January 6, 2021

SSL hash for 107.152.35[.]77

   
fd15760abfc0b2537b89adc65b1ff3f072e7e31c Hash New January 6, 2021 https://otx.alienvault.com/pulse/5fd6df943558e0b56eaf3da8  
ffdbdd460420972fd2926a7f460c198523480bc6279dd6cca177230db18748e8 Hash New January 6, 2021

https://otx.alienvault.com/pulse/5fd6df943558e0b56eaf3da8

 

 
107.152.35[.]77 IPv4

New January 6, 2021

Resolves to infinitysoftwares[.]com

   
13.59.205[.]66 IPv4 New January 6, 2021 https://otx.alienvault.com/pulse/5fd825b7fa4eb2223a0cf812  
173.237.190[.]2 IPv4 New January 6, 2021   CISA
198.12.75[.]112 IPv4 New January 6, 2021

Resolves to ervsystem[.]com

Updated January 7, 2021: Corrected typo in resolves to domain

  Symantec  Sunburst: Supply Chain Attack Targets Solar Winds Users
20.141.48[.]154 IPv4

New January 6, 2021

Updated January 7, 2021: updated reference and source

https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
34.203.203[.]23 IPv4

New January 7, 2021

  CISA

References

Revisions

  • Initial version: December 17, 2020
  • December 18, 2020: Updated note regarding initial vectors and key takeaways.
  • December 19, 2020: Updated mitigation guidance, indicators of compromise table, and provided a downloadable STIX file of the IOCs.
  • December 21, 2020: Added reference to NSA Cybersecurity Advisory: Detecting Abuse of Authentication Methods
  • December 23, 2020: Added link to CISA.gov/supply-chain-compromise
  • January 06, 2021: Updated Initial Access Vectors, Mitigations, and IOCs
  • January 07, 2021: Updated IOCs
  • Febraury 08, 2021: Updated IOCs

This product is provided subject to this Notification and this Privacy & Use policy.

AA21-008A: Detecting Post-Compromise Threat Activity in Microsoft Cloud Environments

Original release date: January 8, 2021 | Last revised: February 4, 2021

Summary

This Advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques.

This Alert is a companion alert to AA20-352A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations. AA20-352A primarily focuses on an advanced persistent threat (APT) actor’s compromise of SolarWinds Orion products as an initial access vector into networks of U.S. Government agencies, critical infrastructure entities, and private network organizations. As noted in AA20-352A, the Cybersecurity and Infrastructure Security Agency (CISA) has evidence of initial access vectors in addition to the compromised SolarWinds Orion products.

This Alert also addresses activity—irrespective of the initial access vector leveraged—that CISA attributes to an APT actor. Specifically, CISA has seen an APT actor using compromised applications in a victim’s Microsoft 365 (M365)/Azure environment. CISA has also seen this APT actor utilizing additional credentials and Application Programming Interface (API) access to cloud resources of private and public sector organizations. These tactics, techniques, and procedures (TTPs) feature three key components:

  • Compromising or bypassing federated identity solutions;
  • Using forged authentication tokens to move laterally to Microsoft cloud environments; and
  • Using privileged access to a victim’s cloud environment to establish difficult-to-detect persistence mechanisms for Application Programming Interface (API)-based access.

This Alert describes these TTPs and offers an overview of, and guidance on, available open-source tools—including a CISA-developed tool, Sparrow—for network defenders to analyze their Microsoft Azure Active Directory (AD), Office 365 (O365), and M365 environments to detect potentially malicious activity.

Note: this Alert describes artifacts—presented by these attacks—from which CISA has identified detectable evidence of the threat actor’s initial objectives. CISA continues to analyze the threat actor’s follow-on objectives.

Technical Details

Frequently, CISA has observed the APT actor gaining Initial Access [TA0001] to victims’ enterprise networks via compromised SolarWinds Orion products (e.g., Solorigate, Sunburst).[1] However, CISA is investigating instances in which the threat actor may have obtained initial access by Password Guessing [T1110.001], Password Spraying [T1110.003], and/or exploiting inappropriately secured administrative or service credentials (Unsecured Credentials [T1552]) instead of utilizing the compromised SolarWinds Orion products.

CISA observed this threat actor moving from user context to administrator rights for Privilege Escalation [TA0004] within a compromised network and using native Windows tools and techniques, such as Windows Management Instrumentation (WMI), to enumerate the Microsoft Active Directory Federated Services (ADFS) certificate-signing capability. This enumeration allows threat actors to forge authentication tokens (OAuth) to issue claims to service providers—without having those claims checked against the identity provider—and then to move laterally to Microsoft Cloud environments (Lateral Movement [TA0008]).

The threat actor has also used on-premises access to manipulate and bypass identity controls and multi-factor authentication. This activity demonstrates how sophisticated adversaries can use credentials from one portion of an organization to move laterally (Lateral Movement [TA0008]) through trust boundaries, evade defenses and detection (Defense Evasion [TA0005]), and steal sensitive data (Collection [TA0009]).

This level of compromise is challenging to remediate and requires a rigorous multi-disciplinary effort to regain administrative control before recovering.

Mitigations

Detection

Guidance on identifying affected SolarWinds software is well documented.[2] However—once an organization identifies a compromise via SolarWinds Orion products or other threat actor TTPs—identifying follow-on activity for on-premises networks requires fine-tuned network and host-based forensics.

The nature of cloud forensics is unique due to the growing and rapidly evolving technology footprints of major vendors. Microsoft’s O365 and M365 environments have built-in capabilities for detecting unusual activity. Microsoft also provides premium services (Advanced Threat Protection [ATP] and Azure Sentinel), which enable network defenders to investigate TTPs specific to the Solorigate activity.[3]

Detection Tools

CISA is providing examples of detection tools for informational purposes only. CISA does not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services does not constitute or imply their endorsement, recommendation, or favoring by CISA.

There are a number of open-source tools available to investigate adversary activity in Microsoft cloud environments and to detect unusual activity, service principals, and application activity.[4] Publicly available PowerShell tools that network defenders can use to investigate M365 and Microsoft Azure include:

  • CISA’s Sparrow,
  • Open-source utility Hawk, and
  • CrowdStrike’s Azure Reporting Tool (CRT).

Additionally, Microsoft’s Office 365 Management API and Graph API provide an open interface for ingesting telemetry and evaluating service configurations for signs of anomalous activity and intrusion.

Note: these open-source tools are highlighted and explained to assist with on-site investigation and remediation in cloud environments but are not all-encompassing. Open source tools can be complemented by services such as Azure Sentinel, a Microsoft premium service that provides comprehensive analysis tools, including custom detections for the activity indicated.

General Guidance on Using Detection Tools

  1. Audit the creation and use of service principal credentials. Look for unusual application usage, such as use of dormant applications.
  2. Audit the assignment of credentials to applications that allow non-interactive sign-in by the application. Look for unexpected trust relationships added to the Azure Active Directory.
  3. Download the interactive sign-ins from the Azure admin portal or use the Microsoft Sentinel product. Review new token validation time periods with high values and investigate whether it was a legitimate change or an attempt to gain persistence by a threat actor.

Sparrow

CISA created Sparrow to help network defenders detect possible compromised accounts and applications in the Azure/M365 environment. The tool 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. It is intended to narrow a larger set of available investigation modules and telemetry to those specific to recent attacks on federated identity sources and applications.

CISA advises Sparrow users to take the following actions.

  1. Use Sparrow to detect any recent domain authentication or federation modifications.
    1. Domain and federation modification operations are uncommon and should be investigated.
  2. Examine logs for new and modified credentials applied to applications and service principals; delineate for the credential type. Sparrow can be used to detect the modification of service principals and application credentials.
    1. Create a timeline for all credential changes, focusing on recent wholesale changes.
    2. Review the “top actors” for activity in the environment and the number of credential modifications performed.
    3. Monitor changes in application and service principal credentials.
    4. Investigate any instances of excessive permissions being granted, including, but not limited to, Exchange Online, Microsoft Graph, and Azure AD Graph.
  3. Use Sparrow to detect privilege escalation, such as adding a service principal, user, or group to a privileged role.
  4. Use Sparrow to detect OAuth consent and users’ consent to applications, which is useful for interpreting changes in adversary TTPs.
  5. Use Sparrow to identify anomalous Security Assertion Markup Language (SAML) token sign-ins by pivoting on the unified audit log UserAuthenticationValue of 16457, which is an indicator of how a SAML token was built and is a potential indicator for forged SAML tokens.
    1. Note that this TTP has not been the subject of significant published security research but may indicate an unusual usage of a token, such as guest access for external partners to M365 resources.
  6. Review the PowerShell logs that Sparrow exports.
    1. Review PowerShell mailbox sign-ins and validate that the logins are legitimate actions.
    2. Review PowerShell usage for users with PowerShell in the environment.
  7. Use Sparrow to check the Graph API application permissions of all service principals and applications in M365/Azure AD.
    1. Investigate unusual activity regarding Microsoft Graph API permissions (using either the legacy https://graph.windows.net/ or https://graph.microsoft.com). Graph is used frequently as part of these TTPs, often to access and manipulate mailbox resources.
  8. Review Sparrow’s listed tenant’s Azure AD domains, to see if the domains have been modified.
  9. For customers with G5 or E5 licensing levels, review MailItemsAccessed for insight into what application identification (ID) was used for accessing users’ mailboxes. Use Sparrow to query for a specific application ID using the app id investigation capability, which will check to see if it is accessing mail or file items.
    1. The MailItemsAccessed event provides audibility for mailbox data accessed via mail protocols or clients.
    2. By analyzing the MailItemsAccessed action, incident responders can determine which user mailbox items have been accessed and potentially exfiltrated by a threat actor. This event will be recorded even in some situations where the message was not necessarily read interactively (e.g., bind or sync).[5]
    3. The resulting suspicious application ID can provide incident responders with a pivot to detect other suspicious applications that require additional analysis.
    4. Check for changes to applications with regards to the accessing of resources such as mail or file items.

Hawk

Hawk is an open-source, PowerShell-driven, community-developed tool network defenders can use to quickly and easily gather data from O365 and Azure for security investigations. Incident responders and network defenders can investigate specific user principals or the entire tenant. Data it provides include IP addresses and sign-in data. Additionally, Hawk can track IP usage for concurrent login situations.

Hawk users should review login details for administrator accounts and take the following steps.

  1.  Investigate high-value administrative accounts to detect anomalous or unusual activity (Global Admins).
  2. Enable PowerShell logging, and evaluate PowerShell activity in the environment not used for traditional or expected purposes.
    1. PowerShell logging does not reveal the exact cmdlet that was run on the tenant.
  3. Look for users with unusual sign-in locations, dates, and times.
  4. Check permissions of service principals and applications in M365/Azure AD.
  5. Detect the frequency of resource access from unusual places. Use the tool to pivot to a trusted application and see if it is accessing mail or file items.
  6. Review mailbox rules and recent mailbox rule changes.

CrowdStrike Azure Reporting Tool

CrowdStrike’s Azure Reporting Tool (CRT) can help network defenders analyze their Microsoft Azure AD and M365 environment to help organizations analyze permissions in their Azure AD tenant and service configuration. This tool has minor overlap with Sparrow; it shows unique items, but it does not cover the same areas. CISA is highlighting this tool because it is one of the only free, open-source tools available to investigate this activity and could be used to complement Sparrow.

Detection Tool Distinctions

  • Sparrow differs from CRT by looking for specific indicators of compromise associated with the recent attacks.
  • CRT focuses on the tenant’s Azure AD permissions and Exchange Online configuration settings instead of the unified audit log, which gives it a different output from Sparrow or Hawk.
  • CRT returns the same broad scope of application/delegated permissions for service principals and applications as Hawk.
  • As part of its investigation, Sparrow homes in on a narrow set of application permissions given to the Graph API, which is common to the recent attacks.
  • CRT looks at Exchange Online federation configuration and federation trust, while Sparrow focuses on listing Azure AD domains.
  • Among the items network defenders can use CRT to review are delegated permissions and application permissions, federation configurations, federation trusts, mail forwarding rules, service principals, and objects with KeyCredentials.

Detection Methods

Microsoft breaks the threat actor’s recent activity into four primary stages, which are described below along with associated detection methods. Microsoft describes these stages as beginning with all activity after the compromise of the on-premises identity solution, such as ADFS.[6]

Note: this step provides an entry vector to cloud technology environments, and is unnecessary when the threat actor has compromised an identity solution or credential that allows the APT direct access to the cloud(e.g., without leveraging the SolarWinds Orion vulnerability).

Stage 1: Forging a trusted authentication token used to access resources that trust the on-premises identity provider

These attacks (often referred to as “Golden Security Assertion Markup Language” attacks) can be analyzed using a combination of cloud-based and standard on-premises techniques.[7] For example, network defenders can use OAuth claims for specific principals made at the Azure AD level and compare them to the on-premises identity.

Export sign-in logs from the Azure AD portal and look at the Authentication Method field.

Note: at portal.azure.com, click on a user and review the authentication details (e.g., date, method, result). Without Sentinel, this is the only way to get these logs, which are critical for this effort.

Detection Method 1: Correlating service provider login events with corresponding authentication events in Active Directory Federation Services (ADFS) and Domain Controllers

Using SAML single sign-on, search for any logins to service providers that do not have corresponding event IDs 4769, 1200, and 1202 in the domain.

Detection Method 2: Identifying certificate export events in ADFS

Look for:

  1. The IP address and Activity_ID in EventCode 410 and the Activity_ID and Instance_ID in EventCode 500.
  2. Export-PfxCertificate or certutil-exportPFX in Event IDs 4103 and 4104, which may include detection of a certificate extraction technique.
  3. Deleted certificate extraction with ADFSdump performed using Sysmon Event ID 18 with the pipe name microsoft##widtsqlquery (exclude processes regularly making this pipe connection on the machine).
  4. Event ID 307 (The Federation Service configuration was changed), which can be correlated to relevant Event ID 510 with the same instance ID for change details (Event ID 510 with the same Instance ID could be more than one event per single Event ID 307 event).

Detection Method 3: Customizing SAML response to identify irregular access

This method serves as prevention for the future (and would only detect future, not past, activity), as it helps identify irregularities from the point of the change forward. Organizations can modify SAML responses to include custom elements for each service provider to monitor and detect any anomalous requests.[8]

Detection Method 4: Detecting malicious ADFS trust modification

A threat actor who gains administrative access to ADFS can add a new, trusted ADFS rather than extracting the certificate and private key as part of a standard Golden SAML attack.[9]
Network defenders should look for:

  1. Event ID 307 (The Federation Service configuration was changed), which can be correlated to relevant Event ID 510 with the same Instance ID for change details. (Event ID 510 with the same Instance ID could be more than one event per single Event ID 307 event.)
    1. Review events, particularly searching for Configuration: Type: IssuanceAuthority where Property Value references an unfamiliar domain.
  2. Possible activity of an interrogating ADFS host by using ADFS PowerShell plugins. Look for changes in the federation trust environment that would indicate new ADFS sources.

Stage 2: Using the forged authentication token to create configuration changes in the Service Provider, such as Azure AD (establishing a foothold)

After the threat actor has compromised the on-premises identity provider, they identify their next series of objectives by reviewing activity in the Microsoft Cloud activity space (Microsoft Azure and M365 tenants).

The threat actor uses the ability to forge authentication tokens to establish a presence in the cloud environment. The actor adds additional credentials to an existing service principal. Once the threat actor has impersonated a privileged Azure AD account, they are likely to further manipulate the Azure/M365 environment (action on objectives in the cloud).

Network defenders should take the following steps.

  1. Audit the creation and use of service principal and application credentials. Sparrow will detect modifications to these credentials.
    1. Look for unusual application usage, such as dormant or forgotten applications being used again.
    2. Audit the assignment of credentials to applications that allow non-interactive sign-in by the application.
  2. Look for unexpected trust relationships that have been added to Azure AD. (Download the last 30 days of non-interactive sign-ins from the Azure portal or use Azure Sentinel.).[10]
  3. Use Hawk (and any sub-modules available) to run an investigation on a specific user. Hawk will provide IP addresses, sign-in data, and other data. Hawk can also track IP usage in concurrent login situations.
  4. Review login details for administrator accounts (e.g., high-value administrative accounts, such as Global Admins). Look for unusual sign-in locations, dates, and times.
  5. Review new token validation time periods with high values and investigate whether the changes are legitimate or a threat actor’s attempts to gain persistence.

Stage 3: Acquiring an OAuth access token for the application using the forged credentials added to an existing application or service principal and calling APIs with the permissions assigned to that application

In some cases, the threat actor has been observed adding permissions to existing applications or service principals. Additionally the actor has been seen establishing new applications or service principals briefly and using them to add permissions to the existing applications or service principals, possibly to add a layer of indirection (e.g., using it to add a credential to another service principal, and then deleting it).[11]

Network defenders should use Sparrow to:

  1. Examine highly privileged accounts; specifically using sign-in logs, look for unusual sign-in locations, dates, and times.
  2. Create a timeline for all credential changes.
  3. Monitor changes in application credentials (the script will export into csv named AppUpdate_Operations_Export).
  4. Detect service principal credentials change and service principal change (e.g., if an actor adds new permissions or expands existing permissions).
    1. Export and view this activity via the ServicePrincipal_Operations_Export.
  5. Record OAuth consent and consent to applications
    1. Export and view this record via the Consent_Operations_Export file.
  6. Investigate instances of excessive high permissions, including, but not limited to Exchange Online, Microsoft Graph, and Azure AD Graph.
    1. Review Microsoft Graph API permissions granted to service principals.
    2. Export and view this activity via the ApplicationGraphPermissions csv file.
      1. Note: Hawk can also return the full list of service principal permissions for further investigation.
    3. Review top actors and the amount of credential modifications performed.
    4. Monitor changes in application credentials.
  7. Identify manipulation of custom or third-party applications.
    1. Network defenders should review the catalog of custom or third-party vendors with applications in the Microsoft tenant and perform the above interrogation principles on those applications and trusts.
  8. Review modifications to federation trust settings.
    1. Review new token validation time periods with high values and investigate whether this was a legitimate change or an attempt to gain persistence by the threat actor.
      1. The script detects the escalation of privileges, including the addition of Service Principals (SP) to privileged roles. Export this data into csv called AppRoleAssignment_Operations_Export.

Stage 4: Once access has been established, the threat actor Uses Microsoft Graph API to conduct action on objectives from an external RESTful API (queries impersonating existing applications).

Network defenders should:

  1. In MailItemsAccessed operations, found within the Unified Audit Log (UAL), review the application ID used (requires G5 or E5 license for this specific detail).
  2. Query the specific application ID, using the Sparrow script’s app ID investigation capability to interrogate mail and file items accessed for that applicationID (Use the application ID utility for any other suspicious apps that require additional analysis.).
  3. Check the permissions of an application in M365/Azure AD using Sparrow.
    1. Hawk will return Azure_Application_Audit, and Sparrow will return ApplicationGraphPermissions.
    2. Network defenders will see the IP address that Graph API uses.
    3. Note: the Microsoft IP address may not show up as a virtual private server/anonymized endpoint.
  4. Investigate a specific service principal, if it is a user-specific user account, in Hawk. This activity is challenging to see without Azure Sentinel or manually downloading and reviewing logs from the sign-in portal.

Microsoft Telemetry Nuances

The existing tools and techniques used to evaluate cloud-based telemetry sources present challenges not represented in traditional forensic techniques. Primarily, the amount of telemetry retention is far less than the traditional logging facilities of on-premises data sources. Threat actor activity that is more than 90 days old is unlikely to have been saved by traditional sources or be visible with the Microsoft M365 Management API or in the UAL.

Service principal logging is available using the Azure Portal via the “Service Principal Sign-ins” feature. Enable settings in the Azure Portal (see “Diagnostic Setting”) to ingest logs into Sentinel or a third-party security information and event management (SIEM) tool. An Azure Premium P1 or Premium P2 license is necessary to access this setting as well as other features, such as a log analytics workspace, storage account, or event hub.[12] These logs must be downloaded manually if not ingested by one of the methods listed in the Detection Methods section.

Global Administrator rights are often required by tools other than Hawk and Sparrow to evaluate M365 cloud security posture. Logging capability and visibility of data varies by licensing models and subscription to premium services, such as Microsoft Defender for O365 and Azure Sentinel. According to CrowdStrike, “There was an inability to audit via API, and there is the requirement for global admin rights to view important information which we found to be excessive. Key information should be easily accessible.”[13]

Documentation for specific event codes, such as UserAuthenticationMethod 16457, which may indicate a suspicious SAML token forgery, is no longer available in the M365 Unified Access Log. Auditing narratives on some events no longer exist as part of core Microsoft documentation sources.

The use of industry-standard SIEMs for log detection is crucial for providing historical context for threat hunting in Microsoft cloud environments. Standard G3/E3 licenses only provide 90 days of auditing; with the advanced auditing license that is provided with a G5/E5 license, audit logs can be extended to retain information for a year. CISA notes that this license change is proactive, rather than reactive: it allows enhanced visibility and features for telemetry from the moment of integration but does not provide retroactive visibility on previous events or historical context.

A properly configured SIEM can provide:

  1. Longer term storage of log data.
  2. Cross correlation of log data with endpoint data and network data (such as those produced by ADFS servers), endpoint detection and response data, and identity provider information.
  3. Ability to query use of application connectors in Azure.

Built-in tools, such as Microsoft Cloud Services and M365 applications, provide much of the same visibility available from custom tools and are mapped to the MITRE ATT&CK framework and easy-to-understand dashboards.[14] However, these tools often do not have the ability to pull historical data older than seven days. Therefore, storage solutions that appropriately meet governance standards and usability metrics for analysts for the SIEM must be carefully planned and arranged.

Contact Information

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/.

Resources

Azure Active Directory Workbook to Assess Solorigate Risk: https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-workbook-to-help-you-assess-solorigate-risk/ba-p/2010718

Volexity – Dark Halo Leverages SolarWinds Compromise to Breach Organizations: https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/

How to Find Activity with Sentinel: https://www.verboon.info/2020/10/monitoring-service-principal-sign-ins-with-azuread-and-azure-sentinel/

Third-Party Walkthrough of the Attack: https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/

National Security Agency Advisory on Detecting Abuse of Authentication Mechanisms: https://media.defense.gov/2020/Dec/17/2002554125/-1/-1/0/AUTHENTICATION_MECHANISMS_CSA_U_OO_198854_20.PDF

Microsoft 365 App for Splunk: https://splunkbase.splunk.com/app/3786/

CISA Remediation Guidance: https://us-cert.cisa.gov/ncas/alerts/aa20-352a

References

Revisions

  • Initial version: January 8, 2021
  • February 4, 2021: Removed link and section for outdated product feedback form

This product is provided subject to this Notification and this Privacy & Use policy.

AA20-352A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations

Original release date: December 17, 2020 | Last revised: February 8, 2021

Summary

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.

  • Orion Platform 2019.4 HF5, version 2019.4.5200.9083
  • Orion Platform 2020.2 RC1, version 2020.2.100.12219
  • Orion Platform 2020.2 RC2, version 2020.2.5200.12394
  • Orion Platform 2020.2, version 2020.2.5300.12432
  • Orion Platform 2020.2 HF1, version 2020.2.5300.12432

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).

Key Takeaways (updated December 18, 2020)

  • This is a patient, well-resourced, and focused adversary that has sustained long duration activity on victim networks.
  • CISA is investigating other initial access vectors in addition to the SolarWinds Orion supply chain compromise. 
  • Not all organizations that have the backdoor delivered through SolarWinds Orion have been targeted by the adversary with follow-on actions.
  • Organizations with suspected compromises need to be highly conscious of operational security, including when engaging in incident response activities and planning and implementing remediation plans. 

(Updated January 8, 2021) For a downloadable list of indicators of compromise (IOCs), see the STIX file, MAR-10318845-1.v1.stix, and MAR-10320115-1.v1.stix.

Technical Details

Overview

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.

Initial Infection Vectors [TA0001]

(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 Supply Chain Compromise [T1195.002]

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.

Anti-Forensic Techniques

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.

Privilege Escalation and Persistence [TA0004, TA0003]

(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]

User Impersonation

(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.

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

(New January 6, 2021): Detection: Identifying Compromised Azure/M365 Resources

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.

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.

  • (Updated January 6, 2021): Most organizations have SAML tokens with 1-hour validity periods. Long SAML token validity durations, such as 24 hours, could be unusual. Exact values (measured in precise seconds) is also considered 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.
  • (New January 6, 2021): Tokens with missing or unusual MFA details, when MFA is enforced, is considered an anoamaoly and should be investigated. This requires correlation of identity provider (iDP) logs with cloud access; differences in claims indicate maninpulated values. All claims should have a corresponding iDP entry.

(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.

Operational Security

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:

  • Out-of-band communications guidance for staff and leadership;
  • An outline of what “normal business” is acceptable to be conducted on the suspect network;
  • A call tree for critical contacts and decision making; and
  • Considerations for external communications to stakeholders and media.

MITRE ATT&CK® Techniques

CISA assesses that the threat actor engaged in the activities described in this Alert uses the below-listed ATT&CK techniques.

  • Query Registry [T1012]
  • Obfuscated Files or Information [T1027]
  • Obfuscated Files or Information: Steganography [T1027.003]
  • Process Discovery [T1057]
  • Indicator Removal on Host: File Deletion [T1070.004]
  • Application Layer Protocol: Web Protocols [T1071.001]
  • Application Layer Protocol: DNS [T1071.004]
  • File and Directory Discovery [T1083]
  • Ingress Tool Transfer [T1105]
  • Data Encoding: Standard Encoding [T1132.001]
  • Supply Chain Compromise: Compromise Software Dependencies and Development Tools [T1195.001]
  • Supply Chain Compromise: Compromise Software Supply Chain [T1195.002]
  • Software Discovery [T1518]
  • Software Discovery: Security Software [T1518.001]
  • Create or Modify System Process: Windows Service [T1543.003]
  • Subvert Trust Controls: Code Signing [T1553.002]
  • Dynamic Resolution: Domain Generation Algorithms [T1568.002]
  • System Services: Service Execution [T1569.002]
  • Compromise Infrastructure [T1584]

Mitigations

(Updated January 6, 2021) SolarWinds Orion Owners

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.)

  • Category 1 includes those who do not have the identified malicious binary code on their network and can forensically confirm that the binary was never present on their systems. This includes networks that do not, and never did, utilize the affected versions of SolarWinds Orion products (see Appendix A).
  • Category 2 includes networks where the presence of the malicious binary has been identified—with or without beaconing to 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:
     

    1. Had no beaconing, or
    2. Only beaconed to 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.
       
  • Category 2 organizations, after conducting appropriate forensic analysis to ensure they only have category 2 activity, can rebuild the platform, harden the configuration based on SolarWinds secure configuration guidelines, and resume use as determined by and consistent with their thorough risk evaluation. For entities not subject to ED 21-01, this can be accomplished by following the steps below. Federal agencies subject to ED 21-01 must follow the appropriate steps as outlined in the effective ED 21-01 supplemental guidance.
     

    1. Denying all incoming and outgoing (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.
    2. Cloud instances of Orion should only monitor cloud resources in that cloud infrastructure.
    3. On-premises instances of Orion should not be permissioned with any cloud/hosted identity accounts.
    4. Restoration of SolarWinds may be done from the legacy database following the SolarWinds restore guidance (http://solarwinds.com/upgrading-your-environment). Restoration for affected versions will differ from restoration for unaffected versions—agencies must ensure that they are following the correct restoration guidance.
    5. Before building SolarWinds:
      1. All account credentials, or other shared secrets (e.g., Simple Network Management Protocol [SNMP] strings) that are or had been utilized by the affected SolarWinds Orion device being rebuilt should be changed.
      2. Enable MFA for these credentials, whenever possible.
      3. Provide service accounts with the minimum privilege necessary for the role performed, whenever possible.
      4. For accounts where MFA is not possible  (e.g., service accounts), use randomly generated long and complex passwords (greater than 25 characters) and implement a maximum 90-day rotation policy for these passwords.
      5. Remove all inbound trust relationships to the SolarWinds Orion device being rebuilt.
    6. Re-building a SolarWinds Orion Platform to at least version 2020.2.1 HF2 and updating the host to the latest supported build, at least Windows 2016.
    7. Following the SolarWinds secure configuration (hardening) guidelines provided by the vendor, which can be found at: https://documentation.solarwinds.com/en/Success_Center/orionplatform/content/core-secure-configuration.htm. CISA does not recommend configuring the SolarWinds software to implement SAML-based authentication that relies on Microsoft’s Active Directory Federated Services if it has not already been configured to leverage SAML. This configuration is currently being exploited by the threat actor with this activity.
    8. Configuring logging to ensure that all logs on the host operating system and SolarWinds platform are being captured and stored for at least 180 days.
    9. Configure logging to ensure that all logs from the host OS, SolarWinds platform, and associated network logs are being captured and stored for at least 180 days in a separate, centralized log aggregation capability.
    10. Implementing subsequent SolarWinds Orion Platform updates. CISA recommends installing all updates within 48 hours of release. 
       
  • Category 3 includes those networks that used affected versions of SolarWinds Orion and have evidence of follow-on threat actor activity, such as binary beaconing to 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:

  1. Take actions to remediate kerberoasting, including, as necessary or appropriate, engaging with a 3rd party with experience eradicating APTs from enterprise networks. For Windows environments, refer to the following:
    1. See Microsoft’s documentation on kerberoasting: https://techcommunity.microsoft.com/t5/microsoft-security-and/detecting-ldap-based-kerberoasting-with-azure-atp/ba-p/462448.
    2. Change all account credentials, or other shared secrets (e.g., SNMP strings) that were potentially exposed:
      1. Enable MFA for these credentials, whenever possible;
      2. Provide service accounts with the minimum level of privilege necessary for the role performed, whenever possible; and
      3. For accounts where MFA is not possible, require use of randomly generated long and complex passwords (greater than 25 characters) and implement a maximum 90-day rotation policy for these passwords.
    3. Replace the user accounts with a Group Managed Service Account (gMSA). See https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview, and Implement Group Managed Service Accounts: https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview.
    4. Set account options for service accounts to support AES256_CTS_HMAC_SHA1_96 and not support DES, RC4, or AES128 bit encryption
    5. Define the Security Policy setting, for Network Security: Configure Encryption types allowed for Kerberos. Set the allowable encryption types to AES256_HMAC_SHA1 and Future encryption types. https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos
    6. See Microsoft’s documentation on how to reset the Kerberos Ticket Granting Ticket password, twice: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-forest-recovery-resetting-the-krbtgt-password.

SolarWinds Orion Specific Mitigations

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.

  • Step 1
    • Forensically image system memory and/or host operating systems hosting all instances of affected versions of SolarWinds Orion. Analyze for new user or service accounts, privileged or otherwise.
    • Analyze stored network traffic for indications of compromise, including new external DNS domains to which a small number of agency hosts (e.g., SolarWinds systems) have had connections.
  • Step 2
    • Affected organizations should immediately disconnect or power down affected all instances of affected versions of SolarWinds Orion from their network.
    • Additionally:
      • Block all traffic to and from hosts, external to the enterprise, where any version of SolarWinds Orion software has been installed.
      • Identify and remove all threat actor-controlled accounts and identified persistence mechanisms.  
  • Step 3  
    • Only after all known threat actor-controlled accounts and persistence mechanisms have been removed:
      • Treat all hosts monitored by the SolarWinds Orion monitoring software as compromised by threat actors and assume that the threat actor has deployed further persistence mechanisms.
      • Rebuild hosts monitored by the SolarWinds Orion monitoring software using trusted sources.
      • Reset all credentials used by or stored in SolarWinds software. Such credentials should be considered compromised.
  • (New December 19, 2020) For all network devices (routers, switches, firewalls, etc.) managed by affected SolarWinds servers that also have indications of additional adversary activity, CISA recommends the following steps:
    • Device configurations
      • Audit all network device configurations, stored or managed on the SolarWinds monitoring server, for signs of unauthorized or malicious configuration changes.
      • Audit the configurations found on network devices for signs of unauthorized or malicious configuration changes. Organizations should ensure they audit the current network device running configuration and any local configurations that could be loaded at boot time.
    • Credential and security information reset
      • Change all credentials being used to manage network devices, to include keys and strings used to secure network device functions (SNMP strings/user credentials, IPsec/IKE preshared keys, routing secrets, TACACS/RADIUS secrets, RSA keys/certificates, etc.).
    • Firmware and software validation
      • Validate all network device firmware/software which was stored or managed on the SolarWinds monitoring server. Cryptographic hash verification should be performed on such firmware/software and matched against known good hash values from the network vendor. CISA recommends that, if possible, organizations download known good versions of firmware.
  • For network devices managed by the SolarWinds monitoring server, the running firmware/software should be checked against known good hash values from the network vendor. CISA recommends that, if possible, organizations re-upload known good firmware/software to managed network devices and perform a reboot.

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.

Contact Information

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/.

Appendix A: Affected SolarWinds Orion Products

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

 

Appendix B: Indicators of Compromise

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

 IOC 

 Type   Notes  References   Source 
32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77  hash  Backdoor.Sunburst 

https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/ 

 
a25cadd48d70f6ea0c4a241d99c5241269e6faccb4054e62d16784640f8e53bc hash Backdoor.Sunburst https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-   attacks/  
d3c6785e18fba3749fb785bc313cf8346182f532c59172b69adfb31b96a5d0af hash Backdoor.Sunburst https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber- attacks/  
13.59.205[.]66 IPv4 DEFTSECURITY[.]com https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
deftsecurity[.]com domain Domain malicious on VT, registered with  Amazon, hosted on US IP address 13.59.205.66, malware repository, spyware and malware

https://www.virustotal.com/gui/domain/deftsecurity.com/details

https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/

Volexity
54.193.127[.]66 IPv4 FREESCANONLINE[.]com  https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/  
ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c hash No info available https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/  
c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77 hash No info available https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/  
dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b hash No info available https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/  
eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed hash No info available https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/  
avsvmcloud[.]com domain Reported by FireEye/ The malicious DLL calls out to a remote network infrastructure using the domains avsvmcloud[.]com. to prepare possible second-stage payloads, move laterally in the organization, and compromise or exfiltrate data. Malicious on VT. Hosted on IP address 20.140.0.1, which is registered with Microsoft.  malware callhome, command and control https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/

https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/

FireEye Report Talos

Volexity

3.87.182[.]149 IPv4 Resolves to KUBECLOUD[.]com, IP registered to Amazon. Tracked by Insikt/RF as tied to SUNBURST intrusion activity. https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
3.16.81[.]254 IPv4 Resolves to SEOBUNDLEKIT[.]com, registered to Amazon. Tracked by Insikt/RF as tied SUNBURST intrusion activity. https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
54.215.192[.]52 IPv4 THEDOCCLOUD[.]com https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134  hash Trojan.MSIL.SunBurst ttps://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber- attacks/  
ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6 hash Trojan.MSIL.SunBurst https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber- attacks/  
8.18.144[.]11 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]12 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]9 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]20 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]40 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/  Volexity
8.18.144[.]44 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]62 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]130 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]135 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]136 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]149 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]156 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]158 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]165 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]170 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]180 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.144[.]188 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]3 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]21 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]33 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]36 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]131 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]134 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]136 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]139 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]150 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]157 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
8.18.145[.]181 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
13.57.184[.]217 IPv4 (corrected typo in this IOC December 18, 2020) https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
18.217.225[.]111 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
18.220.219[.]143 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
20.141.48[.]154 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
34.219.234[.]134 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.1[.]3 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.21[.]54 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.48[.]22 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/  Volexity
184.72.101[.]22 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.113[.]55 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.145[.]34 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.209[.]33 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.212[.]52 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.224[.]3 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.229[.]1 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.240[.]3 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
184.72.245[.]1 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
196.203.11[.]89 IPv4   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/  Volexity
digitalcollege[.]org domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
freescanonline[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
globalnetworkissues[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
kubecloud[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
lcomputers[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
seobundlekit[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
solartrackingsystem[.]net domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
thedoccloud[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/  Volexity
virtualwebdata[.]com domain    https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
webcodez[.]com domain   https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600 hash   https://blog.malwarebytes.com/threat-analysis/2020/12/advanced-cyber-attack-hits-private-and-public  
c15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71 hash   https://blog.malwarebytes.com/threat-analysis/2020/12/advanced-cyber-attack-hits-private-and-public  
ervsystem[.]com domain

New January 6, 2021

Resolves to 198.12.75[.]112

 

https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/sunburst-supply-chain-attack-solarwinds Symantec
infinitysoftwares[.]com domain

New January 6, 2021

Updated January 7, 2021: corrected typo in this IOC; updated source

https://otx.alienvault.com/pulse/5fdce61ef056eff2ce0a90de  
mobilnweb[.]com domain

New January 6, 2021

Updated January 7, 2021: updated source

  CISA
02AF7CEC58B9A5DA1C542B5A32151BA1 Hash

New January 6, 2021

Sunburst Installer

File Name(s): CORE-2019.4.5220.20574-SolarWinds-Core-v2019.4.5220-Hotfix5.msp

 

  Symantec  Sunburst: Supply Chain Attack Targets Solar Winds Users
0548eedb3d1f45f1f9549e09d00683f3a1292ec5 Hash

New January 6, 2021

SSL hash for 198.12.75[.]112

 

   
0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589 Hash New January 6, 2021   CISA
1817a5bf9c01035bcf8a975c9f1d94b0ce7f6a200339485d8f93859f8f6d730c Hash

New January 6, 2021

Sunburst Backdoor

https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/sunburst-supply-chain-attack-solarwinds Symantec
1b476f58ca366b54f34d714ffce3fd73cc30db1a Hash

New January 6, 2021

Sunburst Installer
File Name(s):

CORE-2019.4.5220.20574-SolarWinds-Core-v2019.4.5220-Hotfix5.msp

  Symantec  Sunburst: Supply Chain Attack Targets Solar Winds Users
20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9 Hash New January 6, 2021   CISA
2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d Hash New January 6, 2021 https://otx.alienvault.com/pulse/5fd6df943558e0b56eaf3da8 CISA
2dafddbfb0981c5aa31f27a298b9c804e553c7bc Hash New January 6, 2021    
6e4050c6a2d2e5e49606d96dd2922da480f2e0c70082cc7e54449a7dc0d20f8d Hash New January 6, 2021   CrowdStrike
92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690 Hash New January 6, 2021   CISA
a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d Hash New January 6, 2021   CISA
a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2 Hash New January 6, 2021   CISA
b820e8a2057112d0ed73bd7995201dbed79a79e13c79d4bdad81a22f12387e07 Hash

New January 6, 2021

Sunburst Backdoor

https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/sunburst-supply-chain-attack-solarwinds Symantec
b8a05cc492f70ffa4adcd446b693d5aa2b71dc4fa2bf5022bf60d7b13884f666 Hash New January 6, 2021

https://otx.alienvault.com/pulse/5fd6df943558e0b56eaf3da8

 
cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6 Hash New January 6, 2021   CISA
e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d Hash New January 6, 2021   CISA
e70b6be294082188cbe0089dd44dbb86e365f6a2 Hash

New January 6, 2021

SSL hash for 107.152.35[.]77

   
fd15760abfc0b2537b89adc65b1ff3f072e7e31c Hash New January 6, 2021 https://otx.alienvault.com/pulse/5fd6df943558e0b56eaf3da8  
ffdbdd460420972fd2926a7f460c198523480bc6279dd6cca177230db18748e8 Hash New January 6, 2021

https://otx.alienvault.com/pulse/5fd6df943558e0b56eaf3da8

 

 
107.152.35[.]77 IPv4

New January 6, 2021

Resolves to infinitysoftwares[.]com

   
13.59.205[.]66 IPv4 New January 6, 2021 https://otx.alienvault.com/pulse/5fd825b7fa4eb2223a0cf812  
173.237.190[.]2 IPv4 New January 6, 2021   CISA
198.12.75[.]112 IPv4 New January 6, 2021

Resolves to ervsystem[.]com

Updated January 7, 2021: Corrected typo in resolves to domain

  Symantec  Sunburst: Supply Chain Attack Targets Solar Winds Users
20.141.48[.]154 IPv4

New January 6, 2021

Updated January 7, 2021: updated reference and source

https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ Volexity
34.203.203[.]23 IPv4

New January 7, 2021

  CISA

References

Revisions

  • Initial version: December 17, 2020
  • December 18, 2020: Updated note regarding initial vectors and key takeaways.
  • December 19, 2020: Updated mitigation guidance, indicators of compromise table, and provided a downloadable STIX file of the IOCs.
  • December 21, 2020: Added reference to NSA Cybersecurity Advisory: Detecting Abuse of Authentication Methods
  • December 23, 2020: Added link to CISA.gov/supply-chain-compromise
  • January 06, 2021: Updated Initial Access Vectors, Mitigations, and IOCs
  • January 07, 2021: Updated IOCs
  • Febraury 08, 2021: Updated IOCs

This product is provided subject to this Notification and this Privacy & Use policy.

Here’s How SolarWinds Hackers Stayed Undetected for Long Enough

Microsoft on Wednesday shared more specifics about the tactics, techniques, and procedures (TTPs) adopted by the attackers behind the SolarWinds hack to stay under the radar and avoid detection, as cybersecurity companies work towards getting a “clearer picture” of one of the most sophisticated attacks in recent history.
Calling the threat actor “skillful and methodic operators who follow
The Hacker News – Read More

In the Wake of the SolarWinds Hack, Here’s How Businesses Should Respond

Throughout 2020, businesses, in general, have had their hands full with IT challenges. They had to rush to accommodate a sudden shift to remote work. Then they had to navigate a rapid adoption of automation technologies.
And as the year came to a close, more businesses began trying to assemble the safety infrastructure required to return to some semblance of normal in 2021.
But at the end of the
The Hacker News – Read More

3 New Severe Security Vulnerabilities Found In SolarWinds Software

Cybersecurity researchers on Wednesday disclosed three severe security vulnerabilities impacting SolarWinds products, the most severe of which could have been exploited to achieve remote code execution with elevated privileges.
Two of the flaws (CVE-2021-25274 and CVE-2021-25275) were identified in the SolarWinds Orion Platform, while a third separate weakness (CVE-2021-25276) was found in the
The Hacker News – Read More

A New SolarWinds Flaw Likely Had Let Hackers Install SUPERNOVA Malware

An authentication bypass vulnerability in the SolarWinds Orion software may have been leveraged by adversaries as zero-day to deploy the SUPERNOVA malware in target environments.
According to an advisory published yesterday by the CERT Coordination Center, the SolarWinds Orion API that’s used to interface with all other Orion system monitoring and management products suffers from a security flaw
The Hacker News – Read More

US Agencies and FireEye Were Hacked Using SolarWinds Software Backdoor

State-sponsored actors allegedly working for Russia have targeted the US Treasury, the Commerce Department’s National Telecommunications and Information Administration (NTIA), and other government agencies to monitor internal email traffic as part of a widespread cyberespionage campaign.
The Washington Post, citing unnamed sources, said the latest attacks were the work of APT29 or Cozy Bear, the
The Hacker News – Read More