The actors behind SolarWinds’ supply chain attacks on Orion software have shown a combination of innovative techniques in potential breaches of approximately 18,000 SolarWinds customers , in addition to advanced technical sophistication and operational security considerations. I did. The attacker has been observed to remove the first backdoor after obtaining a more legitimate persistence method, as shown in the disclosure from the original source .
In the analysis of Trojanized Orion artifacts, .NET .dll app_web_logoimagehandler.ashx.b6031896.dll was called SUPERNOVA, but the details of its operation are rarely published.
Note: The relationship between the SUPERNOVA web shell and the SolarStorm actor is different from the SUNBURST .dll, which raises doubts because the above .dll is not digitally signed. This suggests that the web shell, like SUNBURST, was not implanted early in SolarWinds’ software development pipeline, but may have been dropped by a third party. Guidepoint Security has also independently investigated SUPERNOVA and reached similar conclusions.
This article describes its operations, functional overview, tactics and techniques that support the Advanced Persistent Threat (APT) hypothesis, and the protection we provide for Trojanized SolarWinds instances.
- The attacker created a sophisticated in-memory web shell built into the Orion code. It acts as an interactive .NET runtime API.
- Web shell payloads are compiled on the fly and run dynamically, making endpoint and digital forensics, Incident Response (DFIR) analysis more complex.
- Added signature 83225 for anti-spyware to prevent SUPERNOVA traffic.
In traditional web shell attacks, these server-side script pages are often some form of interactive front-end document that can be used to handle back-end side effects, most of which are some form of remote code execution (RCE). .. By targeting misconfigurations and vulnerabilities in the underlying server, web shells could be uploaded, downloaded, deployed, or dropped after an exploit as a means of secondary persistence. The web shell itself is usually malware logic embedded in script pages, most of which is implemented in an interpreted programming language or context (most commonly PHP, Java JSP, VBScript / JScript ASP, C # ASP.NET). It has been. The web shell receives commands from the remote server and runs in the context of the underlying runtime environment of the web server.
SUPERNOVA’s web shell also seems to be designed for persistence, but its novelty goes far beyond the traditional web shell malware that the Unit 42 team encounters on a daily basis in research.
Although .NET web shells are relatively common, most publicly researched samples incorporate command and control (C2) parameters and perform relatively superficial exploits. For example, an attacker might order the implant to dump directory structure or operating system information, or call back to the network to load more exploit tools.
SUPERNOVA differs dramatically in that it takes a valid .NET program as a parameter. .NET classes, methods, arguments and code data are compiled and executed in-memory. Unlike the low-level web shell stager, there are no additional forensic artifacts written to disk and no additional network callbacks are required other than the first C2 request.
In other words, the attacker has built a stealth, full-fledged .NET API embedded in the Orion binary. And users of this Orion binary usually have a high degree of privilege and high visibility into the organizational network. An attacker could use malicious C # code to optionally configure SolarWinds (and local operating system features on Windows exposed by the .NET SDK). This code is compiled on the fly and executed dynamically while benign SolarWinds is running.
This means that an attacker can deploy a fully-featured (possibly highly sophisticated) .NET program during the attack phase, such as reconnaissance or horizontal deployment, which is very important.
The implant itself is a Trojanized copy of app_web_logoimagimehandler.ashx.b6031896.dll, a proprietary SolarWinds .NET library that exposes the HTTP API. The function of this endpoint is to respond to queries to specific .gif images from other components of the Orion software stack. The relatively high-quality code implemented in a benign .dll is harmless and can easily be overlooked by defenders’ automated processing and even manual reviews.
An attacker is taking advantage of this benign file by adding four new parameters to the API and a malicious method that executes the parameters in the context of the .NET runtime on the Orion host. Figure 1 below shows the normal or benign content of the Orion component.
Figure 1 Benign SolarWinds code for handling HTTP requests and their responses
Line 42 defines a collection of parameters supplied to the HTTP endpoint, in which only the id is valid and processed. However, before this snippet , the C2 parameter was added in the same method ProcessRequest () , and the execution method was added to this same file. Figure 2 shows some of the malicious code (lines 27-41).
Figure 2 Four C2 parameters are processed and passed to the malicious method DynamicRun ()
The four parameters depicted above, codes, clazz, method and args, are passed to the Trojanized logo handler component via the GET query string. These parameters are then executed within a custom method, which is different from the typical web shell behavior of simply calling a function in the underlying operating system or programming language.
|clazz||C # class object name to instantiate|
|method||Method of class clazz to call|
|args||Divide the argument with a newline and pass it to the method as a positional parameter|
|codes||.NET assembly and namespace for compilation|
Table 1 Command & Control Parameters
Attention to defenders:
Inbound traffic to logoimagehandler.ashx , which has a combination of these four parameters in any order in the query string, is a powerful indicator of compromise (IOC). If this combination causes detection in any order, immediately isolate and image the Orion instance. If the request comes from inside the network, the user who initiated the request is also likely to be compromised.
An attacker could send a request to an embedded web shell over the Internet or via an internally compromised system. This code is designed to accept parameters as a component of a valid .NET program and then compile in-memory. The executable is never dropped (thus, running the web shell avoids finding most defending endpoints), and the compiled assembly immediately calls the specified class method.
The addition of a try / catch block starting on line 27, including the execution on line 37, is probably an unnecessary scrutiny by preventing operator errors from raising unhandled exceptions in Orion. I suppose I’m trying not to invite. This is a small example of an actor’s technical and operational attention to security.
Figure 3 DynamicRun () compiles C2 parameters into .NET assembly in-memory
On lines 106 and 107, you can see the harmless compiler API flag being diverted to the defender’s sabotage. Line 115 instantiates the class object specified by the attacker, and line 116 executes the attacker’s code.
This design pattern is known as dynamic code execution. In the context of software engineering, this allows programs to be flexible and extensible, but in the context of cyber attacks, the same is true for attacker code and tools.