Reverse Engineering Anti-Sandbox Mechanism

 

The cat-and-mouse game between threat actors and defenders continues to evolve day by day. Attackers constantly develop new versions of their tools and techniques including obfuscation, custom encryption algorithms, and various stealthy methods.

Nowadays, threat actors not only focus on encoding and obfuscation mechanisms but also implement sandbox detection or anti-sandbox techniques. Simply put, they are one step ahead of defenders because they continuously research and innovate, while many defenders are stuck waiting for alerts.

There are dozens of traditional sandbox detection methods, such as:

1. Screen resolution checks

2. Mouse interaction monitoring

3. Presence of legitimate software

4. Process enumeration

5. Service checks

6. Registry keys related to virtual environments

Although defensive security teams have found ways to bypass many of these methods, threat actors have moved one step further detecting sandboxes using drivers. This means interacting with the kernel through ntdll.dll and checking for specific drivers used by known sandbox services.

In this blog, I’ll focus on detecting Any.Run. Today, I came across a video from a friend who created a sample capable of determining whether it's running inside Any.Run. He also provided a proof-of-concept (PoC) video demonstrating how the detection works.

Normal Environments PoC :

Sandbox Environments PoC :

The mechanism works by leveraging low-level system calls to detect the presence of a sandbox environment. After examining the sample code in a disassembler, it became clear that the technique relies on a specific approach. The sample first establishes communication with the Windows kernel by loading functions from ntdll.dll, particularly the NtCreateFile function. It then prepares a specific string \\??\\C:\\Program Files\\KernelLogger  and places it into a register. This path is passed to NtCreateFile, which attempts to access the corresponding file or driver. The presence or behavior of this path can be used to infer whether the sample is running inside a monitored environment like Any.Run, which may use such directories or components as part of its analysis infrastructure.

If the sample detects that it is running inside an Any.Run sandbox, it triggers a message box displaying the message "Any.Run detected." If no sandbox indicators are found, it instead displays a message box stating "Clean environment." This simple output makes it easy to determine whether the detection technique has succeeded in identifying a monitored or virtualized analysis environment.

But where does this operation actually begin? Naturally, we need some clues or indicators to guide our inspection and determine what we’re looking for and in this case, it starts by searching for a specific driver used by the Any.Run sandbox. This driver is named A3E64E55_fl, and its presence serves as a strong indicator that the environment is being analyzed within Any.Run. By checking for this driver at the beginning of execution, the sample can make an informed decision about whether it’s being monitored and adjust its behavior accordingly.

However, if we try to detect the driver using a standard command like driverquery | findstr "A3E64E55_fl", it won’t work. This is because the driver does not appear in the normal driver list available to user-mode commands. Fortunately, we have a proof of concept (PoC) demonstrating how the detection works at a lower level. You can see the details in the screenshot below, where the sample successfully identifies the presence of the A3E64E55_fl driver, bypassing traditional detection methods.

Let’s try a different approach to locate the A3E64E55_fl driver using another fundamental Windows command:
dir /s /b C:\.sys | findstr "A3E64E55_fl.sys"
This command performs a recursive search starting from the root of the C: drive, attempting to find any files or directories with that exact name. As shown in the result below, this method can sometimes reveal hidden or obscure files that aren’t listed through standard driver enumeration techniques.

If you manage to obtain a copy of the A3E64E55_fl.sys driver and open it in IDA (Interactive Disassembler), you’ll find some interesting results. Upon inspection, it becomes evident that this driver is closely tied to the Any.Run sandbox environment. The analysis reveals that the driver is either directly developed by or deeply integrated with Any.Run’s monitoring infrastructure, which confirms its use as a key component in their analysis environment. This connection further validates its role as a reliable indicator for sandbox detection.