There’s this Windows Sandbox habit that I’m not so proud of: when I run an executable, or anything else I don’t completely trust, I basically sit and watch. The fact that it’s open in Sandbox makes me feel like I don’t have to worry about it; it’s Sandbox, so whatever danger is there is contained.

However, very recently I got a rude awakening when I actually paid attention rather than just opening the installer and forgetting about it. For the first time, I noticed that Sandbox had some default access that I would have preferred locked down.

Windows Sandbox already picks two things for you

I didn’t touch a setting, and it was already online and pasteable

t I opened a fresh Windows Sandbox for an executable file that I didn’t trust. Then it struck me that even before clicking anything in this Sandbox, it already had Internet access, and I was able to copy-paste. These were two capabilities Windows had enabled on my behalf without me explicitly configuring them. If something was already sitting on my clipboard, I could paste it directly into Sandbox.

While these may not be flaws, they weren’t what I needed for that test. The Sandbox gets its default network connection through a Hyper-V virtual switch on the host and a virtual network adapter inside the Sandbox. The clipboard sharing is its own redirection feature, also just switched on.

Neither of these defaults means the Sandbox stops being an isolated environment. Windows Sandbox still uses hardware-based virtualization and a separate kernel. What caught my attention, however, was Microsoft’s decision to leave two network and host-sharing features enabled by default in an otherwise locked-down system.

Without me asking Sandbox to talk to anything, Windows had already enabled the channels that let it communicate.

The clipboard bridge is smaller than it feels

Copying into Sandbox is a two-way door

When you use that clipboard link, you often do so without even thinking of it. You could copy a URL, filename, or command from an online source and paste it straight into Sandbox so that you don’t hace to retype. It’s really convenient, and you don’t even think through the process while doing it.

Microsoft describes it as a copy-paste channel running in both directions between the desktop and Sandbox. This is a proper two-way link, which is quite different from a one-way into an isolated box.

I don’t need to prove that a particular malicious program can abuse the clipboard in some dramatic way. The relevant point for my test was simply that this connection existed because Windows Sandbox enabled clipboard redirection, not because the executable I was testing needed it.

So I decided to turn it off, which removed the copy-paste shortcut that my testing didn’t need. Every other element of the Sandbox worked normally as I’d expected.

Networking is the one that changes what’s possible

An unknown program with Internet access can do things a locked-down one simply can’t

Networking, however, was a more significant element. The second you open the default Sandbox, it can reach the Internet. This alone changes what’s possible for whatever is running within your Sandbox. It’s now more than what’s merely convenient for you, like in the case of copy-paste.

Here’s what we learn from Microsoft’s own official documentation for Windows Sandbox configuration and group policy settings: “Enabling networking can expose untrusted applications to the internal network.”

Microsoft also says disabling network access can decrease the attack surface exposed by the Sandbox. This is Microsoft, not some random blog that may be trying to scare you into a setting.

Again, I’ll try to be precise about what this could mean without overselling it. You don’t suddenly make a malicious file harmless because you disable networking. Neither is it a guarantee that nothing escapes the Sandbox. Disabling networking performs the narrower job of removing network access from processes running inside the Sandbox. Processes in the Sandbox can no longer use that Sandbox network connection to communicate with external network resources.

This is Microsoft, not some random blog that may be trying to scare you into a setting.

Microsoft’s sample configuration for testing an unknown download is what makes this click for me; it doesn’t use the defaults. The configuration maps the Downloads folder as read-only and disables networking and the virtualized GPU. So that setup you get when you open Sandbox isn’t Microsoft’s own response to “I don’t trust this file.”

You don’t have to switch off networking whenever you use Sandbox, especially since there are several legitimate tests that require live connection. But it’s important that you understand why and when it’s on.

Now I ask what the test needs before I open it

I no longer see Sandbox as a fixed setup that I may trust or distrust. Before opening Sandbox, I ask what the test needs. This is roughly how I decide what to enable:

This isn’t a Microsoft sanctioned checklist, but simply one question I ask myself: does this specific thing need to talk to anything outside the box?

You don’t have to edit settings every time you open Sandbox, either. I use a small .wsb configuration file to toggle networking and clipboard redirection. It’s what I launch instead of the default shortcut.

The bottom line remains that Sandbox is built with convenience by default, but you can make it more restrictive for specific scenarios.