Resident error

Recently I received a letter similar to the following:

Dear X. Your candidacy is very interested in us, so we would not mind to get to know each other better. You must first download our resume.exe letterhead, fill it out, and send it back to us. Sincerely, network villains.

Tellingly, the link to the resume was written exactly like that. resume.exe (do not click, link for example). They generally, or what?

Download, look. The file is 159744 bytes in size and is packed at first glance. Kaspersky program is known as " Trojan.Win32.Srizbi.v ".

Ida scares the question on the damaged import table. It is understandable - it is quite clear that the file is packed.
')


The code (blue section) takes up about five percent of the program size, but the data - in bulk. This data is most likely a packed code. Particularly frightening the names of the segments: "_67D & NEk &" or "_uoeWPJ3" instead of something familiar like ".code". The entry point is not somewhere at the beginning of the file, but in some ass.

We try a pair of packers, such as PEID - to no avail, this packer is not familiar to them. Therefore, immediately proceed to action. We will not analyze how the program is packaged. Once she can unpack, let her do it herself. (This case turned out to be quite simple, in others the launch of the program can lead to Terrible Things).

Load the file to debugger, set a breakpoint on CreateFile. It is logical after all - should any malicious program use it? (Actually, here we can make some big misses. For example, if the program would use the native function ZwCreateFile, which is a level lower than CreateFile).

... and run for execution. Here we are in for a surprise number 1. It takes 15-20 seconds (!) Before execution stops at the entrance to CreateFile. See, the program is packed and repacked far and wide and more than once. We tried with all my heart what to say.

Stopping at the entrance to CreateFile, we look at the name of the file being opened:

  kernel32! CreateFileA:
 7c801a24 8bff mov edi, edi
 0: 000> da poi (esp + 4)
 0012fe70 "C: \ WINDOWS \ system32 \ drivers \ gran"
 0012fe90 "de48.sys" 

Driver! The case smells like rootkits. While the program is running, we make a dump with something like PE Tools, and view it in a disassembler. He curses ever more, now on IAT, but it is not lethal. In the debager we look at the call stack, find where the function was called from, go back to the disassembler, find this code. The call to CreateFile looks something like

  call ds: 42C1C8 

that doesn't really tell us anything. Therefore, using the dds command in windbg, we find the addresses of real functions, transfer them to go (out of a little, something around twenty). Now we have the names of the called functions (as if an import table restored by hands), and we can analyze the code in a disassembler. It turns out to be very simple, linear, almost without branches. I will give the full code of the main function:

; Attributes: bp-based frame
Main_40164F proc near
var_32C = dword ptr -32Ch
String1 = byte ptr -228h
Windir = byte ptr -124h
var_20 = dword ptr -20h

push ebp
mov ebp, esp
sub esp, 32Ch
call unxor_401040
call SetupImports_401248
call ds: GetTickCount_0
mov ds: TickCount_42C1AC, eax
push 104h; uSize
lea eax, [ebp + windir]
push eax; lpBuffer
call ds: GetWindowsDirectoryA
lea eax, [ebp + windir]
push eax
lea eax, [ebp + String1]
push eax
call ds: lstrcpyA
lea eax, [ebp + windir]
push eax
lea eax, [ebp + var_32C]
push eax
call ds: lstrcpyA
push ds: lpString2
lea eax, [ebp + var_20]
push eax
call ds: lstrcpyA
push ds: dword_42C16C
lea eax, [ebp + windir]
push eax
call ds: lstrcatA
lea eax, [ebp + windir]
push eax
call ExtractDriver_4015E4
lea eax, [ebp + var_20]
push eax
lea eax, [ebp + windir]
push eax
call LoadDriver_4014CB
add esp, 0Ch
call KillMySelf_40139F
call CleanUp_401000
leave
retn
Main_40164F endp

As you can see, everything is simple. First, the lines are prepared, then the import is restored, after which the driver is removed from the program body, saved to the driver folder and loaded.

  ADVAPI32! CreateServiceA:
 77e37071 6a30 push 30h
 0: 000> da poi (esp + 8)
 0012ff74 "grande48" 

Here I want to remind you of one simple, but very effective way to combat this kind of infection. Enough to prohibit entry to the system directories and more than half of the viruses will simply not work.

At the stage of loading the driver we are waiting for the second surprise. It does not load. You can sit and wait for hours with a debugger in hand, when this long-awaited IoCreateDevice is called, but this moment does not come. After a few hours of fruitless attempts to load the driver, it turns out that it was made for Windows 2000! Therefore, most windows users who use XP, this infection is not terrible. It is quite possible that this is only this modification that behaves this way, so I will not say for sure.

Speaking of driver. Size 167936. Defined by Kaspersky as Rootkit.Win32.Agent.aih. Inside contains a lot of diverse code that sends spam. Among other things, contains the IP address of the managing server: 208.66.195.172. Apparently, this is a co-location, and the server itself is rented. Not really, however, it is clear how it is possible to rent a server to manage a botnet) Or maybe the server is legal, just the malicious code is implemented on it, and the admins missed. In general, everything is foggy.

We return back. The KillMySelf function creates a bat file _it.bat in the Temp folder and then launches it:

  kernel32! CreateFileA:
 7c801a24 8bff mov edi, edi
 0: 000> da poi (esp + 4)
 0012fb58 "C: \ DOCUME ~ 1 \ dev \ LOCALS ~ 1 \ Temp \ _i"
 0012fb78 "t.bat" 

Here is its full text:

: abc
del "C: \ sandbox \ Trojan.Win32.Srizbi.v \ resume.exe."
if exist "C: \ sandbox \ Trojan.Win32.Srizbi.v \ resume.exe.txt" goto abc
rmdir "C: \ sandbox \ Trojan.Win32.Srizbi.v"
del "C: \ DOCUME ~ 1 \ dev \ LOCALS ~ 1 \ Temp \ _it.bat"

That is, it tries to remove the program, the folder that contains it, and itself for the last.

Conclusion

Srizbi is not a Trojan, but a carrier of a real malware. His goal is to unload the real virus from his body as quickly as possible (albeit slowly), run it, then disappear, leaving a minimum of traces. Its code is simple and non-volumetric, and for beginners (like me :), it’s pretty easy to figure it out. Because of the stupid error, all the work of Srizbi.v goes for a smarka: it does not check the version of the operating system for compliance with the driver it contains. As a result, the system simply refuses to load the driver. It is useful to look into the driver, there is a rootkit, which hides files, registry keys, network connections and listening ports.