Threat Brief: SolarStorm and SUNBURST Customer Coverage

  • 100,512
    people reacted
  • 192
  • 14 min. read

By

Category: Unit 42

Tags: , , , , ,

Threat brief conceptual image, representing Unit 42 threat briefs such as this post, covering SolarStorm and SUNBURST

This post is also available in: 日本語 (Japanese)

SolarStorm Response With Cortex XDR

Customers running Cortex XDR Pro can leverage the product's existing alert sets and hunt for related activity.

Please note that the Cortex XDR Managed Threat Hunting Service scanned all data available for all XDR Pro customers – even those who are not currently subscribed to the service – and sent an impact report based on the findings to all XDR Pro customers.

Firstly, to understand if the organization is breached, we can search for SolarWinds installations based either on endpoint or network data using the following query, leveraging AppID and known SolarWinds domains (For updated and copy/paste-friendly versions, all queries described in this section are available on GitHub.):

This shows how to leverage AppID and known SolarWinds domains to search for SolarWinds installations based either on endpoint or network data.

To verify if you have been a victim of the attack, assuming there is a Palo Alto Networks NGFW or an agent installed on a SolarWinds server, you can run a query to check for known IOCs.

It’s possible to load known IOCs, such as IPs, domains, hashes and filenames, into XDR and it will automatically run a backwards scan, resulting in alerts on historic data.

To do this, create one file with all the IOCs:

IOCs for SolarWinds and SolarStorm

Go to the Rules → IOC page and click on “+ Add IOC” and then select “Upload File” in the popup view. 

This shows how to add SolarStorm and SolarWinds IOCs to Cortex XDR.

Add your file, assign a severity, reputation, reliability and expiration date, then click “Upload.”

After loading, you’ll see the “Backwards Scan Status” as pending and “# Of Hits” as 0. A few minutes later, you’ll see the status change to “Done” with a timestamp.

If any matches were found, you’ll see the “# Of Hits” change from 0 to the amount of hits the system found per IOC.

If any matches were found, you'll see the # of Hits displayed per IOC.

You can right-click on the IOC and select “View Associated Alerts” to pivot to the alert page.

You can right-click on the IOC and select "View Associated Alerts" to pivot to the alert page, as shown.

Whenever you see this icon ICON indicates historic match based on backwards scanning on an IOC or Behavioral IOC. next to a rule name in XDR, it means that this is a historic match based on backwards scanning on an IOC or Behavioral IOC.

Historic matches based on backward scanning on an IOC or Behavioral IOC appear as shown.

You can right-click on the alert to analyze it and drill down into it.

Vice versa, you can run an XQL query with the known IOCs. This will look across file writes, module loads, process executions, network traffic and DNS queries coming either through NGFW, Cortex Agent or any third party network traffic that is ingested into the Cortex XDR Data Lake:

Historic matches based on backward scanning on an IOC or Behavioral IOC appear as shown.

As attackers might have used different domains and hashes, we suggest hunting for behavior from the infected SolarWinds executable in addition to searching for known IOCs.

We suggest using the following queries to verify that no suspicious activity took place:

1. Look at alerts and incidents that have any SolarWinds binary attached to them or any alerts related to Cobalt Strike, as these attackers have been seen using the framework:

Look at alerts and incidents that have any SolarWinds binary attached to them or any alerts related to Cobalt Strike

Look at alerts and incidents that have any SolarWinds binary attached to them or any alerts related to Cobalt Strike, as these attackers have been seen using the framework.

 

2. Look for binary and scripting files dropped from the infected SolarWinds process:

Look for binary and scripting files dropped from the infected SolarWinds process

3. Look for signs of the infected SolarWinds process accessing non-SolarWinds domains:

Look for signs of the infected SolarWinds process accessing non-SolarWinds domains

4. Look for the infected SolarWinds process running Windows Management Instrumentation queries:

5. Look for the infected SolarWinds process modifying or creating a service:

Look for the infected SolarWinds process modifying or creating a service.
6. We can hunt down backdoored DLLs which initiated network connections and look for any suspicious connection that involves DGA domains:

7. Hunt based on the known backdoor named pipe:

XDR 2.6.5, the latest release, now opens up new abilities to query Azure Active Directory (AD) audit logs to hunt for activities that the threat actor has done after gaining access and leveraging the backdoor to get credentials. You can use the following queries to hunt for such activity assuming you have configured your XDR using our admin guide:

1. Hunt for Azure AD service account created or modified:

2. Hunt for Azure AD application sharing with additional tenants:

3. Hunt for Azure AD custom unverified domain was added:

4. Hunt for SSO being disabled for a domain:

5. Hunt for domain federation settings modified:

6. Hunt for cases where mail permissions were added to a service principal:

These queries are also waiting in our query center for easy execution:

These queries are waiting in the Cortex XDR query center for easy execution.

(See the Appendix for IOCs, or find them on GitHub.)

SolarStorm Response With Cortex XSOAR

Cortex XSOAR has launched a rapid response playbook to speed up the discovery of SolarWind installations within your network, uncover signs of a potential SolarStorm activity and automate response actions such as the quarantining of compromised endpoints.

Continue reading: Conclusion, Additional Resources and IOCs

Back to Top