Threat Context for the SolarWinds Incident

The story so far

In December 2020 the widely used business software application Orion, a product of the popular IT management company SolarWinds, was reported to have been tainted with nation-state malware that affected versions 2019.4 through to 2020.2.1 of the application released between March and June 2020. This Trojanized software update, dubbed SUNBURST, was only identified in December 2020. At the time of writing it is believed that more than 18,000 of SolarWinds’ 300,000 clients have been affected by the supply-chain attack.

Following the successful installation of the malicious software update, attackers identified high-value targets among the compromised SolarWinds clients and moved to elevate credentials and steal signed certificates. Considering how labor intensive such activities are known to be, it is widely believed that significant advanced planning was carried out prior to the successful launch of the Trojanized update.

Weeks after the discovery of the campaign, it is now known that the affected victims spanned government, consulting, technology, telecommunications, and extractive entities across the globe. Microsoft has since deduced that the majority of victims identified are located in the United States, though there are still significant cases globally, including in Canada, Mexico, Belgium, Spain, the UK, Israel, the UAE, and elsewhere.

While neither SolarWinds nor the other campaign victims have yet linked the attack to a specific actor, US federal officials believe it to be of Russian origin, with The Washington Post, via unnamed sources, reporting the attack to have been carried out by threat actor group APT29, a.k.a. Cozy Bear, a group that has been linked to the Russian Foreign Intelligence Service (SVR) as well as, at times, the Russian Federal Security Service (FSB).

The circus around the SolarWinds incident continued in the weeks following the initial disclosures. In early January, a website dubbed “SolarLeaks” appeared. The site purported to be selling data stolen from impacted SolarWinds clients and SolarWinds itself. It’s unclear whether this site is legitimate.


Exploiting the SolarWinds Orion vulnerability

The vulnerability impacting Solarwinds Orion (with Web Console WPM 2019.4.1, and Orion Platform HF4 or NPM HF2 2019.4) allows remote attackers to execute arbitrary code via a defined event, which is this case was triggered when a user downloaded a Trojanized update, giving the attackers the initial access they need to potentially compromise the victim’s entire network infrastructure.

From there the SUNBURST malware communicated back to the attackers via legitimate domains that have previously been purchased by the attacker and had laid dormant until the start of the campaign, which allowed them to evade defences that should identify suspicious traffic. Once live, SUNBURST transfered and executed files, profiled the system, rebooted the machine, and disabled system services. The backdoor masqueraded network traffic as the Orion Improvement Program (OIP) protocol and stored the stolen information within legitimate plugin configuration files.

Blueliv has identified two vulnerabilities that affected SolarWinds Orion and could have been leveraged by the attackers: CVE-2020-14005 and CVE-2020-13169. SolarWinds released a hot fix to patch both vulnerabilities on December 15, 2020. At the time of writing there is little public reporting about how the vulnerabilities were exploited. CVE-2020-14005 affects Web Console WPM 2019.4.1, and Orion Platform HF4 or NPM HF2 2019.4, allowing remote attackers to execute arbitrary code via a defined event. Blueliv has gathered significant insights into CVE-2020-13169 however, noting several severe ATT&CK patterns, particularly via variations of Cross-Site Scripting (XSS) associated with the vulnerability, including:


  • AJAX Fingerprinting: This attack utilizes the frequent client-server round trips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. In many XSS attacks the attacker must get a “hole in one” and successfully exploit the vulnerability on the victim side the first time, once the client is redirected the attacker has many chances to engage in follow on probes, but there is only one first chance. In a widely used web application this is not a major problem because 1 in a 1,000 is good enough in a widely used application.
  • Cross-Site Scripting (XSS): In this instance an adversary embeds malicious scripts in content that will be served to web browsers. The goal of the attack is for the target software, the client-side browser, to execute the script with the users’ privilege level. An attack of this type exploits a program’s vulnerabilities that are brought on by allowing remote hosts to execute code and scripts. Web browsers, for example, have some simple security controls in place, but if a remote attacker is allowed to execute scripts (through injecting them into user-generated content like bulletin boards) then these controls may be bypassed. These attacks are particularly difficult for an end user to detect.
  • DOM-Based XSS: This type of attack is a variation form of Cross-Site Scripting (XSS), above. Here, content served by a vulnerable web application includes script code used to manipulate the Document Object Model (DOM). This script code either does not properly validate input or does not perform proper output encoding, thus creating an opportunity for an adversary to inject a malicious script and launch a XSS attack. A key distinction between other XSS attacks and DOM-based attacks is that in other XSS attacks, the malicious script runs when the vulnerable web page is initially loaded, while a DOM-based attack executes sometime after the page loads. Another distinction of DOM-based attacks is that in some cases, the malicious script is never sent to the vulnerable web server at all. An attack like this is guaranteed to bypass any server-side filtering attempts to protect users.
  • Reflected XSS: This is another form of Cross-Site Scripting (XSS). The process starts with an adversary delivering a malicious script to a victim and convincing the victim to send the script to the vulnerable web application. The most common method of this is through the use of a phishing email in which the adversary embeds the malicious script with a URL that the victim then clicks on. In processing the subsequent request, the vulnerable web application incorrectly considers the malicious script as valid input and uses it to create a response that is then sent back to the victim. To launch a successful Reflected XSS attack, an adversary looks for places where user-input is used directly in the generation of a response. This often involves elements that are not expected to host scripts such as image tags (), or the addition of event attributes such as onload and onmouseover. These elements are often not subject to the same input validation, output encoding, and other content filtering and checking routines.

  • Stored XSS: Another offshoot of Cross-site Scripting (XSS), Stored XSS is initially presented by an adversary to the vulnerable web application. The malicious script is quickly, and incorrectly, considered as a valid input and is not properly encoded by the web application. A victim is then convinced to use the web application in a way that creates a response that includes the malicious script. This response is subsequently sent to the victim and the malicious script is executed by the victim’s browser. To launch a successful Stored XSS attack, an adversary looks for places where stored input data is used in the generation of a response. This often involves elements that are not expected to host scripts such as image tags (), or the addition of event attributes such as onload and onmouseover. These elements are often not subject to the same input validation, output encoding, and other content filtering and checking routines.

Blueliv’s Threat Context module helps defenders identify and monitor threat actors that may be seeking to weaponize CVEs of this nature. Threat Context monitors mentions of CVEs across a spectrum of sources, including security vendor blogs, code repositories, and cybercriminal forums, among others, to garner insights, such as the above, as well as proactive steps in understanding the prerequisites for the attack and how best to mitigate it.


Threat actors

APT29, also popularly known as Cozy Bear, is a Russian state-sponsored APT group and the prime suspect behind the Trojanized Orion update. The group is no stranger to carrying out attacks of this magnitude, having been behind various international espionage operations, including the hack against the Democratic National Committee (DNC) in the run up to the 2016 US presidential election (alongside fellow Russian APT Fancy Bear, the group that leaked documents stolen from the DNC to WikiLeaks).

The group has been active since 2008, conducting espionage operations against the diplomatic, governmental, think tank, healthcare, and energy sectors. The group has also targeted Chechen extremist groups and Russian organized crime, further highlighting the group’s ties to the Russian government. According to researchers at CrowdStrike, APT29 “casts a wide net” when conducting their campaigns, unlike most nation-state APTs which focus on a specific, relatively small range of intelligence targets. The group is also remarkable for the efforts it will take to stay in a network even after detection; whereas many APTs will desert a campaign after being uncovered, researchers have observed APT29 often doubling down and searching for new ways to maintain access.

APT29 is attributed to both the Russian Foreign Intelligence Service (SVR) as well as the Russian Federal Security Service (FSB) by the Estonian CERT and other organizations. ESET has hypothesized that APT29 is made up of several “sub-groups,” which could account for the disparate aims and tooling of the group, as well as the difficulties in attribution.

Kaspersky also identified that the malware Kazuar, attributed to actor group Turla, shares some code similarities with SUNBURST, though this doesn’t necessarily imply Turla was involved in this campaign. Instead, Kaspersky hypothesizes that Sunburst developers may have drawn inspiration from Kazuar; both attackers may have obtained malware from the same provider, Kazuar developers could have moved to another team, or SUNBURST developers may have introduced similarities on purpose as a false flag.

Intel 471, meanwhile, stated that in 2017, prolific initial access dealer “Fxmsp” offered access to SolarWinds computers on the top-tier Russian language forum Exploit, though it’s not clear whether Intel 471 was implying that said access was used in the 2020 SolarWinds incident. Blueliv analysts did not independently verify this claim, but assess the source as usually reliable and the information to be probable.


Threat Score

The NVD gave CVE-2020-13169 a base CVSS score of 9.6/10, whilst CVE-2020-14005 is measured at 8.8/10 in its latest assessment. Both of these scores are critical, though do not quite match Blueliv’s score of 8.0/10 (CVE-2020-14005) and 9.3/10 (CVE-2020-13169). This is because, when evaluating CVEs and their potential impact on an organization, several factors must be analyzed and observed ‘in the wild’. In this respect, Blueliv generates its own dynamic risk score for CVEs, which is subject to change in line with ongoing insights and developments surrounding the vulnerability.

Threat Context grants defenders the ability to identify mentions of a specific CVE in various code repositories which in turn assists them in pinpointing whether there may be a working PoC for a CVE. This ultimately helps defenders better understand what a successful exploitation might look like and ensure they are prepared.



Orion is just one of countless tools used by organizations the world over, any one of which could suffer a compromise of similar magnitude.

Moving forward, this means that the supply-chain must be considered as the latest component in an organization’s ever expanding security perimeter, alongside an emphasis on the vetting of third-party threats and vulnerabilities. Therefore, it is vital that organizations look to incident response platforms equipped with the ability to run security automation, ideally from a one-panel dashboard, that can monitor, and be integrated with, third-party solutions.

Blueliv’s Threat Context module includes third-party assessment, granting users insights into hidden risks and vulnerabilities among their outside environments to ensure SOC teams are always aware of any third-party risks. Threat Context can also assist defenders in tackling similar vulnerabilities to the Trojanized Orion update by providing a risk score as well as information into available exploits and PoCs; malware, threat actors, and campaigns leveraging a CVE; and mentions across different sources such as “Hacktivism,” “Dark Web,” or “Security News.” To provide further insights and assistance, Blueliv provides a dynamic scoring system for CVEs that offers real-time updates on the exploitation and weaponization of a vulnerability.

What is Threat Intelligence and why is it important?

Learn more
Demo Free Trial MSSP