Virus analysis by example - investigating Trojan-Downloader.Win32.Zanoza.ab

Have you ever thought about the fate of a virus caught by antivirus companies? What happens to him even before adding signatures to the database? More specifically, about virus analysis. It may seem that doing a virus test yourself is difficult, unnecessary and dangerous, but in fact this is absolutely not the case. Unnecessary skills will never hurt, and it is useful, sometimes, to look before launching what the executable file downloaded from the Internet is. To start work, any knowledge of the assembler, debugger with disassembler and virtual machine will be suitable to choose from.

Samples of viruses for analysis can, of course, be searched independently on the Internet, but for a start, we will go some other way. A huge collection of viruses ready for analysis can be found at vx.netlux.org . The first virus I liked was Trojan-Downloader.Win32.Zanoza.ab. His detailed analysis, we now deal with. By the way, good descriptions of viruses can be viewed on the site securelist.com.


')
The first thing that catches your eye is the file size - just 1,901 bytes. One might think that, due to its small size, the entire functionality of the virus will be clearly visible, but let's not hurry. Make sure in any hex editor that the file is a Windows executable file (by MZ and PE signatures) and load it into any debugger-disassembler. The picture opens is not joyful:

Not only are all sections and headers in one heap, the file is obviously packed with something. Then you can go two ways. The first is to manually trace the program until an entry point is detected and a further dump is taken (it is not recommended for a beginner). The second is simpler - try to determine the program packer and unpack it automatically. Let's go the second way. Load the program in PIED:

We were lucky, PIED successfully discovered the FSG packer. Download any automatic FSG unpacker and successfully remove one layer of protection (for example, Unfsg2.0):

Again, load the program into the debugger-disassembler. We will see another layer of protection:

Yes, gaze opened to complete nonsense. However, you can be sure that we are on the right track. This is a completely normal executable code, only slightly obfuscated. And badly obfuscated: smooth, the code is simply diluted by nothing doing nop commands and meaning nothing push reg and pop reg. Scroll the program down a bit and see the main decryption loop:

We trace the program to this place:

And we get to the already completely decoded program code (do not forget to update the debugger window in order to display the commands correctly):

Now remove the resulting dump with any tool available to you. Finally, we discovered some functionality of the virus:

Here begins the direct analysis. The first thing to do when the virus starts is the procedure located at 0x401128. It is easy to guess that this function creates a batch file with the name "c.bat", with the following content:

Go ahead. After creating a bat-file, the program launches it for execution. An endless loop of attempts to delete chkdsk * .exe files starts, as well as the source file itself, the path to which was carefully passed to the script via a command line parameter. We will see on the screen a set of successive console windows. Now comes the fun part. The virus generates a child process svhost.exe in the suspended state and writes into it a code of 764 bytes in size, located at the offset 0x401180. Obviously, the svhost.exe executable file was chosen in order to bypass some not very intelligent firewalls and antiviruses, as well as to prevent the user from accidentally ending the running virus process. Where does the virus inject? The programmer decided not to strain too much and simply overwritten the code pointed to by the entry point of the executable file. How did he determine the right address? The virus tritely loaded the svhost.exe image into its address space with the LoadLibraryEx function. And after that, it was already easy to determine the desired address from the standard offsets of the Windows executable file (this section of the code is located at 0x4010A6 - 0x4010AC). So, the injection is implemented and this executable file needs only to transfer the baton to the suspended schost.exe process. The question arises, how to investigate an infected process? You can, of course, manually select the necessary code and then analyze it separately, but at the same time its functionality and performance can suffer greatly. I did not think long and decided to run all this on a virtual machine and skip svchost.exe while it is running. So, we trace the main program before calling ResumeThread, open ProcessExplorer:

And we find the PID of the process we need (in principle, it was possible to recognize the PID even in the debugger, but oh well). We translate 1356 out of 10 into the 16-hereditary system, we get 0x54C. Next, run LordPE and try to remove the dump from the process:

We see that we do not have enough rights for this action due to the fact that the process is already being debugged by another program. Because we work in a virtual machine environment, then you can simply continue with the main program, and then easily remove the dump we need. Attention!!! This step is done at your own risk! Everything went smoothly for me, and I got the infected svhost.exe file ready for analysis:

We again see the decryption cycle:

XOR BYTE PTR DS: [EBX-5], 0xB1
INC EBX
LOOPD SHORT 0x100251D

If you run this program for execution, it will crash with an error, because no entry in the code section. Let's think a bit: once the dump was taken from the process during operation, the decryption cycle has already been completed. And now when you start the program will try to encrypt themselves already. We do not need this, so for further analysis we will burst the entire decryption cycle. At this point, we are much advanced, is not it? We trace further in the virtual machine:

We see the cycle located at the address 0x10255C-0x1002587. Its purpose is to determine addresses of functions that are vital for the operation of WinAPI code. The very comparison of names occurs in this place:

After determining the necessary addresses of WinAPI functions, we encounter another layer of protection. The infected program calls the VirtualAlloc function to allocate an additional area of ​​memory into which another layer of malicious code is copied, to which control is transferred using the JMP EAX command:

Finally, we opened the actual functionality of the virus. The malicious code loads the standard dynamic library “urlmon.dll” to use the URLDownlodToFile function, after which it is used to directly load the chkdsk * .exe files. Here is the moment of file upload:

This is where the loaded file is executed:

And here is the completion of the process:

We also note interesting links for further analysis:

00270204 68 74 74 70 3A 2F 2F 77 77 77 2E 79 76 6F 6E 2D www.yvon-
00270214 70 75 62 6C 69 63 69 64 61 64 2E 63 6F 6D 2F 69 publicidad.com/i
00270224 6D 61 67 65 73 2F 69 6D 61 67 65 73 2E 70 68 70 mages / images.php
00270234 3F 77 3D 31 26 65 3D 32 00 68 74 74 70 3A 2F 2F? W = 1 & e = 2.http: //
00270244 77 77 77 2E 79 76 6F 6E 2D 70 75 62 6C 69 63 69 www.yvon-publici
00270254 64 61 64 2E 63 6F 6D 2F 69 6D 61 67 65 73 2F 69 dad.com/images/i
00270264 6D 61 67 65 73 2E 70 68 70 3F 77 3D 32 26 65 3D mages.php? W = 2 & e =
00270274 32 00 68 74 74 70 3A 2F 2F 77 77 77 2E 79 76 6F 2.http: //www.yvo
00270284 6E 2D 70 75 62 6C 69 63 69 64 61 64 2E 63 6F 6D n-publicidad.com
00270294 2F 69 6D 61 67 65 73 2F 69 6D 61 67 65 73 2E 70 /images/images.p
002702A4 68 70 3F 77 3D 33 26 65 3D 32 00 68 74 74 70 3A hp? W = 3 & e = 2.http:
002702B4 2F 2F 77 77 77 2E 79 76 6F 6E 2D 70 75 62 6C 69 //www.yvon-publi
002702C4 63 69 64 61 64 2E 63 6F 6D 2F 69 6D 61 67 65 73 cidad.com/images
002702D4 2F 69 6D 61 67 65 73 2E 70 68 70 3F 77 3D 34 26 /images.php?w=4&

Time to take stock: the program being analyzed without the user's knowledge downloads files of unknown content from the Internet and launches them for execution. That's all that this malware can do, so it can be classified as Trojan-Downloader. As you can see, malware analysis was not so difficult, although we were faced with a fairly large number of protection layers. Good luck with your virus analysis!