RisingSun: Decoding SUNBURST C2 to Identify Infected Hosts Without Network Telemetry

January 14, 2021

Nearly three weeks after news regarding the widespread compromise of SolarWinds Orion customers became public, TrustedSec continues to receive inquiries from clients seeking more granular detail about the nature of the compromise.

In most cases, clients have received a list of command and control (C2) domains from a major vendor and require assistance in investigating their environment for signs of post-exploitation activity. In one case, a client had received a list of C2 domains containing more domains than the actual amount of SolarWinds servers deployed in their environment. This led to questions such as, ‘Can one host generate multiple C2 domains?’ and, ‘Can we attribute each domain to a particular SolarWinds host?’

Under ideal circumstances, DNS and other network logs would be our go-to data source for identifying which hosts connected to such domains. However, many organizations lack the logging necessary for investigating at the network level. In such cases, host-based analysis and a bit of creativity become necessary.

To find a solution to this challenge, the TrustedSec Incident Response Team dove deeper into the existing research surrounding the domain generation algorithm (DGA) used by the Sunburst backdoor. While our goal here is not to provide a deep-dive analysis of SUNBURST, a few key points should be considered:

  • As explained by FireEye, ‘SUNBURST uses four different forms of subdomains to signify the operating mode of the backdoor.’ In its initial phases, the subdomains will contain the encoded Active Directory domain of the infected system, along with a unique user ID that can be used to identify specific hosts.
  • The user ID value, referred to from here on as the Host ID, is generated by concatenating the MAC address of the host’s primary physical network adapter, the host’s Active Directory domain, and the Registry value found in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid. It then takes this concatenated string and computes the MD5 hash of it. The MD5 hash value is then encrypted and shortened using a custom XOR algorithm.
  • By replicating the algorithm used to create the Host ID and reversing the code used to generate the C2 domains, we can reproduce a system’s Host ID and compare it against the data extracted from C2 domains to determine whether that system produced any of those domains.

With this in mind, we embarked on a journey to produce our own tool to generate Host IDs based on user-provided information and compare them against a list of C2 domains. We are now pleased to release RisingSun, a cross-platform tool written in Go that can help organizations quickly identify if any of their SolarWinds servers generated particular SUNBURST C2 domains. RisingSun takes two inputs via the command line, a CSV file containing information from the hosts, and a file containing a list of C2 domains. The syntax is as follows: “go run RisingSun.go <path to host info file> <path to domains file>.” The host info file should be structured as follows:

<MAC address>,<AD domain>,<machine GUID>,<hostname>

For example:

AF:AF:AF:AF:AF:AF,lab.internal.corp, xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,solarwinds-01

BF:BF:BF:BF:BF:BF,lab.internal.corp, xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,solarwinds-02

The tool will dump the results of its analysis to a separate CSV, named results.csv, with a column indicating whether any of the hosts generated the domain in that row. It will also report any matches to the terminal. An example of the output is shown below.

Figure 1 – Terminal output of RisingSun
Figure 2 – CSV file created by RisingSun

RisingSun can be found here: https://github.com/trustedsec/RisingSun.

This effort would have taken significantly longer if not for the existing research of FireEye, SecureList, TrueSec, QiAnXin Technology, and Netresec. Links to their respective research and tools are provided in the References section below.








  • Browse by Category

  • Clear Form