<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1462084720533760&amp;ev=PageView&amp;noscript=1">
Blog
12.23.2020

Analyzing the SolarWinds Attack Kill Chain

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.

Download our Technical Brief: Taxonomy of The Attack on SolarWinds and Its Supply Chain

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.

Analysis of the Solar Winds attack kill chain

Figure 1: Stage 1 Attack on a vulnerable server in SolarWinds infrastructure

 

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.

figure-2

Figure 2: Stage 3 Attack on gullible human

 

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.

Solar Winds attack: manipulating source code

Figure 3: Manipulating source code at SolarWinds

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.

Solar Winds: Kill chain for end-users

Figure 4: Kill chain for SolarWinds end-users

 

Download our Technical Brief: Taxonomy of The Attack on SolarWinds and Its Supply Chain

About the Author
Satya Gupta is Virsec’s visionary founder, with over 25 years of expertise in embedded systems, network security and systems architecture. Satya has helped build and guide the company through key growth phases from initial funding (2015), developing core technology with key partners including Raytheon and Lockheed (2016-2018), to launching an enterprise class, GA product (2019). Prior to this, Satya built a highly profitable software design and consulting business targeting data networking, application security and industrial automation projects. He was also Director of Firmware Engineering at Narad Networks and Managing Director and Chief Engineer at Eastern Telecom and Tech Ltd. Satya has more than 40 patents in complex firmware architecture with products deployed to hundreds of thousands of users. He holds a BS degree in Engineering from the Indian Institute of Technology in Kanpur and additional degrees from the University of Massachusetts at Lowell.