Reference
I am sure you all saw the news.

2020-12-13 Fireeye 
Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor
2020-12-13 MicrosoftCustomer Guidance on Recent Nation-State Cyber Attacks
 Well, here are the Sunburst binaries. Here is a Sunburst malware analysis walk-through video by Colin Hardyhttps://www.youtube.com/watch?v=JoMwrkijTZ8&feature=youtu.be

Download
             Other malware

Download dlls. Email me if you need the password (see in my profile)
Download Coreinstaller.msi - trojaned installer sample 


Hashes



SolarWinds.Orion.Core.BusinessLayer.dll


32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134a25cadd48d70f6ea0c4a241d99c5241269e6faccb4054e62d16784640f8e53bcce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6d3c6785e18fba3749fb785bc313cf8346182f532c59172b69adfb31b96a5d0af
Trojan:MSIL/Solorigate.B!dhaA Variant Of MSIL/SunBurst.A

This is the compromised installer file ( was still on Solarwinds update downloads  on Dec 14, 2020
File size 419.76 MBCoreInstaller.msi

ad2fbf4add71f61173975989d1a18395afb8538ed889012b9d2e21c19e98bbd1
2020-04-21 17:31:02SolarWinds Orion Core Services 2020.2{77E2D294-3D5C-4D93-ADF1-884CCEAD93B0}File Version InformationDate signed 05:32 PM 04/21/2020SignersSolarwinds Worldwide, LLCSymantec Class 3 SHA256 Code Signing CAVeriSignVT - 0 (Dec 14, 2020)
If you unzip, check 019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134   (36 detections , part of the IOC set)
SolarWinds.Orion.Core.BusinessLayer.dll under OrionCore

This blog entry announces the release of an exhaustive analysis of ComRAT v4. You can find the IDBs here.

More specifically, an IDB for the sample with hash 0139818441431C72A1935E7F740A1CC458A63452, which was mentioned in the ESET report (see especially its attached PDF), and which is available online on Hybrid Analysis. All of the analysis has been performed in Hex-Rays 64-bit, so the results will be less interesting to IDA users who do not own Hex-Rays 64-bit. That is to say, if you open the IDB, you should definitely use Hex-Rays to view the function decompilations, as that is where all of the naming and commenting has taken place. It is rich with detail, in comparison to the disassembly listing's barrenness.

This analysis took roughly six weeks of full-time work. I have spent the pandemic working on a new training class on C++ reverse engineering; part of the preparation includes large-scale analysis of C++ programs. As such, ESET's report of ComRAT's use of C++ caught my eye. ComRAT has a beautiful architecture, and many sophisticated components, all of which I believe deserve a detailed report unto themselves. I had begun writing such a report, but decided that it was side-tracking me from my ultimate goals with my new training class. Hence, I had decided to wait until the class was ready, and release a collection of reports on the software architectures of C++ malware families (perhaps as a book) after I was done. Thus, my write-up on ComRAT's architecture will have to wait. You can consider this release, instead, as a supplement to the ESET report.

(Note that if you are interested in the forthcoming C++ training class, it probably will not be available for roughly another year. More generally, remote public classes (where individual students can sign up) are temporarily suspended; remote private classes (multiple students on behalf of the same organization) are currently available. If you would like to be notified when public classes become available, or when the C++ course is ready, please sign up on our no-spam, very low-volume, course notification mailing list. (Click the button that says "Provide your email to be notified of public course availability".) )

(Note also that I have more analyses like this waiting to be released. FlawedGrace and XAgent are ready; Kelihos is in progress. If you can provide me with a bundle of Careto SGH samples, preferably Windows 64-bit, please get in touch.)

About the Analysis

This analysis was conducted purely statically, without access to RTTI, or any other form of debug information. The only external information I had was the ESET report. I have reverse engineered every function in the binary that is not part of the C++ standard library, and some of those that are. To get an idea of what the sample looks like before and after analysis, here's a screenshot of the binary freshly loaded into IDA on the left, versus the analyzed one on the right. See if you can spot the difference:

Although I believe that the IDB could probably be loaded in versions of IDA prior to 7.5, I nevertheless recommend using IDA 7.5 to view it. The reason for that is because I have made extensive use of 7.5's new "folders" feature to organize the functions and local types windows, which I found massively useful for large-scale reverse engineering. Those two windows have a nearly identical organization; if you were to dock the windows side-by-side, you would see something like this:

As a result of this analysis, I wrote many Hex-Rays plugins, and devised a number of techniques in C++ reverse engineering that were new to me. Eventually, I will publish on topics such as the following:

A Hex-Rays plugin for navigating virtual function cross-references

Reverse engineering STL containers, the easy way

A Hex-Rays plugin for virtual inheritance

Tips for reverse engineering multiple inheritance

Automated creation of VTable structure types

Automation for detecting inlined functions, and the addition of stock comments

ComRAT uses a lot of C++ features; a mostly complete list follows. If you're interested in learning how to reverse engineer C++ programs, you might do well to study how I analyzed the parts of the binary that interact with them.

Inheritance

Polymorphism (virtual functions)

Custom templates

Multiple and virtual inheritance (due to iostreams)

STL, listed in descending order of usage frequency:

shared_ptr

vector

string

wstring

locale

unique_ptr

wstringstream

stringstream

fstream

list

map

regex

wstring_convert

random

Notes on the Sample

Although the use of Gmail as a covert channel was a major aspect of the ESET report, I could not get my hands on any samples that had that feature. However, this sample does contain some of the Gmail communication code -- the Gumbo library is compiled into it, and the configuration in the virtual file system contains a "mail" subdirectory, with similar entries to those in the ESET report. Perhaps that feature was still in development, or was deliberately not compiled into my sample for whatever reason.

One striking feature of the ESET report was that their sample had RTTI information compiled into it, which provided the names of many of the classes used within ComRAT. I.e., section 4.3 of the ESET report mentions specific class names, as created by the ComRAT programmers. However, my sample had no such RTTI information. Therefore, all of my analysis had to be done from scratch. I used the few names provided in the report as a guide when creating my own.

To the extent I was able to verify their claims, everything in the ESET report is accurate. There are a few minor technical details in my sample that were different, but are barely worth mentioning, and might have legitimately changed between the creation of my sample and the non-public one they analyzed.

Today I discovered a neat optimization that I'd only heard about in graduate school, but had never seen in a real binary. Although the code below involves virtual functions in C++, the same technique would work for ordinary function pointers in C. A few other optimizations are referenced in the explanation below; all of them can be found in my presentation, "Compiler Optimizations for Reverse Engineers", which is the course sample for one of my reverse engineering training classes.

The optimization has to do with increasing speculative execution performance for function pointers that nearly always target one particular destination. Note that this is in contrast to the compiler optimization known as "devirtualization", which is when a compiler can prove that a particular function pointer invocation must always target one particular location, and turns the indirect call into a direct one. The optimization described in this entry differs in that the function pointer might nearly always point to one location, but might occasionally point elsewhere. (These estimates of runtime behavior could be derived through profiling, for example.)

The following is a snippet of code that comes from Microsoft's Active Template Library (ATL). More specifically, the smart pointer known as CComPtr, held in atlcomcli.h. Here is the code; modest, and unassuming:

template class CComPtr { T* p; // Release the interface and set to NULL void Release() throw() { T* pTemp = p; if (pTemp) { p = NULL; pTemp->Release(); } } }

Being a template class library, the programmer is free to create their own classes based on CComPtr by specifying any class type for the template typename parameter T. Or rather, any class type that has a method named "Release" with signature "void Release()", as that function is invoked by the if-body in the code above. In this scenario, Release is a virtual function — that is to say, objects of type T contain a function pointer pointing to the implementation of a function called “void Release()”.

In the code below, T is specialized by (i.e., replaced with) a scary-looking ATL type name called ATL::CComObject. So in particular, here is the compiled version of CComPtr>::Release, whose generic C++ code was shown above.

The first four lines aren't interesting:

.text:18005121B mov rcx, [rcx] ; T* pTemp = p; .text:18005121E test rcx, rcx ; if (pTemp) { .text:180051221 jz short return ; [if not taken, return] .text:180051223 and qword ptr [rax], 0 ; p = NULL;

The final line, the call to pTemp->Release, has a longer compiled body than one might expect. A line-by-line explanation follows below.

.text:180051227 lea rdx, offset ATL::CComObject::Release .text:18005122E mov rax, [rcx] .text:180051231 mov rax, [rax+10h] ; rax now contains the pTemp->Release pointer .text:180051235 cmp rax, rdx ; did rax match the fixed location in rdx above? .text:180051238 jnz short no_match .text:18005123A call ATL::CComObject::Release .text:18005123F .text:18005123F return: .text:18005123F add rsp, 28h .text:180051243 retn .text:180051244 .text:180051244 no_match: .text:180051244 add rsp, 28h .text:180051248 jmp rax

To explain the code above:

Line #-27: move the offset some specific function into rdx.

Line #-2E through -31: rax now contains the pTemp->Release function pointer.

Line #-35 through -38: Compare rax and rdx. If equal, don't take the jump.

Line #-3A through -43: Invoke ATL::CComObject::Release(pTemp). The important thing to notice is that the function being called is the same one whose offset was moved into rdx on the first line.

Line #-44 through -48: If rax had not been equal to rdx, call the function pointer in rax. (More precisely, jump there after destroying the stack frame, as the result of an optimization known as tail call elimination.)

Reflecting on the code above, it might seem weird that it:

Compares a function pointer to the address of a known function, let’s call it X.

Calls the known function X directly if it matches.

Calls the function pointer if it doesn't.

In other words, If the function pointer does match X — regardless of the comparison and direct call — then X would be the function invoked anyway by part #3. The indirect call in part #3 is sufficient; parts #1 and #2 would seem to be superfluous. Moreover, we can clearly see that this behavior was not present in the original C++ code: it was introduced by the compiler. Therefore, why would Microsoft Visual C++ — an otherwise heavily-optimizing compiler — insert the comparison and direct call?

What's happening here is that indirect calls are worse for the processor's speculative execution, since the processor needs to know where the call is going before it can start executing it. Direct calls have better performance, because their destinations are fixed and known. Technically, the virtual function call to Release() could go anywhere -- it is a function pointer, after all. However, because the template is specialized for the type T = ATL::CComObject, it's reasonable to expect that the virtual function will actually point at &ATL::CComObject::Release. In fact, profiling might determine that this is the destination on all, or nearly all, of the profiling data. So by performing an explicit comparison, we allow the processor's speculative execution to begin executing the probable destination before the real, runtime destination is known. As a result, if the virtual function usually points where we expect, we’ll get better speculative execution success, and hence better performance.

There's another neat aspect to the code above, also involving speculative execution. Notice that the jump after the comparison on lines #-35 through -38 is in the forward direction. The Pentium 4+ static branch prediction algorithm assumes that jumps that go in the forward direction won't be taken. Therefore, the compiler arranges the indirect function call to be at the end of a forward branch, which encourages the processor to speculatively execute the direct call target on the not-taken side instead of down the path with the indirect call.