↓ Skip to main content
u-random
u-random
  1. Lab-blue/

[TODO] Lab - DLL Injection via LD_PRELOAD e rilevamento con Wazuh FIM

·2 mins
intermedio
Network-Defense Observability
Alessio Barnini
Author
Alessio Barnini
Table of Contents
[TODO] Lab - DLL Injection via LD_PRELOAD e rilevamento con Wazuh FIM

Capitolo: Gibson Cap 7 — Protecting Against Advanced Attacks Concetti: DLL injection, shared object (.so), LD_PRELOAD, File Integrity Monitoring, Wazuh FIM

Obiettivo
#

Capire come funziona DLL injection su Linux:

  1. Scrivere una .so malevola che intercetta una funzione di sistema
  2. Iniettarla in un processo via LD_PRELOAD senza toccare i file di sistema
  3. Sostituire una .so su disco e verificare che Wazuh FIM rilevi la modifica

Ambiente
#

Kali Linux (192.168.64.200) — attaccante, compila e inietta la .so
Ubuntu Server (192.168.64.3) — vittima, ha Wazuh agent installato

Fase 1 — Scrivere la .so malevola
#

Su Kali, crea malware.c:

#define _GNU_SOURCE
#include <stdio.h>
#include <dlfcn.h>

// sovrascrive puts() — chiamata da moltissimi programmi
int puts(const char *str) {
    fprintf(stderr, "[INTERCETTATO]: %s\n", str);
    // chiama il puts originale
    int (*orig_puts)(const char*) = dlsym(RTLD_NEXT, "puts");
    return orig_puts(str);
}

Compila:

gcc -shared -fPIC -o malware.so malware.c -ldl
  • -shared — produce una shared library (.so)
  • -fPIC — Position Independent Code, richiesto per le .so
  • -ldl — linka libdl per usare dlsym()

Fase 2 — Iniezione via LD_PRELOAD
#

LD_PRELOAD=./malware.so curl --version

Ogni chiamata a puts() passa dalla tua funzione prima di quella originale. Verifica che [INTERCETTATO] appaia su stderr.

Prova con altri programmi:

LD_PRELOAD=./malware.so ls
LD_PRELOAD=./malware.so python3 -c "import os"

Obiettivo: capire che LD_PRELOAD si applica a qualsiasi processo, non solo curl.

Fase 3 — Sostituzione .so su disco (su Ubuntu, come root)
#

Prima verifica dove si trova la libreria target:

ldd /usr/bin/curl | grep libz
# libz.so.1 => /usr/lib/aarch64-linux-gnu/libz.so.1

Backup e sostituzione:

cp /usr/lib/aarch64-linux-gnu/libz.so.1 /tmp/libz.so.1.backup
cp /path/to/malware.so /usr/lib/aarch64-linux-gnu/libz.so.1

Verifica che curl funzioni ancora (la .so malevola chiama la funzione originale):

curl --version   # deve funzionare normalmente

Fase 4 — Rilevamento con Wazuh FIM
#

Configura Wazuh syscheck su Ubuntu per monitorare la directory delle librerie:

<!-- /var/ossec/etc/ossec.conf -->
<syscheck>
  <directories check_all="yes" realtime="yes">/usr/lib/aarch64-linux-gnu</directories>
</syscheck>

Riavvia Wazuh agent:

systemctl restart wazuh-agent

Ora sostituisci la .so — Wazuh dovrebbe generare un alert FIM entro 60 secondi con:

  • path del file modificato
  • hash MD5/SHA1 precedente vs nuovo
  • timestamp della modifica

Ripristino
#

cp /tmp/libz.so.1.backup /usr/lib/aarch64-linux-gnu/libz.so.1

Verifica con dpkg --verify:

dpkg --verify libz1g   # controlla hash contro database pacchetti

Domande di verifica
#

  • Perché LD_PRELOAD non richiede di toccare i file di sistema?
  • Cosa succede se aggiorni solo curl senza aggiornare il pacchetto della .so?
  • Perché FIM è più affidabile di monitorare solo i processi in esecuzione?
  • Qual è la differenza tra LD_PRELOAD e la sostituzione della .so su disco in termini di persistenza?

Collegato a
#

  • cap-07-advanced-attacks — DLL injection, memory vulnerabilities
  • mustache-project — Sprint 7, Wazuh FIM

Related