Listen to this Post
Introduction:
Windows Virtualization-Based Security (VBS) introduces a powerful isolation mechanism through its Virtual Trust Levels (VTLs). A critical component of this architecture is the “secure call,” the method by which the less-secure VTL 0 requests services from the highly-secure VTL 1. This article demystifies these secure calls and explores SkBridge, a groundbreaking tool that allows security professionals and developers to manually invoke and analyze these privileged operations.
Learning Objectives:
- Understand the architecture and communication flow between VTL 0 and VTL 1 in Windows VBS.
- Learn how to use the SkBridge project to manually issue secure calls for testing and research.
- Master the use of complementary tools like Vtl1Mon to trace and analyze secure call activity for enhanced system introspection.
You Should Know:
1. The Foundation: Virtual Trust Levels (VTLs)
VBS leverages hardware virtualization to create two isolated security contexts: VTL 0 (the normal operating system kernel) and VTL 1 (a more secure, isolated environment for critical security features like Credential Guard). Communication between these worlds is strictly controlled.
2. The Secure Call Gateway: `VslCreateSecureCall` API
The primary documented function for initiating a secure call from kernel-mode code in VTL 0.
NTSTATUS VslCreateSecureCall( <em>In</em> PVOID InputBuffer, <em>In</em> SIZE_T InputBufferLength, <em>Out</em> PVOID OutputBuffer, <em>Out</em> PSIZE_T OutputBufferLength );
Step-by-step guide: This API is the official channel for a driver in VTL 0 to request a service from VTL 1. The `InputBuffer` contains a serialized request, which is transferred across the VTL boundary. The secure service in VTL 1 processes the request, places the result in an OutputBuffer, and returns it to the caller. This mechanism is the bedrock of most VBS features.
3. Manual Control with SkBridge: Loading the Driver
SkBridge provides a user-mode application and a kernel driver to manually issue these calls. First, load the SkBridge kernel driver.
sc create SkBridge type= kernel binPath= C:\Path\To\SkBridge.sys sc start SkBridge
Step-by-step guide: The `sc create` command creates a new service entry for the driver. The `sc start` command loads the driver into the kernel, enabling its functionality. This driver provides the necessary interface between user-mode and the secure call infrastructure.
4. Issuing a Secure Call with SkBridge CLI
After loading the driver, use the SkBridge command-line interface to issue a call.
SkBridgeCli.exe -v <VSM_PARTITION_ID> -s <SecureCallCode> -i <InputParam>
Step-by-step guide: The `-v` flag specifies the target Virtual Secure Mode partition. The `-s` flag is the most critical, defining the secure call code (e.g., `0x50001` for a specific test call). The `-i` flag allows you to pass an input parameter. This CLI transforms abstract concepts into actionable commands.
5. Tracing the Action: Installing Vtl1Mon
To observe the results of your secure calls, you need visibility into VTL 1. Connor McGarr’s Vtl1Mon is a kernel driver that hooks the VTL 1 dispatcher to log activity.
git clone https://github.com/connormcgarr/Vtl1Mon
Step-by-step guide: Clone the repository, open the solution in Visual Studio, and build it for the Windows Driver target. Load the resulting `Vtl1Mon.sys` driver into your VTL 1 environment (which requires a custom VTL 1 project or a debugger attached to the VSM partition). Once loaded, it will log secure call information to the debugger output.
6. Interpreting Vtl1Mon Output
When a secure call is issued via SkBridge and traced by Vtl1Mon, the debug log reveals the internal flow.
[bash] SecureCall Code: 0x50001 Received. [bash] InputBuffer: 0xFFFFAA8B12D45100 [bash] SecureCall Code: 0x50001 Completed. Status: 0x0
Step-by-step guide: This output confirms that a secure call with code `0x50001` was successfully received and processed by VTL 1. The status `0x0` (STATUS_SUCCESS) indicates the operation completed without error. Analyzing this log is crucial for understanding the request-response lifecycle.
7. Exploring Common Secure Call Patterns
Secure calls follow specific patterns, often involving memory management and validation. A common pattern is the “copy” pattern, where input is validated and then processed.
A simplified pseudocode example for a VTL 1 service routine:
NTSTATUS Vtl1SecureService(SECURE_CALL_CODE Code, PVOID InputBuffer) {
if (Code != EXPECTED_CODE) return STATUS_ACCESS_DENIED;
if (!ValidateInputBuffer(InputBuffer)) return STATUS_INVALID_PARAMETER;
// Process the secure request...
return STATUS_SUCCESS;
}
Step-by-step guide: This pattern highlights the security-critical checks that occur in VTL 1: verifying the call code is authorized and sanitizing all input from the less-trusted VTL 0 before any processing occurs. This is a fundamental tenet of the VBS security model.
What Undercode Say:
- The ability to manually invoke secure calls via SkBridge represents a paradigm shift for offensive and defensive security research, moving from observation to direct interaction with the most secure part of the Windows kernel.
- This research provides a critical foundation for auditing the security of the VBS boundary itself, as the security of the entire system relies on the correct implementation of these secure call handlers.
Analysis: McGarr’s work on SkBridge and Vtl1Mon is not just an academic exercise; it provides the essential tooling required to probe, test, and validate the security claims of VBS. For red teams, it opens avenues for discovering novel vulnerabilities in the VTL 1 dispatcher or individual secure services. For blue teams, it offers a method to build deeper detection capabilities by understanding the precise behavior of legitimate secure calls, making anomalous activity easier to spot. This moves the industry beyond speculation and into empirical analysis of this critical security boundary.
Prediction:
The release of tools like SkBridge will catalyze a new wave of security research targeting Windows VBS. Within the next 12-18 months, we predict the discovery of the first publicly documented vulnerabilities within VTL 1 secure call handlers, potentially leading to a bypass of key security features like Hypervisor-Protected Code Integrity (HVCI) or Credential Guard. This will force Microsoft to enhance the security of the VTL 1 codebase and likely lead to the development of more advanced monitoring and protection solutions tailored specifically for the VSM environment.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Connor Mcgarr – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
