lordnoteworthy / al-khaser

Public malware techniques used in the wild: Virtual Machine, Emulation, Debuggers, Sandbox detection.

Al-Khaser v0.81

Content

• Introduction
• Possible uses
• Features
• Anti-debugging attacks
• Anti-Dumping
• Timing Attacks
• Human Interaction
• Anti-VM
• Anti-Disassembly
• Requirements
• License

Introduction

al-khaser is a PoC "malware" application with good intentions that aims to stress your anti-malware system. It performs a bunch of common malware tricks with the goal of seeing if you stay under the radar.

Download

You can download the latest release here: x86 | x64.

Sorry, binaries have been removed for now as they were triggering Google's Safe Browsing heuristics.

Possible uses

• You are making an anti-debug plugin and you want to check its effectiveness.
• You want to ensure that your sandbox solution is hidden enough.
• Or you want to ensure that your malware analysis environment is well hidden.

Please, if you encounter any of the anti-analysis tricks which you have seen in a malware, don't hesitate to contribute.

Features

Anti-debugging attacks

• IsDebuggerPresent
• CheckRemoteDebuggerPresent
• Process Environment Block (BeingDebugged)
• Process Environment Block (NtGlobalFlag)
• ProcessHeap (Flags)
• ProcessHeap (ForceFlags)
• Low Fragmentation Heap (LFH)
• NtQueryInformationProcess (ProcessDebugPort)
• NtQueryInformationProcess (ProcessDebugFlags)
• NtQueryInformationProcess (ProcessDebugObject)
• WudfIsAnyDebuggerPresent
• WudfIsKernelDebuggerPresent
• WudfIsUserDebuggerPresent
• NtSetInformationThread (HideThreadFromDebugger)
• NtQueryObject (ObjectTypeInformation)
• NtQueryObject (ObjectAllTypesInformation)
• CloseHanlde (NtClose) Invalide Handle
• SetHandleInformation (Protected Handle)
• UnhandledExceptionFilter
• OutputDebugString (GetLastError())
• Hardware Breakpoints (SEH / GetThreadContext)
• Software Breakpoints (INT3 / 0xCC)
• Memory Breakpoints (PAGE_GUARD)
• Interrupt 0x2d
• Interrupt 1
• Trap Flag
• Parent Process (Explorer.exe)
• SeDebugPrivilege (Csrss.exe)
• NtYieldExecution / SwitchToThread
• TLS callbacks
• Process jobs
• Memory write watching
• Page exception breakpoint detection
• API hook detection (module bounds based)

Anti-injection

• Enumerate modules with EnumProcessModulesEx (32-bit, 64-bit, and all options)
• Enumerate modules with ToolHelp32
• Enumerate the process LDR structures with LdrEnumerateLoadedModules
• Enumerate the process LDR structures directly
• Walk memory with GetModuleInformation
• Walk memory for hidden modules

Anti-Dumping

• Erase PE header from memory
• SizeOfImage

Timing Attacks [Anti-Sandbox]

• RDTSC (with CPUID to force a VM Exit)
• RDTSC (Locky version with GetProcessHeap & CloseHandle)
• Sleep -> SleepEx -> NtDelayExecution
• Sleep (in a loop a small delay)
• Sleep and check if time was accelerated (GetTickCount)
• SetTimer (Standard Windows Timers)
• timeSetEvent (Multimedia Timers)
• WaitForSingleObject -> WaitForSingleObjectEx -> NtWaitForSingleObject
• WaitForMultipleObjects -> WaitForMultipleObjectsEx -> NtWaitForMultipleObjects
• IcmpSendEcho (CCleaner Malware)
• CreateWaitableTimer
• CreateTimerQueueTimer
• Big crypto loops (todo)

Human Interaction / Generic [Anti-Sandbox]

• Mouse movement
• File names like sample.exe or sandbox.exe.
• Total Physical memory (GlobalMemoryStatusEx)
• Disk size using DeviceIoControl (IOCTL_DISK_GET_LENGTH_INFO)
• Disk size using GetDiskFreeSpaceEx (TotalNumberOfBytes)
• Mouse (Single click / Double click) (todo)
• DialogBox (todo)
• Scrolling (todo)
• Execution after reboot (todo)
• Count of processors (Win32/Tinba - Win32/Dyre)
• Sandbox known product IDs (todo)
• Color of background pixel (todo)
• Keyboard layout (Win32/Banload) (todo)
• Genuine Windows installation.
• Known Sandbox hostnames and usernames

Anti-Virtualization / Full-System Emulation

• Registry key value artifacts

  • HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) (VBOX)
  • HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) (QEMU)
  • HARDWARE\Description\System (SystemBiosVersion) (VBOX)
  • HARDWARE\Description\System (SystemBiosVersion) (QEMU)
  • HARDWARE\Description\System (VideoBiosVersion) (VIRTUALBOX)
  • HARDWARE\Description\System (SystemBiosDate) (06/23/99)
  • HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) (VMWARE)
  • HARDWARE\DEVICEMAP\Scsi\Scsi Port 1\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) (VMWARE)
  • HARDWARE\DEVICEMAP\Scsi\Scsi Port 2\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) (VMWARE)
  • SYSTEM\ControlSet001\Control\SystemInformation (SystemManufacturer) (VMWARE)
  • SYSTEM\ControlSet001\Control\SystemInformation (SystemProductName) (VMWARE)

• Registry Keys artifacts

  • HARDWARE\ACPI\DSDT\VBOX__ (VBOX)
  • HARDWARE\ACPI\FADT\VBOX__ (VBOX)
  • HARDWARE\ACPI\RSDT\VBOX__ (VBOX)
  • SOFTWARE\Oracle\VirtualBox Guest Additions (VBOX)
  • SYSTEM\ControlSet001\Services\VBoxGuest (VBOX)
  • SYSTEM\ControlSet001\Services\VBoxMouse (VBOX)
  • SYSTEM\ControlSet001\Services\VBoxService (VBOX)
  • SYSTEM\ControlSet001\Services\VBoxSF (VBOX)
  • SYSTEM\ControlSet001\Services\VBoxVideo (VBOX)
  • SOFTWARE\VMware, Inc.\VMware Tools (VMWARE)
  • SOFTWARE\Wine (WINE)
  • SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters (HYPER-V)
  • SYSTEM\CurrentControlSet\Services\Disk\Enum
  • SYSTEM\CurrentControlSet\Enum\IDE
  • SYSTEM\CurrentControlSet\Enum\SCSI

• File system artifacts

  • "system32\drivers\VBoxMouse.sys"
  • "system32\drivers\VBoxGuest.sys"
  • "system32\drivers\VBoxSF.sys"
  • "system32\drivers\VBoxVideo.sys"
  • "system32\vboxdisp.dll"
  • "system32\vboxhook.dll"
  • "system32\vboxmrxnp.dll"
  • "system32\vboxogl.dll"
  • "system32\vboxoglarrayspu.dll"
  • "system32\vboxoglcrutil.dll"
  • "system32\vboxoglerrorspu.dll"
  • "system32\vboxoglfeedbackspu.dll"
  • "system32\vboxoglpackspu.dll"
  • "system32\vboxoglpassthroughspu.dll"
  • "system32\vboxservice.exe"
  • "system32\vboxtray.exe"
  • "system32\VBoxControl.exe"
  • "system32\drivers\vmmouse.sys"
  • "system32\drivers\vmhgfs.sys"
  • "system32\drivers\vm3dmp.sys"
  • "system32\drivers\vmci.sys"
  • "system32\drivers\vmhgfs.sys"
  • "system32\drivers\vmmemctl.sys"
  • "system32\drivers\vmmouse.sys"
  • "system32\drivers\vmrawdsk.sys"
  • "system32\drivers\vmusbmouse.sys"

• Directories artifacts

  • "%PROGRAMFILES%\oracle\virtualbox guest additions\"
  • "%PROGRAMFILES%\VMWare\"

• Memory artifacts

  • Interupt Descriptor Table (IDT) location
  • Local Descriptor Table (LDT) location
  • Global Descriptor Table (GDT) location
  • Task state segment trick with STR

• MAC Address

  • "\x08\x00\x27" (VBOX)
  • "\x00\x05\x69" (VMWARE)
  • "\x00\x0C\x29" (VMWARE)
  • "\x00\x1C\x14" (VMWARE)
  • "\x00\x50\x56" (VMWARE)
  • "\x00\x1C\x42" (Parallels)
  • "\x00\x16\x3E" (Xen)
  • "\x0A\x00\x27" (Hybrid Analysis)

• Virtual devices

  • "\\.\VBoxMiniRdrDN"
  • "\\.\VBoxGuest"
  • "\\.\pipe\VBoxMiniRdDN"
  • "\\.\VBoxTrayIPC"
  • "\\.\pipe\VBoxTrayIPC")
  • "\\.\HGFS"
  • "\\.\vmci"

• Hardware Device information

  • SetupAPI SetupDiEnumDeviceInfo (GUID_DEVCLASS_DISKDRIVE)
    • QEMU
    • VMWare
    • VBOX
    • VIRTUAL HD
  • Power policies (S1-S4 states, thermal control)

• System Firmware Tables

  • SMBIOS string checks (VirtualBox)
  • SMBIOS string checks (VMWare)
  • SMBIOS string checks (Qemu)
  • SMBIOS number of tables (Qemu, VirtualBox)
  • ACPI string checks (VirtualBox)
  • ACPI string checks (VMWare)
  • ACPI string checks (Qemu)

• Driver Services

  • VirtualBox
  • VMWare

• Adapter name

  • VMWare

• Windows Class

  • VBoxTrayToolWndClass
  • VBoxTrayToolWnd

• Network shares

  • VirtualBox Shared Folders

• Processes

  • vboxservice.exe (VBOX)
  • vboxtray.exe (VBOX)
  • vmtoolsd.exe(VMWARE)
  • vmwaretray.exe(VMWARE)
  • vmwareuser(VMWARE)
  • VGAuthService.exe (VMWARE)
  • vmacthlp.exe (VMWARE)
  • vmsrvc.exe(VirtualPC)
  • vmusrvc.exe(VirtualPC)
  • prl_cc.exe(Parallels)
  • prl_tools.exe(Parallels)
  • xenservice.exe(Citrix Xen)
  • qemu-ga.exe (QEMU)

• WMI

  • SELECT * FROM Win32_Bios (SerialNumber) (GENERIC)
  • SELECT * FROM Win32_PnPEntity (DeviceId) (VBOX)
  • SELECT * FROM Win32_NetworkAdapterConfiguration (MACAddress) (VBOX)
  • SELECT * FROM Win32_NTEventlogFile (VBOX)
  • SELECT * FROM Win32_Processor (NumberOfCores and ProcessorId) (GENERIC)
  • SELECT * FROM Win32_LogicalDisk (Size) (GENERIC)
  • SELECT * FROM Win32_ComputerSystem (Model and Manufacturer) (GENERIC)
  • SELECT * FROM MSAcpi_ThermalZoneTemperature CurrentTemperature) (GENERIC)
  • SELECT * FROM Win32_Fan (GENERIC)

• DLL Exports and Loaded DLLs

  • avghookx.dll (AVG)
  • avghooka.dll (AVG)
  • snxhk.dll (Avast)
  • kernel32.dll!wine_get_unix_file_nameWine (Wine)
  • sbiedll.dll (Sandboxie)
  • dbghelp.dll (MS debugging support routines)
  • api_log.dll (iDefense Labs)
  • dir_watch.dll (iDefense Labs)
  • pstorec.dll (SunBelt Sandbox)
  • vmcheck.dll (Virtual PC)
  • wpespy.dll (WPE Pro)
  • cmdvrt32.dll (Comodo Container)
  • cmdvrt64.dll (Comodo Container)

• CPU

  • Hypervisor presence using (EAX=0x1)
  • Hypervisor vendor using (EAX=0x40000000)
    • "KVMKVMKVM\0\0\0" (KVM)
      • "Microsoft Hv"(Microsoft Hyper-V or Windows Virtual PC)
      • "VMwareVMware"(VMware)
      • "XenVMMXenVMM"(Xen)
      • "prl hyperv "( Parallels) -"VBoxVBoxVBox"( VirtualBox)

• NtQueryLicenseValue with Kernel-VMDetection-Private as license value.

Anti-Analysis

• Processes
  • OllyDBG / ImmunityDebugger / WinDbg / IDA Pro / X64dbg / Cheat Engine
  • SysInternals Suite Tools (Process Explorer / Process Monitor / Regmon / Filemon, TCPView, Autoruns)
  • Wireshark / Dumpcap / Fiddler / Http Debugger
  • ProcessHacker / SysAnalyzer / HookExplorer / SysInspector
  • ImportREC / PETools / LordPE
  • JoeBox Sandbox
  • Resource Hacker
  • Frida

Anti-Disassembly

• Jump with constant condition
• Jump instruction with same target
• Impossible disassembly
• Function Pointers
• Return Pointer Abuse

Macro malware attacks

• Document_Close / Auto_Close.
• Application.RecentFiles.Count

Code/DLL Injections techniques

• CreateRemoteThread
• SetWindowsHooksEx
• NtCreateThreadEx
• RtlCreateUserThread
• APC (QueueUserAPC / NtQueueApcThread)
• RunPE (GetThreadContext / SetThreadContext)

Authors

• Mattiwatti: Matthijs Lavrijsen
• gsuberland: Graham Sutherland
• hFireF0x: hfiref0x

Pull requests welcome. Please read the Developer Guidelines on our wiki if you wish to contribute to the project.

References

• An Anti-Reverse Engineering Guide By Josh Jackson.
• Anti-Unpacker Tricks By Peter Ferrie.
• The Art Of Unpacking By Mark Vincent Yason.
• Walied Assar's blog http://waleedassar.blogspot.de/.
• Pafish tool: https://github.com/a0rtega/pafish.
• PafishMacro by JoeSecurity: https://github.com/joesecurity/pafishmacro

al-khaser's Issues

Improve disk size IOCTL check

Right now we always check PhysicalDisk0, which may not be the OS disk and may be part of an array. I'll improve this to detect which drive(s) the C volume is present on and enumerate physical disk size that way., falling back to the old PhysicalDisk0 check if anything goes wrong.

Runtime Library error in x86/Debug configuration

Under Debug configuration the option "C/C++-Code Generation-Runtime Library" has value /MT (Multi-threaded), whereas should be "Multi-threaded Debug", /MTd. Currently build fails with the linking error

DLL Injection checks

Is there ways to detect if malicious dll injected?

TLS thread attach callback getting false positive

I built commit 350631a and I get TLS thread attach callback as Bad, no debuggers attached
Windows 7 x64 Administator account
here is full log
https://gist.github.com/friuns2/9c5a72935972b291a82e93bff4cd7f70

Program raise exception in Cuckoo

The program don't drop a file contains all results as it should.

When I searched in cuckoo behavioral analysis what is going wrong, I found that the exception below was raise before the process die.
stacktrace: RaiseException+0x3d FreeEnvironmentStringsW-0x373 kernelbase+0xa49d @ 0x7fefdd7a49d al-khaser_x64+0x1b65 @ 0x13fc31b65 al-khaser_x64+0xe1e8 @ 0x13fc3e1e8 BaseThreadInitThunk+0xd CreateThread-0x53 kernel32+0x1652d @ 0x77a8652d RtlUserThreadStart+0x21 strchr-0x3df ntdll+0x2c521 @ 0x77cbc521
exception.instruction_r: 48 81 c4 c8 00 00 00 c3 48 85 f6 74 08 83 3b 00
exception.symbol: RaiseException+0x3d FreeEnvironmentStringsW-0x373 kernelbase+0xa49d
exception.instruction: add rsp, 0xc8
exception.module: KERNELBASE.dll
exception.exception_code: 0xc000008e
exception.offset: 42141
exception.address: 0x7fefdd7a49d
registers.r14: 0
registers.r15: 0
registers.rcx: 2856608
registers.rsi: 0
registers.r10: 0
registers.rbx: 0
registers.rsp: 2883184
registers.r11: 514
registers.r8: 0
registers.r9: 0
registers.rdx: 0
registers.r12: 0
registers.rbp: 0
registers.rdi: 0
registers.rax: 2012718689
registers.r13: 0

VM OS: Windows 7 - 64 bits
VM RAM: 6144Mo

Cuckoo version : 2.0.6

I try running the binary (al-khaser_x64.exe) on 2 differents sandbox, first in local, second on Internet.

Here you can find the report of the second try: https://cuckoo.cert.ee/analysis/870150/summary/

Overhaul timing attack code

The timing attack functions don't seem to actually return any useful success/failure state right now. I know the goal is to outrun maximum execution periods, but it'd be useful to have the tests fail if APIs don't return the expected values.

It looks like when they were originally written into the main function they were done separately so that the check's message could be printed first, but at the same time did not return a true/false state and weren't called with exec_check. I've since modified the way we display check text (see commit bbf020b) so this should no longer be a problem. Of course we can't pass a parameter to exec_check right now but we can fix that.

I think we need to do a couple of things:

1. Modify the timing attack functions to return a TRUE/FALSE state.
2. Add a parameterised version of exec_check (probably using templates)
3. Switch back to using exec_check to call those functions from main.

I've commited these changes to the timing-attack-overhaul branch for review. See commit f8d1489 for more info.

I've assigned @LordNoteworthy to review the branch before I merge it. Let me know if you have any feedback.

Got a Question

How did you learn to use the functions in the windows.h file ?

Bugreport?

Hello,

how do you take bugreports, should I give you patches or you fix it on your own, do you need separate issue for each bug or combined issue post?

Thanks.

Detecting Comodo

DLL hijacking check with GetModuleFileName

Call GetModuleFileName on a bunch of common DLL names, see if they're inside the system directory (call GetSystemDirectory to get this path), and fail if they aren't. This detects DLL hijacking.

FirmwareACPI/SMBIOS for Qemu/VMWare

Hello, add to the FirmwareACPI function a validation of known virtual machines:
-VMWare:
PBYTE vmwString = (PBYTE)"VMW";
size_t vmwStringLen = 3;
PBYTE vmwareUpperString = (PBYTE)"VMWARE";
size_t vmwareUpperStringLen = 6;

		if (find_str_in_data(vmwString, vmwStringLen, table, tableSize) ||
			find_str_in_data(vmwareUpperString, vmwareUpperStringLen, table, tableSize)) {
			result = TRUE;
		}

-QEMU:
PBYTE bxpString = (PBYTE)"BXP";
size_t bxpStringLen = 3;
PBYTE bochsUpperString = (PBYTE)"BOCHS";
size_t bochsUpperStringLen = 5;

		if (find_str_in_data(bxpString, bxpStringLen, table, tableSize) ||
			find_str_in_data(bochsUpperString, bochsUpperStringLen, table, tableSize)) {
			result = TRUE;
		}

It can also be useful trick with checking MSR. The value of most of them in the virtual machine is zero,while on the real - no. But this requires a driver, for example, I used the AsIO.sys like this:

void getMSRValue(DWORD reg, DWORD64 *val) {
	if (drvHandle == NULL) { return; }
	DWORD dwBytes;
	if (DeviceIoControl( drvHandle, 0x0a0406458, &reg, sizeof(DWORD),
					val, sizeof(DWORD64), &dwBytes, NULL) == NULL) { 								 
                       printf("DeviceIoControl error: %d\n", GetLastError()); 	
        }
}

PC:

VBox:

VMWare:

Thanks!

System Resources layout as a potential VM detection vector

I was reading XPN's article about a TotalMeltdown exploit and saw that they had updated their code to check which physical addresses were mapped when doing their search for an _EPROCESS struct, to avoid BSOD. They do this via the RESOURCEMAP registry key, which has some REG_RESOURCE_LIST type values. I hadn't come across that registry value type before and it turns out that it's a fairly in-depth struct that describes hardware resources.

This got me thinking - do the physical memory maps change between a host and a VM, and are VM maps generally the same on every box? I can answer the first one: yes. I wrote a tool to dump the address lists and here are the results:

Host box 1 (Win10, 32GB RAM):

[*] Getting physical memory regions from registry
[*] Reading data from Hardware\ResourceMap\System Resources\Physical Memory\.Translated
  --> Memory region found: 0000000000001000 - 000000000009d000
  --> Memory region found: 00000000cb52d000 - 00000000cb98c000
[*] Reading data from Hardware\ResourceMap\System Resources\Reserved\.Translated
  --> Memory region found: 0000000000001000 - 000000000009d000
[*] Reading data from Hardware\ResourceMap\System Resources\Loader Reserved\.Raw
  --> Memory region found: 0000000000000000 - 00000000000a0000
  --> Memory region found: 00000000cb526000 - 00000000cb52d000
  --> Memory region found: 00000000fec00000 - 00000000fec01000

Host box 2 (Win10, 32GB RAM, Hyper-V enabled):

[*] Getting physical memory regions from registry
[*] Reading data from Hardware\ResourceMap\System Resources\Physical Memory\.Translated
  --> Memory region found: 0000000000001000 - 000000000009d000
[*] Reading data from Hardware\ResourceMap\System Resources\Reserved\.Translated
  --> Memory region found: 0000000000001000 - 000000000009d000
  --> Memory region found: 00000000001f5000 - 00000000001fe000
  --> Memory region found: 00000000002fe000 - 00000000003fe000
[*] Reading data from Hardware\ResourceMap\System Resources\Loader Reserved\.Raw
  --> Memory region found: 0000000000000000 - 00000000000a0000
  --> Memory region found: 00000000001f5000 - 00000000001fe000
  --> Memory region found: 0000000000293000 - 0000000000297000
  --> Memory region found: 0000000000875000 - 000000000095a000
  --> Memory region found: 000000000364c000 - 0000000003675000
  --> Memory region found: 000000006929d000 - 000000007fa00000

VirtualBox VM on host 1 (Win8.1 x64, 2GB RAM assigned):

[*] Getting physical memory regions from registry
[*] Reading data from Hardware\ResourceMap\System Resources\Physical Memory\.Translated
  --> Memory region found: 0000000000001000 - 000000000009f000
[*] Reading data from Hardware\ResourceMap\System Resources\Reserved\.Translated
  --> Memory region found: 0000000000001000 - 000000000000e000
[*] Reading data from Hardware\ResourceMap\System Resources\Loader Reserved\.Raw
  --> Memory region found: 0000000000000000 - 000000000000e000
  --> Memory region found: 00000000000f0000 - 0000000000100000

VirtualBox VM on host 1 (Win8.1 x64, 10GB RAM assigned):

[*] Getting physical memory regions from registry
[*] Reading data from Hardware\ResourceMap\System Resources\Physical Memory\.Translated
  --> Memory region found: 0000000000001000 - 000000000009f000
[*] Reading data from Hardware\ResourceMap\System Resources\Reserved\.Translated
  --> Memory region found: 0000000000001000 - 000000000000e000
[*] Reading data from Hardware\ResourceMap\System Resources\Loader Reserved\.Raw
  --> Memory region found: 0000000000000000 - 000000000000e000
  --> Memory region found: 00000000000f0000 - 0000000000130000

Hyper-V VM on host 2 (Win10, dynamic RAM):

[*] Getting physical memory regions from registry
[*] Reading data from Hardware\ResourceMap\System Resources\Physical Memory\.Translated
  --> Memory region found: 0000000000001000 - 00000000000a0000
[*] Reading data from Hardware\ResourceMap\System Resources\Reserved\.Translated
  --> Memory region found: 0000000000001000 - 00000000000a0000
[*] Reading data from Hardware\ResourceMap\System Resources\Loader Reserved\.Raw
  --> Memory region found: 0000000000000000 - 00000000000a0000
  --> Memory region found: 000000007eee9000 - 000000007ef1b000

HyperV VM on host 2 (Win10, 2GB RAM assigned):

[*] Getting physical memory regions from registry
[*] Reading data from Hardware\ResourceMap\System Resources\Physical Memory\.Translated
  --> Memory region found: 0000000000001000 - 00000000000a0000
[*] Reading data from Hardware\ResourceMap\System Resources\Reserved\.Translated
  --> Memory region found: 0000000000001000 - 00000000000a0000
[*] Reading data from Hardware\ResourceMap\System Resources\Loader Reserved\.Raw
  --> Memory region found: 0000000000000000 - 00000000000a0000
  --> Memory region found: 000000007eee9000 - 000000007ef1b000

There are patterns here that we can probably exploit, although I'd like more data samples to be sure.

A preliminary test would be:

• If Reserved\.Translated has anything other than 1 entry, skip test.
• If Loader Reserved\.Raw has anything other than 2 entries, skip test.
• Detect VirtualBox if Reserved\.Translated is 0000000000000000 - 000000000000e000 and Loader Reserved\.Raw contains an entry equal to 0000000000000000 - 000000000000e000.
• Detect HyperV if Reserved\.Translated is 0000000000001000 - 00000000000a0000 and Loader Reserved\.Raw contains an entry equal to 0000000000000000 - 00000000000a0000.

I could do with more data points before I write this up, so @LordNoteworthy it'd be great if you could try this on your side with various VM solutions.

Here's the code for the test utility: PhysMemResourceList.c.txt

If you're feeling lazy and don't wanna compile the above you can use my compiled binary (requires VC Runtime 14 x86): PhysMemResourceList.zip

Let me know what results you get :)

the ACPI virtual-machine checks always return true under winxp

the ACPI checks (vmware_firmware_ACPI, vbox_firmware_ACPI ...) always return true since

DWORD tableSize = enum_system_firmware_tables(static_cast<DWORD>('ACPI'), tableNames, 4096);

API EnumSystemFirmwareTables is not available under winxp

Should i do TLS checks in a while loop or only at application launch?

Should i do TLS checks in a while loop or only at application launch?

i tried put TLS checks in a while loop, then something goes wrong it freezes for 4 seconds and returns true

first interation
0 TLS process attach callback (36 ms)
0 TLS thread attach callback (154 ms)

second interation
1 TLS process attach callback (4999843 ms)
0 TLS thread attach callback (435 ms)

ATA IDENTIFY checks

We can issue an ATA IDENTIFY command to the disk and see if the returned parameters match known ones from VMs.

XP support, VMDriverServices

Hello,

coupe of questions I would like to ask:

1. does this program intended to support Windows XP?

If so, it cannot work here because uses function that is missing on Windows XP - EnumProcessModulesEx.

2. The purpose of VMDriverServices routine in Services.cpp
   

   al-khaser/al-khaser/AntiVM/Services.cpp

   Line 5 in 5eea3ff

   BOOL VMDriverServices()

What actually it supposed to detect? VM drivers/services of host or guest? There is no description of this function and it behavior is unclear.

I'm asking because this list

const TCHAR* KnownVMServices[KnownServiceCount] = { L"VBoxDrv", L"VBoxNetAdp", L"VBoxNetLwf", L"VBoxUSB", L"VBoxUSBMon", L"VMnetAdapter", L"VMnetBridge", L"VMnetuserif", L"vmusb", L"vmx86" };

first part contain VirtualBox drivers that are host only. They do not present inside VM. Second part of this list is VMware drivers, but it is little bit old and should include at least this one listed here -> https://usuaria.org.ar/sites/default/files/documentos/1245_SYMANTEC_FIREEYE.pdf However even that list is incomplete and if I look on my vmware I see more values to add (vmusbmouse, vmmemctl, vmx_svga). Should I add it, or VMDriverServices work as expected?

Thanks.

Any way detect CE VEH debugger/page exceptions?

any way detect CE VEH debugger/page exceptions?

"TLS thread attach callback" also seems work for me in reverse logic. It returns Bad for me if nothing attached but if i attach VEH debugger it returns Good for me. Not sure if its related

CE debugger detection via OutputDebugString

Cheat Engine is actually dumb enough to call OutputDebugString with a load of trivially identifiable stuff that we can use to detect that it is debugging something on the box.

#bug ascii_to_wide_str maybe have a malloc issues

TCHAR* ascii_to_wide_str(CHAR* lpMultiByteStr)
{

/* Get the required size */
CONST INT iSizeRequired = MultiByteToWideChar(CP_ACP, 0, lpMultiByteStr, -1, NULL, 0);

TCHAR *lpWideCharStr = (TCHAR*)MALLOC(**iSizeRequired** * sizeof(TCHAR));

/* Do the conversion */
INT iNumChars =  MultiByteToWideChar(CP_ACP, 0, lpMultiByteStr, -1, lpWideCharStr, iSizeRequired);

return lpWideCharStr;

}

the al-khaseris not functioning properly

Dynamic Protection Engine

To add:

http://www.rohitab.com/discuss/topic/42453-dype/

RunPE and ErasePE access violation error

when use runPE and ErasePe together erasePE zeromemory give an error access violation writing location ?

port to Qt5

port to Qt5
process.obj : error LNK2019: unresolved external symbol "void __cdecl print_results(int,wchar_t *)" (?print_results@@YAXHPA_W@Z) referenced in function "void __cdecl analysis_tools_process(void)" (?analysis_tools_process@@YAXXZ)

why ProcessJob default return value is true?

I get always returned true because of this line, even if i don't attach any debuggers, is this a bug?

BOOL ProcessJob()
{
BOOL foundProblem = TRUE;

Problem in function "serial_number_bios_wmi()".

In " Anti VM -> Generic.cpp -> serial_number_bios_wmi() "

(StrStrI(vtProp.bstrVal, _T("0")) != 0) || // VBox

I think this condition is not good, cause it use StrStr() and there is only 1 character, "0".
Thank you.

Memory leak.

Hello.
File: Anti VM/Generic.cpp, variable LPTSTR buffer = NULL; (326) will be allocated if no one StrStrI(buffer succeeded. Put it in function's global namespace and check nor NULL before return.

check vtProp.vt == VT_BSTR before accessing vtProp.bstrVal

Crashed in serial_number_bios_wmi since hRes = pclsObj->Get(_T("SerialNumber"), 0, &vtProp, 0, 0); failed and we got an invalid vtProp here, which is accessed later StrStrI(vtProp.bstrVal, _T("VMWare")) != 0)

A quick fix is to check if hres is S_OK and vtprop.vt is BT_STR if (hRes == S_OK && vtProp.vt == VT_BSTR) before doing the string comparaison.

Versioning and CI

We need a better software versioning for the tool. At the moment, it have this scheme: a.xy when xy is incremented when a new malware-trick is added or bugs got fixed.

I suggest to move to something like this: a.b.c:

• a: major release
• b: minor release
• c: build number

If we make a major change, we move from version 1.0.0 to 2.0.0 (like an API change/break, huge enhancement in the framework).
If we make a smaller change, we move from 1.0.0 to 1.1.0 (add a new malware-trick).
If we make a minor change, then we go from 1.0.0 to 1.0.1 (we fixed some bugs or refactored some code).

For continuous integration, it would be nice to integrate TravisCI or Appveyor to Github, so we can build and run some tests when somebody make commits/PR. I did a quick search and found out Appveyor to be suitable for our needs, they offer free Windows VM with different VS versions where we can do our builds/tests.

Open to any suggestions.

Anti cuckoo and SIEM detect

anti cuckoo like this https://github.com/David-Reguera-Garcia-Dreg/anticuckoo

Wrong PEB offset in Anti-VM/generic

Hey, looks like you got a typo into the Anti-VM/generic.cpp file.
The PEB offset on a 64b environment is 0x60, not 0x30 as on 32b :)

PR : #92

'Anti Debug\SetHandleInformation_API.cpp' 'Anti Debug\SetHandleInformation_API.h'

what about this files, i think thay are need!

Contribution / development guidelines

As we start to expand the project and include specific ways of doing things (e.g. the API class stuff) we could do with some documentation that helps contributors get up to speed on the codebase.

MmMapIoSpace vm detect

Maybe write this checks?

Parallels Software
Virtual Machine
VirtualBox
QEMU BIOS
VMware
Bochs

idag and idaq

Hi, i think this https://github.com/LordNoteworthy/al-khaser/blob/master/al-khaser/Anti%20Analysis/process.cpp#L20 should be changed to "idaq.exe"

al-khaser/Anti Analysis/process.cpp --> Line 20

Checking for differences between code in memory and on disk

Checking code for modifications in memory, could be added?

Here is article i tried compile code it working for some extent
https://www.codeproject.com/Articles/17636/Dynamic-TEXT-Section-Image-Verification

Where \Anti Dump\SizeOfImage.h and Anti Dump\SizeOfImage.cpp ?

Error 1 error C1083: Cannot open source file: 'Anti Dump\SizeOfImage.cpp': No such file or directory

Error 2 error C1083: Cannot open include file: '..\Anti Dump\SizeOfImage.h': No such file or directory

Technical descriptions of checks in the Wiki

I've started writing up documentation around the different checks we do. This will all go together in the GitHub wiki for this repo.

Qemu-GA

I think qemu-ga.exe should be added to the "Processes" section
https://any.run/

Any.Run is an "amas"(automated malware analysis system). qemu-ga.exe is a agent of qemu virt. system.

Problem with rdtsc diff using vmexit

I think there is a problem with your RDTSC diff using VMEXIT.
Pafish detects my VM using this trick but not al-khaser.
I think this is due to the missing 500 ms sleep present in the pafish one :
for (i = 0; i < 10; i++) {
avg = avg + rdtsc_diff_vmexit();
Sleep(500);
}

Wider range of check return values

I'd like to overhaul the way we run checks and standardise how we handle errors. Right now we just return true or false, which isn't very useful.

What I propose is the following:

First we replace BOOL return values with an enum of {good, bad, warn, fail}. Good means the check completed successfully and nothing was detected. Bad means the check completed successfully and detected something. Warn means the outcome of the check was inconclusive. Fail means that some prerequisite was not met or an API call failed.

Secondly we add a standardised mechanism for reporting additional information from checks that doesn't mess up the output format. Effectively we offer a printf equivalent function for output that pushes messages to an std::vector which we can then print out after the check completes. I'd like to also have these messages tagged with some sort of level so that we can filter them - by default only showing errors (so we can say why a check failed if it failed), but with the ability to specify a debug level on the command line at a later date for increased verbosity.

@LordNoteworthy I'd like your feedback on this before I go ahead and start the work.

disk_size_wmi acting weird with llVal

Hi everyone,

I tried your solution in order to create an hidden Qemu/KVM Sandbox. But when i tried your program on Windows 7 64 bits with the al-khaser_x64.exe i never pass the flag "Checking hard disk size using WMI".
So i looked at the code and make my partition up to 90GB and it still not pass.
I reproduced your code with the MSDN and figured out that you use the parameter vtProp.llVal in order to get the size of the disk. But when i do the same llVal send me random values each time I launch the program. Instead I used the parameter bstrVal which give the exact amount of Bytes on the disk.

I also have to mention that with the x86.exe the "Checking hard disk size using WMI" pass everytime.

Antidump + cURL

When i run AntiDump detection the cURL stop working, if i use any other detection its working.

[*] Erasing PE header from memory
[*] Increasing SizeOfImage in PE Header to: 0x100000
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server
curl_easy_perform() failed: Couldn't connect to server

APIs.cpp GetGetProductInfo?

{ API_IDENTIFIER::API_GetProductInfo,"kernel32.dll","GetGetProductInfo",API_MIN_OS_VERSION::WIN_XP },//APIs.cpp line 10

GetGetProductInfo supposed to be GetProductInfo?

#bug process.cpp line 23 and 28 is same

	_T("dumpcap.exe"),			// Network traffic dump tool
	_T("HookExplorer.exe"),		// Find various types of runtime hooks
	_T("ImportREC.exe"),		// Import Reconstructor
	_T("PETools.exe"),			// PE Tool
	_T("LordPE.exe"),			// LordPE
	**//_T("dumpcap.exe"),		// same with line 23**

Move to Visual Studio 2017

Qemu-QA

I think qemu-qa.exe should be added to the "Processes" section

QueueUserAPC always terminate without error

al-khaser/al-khaser/CodeInjection/QueueUserAPC.cpp

Lines 34 to 35 in c1c491d

	if (hThread == NULL)
	return FALSE;

hThread is initialized with NULL and have not been reassigned any value, hence program always exit prematurely.

VEH table debugger detection

One approach is to manually enumerate the VEH table to see if a debugger has attached itself, although it's a bit tricky because the VEH table pointer is internal to ntdll and it seems the general approach is to AOB-scan the module to find known code that points to that table. This isn't very portable, so I'll have to try to find a better way.

Disk size reporting inconsistency check

Right now we just look to see if the disk size is under ~80GB for each check, but I think it'd be useful to retrieve disk size using every known method and verify that they all give the same results. This is a similar approach to how rootkit detection works (e.g. read registry using regular API, read registry manually from the hive file, compare results).

Precompiled 32 bit binary

Precompiled 32 bit binary would be nice, just a thought.