Targeted Malware Reverse Engineering Workshop follow-up. Part 2

[harlan4096]

If you have read our previous blogpost “Targeted Malware Reverse Engineering Workshop follow-up. Part 1“, you probably know about the webinar we conducted on April 8, 2021, with Kaspersky GReAT’s Ivan Kwiatkowski and Denis Legezo, to share best practices in reverse engineering and demonstrate real-time analysis of recent targeted malware samples. The experts also had a fireside chat with Igor Skochinsky of Hex-Rays and introduced the Targeted Malware Reverse Engineering online self-study course.

The webinar audience having been so active – it was a very pleasant surprise, thanks again! – not only were we unable to address all the incoming questions online, we didn’t even manage to pack the rest of them in one blogpost. So here comes the second part of the webinar follow-up.

Questions related to malware analysis

1. How common are opaque predicates in legitimate software? Can these predicates be leveraged as detection signatures?
   Ivan: It is difficult to provide an answer encompassing all legitimate software. As a general rule, obfuscation or evasion techniques can provide a relevant weak signal  potentially indicating malicious behavior, but should not be used for detection.
   Denis: We mostly deal with malicious, not legit code, but I would not expect such tricks there. What for — protection? I would not expect opaque predicates even from third-party protectors.
   
2. Do you often come across binary obfuscation methods like nanomites, control flow flattening or VM in malwares?
   Ivan: Such techniques are extremely rare, possibly because attackers know that the presence of such protections will raise suspicion.
   Denis: We met several flattening cases lately. I could also name a couple of cases of custom internal VM usage in malware. So, not often, but they do exist.
   
3. When it comes to packed executables, are automated unpackers usually good enough (like using dynamic instrumentation to detect tail jump and so forth) or is it more about manual work?
   Ivan: It turns out that packed executables are not as widespread as you would think. They turn up so rarely that I always default to manual work.
   Denis: We mostly deal with targeted malware, and packing executables are not common in this world, I agree.
   
4. Do we also see any “exotic” commercial packers like vmprotect?
   Ivan: We don’t, however, if this is of interest to you, I strongly recommend you to watch Vitaly Kamluk’s presentation on the subject.
   Denis: Not in this training, but again, I would not say such tools are too popular in the world of targeted malware. Mostly due to being detected by security products, I suppose.
   
5. What are the most creative anti-reversing tricks from malware creators you have seen so far?
   Ivan: I would name the LuckyMouse APT which deploys stripped down malware samples containing none of its configuration anymore, once saved somewhere on the victim’s machine. Generally speaking, they’re very good at making sure that files obtained by defenders are incomplete.
   Denis: The best anti-reversing trick I have seen is a seasoned software design pro with brain-damaging multi-module development style and 30 years of experience on the other side of the court. The only thing you want to do after the encounter is to yell at him/her, your disassembler, your PC, and yourself. But when you are done at last — well, this is the reason why we do it.
   

Questions on the Targeted Malware Reverse Engineering course syllabusYou can find the full syllabus here.

1. Is the training focused on static reverse engineering or do you use dynamic analysis (e.g. debug/emulation) as well? Is the virtual lab analysis limited to static one?
   Ivan: We occasionally use debugging, and debuggers are available in the VM. Most of the work, however, takes place in IDA Pro.
   Denis: Ah, our deep belief in static analysis has affected the training for sure. But we do debugging as well, it is true. For example, in the LuckyMouse track.
   
2. Will the analysis exercises deal only with the “final” malicious payloads/files or with analyzing the entire infection chains (e.g. downloader -> dropper/injector -> shellcode)?
   Ivan: It is closer to the other way around. When we have no time to show everything, we focus on the most complex parts of the infection chain (the beginning), tackle all the problems, and leave the easy part (looking at the unobfuscated final stage) as an exercise for the audience.
   
3. You have mentioned that a lot of course time will be spent discussing deobfuscation mechanisms. Will there also be a chapter/section dealing on bypassing anti-reversing mechanisms?
   Ivan: The course is organized around the specific real malware cases. There is no theory segment on obfuscation. However, we show many samples that use different techniques and demonstrate how to approach each one of them.
   
4. Does the course cover the C2 protocol traffic analysis?
   Ivan: To some extent, yes. One of the tracks is entirely dedicated to analyzing a network utility, understanding and re-implementing its custom protocol.
   Denis: For example, in the Topinambour track, you deal with simple C2 communication protocol analysis from the reversing point of view: it means means by analyzing the code you come to understand what to expect from the traffic.
   
5. Do you cover both IDA Python and IDC during the course?
   Ivan: We only cover IDA Python, but the participants are free to use IDC if they choose to.
   
6. Will you teach any countermeasures against this kind of anti-reversing techniques?
   Ivan: It’s our intentional choice to focus on real-life cases; and it is a fact that the vast majority of samples I have worked on involved no such protections. One of the malware specimens shown in the course has Anti-VM detection, which doesn’t bother us as we are just reading the code.
   
7. What malicious document formats will be analyzed in the training?
   Ivan: The malicious document studied in the course is the InPage exploit.
   Denis: The InPage file format is based upon Compound Document Format, and we will analyze how the Biodata campaign operators had embedded the shellcode into it.
   
8. If you detect such antimalware techniques, will there be a link to your previous Yara training: how to write a good detection rule to find such complex anti obfuscation techniques?
   Ivan: As you will probably see, the course is quite packed as it is! We may make a comment here and there about what could be a good Yara rule, but only in passing. I am, however, certain that the training will help you write better Yara rules.
   
9. Shall we also learn to write or automate these anti obfuscation tasks at scale?
   Ivan: Yes, a large part of the course focuses on defeating the various protections that prevent us from seeing the actual payload!
   

Topics not addressed in the Targeted Malware Reverse Engineering training

1. The course seems to include various topics on RE. Anything that has been left out? Probably saved for a future update to the course.
   Ivan: There are many things we could not get into. Rust/Go malware, CPU architectures beyond x86 and x64, ARM arch and Mac OS, etc. But we believe we were able to provide a varied yet realistic sample of what we usually encounter.
   Denis: In the third-level reverse engineering course from Kaspersky, you may expect the use of a decryption framework to facilitate such typical reversing tasks.
   
2. Does the course address any malware employing unique file formats, thus requiring one to create an IDA loader module? How often do you deal with malware that uses unique file formats? It is something I am looking to learn.
   Ivan: This is a use case not covered by the course, and in fact one that I have yet to encounter.
   Denis: One quite unique _document_ format with the shellcode in it is featured in the course, but it needs no loader module, as you understand. Pity, but your topic seems to be out of the scope of this training. We are planning to create additional reversing screencasts from time to time — let’s think about covering this, too.
   

Virtual lab

1. Will it be possible to do the exercises in a personal lab at home to analyze the samples of the course?
   Ivan: Due to legal restrictions in some countries, participants are required to work in the dedicated virtual lab that we provide and the VM cannot be downloaded. The good news is that it contains all the necessary tools, including a full version of IDA Pro.
   
2. Can the lab hours be extended if required?
   Ivan: Virtual machines will indeed be suspended after 100 hours of runtime. We can extend the hours on a case-by-case basis, but we expect this should be enough to complete all the tracks of the training.
   
3. Do we need to RDP from a VM?
   Ivan: The virtual environment is accessed directly from the web browser.
   
4. Are the VM’s stealthy for the malware, or can they be detected through redpill/no-pill techniques?
   Ivan: The VMs provided in the training make no attempt at concealing what they are. Most of the malware provided does not particularly try to prevent execution in virtualized environments, and in any case the training is focused on static analysis with IDA Pro.
   
5. If we write IDA scripts, can we extract them to our home environment at the end?
   Ivan: Sadly, this will not be possible. But the scripts you write should remain relatively modest in size, and will probably not be generic enough to allow future use anyway.
   

...

Continue Reading