Virsec Blog: Analyzing the SolarWinds Kill Chain

Written by Satya Gupta, Founder and CTO, Virsec

The recent attacks on government agencies and enterprises delivered through SolarWinds, used a complex series of steps to infiltrate the SolarWinds development supply chain, deliver malware to thousands of SolarWinds customers through benign-looking software updates, open back doors for malicious actors, and steal sensitive data.

Following is a technical analysis of the extended “Kill Chain” both infiltrating SolarWinds, and burrowing into software updates, dwelling in target networks for months, and stealing data from end-customers. This analysis is based on currently available information. As new details becomes available, we will continue to update our analysis and recommendations.

Stages in the Attack

Based on the above facts, the attack proceeded through these five stages:

1. Initial Infiltration: Potential exploitation of an Authentication Service vulnerability. This allowed the attackers to persist in the victim enterprise and go on to examine email and develop a profile on the developers they needed to target

2. Reconnaissance: Launching of spear phishing campaign that targeted the developers of interest

3. Spear Phishing: Infecting the local compute instance of the targeted developers

4. Weaponization (Insertion of Backdoor): Manipulating the build system to insert their backdoor

5. Infiltration of Downstream Users: Abuse trust relationships to penetrate end-user’s infrastructure

Deeper Dive into Stage 1: Initial Infiltration

Following is a diagram of the kill chain used for Stage 1. As stated previously, the objective of this attack was to develop a credible profile on victims in the SolarWinds organization.

Deeper Dive into Stage 2: Reconnaissance

Since the attackers had prolonged and persistent access to enterprise emails, they would have been able to include highly relevant contextual information in the spear phishing emails. This is confirmed by SolarWinds in their advisory referred to above.

Deeper Dive into Stage 3: Spear Phishing

A spear phished developer who had access the to the build system managed to check in malicious code as shown in Step 8 below.

Deeper Dive into Stage 4: Weaponization (Insertion of Backdoor)

What happened as part of Step 8 in the kill chain of Figure 2 is further detailed below. Since the attackers had persistent control on the victim developer’s compute instance, they were able to change source code contents as shown below.

An attacker has multiple touch points or opportunities for inserting one or more backdoors into the software vendor’s code. By leveraging the two-way communication channel with the victim’s compute machine, the attacker can drop new code, objects, or executables into the code. Once the code gets signed, the malicious code becomes “legitimate” or “blessed” by the software vendor’s digital certificate.

The first opportunity (Type 1 Attack) involves inserting malicious source code directly into the software vendor’s source code itself. In this scenario, the attacker can read and write code produced by the developer and familiarize themselves with the build processes. A clever attacker can then a use a coding style like that of the victim (one or more targeted software developer) and either modify existing source code or append new files into the sources. The goal is to ensure that the newly added malicious source code does not get detected either by the developer or other such as a peer reviewing the victim’s code or even by automated static code analysis tools. This mode of inserting a backdoor is the most efficient from the attacker’s point of view as there is no easy way to detect that the malicious activity took place or not.

A second opportunity (Type 2 Attack) for the attacker involves inserting precompiled objects directly into the build system. By dropping malicious pre-compiled objects into the one or more build machines, the attacker can add malware into the vendor’s otherwise pristine code. In most cases, the build system starts out by wiping all files from the one or many build directories. This step is followed by checking out code from the enterprise repository. Next the actual compiling/ linking activity subsumed in the build script(s) get activated. Since compiling and linking occur within close succession, for the attacker to be successful, the attacker must be able to insert their malicious precompiled objects in the open window of opportunity. This relatively smaller window of opportunity makes this approach of inserting a backdoor a little harder. Also, someone parsing the build logs could detect the attack and therefore the attacker’s footprint may get detected even before intended damage is done.

A third opportunity (Type 3 Attack) for the attacker involves inserting one or more compiled and linked binaries into the build systems. An unsuspecting build script may not notice the insertion of the executable backdoor and proceed with digitally signing the new build/ update. Since executable generation and signing are back-to-back operations, the attacker must make sure their backdoor is ready and waiting. This window of opportunity is also relatively small; therefore, the attacker must be very nimble.

A fourth opportunity (Type 4 Attack) for the attacker exists wherein they can hardcode access credentials into the code. This kind of backdoor is easily detected using automated code analysis tools like SAST tools and is not something attackers go after.

Deeper Dive into Stage 5: Infiltration of Downstream End Users

Once the malware got baked into Solar Wind’s official patch, it became even more lethal. Thousands of customers deployed the SolarWinds patch. Interestingly, in this case, not taking the Solar Winds patch may have ironically been better but that is just counterintuitive at best. As FireEye’s blog indicated, the Trojanized DLL was activated by the patch updater itself. On activation, this malware proceeded to establish a reverse communication channel to the attacker’s C&C server.