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.
Based on the above facts, the ransomware 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 a 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
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.
Figure 1: Stage 1 Attack on a vulnerable server in SolarWinds infrastructure
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.
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: Stage 3 Attack on gullible human
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 touchpoints 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 computing 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.
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.
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.
Figure 4: Kill chain for SolarWinds end-users
Download our Technical Brief: Taxonomy of The Attack on SolarWinds and Its Supply Chain