How to use esReven to Reverse Engineer a malware

Let's meet Andrew

Andrew's job is to reverse-engineer malicious files: ransomware, stealers, packers, as well as post-exploitation toolkits and RATs. He has to fully analyze these threats and understand in depth how they deploy, in order to extract knowledge and intelligence: to identify their nature, understand how they relate to other existing malware, and maybe uncover evidence pointing to their group of origin. He can begin by using standard tools such as a disassembler, decompiler, or debugger. However, he frequently faces cases where analyzing the file with these tools is either impossible or impractically time-consuming. Now, using esReverse, he is able to solve even the most complex cases.

How Andrew reverse-engineers malware

In cases involving simple malware, a disassembler or decompiler can handle the malicious file well, and the problem is solved using the standard static analysis approach of code reading.

When facing a more complicated threat, Andrew must add a debugger to the mix. This is usually necessary when it is mandatory to execute the sample in order to analyze it, for example, when the malware's behavior is convoluted or obfuscated, or when its first step is to unpack further stages.

However, this process often becomes excessively complicated and intricate, and the combination of static file analysis, debuggers, and traffic monitor utilities is not enough. This occurs, for example, when:

• The payload is hidden behind numerous complex stages.

• Starting a debugging session of each stage requires multiple manual setup steps, making iteration painfully slow.

• Many iterative executions are necessary, and the malware's server (known as C2) detects this •\ as suspicious, resulting in a ban, limiting or preventing further analysis.

• Analysis of the encrypted communication with the C2 is necessary.

Having to repeatedly deal with these complex situations sparked Andrew's interest in esReven.

Andrew explains in detail:

"A typical case involves reversing the encryption algorithms used in the malware and recovering the C2 communication protocol. An extremely challenging example is reversing the Rhadamanthys stealer^1. The threat from this malware is complex because packers are used, the payload launch kill chain is very long (with a dropper, downloader, and several layers of encrypted shellcodes), the initial stages check the environment for sandboxing and debugging, the code runs in the context of different processes, the payload is loaded dynamically from C2 and encrypted in a picture file steganographically, and so on.

My task is not just to get an unpacked image of the payload (which is not very difficult, although this image won't run), but to be able to debug it and understand every step of the chain. Reversing some of the code fragments further with standard analysis utilities is a difficult, time-consuming task. With standard tools, to reverse the C2 communication protocol or the encryption algorithm for the malware config, you would need to repeat the debugging session from the beginning each time, moving up the call stack and seeing where the data came from in the network packet. Alternatively, you could start a debug session, create an image of the session in the virtual machine, wait for the encrypted data to be sent, move up the call stack, and roll back the image of the virtual machine, repeating this multiple times. esReven allows you to simplify this task --- you only need to create the session once to start the chain of malware and knock to C2. Having created the trace once, there is no need to repeat the debugging sessions, or to repeatedly roll back the virtual machine images.

At the same time, esReven solves a number of other problems: it doesn't require you to recalculate the payload image base each debugging iteration, the encryption keys within the created trace will never change (unlike in debug) which makes analysis very easy, and it solves the problem of payload inaccessibility for repeated requests. This last point is a common problem for downloaders and bankers ---when you debug a downloader (to get a payload) or a bank bot (to get injects), repeatedly re-requesting the next stage from the same machine, it is very likely that the machine will be blocked and won't be given the payload again. This problem is not encountered with esReven, as the trace is created only once and then analyzed, so the test lab doesn't knock any outside machines, and fewer knockouts means less chance of getting the machine banned.

Going back to Rhadamanthys and network protocol reverse engineering: Analysis of this and similar threats is complicated by the fact that they can be packaged, encrypted, written in C++, and contain cumbersome network code in the form of virtual method calls, which are unrealistic to analyze in IDA and difficult to debug. esReven greatly reduces the debugging time by, for instance, tainting the content of an encrypted packet and the references to the functions that send, encrypt, and pack the code fragment. Similarly, esReven very quickly finds the data that was sent to C2 before encryption.

My recommendation for successfully reverse engineering malware is to use esReven in combination with ret-sync and IDA. I have successfully reversed numerous network algorithms this way. esReven software simplifies and accelerates many of the malware analyzer's tasks, such as extraction of configs, finding encryption keys, analysis of encryption algorithms, and reversing protocols."