The threat actors gained access to victim organizations through trojanized updates to SolarWind’s Orion IT – SolarWinds.Orion.Core.BusinessLayer.dll. These updates have been digitally signed from March, 2020 to May, 2020 making this an infection period of possibly eight months.
Once infected, the threat actors remain dormant for 12 to 14 days before sending the first beacon to the C2 server. The C2 traffic mimics SolarWind API communications making the detection more difficult. The backdoor configuration also contains blacklists for anti-analysis and anti-virus tools. Upon detection of these tools the malware ceases communication and further activity.
Backdoor Status Overview
The SUNBURST backdoor leverages its configuration to store the state of the backdoor. The state defines the functionality of the backdoor; whether to communicate with the C2 or cease the communication. The configuration of the backdoor is stored in a file named: ‘SolarWinds.Orion.Core.BusinessLayer.dll.config’, with the key: ‘ReportWatcherRetry’.
There are three states of the backdoor.
The state of the backdoor is controlled by the C2 through the DNS response command by IP address. The state of the backdoor can be used to identify the infection status of the machine. By identifying the specific status code in the configuration file, we can identify the current state of the malware.
Based on our analysis, if the backdoor attempts to communicate with the C2 and is unable to based on the following scenarios:
- The communication is blocked
- SUNBURST has identified the presence of analysis tools
Then the actor would then inform the backdoor to cease the communication (TRUNCATE) in the next callback through DNS call.
Command and Control (C2): DNS
There are two types of communication that SUNBURST backdoor uses to communicate with the C2.
- Through DNS, which activates the backdoor.
- Through the HTTP/HTTPS protocol, where the backdoor requests and downloads commands to be executed.
- This method is used to download the second stage.
The first method uses DNS to control the backdoor; to activate the backdoor to callback or to remain idle. During the first execution, the backdoor is in “NEW” mode, and will make a DNS request. The resolved IP address informs the backdoor to activate and make a contact, remain silent, or to cease communication. Detailed list of the Command Types, Description, and Networks are below:
ATM
Cease communication due to the system unable to make communication with the C2.
10.0.0.0
172.16.0.0
192.168.0.0
224.0.0.0
fc00::
ff00::
Ipx
Continue to communicate with the C2.
41.84.159.0
74.114.24.0
54.118.140.0
217.163.7.0
ImpLink
The actor set the backdoor to cease communication. This is due to the backdoor unable to retrieve commands from the C2 or the actor doesn’t need any communication.
20.140.0.0
96.31.172.0
131.228.12.0
144.86.226.0
NetBios
The actor activate the backdoor to make communication with the C2. This inform the backdoor to communicate back using HTTP/s protocol.
8.18.144.0
18.130.0.0
71.152.53.0
99.79.0.0
87.238.80.0
99.201.117.0
184.72.0.0
With this information, we are able to identify the activities of the backdoor and level of risk by inspecting the DNS request.
We observed at least three scenarios that can be taking place in the infected machine.
C2 Communication
Scenario #1
The first scenario is where the infection machine activated the backdoor and the backdoor was able to communicate with the C2. The backdoor is activated by the C2 through the resolve of the IP address in the Netbios class. The backdoor makes the HTTP request and is able to retrieve the commands from the C2. At phase 5, the backdoor is in APPEND state and continues to make communication through the DNS. The actor responds with an IP address in IPX class to inform the backdoor to continue to make connections.
Scenario #2
In the second scenario the backdoor is activated and attempts to retrieve the commands through the HTTP protocol. However, due to the backdoor detecting the existence of an analysis software in the machine; it stops, or attempts to make the connection but is blocked by the firewall/proxy. The actor deactivates the backdoor through the “ImpLink” command.
Scenario #3
In the third scenario the machine is isolated. The DNS query returns the ATM class and the backdoor ceases the communication. Therefore by examining the DNS activities of the infected machine, we are able to assess the level of infection.
Risk Assessment
SUNBURST backdoor has added the logic for these scenarios to ensure the backdoor stays hidden and passive. Being infected does not necessarily mean the system is infected with CobaltStrike or Teardrop. Even though the actor triggers the backdoor callback, if the machine contains analysis tools or EDR, the backdoor does not call back to retrieve the second stage. Therefore examining the web log, DNS requests, and backdoors state at the first stage will help identify the risk level.
Detection And Mitigation
The following are a list of methods that can be used to identify and mitigate the SUNBURST backdoor.
Detections
- Identify the value of the key “ReportWatcherRetry” in the configuration file. If the value is 4 or 5, the backdoor is still communicating with the C2.
- Identify the IP address resolved by the C2, if the IP address network range is in the class of IPX or NetBios; the system potentially downloads the 2nd stage payload. If the system performed two DNS requests and the response is in the IP address network range of the NetBios class followed by ImpLink class, the backdoor is likely unable to communicate back to the C2 and the actor shuts the backdoor down.
Mitigations
- Set the state of the backdoor to TRUNCATE by set the value to “3” for key ” ReportWatcherRetry” in the configuration file as shows in Figure 3.
