Full Report
On a recent internal assessment, we ran into a problem. While holding low-privileged access to an internal Windows host, we realised the software on the host was communicating to a remote API endpoint over HTTPS. However, the remote endpoint was enforcing authentication using client SSL certificates. Normally, the above scenario is easily fixed by exporting the local client SSL certificate from the host and importing it into either Burp Suite or Postman. In Burp Suite, when you want to use a client SSL certificate, you must manually load the certificate and private key into it. This implies (on Windows, at least) that you’ll need to export the client SSL certificate. However, this is only possible if you hold appropriate permissions to the certificate and its private key and it allows exporting.
Analysis Summary
# Tool/Technique: Custom C# SOCKS Proxy with Client Certificate Handling
## Overview
A custom SOCKS proxy implementation written in C# designed to bypass the requirement of exporting non-exportable client SSL certificates for HTTPS communication. This proxy intercepts traffic on a compromised host, uses the locally installed client certificate via Windows Crypto API to authenticate with a remote, secured API endpoint, and forwards the traffic tunnelled through SOCKS.
## Technical Details
- Type: Tool (Custom Implementation)
- Platform: Windows (Target host where .NET framework is present)
- Capabilities: Implements SOCKS4, SOCKS4a, and SOCKS5 protocols; uses local client SSL certificates via CryptoAPI for TLS authentication without requiring export; functions as a local jumpbox for penetration testing traffic forwarding.
- First Seen: The article documenting this custom tool was published on January 24, 2023.
## MITRE ATT&CK Mapping
- **TA0008 - Lateral Movement**
- T1090 - Proxy
- T1090.003 - Proxy: Multi-hop Proxy (Applicable when the proxy is used to reach internal or restricted networks)
- **TA0011 - Command and Control**
- T1090 - Proxy
- T1090.002 - Proxy: Internal Proxy (Used to relay traffic internally)
## Functionality
### Core Capabilities
- **SOCKS Protocol Implementation:** Fully supports SOCKS4, SOCKS4a, and SOCKS5 handshake and data exchange as defined by public RFCs.
- **Traffic Tunneling:** Acts as a standard SOCKS proxy, allowing a remote client (like Burp Suite) to forward arbitrary network connections through the compromised host.
- **TLS/SSL Handling:** Establishes TLS connections to the remote endpoint on behalf of the proxy client.
### Advanced Features
- **Non-Exportable Certificate Utilization:** Leverages the Windows Crypto API to utilize client SSL certificates installed on the host, even if the private key is marked as non-exportable.
- **Authenticated HTTPS Proxying:** Solves the specific operational problem of needing client certificate authentication for an API endpoint when the certificate cannot be easily extracted for use in external tools (like standard Burp Suite configuration).
- **Low Footprint:** Implemented in C# to utilize the pre-existing .NET framework on the target host, reducing the need to deploy external binaries.
## Indicators of Compromise
*Since this describes a custom tool developed specifically for an assessment context, concrete IOCs like hashes are not provided in the source material. Indicators relate to its *behavior*.*
- File Hashes: N/A (Custom creation)
- File Names: Unknown (Defined by the analyst deploying it)
- Registry Keys: N/A
- Network Indicators: Traffic originating from the compromised host using SOCKS protocol negotiation syntax (SOCKS4/4A/5 initial connection requests).
- Behavioral Indicators: A new process or application listening locally, establishing outbound TLS connections that utilize machine-installed client certificates for authentication (detectable via process monitoring or certificate usage logs).
## Associated Threat Actors
The technique described is relevant to penetration testers and red team operations seeking stealthy persistence and functional network access rather than being intrinsically linked to a specific established threat actor group profile.
## Detection Methods
- **Signature-based detection:** No predefined signatures exist unless the custom executable file is obtained.
- **Behavioral detection:** Monitor for unusual process behavior where an application (especially if spawned by a less common process) initiates SOCKS connections and engages in TLS handshakes utilizing specific machine certificates for authentication. Monitoring for non-standard process/port activity related to crypto APIs could be effective.
- **YARA rules:** Not applicable without the tool binary.
## Mitigation Strategies
- **Principle of Least Privilege:** Ensure that low-privileged users do not have unnecessary access to sensitive client SSL certificates and their private keys, even if they have local machine access.
- **Application Hardening:** Review applications communicating over HTTPS to ensure necessary certificate paths and permissions are strictly controlled to prevent abuse via API redirection or local proxying.
- **Application Whitelisting:** Restrict the execution of unknown C# compiled executables or scripts that might serve as custom proxies.
- **Certificate Security:** Implement stronger controls over certificate storage and export policies within certificate management systems.
## Related Tools/Techniques
- Metasploit SOCKS Proxy (Built-in functionality)
- Cobalt Strike SOCKS Proxy (Built-in functionality)
- Mimikatz (Mentioned as a preliminary alternative for extracting non-exportable keys)