LetsDefend — Revenge RAT Challenge Walkthrough
A Malware Reverse Engineering Challenge Using Detect-It-Easy, dnSpy, & Google
Introduction:
Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a walkthrough of the Revenge RAT challenge from LetsDefend, you’re in the right place.
In this scenario, we’re going headfirst into the world of malware reverse engineering. An incident response team provided us with a Remote Access Trojan (RAT) malware sample used during an attack on a fictional organization. Our job is figure out what the malware was compiled with, how it’s configured, and what it does.
To analyze the sample logs, we’ll leverage dnSpy, a .NET debugger, and compare our analysis with some external research about the malware and its functions to give us comprehensive view of the attack. I’m still a newbie with my own reverse engineering skills, so we’ll have fun piecing this together. Let’s get into it!
And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!
Thanks for reading and going on this investigation with me!
Challenge Link: https://app.letsdefend.io/challenge/log-analysis-with-sysmon
Challenge Scenario:
An attack on a company employed a Remote Access Trojan (RAT) disguised in seemingly harmless files. The RAT infiltrated the network and operated as fileless malware.
DFIR analysts have extracted the malware. Now they need you to analyse the sample and uncover its secrets. By dissecting the binary, we can understand its behaviour, assess the damage, and devise a strategy to eradicate the threat, ensuring the organization’s security.
Question 1: What compiler is used for this sample?
All right, let’s kick off our investigation! The first thing we’ll do is extract the sample.7z from the ChallengeFile folder and reveal the sample file — f6b2c58f9846adcb295edd3c8a5beaec31fff3bc98f6503d04e95be3f9f072e8
Next, it’s always a good idea to get familiar with what tools are available for use within the Tools folder. This is especially helpful for me since I’m still working to level-up my malware reverse engineering skills.
Now that we have extracted the sample file and have gotten an overview of our tools, let’s start performing some analysis on the file.
To answer Question 1, we’ll first need to understand what type of file the sample is so that we can determine the best tool for analysis. To do this, let’s gather some information using Detect It Easy (DIE) which is a useful utility to identify the file type of a binary. We’ll launch this utility from the Tools folder, then point it to the sample file.
Once analyzed by DIE, we’ll see a few key details that answer Question 1. The sample binary is .NET-based and compiled with the Visual Basic (VB.NET) compiler.
Question 2: What is the mutex name checked by the malware at the start of execution?
All right, now we’re getting into the meat of the challenge.
In the previous question, we’ve determined that the malware is .NET based, so we should be able to use some of the .NET decompilers from the Tools folder. While I’ve used JetBrains dotPeek in the past, I want to expand my horizons and try out a new tool this time.
Only one problem, I’m not familiar with any of the other available tools. So, let’s back up and do some Google research. But instead of searching for .NET decompilers, why don’t we first see what research is available about the Revenge RAT? By doing this, I stumbled across an excellent blog from Perception Point containing some helpful information about the malware.
It’s so helpful in fact, that we’ll refer to it throughout the walkthrough to corroborate our findings. But most importantly for this task, it gives us an idea of a tool that we can use to view the sample’s code — dnSpy.
we can open the executable in DnSpy and view the code. Surprisingly, this malware’s code is readable and not obfuscated.
Sounds like this will fit the bill, so let’s jump into the dnSpy. Once the sample is loaded, we can start with the analysis. Inside dnSpy we’ll immediately see something identical to Perception Point’s infographic — the executable name Client.exe with the Lime namespace below.
Let’s expand the Program class node and check out the Main() method as a starting point. There are references to mutex in a couple of spots. It seems that once the malware creates the mutex, it pulls the name from the Config class. Let’s check this out by clicking on currentMutex.
This jumps us directly into the Config class which holds some interesting configuration strings including the name for the currentMutex. This should be the string that we need to answer Question 2!
Question 3: What function was used to get information about the CPU?
For Question 3, instead of stumbling through the code blindly, let’s refer back to the Perception Point research to get some direction. Their research states:
Now that we have some idea of what to look for, let’s verify if we see the same result within our sample. Expand all the namespaces to locate the IdGenerator class beneath Lime.Helper.
Here we’ll find several methods that appear to be collecting identifying data about the victim’s device — I’ll take a wild guess that GetCPU()is responsible for gathering information about the device’s CPU.
After a quick review, we can confirm the answer for Question 3. We’ll see that this function collects CPU information from the device’s Windows registry.
Question 4: What key was used during the “SendInfo” function?
Now, let’s navigate to the SendInfo()method, also under Lime.Helper , and locate the references to the key variable. If we click it, we’ll be taken back to the Config class where we can see the string we’ll need to answer Question 4:
Question 5: What API was used by the malware to prevent the system from going to sleep?
From the previous questions, you may have already noticed another conveniently labeled class under Lime.Helper called PreventSleep. This sounds like exactly what we are looking for!
Once we click into the Run()method, we can see a call being made to the SetThreadExecutionStateAPI:
To confirm that this is correct, we’ll check the Microsoft Learn page for this function where it states:
Enables an application to inform the system that it is in use, thereby preventing the system from entering sleep or turning off the display while the application is running.
There we go! Thanks to the convenient labeling and some external research, we’ve confirmed that we found the answer to Question 5.
Question 6: What variable stores the volume name and the function that imported the “GetVolumeInformationA” api?
To answer Question 6, we’ll need to search for a specific variable that stores the volume name retrieved by the GetVolumeInformationA API.
For some context, let’s turn back to Microsoft Learn, where it’s documented that this function “Retrieves information about the file system and volume associated with the specified root directory.”
So, to find this reference in the sample, let’s simply leverage dnSpy’s search function and use the keyword GetVolumeInformationA. The search leads us to Lime.NativeMethods > Native > GVI.
While I’m no coding wizard, it appears that within the GVI method, the GetVolumeInformationA function is imported from kernel32.dll and called. Then, the volume data retrieved by this function is stored in the IP variable.
Question 7: What function was used to retrieve information about installed video capture drivers?
For Question 7, we need to look for a function that collects information about the victim’s video capture (aka camera) drivers. For this, let’s circle back to the IdGenerator class under Lime.Helper where we found the answer to Question 3.
There we’ll find a GetCamera() method. While this seems like a good match based on the name, let’s double-verify this again with Microsoft Learn which states that:
The capGetDriverDescription function retrieves the version description of the capture driver.
Question 8: What is the value of the ID after removing obfuscation?
We’ve made it to the last question! To answer Question 8, we’ll jump back to the Config class where already found the answers to Questions 2 & 4, this time focusing on the id string.
The question tells us that the value is obfuscated (likely in Base64), so we’ll need to decode it to find the answer. To do this, we’ll use CyberChef from Tools folder to perform some operations on the string. Just paste the value into the input box and add “From Base64” to the recipe:
Easily enough, we’ve decoded the string and have uncovered the answer to Question 8! Now let’s wrap up this analysis.
Conclusion:
Mission accomplished! Using Detect-It-Easy, we figured out that the malware binary was compiled with VB.NET and then discovered some external research about the RAT from Perception Point to add some context to the investigation. Then, we brought the malware sample into dnSpy to uncover details about the information it collects about a victim’s system and how these functions work from Microsoft Learn. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the Revenge RAT!
A big thank you to LetsDefend, for yet another engaging and challenging lab! I tend to stumble through reverse engineering challenges since I do not have a coding background and even the terms can be confusing! Even so, I always try to push myself to learn about new things outside of my comfort zone by tackling unfamiliar topics. Fortunately, the power of research helped me understand the bigger picture of the malware, allowing me to analyze it more confidently. Overall, this lab was a great learning opportunity, especially getting some hands-on time with dnSpy and expanding my toolset. Practice makes perfect, after all!
Thanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don’t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we’re in this together!
Until next week’s challenge — stay curious and be safe out there!
Tools & References:
Wikipedia (Visual Basic (.NET)): https://en.wikipedia.org/wiki/Visual_Basic_(.NET)
dnSpy: https://github.com/dnSpy/dnSpy
Perception-Point: https://perception-point.io/blog/revenge-rat-back-from-microsoft-excel-macros/
Microsoft Learn — SetThreadExecutionState: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadexecutionstate
Microsoft Learn — GetVolumeInformationA: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationa
Microsoft Learn — capGetDriverDescriptionA: https://learn.microsoft.com/en-us/windows/win32/api/vfw/nf-vfw-capgetdriverdescriptiona
CyberChef: https://gchq.github.io/CyberChef/
