What This Lab Is About
Parts 1 and 2 of this lab series worked with synthetic data — a pcap file built from documented behavioral indicators, and a triage tool designed to detect those same patterns automatically. Part 3 is different. This is a live lab: two virtual machines on an isolated network, one running Kali Linux as the attacker and one running Windows 11 as the victim, with Wireshark capturing everything that passes between them.
The goal was to generate real C2 traffic — not reconstructed from threat reports, but actually produced by running a Meterpreter session — and then analyze what that traffic looks like in Wireshark. Understanding what attack traffic looks like is a prerequisite to detecting it. You cannot write a detection rule for something you have never seen.
I want to be upfront about how this lab was built. I am not a penetration tester and I do not have prior experience running live exploit labs. I worked through this session with Claude as a guide — troubleshooting the network setup, the payload delivery, and the repeated Defender blocks that made getting a session much harder than expected. That troubleshooting process turned out to be as educational as the session itself.
Important: This lab was conducted entirely on an isolated host-only network inside Parallels Desktop on a single MacBook. No traffic left the host machine. No real systems were affected. The techniques demonstrated here are documented for defensive purposes — understanding how attacks work is how defenders build better detection.
Network Setup —
Getting Two VMs to Talk
The first challenge was getting Kali and Windows on the same isolated network. Kali was installed fresh in Parallels for this lab. Both VMs were set to Host-Only networking — a Parallels network mode that lets VMs communicate with each other and the host Mac, but not with the internet. That isolation matters for a lab involving malware payloads.
Confirming connectivity was the first milestone. From Kali, a simple ping confirmed both machines were reachable on the same subnet before touching any exploit tools.
ping 10.37.129.2 -c 4
64 bytes from 10.37.129.2: icmp_seq=1 ttl=128 time=0.728 ms
64 bytes from 10.37.129.2: icmp_seq=2 ttl=128 time=0.716 ms
64 bytes from 10.37.129.2: icmp_seq=3 ttl=128 time=0.687 ms
64 bytes from 10.37.129.2: icmp_seq=4 ttl=128 time=0.891 ms
4 packets transmitted, 4 received, 0% packet lossThe Defender Problem —
What Getting Caught Looks Like
Getting a Meterpreter session to connect was not straightforward. Windows Defender caught the payload repeatedly — on first download, on execution, and even on in-memory execution attempts. This was genuinely frustrating during the lab session but turned out to be the most educational part of the day.
Defender flagged the standard Meterpreter exe by signature before it could even run. Registry-based disable attempts partially worked but did not fully stop behavioral detection. The AMSI (Antimalware Scan Interface) layer caught PowerShell-based delivery even when Defender's real-time protection appeared disabled. After more than ten failed attempts across different payload formats and delivery methods, the approach that finally worked was reverting to a clean Windows snapshot without the additional hardening that came with the FlareVM analysis environment — and fully disabling Defender through Group Policy before attempting delivery.
What made this valuable: Wireshark was running during all those failed attempts. The RST/ACK pattern visible in the capture is Defender killing the connection — each time the payload tried to phone home on port 4444, Defender reset the TCP connection before the session could establish. That pattern is itself a detection signature.
Detection insight from the failed attempts: A series of outbound SYN packets to the same destination IP and port, each immediately followed by a RST/ACK from that destination, is a strong indicator of endpoint security killing a reverse shell attempt. The pattern is visible without knowing anything about the specific payload — just the TCP flags tell the story.
| Attempt | Method | Result | What Caught It |
|---|---|---|---|
| 1–3 | Standard Meterpreter exe | Blocked | Defender signature match on download |
| 4–6 | Encoded exe (xor_dynamic) | Blocked | Defender behavioral detection at execution |
| 7–8 | HTA payload | Blocked | Defender caught mshta.exe payload |
| 9–10 | PowerShell in-memory | Blocked | AMSI caught script before execution |
| 11 | Standard exe on clean snapshot + Group Policy disable | Session opened | Defender fully disabled via gpedit.msc |
The lesson here is straightforward: signature-based AV with behavioral detection layers is genuinely effective against known payloads. Metasploit's Meterpreter is in every major AV database. Getting it past Defender on a standard Windows install required significant effort. This is exactly why real attackers invest in custom payload obfuscation and why "we have antivirus" is not sufficient as a security posture.
The Session —
What Remote Access Looks Like
With Defender disabled and the listener running on Kali, the payload executed on Windows and the session opened within seconds. The Meterpreter prompt appearing in the Kali terminal is the moment the attacker has remote access to the victim machine — from this point, everything that follows happens silently on the Windows side while appearing in the Kali terminal.
[*] Started reverse TCP handler on 10.37.129.4:4444 [*] Sending stage (232006 bytes) to 10.37.129.2 [*] Meterpreter session 2 opened (10.37.129.4:4444 -> 10.37.129.2:52283) meterpreter > sysinfo Computer : ARTEMISHEX8439 OS : Windows 11 24H2+ (10.0 Build 26200) Architecture : x64 System Language : en_US Meterpreter : x64/windows meterpreter > getuid Server username: ARTEMISHEX8439\artemishex meterpreter > shell Process 6092 created. Channel 1 created. Microsoft Windows [Version 10.0.26200.8037] C:\Users\artemishex> whoami artemishex8439\artemishex meterpreter > screenshot Screenshot saved to: /home/artemishex/ffprSmKn.jpeg
The screenshot command is worth pausing on. From Kali, a single command captured the current state of the Windows desktop as a JPEG file — saved to the Kali filesystem, with no visible indication on the Windows side that anything had happened. No window opened. No notification appeared. The desktop was photographed remotely and silently. This is a routine reconnaissance step for an attacker who wants to understand what the victim is working on.
Full interactive shell on the victim machine
Victim's username, hostname, OS version
Complete process list — every running application
Network configuration including internal IPs
Screenshot of the victim's desktop, silently
Full filesystem access for the logged-in user
Nothing — no visible window or notification
No indication the machine is compromised
Normal desktop, normal applications
update.exe running silently in the background
No alert if AV is disabled or bypassed
Business as usual until discovery
What the Traffic Looks Like
in Wireshark
Wireshark was capturing on Kali's eth0 interface for the entire session — including all the failed delivery attempts and the successful session. The 67MB pcapng file contains the complete record of the lab.
The traffic breaks into two distinct phases that look completely different in Wireshark.
Phase 1 — The Failed Attempts
During the repeated Defender blocks, the Wireshark capture shows a repeating pattern: a SYN packet from Windows attempting to connect outbound to Kali on port 4444, immediately followed by a RST/ACK from Kali resetting the connection. This pattern repeated dozens of times. Defender was killing the connection at the endpoint before the TCP handshake could complete — the RST/ACK is Defender's signature in the capture.
tcp.port == 4444 and tcp.flags.reset == 1
Phase 2 — The Live Session
When the session opened, the traffic pattern changed completely. Instead of SYN/RST pairs, the capture shows a sustained bidirectional TCP conversation on port 4444 — PSH/ACK packets flowing in both directions as commands were sent to the victim and responses came back. The 232KB stage download is visible as a large burst of data from Kali to Windows immediately after the session opened — that is Meterpreter's second stage being delivered to the victim.
For the active session: tcp.port == 4444 and tcp.flags.push == 1
| Pattern | What It Means | Filter |
|---|---|---|
| SYN → RST/ACK | Endpoint security blocking connection attempt | tcp.flags.reset == 1 |
| Large burst (232KB) | Meterpreter stage 2 being delivered | frame.len > 1400 |
| Sustained PSH/ACK | Active C2 channel — commands being issued | tcp.flags.push == 1 |
| TCP Keep-Alive | Session maintained while attacker is idle | tcp.analysis.keep_alive |
| FIN/ACK | Session terminated | tcp.flags.fin == 1 |
The most important observation from the capture: Meterpreter traffic on port 4444 is encrypted. The packet contents are not readable in Wireshark — you cannot see the commands being issued or the responses coming back. What you can see is the behavioral pattern — the timing, the volume, the direction, and the port. Detection has to happen at the behavioral level, not the content level.
Why port 4444 matters: Port 4444 is the default Meterpreter port and one of the most commonly flagged ports in security tooling. A real attacker would use port 443 (HTTPS) or port 80 (HTTP) to blend in with legitimate traffic. In this lab we used the default to make the traffic easy to identify — in the wild, the same behavioral patterns would appear on ports that look like normal web traffic, making detection harder.
Detection and Defense —
How to Catch This
The most important detection insight from this lab came from the failed attempts, not the successful session. Defender's behavioral detection caught Meterpreter repeatedly using signatures and behavioral patterns — not by reading the encrypted traffic, but by watching what the process tried to do on the endpoint. Network monitoring alone is not sufficient. The detection that matters most happens at the endpoint before the session is established.
Layered detection for this attack class looks like this:
| Detection Layer | What It Catches | Tool |
|---|---|---|
| Email gateway | Malicious executable delivered via email | Sublime Security, Proofpoint |
| Endpoint AV | Known payload signatures at download and execution | Windows Defender, CrowdStrike |
| AMSI | Malicious PowerShell scripts in memory before execution | Built into Windows |
| Network monitoring | Outbound connections to non-standard ports, sustained C2 beaconing | Wireshark, Zeek, SIEM |
| Behavioral EDR | Suspicious process chains, unusual parent-child relationships | CrowdStrike, SentinelOne |
| Sysmon logging | Process creation, network connections, file writes logged to SIEM | Sysmon + any SIEM |
For a defense contractor without a dedicated SOC, the minimum viable detection stack is: endpoint AV with tamper protection enabled, Sysmon deployed and logging to a central location, and outbound network monitoring for connections to non-standard ports. The Wireshark filters from this lab translate directly into SIEM detection rules — any sustained outbound TCP connection to a non-business IP on port 4444 should trigger an alert.
Lab conducted in a controlled environment on an isolated host-only network inside Parallels Desktop. No real systems were targeted. No traffic left the host machine. All techniques demonstrated are publicly documented and used for defensive security education. Educational use only — not for use in production environments or against systems without explicit authorization.
This completes the Lab 009 series. Part 1 analyzed synthetic WAVESHAPER.V2 C2 traffic in Wireshark. Part 2 automated that detection with a Python script packaged in Docker. Part 3 generated real C2 traffic in a live lab environment and documented what it looks like — and how to stop it. The progression from analysis to automation to live simulation reflects how defenders actually develop detection capabilities.