Script RC di Avvio: RC Scripts (T1037.004)

In un esercizio di red team, la manipolazione degli script RC richiede accesso root al sistema target. La catena tipica prevede escalation privilegi, individuazione dei file RC attivi sulla distribuzione, iniezione del payload e verifica della persistenza attraverso reboot controllato.

Su Linux tradizionale (Debian, Ubuntu con retrocompatibilità), il file di riferimento è /etc/rc.local. Una modifica minimalista aggiunge una riga prima di exit 0:

echo '/opt/backdoor/implant &' >> /etc/rc.local chmod +x /etc/rc.local

È fondamentale verificare che il file abbia il bit di esecuzione, altrimenti su Ubuntu moderno non verrà lanciato. In alternativa, si può creare uno script in /etc/init.d/ e registrarlo con update-rc.d nomescript defaults, replicando il pattern usato da Green Lambert con file init.d e rc.d.

Su VMware ESXi, target d'elezione documentato per UNC3886, il file chiave è /etc/rc.local.d/local.sh. L'inserimento di comandi qui garantisce persistenza attraverso reboot, nonostante ESXi resetti il filesystem in RAM, perché questo path viene reimportato dalla configurazione persistente. Un pattern realistico:

vi /etc/rc.local.d/local.sh

e aggiunta di una riga nohup /store/packages/vmtools.py & prima di exit 0. Va poi rigenerato lo stato con auto-backup.sh per garantire che la modifica sopravviva.

Su macOS legacy (fino a Panther 10.3) e in scenari di compatibilità, /etc/rc.common resta un vettore, come sfruttato da iKitten. Su macOS moderno la tecnica è deprecata a favore di launchd.

Su appliance di rete (come i BIG-IP F5 targetizzati da Velvet Ant), l'attaccante modifica /etc/rc.local direttamente via shell bash dopo aver ottenuto un accesso amministrativo, spesso sfruttando vulnerabilità di management interface.

Per laboratorio consiglio Atomic Red Team (open source) che include test T1037.004 pronti all'uso, e Caldera (open source) di MITRE per automazioni end-to-end. Per validazione post-exploitation, systemd-analyze (open source, incluso in systemd) mostra i servizi effettivamente lanciati al boot, mentre chkconfig --list (open source) elenca gli script init.d attivi. Su ESXi, esxcli system syslog config get aiuta a capire cosa viene loggato durante il boot, informazione utile per pianificare evasione. Ricordate di documentare ogni modifica in scope per il rollback pulito.

La detection di T1037.004 si fonda sul monitoraggio dell'integrità dei file RC e sulla correlazione con eventi di boot. La strategia DET0237 identifica quattro piattaforme d'interesse con analytiche dedicate.

Su Linux (analytica AN0658), la fonte primaria è auditd. Va configurata una regola watch sui file critici:

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

Gli eventi SYSCALL con syscall open, openat, rename verso questi path generano alert. Correlare con linux:syslog per catturare l'esecuzione post-reboot: qualsiasi processo child di rc.local che non sia un binario noto (network manager, script custom autorizzati) è sospetto. Falso positivo tipico: modifiche legittime da parte di configuration management come Ansible o Puppet — mitigabile filtrando per utente e per finestra di manutenzione.

Su macOS (AN0659), la telemetria arriva dallo unified log e da fs_usage. Interrogazioni utili cercano scritture su /etc/rc.common, /Library/StartupItems/, /System/Library/StartupItems/. L'esecuzione di log stream --predicate 'eventMessage contains "rc.common"' durante troubleshooting mostra l'attività real-time. Il tuning parametri include script_name, finestra temporale tra modifica e reboot, e permessi risultanti.

Su ESXi (AN0660), la sfida è che la telemetria nativa è limitata. Occorre inoltrare esxi:syslog e esxi:shell verso un SIEM esterno. Alert prioritari: qualsiasi modifica a /etc/rc.local.d/local.sh effettuata via shell SSH o via ESXi Shell, specialmente fuori orario di manutenzione, e presenza di comandi non standard (curl verso IP esterni, esecuzione di script Python custom, riferimenti a path in /store/ o /tmp/). Vista la campagna documentata di UNC3886 su ESXi, questo controllo dovrebbe avere priorità critica in ambienti VMware.

Su network devices (AN0661), i log syslog dell'appliance devono essere centralizzati. Pattern di detection: modifica config seguita da reboot in finestra ristretta (<24h), comandi CLI insoliti nello startup-config, riferimenti a interfacce management inaspettate.

Complementari: Wazuh (open source) con moduli FIM su /etc/rc*, OSSEC (open source) e AIDE (open source) come baseline di integrità. Per stack SIEM, regole Sigma pubbliche coprono T1037.004 e sono importabili in Splunk, Elastic e Sentinel. Threshold consigliata: alert immediato su qualsiasi write a rc.local fuori change window, con enrichment del PID parent e dell'utente effettivo (verificare auid per identificare utente originario in caso di sudo su).

L'analisi forense di T1037.004 richiede la ricostruzione di due momenti: la modifica dello script e la sua esecuzione al boot. Gli artefatti principali variano per piattaforma.

Su Linux, il primo passo è acquisire i file RC e i loro metadati. Comandi utili in fase di triage live:

stat /etc/rc.local /etc/rc.common ls -la /etc/init.d/ /etc/rc.d/* find /etc -name 'rc' -newer /etc/hostname -ls*

Il campo ctime è particolarmente rivelatore perché non è modificabile con touch -t standard e riflette l'ultima modifica dell'inode. Su filesystem ext4 è possibile estrarre timestamp aggiuntivi tramite debugfs -R 'stat ' /dev/sdaX. I log auditd in /var/log/audit/audit.log, se attivi, contengono la SYSCALL di modifica con auid, uid effettivo, PID parent e comm — cruciali per attribuzione. Il file /var/log/wtmp e /var/log/auth.log aiutano a correlare la sessione SSH con la finestra di modifica.

Essenziale confrontare hash contro baseline: se manca, ricostruire da package manager originale con dpkg -V (Debian/Ubuntu, open source) o rpm -Va (RHEL/CentOS, open source). Un output con 5 nella colonna hash su rc.local indica modifica rispetto al pacchetto originale.

Su ESXi, il caso UNC3886 documenta script bash piazzati in /etc/rc.local.d/. L'acquisizione richiede accesso via ESXi Shell o vSphere. File di interesse: /etc/rc.local.d/local.sh, /etc/rc.local.d/009.vmware-configure.sh e cartelle simili. Va ispezionato anche /bootbank/state.tgz, che contiene lo stato persistente reimportato al boot: qualsiasi modifica a rc.local.d è replicata qui e sopravvive al reset RAM. Estrarre con tar xzf state.tgz in ambiente isolato e cercare artefatti aggiunti.

Su macOS, oltre a /etc/rc.common (target di iKitten), verificare /Library/StartupItems/ e /System/Library/StartupItems/. Lo unified log macOS conserva eventi di boot per giorni; interrogare con:

log show --predicate 'process == "launchd"' --last 7d

Per la timeline consolidata, Plaso/log2timeline (open source) supporta parsing di auditd, syslog e macOS unified log, producendo un supertimeline in cui la modifica dello script si allinea con esecuzioni sospette al boot successivo. Velociraptor (open source) offre artefatti pronti per hunting di persistence Linux, incluso il modulo Linux.Sys.BootPersistence. In casi come Cyclops Blink, che rinomina uno script (S51armled) mimando naming convention di init, è cruciale confrontare l'inventario script con la baseline della distribuzione: qualsiasi file S[0-9]{2}[a-z]+ non riconducibile a pacchetto legittimo va isolato per analisi malware.

Il panorama delle minacce che abusano di T1037.004 mostra una netta specializzazione geografica e settoriale, con concentrazione su infrastruttura critica di virtualizzazione, appliance di rete e sistemi embedded.

APT29 (noto anche come Cozy Bear, attribuito al servizio di intelligence estera russa SVR) rappresenta l'attore state-sponsored più maturo che ha impiegato modifiche a run command per abilitare esecuzione malware allo startup. Il gruppo è storicamente associato a operazioni di spionaggio contro governi occidentali, think tank e supply chain IT (celebre il caso SolarWinds), e l'uso di RC scripts si inserisce in una toolchain ampia dove la persistenza cross-boot è un requisito per operazioni a lungo termine.

UNC3886, cluster tracciato con focus su ipervisori VMware ESXi e appliance FortiGate, ha piazzato script bash di installazione in /etc/rc.local.d/ per persistenza su ESXi. Il gruppo ha targettizzato aziende Defense Industrial Base, telecomunicazioni e settore tecnologico, principalmente in Nord America e Asia. La scelta di ESXi non è casuale: comprometterlo consente accesso a tutte le VM ospitate senza generare telemetria endpoint tradizionale, e rc.local.d è uno dei pochi meccanismi di persistenza sopravvissuti al design di ESXi.

Velvet Ant, attore documentato per operazioni prolungate contro aziende asiatiche del settore enterprise, ha modificato /etc/rc.local su dispositivi F5 BIG-IP compromessi. Il gruppo dimostra pazienza operativa notevole (persistenze pluriennali documentate) e predilige target di edge network dove la visibilità del blue team è limitata. L'abuso di rc.local su BIG-IP consente di sopravvivere ai reboot manutentivi mantenendo tunnel C2 verso l'infrastruttura core.

Sul piano malware, la varietà tecnica è significativa: iKitten (macOS) usa rc.common, coprendo un vettore ormai legacy ma ancora presente in ambienti macOS non aggiornati. HiddenWasp (Linux) inserisce riferimenti in /etc/rc.local come parte di una toolchain modulare associata a operazioni cinesi. Cyclops Blink (attribuito a Sandworm, GRU russo) ha usato uno script rinominato S51armled su dispositivi WatchGuard e ASUS, mostrando adattamento a firmware embedded. Green Lambert, storicamente collegato a operazioni di intelligence occidentali, sfrutta sia init.d che rc.d in /etc.

Il pattern trasversale è chiaro: RC scripts restano vitali dove systemd non è disponibile o dove il default runtime è root — esattamente gli ambienti (ipervisori, edge network, IoT industriale) che gli attori state-sponsored più capaci stanno prioritizzando. Il trend previsto è un aumento di targeting ESXi e appliance, dove la superficie di detection endpoint è minima e la persistenza rc.local resta un vettore altamente efficace.

MITRE ATT&CK: tecnica T1037.004, tattiche TA0003 e TA0004, gruppi G0016 (APT29), G1047 (Velvet Ant), G1048 (UNC3886), software S0278, S0394, S0687, S0690, mitigazione M1022, detection strategy DET0237 (analytiche AN0658-AN0661). Framework difensivo MITRE D3FEND per mapping harden/detect. Il documento integra conoscenza professionale di cybersecurity per comandi operativi, sintassi tool (auditd, debugfs, Wazuh, Velociraptor, Plaso, Atomic Red Team) e procedure forensi, verificati su documentazione ufficiale dei rispettivi progetti open source.