al-khaser is a proof-of-concept testing application that executes the full catalog of known anti-debugging, anti-VM, anti-sandbox, and timing-based tricks so defenders can verify their analysis environments stay undetected.
| Tool | ayoubfaouzi/al-khaser — a benign PoC "malware" application that stresses anti-malware systems by replaying common evasion techniques |
| Category | Anti-analysis test harness / evasion audit tool written in C++ |
| Primary Use | Verifying that sandbox solutions, anti-debug plugins, and malware analysis VMs (VirtualBox, VMware, QEMU, Hyper-V, KVM, Xen) are properly hardened against detection |
| Safe Use | Intended solely for authorized defensive testing in owned labs and analysis environments; the project explicitly describes itself as PoC malware "with good intentions" for AV and sandbox validation |
| Telemetry Note | The binary itself is loud by design: it queries registry keys, WMI classes, firmware tables, and timing sources in sequence, producing a distinctive API-call profile that EDR and monitoring tools can flag and defenders can use as a canary |
al-khaser, hosted at ayoubfaouzi/al-khaser and currently standing at over 7,100 stars with a GPL-2.0 license, occupies a peculiar and genuinely useful niche in the security tooling ecosystem. It describes itself as a PoC "malware" application with good intentions: a benign C++ binary whose sole purpose is to execute the collected repertoire of anti-analysis tricks seen in real malware, so that defenders can measure whether their defenses light up. The author frames it as a way to "stress your anti-malway system" — the README's actual wording is "stress your anti-malware system" — and see whether you stay under the radar. In other words, it is a test oracle for the other side of the arms race.
The stated use cases in the README are explicitly defensive. If you are building an anti-debug plugin, you run al-khaser to check its effectiveness. If you operate an automated sandbox, you run it to verify the guest is sufficiently hidden. If you maintain a malware analysis lab, you run it to confirm your VM images do not leak the artifacts that live samples look for. This positioning matters for anyone triaging the repository's malware and av-bypass topics: the code demonstrates techniques, but it ships no payload, no network functionality, and no persistence — it only detects and reports.
Operationally, the tool is refreshingly simple. The current release is Al-Khaser v0.81, and prebuilt x86 and x64 binaries are distributed on the project's GitHub releases page inside password-protected 7z archives, with the password deliberately stored in the release workflow file (.github/workflows/release.yml) so that automated detonation pipelines can extract it. Command-line invocation centers on a --check option that accepts a category name and can be repeated to compose a run, plus --sleep/--delay (default 600 seconds) to control timing-based tests. For example, al-khaser.exe --check DEBUG --check TIMING_ATTACKS --sleep 30 exercises only the anti-debugging and timing suites with a shortened delay — a sensible first pass for a lab audit.
The check taxonomy is granular and worth understanding, because it doubles as a taxonomy of real-world evasion behavior. The --check flag recognizes categories including TLS (thread local storage callback checks), DEBUG, INJECTION, CODE_INJECTIONS, GEN_SANDBOX, per-hypervisor checks for VBOX, VMWARE, VPC, QEMU, KVM, XEN, WINE, PARALLELS, and HYPERV, plus TIMING_ATTACKS, DUMPING_CHECK, ANALYSIS_TOOLS, and ANTI_DISASSM. Selective execution like al-khaser.exe --check VMWARE --check QEMU lets an operator target exactly the detection surface relevant to a given analysis host without wading through the entire suite.
The anti-debugging module is the deepest section of the README, cataloging roughly thirty techniques that span from the trivially old to the quietly clever. Classic API-based checks like IsDebuggerPresent and CheckRemoteDebuggerPresent sit alongside PEB inspection via the BeingDebugged flag and NtGlobalFlag, heap forensics through ProcessHeap Flags/ForceFlags and low-fragmentation heap behavior, and NtQueryInformationProcess queries against ProcessDebugPort, ProcessDebugFlags, and ProcessDebugObject. Deeper still are NtSetInformationThread with HideThreadFromDebugger, invalid-handle abuse of NtClose, hardware and software breakpoints (SEH/GetThreadContext and INT3/0xCC), PAGE_GUARD memory breakpoints, Interrupt 0x2d and Interrupt 1, trap-flag manipulation, parent-process checks against Explorer.exe, SeDebugPrivilege ownership of Csrss.exe, and API hook detection based on module bounds. For a sandbox engineer, each of these is a unit test your instrumentation either survives or fails.
The timing-attack suite deserves its own attention because it is the workhorse of modern sandbox evasion. al-khaser implements RDTSC-based timing with CPUID to force a VM exit, the Locky-style RDTSC variant pairing GetProcessHeap with CloseHandle, and the full Sleep → SleepEx → NtDelayExecution chain. It also checks whether sleep time was accelerated using GetTickCount — a direct probe of sandboxes that fast-forward delays — and exercises SetTimer, timeSetEvent, the WaitForSingleObject/WaitForMultipleObjects families down to their ntdll counterparts, CreateWaitableTimer, CreateTimerQueueTimer, and the IcmpSendEcho technique attributed in the README to the CCleaner malware. The default 600-second sleep exists precisely because unmodified sandboxes that truncate long waits will betray themselves.
Generic sandbox detection blends environmental heuristics that are individually unremarkable but collectively devastating to a lazy lab image. The tool looks for mouse movement, suspicious file names such as sample.exe or sandbox.exe, total physical memory via GlobalMemoryStatusEx, disk size through both DeviceIoControl with IOCTL_DISK_GET_LENGTH_INFO and GetDiskFreeSpaceEx, processor counts in the style of Win32/Tinba and Win32/Dyre, OS genuineness, and known sandbox hostnames and usernames. Several items — single/double-click detection, dialog boxes, scrolling, execution-after-reboot, background pixel color, keyboard layout per Win32/Banload — are still marked (todo), which tells you the project is a living catalog rather than a finished product.
The anti-virtualization section is effectively a field manual of hypervisor fingerprints. al-khaser enumerates registry artifacts such as HARDWARE\DEVICEMAP\Scsi identifiers, SystemBiosVersion values for VBOX and QEMU, and SYSTEM\ControlSet001\Control\SystemInformation keys for VMWARE; filesystem artifacts including VBoxMouse.sys, VBoxGuest.sys, vboxtray.exe, vmci.sys, and vmhgfs.sys; and directory artifacts under %PROGRAMFILES% for both Oracle and VMware guest additions. It then escalates to harder-to-spoof surfaces: IDT, LDT, GDT locations and the STR task-register trick in memory, vendor MAC prefixes like \x08\x00\x27 for VirtualBox and \x00\x50\x56 for VMware, virtual devices such as \\.\VBoxGuest and \\.\HGFS, SetupDiEnumDeviceInfo disk-drive enumeration, and SMBIOS/ACPI firmware-table string checks.
Process- and DLL-based detection rounds out the coverage. The tool scans for guest-agent processes like vboxservice.exe, vmtoolsd.exe, qemu-ga.exe, and xenservice.exe, and inspects loaded DLLs for analysis-product signatures: avghookx.dll (AVG), snxhk.dll (Avast), sbiedll.dll (Sandboxie), cmdvrt32.dll/cmdvrt64.dll (Comodo Container), pstorec.dll (SunBelt Sandbox), api_log.dll and dir_watch.dll (iDefense Labs), and wine_get_unix_file_name exported from kernel32.dll as a Wine tell. A large WMI surface is also queried — Win32_Bios, Win32_Processor, Win32_ComputerSystem, Win32_NetworkAdapterConfiguration, and thermal/fan classes — which is itself a detection opportunity for defenders, since these queries are visible to host instrumentation.
Additional modules cover anti-dumping (erasing the PE header from memory and checking SizeOfImage), anti-injection through module enumeration via EnumProcessModulesEx, ToolHelp32, LdrEnumerateLoadedModules, and direct LDR structure walking including hidden-module detection, and anti-disassembly checks. The README closes with an explicit invitation: if you encounter anti-analysis tricks in real malware that the tool does not yet cover, contribute them. That crowd-sourcing model is why the catalog tracks named campaigns like CCleaner, Tinba, Dyre, and Banload rather than remaining a textbook exercise.
From a defensive telemetry standpoint, al-khaser is noisy by design, and that is a feature. A detonation in a monitored environment produces a rapid, sequential burst of registry reads, WMI queries, firmware-table accesses, cpuid instructions, and timing probes — a call pattern that EDR sensors and API-monitoring sandboxes should flag as anomalous even when each individual check is benign. Blue teams can also use it as a canary: an unexplained execution of a binary matching this behavioral profile inside a production segment is almost certainly an analyst, a misconfigured pipeline, or something worth investigating.
The honest assessment is that al-khaser is one of those rare tools whose value is entirely in the eye of the beholder. For an adversary it is a catalog of ideas; for a defender it is a benchmark. The project's own framing, its lack of any malicious payload, and its release engineering (password-protected archives to survive overzealous scanners, with the password published in the repo) all point squarely at the sandbox-hardening and AV-evaluation audience. If you operate analysis infrastructure for authorized incident response or threat research, running it periodically against your images is cheap, high-signal hygiene — and every check it passes is a technique your sandbox will not silently miss the next time a real sample tries it.
ayoubfaouzi/al-khaser.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.