On December 8, 2020, cybersecurity company FireEye announced in a blog post that it had been attacked by what CEO Kevin Mandia described as a “highly sophisticated threat actor” that “targeted and accessed certain Red Team assessment tools that we use to test our customers’ security. These tools mimic the behavior of many cyber threat actors and enable FireEye to provide essential diagnostic security services to our customers.”
As FireEye investigated the attack, it discovered a vulnerability in a product made by SolarWinds Corp., one of its software providers. Hackers reportedly took advantage of that vulnerability to “implant malware, which then found its way into the systems of SolarWinds customers when they updated their software,” according to Bloomberg. This vulnerability is known as the SUNBURST Backdoor malware.
Since these events were discovered, Devo has taken publicly available information and applied methods of detection and currently available indicators to help evaluate the presence of these attack vectors or their channels in our customers’ networks. We have focused on our ability to create union tables with data related to the same type of technology, along with indicators available from various disclosed and undisclosed sources.
In a supply chain attack such as this, the impact can be widespread. That’s why Devo recommends that our customers search for these indicators by first looking at their near-term data—going back about a week—but also by looking back about six months to ensure you have a comprehensive view of any indicators that might be lurking in your data.
This post is a collaboration with my software engineering colleague Samuel Sancho and Fred Wilmot, CISO of Devo.
The following indicators are meant to help guide customers’ investigation and alerting processes. They do not mean that an organization has been compromised; rather, we intend them to help accelerate and focus our customers’ investigations.
Anatomy of a Detection
This is the detection process the Devo team performed. First, we evaluated all sources of data where an IOC would populate the event stream, which we call IOC inclusion. Using simple lookups, Devo distributes pieces of information that can be used to enrich and/or correlate with customer data. Consider domains, IPs, and hashes as some of these indicators.
Multiple trojaned software updates were digitally signed between March and May 2020 and posted to the SolarWinds updates website. More than a simple compromise, this is SolarWinds shipping compromised code using valid signed certificates to more than 17,000 customers worldwide for a widely used network management system with widespread activity. This is why it’s vital for customers to look back at several months’ worth of data to search for possible signs of compromise.
The trojan update file is a standard Windows Installer patch file that includes compressed resources associated with the update, including the trojaned SolarWinds.Orion.Core.BusinessLayer.dll component. Once the update is installed, the malicious DLL will be loaded by the legitimate SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe.
Devo provides methodologies to detect the backdoor both during and after the installation process. Here are the steps:
Devo’s detection and investigation capabilities play an important role across all three steps. Let’s dig in.
IOC Matching
Devo’s security engineering team creates and maintains some multilookups (lookups that all customers can use) with the known IOC-related Sunburst threat.
These lookups are used across the platform and applied to all customer tables. Based on the detection opportunities above, we can use these lookups across a wide range of tables to search for simple indicator matches. The following examples are a starting point for an investigation or as part of an alert definition.
Network DNS
Based on the lookups created by IOC we can track indicators across the network DNS union to detect connections between all DNS types and the domains associated with Sunburst.
from network.dns
where isnotnull(`lu/sunburst`(name)) or isnotnull(`lu/sunburst`(rootsuffix(name)+"."+topleveldomain(name)))
Firewall
Leveraging the lookups created by IOC we can track indicators across the firewall data union to detect connections between your network and the domains associated with Sunburst.
from firewall.all.traffic
where isnotnull(`lu/sunburstIP`(srcIp)) or isnotnull(`lu/sunburstIP`(dstIp))
Windows
Using the lookups created by IOC we can track indicators across the Windows logs union to detect process behavior related to Sunburst.
from box.all.win
select `lu/sunburstProc`(procName) as sunburstProc
where isnotnull(sunburstProc)
select `lu/sunburstProc`(procName) as sunburstProc
where isnotnull(sunburstProc)
Endpoints
from edr.all.threats
select `lu/sunburstHash`(sha256hash) as sunburstHash
where isnotnull(sunburstHash)
Partial Information
Other occasions require carrying out a detection based on partial information. For this type of request, we use functions capable of searching for extracts of information in our tables.
Network DNS
Because the backdoor determines its C2 server using a domain generation algorithm (DGA) to construct and resolve a subdomain of avsvmcloud.com. We can monitor this activity using the following query over network DNS data.
from network.dns
where toktains(lookupId, "appsync-api.eu-west-1.avsvmcloud.com")
or toktains(lookupId, "appsync-api.us-west-2.avsvmcloud.com")
or toktains(lookupId, "appsync-api.us-east-1.avsvmcloud.com")
or toktains(lookupId, "appsync-api.us-east-2.avsvmcloud.com")
Proxy Data
There are some indicators we can track in proxy data related to external communication.
from proxy.all.access
where url -> "swip/Events" or
url -> "/swip/upd/SolarWinds.CortexPlugin.Components.xml" or
url -> "swip/Upload.ashx" or
url -> "/swip/upd/"
Let’s Go Hunting
Devo aligns these individual queries, by indicators, across multiple tables. IOC cross-detection on all available data is considered critical. We commonly like to ask, ‘where has this indicator been seen’ across all data. Attacks of this type are best detected by combining all the available indicators both for efficiency and to understand the blast radius. From these types of searches, we can determine attack success, magnitude, and which systems were affected or adjacent to the initial attack.
Based on IP IOCs, for example, we can use hunting in Devo SecOps to correlate data from different tables, in this case, Firewall and Proxy.
Open SecOps from the Applications menu > Go to Hunting > Select one of the tables where you want to search (firewall.all.traffic for example) > Change to Expert mode > copy the following query:
from firewall.all.traffic
select "link" as subquery_link
group every 1m by subquery_link
where subquery_link in ((from firewall.all.traffic
where str(dstIp) in {'54.193.127.66','34.203.203.23','139.99.115.204','5.252.177.25','5.252.177.21','204.188.205.176','51.89.125.18','167.114.213.199','54.215.192.52'}
select "link" as subquery_link
group every - by subquery_link, srcIp, dstIp
select count() as count
) as firewall_all_traffic)
or subquery_link in ((from proxy.all.access
where str(dstIp) in {'54.193.127.66','34.203.203.23','139.99.115.204','5.252.177.25','5.252.177.21','204.188.205.176','51.89.125.18','167.114.213.199','54.215.192.52'}
select "link" as subquery_link
group every - by subquery_link, dstIp, dstHost
select count() as count
) as proxy_all_access)
select firewall_all_traffic[subquery_link][0] as firewall_all_traffic_srcIp
select firewall_all_traffic[subquery_link][1] as firewall_all_traffic_dstIp
select proxy_all_access[subquery_link][0] as proxy_all_access_dstIp
select proxy_all_access[subquery_link][1] as proxy_all_access_dstHost
AD Azure Access and Audit Queries
Based on the sign-in and audit, we also can look for anomalous AD PowerShell by new/existing users.
from cloud.azure.ad.signin
where eqic(properties_appId, "1b730954-1685-4b74-9bfd-dac224a7b894"), // AppDisplayName IS Azure Active Directory PowerShell
eqic(properties_tokenIssuerType, "AzureAD"),
not properties_resourceId = "00000002-0000-0000-c000-000000000000", // ResourceDisplayName IS NOT Windows Azure Active Directory
properties_status_errorCode = 0 // Success
Domain federation settings modification success (or failure) by user and IP address.
from cloud.azure.ad.audit
// FILTERS
where eqic(operationName, "Set federation settings on domain"),
eqic(properties_result, "success") // comment out if you also want to capture failed attempts
// FIELD EXTRACTIONS
select jsonparse(properties_targetResources) as json_targetResources,
jqeval(jqcompile(".[0].displayName"), json_targetResources) as displayName,
ifthenelse(isnotnull(properties_initiatedBy_user_userPrincipalName), properties_initiatedBy_user_userPrincipalName, properties_initiatedBy_user_displayName) as InitiatingUser,
properties_initiatedBy_user_ipAddress as InitiatingIpAddress
Audit log validation of certificate and secrets management may indicate new access credential added to the application or service principal.
This is an interesting finding from the past seven days.
from cloud.azure.ad.audit
// FILTERS
where weakhas(operationName,"Add service principal") or weakhas(operationName, "Certificates and secrets management")
where eqic(properties_result, "success")
where properties_initiatedBy_user_userPrincipalName -> "@" or properties_initiatedBy_user_displayName -> "@"
// FIELD EXTRACTIONS
select jsonparse(properties_targetResources) as json_targetResources,
jqeval(jqcompile(".[0].displayName"), json_targetResources) as targetDisplayName,
jqeval(jqcompile(".[0].id"), json_targetResources) as targetId,
jqeval(jqcompile(".[0].type"), json_targetResources) as targetType,
jqeval(jqcompile(".[0].modifiedProperties"), json_targetResources) as keyEvents_json,
stringify(keyEvents_json) as keyEvents_str
// ADDITIONAL FILTERS
where weakhas(keyEvents_str,"KeyIdentifier=") and weakhas(keyEvents_str,"KeyUsage=Verify")
Conclusion
When a cybersecurity attack occurs, the impact can range from merely annoying to potentially devastating. In a case like this, where a software company whose products are widely used is the victim, the ripple effects can be far-reaching and long-lasting. That’s why a supply chain attack, such as the one that hit SolarWinds, can be particularly damaging.
The attack on SolarWinds enabled attackers to steal FireEye’s red team tools. And the effects could continue to be felt for some time to come, based on the proliferation of the malware to other connected entities. SolarWinds estimates that as many as 18,000 entities may have downloaded the malicious Trojan.
As always, Devo will continually provide our customers with updated IOC information as it becomes available. We will incorporate all of the alerts necessary to detect known behaviors—and any behaviors to come—into our ongoing alert set that we provide to all Devo customers.
Appendix – A Sources
FireEye notifications https://www.fireeye.com/blog/products-and-services/2020/12/fireeye-shares-details-of-recent-cyber-attack-actions-to-protect-community.html
CISA Advisory
https://us-cert.cisa.gov/ncas/current-activity/2020/12/13/active-exploitation-solarwinds-software
FireEye Indicators
https://github.com/fireeye/sunburst_countermeasures
https://github.com/fireeye/red_team_tool_countermeasures
Bambenek Indicators
https://github.com/bambenek/research/tree/main/sunburst
Further Reading
https://thehackernews.com/2020/12/us-agencies-and-fireeye-were-hacked.html
https://www.sans.org/webcasts/emergency-webcast-about-solarwinds-supply-chain-attack-118015
https://support.solarwinds.com/SuccessCenter/s/article/Orion-Hotfix-Release-Notes?language=en_US
https://www.solarwinds.com/securityadvisory
https://www.wsj.com/articles/agencies-hacked-in-foreign-cyber-espionage-campaign-11607897866
Government Advisory
https://www.cyber.gov.au/acsc/view-all-content/alerts/potential-solarwinds-orion-compromise
