True to its real-world namesake, a sandbox is a lifelike emulation of an actual environment. In a child’s sandbox, tikes can play at building within controlled and safe surroundings. Just so with a software sandbox, whose job is to keep running programs separate – mitigating the risk of malicious code infiltrating actual systems.
Sandboxes were designed to allow developers or security professionals to execute untrusted or untested code, and have done their job over the years. But recent advances in malware have exposed a structural vulnerability in the sandbox model that vendors may be hard-pressed to close.
A new variant of the infamous Locky ransomware (which has wreaked havoc on tens of thousands of businesses and individuals since 2016) was recently discovered. This variant brings into question the efficacy of sandbox-based defenses against malicious file infiltration. It also follows a previously-discovered version of Locky, which did the same.
In the previous variant, discovered in April 2017, Locky was deviously hidden in a macro inside a Word doc, which in turn was nested inside a PDF file. The ransomware would activate when the PDF was downloaded, and the user tried to open the Word doc via Acrobat Reader. The Word doc contained social engineering that attempted to convince the user to enable editing. Once editing was enabled, a VBA macro would be launched – and the ransomware activated.
The current variant takes the above model one step further. It uses a similar nesting mechanism, but the malware is triggered only when the user closes the Word doc – not when he or she enables macros.
Staying Ahead of Malware
It’s clear that Locky – and likely other malware – is a step ahead of legacy models like sandboxing. Sandboxes still use behavior-based malware detection – meaning that a malicious operation must be observed during a file’s analysis in order for the system to declare it a threat.
The fact is that the sandbox paradigm simply can’t handle the level of sophistication that we’re seeing in recent malware attacks like Locky. These traditional signature and reputation-based tools use techniques designed to fight yesterday’s war. They are challenged to mitigate distributed malware attacks (DMA) in which the malware is split into several files, or encrypted malware attacks (EMA).
To secure incoming files from any threat – known or unknown, a different paradigm is required. Content Disarm and Reconstruction (CDR) is the right paradigm to meet this challenge.
Content Disarm and Reconstruction
Content Disarm and Reconstruction technology is the ideal solution to protect from all types of malware attacks originating from incoming files. Advanced CDR solutions like those from ODI strip away malicious code and return clean, fully functioning files.
CDR actually reconstructs files entering the organization to avoid malicious code infiltration – creating a new, clean replica of any file. CDR replicas contain all the functionality of the original file – without any hidden or embedded codes that might put users at risk. CDR solutions, rather than blocking suspicious files – which cripples both user experience and productivity – empower users to continue working safely and uninterrupted.
Can CDR completely replace sandbox solutions? For content files, which comprise the vast majority of files shared within and between organizations, yes. CDR vendors like ODI support the whole range of Office documents, PDFs, images, archive files and media files.
That said, organizations that receive non-content files on a regular basis – like executables, for example – and cannot block these files as part of your security policy, may still find a sandbox effective.
The Bottom Line
Sandbox technology and solutions are severely limited in their ability to protect against malware in in incoming content files. Given the increasing sophistication of malware like Locky, it’s time to rethink how CDR can better sanitize incoming files.
Interested in learning more about securing and controlling incoming files ?