Hi
The exe definitely looks for a randomly named driver and will call several DeviceIoControl IOCTL's if present. I could not however get it to generate a driver per se, so it's possible the driver is a downloaded file (or created from one) and not one embedded and executed from the exe, or dll.
This looks like the dropper file variously known as
Trojan-Downloader:W32/Injecter.GX
http://www.f-secure.com/v-descs/trojan-downloader_w32_injecter_gx.shtml
Troj/Murlo-BH
http://www.sophos.com/security/analyses/trojmurlobh.html
Troj/Agent-GIH
http://www.sophos.com/security/analyses/viruses-and-spyware/trojagentgih.html
TrojanDropper:Win32/Cavitate.A
http://onecare.live.com/standard/en-us/virusenc/VirusEncInfo.htm?VirusName=TrojanDropper:Win32/Cavitate.A
The f-secure description is the best one, pretty much exactly what the attached file does. There is no mention in any of the descriptions though of a driver or its possible function.
Both the exe file and the dll (embedded in the exe file and loaded as tmp*.tmp) are VM-aware. Since the dll is loaded dynamically it becomes tiring to have to break on the dll loading and manually bypass the VM check each time you're running a live analysis. I found that you can easily bypass the VM check in both files by patching the exe in 2 places.
In the exe the check is right at the start. The result of the VM check (based on an encrypted SIDT test) is to return an index value into a call table:
Code:
.text:00404C80 50 push eax
.text:00404C81 E8 3A F6 FF FF call Check_VM
; returns 3 under VM, returns 6 otherwise
.text:00404C86 6A 00 push 0
.text:00404C88 FF 14 85 54 E8 40+ call CallTable[eax*4]
Also embedded in the exe in the .data section is the code for the DLL, and its VM check. It is identical and also run at DLL initialization:
Code:
.data:0040C010 6A 01 push 1
.data:0040C012 E8 71 FE FF FF call Check_VM_DLL
; returns 3 under VM, returns 6 otherwise
.data:0040C017 6A 00 push 0
.data:0040C019 FF 14 85 F4 8F 00+ call dword ptr ds:10008FF4h[eax*4]
What you can do is patch both locations, overwriting the Check_VM call entirely with the instruction
MOV EAX, 6 (plus appropriate NOPS)
which will force the correct (infective) call to be indexed from the call table.
Without a driver to analyze it's...kinda hard to analyze the driver...
However it looks like there may be several possible IOCTL codes available, and not all called by this particular exe. This makes me wonder if this is a somewhat "generic" malware driver with multiple functions, possibly downloaded from a remote site, that could be used with a family of this type of trojan.
There are 3 hardcoded IOCTL's used by DeviceIoControl calls in this malware:
220020h
220024h
220040h
and 2 more taken from an indexed table of possible IOCTL values:
.data:00406004 dd 22007Ch
.data:00406008 dd 220080h
.data:0040600C dd 220084h
.data:00406010 dd 220088h
.data:00406014 dd 22008Ch
.data:00406018 dd 220090h
.data:0040601C dd 220094h
.data:00406020 dd 220098h
.data:00406024 dd 22009Ch
.data:00406028 dd 2200A0h
That leaves 8 potential IOCTL's unused. Maybe they exist in the driver, maybe they're being developed, or maybe this is just sloppy programming, who knows? It would be interesting to find the driver..
