Challenge: https://app.hackthebox.com/sherlocks/Lovely%20Malware

An employee at NeirCyber Security discovered a suspicious file named employee_benefits.exe on their desktop. The employee found the file after returning from lunch and immediately reported it to the IT security team, suspecting that it could be malicious. The objective is to reverse engineer the file and dissect its inner workings. This is a warning that this Sherlock includes software that is going to interact with your computer and files. This software has been intentionally included for educational purposes and is NOT intended to be executed or used otherwise. Always handle such files in isolated, controlled, and secure environments. One the Sherlock zip has been unzipped, you will find a DANGER.txt file. Please read this to proceed.

Introduction

We are provided a ZIP file with four files, Attachement.txt.naso, cap.pcapng, DANGER.txt and the malware Update.exe nested inside malware.zip.

To start, I launched my fresh snapshot of Win10 VM post FlareVM install, and disconnected network. The attachment is encrypted, I assume this must be the final challenge of reversing the program to pull decryption keys so we can decrypt the file and get the SHA256, so we will revisit it later.

Conclusion

The first 13 parts of this challenge were rather easy to me. I was able to grab them with relative ease by just using online sandboxes and tools like VirusTotal. However the real challenge was being given a file encrypted by the ransomware, and being told to decrypt it. It required intense reverse engineering of almost every function I could find, over 160 functions in total. Every time I finally figured out one function, there may have been 3 or 4 child functions inside of it that called on encrypted strings that needed to be reversed as well to paint the whole picture. This binary made large use of api hashing, so all of the calls utilized from external libraries were actually not visible from tools like Detect it Easy and required finding the actual function call where it then would live decrypt the string and call the relevant library.

It took me 4 or 5 days of solid reverse engineering to get a good enough picture to determine where to actually begin looking for the encryption key and how it worked. And even once I finally thought I had it, the file itself still had one last trick up its sleeve before allowing the key to work properly.

This definitely was an insane challenge that led to many late nights, but I learned an incredible amount.