learning hacking? DON'T make this mistake!! (hide yourself with Kali Linux and ProxyChains)

Using Kali Linux without hiding can expose an attacker’s public IP and trigger blocking—so proxy chains are presented as a practical way to route scanning and browsing through multiple intermediate servers, making attribution harder. The core warning is blunt: recon scans (like Nmap) don’t just reveal information about a target; they also leave traces. Firewalls can flag the activity, and defenders can correlate requests back to the attacker’s IP—sometimes even recording a “from” address on each scan—meaning the target can report the source.

To reduce that risk in an ethical-hacking context (explicit permission only), the transcript frames a “middleman” approach. Instead of sending probes directly from the attacker to the target, traffic is sent through one proxy server, so the target sees the proxy’s IP rather than the attacker’s. But that’s not a free pass: if defenders contact law enforcement, proxy logs can identify who used the proxy. The mitigation is to chain multiple proxies—each hop becomes another layer of indirection—so defenders would need to unwind several logs across multiple systems. It’s described as not foolproof, but significantly more difficult to trace.

Implementation focuses on ProxyChains on Kali Linux. The process starts by locating and editing the configuration file (proxychains.conf), then choosing a chaining mode. “Dynamic” is emphasized: with a list of proxies, it can skip non-responsive entries and select from the set, while “random” is mentioned as another option that varies which proxy is used. The transcript also highlights proxy DNS handling: if DNS requests aren’t proxied, lookups can leak the attacker’s real IP. Enabling proxy DNS ensures even domain resolution is routed through the proxy chain.

The configuration requires listing proxies with type, IP/hostname, and port, and optionally credentials. Different proxy types are referenced, with SOCKS5 described as preferable to SOCKS4, and HTTPS/HTTP types noted as additional options. A default entry pointing to 127.0.0.1 is tied to Tor/onion routing, but Tor is skipped in the walkthrough.

To verify the setup, the transcript uses ProxyChains in front of normal commands—first launching Firefox to confirm outbound traffic is going through the configured proxy chain, then checking public IP location (“what’s my IP” and “where am I”). After that, Nmap scans are run through the chain (including a TCP connect scan against ports 80 and 443 on a target IP). The result is that each scan appears to originate from the chain’s exit points rather than the attacker’s machine.

Finally, a challenge tests the same skills in a constrained environment: three proxies must be used in a specific order to reach a web server that sits behind private IP ranges (172.31.172.32.29 mentioned). The student must scan the subnet with Nmap to find the host with port 80 open, then access the site through the proxy chain. A key hint is that hosts won’t respond to ping, so Nmap should avoid the initial host-discovery step (using options like -Pn) and rely on TCP connect scanning through ProxyChains. The winners are limited to the first five completions.