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

Wazuh + auditd: rilevare una reverse shell con regola custom

·4 mins
intermedio
Observability Dfir
Alessio Barnini
Author
Alessio Barnini
Table of Contents
Wazuh + auditd: rilevare una reverse shell con regola custom

Cosa fa
#

auditd cattura le syscall del kernel (inclusa connect()) e le scrive in /var/log/audit/audit.log. Il Wazuh Agent legge quel file e manda gli eventi al Manager, che applica una regola custom per generare un alert quando bash apre una connessione TCP in uscita.

TL;DR
#

# Il flusso completo
bash /dev/tcp/192.168.64.200/4444
  → auditd cattura syscall connect() → /var/log/audit/audit.log
    → Wazuh Agent (host) legge il file
      → Wazuh Manager (Docker) applica regola 100100
        → Alert in dashboard: level 12, MITRE T1059.004

Architettura: agent sull'host, manager in Docker
#

Wazuh Manager, Indexer e Dashboard girano in Docker. Il Wazuh Agent è installato direttamente sull'host Ubuntu — perché deve vedere il filesystem, i processi e i log del sistema operativo reale, non del container.

Ubuntu host
├── Wazuh Agent        ← legge log, manda eventi al manager
├── auditd             ← cattura syscall kernel
└── Docker
    ├── wazuh.manager  ← riceve eventi, applica regole
    ├── wazuh.indexer  ← salva gli alert (OpenSearch)
    └── wazuh.dashboard ← interfaccia web

Le regole custom vivono nel manager (Docker) su un named volume:

# Il volume persiste tra restart e rebuild del container
docker inspect single-node-wazuh.manager-1 | grep -A3 "Mounts"
# Source: /var/lib/docker/volumes/single-node_wazuh_etc/_data
# Destination: /var/ossec/etc

Questo significa che le modifiche a local_rules.xml sopravvivono a docker compose down && up.

auditd — cos'è
#

auditd (Audit Daemon) è un demone Linux che intercetta le syscall del kernel e le registra in /var/log/audit/audit.log. Non monitora i log di sistema — monitora le chiamate al kernel stesso.

Una regola auditd dice: "ogni volta che un processo esegue questa syscall, scrivilo." Nel nostro caso:

# Regola: logga ogni connect() eseguito da /usr/bin/bash
sudo auditctl -a always,exit -F arch=b64 -S connect -F exe=/usr/bin/bash -k bash_reverse_shell

# Resa persistente
echo '-a always,exit -F arch=b64 -S connect -F exe=/usr/bin/bash -k bash_reverse_shell' \
  | sudo tee /etc/audit/rules.d/reverse-shell.rules
sudo augenrules --load

Il parametro -k bash_reverse_shell è la chiave — finisce nel campo key= del log e permette di filtrare gli eventi.

Problemi reali e soluzioni
#

1. Wazuh Agent non leggeva audit.log
#

Il file /var/log/audit/audit.log è owned da root:adm. L'agent gira come utente wazuh, che non era nel gruppo adm.

sudo -u wazuh cat /var/log/audit/audit.log  # Permission denied
sudo usermod -aG adm wazuh
sudo systemctl restart wazuh-agent

2. log_format: audit non funzionava
#

Il formato audit in ossec.conf è incompatibile con il formato enriched di auditd su Ubuntu 24.04, che aggiunge traduzioni human-readable in fondo a ogni riga:

key="bash_reverse_shell"ARCH=aarch64 SYSCALL=connect AUID="barno"...

Soluzione: usare log_format: syslog in /var/ossec/etc/ossec.conf:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>

3. La regola senza if_sid non scattava
#

In Wazuh, quando un evento viene catturato da un decoder (nel nostro caso auditd), vengono valutate solo le regole figlie di quel decoder. Una regola senza <if_sid> viene ignorata per quegli eventi.

Il decoder auditd scatta la regola base 80700. La nostra regola custom deve essere figlia di 80700:

<if_sid>80700</if_sid>  <!-- obbligatorio per eventi auditd -->
<match>bash_reverse_shell</match>

La regola custom
#

Si scrive dalla dashboard: Management → Rules → local_rules.xml → icona matita.

<group name="audit,reverse_shell,">
  <rule id="100100" level="12">
    <if_sid>80700</if_sid>
    <match>bash_reverse_shell</match>
    <description>Possible reverse shell: bash ha aperto una connessione TCP in uscita</description>
    <mitre>
      <id>T1059.004</id>
    </mitre>
  </rule>
</group>

Dopo il salvataggio, riavviare il manager:

docker exec single-node-wazuh.manager-1 /var/ossec/bin/wazuh-control restart
Tip

Per testare la regola prima di applicarla: Management → Rules → Ruleset Test (o wazuh-logtest dal container). Incolla una riga del log e verifica che la Phase 3 mostri il rule id corretto.

Warning

Non usare ID regola gia' esistenti. Il file local_rules.xml contiene gia' un esempio con ID 100001. Usa ID da 100100 in su per le regole custom.

Cosa vede tshark vs cosa vede Wazuh
#

tsharkWazuh (auditd)
Connessione TCPSi — IP, porta, durataSi — tramite syscall connect()
Comandi eseguitiSi, in chiaro (bash /dev/tcp non cifra)No — i comandi non finiscono nei log
Processo responsabileNoSi — exe="/usr/bin/bash", pid, uid
Alert automaticoNo — serve analisi manualeSi — regola custom level 12
Visibilita'ReteHost

Una reverse shell cifrata (es. via SSH o meterpreter con TLS) renderebbe tshark cieco ma non Wazuh — la syscall connect() avviene comunque.

Scenario Reale
#

In un SOC enterprise auditd e Wazuh coesistono su tutti gli endpoint. La regola bash_reverse_shell fa parte di un ruleset di detection per Living-off-the-Land (LotL): tecniche che usano binari legittimi del sistema operativo (bash, python, nc) per fare cose malevole. MITRE T1059.004 copre esattamente questo. Un alert level 12 su questa regola richiederebbe triage immediato da parte di un analista Tier 1.

Collegato a
#

  • log — categoria (Wazuh come SIEM)
  • incidents — categoria (detection reverse shell)
  • wazuh-architecture — architettura base Wazuh prima di questa nota
  • reverse-shell — il vettore di attacco rilevato

Related