SUPERNOVA - Additional Orion Compromisation?

I've been seeing articles as of last night discussing SUPERNOVA, an additional supply chain attack likely originating from a different APT than SUNBURST. This one comes in the form of a .NET webshell implanted in the App_web_logoimagehandler.ashx.b6031896.dll file and programmed to hijack the Orion HTTP API and listen for specific API parameters, then compile and execute .NET code in memory using the runtime on the Orion host. Per the article,

"The attacker may send a request to the embedded webshell over the internet or through an internally compromised system. The code is crafted to accept the parameters as components of a valid .NET program, which is then compiled in-memory. No executable is dropped (and thus the webshell’s execution evades most defender endpoint detections), and the compiled assembly immediately invokes the specified class method."

I'm assuming SolarWinds is already aware of this additional supply chain breach -- but the only mitigations I'm finding in the article point to Palo Alto antivirus definitions that can detect the compromised DLL. Are other mitigations available? Are Orion customers who've installed the latest 2020.2.1 HF2 hotfix for SUNBURST protected from this compromise also?

Find more posts tagged with

Accepted answers

All comments

tsadler

For anyone else reading this and asking the same question, I did a bit of digging on my own. According to the Palo Alto article, the DLL file in question is located on any Orion server running IIS web services. It's located under C:\inetpub\SolarWinds\bin and has four command-and-control API parameters added to it that the hijacked API will listen for:

Through some research, I found dotPeek by jetbrains that allows you to decompile .NET DLL files. Opening up the App_web_logoimagehandler.ashx.b6031896.dll file in dotPeek, I was able to look at the API parameters. Once inside the DLL, navigating to <Root Namespace> and LogoImageHandler.cs will show the area commonly altered by the attack.

According to Palo Alto, a benign, unaltered DLL will look like this:

Whereas a compromised DLL will show the listed additional API strings under the ProcessRequest() method as shown here:

Thankfully, in our case, the DLL on our MPE appears to be unaltered:

Image 2078.png

Thankfully, our MPE and both of our Additional Web Servers appear to be clean. Anyway, hope this helps anyone else who's looking at this.

dsproc

Good news that in your case DLL wasn't compromised.

Just wondering if SWinds perhaps via TAC case can decrypt the DLL and also confirm if there is any patch or firmware upgrade that would prevent this scenario ?

Regards,

DSP