Persistenza via RC Scripts: Boot or Logon Initialization Scripts: RC Scripts (T1037.004)

Il test di questa tecnica richiede un ambiente lab con accesso root su una macchina Linux, un hypervisor ESXi e, idealmente, una VM macOS legacy (Panther 10.3 o precedente, oppure una distribuzione che mantenga la retrocompatibilità con rc.local). L'obiettivo è verificare se gli script RC vengono effettivamente eseguiti al boot e se i controlli di detection in essere rilevano la modifica.

Scenario Linux — Iniezione in rc.local. Il primo passo è accertarsi che il file esista e sia eseguibile. Su distribuzioni basate su Debian/Ubuntu, /etc/rc.local potrebbe non essere presente di default ma il servizio rc-local di systemd lo onora se creato manualmente:

touch /etc/rc.local && chmod +x /etc/rc.local

A questo punto si inietta un payload di test — un semplice callback tramite netcat o un marker nel syslog per confermare l'esecuzione:

echo '#!/bin/bash' > /etc/rc.local && echo 'logger "RC_LOCAL_TEST_EXEC"' >> /etc/rc.local

Dopo il reboot, la stringa RC_LOCAL_TEST_EXEC apparirà in /var/log/syslog (o nel journal di systemd). In un engagement più realistico, si sostituisce il logger con una reverse shell o un binary dropper, simulando il comportamento di HiddenWasp che aggiunge sé stesso direttamente a /etc/rc.local.

Scenario ESXi — Persistenza su local.sh. Su un host ESXi in laboratorio, il file target è /etc/rc.local.d/local.sh. Lo script è già presente con un blocco exit 0 in fondo. L'iniezione va posizionata prima di quella riga:

sed -i '/^exit 0/i /tmp/implant.sh &' /etc/rc.local.d/local.sh

Questo replica il pattern adottato da UNC3886, che ha collocato script di installazione in /etc/rc.local.d/. Per verificare la persistenza è sufficiente riavviare l'host e controllare che il processo atteso sia in esecuzione.

Scenario init.d — Servizio custom. Il malware Green Lambert utilizza directory init.d e rc.d per creare un servizio fittizio. La simulazione prevede la creazione di uno script in /etc/init.d/ con header LSB, seguito dall'abilitazione tramite:

update-rc.d nome_servizio defaults

Su distribuzioni Red Hat-like si usa invece chkconfig nome_servizio on.

Scenario macOS legacy. Su sistemi compatibili, la modifica di /etc/rc.common con un comando aggiuntivo in coda replica il meccanismo di iKitten. Su macOS moderno questo vettore è deprecato: verificate piuttosto che il file non venga comunque letto per retrocompatibilità.

Per la validazione automatizzata, il framework Atomic Red Team (open source) include test atomici per T1037.004 che permettono di eseguire e ripulire ciascuno scenario in modo controllato.

La detection di questa tecnica si fonda su un principio semplice: i file RC non dovrebbero MAI cambiare in produzione. Qualunque modifica è sospetta, e la sfida non è distinguere il segnale dal rumore — è assicurarsi di raccogliere il segnale in primo luogo.

Log sources critici. La strategia di rilevamento copre quattro superfici distinte, ciascuna con le proprie sorgenti:

• Linux: auditd:SYSCALL e linux:syslog — il cuore della detection. Una regola auditd che monitora la scrittura sui file RC è il primo controllo da implementare.
• macOS: macos:unifiedlog e fs:fsusage — per intercettare modifiche a /etc/rc.common e alle directory /Library/StartupItems e /System/Library/StartupItems.
• ESXi: esxi:syslog e esxi:shell — i log della shell ESXi catturano l'accesso interattivo, mentre il syslog registra l'esecuzione post-boot.
• Network devices: networkdevice:syslog — per appliance come i BIG-IP compromessi da Velvet Ant.

Regola auditd per Linux. La configurazione auditd rappresenta il controllo fondamentale. Si aggiunge al file /etc/audit/rules.d/ una regola che intercetti qualsiasi operazione di scrittura o modifica attributi sui percorsi critici:

-w /etc/rc.local -p wa -k rc_script_mod -w /etc/init.d/ -p wa -k rc_script_mod -w /etc/rc.local.d/ -p wa -k rc_script_mod

Il flag -p wa cattura sia le scritture (write) che i cambi di attributo (attribute), mentre la chiave -k rc_script_mod consente di filtrare rapidamente gli eventi nel SIEM.

Correlazione comportamentale. L'alert più efficace non si limita alla singola modifica del file: correla la scrittura con l'esecuzione post-reboot. Il pattern è una sequenza temporale: evento di modifica file (chiave rc_script_mod) → evento di shutdown/reboot → esecuzione di un processo figlio di /etc/rc.local o dello script init.d modificato. Questa correlazione riduce i falsi positivi a quasi zero, perché in un ambiente sano nessun operatore modifica un RC script e poi riavvia senza un change ticket associato.

Tuning essenziale. I parametri da calibrare sono il percorso esatto dello script (varia per distribuzione), il contesto utente (root vs. non-root) e la finestra temporale tra modifica e boot. Su ESXi va prestata attenzione alla sezione dello script modificata: un'aggiunta in fondo a local.sh prima del exit 0 è il pattern più comune.

Per il monitoraggio dell'integrità dei file, strumenti come Wazuh (open source), OSSEC (open source) o Tripwire (freemium) permettono di generare alert immediati su qualsiasi alterazione di hash dei file RC monitorati, senza dipendere esclusivamente da auditd. Osquery (open source) offre un approccio complementare tramite query SQL periodiche sulla tabella file per verificare mtime e hash dei percorsi critici.

Quando un incident coinvolge la persistenza tramite RC scripts, la timeline si costruisce incrociando artefatti del filesystem con i log di sistema. Il vantaggio investigativo è che le modifiche sono quasi sempre banali da individuare — il file RC è piccolo e ogni riga aggiunta spicca — ma il contesto temporale richiede lavoro.

Artefatti filesystem primari. Il punto di partenza è l'analisi dei metadati dei file RC. Su un sistema Linux con filesystem ext4, i timestamp mtime (ultima modifica contenuto), ctime (ultimo cambio metadati) e atime (ultimo accesso) del file /etc/rc.local raccontano la storia dell'iniezione. Il comando stat /etc/rc.local restituisce tutti e tre i valori. Se il filesystem è montato con l'opzione noatime (comune su ESXi e sistemi embedded), si perde il dato di accesso ma mtime e ctime restano affidabili.

Su ESXi, il file /etc/rc.local.d/local.sh merita un'attenzione particolare. Poiché il filesystem è prevalentemente in RAM, un'acquisizione post-mortem richiede di operare prima dello shutdown — o di aver configurato in anticipo un log forwarding verso un syslog remoto. Il pattern di UNC3886 prevede il posizionamento di uno script bash in /etc/rc.local.d/: l'analista deve esaminare l'intero contenuto della directory, non solo local.sh.

Log di sistema. I log di auditd, se configurati con le regole di monitoraggio descritte nella sezione SOC, forniscono l'evento SYSCALL esatto con UID, PID del processo che ha modificato il file, e il percorso completo. In assenza di auditd, il syslog standard registra comunque l'esecuzione dei servizi init al boot: cercare righe contenenti il nome dello script o messaggi anomali nei log di avvio tramite journalctl -b (su sistemi con systemd) o esaminando /var/log/boot.log.

Analisi del contenuto iniettato. Una volta identificato il file modificato, il contenuto aggiunto rivela la catena operativa dell'avversario. HiddenWasp aggiunge a rc.local il percorso del proprio binary, rendendo immediata l'identificazione del payload. Cyclops Blink rinomina il proprio script RC in S51armled, un nome che mimetizza un servizio ARM legittimo: la convenzione di naming SysVinit (prefisso numerico + nome) va verificata contro l'elenco dei servizi attesi. iKitten modifica rc.common su macOS: su sistemi legacy l'analista deve esaminare anche /Library/StartupItems e i relativi plist.

Costruzione della timeline. L'ordine di ricostruzione è: timestamp di modifica del file RC → log di autenticazione per identificare la sessione SSH o l'accesso locale usato per la modifica → eventi di reboot successivi → processi anomali eseguiti al primo boot post-iniezione. Su dispositivi di rete come i BIG-IP compromessi da Velvet Ant, il syslog del dispositivo e i log del sistema di gestione centralizzato sono le fonti primarie da correlare.

L'abuso degli RC scripts racconta una storia precisa nel panorama threat: attori sofisticati che operano al di sotto del radar degli EDR tradizionali, colpendo infrastrutture di rete e hypervisor dove la copertura di security è strutturalmente più debole.

APT29 è il gruppo con il profilo più ampio tra quelli associati a questa tecnica. L'installazione di un run command su sistemi compromessi per abilitare l'esecuzione del malware allo startup si inserisce in un modus operandi che privilegia la persistenza silenziosa e duratura. APT29 è noto per operazioni di lungo periodo: la scelta di meccanismi di boot persistence coerente con campagne in cui la furtività conta più della velocità.

UNC3886 rappresenta il caso più emblematico di specializzazione infrastrutturale. Collocare script bash in /etc/rc.local.d/ su sistemi ESXi dimostra una conoscenza approfondita dell'architettura VMware, dove la persistenza è un problema ingegneristico non banale a causa del filesystem volatile. Il target ESXi suggerisce un interesse primario per ambienti enterprise virtualizzati — il tipo di accesso che permette movimenti laterali massicci attraverso l'intera infrastruttura virtuale.

Velvet Ant sposta il focus su un'altra superficie critica: le appliance di rete. La modifica di /etc/rc.local su dispositivi F5 BIG-IP compromessi rivela un pattern di persistenza su network appliance che condivide la logica degli RC scripts ma opera in un contesto dove il monitoraggio è tipicamente assente. Questi dispositivi gestiscono traffico critico e offrono visibilità privilegiata sul flusso dati dell'organizzazione.

Pattern trasversali. Tutti e tre i gruppi condividono una caratteristica: evitano i sistemi endpoint tradizionali (workstation, server Windows) per questa tecnica, preferendo superfici dove gli strumenti di detection standard non operano — hypervisor, appliance di rete, dispositivi embedded. Il software associato riflette la stessa filosofia: Cyclops Blink colpisce dispositivi di rete con architettura ARM, HiddenWasp opera su server Linux, Green Lambert installa servizi tramite init.d su sistemi Unix.

La convergenza di questi profili indica un trend chiaro: la persistenza via RC scripts è una tecnica di nicchia ma ad alto impatto, utilizzata da attori che hanno già compromesso l'infrastruttura critica e necessitano di un meccanismo affidabile per sopravvivere ai riavvii. Il TI analyst dovrebbe monitorare con priorità le proprie appliance di rete e hypervisor come potenziali target, verificando periodicamente l'integrità dei file di startup.

Framework MITRE ATT&CK v16 — T1037.004 (Boot or Logon Initialization Scripts: RC Scripts), tattiche TA0003, TA0004. Gruppi: G1047 (Velvet Ant), G1048 (UNC3886), G0016 (APT29). Software: S0394, S0690, S0687, S0278. Mitigazione: M1022. Detection: DET0237 con analytics AN0658–AN0661. Integrato con conoscenza professionale per tool e procedure operative.