“Beeeeeeeeep!”. How Malware Uses the Beep WinAPI Function for Anti-Analysis
I was recently analyzing a malware sample that abuses the Beep function as an interesting evasion tactic. The Beep function basically plays an audible tone notification for the user. The Beep function accepts a parameter DelayInterval, which is the number of milliseconds to play the beep sound. The calling program’s thread that executed the function will “pause” execution for the duration of the beep. This can be an interesting anti-sandbox and anti-debugging technique. Let’s take a deeper look at the Beep function.
How Beep Works
When a program invokes the Beep function, it ultimately calls into a function called NtDelayExecution, which does exactly as it is titled: It delays execution of the calling program’s running thread. The below image illustrates how this essentially works:
The calling program (in this case, the malware), calls Beep, which further calls into NtDelayExecution. Once the beep duration has been met, control flow is passed back to the malware.
Here is a function trace from API Monitor, showing the same thing. Notice how Beep invokes several other lower level functions, including DeviceIOControl (to play the audible beep sound via hardware) and the call to NtDelayExecution:
As a side note, as the Beep function was originally intended to play an audible “beeeep!” when executed, it accepts a parameter called dwFreq which denotes a frequency of the beep sound, in hertz. This means that the calling program can decide the type of the tone that is played when Beep executes. This particular malware doesn’t play a tone when calling beep, but I think this would be a funny technique for malware to use; annoy the victim (or malware analyst). You may also wonder why the malware can’t just call NtDelayExecution directly. This would also work, but may appear more obvious to malware analysts and researchers. Anyway, it’s much more fun to use Beep than to call NtDelayExecution directly.
The Malware
The malware I was investigating calls the Beep function with a DelayInterval parameter of 65000 milliseconds (which will stall analysis for about 1 minute). It also calls this Beep function multiple times for added delay. This will cause the sandbox to stall for potentially log periods of time. If the malware is being debugged, the analyst will temporarily lose control of the malware as the thread is “paused”. Here is an excerpt of this code in IDA Pro:
Sandbox and Debugger Mitigations
To mitigate this technique, the sandbox should hook the NtDelayExecution function and modify the DelayInterval parameter to artificially decrease any delay. In a debugger, the malware analyst can set a breakpoint on NtDelayExecution or the Beep function and modify the DelayInterval parameter in the same way.
Other References
While researching this malware, I ran across an article from researcher Natalie Zargarov from Minerva Labs who wrote about this same technique in 2023 used in a different malware family.
Thanks for reading!
— Kyle Cucci (@d4rksystem)