SolarWinds: what happened and what’s next

Some of our clients here at NTT Application Security have asked us what they could do differently to prevent these kinds of attacks going forward, as they look to strengthen their digital security before another large-scale supply-chain attack occurs. But, preventing and detecting an attack such as this does not have a singular approach. One way to improve, however, is to identify and understand the core methods employed by the SolarStorm attackers.

A quick recap

‘The Sunburst attack appears to be one of the most complex and sophisticated cyberattacks in history.’

Sudhakar Ramakrishna, President and CEO of SolarWinds

According to a filing released by SolarWinds, nearly 18,000 of its clients downloaded an infected version of the company’s Orion product suite between March and June of last year. The four malware strains used in the attack — Sunspot, Sunburst, Raindrop and Teardrop — were designed to implant themselves onto vulnerable networks by leveraging a critical networking and infrastructure tool (in this case, Orion), allowing the attackers to gain highly privileged access to sensitive information.

Although the initial entry point is still unknown, the primary aspects of the attack have been researched and analyzed at some length. This includes what each malware strain was designed to execute, and how Sunspot was able to remain undetected on SolarWinds’ network for several months.

Here’s a brief breakdown of the SolarStorm attack:

• First, attackers were able to gain access to SolarWinds’ internal infrastructure, allowing them to inject the Sunspot malware on their network, giving them access to the Orion build process.
• Sunspot monitored all processes running on the build server and waited until it found the correct file relating to the Orion project (SLN file) to inject Sunburst, a subsequent malware strain, directly into the project’s build process. To avoid detection, Sunspot created a temporary file and overwrote the original source code with the malicious code from the temp file.
• Once the build process was complete and the injection fully implanted into the Orion product, Sunspot replaced the malicious file in the repository with the original, uninfected source code. This cleanup process was another one of the detection avoidance techniques the attackers used to remain hidden for as long as they did.

The Orion builds were successfully infected with the Sunburst malware in February of 2020. But it wasn’t until March of the same year that the infected code was fully rolled out into production builds and the malware was made available for download by SolarWinds’ clients. These vulnerable builds were available for download for only two months, but the breach remained undetected for six more months beyond that point.

After the client downloaded an infected build, Sunburst was able to send and receive commands via multiple Command & Control (C2) servers, including the injection of two additional malware strains dubbed Raindrop and Teardrop. The two strains are nearly identical to each other, aside from minor changes based on a given target’s specific operating system and internal infrastructure.

The data harvested by these malware strains was first sent to the primary C2 server, and filtered data was forwarded on to the secondary C2 servers. At that point, the attackers merely had to sift through a handful of targets identified by their code before beginning manual attacks on each individual system.

What’s next?

Another malware strain, Supernova, is now being scrutinized more closely. According to Palo Alto Networks, this strain may not be related to the SolarStorm attackers at all, due to the malicious DLL not being digitally signed like the Sunburst malware. The attackers designed this code to overwrite a pre-existing SolarWinds DLL on the systems of Orion’s end-users, which created a code injection vulnerability through modified API calls.

SolarWinds has continued to investigate the matter internally dating back to late January and has narrowed down the initial attack vector to one of three possible scenarios: spear-phishing, credentials-related attack of internal users, or an unpatched library vulnerability from a third-party vendor’s code.

One of the most effective ways to prevent spear-phishing and credentials-related attacks is by performing internal penetration tests and having regular internal security trainings to keep employees up-to-date on current policies, procedures and modern attack methodologies.

The third vulnerability type (Unpatched Library) can be identified through Software Composition Analysis (SCA) scans. Just like all vulnerabilities, patching libraries with known CVEs in a timely manner is of critical importance to reducing the window of exposure.