SnakeKeyLogger Malware Analysis
Normally, it is easier to analyze .NET variants of this malware since there is nearly no obfuscation (maybe some simple encryption and variable names). So I decided to analyze a C++ compiled binary around 1MB instead. After checking the binary graph and anti-debug techniques, I found that the only protection they implemented is checking "IsDebuggerPresent" - there's nothing else. Everything is quite clear, so I'll just list the key points of the malware.
The first time I opened the malware in Ghidra, what was most interesting to me was that there were a lot of API imports, and none of them were hidden or obfuscated. I decided to check one of the APIs, found a reference to it, and traced back to see where the call originated from - and I hit the jackpot.
The Function at `0x414800`
Normally, it is easier to analyze .NET variants of this malware since there is nearly no obfuscation (maybe some simple encryption and variable names). So I decided to analyze a C++ compiled binary around 1MB instead. After checking the binary graph and anti-debug techniques, I found that the only protection they implemented is checking "IsDebuggerPresent" - there's nothing else. Everything is quite clear, so I'll just list the key points of the malware.
The first time I opened the malware in Ghidra, what was most interesting to me was that there were a lot of API imports, and none of them were hidden or obfuscated. I decided to check one of the APIs, found a reference to it, and traced back to see where the call originated from - and I hit the jackpot.
As you can see, there's an "if" statement. Why? Initially, it actually initializes the struct of the functions. Luckily, all of them have clear names, so it's easy to understand what they do. After initialization, other functions can search for function names one by one and find the functions they need.
The malware also gives us a hint about what these are. If you search for references to "IsDebuggerPresent", you will find:
Funny, right? The malware literally tells us everything we need to know. This is an AutoIT script. If you're wondering what that is, it's used for automation processes using keyboard and mouse movements, etc.
Note: You can also patch IsDebuggerPresent and debug without any issues, or just use ScyllaHide.
Note 2: I also forgot to mention that in the "strings" of the malware, you can easily see BACKSPACE, ESC, mouse-related strings, numpad, etc. - strings that are related to date/time and similar functions.
Analysis Summary
What we've discovered so far is that the malware is a keylogger and botnet. There may be more functionality that I missed, but I believe I captured everything significant.
Function Call Order Analysis
To understand the order in which the malware calls functions, I found a technique that you can also automate with r2 or x32dbg scripts:
First, we put a breakpoint at 0x414800. After the breakpoint is hit, you'll see the value in the stack is "0x0", indicating this is only for the initialization stage. Continue one more time and check the call stack - the call is from 0x41C64A.
Obviously, this function searches for specific function names. If you put a breakpoint at _wcscmp (0x41C654), you can see every function it tries to search for, and you may even be able to trace into the functions for more detail.
I believe this covers the essential aspects of the SnakeKeylogger analysis.