New details emerged on SolarWinds supply chain compromise


On 13 December 2020, PwC Dark Lab reported on the compromise of IT network monitoring software SolarWinds Orion to deliver the SUNBURST malware. Since then, more information emerged from private and public sector sources, which this report addreses. As investigations over this espionage operations are ongoing, more details are likely to emerge in coming weeks, including of more potential entry points exploited by threat actors.1


The compromised update packages - SolarWinds.Orion.Core.BusinessLayer.dll and c:\\windows\\syswow64\\netsetupsvc.dll - were distributed from the legitimate vendor’s servers between March – June 2020, and reportedly affected software builds for versions 2019.4 HF5 through 2020.2.1.2

Attackers tested their ability to modify and deliver Orion updates via SolarWinds’ patch release management system in October 2019, although no malicious payload was reportedly included at the time.3 Analysis of the compromised updates shows that attackers modified the source code of an Orion’s library to include their backdoor, which was signed with SolarWinds’ digital certificate and closely followed SolarWinds’ coding style to blend in.4 It remains unclear how attackers gained access to SolarWinds’ network, although the company discovered the intrusion traces back to at least September 2019.5 Researchers discovered a malware dubbed SUNSPOT exploited by the attackers in the SolarWinds’ environment to inject SUNBURST in the Orion software.6

The compromised DLLs contain a backdoor dubbed SUNBURSTor Solarigate.8 SUNBURST can gather system information, start and kill processes, drop and delete files, modify the registry, among other functions. In particular, attackers went a long way to avoid detection. For instance, SUNBURST executes up to two weeks after delivery, identifies and attempt to terminate EDR tools’ processes, includes a function to disable itself (ReportWatcherRetry value 3), sends HTTP requests masquerading as Orion traffic to IPs in the same country as the victim.

C2 and victimology

SUNBURST gathers the domain where the victim machines is registered to generate a unique subdomain for command and control (C2). The malware uses domain generation alghoritm (DGA)9 to create victim-specific subdomains of the hardcoded C2 domain avsvmcloud[.]com. The domain has since been sinkholled by Microsoft.10 The subdomains are encoded with a custom method which researchers were able to decode to gather a list of victim-specific subdomains obtained via passive DNS.

The decoded list allows identification of potential victims and whether the attackers actively controlled the backdoor in that environment. Only a very small subset of the 18,000 Orion’s customers that reportedly downloaded the malicious Orion updates11 were actually targeted by threat actor. This suggests a highly targeted espionage operation against high value targets. Such a widespread supply chain compromise to target a small number of selected organisations resembles more the compromise of CCleaner,12 than the indiscriminate ransomware-like infection of NotPetya.13

PwC analysis of the unique C2 subdomains reveals that SUNBURST targets operated in the sectors listed in Table 1, and in countries visualised in the map in Figure 1.

Sectors affected by SUNBURST
Defence Manufacturing
Education Professional Services
Financial Services Technology
Government Telecommunications

Table 1 – Sectors affected by SUNBURST

Post Exploitation

On selected victims, the attackers then deployed additional tools like the TEARDROP memory dropper likely used to deploy a Cobalt Strike beacon.14 The attackers leveraged the access to move laterally across the network, gathering the necessary information to meet their objectives. Attackers were also observed using the authentication material stolen on-premises to elevate their access to the victim’s cloud environment, notably Azure Active Directory, effectively conducting vertical, rather than lateral, movement.

Attack diagram of SolarWinds compromise

Figure 1 – Attack diagram of SolarWinds compromise

To achieve this, the attackers stole the credentials from users with administrative access rights, particularly those not protected by multi-factor authentication. Attackers also targeted the on-premise servers with Security Assertions Markup Language (SAML) federation capabilities, gaining access to the SAML tokens signing certificate and allowing them to impersonate any user or account in the victim network. Threat actors were also observed taking steps to ensure long term access, including modifying Azure Active Directory to add new Federation Trusts and abuse OAuth Application & Service Principal credentials to Exchange servers.  

Uncertain attribution

On 5 January 2021, four US security agencies stated that the threat actor behind the SolarWinds supply chain compromise is "likely Russian in origin”.15 This follows earlier and unconfirmed news report that a group known in open source as APT29, often linked to the Russian foreign intelligence service agency SVR, was behind the operation.16  Since then, researchers identified some similarieties between SUNBURST and the Kuzuar backdoor used by an alleged Russia-based espionage group known as Turla.17

However, currently available evidence does not allow PwC to attribute Sunburst to a known threat actor with the necessary degree of confidence.


Organisations using SolarWinds Orion platform are advised to:

  • Upgrade to Orion Platform release 2020.2.1 HF 1, or HF2 – available at SolarWinds’ customer portal;18
  • Identify whether affected versions of SolarWinds Orion have previously been installed;
  • Check whether any of the affected SolarWinds file hashes are found;
  • Analyse SolarWinds Orion hosts for new user or service accounts, whether privileged or not;
  • If any suspicious activity is identified, conduct forensic imaging of the affected hosts;
  • Check for past external DNS queries for indicators of compromise, and with a statistical approach to identify if any unusual domain names were queried by SolarWinds hosts;
  • Rebuild hosts monitored by the SolarWinds Orion monitoring software using trusted sources;
  • Reset all credentials used by or stored in SolarWinds software;
  • Run up-to-date endpoint security solutions with endpoint detection and response (“EDR”) capabilities to identify possible malicious behaviour, or hands-on-keyboard activities;
  • Perform a review on excessive permissions in the Azure AD environments, or an analysis of one of the available tools.19,20
  • Ensure that cloud environments are properly hardened to prevent attackers' unauthorised access via vertical movement.
  • Review existing infrastructure to segregate and isolate servers associated to the connection to Azure Active Directory environment. In particular, re-assign ADFS as Tier-0 with the same security baseline as the domain controllers.

General cyber security best practices

Short-term plan: Intranet security assessment

  • Log audit (including system logs, app logs and security logs)
  • Abnormal network traffic analysis
  • External threat intelligence analysis
  • Security scanning and penetration testing for internal systems

Medium-term plan I: Vulnerability management

  • Identification of risk level of assets and third party suppliers
  • Definition of level of vulnerabilities
  • Establishment of internal responsible department
  • Development of vulnerability management process
  • Regular reporting

Medium-term plan II: Establishment of a zero-trust network architecture

  • Identity identification and access control
  • Asset management
  • Network segmentation
  • Terminal security
  • Threat intelligence

Long-term plan: Establishment of a security management and operation platform

  • Real-time monitoring of logs from servers, network devices and security devices
  • Integration of internal systems or services in response to those evolving threats in an efficient manner
  • Optimisation of intranet cybersecurity resources
  • Real-time threat alerts
  • Automation of task responses
  • Compliance with local regulatory requirements

Traffic Light Protocol

This report is classified as TLP:AMBER. Recipients may only share TLP:AMBER information with members of their own organisation who need to know the information to protect themselves or prevent further harm.




[4] Ibid.

















Contact us

Kenneth Wong

Kenneth Wong

Mainland China and Hong Kong Digital Trust & Risk - Cybersecurity and Privacy Leader, PwC Hong Kong

Tel: +[852] 2289 2719

Kok Tin Gan

Kok Tin Gan

Partner, PwC Hong Kong

Tel: +[852] 2289 1935

Follow us