- Without any updates, SentinelOne customers are protected from SUNBURST; additionally, our customers have been supplied bespoke in-product hunting packs for real-time artifact observability.
- The malware deployed through the SolarWinds Orion platform waits 12 days before it executes.
- This common phenomenon is a prime example of why lengthy EDR data retention is critical after the 12-day dormant period, SUNBURST’s malicious code looks for processes, services, and drivers. You can find each list lists at the end of this research.
- List of processes: includes mostly monitoring tools like Sysinternals and researchers tools. If they are seen, SUNBURST exits and does not run.
- List of services: includes security products that have weak anti-tamper measures. SUNBURST goes to the registry and tries to disable them. The backdoor may have bypassed these products, or at least tried to. SentinelOne is not on this list, and even if it was, SentinelOne’s anti-tamper capability protects from such attempts (without any special configuration needed).
- List of drivers: The third list is shorter and includes a list of drivers; among them is SentinelOne. When SUNBURST sees the drivers, it exits before initiating any C2 communication or enabling additional payloads.
- The following analysis demonstrates the above key findings.
Interesting functionality resides within the
Update() methods, more specifically, the true payload lies within an important
TrackProcesses() method (called both by
UpdateNotification) is responsible for querying the running processes on the victim’s machine to find process, service, and driver names of interest. This routine will get a list of running process objects, then pass it to three methods below for identifying blacklisted processes/services. These methods will return true if a blacklisted process/service is found, causing the malware to break out of the
The hash of each process name is calculated, and then checked against a blacklist of hardcoded hashes, if the calculated hash is present in the blacklist, this method will return true.
SearchServices() method, the malware leverages the same hashing technique to identify services of interest, then tries to manually disable the service through modifying its registry key.
SetValue() method is used with argument 4 for the
Start entry, thus disabling the service through the registry.
In order to ensure that this works as intended, the malware attempts to take ownership of the registry key before disabling the service.
SearchConfigurations() is used to identify blacklisted drivers. This is performed through the WMI query –
Select * From Win32_SystemDriver, which is obfuscated in the below screenshot as C07NSU0uUdBScCvKz1UIz8wzNooPriwuSc11KcosSy0CAA==. The file name is obtained for each driver, and if this driver is found in the blacklist, this method will return true. As mentioned before, returning true causes the malware to break out of the Update() loop prior to initiating the true backdoor code. Our driver
SentinelMonitor.sys is hardcoded in the blacklist, meaning that the malware will not fully execute its payload on endpoints protected by SentinelOne so long as our driver is loaded.
If this blacklist check is passed, only then is the backdoor code initiated. The first interesting action the backdoor code takes is to call out to C2 to receive instructions/commands that will be parsed and passed to the job engine. This C2 callout is to a URL generated at runtime by the malware’s DGA, which will end up being a subdomain of avsvmcloud[.]com. We have observed no endpoints monitored by SentinelOne calling out to any subdomain of *.avsvmcloud[.]com.
During the research, we extracted all hashes from the malware, then calculated components in our agent found in C:\Program Files\SentinelOne\* to match. The only SentinelOne-related hash found was the driver name that FireEye shared.
Snip of hardcoded hashes extracted from the malware:
Hashing function extracted from the malware:
Results of the tool:
12343334044036541897 matched --> SentinelMonitor.sys
List of processes: SunBurst Exits
List of services: SunBurst trys to bypass
List of drivers: SunBurst Exits
- Search for the presence of the Injected class of weaponized DLL on OrionImprovementBusinessLayer class in the SolarWinds.Orion.Core.BusinessLayer namespace – Indicates weaponized .NET assembly/DLL
- Hardcoded named pipe name 583da945-62af-10e8-4902-a8f205c72b2e – Does not indicate that the backdoor code was initiated, but is the first action taken after the 12-14 day dormant period.
- Review proxy/web gateway logs for traffic to subdomains of this domain. This indicates that the backdoor code was indeed executed – avsvmcloud[.]com
- Executed during blacklist check routine in the context of the process
Select * From Win32_SystemDriver–
WMI query to identify blacklisted drivers
The post SolarWinds SUNBURST Backdoor: Inside the APT Campaign appeared first on SentinelLabs.