"Sand" technologies: about the architecture and techniques for bypassing sandboxes

Architecture and Approaches to Creating Sandboxes

The approach to creating and choosing an architecture depends on the type of analysis our sandbox should perform — agent-based or agentless. Therefore, sandboxes are usually divided into two corresponding types. Let's briefly recall the difference between them.

Agent-Based Analysis

Let's start with agent-based analysis. It's quite simple here — we have a virtual machine running some agent. It collects events at the kernel level and sends them for processing to the system or directly to the analyst. In this case, the agent can be a Windows driver or a kernel module if we are talking about Linux systems.

If we delve a little deeper into the topic, when creating an agent-based sandbox, we develop a rootkit. Its task is to hide itself from the system and cover its tracks so as not to leave any artifacts that could alert attackers to the presence of "sand".

For example, in the Linux operating system, the kernel creates a chain of loaded modules, among which there is an agent. Its task is to remove itself from it, as well as from the files in sysfs that contain information about the driver.

🙂 Advantages

The main advantage of agent-based analysis is high performance compared to hypervisor-based sandboxes (which will be discussed below). The reason is that when we use agentless monitoring, we have to constantly make VM-exit callsand stop the guest operating system. Each such pause takes a fraction of a second, however, when we have to process thousands of events, the slowdown can be very noticeable.

High performance not only ensures faster incident response. It also means that agent-based analysis does not require high-performance hardware, which is also an important factor for many companies.

😕 Disadvantages

As strange as it may sound, the disadvantage of agent-based analysis is precisely the presence of an agent inside the system. On the one hand, our white rootkit does not see all events and may fight with the attacker's rootkit when it enters the system. On the other hand, it leaves various artifacts in the OS, by which attackers can notice that they are in a sandbox. For example, hackers can track the names of running processes, special paths in the file system, and use other sandbox detection techniques.

If attackers notice the sandbox, they stop launching malicious code and have the opportunity to find a workaround to their target.

Agentless analysis

When creating an agentless sandbox, developers use a different technology stack — hardware virtualization. In this case, the hypervisor is responsible for isolation and monitoring, on top of which the guest operating system is launched. It turns out that the hypervisor is kind of at the minus first ring of protection, which allows you to monitor events at the processor and RAM level, as well as hide the "sand" from attackers.

🙂 Pros

The key advantage of agentless analysis is the ability to track all operating system events: from OS boot to the launch of individual applications. In particular, hypervisor sandboxes allow tracing UEFI — Unified Extensible Firmware Interface. This allows, for example, to detect threats such as bootkits.

😕 Cons

As I mentioned earlier, the biggest pain of agentless sandboxes is speed. Frequent VM-exit calls and virtual machine stops significantly delay the analysis of individual samples. Accordingly, if you need a sandbox with a hypervisor, you will have to take care of having powerful "hardware" in advance.

What to choose?

Each approach has its pros and cons, so it is impossible to call any of them unbreakable. My position is to take the best of both worlds and combine the coverage of agentless analysis with the speed of agent-based analysis. After all, nothing prevents you from using a combined approach to protect against more complex sandbox detection techniques. For example, placing an agent in the system and covering it with a hypervisor.

Now I propose to look at the most complex attack techniques and how different types of sandboxes cope with them.

What techniques hackers use to bypass sandboxes

Rootkits

Let us immediately stipulate that the task of the sandbox is not to prevent the launch of the rootkit, but to detect suspicious behavior before the malicious activity starts. Any attempt to install such a kernel module in the OS is preceded by a series of actions, seeing which the SOC analyst will suspect a threat and try to eliminate it. Rootkits are most dangerous for agent-based analysis systems: if a malicious module can execute processes at the kernel level, the sandbox will not register them.

Fileless threats

There are several points of view on what to consider fileless threats. In general, these are called attacks that do not require writing a file to disk - all information is stored in RAM. So, in the case of Windows, the following attack techniques are distinguished:

• autostart PowerShell scripts;

• writing code to registry branches;

• using the WMI (Windows Management Instrumentation) tool;

• delayed code execution using the task scheduler.

Fileless attacks on Linux systems are carried out by other methods, including:

• memfd_create system call;

• using the /dev/shm (shared memory) directory;

• creating files in RAM through the /tmp directory.

Some may disagree with the methods given for Linux, but the very concept of Linux - "everything is a file" - implies that there are no fileless threats in this system :)

Attacks through new system calls

Manufacturers of operating systems do not stand still and constantly expand their APIs. For example, in Windows, they add Ex2, Ex3, or Ex15, which creates certain difficulties for sandboxes. Experts simply cannot keep track of all the new system calls that developers add. Attackers, naturally, try to use new features while sandboxes are still unable to intercept such events.

This is partly compensated by the fact that sandboxes use not only behavioral analysis but also a whole set of tools. The system detects threats using static analysis, memory dumps, file extraction, and other methods. In addition, when a new system call appears, security experts try to "teach" the sandbox to intercept it as soon as possible.

Bootkit Implementation

A bootkit is a malicious program that runs before the OS starts. For example, such a program can be stored in the hard disk loader, as well as in the BIOS or UEFI firmware. With its help, attackers gain a foothold in the system and hide the activities of other malware from security tools.

Depending on the target firmware, there are two types of bootkits — BIOS or UEFI. The malware also acts differently:

• Bootkits for devices with BIOS are stored in the MBR (master boot record), VBR (volume boot record), or IPL (initial program loader). Examples of such software include Gapz, Satana, and Pitou.

• Bootkits for UEFI are embedded in Bootmgr, SPI flash, or the EFI partition. Among the representatives of this family of malware, the most famous are LoJax, FinSpy, and TrickBot.

An attack using a bootkit usually develops according to the following scenario:

1. A bootkit compromises the OS boot process and creates conditions for the stealthy introduction of a rootkit and other malware.

2. The rootkit infects the system kernel.

3. A backdoor is launched in user mode.

4. Attackers take control of the system.

Most often, bootkits are delivered to the system through CreateFileA → WriteFile calls, SCSI (Small Computer System Interface) commands, and DeviceIoControl functions. As a rule, sandboxes track these commands and help analysts detect the attack in time.

When it comes to targeted threats, hackers often write malware directly to the SPI (Serial Peripheral Interface) chip. To deal with such a challenge, you will need to fine-tune the sandbox — the virtual machine may simply not have this controller.

DoS sandboxes

Any sandbox takes some time to notice suspicious activity — an average of two minutes. Most of the resources are spent on behavioral analysis, which means that when a large number of events occur, the system will sooner or later stop coping with their processing.

Attackers know this, so they may try to overwhelm the system with a stream of useless actions and put it into a stupor. For example, send a huge stream of emails, the analysis of which will take up the sandbox's resources.

However, it is possible to conduct a DoS attack not only on the behavioral but also on the static component of the system. To slow down the sandbox, it is enough to create a document with a complex nested structure or use complex arithmetic calculations, such as multiplying large square matrices. It is worth noting that detecting DoS attacks on mail is not within the tasks of the sandbox itself; for this, there are basic protection tools, such as a mail gateway.

Conclusion

The sandbox significantly facilitates the work of an information security analyst, but attackers are constantly coming up with new methods to bypass it. Agent analysis will save on hardware and speed up event processing, while a hypervisor-based system will help detect threats at the operating system boot level. Even a comprehensive approach using both types does not guarantee information security without the use of additional protection measures. Therefore, when creating your sandbox, it is important to properly integrate it with other solutions to cover the vulnerabilities of individual products.

⌛ NetCase Day is coming soon, and if you want to hear real cases from the world of network security before I write a new article, register! – we will be glad to see you as viewers.

📅 September 24 at 16:00

Aleksey Kolesnikov

Malware Detection Specialist, PT Expert Security Center, Positive Technologies