Al-Khaser: an anti-analysis stress test for sandboxes and debuggers

What Al-Khaser actually measures

Al-Khaser is described in its README as a PoC "malware" application with good intentions that aims to stress your anti-malware system. The distinction matters. It is not a scanner that inspects other files. It is a Windows executable that performs the same tricks real malware uses and reports which ones fire, so you can judge whether your environment stayed hidden.

The intended audience is narrow. The README lists three uses: checking the effectiveness of an anti-debug plugin you are writing, confirming that a sandbox solution is hidden enough, and verifying that a malware analysis environment is well hidden. Those are all defensive uses, but the code is offensive in form. It calls IsDebuggerPresent, reads the Process Environment Block, queries NtQueryInformationProcess, and walks the process LDR structures. Anyone who runs it is deliberately triggering behaviour that endpoint protection watches for.

That cuts both ways. If your EDR quarantines the binary on launch, you have learned something about your EDR, not about your sandbox. Run it on a machine you can afford to lose, and expect the first run to be noisy.

How the detection routines are grouped

The feature list in the README is organised by technique family rather than by target product, and the categories overlap in practice. Anti-debugging covers roughly forty checks, from the trivial IsDebuggerPresent and CheckRemoteDebuggerPresent to hardware breakpoints via SEH and GetThreadContext, software breakpoints via INT3, memory breakpoints via PAGE_GUARD, Interrupt 0x2d, the trap flag, TLS callbacks, and API hook detection based on module bounds.

Anti-injection is a smaller group aimed at module enumeration: EnumProcessModulesEx, ToolHelp32, LdrEnumerateLoadedModules, and direct walks of the process LDR structures. The anti-dumping group is only two entries, erasing the PE header from memory and SizeOfImage. Timing attacks are the anti-sandbox core: RDTSC with a CPUID to force a VM exit, the Locky variant that pairs RDTSC with GetProcessHeap and CloseHandle, and several sleep paths (Sleep to SleepEx to NtDelayExecution, SetTimer, timeSetEvent, waitable timers, timer queues).

Virtualization detection is the largest block and is mostly registry artifact matching. The README lists specific keys such as HARDWARE\\DEVICEMAP\\Scsi\\Scsi Port 0\\Scsi Bus 0\\Target Id 0\\Logical Unit Id 0 and its Identifier value for VirtualBox, QEMU and VMware, HARDWARE\\Description\\System SystemBiosVersion, and a SystemBiosDate of 06/23/99. These are string comparisons against values that hypervisors historically left in place. They are cheap to run and cheap to fix, which is exactly why they are worth testing: a sandbox that still exposes them is leaving the door open for no reason.

Running a targeted check from the command line

The README shows a usage string with a --check flag that can be repeated, plus --sleep (aliased as --delay) to set a delay in seconds, defaulting to 600. The help output is the authoritative list of check names, so read it before scripting anything.

./al-khaser.exe -h

Valid types printed by that command include TLS, DEBUG, INJECTION, GEN_SANDBOX, VBOX, VMWARE, VPC, QEMU, KVM, XEN, WINE, PARALLELS, HYPERV, CODE_INJECTIONS, TIMING_ATTACKS, DUMPING_CHECK, ANALYSIS_TOOLS and ANTI_DISASSM. Note that the README examples combine several of these in one invocation.

./al-khaser.exe --check DEBUG --check TIMING_ATTACKS --sleep 30

That runs the anti-debugging and timing families and waits 30 seconds instead of the default 600. The README gives a second example, al-khaser.exe --check VMWARE --check QEMU, for virtualization checks only, and a third that passes --sleep alone. For a first pass on a fresh VM, start with the two-check example and watch which routines report a hit.

If you prefer not to build from source, the README points to the releases page for prebuilt x86 and x64 binaries packaged as 7z archives, and states that the password for the 7zs can be found in the release workflow file. Unpack them on the analysis host, not on a workstation.

Where Al-Khaser gives you a false sense of coverage

The README's feature list and the --check list do not agree, and that gap is the main practical limitation. The help text exposes INJECTION and CODE_INJECTIONS as separate types, and the feature section lists an anti-injection group and an anti-dumping group, but there is no --check value named DUMPING or ANTIDUMP in the help output; DUMPING_CHECK is the only dumping-related name. If you assume every feature heading maps to a selectable check, you will misread your results.

Several entries are marked todo in the README itself: big crypto loops under timing attacks, and under human interaction, single and double click, DialogBox, scrolling, execution after reboot, sandbox known product IDs, background pixel colour, and keyboard layout. Those are not implemented, so a clean run does not mean your environment handles them.

The scope is also Windows only. Every technique in the list is a Win32 or NT API call: NtQueryInformationProcess, NtSetInformationThread, NtQueryObject, Csrss.exe privilege checks, WudfIsAnyDebuggerPresent. There is no equivalent path for Linux or macOS analysis hosts, and nothing in the README suggests one. A related search phrase, Al khaser android, points at a platform this project does not target at all.

Finally, this is a PoC, not a hardened product. The README invites contributions when you encounter anti-analysis tricks you have seen in malware, which tells you the check set is a moving target maintained by hand.

Al-Khaser versus Pafish

Pafish is the obvious comparison, and it appears in the related searches as both a term and as "Pafish alternative". Both are Windows proof-of-concept tools that run anti-debugging, anti-VM and sandbox detection techniques to see whether an analysis environment is visible.

The difference is breadth and organisation. Pafish is a compact single-purpose tool. Al-Khaser is the larger collection, with the README documenting dozens of individual checks grouped into anti-debugging, anti-injection, anti-dumping, timing, human interaction and anti-virtualization, plus a command line that lets you select families with --check and control the sleep window with --sleep. Where Pafish gives you a quick yes or no, Al-Khaser lets you isolate a family, for example running only VMWARE and QEMU, and read the result per routine.

That granularity is the reason to pick Al-Khaser over Pafish when you are tuning a specific sandbox. If you only want a fast smoke test of whether a VM is obviously detectable, the smaller tool is easier to reason about. If you are writing an anti-debug plugin and want to iterate against a specific check, the selectable families are the point.

Licence, build and upgrade cost

Al-Khaser is licensed under GPL-2.0, and the LICENSE file sits at the repository root. For internal lab use that is unlikely to matter, but GPL-2.0 is a copyleft licence: if you take code from these detection routines into a product you distribute, the obligations that attach to derivative works are yours to review. This article is not legal advice; read the licence text and, if you are shipping something, get a real opinion.

The build is a Visual Studio solution, al-khaser.sln, with the source in the al-khaser/ directory and a Tools/ directory alongside it. There is a .clang-format and an .editorconfig, so the project expects contributors to match a formatting style. The repository is not archived and the last push was on 2026-07-01, which is recent enough that the codebase is being touched, though the README header still reads Al-Khaser v0.81 while the most recent release is v1.1.0 from 2026-01-27, with v1.0.0 dating to 2024-09-22. That version drift between the README and the releases is worth knowing before you quote a version number in internal documentation.

Upgrade cost is low if you track releases and rebuild from source. It rises if you depend on a specific check name, because the selectable list is defined by the binary's help output, not by a stable published API.

Editorial conclusion

Adopt Al-Khaser if you run a malware analysis lab, build a sandbox product, or write anti-debug plugins, and you want a repeatable Windows-only check of what your environment leaks. Do not adopt it if you need macOS or Linux coverage, or if you expect a general purpose security scanner; it is a PoC that executes detection routines, not a hardening tool. Before trusting a run, verify which checks the binary actually supports on your build, since the README feature list and the --check list do not match, and confirm the 7z password source before unpacking a release.

Frequently asked questions

Official sources

1. ayoubfaouzi/al-khaser on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases