Rony Moshkovich
Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam.
Tags
Share this article
12/15/20
Published
Update: Next two parts of the analysis are available here and here.
As earlier reported by FireEye, the actors behind a global intrusion campaign have managed to trojanise SolarWinds Orion business software updates in order to distribute malware.
The original FireEye write-up already provides a detailed description of this malware. Nevertheless, as the malicious update SolarWinds-Core-v2019.4.5220-Hotfix5.msp was still available for download for hours since the FireEye’s post, it makes sense to have another look into the details of its operation.
The purpose of this write-up is to provide new information, not covered in the original write-up. Any overlaps with the original description provided by FireEye are not intentional.
For start, the malicious component SolarWinds.Orion.Core.BusinessLayer.dll inside the MSP package is a non-obfuscated .NET assembly. It can easily be reconstructed with a .NET disassembler, such as ILSpy, and then fully reproduced in C# code, using Microsoft Visual Studio. Once reproduced, it can be debugged to better understand how it works.
In a nutshell, the malicious DLL is a backdoor. It is loaded into the address space of the legitimate SolarWinds Orion process SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe.
The critical strings inside the backdoor’s class SolarWinds.Orion.Core.BusinessLayer.OrionImprovementBusinessLayer are encoded with the DeflateStream Class of the .NET’s System.IO.Compression library, coupled with the standard base64 encoder.
Initialisation
Once loaded, the malware checks if its assembly file was created earlier than 12, 13, or 14 days ago. The exact number of hours it checks is a random number from 288 to 336.
Next, it reads the application settings value ReportWatcherRetry. This value keeps the reporting status, and may be set to one of the states:
New (4)
Truncate (3)
Append (5)
When the malware runs the first time, its reporting status variable ReportWatcherRetry is set to New (4).
The reporting status is an internal state that drives the logic. For example, if the reporting status is set to Truncate, the malware will stop operatin