"Help with Proxychains4: Unable to Connect to Burp Suite (Port 8080)" #172
Description
Hello, Proxychains4 developers. I need your assistance.
I'm trying to use Proxychains4 to anonymize the requests made by my tool, TurboSearch, since SOCKS5 allows me to mask DNS resolutions. I'm also using Burp Suite, a tool to intercept and analyze HTTP/S traffic, aiming to send TurboSearch's findings directly to it.
For context, TurboSearch is an automated URL discovery tool widely used in security testing to identify possible API endpoints or vulnerable paths on a server. It sends HTTP(S) requests to a specified target using a wordlist (e.g., /api/login, /admin, etc.). My goal is to execute TurboSearch with Proxychains4, ensuring that requests are routed through the Tor network for anonymity, while the findings are sent to Burp Suite.
Here is my current Proxychains4 configuration (with comments and blank lines removed for simplicity):
strict_chain
proxy_dns
remote_dns_subnet 224
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
socks5 127.0.0.1 9050
I confirmed that both Tor and Burp Suite are active and listening on their respective ports (9050 and 8080) using the following command:
netstat -platun | grep -E "8080|9050"
Command output:
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN -
tcp6 0 0 127.0.0.1:8080 :::* LISTEN 3323/java
With this setup, I successfully executed TurboSearch using Proxychains4. Here’s the command and its corresponding output:
proxychains4 turbosearch -I -t https://api.client.com -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt --method get,post,put,patch -D --random-agent
Explanation of TurboSearch options:
-I: Enables interactive mode, displaying detailed information about the requests and responses during execution.-t https://api.client.com: Sets the target URL where TurboSearch will send requests.-w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt: Specifies the path to the wordlist containing possible endpoints (e.g.,/login,/admin).--method get,post,put,patch: Defines the HTTP methods to use (GET, POST, PUT, PATCH).-D: Activates "Double Path" mode, where TurboSearch tests concatenated paths like/api/api/loginfor possible vulnerabilities.--random-agent: Makes TurboSearch use randomized User-Agents in requests to make traffic harder to identify.--report-to http://127.0.0.1:8080(when added): Sends the findings to Burp Suite, configured to listen on port 8080.
Partial output without --report-to:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] Strict chain ... 127.0.0.1:9050 ... api.client.com:443 ... OK
[+] Connectivity checker
[+] Connection test against https://api.client.com OK! (CODE:403|SIZE:335)
At this stage, everything works perfectly. Proxychains4 routes TurboSearch's requests through the Tor network, and scans run without any issues.
The problem:
When I include the --report-to http://127.0.0.1:8080 option in the TurboSearch command to send the findings to Burp Suite, Proxychains4 fails the connectivity check. Here's the updated command:
proxychains4 turbosearch -I -t https://api.client.com -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt --method get,post,put,patch -D --random-agent --report-to http://127.0.0.1:8080
Partial output:
[proxychains] Strict chain ... 127.0.0.1:9050 ... 127.0.0.1:8080 <--socket error or timeout!
[!] Error connecting to url https://api.client.com using report to proxy http://127.0.0.1:8080
[!] Error: HTTPSConnectionPool(host='api.client.com', port=443): Max retries exceeded with url: / (Caused by ProxyError('Unable to connect to proxy', NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fe1f6f9cb90>: Failed to establish a new connection: [Errno 111] Connection refused')))
My interpretation of the issue:
I suspect the problem lies in the Proxychains4 configuration, as it seems unable to connect to Burp Suite on port 8080. Here are my thoughts:
-
strict_chainis enabled, which forces all connections to go through the configured proxy chain in the specified order. This includes routing local traffic (127.0.0.1:8080) through the Tor network (127.0.0.1:9050). This behavior doesn't make sense for localhost connections like those to Burp Suite. -
dynamic_chain, another Proxychains4 option, allows connections to bypass non-responsive proxies and proceed with the remaining proxies in the chain. If enabled, the configuration would look like this:
dynamic_chain
proxy_dns
remote_dns_subnet 224
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
socks5 127.0.0.1 9050
Although strict_chain seems like the likely cause, I don’t fully understand how dynamic_chain would resolve the issue, as the problem appears specific to Proxychains4 failing to reach Burp Suite on localhost.
Specific questions:
- Is this behavior expected when using strict_chain?
- Is there a way to ensure that local connections (e.g., to Burp Suite) are not routed through the Tor network unnecessarily?
- Can Proxychains4 be configured differently to handle this situation?
If I’m overlooking something crucial, it might be because I’ve been struggling with this all day. Any guidance or suggestions would be greatly appreciated. Thank you so much!