Reversing malware loaders - The Matsnu-A Case

From Botnets.fr
Revision as of 16:28, 7 February 2015 by Eric.freyssinet (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

(Publication) Google search: [1]

Reversing malware loaders - The Matsnu-A Case
Botnet Matsnu
Malware
Botnet/malware group
Exploit kits
Services
Feature
Distribution vector
Target
Origin
Campaign
Operation/Working group
Vulnerability
CCProtocol
Date 2012 / 21/07/2012
Editor/Conference
Link http://anti-reversing.com/Downloads/Sec Research/Reversing Malware Loaders - The Matsnu-A Case.pdf anti-reversing.com (PDF) (anti-reversing.com (PDF) Archive copy)
Author Kyriakos Economou
Type

Abstract

The AV industry is growing every day along with the underground industry that

produces all those types of malware, from simple file infectors to more sophisticated Trojan types, able to gather and send sensitive information to the bad guys.
The fight between AV companies and malware authors is getting bigger and bigger every single day. Both good and bad guys dedicate a lot of time into researching and implementing either ways to detect or ways to avoid detection, depending on which side these people are. Most of the malware research is usually concentrated on the infection mechanisms of the malware, as well as the techniques used from the malware to communicate with his creator, completely ignoring sometimes the anti-virus evasion techniques used by the malware in the first place.
This article aims to dig inside the loader used by the Matsnu malware family, in order to deploy itself avoiding detection by AV products. Fortunately, at this point this variant is already detected by most AV vendors. In my job as malware analyst, I hear very often talking about this kind of AV evasion technique as a ‘packer’. In a very abstract way, this might be true, but in a technical way it really isn’t.
From my experience with packers and manual unpacking, I expect that a packer will incorporate some compression algorithm and most probably an encryption algorithm custom or not. Furthermore, the behaviour of a packer is usually a lot different. A packer will usually decompress and decrypt the code of the original executable and then will jump to its original entry point (OEP).
On the other hand, I prefer calling these ‘packers’ used by more and more malware authors as loaders. This is because of the technical details. These loaders will usually launch a child process in suspended mode, will overwrite its memory with the decrypted code of the malware and then they will resume its main thread. Some of them, they might choose to allocate some extra memory on the child process, instead of overwriting its memory, and write there the decrypted viral code and then inject a thread to it with starting address the beginning of the allocated memory where the viral code is placed. Some others, they might overwrite themselves through a code stub written into an extra chunk of allocated memory and then jump back to the PE image address space.

Bibtex

 @misc{Lua error: Cannot create process: proc_open(/dev/null): failed to open stream: Operation not permitted2012BFR1151,
   editor = {},
   author = {Kyriakos Economou},
   title = {Reversing malware loaders - The Matsnu-A Case},
   date = {Error: Invalid time.},
   month = Error: Invalid time.,
   year = {2012},
   howpublished = {\url{http://anti-reversing.com/Downloads/Sec_Research/Reversing_Malware_Loaders_-_The_Matsnu-A_Case.pdf anti-reversing.com (PDF)}},
 }