Intercepting Encrypted C2 Traffic with INetSim and REMnux

May 17, 2026

Ever wonder what malware does behind the scenes when it thinks no one is watching? In this hands-on lab teardown, we analyze a self-deleting malicious payload, bypass its encrypted network traffic hurdles, and trick it into revealing its secondary download stages using REMnux and INetSim.

The Cat-and-Mouse Game of Dynamic Analysis

Analyzing modern malware is rarely a straightforward process. Threat actors are building increasingly sophisticated evasion techniques into their payloads, designed specifically to frustrate analysts and bypass automated sandbox environments. You can't just double-click an executable, fire up Wireshark, and expect the malware to hand over its command-and-control (C2) domains on a silver platter.

In a recent lab session, I tore down a particularly evasive sample—a variant packed inside a gh0st.zip archive. The analysis required a classic isolated two-machine setup: a Windows victim machine to execute the payload, and a REMnux Linux environment acting as our network gateway to capture and dissect the traffic.

Here is a detailed breakdown of the behavioral analysis, the roadblocks encountered, and how to leverage service simulation to force the malware's hand.

Step 1: Execution and The "Disappearing Act"

The first phase of dynamic analysis involves observing the malware's interaction with the host operating system. After extracting the payload and executing it on the Windows machine, the initial behavior was immediately suspicious: self-deletion.

Within moments of execution, the original executable file vanished from the Desktop. However, a quick check in tools like Process Hacker revealed that the process was still very much alive and running in memory. This is a classic defense mechanism. By deleting the file from the disk, the malware attempts to remove forensic artifacts, making post-incident recovery and static analysis significantly harder for incident responders who arrive late to the scene.

Step 2: The Network Sinkhole Attempt

With the malware running in memory, the next logical step was to intercept its communications. Standard procedure dictates setting up a network sinkhole.

By configuring the Windows machine to use the REMnux box as its default gateway and DNS server, we can manipulate the routing. I spun up fakedns on the REMnux terminal to capture DNS queries and opened Wireshark to monitor the packet flow.

The malware quickly reached out to a specific domain: talonstamed.com.

However, we immediately hit a wall. While Wireshark confirmed the connection, the traffic was moving over port 443 (HTTPS). Because the payload's communications were encrypted, looking at the packet bytes in Wireshark yielded nothing but cryptographic noise. We knew where it was talking, but we had absolutely no idea what it was saying.

Step 3: Changing Tactics with INetSim

When dealing with encrypted traffic that you cannot easily intercept with a man-in-the-middle proxy (due to certificate pinning or complex custom encryption), the best approach is to simulate the internet itself.

Enter INetSim (Internet Services Simulation Suite).

Instead of just capturing the traffic, INetSim pretends to be the destination server. It spins up fake listeners for HTTP, HTTPS, DNS, FTP, and more. When the malware reaches out expecting a malicious server, INetSim answers the call and serves up benign, pre-configured responses.

Here is how the tide turned:

  1. Halt the Noise: I stopped the local HTTP/HTTPS services (httpd) that might conflict with our simulation and killed the initial fakedns instance.
  2. Launch INetSim: Running inetsim on the REMnux machine immediately spun up a comprehensive suite of fake services, listening on all critical ports (80, 443, 53, etc.).
  3. Relaunch the Payload: To capture the exact chain of events, I terminated the lingering malware process in Windows, extracted a fresh copy from the zip file, and executed it again.

Step 4: The Reveal

With INetSim running point, the malware executed, deleted itself, and reached out to talonstamed.com over HTTPS. But this time, INetSim caught the request and successfully negotiated the connection, effectively terminating the encryption at our Linux gateway.

By trailing the INetSim service logs (tail -f /var/log/inetsim/service.log), the malware's true intentions were laid bare.

The log output revealed a clear GET request: GET /images/240r.exe

The initial payload we executed was just a stager. Its primary goal was to establish a secure connection and quietly download a secondary executable masquerading in an /images/ directory. Because INetSim is designed for exactly this scenario, it didn't just log the request; it automatically served the malware a fake, harmless binary (sample_gui.exe from its default library) in response, keeping the malware actively engaged without allowing it to pull down actual malicious code.

The Takeaway

This session highlights a critical truth in infrastructure security and analysis: you cannot rely solely on passive observation. When threat actors encrypt their staging traffic, you have to actively manipulate the environment to uncover the attack chain.

By utilizing REMnux and INetSim, we easily bypassed the encryption hurdle, identified the C2 domain, and mapped out the secondary download stages of the infection.

A final, critical reminder for any lab work: Always remember to restore your virtual machines to their clean snapshots after a session. Good lab hygiene is the only thing standing between a successful analysis and a compromised host network.

← All posts