Windows Defender Antivirus has hit a new milestone: the built-in antivirus capabilities on Windows can now run within a sandbox. With this new development, Windows Defender Antivirus becomes the first complete antivirus solution to have this capability and continues to lead the industry in raising the bar for security.
Putting Windows Defender Antivirus in a restrictive process execution environment is a direct result of feedback that we received from the security industry and the research community. It was a complex undertaking: we had to carefully study the implications of such an enhancement on performance and functionality. More importantly, we had to identify high-risk areas and make sure that sandboxing did not adversely affect the level of security we have been providing.
While it was a tall order, we knew it was the right investment and the next step in our innovation journey. It is available to Windows Insiders today. We encourage researchers and partners to try and examine this feature and give us feedback, so we can fine-tune performance, functionality, and security before we make it broadly available.
Why sandbox? Why now?
From the beginning, we designed and built Windows Defender Antivirus to be resistant to attacks. In order to inspect the whole system for malicious content and artifacts, it runs with high privileges. This makes it a candidate for attacks.
Security researchers both inside and outside of Microsoft have previously identified ways that an attacker can take advantage of vulnerabilities in Windows Defender Antivirus’s content parsers that could enable arbitrary code execution. While we haven’t seen attacks in-the-wild actively targeting Windows Defender Antivirus, we take these reports seriously. We immediately fixed potential problems and ramped up our own research and testing to uncover and resolve other possible issues.
At the same time, we continued hardening Windows 10 in general against attacks. Hardware-based isolation, network protection, controlled folder access, exploit protection, and other technologies reduce the attack surface and increase attacker costs. Notably, escalation of privilege from a sandbox is so much more difficult on the latest versions of Windows 10. Furthermore, the integration of Windows Defender Antivirus and other Windows security technologies into Windows Defender ATP’s unified endpoint security platform allows signal-sharing and orchestration of threat detection and remediation across components.
Running Windows Defender Antivirus in a sandbox ensures that in the unlikely event of a compromise, malicious actions are limited to the isolated environment, protecting the rest of the system from harm. This is part of Microsoft’s continued investment to stay ahead of attackers through security innovations. Windows Defender Antivirus and the rest of the Windows Defender ATP stack now integrate with other security components of Microsoft 365 to form Microsoft Threat Protection. It’s more important than ever to elevate security across the board, so this new enhancement in Windows Defender Antivirus couldn’t come at a better time.
Implementing a sandbox for Windows Defender Antivirus
Modern antimalware products are required to inspect many inputs, for example, files on disk, streams of data in memory, and behavioral events in real time. Many of these capabilities require full access to the resources in question. The first major sandboxing effort was related to layering Windows Defender Antivirus’s inspection capabilities into the components that absolutely must run with full privileges and the components that can be sandboxed. The goal for the sandboxed components was to ensure that they encompassed the highest risk functionality like scanning untrusted input, expanding containers, and so on. At the same time, we had to minimize the number of interactions between the two layers in order to avoid a substantial performance cost.
The ability to gradually deploy this feature was another important design goal. Because we would be enabling this on a wide range of hardware and software configurations, we aimed to have the ability at runtime to decide if and when the sandboxing is enabled. This means that the entire content scanning logic can work both in-proc and out-of-proc, and it can’t make any assumptions about running with high privileges.
Performance is often the main concern raised around sandboxing, especially given that antimalware products are in many critical paths like synchronously inspecting file operations and processing and aggregating or matching large numbers of runtime events. To ensure that performance doesn’t degrade, we had to minimize the number of interactions between the sandbox and the privileged process, and at the same time, only perform these interactions in key moments where their cost would not be significant, for example, when IO is being performed.
Windows Defender Antivirus makes an orchestrated effort to avoid unnecessary IO, for example, minimizing the amount of data read for every inspected file is paramount in maintaining good performance, especially on older hardware (rotational disk, remote resources). Thus, it was crucial to maintain a model where the sandbox can request data for inspection as needed, instead of passing the entire content. An important note: passing handles to the sandbox (to avoid the cost of passing the actual content) isn’t an option because there are many scenarios, such as real-time inspection, AMSI, etc., where there’s no ‘sharable’ handle that can be used by the sandbox without granting significant privileges, which decreases the security.
Resource usage is also another problem that required significant investments: both the privileged process and the sandbox process needed to have access to signatures and other detection and remediation metadata. To avoid duplication and preserve strong security guarantees, i.e., avoid unsafe ways to share state or introducing significant runtime cost of passing data/content between the processes, we used a model where most protection data is hosted in memory-mapped files that are read-only at runtime. This means protection data can be hosted into multiple processes without any overhead.
Another significant concern around sandboxing is related to the inter-process communication mechanism to avoid potential problems like deadlocks and priority inversions. The communication should not introduce any potential bottlenecks, either by throttling the caller or by limiting the number of concurrent requests that can be processed. Moreover, the sandbox process shouldn’t trigger inspection operations by itself. All inspections should happen without triggering additional scans. This requires fully controlling the capabilities of the sandbox and ensuring that no unexpected operations can be triggered. Low-privilege AppContainers are the perfect way to implement strong guarantees because the capabilities-based model will allow fine-grained control on specifying what the sandbox process can do.
Lastly, a significant challenge from the security perspective is related to content remediation or disinfection. Given the sensitive nature of the action (it attempts to restore a binary to the original pre-infection content), we needed to ensure this happens with high privileges in order to mitigate cases in which the content process (sandbox) could be compromised and disinfection could be used to modify the detected binary in unexpected ways.
Once the sandboxing is enabled, customers will see a content process MsMpEngCP.exe running alongside with the antimalware service MsMpEng.exe.
The content processes, which run with low privileges, also aggressively leverage all available mitigation policies to reduce the attack surface. They enable and prevent runtime changes for modern exploit mitigation techniques such as Data Execution Prevention (DEP), Address space layout randomization (ASLR), and Control Flow Guard (CFG). They also disable Win32K system calls and all extensibility points, as well as enforce that only signed and trusted code is loaded. More mitigation policies will be introduced in the future, alongside other techniques that aim to reduce even further the risk of compromise, such as multiple sandbox processes with random assignment, more aggressive recycling of sandbox processes without a predictable schedule, runtime analysis of the sandbox behavior, and others.
How to enable sandboxing for Windows Defender Antivirus today
We’re in the process of gradually enabling this capability for Windows insiders and continuously analyzing feedback to refine the implementation.
Users can also force the sandboxing implementation to be enabled by setting a machine-wide environment variable (setx /M MP_FORCE_USE_SANDBOX 1) and restarting the machine. This is currently supported on Windows 10, version 1703 or later.
Looking ahead: Broader availability and continuous innovation
To implement sandboxing for Windows Defender Antivirus, we took a lot of inputs from the feedback, suggestions, and research from our peers in the industry. From the beginning, we saw this undertaking as the security industry and the research community coming together to elevate security. We now call on researchers to follow through, as we did, and give us feedback on the implementation.
Windows Defender Antivirus is on a path of continuous innovation. Our next-gen antivirus solution, which is powered by artificial intelligence and machine learning and delivered in real-time via the cloud, is affirmed by independent testers, adoption in the enterprise, and customers protected every day from malware campaigns big and small. We’re excited to roll out this latest enhancement to the rest of our customers.
And we are committed to continue innovating. We’re already working on new anti-tampering defenses for Windows Defender Antivirus. This will further harden our antivirus solution against adversaries. You’ll hear about these new efforts soon. Windows Defender Antivirus and the rest of the Windows Defender Advanced Threat Protection will continue to advance and keep on leading the industry in raising the bar for security.
Mady Marinescu
Windows Defender Engineering team
with Eric Avena
Content Experience team
Talk to us
Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.
Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.
