Sandboxing is a dynamic malware analysis technology that analyzes files (executables, libraries, documents, etc.) and URLs in a secure virtual environment.
At the end of the 90’s and beginning of the 2000’s, security researchers started to realize that it was impossible to manually analyze samples of any new version of malware, as the number of new samples per day was growing exponentially.
The beginnings
We all started first by leveraging some tools and trying to automate them using scripts and anything that could help to extract meaningful information from the malware samples. Some of the tools we were using (usually in Windows environments, as malware in Linux was almost non-existent) were:
- Filemon: getting information about all the file activity.
- Regmon: getting information about all the registry activity.
- Procmon: getting information about all the process activity.
- Ethereal (now WireShark): getting information about all the network activity.
But it was still a very manual process and didn’t scale very well. Not only because the analysis was getting complex, but also because after detonating a malware sample (for instance, in a Windows XP), that Windows XP needed to be reverted back to a clean state before detonating a new sample.
This was a big issue at the time, as there weren’t many virtualization solutions available that could help with their snapshots. So different workarounds were used trying to revert a machine to a clean state:
- Solutions like Norton Ghost, CoreProtect that were able to restore a disk to a good previous state (this software was heavily used in the 90’s Internet ).
- Truman (The Reusable Unknown Malware Analysis Net) by Joe Stewart, that was also using physical machines. It used a Linux boot image and a set of Perl scripts for booting Windows XP machines.
- Norman Sandbox, one of the commercial sandbox solutions.
But still there were many problems as the analysis was not automated, and the outputs from multiple tools were difficult to correlate.
Starting to scale
Soon after new virtualization technologies appeared (like QEMU, VirtualBox, etc.), many researchers started to create their own tools, based on virtualization and using the snapshot feature to be able to discard all the changes that a malware sample made to the system.
Of course malware authors knew of the existence of these sandboxing solutions, and started to add some checks in the code to detect that the malware was running in a virtual environment. Some of those ‘Sandbox Evasion (T1497)‘ techniques can be seen in the pafish tool:
The vast majority of the sandboxing frameworks at the time were using API hooking in order to gather telemetry data from the operating system, and many of them were based on QEMU launching Windows XP hosts. JSON was starting to be used as the standard format for the output, and there were many enrichment of the IOCs found during the execution (for example, getting geographical information about the IP Address, obtaining attributes from the Windows PE binaries, dumping the process memory and looking for strings, etc.).
Malware trackers for popular malware families (ZeuS, Citadel, Ryuk, Cridex, etc.) were very active and many security companies were automating the analysis of new malware samples from these families; as soon as a new sample was published in the malware tracker, it was automatically analyzed. VirusTotal also started to become the de-facto tool for checking (and sharing) binaries.
One of the most prolific sandboxing open source projects was Cuckoo Sandbox, which was used by almost every security researcher.
But still there were some limitations:
- Evasion techniques: many sandbox detection techniques were developed by malware authors.
- Time sensitivity: usually sandboxes were running the sample for 60 seconds (in order to be able to analyze a big number of samples), so malware authors also developed some changes to avoid them (for example, sleeping for 1 hour before executing the real payload).
- Resource constraints
- Environment differences: it is complicated to customize the environment (like the wallpaper, domain name, user account, files and folders, etc.) for each malware detonation.
- Network limitations: usually the network range was always the same and completely different from the target network.
Some examples of sandbox evasions (apart from detecting that is running in a virtual environment, or that the network – ip address – is not right) are:
- Shamoon: a well-known malware that attacked some oil and gas companies in the Middle East. It triggered a data wiping payload at 11:08 am local time on Wednesday, August 15. The attack occurred during the month of Ramadan in 2012.
- Lockbit: Lockbit 3.0 requires a specific passphrase to execute. The passphrase is unique to each sample or campaign and serves to hinder dynamic and sandbox analysis if the passphrase has not been recovered along with the sample.
- KeRanger: a ransomware malware for OSX that sleeps for 3 days before executing its payload.
Virtual Machine Introspection (VMI)
When Virtual Machine Introspection (VMI) came out, security researchers started to use it as it had an incredible advantage: no need to run the monitoring agent inside the guest virtual machine, making the sandbox detection more difficult and adding more features to the data collection.
ResearchGate: Architecture of virtual machine introspection
Two open source libraries started to use VMI, libVMI and DRAKVUF, making it possible to create sandbox environments that were using this new technique.
One of the open source frameworks designed for this purpose was pyREbox, based on Volatility.
While VMI was very helpful for avoiding being detected, there were many other features that were important and were developed at this time, like:
- MITRE ATT&CK® complete mapping
- Screen capture in video
- SSL man-in-the-middle (MiTM)
- Support for:
- Binaries (Windows PE, ELF, Android, etc.)
- Files + Applications:
- PDF + Acrobat Reader
- Office docs + Microsoft Office
- URL + Browsers
- And many more.
The future
During the last 20 years, the evolution of sandboxing has been focused on being able to extract as much as information from a malware sample (binary, document URL, etc.) and we can say that nowadays it is stronger than ever. But, there is one big limitation that still is not solved yet: the realism and credibility of the infrastructure where the malware is detonated.
Nowadays, many of the advanced attacks are targeted attacks, and very often running a malware sample in a sandbox won’t be enough as the information captured will be limited. Some of the current limitations are:
- In targeted attacks, attackers will know the environment they are attacking, and they will expect to see a similar environment (same network range, domain name, wallpaper, user accounts, applications, outgoing IP address, etc.)
- Those attacks are usually multi-staged attacks where the attacker will move laterally using different tools, so the environment should include the infrastructure to let the attacker move laterally.
- The sandbox infrastructure should include real-life activity making it more credible: logins, users browsing the Internet, new emails, files being downloaded, etc.
- Content (files, emails, Teams messages, etc.) also needs to be credible.
- Long-term execution: as these attacks can be running for days, weeks or even months, the infrastructure should be able to handle it.
- Cloud infrastructure is also being attacked, so we should be able to have sandboxing versions of popular cloud services like Microsoft Office36, Google Workspace, AWS, Azure, etc.
As you can see, sandboxes must be ultra-realistic, especially when it comes to advanced attacks. Some of the above limitations are a handicap when it comes to gathering more threat intelligence from attacks, as attackers will quickly detect that it is not the targeted environment and will leave without doing nothing.
Deception technology enables the construction of lifelike, convincing environments that are digital twins of your real network. At CounterCraft, we specialize in building long-term complex infrastructures with the sole purpose of engaging with threat actors and being able to collect fresh IOCs and TTPs in real time. Our technology enables sandboxing to evolve to the next level, with a credibility that makes them truly effective.
To find out more about how our deception technology drives the collection of specific, actionable intelligence from threat actors and how you can employ it in sandbox scenarios, please contact us!
