We’re nearing the end of the quarter and our team has made serious strides in analyzing our chosen malware samples. With the analysis portion of our capstone project mostly complete, I’d like to share a few of my thoughts on my greatest success from this course.
Reverse Engineering
My biggest breakthrough in our project has been using IDA Free (the free version of IDA Pro) to reverse engineer an executable malware file. The challenge of this particular malware sample stemmed from our initial observations that running the file on its own would result in the malware deleting all traces of itself. Having a bit of experience with reverse engineering, I decided to open up the file in IDA and take a look inside.
One of the first things I noticed upon opening up the file in IDA was that multiple paths lead to a function which seems to run a shell command to delete a file. Presumably this is the culprit for the malware deleting itself when not run correctly – whatever “correctly” means. The next big breakthrough came in noticing that a significant chunk of the file’s functionality is gated by a call to a function which seems to process characters in a string. Upon taking a closer look at that function, it was clear that the malware expects a string ("abcd") to be passed in when executing commands. So now we had found the password required to run the malware! What next?
With a little bit more time and reverse engineering effort, I was able to determine that there are 4 different flags that the malware can be run with (-in-re, -cc, and -c) which respectively install the malware as a Windows service, remove the malware service, print the current malware configuration, and update the malware’s configuration. Testing these commands along with the reversed password in my Windows Virtual Machine revealed that we were making progress on understanding how the malware installs itself and what some of its capabilities are. Further reversing resulted in understanding what the malware could do once it was installed, how it connects to the Command and Control (C2) server, and the format of the commands that the C2 server sends.
Why It Matters
So why go through all the effort to reverse the malware? Without diving into the assembly code, we would never have been able to find the password necessary to install the malware as a service. And while we had previously found the flags as strings, we gained a much deeper understanding of how to use them and what they controlled because of this reversing process. Ultimately, reversing the malware executable using IDA allowed our team to fully comprehend the capability of this malware in a way that simple basic and dynamic analysis could not.
The more personal reason why this work matters, though, is that reverse engineering is the kind of work I expect to be undertaking in my post-graduation job as a cybersecurity researcher. One of the major reasons that I wanted to work on this project was specifically because of the opportunity to perform reverse engineering, and I was excited to finally get that chance.
What I Learned
While I’ve been able to use multiple analysis tools throughout the course of this project, I’ve enjoyed reverse engineering with IDA the most. I’ve grown more comfortable in using the many, many tools that IDA provides (and that’s accounting for the fact that the Free version is already pared down). And from all of the documentation reading I did, I now also feel more comfortable in how Windows system calls work.
My biggest takeaway, though, is just how much more engrossed in the analysis I was once I started reversing the executable. It felt like an irresistible challenge to delve deeper and deeper into the disassembly to suss out what it was trying to accomplish. While other parts of the project were fun, nothing was as addictive as the reverse engineering part, which makes me even more excited for my future.
