Deobfuscating Clop ransomware resources

A colleague and I reverse-engineered the Clop ransomware binary (with SHA256 hash value
2f29950640d024779134334cad79e2013871afa08c7be94356694db12ee437e2), and observed that it contained two obfuscated resources:

  • SIXSIX
  • SIXSIX1

One of them is just the README file that the malware drops all over the disk, so nothing too exciting, but the other is a batch script that deletes the volume shadow copies. Granted, you could just debug it and get it to drop these files, but as a personal challenge I decided to write a deobfuscator based on my analysis of the decompiled code (I looked at it in both Ghidra and IDA Pro, the latter of which was much more helpful in this case). After spending a bit of time labeling each variable/function, this is the relevant decompiled section of code:

Learning a new programming language: Grokking syntax vs. paradigms

My journey thus far

I began programming in middle school in BASIC on a Radio Shack TRS-80 (“Trash 80”) that ran using two 5.25” floppy disks (to be fair, you pretty much had to learn BASIC in order to use the thing). I’m not that old, we simply didn’t have much money growing up so I got ancient computers from places like the Goodwill (the kind that were so old and junky people literally gave them away). I was lucky to have a neighbor/babysitter that taught me the foundations of BASIC, and one of the benefits of learning old tech was that the (typically outdated) library books covered everything I was learning!

Fast-forward more than two decades later and my journey has taken me from various flavors of BASIC all the way through HTML, CSS, JavaScript, PHP, Python, C, C++, SQL, C#, and more. Recently I decided to learn Go. I was torn between beginning to learn Rust or Go, but for reasons that I’ll spare you from, I ended up choosing Go.

Some reminders about Windows file times

This information is covered in introductory courses on Windows/NTFS forensics, but I often lose track of the original source for technical information that I can cite in expert reports and other deliverables. Also, I’m not a fan of citing proprietary training materials that can’t be easily found on the web, purchased from Amazon, or found in a public library.

Big RAM and the kernel debugger data block

I recently was provided with a 64GB raw memory image created by the free DumpIt tool from a Windows 2012 R2 x64 server. To my dismay, neither Volatility nor Rekall could make heads or tails of it. After debugging a little further, I discovered that neither tool was able to find the kernel debugger data block (_KDDEBUGGER_DATA64) structure.