Chapter 06: Attacking the sandbox – Techniques and countermeasures

The cat-and-mouse game between threat actors and security professionals intensifies with each passing day. Malware authors are becoming increasingly adept at evading detection and analysis, and one of their primary battlegrounds is the sandbox. This chapter explores the sophisticated techniques used by threat actors to attack sandboxes and how robust sandbox technologies can withstand these assaults.

Blinding the Monitor

Hook Removal / Circumvention

One of the fundamental methods employed by malware to evade sandboxes is hook removal or circumvention. Hooks are mechanisms that monitor and intercept API calls and other activities within an application. Malware can attempt to subvert these hooks in two ways:

Removal: Malware can restore the original instructions or data, effectively removing the hook.

Circumvention: Instead of making API calls that are monitored and hooked, malware can use direct system calls or invoke private functions that are not hooked. Additionally, malware may perform unaligned function calls, effectively bypassing the hook code. While hooks can be effective for specific internal functions, they do not cover all functions present in the operating system, which vary with each Windows version. The problem of unaligned function calls also remains challenging to solve through hooking.

API Hammering

Some malware adopts a strategy called API hammering, which introduces delays in slow sandboxes. Sandboxes often impose time limits on the analysis of an application’s behavior. By introducing artificial delays, malware can prolong the analysis period, making it more challenging for the sandbox to observe malicious actions.

System File Replacement

Malware can target system files residing in memory. Hooks usually reside in system files mapped into memory. Certain malware families un-map these files and reload them, effectively “unhooking” them. This tactic allows malware to execute without detection.

Unmonitored Kernel Code and Boot Processes

Many sandboxes lack the capability to monitor kernel code or the boot process of a system. Malware can take advantage of this limitation by executing code within these unmonitored areas.

Obscure File Formats

Sandbox environments often do not support all file formats, leaving room for evasion. Malware can employ obscure file formats, such as OneNote, PowerShell, .hta, or .dzip, which may not be supported by the sandbox. Consequently, these files fail to execute, bypassing analysis.

No Support for Obscure Technologies

Malware may deliver payloads that leverage obscure technologies hidden from analysis tools. While the initial infection vector, such as a Word document with a macro, may open and execute in the sandbox, the subsequent payload uses technologies like COM, Ruby, ActiveX, or JAVA that remain hidden from detection.

OS Reboots

Some sandboxes cannot survive an operating system reboot. To evade analysis, malware may monitor reboot triggers, detecting instances where the sandbox tries to emulate logging in and out. These emulated reboots can be detected by malware, signaling the presence of a sandbox.

File Size Bloating

Many commercial sandboxes impose file size limitations on sample submissions (some free public-facing sandboxes have 100 Mb maximum file size). To bypass these restrictions, malware authors pad the file with zeros, artificially inflating its size. This padding can enable the malware to evade sandbox analysis.

Reserved Characters in Filename

Reserved characters in filenames, such as \ / : * ? ” < > |, are part of system functions and cannot be used when creating folders or files. Malware authors deliberately use these illegal characters in filenames, hoping that the sandbox will reject the sample. VMRay automatically renames files containing reserved characters before submission, ensuring proper analysis.

Defeating sandbox “technology” weaknesses

To counter these sandbox evasion techniques effectively, a robust sandbox analysis environment should consider the following strategies:

Not Rely on Modifying the Target Environment:

Many sandboxes rely on modifying the target environment through hooking. However, hooks can be targeted by malware to disable analysis. A more resilient approach is to refrain from modifying the environment.

Run Gold Images as Target Analysis Environments:

Instead of using a generic target environment, employ actual gold images – standard OS and application configurations used within your enterprise. This ensures that any malware that can run on your enterprise’s systems will also execute in the analysis environment.

Monitor All Malware-Related Activity:

Some malware sandboxes, particularly those using a hooking-based approach, take shortcuts by not monitoring all activity for the sake of efficiency. This can create blind spots in analysis. VMRay technology accommodates all scenarios, offering full visibility into malware activity, regardless of attempts to obfuscate intentions.

As we navigate the intricate terrain of sandbox evasion techniques, it’s imperative to recognize the evolving strategies employed by threat actors. In the next chapter, we will delve deeper into techniques that allow malware to evade detection and analysis, uncovering their strategies, and understanding how advanced threat analysis tools like VMRay can thwart their efforts.

Days
Hours
Minutes
Seconds

Ready to stress-test your malware sandbox? Join us for a no-fluff, all-demo webinar that shows you real techniques to evaluate and optimize your sandboxing solution!