More information has come to light about the Sunburst backdoor that could help defenders get a better handle on the scope of the sprawling SolarWinds espionage attack. The campaign is known to have affected six federal departments, Microsoft, FireEye and dozens of others so far.
Sunburst, a.k.a. Solorigate, is the malware used as the tip of the spear in the campaign, in which adversaries were able to use SolarWinds’ Orion network management platform to infect targets. It was pushed out via trojanized product updates to almost 18,000 organizations around the globe, starting nine months ago. With Sunburst embedded, the attackers have since been able to pick and choose which organizations to further penetrate.
Following the breadcrumbs found in Sunburst’s command-and-control (C2) communications, researchers from Kaspersky were able to progress from uncovering which companies are infected with the backdoor, to which ones were actually chosen for additional exploitation. Kaspersky researchers said they used the approach to identify a U.S. government entity and a telco (“a rather big telecommunications company from the U.S., serving more than 6 million customers”) that caught the attention of the attackers.
Further exploitation by the unknown advanced persistent threat (APT) group, dubbed UNC2452 or DarkHalo by researchers, involves installing more malware, installing persistence mechanisms and exfiltrating data, according to Kaspersky.
“The primary goal of the campaign appears to be espionage,” according to an analysis from Kaspersky, issued Thursday. “The attackers showed a deep understanding of Office365, Azure, Exchange and Powershell, and leveraged it in creative ways to monitor and extract the victims’ emails.”
Sunburst was planted in around 18,000 first-stage victims, but “only a handful [of the 18,000] were interesting to them,” Kaspersky analysts said.
“We spent the past days checking our own telemetry for signs of this attack, writing additional detections and making sure that our users are protected,” said Costin Raiu, head of Kaspersky’s Global Research and Analysis team, in a Thursday blog post. “At the moment, we have identified approximately 100 customers who downloaded the trojanized package containing the Sunburst backdoor. Further investigation is ongoing.”
The fact that Sunburst stayed under the radar for so long is unsurprising, analysts said. For instance, once installed, Sunburst stays silent for up to two weeks in an effort to evade detection, researchers said. Also, the component that contained the malware was code-signed with the appropriate SolarWinds certificate, as previously reported. This made the DLL look like a legitimate and safe component for the Orion product, with the right size and no suspicious scripts.
“The campaign was effective because of its combination of a supply-chain attack with a very well-thought-out first-stage implant and careful victim-selection strategies, and because it had no obvious connections to any previously observed tactics, techniques and procedures (TTPs),” according to the Kaspersky analysis. “It was particularly stealthy because of the slow communication method, a lack of x86 shellcode, and the fact that there was no significant change in the file size of the module when the malicious code was added.”
On the Hunt for Victims
The analysts were able to uncover more about how Sunburst communicates with its command-and-control (C2) server – namely, it does so through Domain Name System (DNS) requests. DNS performs the translation between human-readable domain names, like threatpost.com, and the numeric IP addresses that web browsers use. DNS requests initiate this translation – and these queries can be manipulated or altered by threat actors to contain additional information.
Once implanted, Sunburst starts to communicate with a first-stage C2 (“avsvmcloud[.]com”) by sending encoded DNS requests with information about the infected computer, so the attackers can decide whether to proceed to the next stage of infection.
If the attackers decide that an organization should be flagged for additional attention, the C2’s next DNS response will include a CNAME record pointing to a second-level C2 – an process that was also flagged by FireEye, with samples. CNAME is a type of DNS record that maps an alias name to a true or canonical domain name.
Importantly, the use of DNS requests can allow researchers to better identify victims of the attack, Raiu noted: “Knowing that the DNS requests generated by Sunburst encode some of the target’s information, the obvious next step would be to extract that information to find out who the victims are.”
Matching DNS Requests to Victims
In looking at the FireEye samples containing the CNAME records, Kaspersky analysts were able to uncover the OrionImprovementBusinessLayer.Update binary.
In unpacking it, it became clear that the binary calls one of four functions: GetCurrentString, GetPreviousString, GetNextStringEx and GetNextString, each of which correspond to four different DNS-based communications.
The first function, GetCurrentString, generates strings that contain a unique target’s identifier (this.guid), the target’s hostname (this.dnStrLower) and the rest of the hostname that will be in form of “appsync-api.*.avsvmcloud[.]com”, according to the analysis.
The encoding of the data is done by two additional functions, CreateSecureString and CreateString.
The function GetPreviousString meanwhile produces a similar hostname for a DNS request.
“It includes a part of the target’s hostname in the request, so that it would match the limitations on the request length. Each such request also includes the sequence number (this.nCount) that is the offset of the current substring from the beginning of the hostname,” researchers noted.
The remaining two functions, GetNextStringEx and GetNextString, include only the target’s unique ID (UID), hashes of the running processes of interest and the list and status of these processes. The target’s UID is then encrypted, and the data is encoded with CreateSecureString.
This information, which is sent to the attackers’ C2, can be matched with information in other (legitimate) DNS requests to identify who the companies are that have been flagged for additional focus, Raiu said.
“At this point, a question arises – can we match any of existing private and public DNS data for the malware root C2 domain, avsvmcloud[.]com, with the CNAME records, to identify who was targeted for further exploitation,” Raiu said.
After parsing publicly available DNS databases, Sunburst-generated and otherwise, the researchers were able to find that the UIDs are also included in other types of DNS requests – leading them to specific domains for specific victim companies.
Using this technique, both Kaspersky and QiAnXin Technology have published public decoders to help defenders assess the extent of the campaign.
While the finds are a breakthrough, Raiu said that much remains unknown about the attackers and their TTPs.
At the moment, there are no technical links with previous attacks, so it may be an entirely new actor, or a previously known one that evolved its TTPs and opsec to the point that it can’t be linked anymore. While some have linked it with APT29/Dukes, this appears to be based on unavailable data or weak TTPs, such as legitimate domain re-use.