Obscene Trojan.

In general, with this trojan, everything was clear from the very beginning: he is pumping something from the network. But for some reason (one of them is detected by Casper as P2P-Worm.Win32.Socks.s), I decided to “disassemble” it. Under the cut - the technical details of opening the Trojan. Attention, there are not quite censorship words and many technical details!


Today on the table is the file services.exe, a little less than 20,000 bytes. Not packaged, written on a version of VC.
IDA after processing the file stops at WinMain. And in WinMain, we immediately see:

.text: 00403444 push ebp
.text: 00403445 mov ebp, esp
.text: 00403447 push 0FFFFFFFFh
.text: 00403449 push offset unk_404140
.text: 0040344E push offset loc_403540
.text: 00403453 mov eax, large fs: 0
.text: 00403459 push eax
.text: 0040345A mov large fs: 0, esp
.text: 00403461 push ecx
.text: 00403462 push ecx
.text: 00403463 sub esp, 10h
.text: 00403466 push ebx
.text: 00403467 push esi
.text: 00403468 push edi
.text: 00403469 mov [ebp + var_18], esp
.text: 0040346C and [ebp + var_4], 0
.text: 00403470 and dword ptr [ebp + Time + 4], 0
.text: 00403474 mov eax, dword ptr [ebp + Time + 4]
.text: 00403477 mov dword ptr [eax], 0DFADBABEh
.text: 0040347D or [ebp + var_4], 0FFFFFFFFh
.text: 00403481 jmp loc_40352B
...
.text: 0040352B loc_40352B :; CODE XREF: WinMain (x, x, x, x) + 3D
.text: 0040352B mov ecx, [ebp + var_10]
.text: 0040352E mov large fs: 0, ecx
.text: 00403535 pop edi
.text: 00403536 pop esi
.text: 00403537 pop ebx
.text: 00403538 leave
.text: 00403539 retn 10h
.text: 00403539 _WinMain @ 16 endp
')
But pay attention to the code starting with the address 0x403470 - a clear attempt to contact the address 0x000000! In this place, the SEH handler is called, and as a result, the control is transferred to the next place. This trick is used at least once more in WinMain. But WinMain has prepared a couple more surprises, for example, control is transferred to this code:

.text: 00401EA3 loc_401EA3 :; CODE XREF: WinMain (x, x, x, x): loc_4034C9
.text: 00401EA3 push ebp
.text: 00401EA4 mov ebp, esp
.text: 00401EA6 push 0FFFFFFFFh
.text: 00401EA8 push offset unk_404120
.text: 00401EAD push offset loc_403540
.text: 00401EB2 mov eax, large fs: 0
.text: 00401EB8 push eax
.text: 00401EB9 mov large fs: 0, esp
.text: 00401EC0 push ecx
.text: 00401EC1 push ecx
.text: 00401EC2 push ecx
.text: 00401EC3 push ebx
.text: 00401EC4 push esi
.text: 00401EC5 push edi
.text: 00401EC6 mov [ebp-18h], esp
.text: 00401EC9 and dword ptr [ebp-4], 0
.text: 00401ECD mov eax, 1
.text: 00401ECD; - .text: 00401ED2 dw 3F0Fh
.text: 00401ED4 dd 45C70B07h, 0FFFFFFFCh, 0FC4D83FFh, 6A14EBFFh, 8BC35801h
.text: 00401ED4 dd 6580E865h, 4D8300E7h, 458AFFFCh, 0B002EBE7h, 0F04D8B01h
.text: 00401ED4 dd 0D8964h, 5F000000h, 0C3C95B5Eh

Invalid opcode. Olly in this place tightly refuses to move to the next instruction. That is, we have a kind of anti-debugging trick. And the last trick is VMWare detection, which is quickly and easily identified by the following instructions:

.text: 00401F34 mov eax, 'VMXh'
.text: 00401F39 mov ebx, 8685D465h
.text: 00401F3E mov ecx, 0Ah
.text: 00401F43 mov dx, 5658h
.text: 00401F47 in eax, dx

In fact, WinMain performs two functions: it complicates the life of the researcher and transfers (if everything is as it should) control to the payload. I did not get through WinMain, but at the very beginning I moved EIP to PayLoad right away. First, as usual, the trojan prepares data for its black deeds: it decrypts all the lines and finds out the addresses of the necessary API functions (LoadLibrary + GetProcAddress, and not in a loop). String encryption - XOR in one byte, although the key is different everywhere. The algorithm is easily recognized:

.text: 0040100E loc_40100E :; CODE XREF: decryptXor + 37 j
.text: 0040100E mov eax, [ebp + pos]
.text: 00401011 inc eax
.text: 00401012 mov [ebp + pos], eax
.text: 00401015
.text: 00401015 loc_401015 :; CODE XREF: decryptXor + C j
.text: 00401015 push [ebp + lpString]; lpString
.text: 00401018 call ds: lstrlenA
.text: 0040101E cmp [ebp + pos], eax
.text: 00401021 jge short loc_401039
.text: 00401023 mov eax, [ebp + lpString]
.text: 00401026 add eax, [ebp + pos]
.text: 00401029 movsx eax, byte ptr [eax]
.text: 0040102C xor eax, [ebp + key]
.text: 0040102F mov ecx, [ebp + lpString]
.text: 00401032 add ecx, [ebp + pos]
.text: 00401035 mov [ecx], al
.text: 00401037 jmp short loc_40100E

On Delphi, by the way, such a decryption function would take two pages. What I do not like Delphi.
Then comes the WSAStartup call - preparation for working with Windows Sockets, an attempt to delete the c: \ stop file (the Trojan is uniquely identified by the name of this file), preparation of lines containing the necessary paths. The next moment is interesting: the Trojan opens its file for reading, moves the reading position to 0x43 bytes and reads 8 bytes from there. I look at this place in HIEW ... Oppa! Yes, we have here a MANUALLY modified title! 0x43 - just the beginning of the line "This program ...", and here we have load \ 0. The next number of our program is the calculation of some unique line based on the path to the Windows system catalog and the serial number of the disk. Now the trojan will check for the presence of two files in the system:% Windows% \ system32 \ drivers \ services.exe and svchost.exe in the current user directory. When a trojan is not installed in the system, a transition is made to a very interesting code. First, a number is obtained from the string (!) Through its own implementation of the atoi function, which is then multiplied by 1000, and the result is passed to the Sleep function, that is, an adjustable delay is performed. The delay before the Trojan receives command line arguments, gathers them all together and passes them to WinExec. It leads to suspicions that the Trojan can be registered as a default program for opening files! Missing arguments are handled correctly. Before performing destructive actions, the Trojan checks for the presence of a mutex in the system, and if it already exists, it completes its work. If there are no fellows, it creates two threads, one of which checks in the cycle the presence of the c: \ stop file (if it exists, it completes the process), and the second works with the network. The final touch is extracting the ftp34.dll file from your body (XOR encryption, 1-byte key) to the user’s directory and the system directory and then downloading it. To complicate the user's life, the creation date of these files will be the same as the system ones.

Network activity.
All work with the network is concentrated in one of the streams of the Trojan. In the same thread, the Trojan copies itself to% Windows% \ system32 \ drivers \ services.exe, the svchost.exe file in the current user’s directory and the userinit.exe file in “Startup” in the Windows Main Menu (and also corrects the date). (At this point, I foolishly released the Trojan out of control and had to restore the system from the image). Register in the registry, at least in 5 places. And, as I expected, it is written as a default program for opening EXE files. I will not set a bryak on the beginning of ThreadProc, again stupidly and cynically change my EIP to its beginning :-)
So what about the network? An attempt is made to request a URL of the form site.com/shl/?&v=load&lid=1033. Whois reports that the contact soap for this site is on mail.ru, and the IP address belongs to the Russian hoster. What is passed in the URL? “Load” is the piece that was extracted from the site header, and 1033 is the system language identifier. If you enter the browser on site.com/shl/ - there will be a picture and a form for the login.


Here is such a logo!

I put on Vendian shttpd, registered in etc / hosts 127.0.0.1 for site.com. But there is a problem: shttpd is bad with urls containing "?" copes. The problem is solved simply: we download the necessary file from the server with wget, rename it to shl.txt, and before calling InternetReadFile from the Trojan, patch the URL into memory so that it becomes site.com/shl.txt. Now the server will give the file, and the Trojan will accept it. At first I thought that the trojan needed this page to somehow send the login and password. But everything turned out to be simpler: the Trojan searches for the string “form method” and if it continues to download. This time, the file is downloaded from the URL site.com/shl/manda.php?ns=1&id=1212312124, where id is a unique number (for receiving, see above). But for some reason I didn’t download this file :-( Maybe it’s blocking by IP on the server, who knows ... But the file was downloaded at work. There’s a list of URLs in plain text. The code is pretty simple, and it becomes clear that URLs are downloaded files and launched for execution; this is done from a separate thread.

Results
Caspers made a mistake with the name, and I was once again convinced that such files are at least Downloaders. The authors of the Trojan are Russian-speaking comrades who sell the Trojan ... Less than 20% of the code is not disassembled in detail, but judging by the description on the authors website, as well as text strings, the Trojan is able to collect email addresses for spam emails. The ftp34.dll library most likely serves to intercept passwords for access to FTP. I think at work I can pick up the rest in detail. Here it is, zalupko Trojan :-)

UPDATE Continued vilgeforce.habrahabr.ru/blog/44145.html