Steve Gibson (139:22)
So isn't that a nice little place for malware to hide? Somewhere where there is no av? Now, this decision was presumably made because running Defender inside the sandbox would slow everything down, because users might specifically wish to run things that would cause Defender to freak out, you know, to quarantine and delete their files. And because the entire point of the Sandbox is that it's a safe place where terror may reign with confinement and nothing can get out. You got full confinement there. So unfortunately, it would probably come as no surprise to anyone who's been following this pat this podcast for long to learn that the bad guys have figured out how to take up residence in Windows Sandbox as a means of obtaining secret persistence within Windows systems while still being hidden from Windows Defender and any other AV scanning which you know might be patrolling the grounds outside the sandbox but be unable to see inside. So let's take a closer look at how Windows Sandbox is being abused and what that means, and then we're going to examine what can be done to prevent its abuse, whether a user wishes to use Windows Sandbox or not for themselves. So I'm going to start by sharing a piece of an overview of the problem, which appeared in the Risky Business newsletter. That newsletter was headlined Chinese apt. So yes, we have Chinese Advanced Persistent Threat Actors. Chinese Apt abuses Windows Sandbox to go invisible on infected hosts Catalan, writing on the newsletter, wrote, A Chinese cyber espionage group named Mirror Face, also known as earth, Kasha and Apt10, is abusing the Windows Sandbox virtual environment to hide the execution of its malware on infected systems. Attacks incorporating Windows Sandbox have been taking place since 2023 and represent the first known case of Windows Sandbox abuse since its release in December of 2018. As the name hints, the feature allows Windows users to start an isolated sandbox where they can temporarily install and test apps, and then shut down the virtual environment without impacting the main OS and their data. It functions as a virtual machine, but it doesn't have all the bulky features of a vm. It's light, super fast, easy to start and use. Abuse of this feature sounds implausible because Windows Sandbox support is disabled by default, and when a sandbox is started, it runs in a window in the user's foreground. But according to reports from the Japanese government and eset, Mirror Face has found a way around these limitations. The group gains an initial foothold on compromised networks, enables Windows Sandbox, restarts systems, then silently launches Windows Sandbox instances that do not appear on the screen. This is accomplished by launching the sandbox via task scheduler under a different account from the user's current one, so the Sandbox UI never appears on the logged on user. The Mirror Face operators drop malware in a folder on the infected systems, then use windows sandbox.w sb configuration files to share access to that folder to the sandbox. Grant the Sandbox network access, then configure one of the malicious files to automatically run I'm sorry to automatically run when the Sandbox is executed. Since Windows Sandbox environments cannot run Defender, nothing happens inside and is either logged or detected. This allows the attacker to install malware and open a hidden backdoor inside that system and a victim company's network. Japanese security firm Ito Chu explains how how blind companies can become against Windows Sandbox based attacks. They wrote, since the malware in Windows Sandbox operates according to the WSB files configuration, it can access files on the host machine. However, because the files are accessed from the sandbox, activity is never logged by monitoring tools running on the host system. The technique used by mirrorface seems to be an evolved version of of a technique first documented by security researcher Lloyd Davies back in 2020. ITOCHU researchers say the abuse can go a few steps further since new features are constantly being added to Windows Sandbox. For example, the Windows Sandbox can now share clipboard audio and video input with the base os. The Windows Sandbox can now also be started via command line arguments using the new WSB exe command, which removes the need for WSB configuration files, which are artifacts security firms could use to detect possible abuse. The technique is incredibly simple to automate, even for low to mid tier skilled malware developers. Once detailed in these reports, it is likely to spread to other groups. The first to jump on and abuse this technique are likely ransomware gangs. Some groups are already using something similar. At least half a dozen ransomware groups have been spotted installing bulky VM software, you know, full virtual machine suites on infected hosts just to start the VM and send victim files to be encrypted inside where security tools don't have access to spot the ongoing encryption. Since Windows Sandbox is built in and present on all Windows 10 and Windows 11 systems, and the app's file is signed by Microsoft itself, abusing it is likely easier and safer. Itochu has published some monitoring and infection remediation advice to detect this technique, but the cat is out of the bag now, and further and broader abuse is now expected to start taking place. Okay, so one thing that's very interesting is the observation that the Windows Sandbox is able to launch and run under a different user's account, so that the foreground user never sees any indication that it's happening in the background. And here the inherent efficiency of Windows Sandbox, which so impressed me last week, actually works against the user, since its lightweight nature means a user would be much less likely to wonder where all their free RAM went, because it wouldn't be going anywhere, it wouldn't be consuming very much, just like an app. Also, the default enabled Clipboard sharing is a bit chilling since it would be a bit like having a malicious instance of Windows recall running unseen in the background, capturing anything the foreground user might temporarily place onto their clipboard, such as a cryptocurrency wallet address. I was curious to see what this researcher Lloyd Davies came up with five years ago in 2020. Whatever it was, Microsoft apparently blew it off without a second thought since we're now five years downstream of that and Windows Sandbox is still here and completely abuse prone. Five years ago, under his headline Weaponizing Windows Sandbox to Bypass Defender, Lloyd Davies wrote this short blog post may be useful for a red team living off the land for the execution of payloads on a machine where Windows Sandbox can be enabled. Windows Sandbox is designed to work this way. No exploitation of anything is covered in this post with this technique. In terms of executing within a vm, we don't need to load an external ISO onto the machine as all of this is handled by the sandbox. In my research, the Sandbox WSB configuration file was not inspected or blacklisted on any major EDR or av. At the tail end of last year, Microsoft introduced a new feature named Windows Sandbox WSB for short, when the sandbox allows you to quickly, within 15 seconds create a disposable Hyper V based virtual machine with all the qualities a familiar VM would have such as clipboard sharing, mapping directories, etc. The sandbox is also the underlay for Microsoft Defender application guard for dynamic analysis on Hyper V enabled hosts and can be enabled on any Windows 10 Pro, Enterprise or Education machine, making this perfect as a living off the land technique. So you know he's couching this all as red team, not you know like how like a red team who is our good guys acting to see like to do exploit testing against someone who has hired them to to check their defenses could use in order to obtain a an undetected presence on computers. So he says the TLDR of this technique is to craft the WSB that can be executed on an endpoint which mounts the user's file system, allowing us to execute the implant inside a hidden VM and bypass any avedr that's on the host. The WSB configuration also seems to be bypassing Windows Defender on the host where it's executed. It's not incredibly complicated, but could prove useful in an engagement. Lloyd then proceeds to talk about a document the various ways very powerful WSB files can be created to give a malicious sandbox all the power it might need on the user system, all while always remaining completely hidden and undetectable. He concludes his observations by writing a similar technique has been used by the infamous Maze and Ragnar Locker threat actors in recent times. However, they've installed third party virtualization suites such as VMware and VBox using Windows Sandbox bypasses the requirement for this software to be installed. To complement this technique, he says, I created a simple Go program to find drives automatically and mount network shares that include them as mapped folders, and then generates a WSB based on this. I have a link in the show Notes to an English language translation of the talk that was given last January in Japanese by the Ito Chu researchers. Among the many other things they've noted is that with the introduction of Windows 11, Microsoft enhanced the sandbox's features in ways that allow for additional abuses, they wrote the changes to Windows Sandbox after the Windows 11 update are as follows. Addition of the WSB EXE command, enabling Sandbox execution via the command line, background execution of the Sandbox, and the ability to modify certain settings via the gui. These recent feature updates may make it more difficult to detect attacks leveraging Windows Sandbox. The key reasons for this are as follows, and they list three background execution of Windows Sandbox previously, in Windows 10 and early versions of Windows 11 Windows Sandbox always ran as a foreground GUI application. However, with the new WSB EXE start command, it can now run in the background. As a result, the Sandbox can be launched without user awareness, and its window remains hidden until the WSBexe connect command is executed. Second, sandbox execution without a WSB file the updated WSBexe command allows sandbox configurations to be set entirely via command line arguments. Previously, WSB files were an important forensic artifact during investigations, but this change increases the risk of leaving no trace of Sandbox usage and third, persistent data inside the sandbox. In earlier versions, closing the Windows Sandbox window would terminate the process and delete all data within the environment. However, after the update, closing the window does not stop the sandbox and its data remains intact. To delete data, the sandbox must be explicitly stopped using the WSBXE stop command or terminated by shutting down the host machine. This change significantly increases the potential for long term attacker operations within the sandbox. Given these updates, security researchers must carefully verify whether such feature changes improve convenience for attackers and implement appropriate countermeasures when new functionalities are introduced. Okay, so I titled today's podcast Preventing Windows Sandbox Abuse because having now explored the dark side of this otherwise truly useful and nifty Windows Sandbox feature, if it's not something that its user will be actively using it might be worth considering taking some measures to neuter it so that it cannot be abused behind its user's back. My number one favorite way to do this would be to disable a system's virtual machine extensions capabilities at the pre boot firmware level. I recently learned that the BIOS settings backup battery on the aging gigabyte motherboard of my older Win7 machine had died. My neighborhood had a planned day long power outage while our local power company's equipment was replaced. When I fired my sheet my machine back up after having it shut down for the day, I quickly saw that it had lost its time of day and date clock. That's probably something that's familiar to us oldsters back in the days when no.
