A colleague and I reverse-engineered the Clop ransomware binary (with SHA256 hash value2f29950640d024779134334cad79e2013871afa08c7be94356694db12ee437e2), and observed that it contained two obfuscated resources:
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:
]]>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.
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.
]]>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.
It seems like many times when I try to learn something new, I find that I am missing some prerequisite knowledge or skill set that needs to be understood and/or mastered before I can proceed. This humorous comic illustrates this experience.
Be sure to click on the actual comic to advance to the next scene.
]]>