# sandbox-attacksurface-analysis-tools: probing what a Windows sandbox exposes > This suite of PowerShell and C# tools from Google Project Zero enumerates the access a sandboxed Windows process actually has, by impersonating its token and inspecting NT objects, tokens and memory sections. It suits sandbox developers who need to find escape paths, and it requires administrator rights and a build from source. **googleprojectzero/sandbox-attacksurface-analysis-tools** — Set of tools to analyze Windows sandboxes for exposed attack surface. - Repository: https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools - Stars: 2,344 · Forks: 451 - Language: C# - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/googleprojectzero-sandbox-attacksurface-analysis-tools ## The question is what the sandboxed identity can reach This is a small suite of PowerShell tools for testing properties of sandboxes on Windows, and it works in a way that is more direct than reading a policy document. Most of the tools take a -ProcessId flag naming a sandboxed process. The tool then impersonates the token of that process and determines what access is allowed from that location. In other words, it asks the operating system directly what a low privileged process inside the sandbox can reach, rather than inferring it from the sandbox configuration. That distinction is the whole point of the project. A sandbox can be described as restricting a set of capabilities, but the enforcement is scattered across objects, sections, tokens and access checks. Enumerating from the inside, using the actual token the sandboxed code will run with, produces the effective capability set rather than the intended one. The README also states that it is recommended to run the tools as an administrator or local system to ensure the system can be appropriately enumerated. That is a practical instruction with a real reason behind it: a process that is itself restricted cannot see everything it is trying to inspect, so the enumeration has to run from a position of greater privilege. ## Five tools covering sections, tokens, NT objects and descriptors The suite is small enough to describe exactly. EditSection is for viewing and manipulating memory sections. TokenViewer is for viewing and manipulating various process token values. NtCoreLib is a basic managed library to access NT system calls and objects, and NtCoreLib.Forms provides a few simple forms to view security descriptors and tokens. NtObjectManager is the piece that ties the rest together. It is a PowerShell module that uses NtApiDotNet to expose the NT object manager, which is the namespace that holds kernel handles such as processes, threads, files and registry keys. The module is loaded with the standard Import-Module cmdlet, and once loaded you can list the namespace directly: ``` Import-Module NtObjectManager ``` ``` Get-ChildItem NtObject:\ ``` The remaining tool, ViewSecurityDescriptor, views the security descriptor from an SDDL string or from an inherited object, which is how you read the actual permissions on a given object rather than the permissions you believe it has. The six pieces divide the problem cleanly. Sections are where memory lives and where a process can map or read what it should not. Tokens are the identity itself, and manipulating token values is how you test whether a sandbox can escalate. The NT object manager is the namespace in which handles are the currency. And the security descriptor is the per-object access rule that decides what a given handle can do. ## Loading the module means disabling code signing requirements The installation path is unconventional in a way that will stop you if you are not expecting it. The README says the tools are loaded with the Import-Module cmdlet and that you will need to disable signing requirements however. The suggested route is to copy the module into the user profile's Windows PowerShell modules directory, at %USERPROFILE%\Documents\WindowsPowerShell\Modules, and then load it from there with the command shown above. Because the modules are not signed in a way your machine will accept by default, the execution policy has to be adjusted before the import will work. That instruction deserves a moment of thought rather than a reflex. Disabling the code signing requirement on a machine is a change to a security control, and doing it permanently is not a decision to make casually. The tools themselves are from Google Project Zero, and the project is Apache 2.0 licensed with the copyright line reading Google LLC 2015 to 2024, developed by James Forshaw. So the provenance is checkable, but the check is yours to do: verify the repository and the LICENSE.txt file yourself before you relax the policy on a machine that matters. The help for the individual commands is also documented, with Get-NtProcess, Get-NtType and New-File named as examples worth reading first. ## Building from source, because 2.0 has no binaries The tools can be built with Visual Studio 2022, and the repository layout shows what you are building. There is a solution file, sandbox-attacksurface-analysis-tools.sln, and the top level directories are EditSection, NtCoreLib, NtCoreLib.Forms, NtObjectManager, TokenViewer and ViewSecurityDescriptor, plus a third_party/ directory and a README.txt alongside CONTRIBUTING and LICENSE.txt. Each tool is a separate project in the solution, which is a sensible structure for a suite like this. The managed library sits underneath the two form-based tools, and the PowerShell module depends on the managed library, so the dependency order is: build NtCoreLib, then the PowerShell module that wraps it, then the tools you actually run. The release history explains why building is the only route. Version 2.0.0 was released on 2024-09-21, immediately after v1.1.34 on the same day, and the only release note given is that 2.0.0 is a major refactor. The version before that, v1.1.33, is dated 2022-01-22. So there is a two and a half year gap between 1.1.33 and the 1.1.34 that shipped alongside 2.0.0, and the entire public description of 2.0.0 is the four words major refactor. That is a real documentation gap. A major refactor with no changelog means anyone coming from the 1.1.x line has to rediscover the API by reading the source, and anyone evaluating the project has no way to know from the release notes what changed or whether their workflow still applies. ## A working set with a last push in the last few days The activity picture for this repository is unusual and worth stating precisely. The last push to the main branch was on 2026-10-19, and the release tags stop at 2.0.0 from September 2024. So the code is being changed while the released version is two years old. For a research tool collection that is a defensible arrangement, and it has a practical consequence: the version you get from a release is not necessarily the version in the working tree. If you want the current state of the sandbox enumeration logic, you build from the branch, and if you want a reproducible reference point, you take the 2.0.0 tag. The scope is worth being clear about too. These are analysis tools, not a sandbox implementation and not a runtime mitigation. They do not stop a sandbox escape, they help you find one, by telling the developer what the sandboxed code can reach. The natural workflow is to run them against a build of your sandbox, look at what is exposed beyond the intended boundary, and then fix the sandbox rather than the tool. The project sits in the Google Project Zero organisation, and the project description is a set of tools to analyze Windows sandboxes for exposed attack surface. James Forshaw developed the suite. ## Conclusion Adopt these tools when you are designing a Windows sandbox and need to know what it actually exposes, because the method of impersonating a sandboxed process token and asking the system what that identity can reach is more revealing than a configuration review. Do not treat them as a packaged dependency: build the solution with Visual Studio 2022 and load the module with signing requirements disabled. Before you run anything, plan for administrator or local system privileges, because the enumeration is incomplete otherwise, and read the 2.0.0 release note, which is only a major refactor with no detail on what moved. ## FAQ ### How do I use the sandbox-attacksurface-analysis-tools? Build the solution with Visual Studio 2022, copy the module to %USERPROFILE%\Documents\WindowsPowerShell\Modules, disable the code signing requirements, then load it with `Import-Module NtObjectManager` and list the namespace with `Get-ChildItem NtObject:\`. Most tools also take a -ProcessId flag naming the sandboxed process to impersonate. ### What do the individual tools in the suite do? EditSection views and manipulates memory sections, TokenViewer views and manipulates process token values, NtCoreLib is a managed library for NT system calls and objects, NtCoreLib.Forms provides simple forms to view security descriptors and tokens, NtObjectManager is a PowerShell module exposing the NT object manager, and ViewSecurityDescriptor views a descriptor from an SDDL string or an inherited object. ### Do I need administrator rights to run these Windows sandbox analysis tools? The README says it is recommended to run them as an administrator or local system to ensure the system can be appropriately enumerated, because a restricted process cannot see everything it is trying to inspect. ### Is there a release of sandbox-attacksurface-analysis-tools version 2? The v2.0.0 tag exists and was published on 2024-09-21, alongside v1.1.34 on the same day, and the only release note for 2.0.0 is that it is a major refactor. The README does not describe building the tools in detail beyond stating they can be built with Visual Studio 2022. ## Sources - [googleprojectzero/sandbox-attacksurface-analysis-tools on GitHub](https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools) - [Issues](https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/issues) - [License: Apache-2.0](https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/blob/main/LICENSE) - [README](https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/blob/main/README.md) - [Releases](https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googleprojectzero-sandbox-attacksurface-analysis-tools