Intercepting Malware Network Traffic: A Lab Walkthrough using Fiddler, iptables, and Remnux

When you spend enough time tearing apart malicious executables, you quickly realize that static analysis only gets you so far. You can look at strings and decompiled routines all day, but eventually, you need to see the malware in motion. You need to know exactly who it is trying to talk to, what data it is exfiltrating, and what secondary payloads it is trying to pull down.

However, letting a live malware sample connect to the open internet is a terrible idea. It alerts the threat actor, risks secondary infections, and violates fundamental lab isolation principles. Instead, we have to trick the malware into thinking it has an active internet connection while we quietly intercept and log every packet it sends.

In this walkthrough, I am going to break down a recent lab session where we analyze a malware sample known as GetDown. We will walk through configuring a Windows victim virtual machine alongside a Remnux (Linux) analysis gateway. By combining Windows-based proxy tools like Fiddler with Linux-based network redirection via iptables and FakeDNS, we can force the malware to reveal its hand.

Here is exactly how to set up the interception infrastructure and pull actionable intelligence out of the GetDown sample.

The Objective and the Arsenal

Our primary objective is to execute getdown.exe in an isolated Windows environment and capture its command-and-control (C2) or staging traffic.

To achieve this, we are using two machines in a host-only virtual network:

1. The Victim: A Windows machine where the malware will be detonated.
2. The Gateway: A Remnux Linux virtual machine configured to act as the default gateway and DNS server for the victim.

The tools we will rely on include Process Hacker (to monitor the process execution), Fiddler (for application-layer HTTP/HTTPS interception), iptables (for network-layer redirection), a basic web server daemon (httpd), FakeDNS, and Wireshark.

Phase 1: Preparing the Windows Client with Fiddler

Before we touch the networking layer, we want a clean, easily readable view of any web traffic the malware generates. Fiddler is an incredibly powerful web debugging proxy that is perfect for this. It excels at intercepting and displaying HTTP and HTTPS traffic right from the client side.

Once Fiddler is open on the Windows machine, we need to ensure it is configured to catch secure traffic. Malware rarely communicates in plaintext HTTP anymore; TLS is the standard.

To configure this:

1. Navigate to Tools > Options.
2. Select the HTTPS tab.
3. Check the boxes for Capture HTTPS CONNECTs and Decrypt HTTPS traffic.
4. Ensure Ignore server certificate errors (unsafe) is also checked. This is crucial because when we intercept the traffic, we will be presenting a fake certificate to the malware. If the malware doesn't utilize certificate pinning, it will accept Fiddler's dummy cert, allowing us to read the encrypted payload.

Note: Fiddler also has an AutoResponder feature that is highly useful for serving specific files back to applications based on regex URL matches. We will touch on how to handle responses at the network layer shortly, but keep AutoResponder in your back pocket for application-specific spoofing.

Phase 2: Traffic Redirection on the Remnux Gateway

Now we switch over to the Remnux machine. Our goal here is to make sure that any traffic leaving the Windows machine is forced into our analysis tools.

First, we need to verify the IP configurations. In this specific lab setup, our Remnux machine is operating on the ens33 interface. Running ifconfig reveals our gateway IP (in this case, 192.168.80.128).

Over on the Windows machine, we must manually configure the network adapter. By accessing the Internet Protocol Version 4 (TCP/IPv4) Properties, we set the Default Gateway and the Preferred DNS server to point directly to the Remnux IP (192.168.80.128).

Back on Remnux, we need to configure iptables to grab the traffic coming into ens33 and redirect it locally so our services can answer it. The command to insert a rule into the NAT table's PREROUTING chain looks like this:

sudo iptables -t nat -A PREROUTING -i ens33 -j REDIRECT

Let's break that down:

• -t nat: We are modifying the Network Address Translation table.
• -A PREROUTING: We are appending a rule to the PREROUTING chain (handling packets before they are routed).
• -i ens33: We are targeting traffic coming in on the ens33 interface.
• -j REDIRECT: We are instructing the firewall to redirect this traffic to the local machine.

A quick troubleshooting note from the trenches: When typing these out manually in the terminal, it's easy to fat-finger a command (like typing REDIRETED instead of REDIRECT or forgetting sudo). Always double-check your syntax if the firewall throws an error.

If you need to disable this rule later, you can swap the -A (Append) flag for a -D (Delete) flag:

sudo iptables -t nat -D PREROUTING -i ens33 -j REDIRECT

Remnux also includes a fantastic utility script called accept-all-ips. Running this script automates the process of accepting and redirecting connections to all IPs on your specified interface, effectively setting the system's default gateway behavior for analysis.

accept-all-ips start

Phase 3: Standing Up Fake Services

If the malware reaches out to download a secondary payload or ping a C2 server, and it receives a "Connection Refused" error, it might simply terminate or go to sleep. We need to feed it a response.

First, we need a web server to answer HTTP requests. On Remnux, we can easily start the built-in HTTP daemon:

httpd start

You can verify the service is running by checking its status or simply using curl:

curl localhost

You should see the HTML output for the default Index of / page. To be absolutely sure the Windows machine can see it, I like to open Firefox on the Windows victim and navigate to the Remnux IP. Seeing that default directory listing confirms our web server is reachable and responsive.

Next, we must handle Domain Name System (DNS) requests. Malware utilizes domains (like bad-actor-c2.com). If our Remnux box doesn't resolve that domain to an IP address, the HTTP request will never even happen.

We launch FakeDNS on Remnux to blindly resolve all DNS queries back to our gateway IP:

fakedns

With fakedns running, iptables redirecting traffic, and httpd ready to serve web pages, our trap is fully set.

Phase 4: Detonation and Packet Inspection

It is time to run the malware. On the Windows machine, we open Process Hacker. Filtering for the getdown process allows us to monitor its process tree and see if it spawns any suspicious child processes (like cmd.exe or powershell.exe).

We execute getdown.exe.

Immediately, we pivot to Fiddler to watch the application layer. The results are instant. In the Fiddler web sessions list, we capture a specific outbound HTTP request generated by the malware.

By inspecting the request in Fiddler, we can clearly see the target host and the exact URI the malware is trying to hit. In this case, GetDown is attempting to download an executable. The captured URL looks like this:

http://[Target_Host]/PCFix.exe?AFFID=...

This is a massive win. Fiddler neatly parses the HTTP headers, allowing us to see the exact User-Agent the malware uses, the specific query parameters (AFFID), and the filename of the secondary payload it expects (PCFix.exe). This AFFID parameter suggests an affiliate ID system, common in adware and pay-per-install malware ecosystems.

While Fiddler gives us the pristine application-layer view, we also want the ground truth at the network layer. Over on the Remnux machine, we fire up Wireshark and begin capturing on the ens33 interface.

Executing the malware again populates Wireshark with the raw packets. Here, we can observe the entire sequence:

1. The DNS Query: We see the standard query from the Windows machine asking for the IP of the malicious domain.
2. The DNS Response: We see our fakedns service instantly replying with 192.168.80.128.
3. The TCP Handshake: The SYN, SYN-ACK, ACK sequence as the malware connects to our fake web server.
4. The HTTP GET: The actual request for PCFix.exe.

Note: In the lab session, the initial run showed a failed DNS query because I hadn't started fakedns yet. This highlights a crucial point: if your simulated infrastructure is missing a single piece (like DNS resolution), the malware will halt its execution chain, and you will miss the subsequent HTTP requests. Always verify your fake services are actively listening.

Conclusion: Tying it All Together

By the end of this short exercise, we successfully unraveled the initial network staging mechanism of the GetDown malware.

This dual-layered approach—using Fiddler for high-level, easily readable HTTP debugging on the client side, and Remnux/Wireshark for low-level protocol capturing and routing on the gateway side—is incredibly potent.

It allows us to safely explore and understand malware functionality, such as command-and-control mechanisms and downloader behaviors. It helps us prove or disprove theories we might have developed during code-level static analysis, bringing additional, concrete findings to our reverse engineering reports.

You can see that some malware is quite fragile; if we cannot simulate the exact environment and responses it expects, we get nothing. But when we carefully orchestrate iptables, fakedns, and tools like Fiddler, we force the malware to expose its network IOCs (Indicators of Compromise)—giving us exactly what we need to build robust defenses.