Virus analysis by example - exploring Trojan-Downloader.Win32.Zanoza.ab
Have you ever wondered what the fate of a virus caught by antivirus companies is? About what happens to him even before adding signatures to the database? More specifically, about viral analysis. It may seem that doing viral analysis yourself is difficult, unnecessary and dangerous, but in fact it is completely wrong. Extra skills will never hurt, and it’s useful, sometimes, to see before launch what an executable file downloaded from the Internet is like. To start work, any assembler knowledge, a debugger with a disassembler, and a virtual machine to choose from will work.
Samples of viruses for analysis can, of course, be searched independently on the Internet, but for starters we will go a different way. A huge collection of ready-to-analyze viruses can be found at vx.netlux.org. The first virus that attracted my attention was Trojan-Downloader.Win32.Zanoza.ab. We will now take up his most detailed analysis. By the way, good descriptions of viruses can be found on securelist.com.
The first thing that catches your eye is the file size - only 1,901 bytes. You might think that due to the small size all the functionality of the virus will be visible at a glance, but let's not rush it. Make sure in any hexadecimal editor that the file is a Windows executable (according to the MZ and PE signatures), and load it into any debugger-disassembler. The picture does not open joyful:
Not only that, all sections and headers are collected in one heap, but the file is obviously packed with something. Then you can go in two ways. The first one is to manually trace the program until an entry point is detected and then dump it further (it is not recommended for a beginner). The second simpler one is to try to determine the program packer and unpack it automatically. Let's go the second way. Download 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):
Once again, load the program into the debugger-disassembler. We will see another layer of protection:
Yes, a complete nonsense was revealed. However, you can be sure that we are on the right track. This is quite normal executable code, only slightly obfuscated. And it’s badly obfuscated: smooth, the code is simply diluted with nop commands that do nothing and push reg and pop reg nothing. Scroll down a little and see the main decryption cycle:
We trace the program to this place:
And we get to the fully decrypted program code (do not forget to update the debugger window to display the commands correctly):
Now remove the resulting dump with any tool available to you. Finally, some functionality of the virus was revealed to us:
Here begins a direct analysis. First of all, when launched, the virus calls the procedure located at 0x401128. It is easy to guess that this function creates a batch file named "c.bat", with the following contents:
Move on. After creating the bat-file, the program launches it for execution. An endless cycle of trying to delete chkdsk * .exe files begins, as well as the original file itself, the path to which was carefully passed to the script through the command line parameter. We will see on the screen a lot of successive console windows. Now comes the fun part. The virus spawns the svсhost.exe child process in a suspended state and writes into it a code of 764 bytes in size, located starting at offset 0x401180. Obviously, the svсhost.exe executable file was chosen to bypass some not-so-intelligent firewalls and antiviruses, as well as to prevent the user from accidentally terminating the running virus process. Where does the virus inject? The programmer decided not to strain too much and simply rewrote the code, pointed to by the entry point of the executable file. How did he determine the address? The virus corruptedly 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 by standard offsets of the Windows executable file (this code section is located at addresses 0x4010A6 - 0x4010AC). So, the injection has been completed and this executable file only has to pass the baton to the suspended sсvhost.exе process. The question is, how to investigate an infected process? You can, of course, manually select the desired code and then separately analyze it, but at the same time its functionality and performance can greatly suffer. I did not think long and decided to run all this in a virtual machine and dump svсhost.exe while it was running. So, we trace the main program before calling ResumeThread,
And we find the PID of the process we need (in principle, it was possible to find out the PID in the debugger, but oh well). We translate 1356 out of 10 into a hexadecimal system, we get 0x54C. Next, start 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 Since we work in a virtual machine environment, you can simply continue to run the main program, and then freely remove the dump we need. Attention!!! This step is done at your own peril and risk !!! Everything went well 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 this program is launched, it will crash , because write to the code section is prohibited. Let's think a little: since the dump was removed from the process during operation, the decryption cycle has already ended. And now at startup, the program will try to encrypt itself already. We don’t need this, so for further analysis we’ll fill in the whole decryption cycle. By this moment, we have already made much progress, aren't we? Trace in a virtual machine further:
We see the cycle located at the addresses 0x10255C-0x1002587. Its purpose is to determine the addresses of functions vital for the operation of WinAPI code. The name comparison itself takes place at this location:
After determining the necessary addresses of WinAPI functions, we are faced with another layer of protection. The infected program calls the VirtualAlloc function to allocate an additional memory area into which another layer of malicious code is copied, the transfer of control to which is performed using the JMP EAX command:
Finally, the virus functionality itself was revealed to us. Malicious code loads the standard dynamic library urlmon.dll in order to use the URLDownlodToFile function, after which it directly downloads chkdsk * .exe files. Here is the file upload moment:
This is where the downloaded 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
00270 254 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 analyzed program, without the knowledge of the user, downloads files of unknown content from the Internet and launches them for execution. That, in fact, is all that this malware can do, so it can be categorized as Trojan-Downloader. As you can see, the analysis of malware turned out to be not so difficult, although we encountered a rather large number of protection layers. Good luck with your viral analysis!
Samples of viruses for analysis can, of course, be searched independently on the Internet, but for starters we will go a different way. A huge collection of ready-to-analyze viruses can be found at vx.netlux.org. The first virus that attracted my attention was Trojan-Downloader.Win32.Zanoza.ab. We will now take up his most detailed analysis. By the way, good descriptions of viruses can be found on securelist.com.
Not only that, all sections and headers are collected in one heap, but the file is obviously packed with something. Then you can go in two ways. The first one is to manually trace the program until an entry point is detected and then dump it further (it is not recommended for a beginner). The second simpler one is to try to determine the program packer and unpack it automatically. Let's go the second way. Download 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):
Once again, load the program into the debugger-disassembler. We will see another layer of protection:
Yes, a complete nonsense was revealed. However, you can be sure that we are on the right track. This is quite normal executable code, only slightly obfuscated. And it’s badly obfuscated: smooth, the code is simply diluted with nop commands that do nothing and push reg and pop reg nothing. Scroll down a little and see the main decryption cycle:
We trace the program to this place:
And we get to the fully decrypted program code (do not forget to update the debugger window to display the commands correctly):
Now remove the resulting dump with any tool available to you. Finally, some functionality of the virus was revealed to us:
Here begins a direct analysis. First of all, when launched, the virus calls the procedure located at 0x401128. It is easy to guess that this function creates a batch file named "c.bat", with the following contents:
Move on. After creating the bat-file, the program launches it for execution. An endless cycle of trying to delete chkdsk * .exe files begins, as well as the original file itself, the path to which was carefully passed to the script through the command line parameter. We will see on the screen a lot of successive console windows. Now comes the fun part. The virus spawns the svсhost.exe child process in a suspended state and writes into it a code of 764 bytes in size, located starting at offset 0x401180. Obviously, the svсhost.exe executable file was chosen to bypass some not-so-intelligent firewalls and antiviruses, as well as to prevent the user from accidentally terminating the running virus process. Where does the virus inject? The programmer decided not to strain too much and simply rewrote the code, pointed to by the entry point of the executable file. How did he determine the address? The virus corruptedly 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 by standard offsets of the Windows executable file (this code section is located at addresses 0x4010A6 - 0x4010AC). So, the injection has been completed and this executable file only has to pass the baton to the suspended sсvhost.exе process. The question is, how to investigate an infected process? You can, of course, manually select the desired code and then separately analyze it, but at the same time its functionality and performance can greatly suffer. I did not think long and decided to run all this in a virtual machine and dump svсhost.exe while it was running. So, we trace the main program before calling ResumeThread,
And we find the PID of the process we need (in principle, it was possible to find out the PID in the debugger, but oh well). We translate 1356 out of 10 into a hexadecimal system, we get 0x54C. Next, start 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 Since we work in a virtual machine environment, you can simply continue to run the main program, and then freely remove the dump we need. Attention!!! This step is done at your own peril and risk !!! Everything went well 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 this program is launched, it will crash , because write to the code section is prohibited. Let's think a little: since the dump was removed from the process during operation, the decryption cycle has already ended. And now at startup, the program will try to encrypt itself already. We don’t need this, so for further analysis we’ll fill in the whole decryption cycle. By this moment, we have already made much progress, aren't we? Trace in a virtual machine further:
We see the cycle located at the addresses 0x10255C-0x1002587. Its purpose is to determine the addresses of functions vital for the operation of WinAPI code. The name comparison itself takes place at this location:
After determining the necessary addresses of WinAPI functions, we are faced with another layer of protection. The infected program calls the VirtualAlloc function to allocate an additional memory area into which another layer of malicious code is copied, the transfer of control to which is performed using the JMP EAX command:
Finally, the virus functionality itself was revealed to us. Malicious code loads the standard dynamic library urlmon.dll in order to use the URLDownlodToFile function, after which it directly downloads chkdsk * .exe files. Here is the file upload moment:
This is where the downloaded 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
00270 254 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 analyzed program, without the knowledge of the user, downloads files of unknown content from the Internet and launches them for execution. That, in fact, is all that this malware can do, so it can be categorized as Trojan-Downloader. As you can see, the analysis of malware turned out to be not so difficult, although we encountered a rather large number of protection layers. Good luck with your viral analysis!