In this article, I give you an example of how malware is hiding through packer techniques to prevent getting caught on your systems. For that, I have recorded a small ‘adventure’ for you that I took last night.

Here it goes:

In an environment that is auditing Attack Surface Reduction rules, I ran the following Microsoft Threat Protection (MTP) Query:

Which – among others- returned an entry for a .js file which was downloaded. I wasn’t able to grab that .js file, but in the timeline of the Machine in Microsoft Defender ATP (MDATP), I saw the following entry, right after the ASR-Audit:

So, probably the .js file downloaded this .txt file. Luckily I could download the .txt file and I then directly uploaded it to VirusTotal:

Ok, nada. Let’s take a closer look at the file:

Hm, a lot of ~ in there. When you now look at the command line from the event graph above, you will recognize that they are replacing ~ with nothing:

(Get-Content wznwsvxvfdh.txt).replace(‘~’,”)

I did this with the ultimate power of Notepad and got something like this:

Let’s see what VT says about it now:

Better – not good. So next, I had to decode the base64 string that we found in the first line of the ~-free txt file. The most convenient way for me to do that is in Terminal/WSL Ubuntu:

Still, the result didn’t look very readable:

It looks like this will be a long night. Anyway – at the end of this encoded block, I found this:

Ok, they are reading this encoded block, base64 decode it (again!) and then de-compress it. They then cut some stuff off by selecting only certain bytes and then take it and load it as an assembly.

They are skipping the step of creating a .dll on disk to get not caught by that. Instead they are loading the assembly on the fly from the data in the variable.

Finally, they call a function in this assembly called “setup()”.

I wanted to investigate the content of the .dll more closely, so I needed to write it’s content to a file:

I cut off the call of the ‘Setup()’ function and executed the rest of the PowerShell script. With that, I had the ‘assembly’ in $UnFiBy.

Now, to create a dll I did:

$unfiby | set-content out.dll -Encoding Byte

Et voilà, I had a fresh .dll which I uploaded to VirusTotal:

Aha. We are getting closer. I then opened the .dll in a disassembler which immediately told me that the .dll consists of .net code. With that I could use DotPeek to decompile the code, which I did.

I found the setup() function and … this:

Another base64 encoded string but this time it was reversed in addition.

I copied the string to a txt file called ‘rev.txt’ and worked on it with PowerShell:

$t=gc .\rev.txt
$ca=$t.ToCharArray()
[array]::Reverse($ca)
$decoded = [System.Convert]::FromBase64CharArray($ca,0,$ca.length)
$decoded | set-content another.dll -encoding byte

After reading it, I reversed it character by character, then base64 decoded it (did I say AGAIN??) and finally wrote it to a .dll file.

Guess what’s next? Yes, I asked my friend VirusTotal:

Finally, this is the actual malware now with all the additional packer stuff pealed off.

VirusTotal told me then it was Sodinokibi Malware, that I found somewhere in the wild, a not-so-nice ransomware thing that has some interesting background.

It was interesting to see what those packers do, to hide the Malware and how more and more AV engines detected it, the more packer stuff I pealed off.