Sunburst - Part 3

This piece is another follow up to my analyses of the Sunburst intrusion toolchain that was introduced to the SolarWinds software distribution channel in March of 2020, and, which remained undetected for several months while a large number of US government computer systems were compromised. Unless there is a twist from left field, this will likely be the last in this series. 

Part 1

Part 2 

It has been several weeks since my last entry on this topic, and I have to admit, the story has drifted from my attention given the current events in my nation. But, I finally managed to steal a few minutes to do some more collation of source data and I am able to report a bit more. 

Who is doing this and why?

There seems to be a consensus at this point that the actors are a non-state group of malicious programmers (I hate the term "hackers"). They have been dubbed APT29 (Advanced Persistent Threat). 

From https://www.enigmasoftware.com/apt29-removal/

APT29 (Advanced Persistent Threat) is a hacking group that originates from Russia. This hacking group also acts under the aliases Cozy Bear, Cozy Duke, the Dukes, and Office Monkeys. The cybergang traces its origins to the 2008 MiniDuke malware, and they have been continuously improving and updating their hacking arsenal as well as attack strategies and infrastructure. APT29 often goes after high-value targets all over the world. APT29’s most recent efforts have focused on stealing COVID-19-vaccine data from medical institutions across the globe. 

What does it do?

APT29 always conducts two-stage attacks featuring a backdoor Trojan and a malware dropper. The former aims to retrieve personal data and send it back to a remote Command-and-Control server (C&C), while the latter does the actual damage, depending on the targeted organization. The toolkits are subject to regular updates and tweaks for enhanced AV evasion.

Having read the full technical write-up at FireEye, I can summarize a little more about it's capabilities. 

• It checks to see if it's in a possible monitoring environment, and if so,  quasi-permanently disables itself.  
• It uses DNS for a "beacon" mode and once it receives a particular type of DNS response to a query, it starts using HTTPS for Command and control mode, but disguises its communications as legitimate SolarWinds traffic. 
• The following generic operations are available for the C2 server: 
• List processes on host
• Run program
• Write file
• Read file
• Switch state (beacon/active)
• Delete file
• It can be updated dynamically. 

How does it do this?

A very detailed "additional technical details" can be found at the FireEye web site. From the link. 

Before reaching out to its C2 server, SUNBURST performs numerous checks to ensure no analysis tools are present. It checks process names, file write timestamps, and Active Directory (AD) domains before proceeding.

Next, the backdoor only executes if the filesystem last write time of the .NET assembly SolarWinds.Orion.Core.BusinessLayer.dll is at least 12 to 14 days prior to the current time. The exact threshold is selected randomly from this interval. 

The backdoor also determines if the system is joined to an Active Directory (AD) domain and, if so, retrieves the domain name. Execution ceases if the system is not joined to an AD domain. SUNBURST checks the AD domain name against a blocklist and halts execution. 

From this point it gets pretty complicated. I used the flow diagram from the FireEye site rather than having the content of this article be nearly 90% scraped content. 

Complete flowchart for Sunburst malware

It does quite a bit. I had joked at one point that "give me a salary and a half a year I might be able to build something like this". What you should hear in that sentence is quite a large modicum of respect for the architects of this toolchain. They thought of quite a bit. The key takeaways from all of the technical reporting that I have been able to find to date has been

• This is a multi-stage attack, and multiple payloads are dropped on target hosts 
• It attempts to stealth itself 
• It will "suicide" if it thinks it's been detected. 
• It will only remain active on "interesting" domains. 

What is being done about it? 

While clever and creative, the use of the DNS beacon mode may have been a mistake by the architects of this gem of nasty. If you read the "DNS C2 and the C2 Coordinator Protocol" section of the FireEye paper, you'll see it uses DNS heavily in passing messages and locating compromised systems. DNS records were manipulated in a manner to disrupt the C2 protocol. With respect to the flowchart, the part where "CNAME required at this point" is disrupted now. 

FireEye discovered that certain DNS responses cause the malware to disable itself and stop further network activity. With the support and help of GoDaddy’s Abuse Team and the Microsoft Threat Intelligence Center, the domain used for resolving DGA domains was reconfigured to point to a sinkhole server under Microsoft’s control. The IP of this sinkhole server was specially chosen to fall into the range used by the malware to transition from its current mode (New or Append) into Truncate mode where it will be permanently inactive. In other words, SUNBURST infections should now be inoculated due to the killswitch.

What specific organizations are doing to mitigate this threat beyond this "innoculation" with the "killswitch" is beyond the scope of this article.  

Analysis

• My trust in the FireEye analysis is very high simply due to the amount of information they are sharing with the world about this very advanced malware. 
• The complexity of Sunburst is consistent with a seasoned or experienced software development team working on it. 
• Inside knowledge of the SolarWinds corporate network that was leveraged. 
• It appears that the entire SolarWinds software development build process was compromised, as this was spread using compromised DLL files which bore valid signatures. 
• Since multiple payloads were dropped, I still suspect there is more to come. The technical reporting isn't saying anything yet, but I imagine that a compromised system will have a backdoor on it that is not yet known about. This will be exceedingly difficult to prove in the negative, as is a virus infection on a system. If possible all systems affect should be re-imaged. 

Post-event lessons 

• If there wasn't any "inside knowledge" used to gain access, SolarWinds leaked too much about their internal network. 
• Software distribution channels are a "holy grail" for malicious actors, and they will expend considerable time, money and resources to compromise them. 
• The target of the attack is actually a rather run-of-the-mill class of target for this sort of actor - research data or trade secrets. 
• This one turned the thread landscape somewhat on it's ear - instead of the classic story of "the user double-clicked an attachment", the compromise story on this one goes "the software update came down from corporate".
• The development and build workflow can be a very high-value target at a software development company - resources like the subversion or git servers, along with production build systems should probably be treated as we treat internal database servers with sensitive information on them. "It's just a development server" doesn't really ring true anymore.