Persistenza tramite Autostart Desktop Linux: XDG Autostart Entries (T1547.013)

In un ingaggio red team su endpoint Linux con desktop environment, la persistenza XDG è tra le prime opzioni da valutare perché non richiede privilegi, non tocca cron o systemd (spesso monitorati) e sopravvive a reboot senza artefatti particolarmente rumorosi.

La procedura minima consiste nel creare un file .desktop valido nella directory utente. Un esempio funzionante di payload:

mkdir -p ~/.config/autostart

cat > ~/.config/autostart/gnome-session-helper.desktop <<EOF [Desktop Entry] Type=Application Name=GNOME Session Helper Exec=/tmp/.cache/beacon Hidden=false NoDisplay=false X-GNOME-Autostart-enabled=true EOF

Le direttive rilevanti da conoscere sono Exec= (comando o binario), Hidden=true (nasconde l'entry dalla GUI di gestione autostart in GNOME Tweaks o simili), OnlyShowIn=GNOME; per limitare l'esecuzione a specifici DE, e X-GNOME-Autostart-Delay=N per ritardare l'esecuzione ed evitare correlazione temporale con il logon.

Per la fase di weaponization il payload può essere generato con msfvenom (open source, incluso in Metasploit Framework) come reverse shell ELF, oppure con Sliver (open source) che offre implant Linux più moderni e resistenti a signature. Un pattern efficace è puntare Exec= a uno script bash che lancia in background l'implant e disowna il processo, così il crash dell'implant non blocca il caricamento della sessione desktop.

Per masquerading conviene enumerare prima gli entry legittimi presenti sul sistema target: ls -la ~/.config/autostart/ /etc/xdg/autostart/ e replicare naming convention e commenti multilingua tipici (es. Comment[it]=, GenericName=) per rendere l'entry indistinguibile da uno pacchettizzato.

Se si dispone di privilegi root, il posizionamento in /etc/xdg/autostart/ garantisce esecuzione per ogni utente che effettua login, moltiplicando le occasioni di harvesting credenziali o pivot. Attenzione al fatto che alcune distribuzioni (Fedora recenti, Ubuntu con SELinux/AppArmor in enforcing) applicano policy MAC che possono bloccare l'esecuzione di binari da path non standard come /tmp o /dev/shm — testare in laboratorio la distribuzione esatta del target.

Per emulazione avversariale strutturata, Atomic Red Team (open source, di Red Canary) include il test T1547.013 con payload pronti che possono essere adattati. In ambienti CTF o lab, Caldera (open source, MITRE) permette di orchestrare la tecnica come parte di catene più ampie che includono initial access via phishing e successiva discovery.

La detection di T1547.013 ruota attorno a due segnali complementari: la creazione o modifica di file .desktop in directory di autostart e la esecuzione di processi figli del gestore di sessione desktop all'inizio della sessione utente. La strategia MITRE DET0390 (AN1096) formalizza esattamente questa correlazione con una finestra temporale di 0-5 minuti dal logon.

La fonte primaria è auditd. Va configurata una watch rule sulle directory rilevanti:

-w /etc/xdg/autostart/ -p wa -k xdg_autostart -w /home -p wa -k xdg_autostart_user

La seconda regola è volutamente ampia sulla home per catturare qualsiasi utente; in ambienti con molti account conviene invece iterare per utente reale o usare find in fase di deploy per generare regole mirate su ogni ~/.config/autostart/. Gli eventi SYSCALL con syscall openat o rename seguiti da nomi terminanti in .desktop sono l'indicatore base.

Sul fronte esecuzione, gli eventi EXECVE con parent process gnome-session-binary, ksmserver, xfce4-session o mate-session che lanciano binari inattesi meritano triage. Un enrichment prezioso è verificare se il processo eseguito appartiene a un pacchetto installato: dpkg -S /path/to/binary su Debian/Ubuntu o rpm -qf su RHEL. Un binario in /tmp, /dev/shm, ~/.cache o path utente non pacchettizzato è fortemente sospetto.

osquery (open source) offre query dirette che si integrano bene in un SIEM. La tabella startup_items su Linux enumera gli entry XDG e può essere schedulata a intervalli con hash del contenuto per rilevare drift. Query di baseline utile è confrontare periodicamente l'elenco di .desktop con lo snapshot iniziale post-hardening.

Per il tuning suggerito da DET0390 vanno considerati: ExecCommandPattern (mantenere allowlist regex di path attesi come /usr/bin/, /usr/libexec/, /opt/); AutostartDirectory (enumerare variabile $XDG_CONFIG_HOME che può ridefinire il path standard); UserContext (filtrare utenti di servizio con UID < 1000 dove XDG non ha senso operativo); PackageOriginBaseline (correlazione con package manager).

I falsi positivi più comuni derivano da installazioni di applicazioni desktop legittime (Spotify, Discord, Steam, client VPN) che aggiungono entry autostart durante il setup, e da tool di sincronizzazione (Nextcloud, Dropbox, Syncthing). Una correlazione con eventi di package manager (dpkg, apt, dnf, flatpak install) nella finestra temporale precedente riduce drasticamente il rumore. Wazuh (open source) fornisce moduli FIM già pronti per monitorare queste directory con alert configurabili.

In un'analisi post-incident su host Linux compromesso, le directory XDG autostart sono un check obbligatorio nella fase di persistence hunting. L'ispezione manuale parte da:

ls -la /etc/xdg/autostart/ ~/.config/autostart/ /root/.config/autostart/

seguita da lettura dei file con particolare attenzione alla direttiva Exec=, al campo Name= (spesso masqueraded) e alla data di modifica (stat filename.desktop). Il timestamp mtime e ctime dei file .desktop è il primo pivot temporale: va confrontato con la timeline generale dell'incidente costruita con plaso/log2timeline (open source) o Sleuth Kit (open source).

Gli artefatti chiave da collezionare sono: contenuto integrale dei file .desktop sospetti, il binario o script referenziato in Exec= con relativo hash SHA-256 per lookup su VirusTotal (freemium), i log di auditd in /var/log/audit/audit.log filtrati per la chiave definita nelle watch rule, e i log di autenticazione in /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL) per correlare i login utente con l'esecuzione degli entry.

I journal di systemd meritano ispezione con journalctl --user -u gnome-session (o l'unit del DE in uso) che spesso registra il caricamento dei componenti autostart e può rivelare errori se il binario malevolo fallisce. Su sistemi con rsyslog o syslog-ng i log sono in /var/log/syslog.

Per la ricostruzione della timeline il pattern tipico osservato nelle campagne documentate è: (1) initial access — spesso via phishing o supply chain come nel caso di InvisibleFerret distribuito da Contagious Interview attraverso finti processi di assunzione a sviluppatori; (2) drop del payload in directory utente come ~/.cache/ o ~/.local/share/; (3) creazione dell'entry .desktop in ~/.config/autostart/ con delay temporale tipicamente inferiore a 60 secondi rispetto al drop; (4) prima esecuzione del payload al successivo logon utente.

Artefatti di supporto includono la shell history (~/.bash_history, ~/.zsh_history) — spesso disabilitata o troncata dall'attaccante ma comunque da verificare — e i file ~/.xsession-errors che possono contenere output stderr del payload se non ridiretto. La tabella startup_items di osquery può essere eseguita anche in modalità forense su immagine montata read-only.

Per campagne come RotaJakiro, documentata come particolarmente evasiva grazie a cifratura del traffico C2 e naming legittimo dei file, l'analisi statica del binario referenziato con radare2 (open source) o Ghidra (open source, NSA) è essenziale per estrarre IOC di rete e confermare l'attribuzione. Fysbis, attribuito storicamente a operazioni contro target di alto profilo, mostra il pattern di fallback verso ~/.config/autostart/ esattamente quando l'esecuzione avviene senza root.

L'adozione di XDG Autostart Entries come tecnica di persistenza riflette una tendenza precisa nel panorama delle minacce: la crescente attenzione degli attaccanti verso endpoint Linux desktop, storicamente sotto-monitorati rispetto agli equivalenti Windows. I dati MITRE mostrano un mix interessante di attori state-sponsored e strumenti offensive-security ripurposed.

Contagious Interview (G1052) è l'unico gruppo APT esplicitamente mappato a questa tecnica. Il modus operandi documentato prevede l'uso di InvisibleFerret (S1245) come payload di seconda fase, deployato dopo initial access ottenuto tramite finte offerte di lavoro rivolte a sviluppatori. L'entry .desktop viene creato specificamente per ambienti GNOME su Linux, riflettendo una scelta target-aware verso la workstation tipica dello sviluppatore. Questo pattern operativo indica capacità di targeting multi-piattaforma (macOS e Windows sono anch'essi target di InvisibleFerret in varianti diverse).

Sul fronte malware families, NETWIRE (S0198) rappresenta il caso più longevo: RAT commerciale venduto come strumento legittimo di remote administration ma ampiamente abusato da threat actor di vario livello, con capacità cross-platform e supporto esplicito a XDG per la versione Linux. Pupy (S0192) è un post-exploitation framework open source scritto in Python, apprezzato da red team ma osservato anche in operazioni malevole reali, che offre modulo dedicato per la persistenza XDG.

CrossRAT (S0235) è stato attribuito storicamente a operazioni di sorveglianza contro attivisti e giornalisti, con implementazione cross-platform (Windows, macOS, Linux) che dimostra l'intento di coprire l'intera superficie della vittima indipendentemente dal sistema in uso. Fysbis (S0410) è un backdoor Linux modulare associato a operazioni contro settori difesa e diplomatico, notevole per la logica di fallback: usa systemd o init.d con privilegi root, altrimenti degrada a XDG autostart in contesto utente — un design che massimizza le probabilità di persistenza.

RotaJakiro (S1078) merita menzione a parte: scoperto tardivamente dopo anni di attività non rilevata, ha caratteristiche di sofisticazione (traffico C2 cifrato multi-layer, naming legittimo di file e processi) tipiche di attori state-level, sebbene l'attribuzione pubblica rimanga incerta.

Il trend prevedibile è l'aumento di questa tecnica in scenari di targeting a sviluppatori, DevOps engineer e ricercatori — categorie che utilizzano Linux desktop con maggiore frequenza e spesso hanno accesso a repository codice, infrastruttura cloud e credenziali privilegiate. La combinazione con supply chain attacks su pacchetti npm, PyPI o estensioni VSCode (pattern già osservato in operazioni Contagious Interview) rende XDG persistence uno strumento particolarmente efficace nella catena post-compromise.

MITRE ATT&CK T1547.013 (XDG Autostart Entries), tattiche TA0003 e TA0004. Gruppi: G1052. Software: S0192, S0198, S0235, S0410, S1078, S1245. Mitigazioni: M1018, M1022, M1033. Detection: DET0390 (AN1096). Specifiche freedesktop.org Desktop Entry. Conoscenza professionale Livello 2 utilizzata per comandi auditd, osquery, sintassi .desktop, tool open source (Metasploit, Sliver, Atomic Red Team, Caldera, Wazuh, plaso, Ghidra, radare2) e VirusTotal (freemium).