Stored Procedure Malevole: SQL Stored Procedures (T1505.001)

Un red team che voglia simulare T1505.001 in laboratorio deve partire da un presupposto: servono credenziali con ruolo sysadmin o quantomeno db_owner sul database target. L'accesso può derivare da SQL injection, credenziali riutilizzate estratte da file di configurazione, o account di servizio compromessi.

Su MSSQL Server, il primo passo tipico è verificare lo stato di xp_cmdshell interrogando sp_configure e, se disabilitato, riabilitarlo (richiede sysadmin). La sequenza operativa classica prevede prima EXEC sp_configure 'show advanced options', 1; RECONFIGURE; seguito dall'abilitazione della funzione e infine dall'esecuzione di comandi tramite EXEC xp_cmdshell 'whoami';. Per rendere l'accesso persistente si crea una stored procedure che incapsuli il comando e la si lega a un trigger di startup con sp_procoption, in modo che venga eseguita a ogni avvio del servizio SQL.

La via CLR è più stealth. Si compila un assembly .NET (ad esempio con csc.exe) che espone un metodo statico, si abilita clr enabled e, per assembly non firmati, clr strict security va aggirato marcando il database come TRUSTWORTHY o firmando l'assembly. L'assembly viene caricato con CREATE ASSEMBLY da un file o da un blob esadecimale inline, poi collegato a una stored procedure con CREATE PROCEDURE ... AS EXTERNAL NAME.

Sul fronte tooling, PowerUpSQL (open source, repository NetSPI su GitHub) è il framework di riferimento per l'enumerazione e l'exploitation MSSQL: espone cmdlet come Get-SQLServerInfo, Invoke-SQLOSCmd e Get-SQLStoredProcedureAutoExec. mssqlclient.py dello Impacket suite (open source) permette interazione da Linux con supporto a xp_cmdshell e autenticazione integrata Kerberos. Per la parte CLR, SharpSQLTools e SQLRecon (open source) automatizzano la generazione, il caricamento e l'esecuzione di assembly custom.

Su PostgreSQL un pattern analogo passa per CREATE FUNCTION ... LANGUAGE plpythonu o plperlu se le lingue untrusted sono installate, oppure tramite UDF caricate da libreria condivisa. Su MySQL/MariaDB l'equivalente è l'abuso di UDF caricate da .so o .dll copiate in plugin_dir.

In laboratorio, isolare sempre l'ambiente in una VM segregata, documentare ogni assembly caricato e prevedere script di cleanup che rimuovano procedure, assembly e riportino le opzioni server allo stato iniziale. Evitare di lasciare TRUSTWORTHY ON sui database di test connessi a domini reali.

La detection di T1505.001 si costruisce su tre pilastri: monitoring delle configurazioni server, tracciamento delle DDL sulle stored procedure e correlazione con l'esecuzione di processi figli del servizio SQL.

Sul primo pilastro, ogni modifica a opzioni sensibili tramite sp_configure — in particolare xp_cmdshell, clr enabled, clr strict security, Ole Automation Procedures — deve generare un alert ad alta priorità. Questi eventi vanno abilitati tramite SQL Server Audit con action group SERVER_STATE_CHANGE_GROUP e SERVER_OBJECT_CHANGE_GROUP, che scrivono su file .sqlaudit o direttamente nel Windows Application EventLog con source MSSQLSERVER. La detection AN0511 indica proprio WinEventLog:Application e WinEventLog:Sysmon come sorgenti primarie.

Il secondo pilastro riguarda le DDL: CREATE PROCEDURE, ALTER PROCEDURE, CREATE ASSEMBLY e sp_procoption vanno catturate tramite audit group DATABASE_OBJECT_CHANGE_GROUP e SCHEMA_OBJECT_CHANGE_GROUP. Particolare attenzione alle procedure marcate per auto-execution allo startup e agli assembly caricati con PERMISSION_SET = UNSAFE o EXTERNAL_ACCESS, che rappresentano un forte segnale di abuso perché consentono chiamate P/Invoke verso Win32.

Il terzo pilastro sfrutta Sysmon Event ID 1 (Process Create) per intercettare processi figli di sqlservr.exe: la comparsa di cmd.exe, powershell.exe, wmic.exe, rundll32.exe o net.exe come discendenti diretti è quasi sempre anomala in produzione. Una regola Splunk o Sentinel efficace correla ParentImage="\sqlservr.exe"* con Image appartenente a una lista di binari LOLBAS. Il parametro di tuning xp_cmdshell_invocation_threshold citato nella detection AN0511 serve a filtrare ambienti dove alcune procedure legittime — tipicamente job SSIS o ETL legacy — usano xp_cmdshell, e la whitelist CLRAssemblyNameWhitelist serve a escludere assembly noti di terze parti.

Su Linux, dove gira MSSQL 2017+ o PostgreSQL/MySQL, la detection AN0512 punta su auditd:SYSCALL per intercettare execve originati dal processo sqlservr o postgres, correlati con ApplicationLogs:SQL. Regole auditd con -F ppid che tracciano il PID del servizio DB sono il meccanismo base.

I falsi positivi più comuni riguardano job di manutenzione, DBA che eseguono script diagnostici e agenti di backup che usano procedure custom. Una baseline di 30 giorni per identificare le procedure legittime che invocano xp_cmdshell riduce drasticamente il rumore. In coerenza con M1047 (Audit), va pianificata una review trimestrale dell'elenco assembly CLR e delle procedure con is_auto_executed = 1.

Un'indagine forense su sospetta compromissione via T1505.001 parte dall'estrazione di quattro categorie di artefatti dal database server.

La prima è l'inventario delle stored procedure e degli assembly. Le viste di sistema sys.procedures, sys.sql_modules, sys.assemblies e sys.assembly_modules contengono nome, data di creazione (create_date), data di modifica (modify_date) e — per gli assembly — il flag permission_set_desc. Un assembly con UNSAFE creato di recente e non presente nella baseline è un indicatore forte. Il codice sorgente delle procedure T-SQL è recuperabile da sys.sql_modules.definition, mentre il binario degli assembly CLR è estraibile da sys.assembly_files.content come blob esadecimale, poi analizzabile con dnSpy o ILSpy (entrambi open source) per il reverse engineering .NET.

La seconda categoria è la configurazione persistente: sys.configurations mostra lo stato di xp_cmdshell, clr enabled, Ole Automation Procedures. La query SELECT * FROM sys.procedures WHERE OBJECTPROPERTY(object_id, 'ExecIsStartup') = 1 elenca le procedure marcate per auto-esecuzione allo startup del servizio, meccanismo tipico della persistenza.

La terza categoria sono i log applicativi. Il SQL Server ERRORLOG, tipicamente in C:\Program Files\Microsoft SQL Server\MSSQL\MSSQL\Log*, registra avvii del servizio, modifiche di configurazione e messaggi di xp_cmdshell. I file di SQL Server Audit (.sqlaudit) sono leggibili tramite sys.fn_get_audit_file e forniscono la trail di DDL con timestamp preciso e principal name. Se attivo, il Default Trace (log_NN.trc) contiene eventi di Object:Created e Audit Server Alter Trace Event per finestre temporali di alcune ore.

La quarta categoria copre gli artefatti sistema operativo. Su Windows, Sysmon Event ID 1 con parent sqlservr.exe materializza la timeline dei comandi eseguiti, mentre Event ID 11 (File Create) intercetta assembly DLL scritti su disco. I Prefetch (C:\Windows\Prefetch*.pf) di cmd.exe o powershell.exe con timestamp vicini all'attività SQL corroborano l'esecuzione. Su Linux, i log auditd e /var/opt/mssql/log/errorlog forniscono l'equivalente.

Per la ricostruzione della timeline, correlare create_date delle procedure sospette con gli eventi di process creation e con le connessioni di rete (sys.dm_exec_connections fornisce solo dati live, ma i log firewall e i Sysmon Event ID 3 riempiono il gap storico). La campagna C0025 (2016 Ukraine Electric Power Attack) di Sandworm Team contro il grid ucraino ha visto proprio l'uso di varie stored procedure MS-SQL, il che rende i pattern di analisi qui descritti direttamente applicabili a casi ICS/OT dove il database è nodo di integrazione tra IT e sistemi di controllo.

Il quadro di threat intelligence su T1505.001 è concentrato ma qualitativamente rilevante, perché tocca due dei casi più studiati della storia recente delle operazioni cyber offensive.

Il primo riferimento è Stuxnet (S0603), il malware attribuito pubblicamente a operazioni congiunte statunitensi e israeliane contro il programma nucleare iraniano di Natanz, scoperto nel 2010. Nel contesto T1505.001, Stuxnet ha sfruttato xp_cmdshell per memorizzare ed eseguire codice SQL come parte della sua catena di propagazione, che coinvolgeva il database WinCC di Siemens utilizzato dai sistemi SCADA. L'uso di stored procedure serviva sia per la persistenza sui server WinCC sia come vettore laterale per raggiungere altri componenti dell'infrastruttura. Il pattern è caratteristico: l'attaccante identifica un database di supporto a sistemi industriali, dove i controlli di monitoring endpoint sono tipicamente deboli, e lo trasforma in beachhead persistente.

Il secondo riferimento è la campagna C0025 — 2016 Ukraine Electric Power Attack, condotta da Sandworm Team nel dicembre 2016 contro sottostazioni di distribuzione della rete elettrica ucraina. Sandworm è un gruppo attribuito da fonti governative occidentali all'unità 74455 del GRU russo. In questa operazione, che ha impiegato il malware Industroyer (noto anche come CrashOverride), gli attaccanti hanno utilizzato varie stored procedure MS-SQL come parte dell'attività di persistenza e movimento. Si tratta della seconda grande operazione pubblica di Sandworm contro l'Ucraina, dopo l'attacco del dicembre 2015 che aveva già colpito distributori elettrici ucraini.

Il pattern comune ai due casi documentati è indicativo: T1505.001 tende a emergere in operazioni di alto profilo contro infrastrutture critiche, dove il database non è il target finale ma un componente di supporto a sistemi ICS/SCADA. Questa collocazione lo rende particolarmente insidioso perché i team OT raramente hanno visibilità EDR sui database Windows che sostengono HMI e historian, e i team IT raramente considerano i server SQL come asset a rischio compromissione avanzata.

Dal punto di vista del targeting geografico, entrambi i casi documentati riguardano operazioni statuali con obiettivi geopolitici precisi (Iran, Ucraina) e settore energia/nucleare. La lezione operativa per i team di threat intelligence è che T1505.001 va considerato un indicatore di sofisticazione avanzata: la sua presenza in un incident suggerisce un attore con capacità di sviluppo custom, familiarità con l'ambiente target e obiettivi di persistenza a lungo termine.

Le mitigazioni prioritarie convergono sui tre controlli MITRE: M1026 (Privileged Account Management) per limitare i ruoli sysadmin, M1045 (Code Signing) per gli assembly CLR firmati da autorità attendibili, e M1047 (Audit) per la review periodica di procedure e assembly caricati.

MITRE ATT&CK: T1505.001 (SQL Stored Procedures), tattica TA0003. Software S0603 (Stuxnet). Campagna C0025 (2016 Ukraine Electric Power Attack — Sandworm Team, Industroyer). Mitigazioni M1026, M1045, M1047. Detection DET0181 con analitiche AN0511 (Windows) e AN0512 (Linux). Le sezioni operative su tool (PowerUpSQL, Impacket, SQLRecon, dnSpy, ILSpy), sintassi T-SQL, viste di sistema SQL Server, Sysmon e auditd derivano da conoscenza professionale in cybersecurity basata su documentazione ufficiale Microsoft e progetti open source verificabili.