SOCKS PROXY
PIVOT
LISTENER
ZEEK
DetectionBlue TeamSOCOctober 12, 2026•9 min read

Detecting SOCKS Proxies: Internal Pivot Listeners and Dynamic Forwarding

A SOCKS proxy on a workstation is a pivot point: it lets an operator route any tool through a host that is already trusted inside the network.

Scroll

Attackers stand up SOCKS proxies on compromised hosts to reach segments they cannot route to directly, using SSH -D, Chisel, Meterpreter, Cobalt Strike or a bespoke listener. The proxy is rarely noisy on the host, so the useful signals are an unexpected listening socket and east-west traffic that follows the SOCKS handshake.

Signals at a Glance

SignalWhereATT&CK
New TCP listener on 1080, 9050, 8888 or high port by a non-proxy processEDR listening-connection eventsT1090.001
SOCKS4/5 protocol records between internal hostsZeek socks.log, NGFW app-IDT1090.001
ssh -D or plink -D opening a local dynamic forwarderSysmon 1, auditd, EDRT1572
One workstation initiating connections to many internal hosts on behalf of a single inbound sessionFlow, EDRT1090
Proxy tooling arguments (socks, -D, R:socks) on the command lineProcess creationT1090.001

Unexpected Listeners

Most workstations have no reason to accept a SOCKS connection. EDR platforms record listening sockets, which lets us flag any process that opens a listener on a classic proxy port or an unusual high port outside the normal application set:

// Microsoft Defender XDR (KQL) - new proxy-like listeners
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where ActionType == "ListeningConnectionCreated"
| where LocalPort in (1080, 1081, 9050, 9150, 8888, 10808)
| where InitiatingProcessFileName !in~ ("tor.exe", "firefox.exe", "chrome.exe")
| project Timestamp, DeviceName, LocalPort, InitiatingProcessFileName,
          InitiatingProcessCommandLine, InitiatingProcessAccountName
// tune/validate: the port list is a hunt starting point, not a boundary;
// pair with first-seen listening process per host to catch random ports.

Wire-Level SOCKS Handshakes

Zeek parses SOCKS4 and SOCKS5 requests into socks.log, recording the requested host, port and whether the proxy replied with success. Internal-to-internal SOCKS is rarely legitimate, which makes it a high-value hunt:

# Splunk (Zeek socks.log) - internal SOCKS use, ranked by distinct targets
index=zeek sourcetype=bro_socks
| where cidrmatch("10.0.0.0/8", 'id.resp_h') OR cidrmatch("192.168.0.0/16", 'id.resp_h')
| stats count AS requests, dc(request.host) AS targets, values(request.port) AS ports
    BY id.orig_h, id.resp_h, version
| where requests > 5
| sort - targets
# tune/validate: adjust the RFC 1918 ranges to your network and exclude
# approved forward proxies and security tooling.
Vetted sources

Use the Zeek SOCKS analyzer documentation, SigmaHQ rules for proxy and tunneling tool execution, Elastic rules covering internal proxy behaviour and your firewall app-ID. Always baseline your own environment — legitimate forward proxies and developer tooling will appear, so build an allow-list before alerting.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming
  • Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
  • Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
  • 24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.
Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026