Leveraging Smart Launcher to Evade the Evaders

Smart Launcher is a technology designed by FireEye to rapidly upgrade and modify the FireEye MVX sandbox technology used in our Network Security and Email Security solutions. Smart Launcher enables FireEye to quickly respond to ever-evolving threats, identify new malware techniques, and deliver hotfixes instantly and efficiently to our customers. In addition to back-end improvements, Smart Launcher also provides customer modifiable parameters to customize their FireEye MVX environments.

Preface

Since the onset of antivirus software, malware authors have attempted to bypass automated detection. The early, rudimentary signature-based antivirus software solutions were often easily bypassed by leveraging code packers, obfuscators, or creating polymorphic malware. Signature-less detection solutions, such as the FireEye MVX Sandbox, were built specifically to identify previously unseen malware, regardless of code hiding capability. With the prevalence of sandbox solutions today, malware authors have invested in finding techniques, referred to as ‘evasions’, to identify emulated environments.

Here at FireEye, we leverage many automated internal systems and processes to identify malware samples that attempt to evade sandbox execution. Combing heuristic analysis, our MalwareGuard machine-learning engine and MVX engine, we can identify high-confidence malicious samples that do not generate the expected malicious activity in our sandbox. Once these malware families and samples are identified, we can quickly triage how they detect our environment, and produce fixes for those techniques. Often, these once evasion techniques can become new heuristic detections of malicious activity.

Generic Evasions

A couple months ago, FireEye identified a phishing document in the wild that attempted to evade our sandbox. The phishing lure “notice-of-investigation.docx” (2d7889010b497e66b342ee32dca559c1) contains a malicious macro that leverages a novel technique to perform code-injection that is intended to subvert endpoint technology and sandbox detection. A great technical write-up of this sample has already been published on the “Neutralize Cyber Threat” blog.

In summary, the malware performs the following steps to attempt to bypass traditional detections:

1. Identifies the Process ID of ‘explorer.exe’ through a WMI query
2. Opens a handle to ‘explorer.exe’
3. Calls InitializeProcThreadAttributeList to open a handle to the threads running under ‘explorer.exe’
4. Creates a new process ‘dllhost.exe’ as a child process under ‘explorer.exe’ by directly modifying it’s startup information to use ‘explorer.exe’

The result of these commands is a new process that can be further manipulated starting under the Windows GUI process ‘explorer.exe’ instead of the Microsoft Word process ‘winword.exe’. For Sandboxes that use taint tracking to determine child processes, this can produce false negatives.

To fix this detection, FireEye implemented a simple fix to identify the combination of thread enumerations and creating processes with manipulated parent information. This fix was silently pushed out within a week of identification (in May 2018) and adopted by more than 95 percent of FireEye customers within 24 hours.

Evasions at Scale

Every time a new evasion is detected, FireEye must produce a fix and distribute it to all FireEye appliances in an expedited fashion. Historically, the sandbox architecture was not designed for rapid fix implementation. The original FireEye architecture required distributing raw sandbox guest images, sometimes reaching up to 120GB in size, to customers around the world. Due to the bandwidth limitation, update adoption rates were slow and multiple fixes would often be bundled together into update rollups.

To increase the speed of update adoption and fix generation, the FireEye MVX sandbox was completely rearchitected. Part of that involved modularizing each piece of the sandbox, enabling independent feature updates, and deployment of new analysis capabilities. The second part of the equation was a package deployment system, named Smart Launcher, that pre-configures a guest image before execution.

Smart Launcher can be leveraged to perform a simple sandbox feature change, such as processing a new file type, or a more complex changes, such as simulating specific user activity. An additional benefit of this system is that micro upgrades can now be deployed to customers targeting the Smart Launcher system. These upgrades are distributed silently in the background, total on average 10MB in size, and are thus seamlessly adopted by 90 percent of our customers within the first 24 hours. We have released north of 80 micro-updates through Smart Launcher in 2018 alone, an over 8x improvement versus 2017.

Targeting Targeted Malware

In addition to providing a new update architecture, we have chosen to expose Smart Launcher configurable settings to users so that they can handle targeted evasions at the local level. Imagine a piece of malware specifically configured for execution at a specific company, Company A. As a malware author, I may build specific checks into my malware to detect that I’m running on a valid ‘Company A’ employee workstation. To accomplish this, malware authors often check the joined domain of a system or the existence of specific browser history entries on the system.

With Smart Launcher, you can now configure all FireEye MVX sandboxes to contain simulated enterprise configurations.

Smart Launcher provides per-appliance configuration for sandbox settings including the follow fields:

• Computer name, hostname, and domain
• Logged in user
• Browser History
• Recent Documents
• Honey credentials, files, and directories
• DNS cache entries

Conclusion

FireEye Network Security and Email Security both greatly improve their detection resilience through the use of Smart Launcher. Customers today receive updates to respond to threats and evasions efficiently and seamlessly, while being given new controls on how to masquerade their FireEye MVX solutions to match their enterprise environment.

This post was first first published on

‘s website by Chris DiGiamo. You can view it by clicking here