Iscriviti al webinar gratuito del 12 Maggio per diventare Forensic Analyst! Scopri di più
Corso Ethical Hacker: accedi alla promozione fino al 30 Aprile! Scopri di più
Compromise Host Software Binary è una tecnica di persistenza classificata nella tattica TA0003 – Persistence, la fase in cui l'avversario cerca di mantenere il proprio accesso al sistema sopravvivendo a riavvii, aggiornamenti e rotazione delle credenziali. Il concetto è tanto semplice quanto devastante: anziché installare un nuovo eseguibile malevolo — facilmente individuabile — l'attaccante modifica un binario già presente e considerato legittimo dal sistema operativo, dagli utenti e spesso anche dalle soluzioni di sicurezza.
Le varianti operative sono diverse. Un client SSH può essere trojanizzato per registrare ogni coppia di credenziali immessa. Un'applicazione di uso quotidiano, come un browser o un editor di testo, può essere patchata in memoria o su disco per iniettare un backdoor all'avvio. L'adversary può persino intervenire sull'Import Address Table (IAT) o sull'entry point del binario, redirigendo il flusso di esecuzione verso codice malevolo prima che il programma originale prenda il controllo. A completare la catena, tecniche di lock dei pacchetti — come il comando yum-versionlock su distribuzioni Linux — impediscono che un aggiornamento sovrascriva la modifica.
La superficie d'attacco è ampia: i dati censiscono 2 gruppi APT, 16 famiglie malware, 3 campagne documentate e 1 mitigazione direttamente associata. L'impatto attraversa settori critici — energia, difesa, telecomunicazioni, finanza — e coinvolge dispositivi di rete enterprise come VPN e router, non solo endpoint tradizionali.
La simulazione di questa tecnica in un esercizio red team richiede di dimostrare che un binario legittimo, una volta modificato, continua ad essere eseguito normalmente mentre svolge operazioni aggiuntive malevole. L'obiettivo non è distruggere il binario, ma renderlo un veicolo di persistenza invisibile.
Scenario 1 — Trojanizzazione di un client SSH su Linux. In laboratorio, partendo da un sistema con OpenSSH installato, il red teamer compila una versione modificata del client SSH che registra le credenziali in un file nascosto. Il concetto è lo stesso usato da Kobalos e Kessel, che sostituiscono il binario SSH per catturare login. In un lab isolato si può procedere scaricando i sorgenti di OpenSSH, aggiungendo una riga di logging nel file auth-passwd.c che scriva username e password in chiaro su un file locale, e ricompilando. Il binario risultante sostituisce /usr/bin/ssh e ogni sessione successiva produce un log di credenziali. Per evitare che il pacchetto venga ripristinato:
sudo yum versionlock add openssh-clients
Questo comando, presente nelle distribuzioni RHEL/CentOS con il plugin yum-plugin-versionlock (open source), blocca il pacchetto alla versione corrente impedendo aggiornamenti automatici.
Scenario 2 — Prepend di codice su macOS. La logica di ThiefQuest è replicabile in laboratorio: uno script Python attraversa una directory, copia il contenuto dell'eseguibile originale in un file nascosto, poi sovrascrive l'originale con uno stub che esegue prima il payload e poi lancia il file nascosto. Il risultato è un binario che sembra identico ma esegue codice aggiuntivo.
Scenario 3 — Patching di un PE su Windows. Per simulare il patching dell'entry point, lo strumento backdoor-factory, ormai datato, è stato concettualmente sostituito da tecniche manuali con LIEF (open source), una libreria Python per il parsing e la modifica di eseguibili PE, ELF e Mach-O. Un red teamer può usarla per modificare l'entry point di un binario firmato:
import lief; binary = lief.parse("notepad.exe"); binary.optional_header.addressof_entrypoint = 0xNEWADDR; binary.write("notepad_patched.exe")
Dopo il patching, la firma digitale risulterà invalida — esattamente il segnale che il blue team deve cogliere. Per verificarlo:
sigcheck.exe -e -u C:\Windows\notepad_patched.exe
Sigcheck (gratuito), parte della suite Sysinternals, elenca i binari con firma non valida o assente nella directory specificata.
Scenario 4 — Appliance di rete. Per chi opera su dispositivi Ivanti o Pulse Secure in ambiente lab, il pattern della campagna Cutting Edge prevedeva l'iniezione di codice in file Python e CGI legittimi dell'appliance. Un esercizio realistico può consistere nel modificare uno script CGI di un'applicazione web interna, inserendo un handler che risponda a un parametro HTTP specifico con una reverse shell.
Scarica la guida gratuita e segui il percorso corretto fin dal primo passo