[Codehook]

Attached is an API log, captured using PIN. Apart from the obvious I/O VMWare detection that occurs at 70005277, how is it detecting the presence of a VM? Any calls prefixed with "mal." are calls made from the malware itself and not subsequent API calls.

As a test, you can create C:\pagefile.sys.bak.txt and it will not perform the VM checks.

I have made a comment in the API log after FindFirstFileA/_strcmpi that the VM detection probably occurs after that point. The APIs called after this, in order, are:

Code: Select all

  -->mal.70001866 : call dword ptr [0x700090ec] (GetDriveTypeA) (7c8214cb) [C:\WINDOWS\system32\kernel32.dll]
  -->mal.70004575 : call dword ptr [0x70009080] (unnamedImageEntryPoint) (763610e0) [C:\WINDOWS\system32\WINSTA.dll]
  -->mal.70003770 : call dword ptr [0x70009028] (EqualSid) (77ddf06a) [C:\WINDOWS\system32\ADVAPI32.DLL]
  -->mal.70007ddc : call eax (WTSEnumerateSessionsA) (76f51a90) [C:\WINDOWS\system32\wtsapi32.dll]
  -->mal.70008966 : jmp dword ptr [0x700091b8] (NetUserEnum) (5b89495d) [C:\WINDOWS\system32\NETAPI32.dll]
  -->mal.700086ac : call edi (LookupAccountNameW) (77de5b39) [C:\WINDOWS\system32\ADVAPI32.DLL]
  -->mal.700086e3 : call edi (CopySid) (77ddf0d7) [C:\WINDOWS\system32\ADVAPI32.DLL]
  -->mal.7000818b : call esi (RtlGetLastWin32Error) (7c90fe01) [C:\WINDOWS\system32\ntdll.dll]
  -->mal.700084f6 : call dword ptr [0x70009010] (ConvertSidToStringSidA) (77dfc15d) [C:\WINDOWS\system32\ADVAPI32.DLL]
  -->mal.700088f0 : jmp dword ptr [0x70009174] (_local_unwind2) (77c354a7) [C:\WINDOWS\system32\msvcrt.dll]
  -->mal.70008960 : jmp dword ptr [0x700091bc] (NetApiBufferFree) (5b867a00) [C:\WINDOWS\system32\NETAPI32.dll]
  -->mal.70007e02 : call eax (WTSFreeMemory) (76f51454) [C:\WINDOWS\system32\wtsapi32.dll]
  -->mal.70008884 : call dword ptr [0x7000911c] (exit) (77c39e7e) [C:\WINDOWS\system32\msvcrt.dll]

Any help appreciated.

EDIT: Oops, forgot to include the sample. It is now attached, password is 'infected'

[EP_X0FF]

I did only quick looking, so maybe missing something.

In unpacked see @700051C7, multiple vm detection routines called here.

cpuid, ecx 31 bit
invalid instruction set (unsure if this stuff is really working)
VmWare VMX backdoor
SetupAPI
Sandboxie SBIEDLL.DLL (they did string comparison by comparing string hashes I think).

Nothing new, except they hide all string behind hashes.

[Codehook]

Thanks I will have a closer look there.

[EP_X0FF]

Decrypted in attach. There also some extra long instruction method, likely used for software vm emulation detection.

https://www.virustotal.com/en/file/ad33 ... 409196368/

Also take a look on VT fckup. I strongly suggest them remove VirtualBox extensions in their online sandbox.

[Codehook]

Thanks again.

My VirtualBox setup seems to get fooled by the invalid instruction set, but my VMWare setup does not. Are there settings I can change in VBox to prevent this sort of detection?

Also I notice it does a basic check to see if it is named "sample.exe" too.

[EP_X0FF]

Thanks again.

My VirtualBox setup seems to get fooled by the invalid instruction set, but my VMWare setup does not. Are there settings I can change in VBox to prevent this sort of detection?

Also I notice it does a basic check to see if it is named "sample.exe" too.

http://www.kernelmode.info/forum/viewto ... =11&t=1911

^ only for older VBox versions (< 4.3.14) for example 4.3.12, configure DMI and try patched dlls. Maybe this will be enough I didn't checked this malware for VBox.

[Codehook]

http://www.kernelmode.info/forum/viewto ... =11&t=1911

^ only for older VBox versions (< 4.3.14) for example 4.3.12, configure DMI and try patched dlls. Maybe this will be enough I didn't checked this malware for VBox.

Ah yeah I've already been using the patched DLLs :) and have also configured DMI stuff.

It's definitely the instruction set detection. Will changing the hardware assisted virtualization setting work? As I say, this specific detection doesn't seem to detect my VMWare setup but it does detect my VirtualBox.

[EP_X0FF]

http://www.kernelmode.info/forum/viewto ... =11&t=1911

^ only for older VBox versions (< 4.3.14) for example 4.3.12, configure DMI and try patched dlls. Maybe this will be enough I didn't checked this malware for VBox.

Ah yeah I've already been using the patched DLLs :) and have also configured DMI stuff.

It's definitely the instruction set detection. Will changing the hardware assisted virtualization setting work? As I say, this specific detection doesn't seem to detect my VMWare setup but it does detect my VirtualBox.

Interesting, have you tried skipping this check in debugger? Do you mean routine at @7000510D @70005168 in unpacked binary?

edit:

if you look at VT report you will see that decrypted sample working well inside VT VirtualBox VM = lots of network request etc.

[EP_X0FF]

Finally I tried both original and decrypted binaries on VirtualBox with VM detection bypass.

Samples runs very well, all VM detection sucks as expected.

Malware installed to %Users%\UserName\Application Data\Microsoft\[RandomName]\[RandomName].exe and set to autorun as Win32 service.
here also stored all configuration files and downloaded payload.

It is lolkit.
It hooks NtQuerySystemInformation to hide it process, NtResumeThread hook used for self-propogation in newly spawned processes (from explorer.exe).
Payload downloading performed from zombified IEXPLORE process copy.

Hides part of registry values related to own Win32 service with help of RegEnumValueW/RegEnumValueA hooks.

Seems to be has code to detect Rapport Trusteer (rapportgp.dll).

Below is screenshot from infected system where you can see regedit with filtered information and actual state obtained from the antirootkit.



The following API are intercepted (note the different names of payload dll - actually this information faked by lolkit in PEB and they all the same dll):

Code: Select all

[1100]svchost.exe-->ntdll.dll-->NtQuerySystemInformation, Type: Inline - RelativeJump 0x7C90D910-->009A368F [uyghebn.dll]
[1100]svchost.exe-->ntdll.dll-->NtResumeThread, Type: Inline - RelativeJump 0x7C90DB20-->009A361B [uyghebn.dll]
[1100]svchost.exe-->ntdll.dll-->LdrLoadDll, Type: Inline - RelativeJump 0x7C9163A3-->009A2B00 [uyghebn.dll]
[1100]svchost.exe-->advapi32.dll-->RegEnumValueW, Type: Inline - RelativeJump 0x77DD7EDD-->009A37A0 [uyghebn.dll]
[1100]svchost.exe-->advapi32.dll-->RegEnumValueA, Type: Inline - RelativeJump 0x77DF9B8F-->009A398F [uyghebn.dll]
[1100]svchost.exe-->user32.dll-->TranslateMessage, Type: Inline - RelativeJump 0x7E418BF6-->009A298E [uyghebn.dll]
[1100]svchost.exe-->user32.dll-->GetClipboardData, Type: Inline - RelativeJump 0x7E430DBA-->009A1000 [uyghebn.dll]
[1100]svchost.exe-->user32.dll-->CharToOemBuffA, Type: Inline - RelativeJump 0x7E431626-->009A317A [uyghebn.dll]
[1100]svchost.exe-->ws2_32.dll-->connect, Type: Inline - RelativeJump 0x71AB4A07-->009A418A [uyghebn.dll]
[1100]svchost.exe-->ws2_32.dll-->send, Type: Inline - RelativeJump 0x71AB4C27-->009A42DD [uyghebn.dll]
[1100]svchost.exe-->ws2_32.dll-->WSASend, Type: Inline - RelativeJump 0x71AB68FA-->009A422D [uyghebn.dll]
[1100]svchost.exe-->ws2_32.dll-->WSAConnect, Type: Inline - RelativeJump 0x71AC0C81-->009A40DB [uyghebn.dll]

+more network related hooks if WinInet dll available

Code: Select all

[1572]explorer.exe-->ntdll.dll-->NtQuerySystemInformation, Type: Inline - RelativeJump 0x7C90D910-->0278368F [ynooy.dll]
[1572]explorer.exe-->ntdll.dll-->NtResumeThread, Type: Inline - RelativeJump 0x7C90DB20-->0278361B [ynooy.dll]
[1572]explorer.exe-->ntdll.dll-->LdrLoadDll, Type: Inline - RelativeJump 0x7C9163A3-->02782B00 [ynooy.dll]
[1572]explorer.exe-->advapi32.dll-->RegEnumValueW, Type: Inline - RelativeJump 0x77DD7EDD-->027837A0 [ynooy.dll]
[1572]explorer.exe-->advapi32.dll-->RegEnumValueA, Type: Inline - RelativeJump 0x77DF9B8F-->0278398F [ynooy.dll]
[1572]explorer.exe-->user32.dll-->TranslateMessage, Type: Inline - RelativeJump 0x7E418BF6-->0278298E [ynooy.dll]
[1572]explorer.exe-->user32.dll-->GetClipboardData, Type: Inline - RelativeJump 0x7E430DBA-->02781000 [ynooy.dll]
[1572]explorer.exe-->user32.dll-->CharToOemBuffA, Type: Inline - RelativeJump 0x7E431626-->0278317A [ynooy.dll]
[1572]explorer.exe-->wininet.dll-->HttpOpenRequestA, Type: Inline - RelativeJump 0x771C2AF9-->02787E20 [ynooy.dll]
[1572]explorer.exe-->wininet.dll-->InternetCloseHandle, Type: Inline - RelativeJump 0x771C4D8C-->02787265 [ynooy.dll]
[1572]explorer.exe-->wininet.dll-->HttpSendRequestA, Type: Inline - RelativeJump 0x771C60A1-->02787417 [ynooy.dll]
[1572]explorer.exe-->wininet.dll-->InternetReadFile, Type: Inline - RelativeJump 0x771C82EA-->02787A4D [ynooy.dll]
[1572]explorer.exe-->wininet.dll-->HttpSendRequestExW, Type: Inline - RelativeJump 0x771CE9C1-->02788040 [ynooy.dll]
[1572]explorer.exe-->wininet.dll-->HttpOpenRequestW, Type: Inline - RelativeJump 0x771CF4D7-->027880AD [ynooy.dll]
[1572]explorer.exe-->wininet.dll-->InternetQueryDataAvailable, Type: Inline - RelativeJump 0x771D89F7-->027871DA [ynooy.dll]
[1572]explorer.exe-->wininet.dll-->InternetWriteFile, Type: Inline - RelativeJump 0x771F8BB9-->02788083 [ynooy.dll]
[1572]explorer.exe-->wininet.dll-->InternetReadFileExA, Type: Inline - RelativeJump 0x771F9100-->02787B29 [ynooy.dll]
[1572]explorer.exe-->wininet.dll-->HttpSendRequestW, Type: Inline - RelativeJump 0x77212EBC-->02787705 [ynooy.dll]
[1572]explorer.exe-->ws2_32.dll-->connect, Type: Inline - RelativeJump 0x71AB4A07-->0278418A [ynooy.dll]
[1572]explorer.exe-->ws2_32.dll-->send, Type: Inline - RelativeJump 0x71AB4C27-->027842DD [ynooy.dll]
[1572]explorer.exe-->ws2_32.dll-->WSASend, Type: Inline - RelativeJump 0x71AB68FA-->0278422D [ynooy.dll]
[1572]explorer.exe-->ws2_32.dll-->WSAConnect, Type: Inline - RelativeJump 0x71AC0C81-->027840DB [ynooy.dll]

Hooks cause the expected and visible system slowdown. Payload can be extracted from processes VA.

When this post was finished I found my own old post about Qakbot, hehe. There is actually nothing new from 2 years old post. Threads merged.

[Codehook]

Nice analysis EP.

Ya I was referring to @7000510D @70005168. I think it must just be a problem with my specific setup, as clearly it works when you tried it and VT's VBox also worked (lol they should harden that better).

The detection itself exploits an old flaw in VirtualPC (and maybe others) that did not handle the 15 byte instruction limit properly and would not raise an exception. I don't know why my setup of VirtualBox is getting tripped up by it though.

When it tries to execute the instruction @ 7000513A it does not raise an exception, instead it 'successfully' executes the instruction and EIP goes to 70005149. I'm using VirtualBox 4.3.12 r93733 with the patched DLLs, no guest additions, DMI modified and running Windows XP SP2. I have tried with hardware virtualization on and off, too.