SolarWinds | Understanding & Detecting the SUPERNOVA Webshell Trojan - SentinelLabs By Marco Figueroa Published: 2020-12-23 · Archived: 2026-04-05 17:42:34 UTC By Marco Figueroa, James Haughom and Jim Walter Introduction The recent SolarWinds’ Orion supply chain attack has proven to be one of the most layered and damaging attacks of 2020, consisting of multiple artifacts and sophisticated TTPs. Several distinct malware families have emerged in relation to the compromise. These include the SUNBURST backdoor, SUPERNOVA, COSMICGALE & TEARDROP. Organizations protected by SentinelOne’s Singularity platform are fully protected against all of these new threats. In this post, we provide an analysis of the SUPERNOVA trojan, describing how the weaponized DLL payload differs from the legitimate version it supplanted. Further, we disclose some new Indicators of Compromise that may, in addition to previously documented IoCs, help security teams to detect when the malicious webshell is active. Overview of SolarWinds’ Malware Components The sophisticated nature of the SolarWinds compromise has resulted in a flurry of new malware families, each with different characteristics and behaviors. SUNBURST refers to a .NET backdoor (written in C#). This backdoor was distributed as part of a trojanized MSI (Windows installer) patch and distributed via SolarWinds updating mechanisms. TEARDROP is a memory-resident implant used (primarily) to distribute the Cobalt Strike beacon payload. COSMICGALE refers to certain malicious PowerShell scripts that are executed on compromised hosts. SUPERNOVA refers to a web shell implant used to distribute and execute additional code on exposed hosts. Below, we focus on understanding and detecting the SUPERNOVA web shell implant. The Trojanized App_Web_logoimagehandler DLL The SUPERNOVA web shell implant is a trojanized copy of a legitimate DLL .NET library in the SolarWinds Orion web application. The purpose of the original DLL is to serve up a user-configured logo to web pages in the Orion web application. https://labs.sentinelone.com/solarwinds-understanding-detecting-the-supernova-webshell-trojan/ Page 1 of 10 Modifying the legitimate SolarWindows DLL for malicious use required just a few key changes, and upon analysis appears deceptively ‘elegant’. Below, we illustrate some of the key differences between the legitimate SolarWinds DLL and the weaponized ‘SUPERNOVA’ DLL. The attackers injected an additional method, DynamicRun(), into the legitimate SolarWinds’ LogoImageHandler class from the App_Web_logoimagehandler.ashx.b6031896.dll , turning the benign DLL into a sophisticated webshell. https://labs.sentinelone.com/solarwinds-understanding-detecting-the-supernova-webshell-trojan/ Page 2 of 10 A legitimate instance of App_Web_logoimagehandler.ashx.b6031896.dll : https://labs.sentinelone.com/solarwinds-understanding-detecting-the-supernova-webshell-trojan/ Page 3 of 10 A weaponized instance of App_Web_logoimagehandler.ashx.b6031896.dll : https://labs.sentinelone.com/solarwinds-understanding-detecting-the-supernova-webshell-trojan/ Page 4 of 10 The added DynamicRun() method is called by the ProcessRequest() method, which handles HTTP requests. The attackers added a try/catch block to the beginning of this method’s source code to parse part of the HTTP request and redirect control flow to the attacker’s DynamicRun() method. The legitimate ProcessRequest() method: And the weaponized ProcessRequest() with added try/catch block: https://labs.sentinelone.com/solarwinds-understanding-detecting-the-supernova-webshell-trojan/ Page 5 of 10 The additional code simply extracts data in the form of name-value from the Request property of an instance of the HttpContext class. Once extracted, these four values will be passed to DynamicRun() to be executed, and the method’s return value will be written back to the attacker as an HTTP response. The DynamicRun() method is where the true functionality of the SUPERNOVA webshell resides. This method accepts a blob of C# source code, along with the class to instantiate, the method to invoke, and the method’s arguments. These parameters will be used to compile and execute an in-memory .NET assembly sent by the attackers over HTTP. The .NET CSharpCodeProvider class is the mechanism used to perform the in-memory compilation. As you can see below, the GenerateInMemory parameter is set to true, meaning a physical assembly will not be written to disk, allowing minimal forensic artifacts to be created. The last parameter passed to the in-memory compiler is the blob of C# source code supplied by the attacker’s HTTP request to be compiled. https://labs.sentinelone.com/solarwinds-understanding-detecting-the-supernova-webshell-trojan/ Page 6 of 10 Breakdown of parameters: If no errors arise during compilation, the malware instantiates the respective class, invokes the method passed as the third argument to the function, and returns the results. This functionality allows the attackers to compile and execute .NET payloads at will, all within the context of SolarWinds. This mechanism does not leverage any exploit, but simply abuses legitimate .NET functionality. This is powerful, as it allows the malware to execute robust compiled code on the fly, without dropping any additional files to the file system or running any obvious or noisy commands being sent over the wire. Detecting SUPERNOVA Webshell Activity During our research, we created a PoC, leveraging the same CSharpCodeProvider mechanism SUPERNOVA uses for in-memory compilation of .NET assemblies. We found that during the compilation process, the native .NET-related utilities CSC.exe and CVTRES.exe are spawned as child processes of the calling process. Passed as arguments to CSC and CVTRES are paths to randomly named temporary files that are used by these utilities during the compilation process. Process tree: https://labs.sentinelone.com/solarwinds-understanding-detecting-the-supernova-webshell-trojan/ Page 7 of 10 Process tree with command lines: - "C:UsersREMDesktoptest_compiler.exe" ----- "C:WindowsMicrosoft.NETFramework64v4.0.30319csc.exe" /noconfig /fullpaths @"C:UsersREMAppDataLo -------------"C:WindowsMicrosoft.NETFramework64v4.0.30319cvtres.exe /NOLOGO /READONLY /MACHINE:IX86 The syntax of these command lines are as follows. CSC: "C:WindowsMicrosoft.NETFramework64csc.exe" /noconfig /fullpaths @"C:UsersAppDataLocalT CVTRES: "C:WindowsMicrosoft.NETFramework64cvtres.exe /NOLOGO /READONLY /MACHINE:IX86 "/OUT:C:Users