If I was still with CERT/CC, I know I'd be patiently awaiting the teardown analysis of that DLL. I bet it's an interesting bit of code. I remember being shown the clever obfuscations through JMPs that many mal-devs put in their code to remain harder to decode intention & methods.

To note, the CISA report here does remind me of the stuff we used to do on more impactful incidents. I'm appreciating the detail and what you can learn from those code segments about what they were doing. Highly advise folks to read that link @ericgeller included.

What would be very interesting, and I know doubtful, but maybe @C_C_Krebs & @alexstamos can convince their client to do so, since we're talking transparency... is to show the "before" & "afters" of where in the overall codebase these actually sat from the source code in Orion.

Note to @CISAgov & @USCERT_gov the report has some HTML element translation issues (such as "&lt;&lt;" instead of <<) which hurts some readability.

Also, if any enterprising person may want to annotate some of the functions... those hashes is say "UploadSystemDescription Function" could do well with linking, rather than hopping around the doc.

That custom Base-64 alphabet is clever AF.

I'm wondering how the malware/trojan may have dealt with updating some of the blocked processes/commands/features if they were updated/replaced/modified during an upgrade (such as AV or OS updates), & how they were tracking that over the period. Seems a pretty static hash list.

I'm guessing what I'm getting at that if the hard-coded block list existed, it should have been present in SolarWInd's own build repo... & they sacrificed some stealth by letting that possibly not get updated in these cases, but if they were updated.... 1/2

why wasn't that detected in the source control/QA management side of SolarWinds' own build and analysis. I do wonder what their CI/CD pipeline looks like, are they doing any major change analysis, smoke testing before releases & diffs?