Reverse engineering Infostealer.Dyre

Question

I'm a newbie to malware analysis and reverse engineering in general. I got hold of a Dyre malware sample from theZoo on GitHub and I've been trying to analyze it.

I've put up my analysis report here. I looked up Symantec's report on the same malware family here. They've some additional information on the remote IP addresses that the malware connects to.

When conducting dynamic analysis, I could see on Wireshark that the malware is trying to get the resource: /cho1017/W512600.52818BB853DEE114E367C21952160412/5/pub.... My VM was not connected to the Internet, so I don't know what that resource actually is. I'm not sure if that can be simulated with INetSim.

Can static analysis help to identify the IP addresses mentioned in Symantec's report? I've been trying static analysis but I'm lost. Although I know what static analysis entails, I'm having a hard time understanding how to proceed from the start area of the code and look for network related code.

If any one has experience with this malware family, any help would be appreciated. Also, if possible I'd like to know the quality of the analysis report that I've put up. I'd like to make sure that I'm writing malware analysis reports the right way.

Answer 1

Static malware analysis can be rather straightforward.

The first step is finding the core code component. Malware usually unpacks itself, creates new processes, writes shellcode to processes and so on, so the first task is finding the final payload to analyze.

This is roughly what unpacking entails. It's also where a lot of public blogposts stop but in reality, nobody cares about the packer used for malware and I'm always confused why people write about the 5 outer layers which will most likely be different 2 hours later when the new build is distributed.

Once you located the main component (likely some injected thread/code block in explorer.exe or something) you load it into IDA. Sometimes it's a full PE file, sometimes you just find a "shellcode" block, doesn't matter.

The next two steps are:

• Getting the imports
• Getting the strings

Malware almost never uses static imports via the IAT so even if you have a full PE file, odds are you don't actually see what APIs the malware uses. So then you will have to find how and where the malware resolves its important dynamically. This usually happens around the entry point so look around there.

And the same goes for strings. It's very likely that the malware either decrypts all strings at runtime, or at least some crucial ones. For that reason, looking around for code that looks like string decryption routines or for data that could be encrypted strings is a good idea.

And this is where you can usually start actually reversing the malware. Strings very often lead to interesting code (if you find a bunch of HTTP-related strings or a user agent, you can just check where they are used and are likely in the communication code), or you jump to relevant APIs right away if they are obvious (if you find InternetConnect or HttpSendRequest or connect/recv/send for example).

In any case, resolving imports and strings is pretty much always the first step and the stepping stone for further targeted analysis.

This is pretty general but pretty much every static malware analysis goes through these steps. The rest is just pure reversing, finding functions, understanding them, finding who uses them and so on, like a crossword puzzle.