Executive Summary
There has been considerable focus on the recent disclosures associated with SolarWinds, and while existing analysis on the broader campaign has resulted in detection against specific IoCs associated with the Sunburst trojan, the focus within the Advanced Threat Research (ATR) team has been to determine the possibility of additional persistence measures. Our analysis into the backdoor reveals that the level of access lends itself to the assumption that additional persistence mechanisms could have been established and some inferences regarding the intent from adversaries;
- An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”. The ImprovementClient is a program that can collect considerable information such as count of Orion user accounts by authentication method and data about devices and applications monitored.
- Observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of Cloud and/or wireless networks of their victims.
- Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2.
Available Resources
Although this analysis will focus on the premise that the backdoor supports the feasibility of establishing additional persistence methods we recognize the importance of providing assurance regarding coverage against available indicators. To that end the following resources are available:
- KB93861: McAfee coverage for SolarWinds Sunburst Backdoor:
https://kc.mcafee.com/corporate/index?page=content&id=KB93861 - SUNBURST Malware and SolarWinds Supply Chain Compromise : Detailing the protection summary, but also how to use MVISION EDR or MAR to search for SUNBURST: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/sunburst-malware-and-solarwinds-supply-chain-compromise/
- MVISION Insights Campaign: SolarWinds Supply Chain Attack Affecting Multiple Global Victims With SUNBURST Backdoor. This resource provides up to date tracking on the prevalence of available indicators based on geography and sector of potential targets: https://www.mcafee.com/enterprise/en-us/lp/insights-preview.html#
Additional resources will become available as analysis both conducted by McAfee researchers, and the wider community becomes available.
Backdoor Analysis
There exists excellent analysis from many of our industry peers into the SUNBURST trojan, and the intention here is not to duplicate findings but to provide analysis we have not seen previously covered. The purpose is to enable potential victims to better understand the capabilities of the campaign in an effort to consider the possibility that there are additional persistence mechanisms.
For the purposes of this analysis our focus centered upon the file “SolarWinds.Orion.Core.BusinessLayer.dll“, this particular file, as the name suggests, is associated with the SolarWinds ORION software suite and was modified with a class added containing the backdoor “SunBurst”.
A deeper dive into the backdoor reveals that the initial call is to the added class “OrionImprovementBusinessLayer” which has the following functions:
The class starts with a check to see if the module is running and, if not, it will start the service and thereafter initiate a period of dormancy.
As was detailed by FireEye, this period of sleep can range from minutes up to two weeks. The actual time period of dormancy is dependent on the checks that must be passed from the code, like hash of the Orion process, write-times of files, process running etc. A sleep period of this length of time is unusual and speaks to a very patient adversary.
The most important strings inside the backdoors are encoded with the DeflateStream Class of the .NET’s Compression library together with the base64 encoder. By examining the block-list, we discover findings that warrant further inspection. First entries are the local-IP address ranges and netmasks:
- 10.0.0.0 255.0.0.0
- 172.16.0.0 255.240.0.0
- 192.168.0.0 255.255.0.0
Followed by the IPv6 local addresses equivalents:
fc00::,fe00::, fec0::,ffc0::,ff00::,ff00::
Next, there is a list of IP-addresses and their associated subnetmasks. We executed a whois on those IP-addressees to get an idea of whom they might belong to. There is no indication as to the reason that the following IPs have been inserted into the blocklist, although the netmasks implemented in certain entries are ‘quite’ specific, therefore we have to assume the attackers were intentional in their desire to avoid certain targets.
Assuming that the victim is not within the block list, the sample will then proceed to create the named pipe 583da945-62af-10e8-4902-a8f205c72b2e. This is done to ensure that only one instance of the backdoor is running. We were able to verify this through replication we carried out within our own environment.
When we ran the backdoor, we were able to confirm that this value is hardcoded in the code, and once the dormancy period passed the service is started and named pipe is created. At this point, the backdoor will also create a unique UserID MD5 value for the system it is installed on as depicted within figure 5.
This particular routine will initially read the Device-info of the system but ignore the loopback interfaces (part of the code of the ReadDeviceInfo routine that mentions “Select * From Win32_NetworkAdapterConfiguration where IPEnabled=true” ). The Device-info will then be combined with the domain name, followed by a value from the registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography). This information is then used to create an MD5 value of that string.
The module will start the ‘update’ routine. This routine is a continuous loop designed for verification against, for example, unwanted services that could potentially be used against detection of the backdoor as depicted in figure 6.
Information Gathering
The backdoor gathers information from the system. The following information is gathered by a routine called “CollectSystemDescription”, some examples include;
- OS version, major /minor – is it 32 or 64 bits
- Network configs, info on IP, NetBIOS, IPV6 etc.
- Host, SID & Username & System directory. In particular the SID for the Administrator account is searched for.
There exists other subroutines to collect additional data, for example enumerating the information from the network-adaptors, the backdoor uses the GetNetworkAdapterConfiguration routine. The routine is gathering the following information:
In order to check if certain ‘unwanted’ services are running, the backdoor enumerates the services, creates a hashlist and compares them with a hard-coded set of these values. The ‘update’ routine will exit once a ‘block-listed’ process id discovered. The backdoor will attempt to stop these services by entering a value in the registry for that service that will disable that service. The update routine will check again and continue this process until all unwanted processes are disabled.
Another capability of the backdoor is to start/stop tasks:
Other functionalities we observed in the code are:
- SetTime
- CollectSystemDescription
- UploadSystemDescription
- GetProcessByDescription
- GetFileSystemEntries
- WriteFile
- FileExists
- DeleteFile
- GetFileHash
- ReadRegistryValue
- SetRegistryValue
- DeleteRegistryValue
- GetRegistrySubKeyAndValueNames
- Reboot
An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”.
The ImprovementClient is a program that can collect the following information (source SolarWinds) :
- The SWID (SolarWinds ID) associated with any SolarWinds commercial licenses installed
- The email address provided to the installer during installation
- Unique identifier of the downloaded installer
- Versions of all Orion products installed
- Operating system version
- CPU description and count
- Physical memory installed and percent used
- Time zone
- Dates when you logged in to the Orion website
- Licensing information of other SolarWinds Orion products locally installed
- Row counts for database tables
- Count of monitored nodes by polling protocol
- Count of Orion user accounts by authentication method
- Network discovery scheduling information (not results)
- Data about devices and applications monitored:
- Vendor
- Model
- OS/Firmware version
- Count
- Abstract configuration information, such as number of websites hosted
- Data about the SolarWinds product:
- Feature usage statistics
- Performance statistics
- Hardware and OS platform description
Another observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of cloud and/or wireless networks of their victims by using the SolarWinds’ modules that are installed to monitor/administer these kinds of instances. Managing the network using SolarWinds’ Orion is executed by using a browser and localhost that is hosting the webserver. Reading out the certificate values and search for these keywords in the http-traffic would have gained this information.
Network / DGA
After all checks and routines have passed, the backdoor will use a domain generating algorithm (hereafter DGA) to generate a domain. Example of the part of the DGA code:
When the domain is successfully reached, the routine called ‘Update’ contains a part that will act on this and start a new thread firing off the routine “HttpHelper.Initialize”. In the below screenshot we can observe that flow:
The code shows that when the dnsrecord equals the domain and can be reached, the new thread will start in the background.
The ‘HttpHelper’ class/routine is responsible for all the C2 communications:
Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2. It then uses a routine called “IWebProxy GetWebProxy” for that:
The DGA-generated C2s are subdomains of: avsvmcloud[.]com.
An example of how these domains would look:
- 02m6hcopd17p6h450gt3.appsync-api.us-west-2.avsvmcloud.com
- 039n5tnndkhrfn5cun0y0sz02hij0b12.appsync-api.us-west-2.avsvmcloud.com
- 043o9vacvthf0v95t81l.appsync-api.us-east-2.avsvmcloud.com
- 04jrge684mgk4eq8m8adfg7.appsync-api.us-east-2.avsvmcloud.com
- 04r0rndp6aom5fq5g6p1.appsync-api.us-west-2.avsvmcloud.com
- 04spiistorug1jq5o6o0.appsync-api.us-west-2.avsvmcloud.com
Inspecting the CNAME’s from the DGA-generated C2’s we observed the following domain-names:
- freescanonline[.]com
- deftsecurity[.]com
- thedoccloud[.]com
- websitetheme[.]com
- highdatabase[.]com
- incomeupdate[.]com
- databasegalore[.]com
- panhardware[.]com
- Zupertech[.]com
- Virtualdataserver[.]com
- digitalcollege[.]org
In the forementioned HTTP handler code, we discovered paths that might be installed on the C2’s for different functions:
- swip/upd/
- swip/Events
- swip/Upload.ashx
Once the backdoor is connected, depending on the objectives from the adversaries, multiple actions can be executed including the usage of multiple payloads that can be injected into memory. At the time of writing, details regarding the ‘killswitch’ against the above domain will prevent this particular backdoor from being operational, however for the purpose of this analysis it demonstrates the level of access afforded to attackers. While the efforts to sinkhole the domain are to be applauded, organisations that have been able to identify indicators of SUNBURST within their environment are strongly encouraged to carry out additional measures to provide themselves assurances that further persistent mechanisms have not been deployed.
The post Additional Analysis into the SUNBURST Backdoor appeared first on McAfee Blogs.