SOCKS5 Protocol Analysis with PCAPs¶

Overview¶

This is a runthrough of the SOCKS5 protocol through packet captures demonstrating different commands, authentication methods, and real-world use cases. The goal is just to become familiar with the protocol and be able to understand/identify when it is being used and what that ends up looking like in a pcap. RFC 1928 goes into the nitty gritty, but let's be honest, having some visuals ends up being a lot more helpful in making sense of things.

Network Topology¶

Client: 192.168.1.100 (MAC: 00:11:22:33:44:55)
  │
  │ Port: Dynamic (54321-54325)
  ↓
Proxy:  192.168.1.200 (MAC: aa:bb:cc:dd:ee:ff)
  │
  │ SOCKS Port: 1080
  ↓
Destination Servers (various)

Available PCAP Files¶

SOCKS5 Protocol Basics¶

Handshake Flow¶

sequenceDiagram
    participant C as Client
    participant P as Proxy
    participant S as Server

    C->>P: 1. Greeting (methods)
    P->>C: 2. Method Selection

    opt Authentication Required
        C->>P: 3. Auth Credentials
        P->>C: 4. Auth Response
    end

    C->>P: 5. Connection Request
    P->>S: 6. Establish Connection
    S->>P: 7. Connection ACK
    P->>C: 8. Reply (success/failure)

    Note over C,S: Tunnel Established
    C->>P: Application Data
    P->>S: Application Data
    S->>P: Application Data
    P->>C: Application Data

Command Types¶

Scenario 1: No Authentication + HTTP¶

File: socks5_no_auth_http.pcap

Description¶

Demonstrates the simplest SOCKS5 flow: client connects to example.com (93.184.216.34:80) without authentication and sends an HTTP GET request.

Packet Flow¶

Phase 1: TCP Handshake (Packets 1-3)¶

Client → Proxy:1080 [SYN]
Proxy → Client       [SYN-ACK]
Client → Proxy       [ACK]

Phase 2: SOCKS5 Negotiation¶

Packet 4: Client Greeting

Direction: Client → Proxy
TCP Payload:

05 01 00

Packet 6: Method Selection

Direction: Proxy → Client
TCP Payload:

05 00

Packet 8: Connection Request

Direction: Client → Proxy
TCP Payload:

05 01 00 01 5D B8 D8 22 00 50

The real destination IP address is conveyed in this CONNECT packet as the Remote Host. This is what Wireshark uses to fill in SOCKS layer details in packet 12 even though packet 12 does not contain actually contain the Remote Host IP address.

Packet 10: Reply

Direction: Proxy → Client
TCP Payload:

05 00 00 01 5D B8 D8 22 00 50

Phase 3: Application Protocol (HTTP)¶

Packet 12: HTTP GET Request

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: */*

Packet 14: HTTP Response

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 13

Hello World!

Key Observations¶

• SOCKS negotiation completes in 4 packets (greeting, method, request, reply)
• Total overhead: ~20 bytes
• Application protocol is completely transparent
• No encryption - HTTP is readable in plaintext

When you follow the TCP Stream for the session, you notice immediately that it does not look like a vanilla http GET request.

Scenario 2: Username/Password Authentication¶

File: socks5_userpass_auth.pcap

Description¶

Shows SOCKS5 with username/password authentication connecting to example.com:443 (HTTPS), followed by TLS handshake.

Authentication Credentials¶

Username: alice
Password: secret123

Extended Packet Flow¶

Packet 4: Client Greeting

05 01 02

Packet 6: Method Selection

05 02

Packet 8: Authentication Request

01 05 61 6C 69 63 65 09 73 65 63 72 65 74 31 32 33

Packet 10: Authentication Response

01 00

Packet 12: Connection Request with Domain Name

05 01 00 03 0B 65 78 61 6D 70 6C 65 2E 63 6F 6D 01 BB

Packet 16: TLS Client Hello

16 03 01 00 50 01 00 00 4C 03 03 [32 random bytes]...

Key Observations¶

• Authentication adds 2 extra packets to handshake
• Credentials sent in plaintext within SOCKS connection
• Domain name resolution delegated to proxy
• TLS encrypts application data after handshake

Scenario 3: BIND Command¶

File: socks5_bind.pcap

Description¶

Demonstrates the BIND command, used for protocols requiring the server to connect back to the client (e.g., FTP data connections).

Note: BIND is not common nowadays

- Most protocols switched to client-initiated models (FTP PASV, HTTP, etc.)
- NAT traversal techniques (STUN/TURN/ICE) handle P2P better
- WebRTC and modern real-time protocols have better solutions
- It's complex to implement and maintain

Modern equivalent: NAT traversal techniques or relay servers (like TURN) handle this better for contemporary protocols. BIND exists mainly for legacy protocol compatibility.

BIND Flow¶

sequenceDiagram
    participant C as Client
    participant P as Proxy
    participant S as Server

    C->>P: BIND Request
    P->>C: First Reply (listening address)
    Note over P: Proxy listens on<br/>192.168.1.200:5000

    Note over C: Client tells server to<br/>connect to 192.168.1.200:5000

    S->>P: Connection from 10.0.0.50:21
    P->>C: Second Reply (connection established)

    Note over C,S: Data flows through tunnel

Critical Packets¶

Packet 8: BIND Request

05 02 00 01 00 00 00 00 00 00

Packet 10: First Reply (Bound Address)

05 00 00 01 C0 A8 01 C8 13 88

Packet 12: Second Reply (Connection Established)

05 00 00 01 0A 00 00 32 00 15

Use Cases¶

• FTP PORT mode data connections
• IRC DCC file transfers
• Peer-to-peer protocols
• Any protocol requiring reverse connections

Scenario 4: UDP ASSOCIATE¶

File: socks5_udp_associate.pcap

Description¶

Shows UDP relay through SOCKS5, using DNS as an example. UDP ASSOCIATE requires a TCP control connection to remain open.

UDP Encapsulation¶

Every UDP packet sent through SOCKS5 includes a header:

+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
+----+------+------+----------+----------+----------+
| 2  |  1   |  1   | Variable |    2     | Variable |
+----+------+------+----------+----------+----------+

Critical Packets¶

Packet 8: UDP ASSOCIATE Request

05 03 00 01 C0 A8 01 64 23 28

Packet 10: UDP ASSOCIATE Reply

05 00 00 01 C0 A8 01 C8 1F 40

Packet 12: Encapsulated UDP Packet (DNS Query)

00 00 00 01 08 08 08 08 00 35 [DNS query data]

Key Observations¶

• TCP connection must stay open for UDP association lifetime
• Every UDP packet includes 10-byte SOCKS5 header (for IPv4)
• Fragment field supports UDP fragmentation
• Closing TCP terminates UDP association

Scenario 5: SSH Through SOCKS¶

File: socks5_ssh.pcap

Description¶

Demonstrates SSH protocol tunneled through SOCKS5 to server 10.20.30.40:22.

SSH Protocol Flow¶

Packet 8: CONNECT Request

05 01 00 01 0A 14 1E 28 00 16

Packet 12: SSH Server Banner

SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5\r\n

Packet 14: SSH Client Banner

SSH-2.0-OpenSSH_9.0\r\n

Packet 16: SSH Key Exchange Init

00 00 01 14 0A 14 [key exchange data]

Packet 17: Encrypted SSH Traffic

00 00 00 40 [encrypted data]

Key Observations¶

• SOCKS completely transparent to SSH
• SSH banner exchange in cleartext
• Port 22 strong indicator of SSH
• Post-handshake encryption hides all content
• SSH operates identically through SOCKS vs direct connection

Protocol Reference¶

SOCKS5 Version Field¶

Command Field¶

Address Type (ATYP)¶

Reply Status Codes¶

Authentication Methods¶

Analysis Techniques¶

Wireshark Display Filters¶

# Show SOCKS handshake packets only
tcp.port == 1080 && tcp.len > 0 && tcp.len < 100

# Show post-tunnel application data
tcp.port == 1080 && tcp.len > 100

# Show specific SOCKS commands
tcp.payload[0:1] == 05 && tcp.payload[1:1] == 01  # CONNECT
tcp.payload[0:1] == 05 && tcp.payload[1:1] == 02  # BIND
tcp.payload[0:1] == 05 && tcp.payload[1:1] == 03  # UDP ASSOCIATE

# Show UDP SOCKS packets
udp.port == 8000

Follow TCP Stream¶

1. Right-click any packet in the SOCKS conversation
2. Select Follow → TCP Stream
3. Observe SOCKS negotiation at the beginning
4. Application protocol becomes visible after success reply

Identifying SOCKS Traffic¶

Look for this sequence:

1. Client greeting: 05 01 XX (version 5, method count, methods)
2. Server response: 05 XX (version 5, chosen method)
3. Request packet: 05 [01|02|03] 00... (version, command, reserved)
4. Server reply: 05 00... (version, status)
5. Application data: Pure protocol, no SOCKS headers

Security Considerations¶

What SOCKS Does NOT Provide¶

Recommendations¶

Privacy Benefits¶

• DNS Privacy: Domain resolution at proxy prevents DNS leaks
• IP Hiding: Destination sees proxy IP, not client IP
• Port/Protocol Diversity: Works for any TCP/UDP application
• NAT Traversal: Can help bypass restrictive NATs

Command-Line Tools¶

tcpdump¶

# Read PCAP file with ASCII output
tcpdump -r socks5_no_auth_http.pcap -A | less

# Read with hex and ASCII
tcpdump -r socks5_no_auth_http.pcap -X | less

# Filter for SOCKS port
tcpdump -r socks5_no_auth_http.pcap -n port 1080

tshark¶

# Show all packets with full details
tshark -r socks5_no_auth_http.pcap -V

# Show only SOCKS negotiation
tshark -r socks5_no_auth_http.pcap -Y "tcp.port==1080" -V

# Extract HTTP data
tshark -r socks5_no_auth_http.pcap -Y "http" -V

# Export objects
tshark -r socks5_no_auth_http.pcap --export-objects http,output/

Wireshark¶

# Open in Wireshark GUI
wireshark socks5_no_auth_http.pcap

# Open multiple files
wireshark socks5_*.pcap

Comparison: HTTP Proxy vs SOCKS¶

Additional Resources¶

RFCs¶

• RFC 1928 - SOCKS Protocol Version 5
• RFC 1929 - Username/Password Authentication for SOCKS V5
• RFC 1961 - GSS-API Authentication Method for SOCKS Version 5