Saccheggiare i Database: Data from Information Repositories: Databases (T1213.006)

L'obiettivo in un red team engagement è dimostrare che un attaccante, dopo aver ottenuto credenziali valide o accesso a un host con connettività verso il database, può estrarre dati sensibili in modo silenzioso e rapido. La simulazione deve coprire tre fasi: discovery, query mirata e esfiltrazione locale.

La prima fase è l'enumerazione. Su un host compromesso con accesso alla rete interna, lo scanning delle porte database classiche permette di mappare le istanze raggiungibili. Con Nmap (open source) è sufficiente un comando mirato:

nmap -sV -p 3306,5432,1521,27017,1433

Una volta individuata un'istanza MySQL, l'accesso con credenziali raccolte durante la fase di privilege escalation è banale. Il client mysql (open source), presente sulla maggior parte dei sistemi Linux, consente di enumerare i database disponibili:

mysql -h -u -p -e "SHOW DATABASES;"

Per PostgreSQL il flusso è analogo con psql (open source):

psql -h -U -c "SELECT datname FROM pg_database;"

La fase critica è l'estrazione. Per simulare ciò che Sandworm Team e Sea Turtle fanno con Adminer — un tool di gestione database via web scritto in PHP (open source) — si può deployare il singolo file PHP su un webserver già compromesso e usarlo come interfaccia grafica per navigare tabelle ed esportare dati. In laboratorio, è più diretto usare i client nativi per il dump. Su MySQL:

mysqldump -h -u -p --single-transaction > /tmp/dump.sql

Su SQL Server, per replicare le operazioni documentate per FIN6 che raccoglie schema e account, si può usare sqlcmd (incluso con SQL Server):

sqlcmd -S -U -P -Q "SELECT name, type_desc FROM sys.databases;" -o C:\Temp\db_enum.txt

Per scenari Oracle — come nella campagna APT41 DUST dove è stato usato il tool SQLULDR2 per esportare dati — si può simulare con SQLcl (gratuito, distribuito da Oracle):

sql /@:1521/ <<< "SELECT * FROM hr.employees;" > /tmp/oracle_dump.csv

Sul fronte MongoDB (NoSQL), il tool mongoexport (open source, parte di MongoDB Database Tools) consente l'esportazione diretta:

mongoexport --host --db --collection --out /tmp/mongo_dump.json

Ricorda di documentare ogni passaggio per il report e di concordare preventivamente con il cliente il perimetro dei dati che possono essere toccati.

La detection dell'accesso malevolo ai database è una sfida di contesto: gli stessi tool e le stesse query usate dagli attaccanti sono identici a quelli impiegati da DBA e sviluppatori ogni giorno. La chiave è costruire baseline comportamentali solide e correlare eventi multi-sorgente.

Partiamo dai log essenziali. Su Linux, il framework auditd è la prima linea. Le syscall EXECVE che lanciano client database come psql, mysql, mongo o mongodump devono essere catturate e correlate con il processo padre. Se il parent process è una reverse shell, un interprete inatteso (Python, Perl) o un processo web (Apache, Nginx), l'alert deve scattare immediatamente. I log auditd:SYSCALL e auditd:PATH sono le sorgenti primarie.

Su Windows, Sysmon (open source, Microsoft) è indispensabile. L'EventCode 1 (Process Create) deve monitorare l'esecuzione di sqlcmd.exe, isql.exe, bcp.exe e tool ODBC da percorsi inusuali o con parent process anomali come explorer.exe o powershell.exe. L'EventCode 11 (File Create) cattura la scrittura di file con estensioni .sql, .bak, .csv nelle directory temporanee utente — un pattern coerente con dump non autorizzati.

Per gli ambienti cloud IaaS, i log di audit nativi sono fondamentali. Su AWS, CloudTrail registra ogni chiamata API a RDS, Redshift e DynamoDB: cercate azioni come rds:DownloadDBLogFilePortion, s3:PutObject su bucket non autorizzati, o query massive da ruoli IAM non associati a operazioni database. Su Azure, i Diagnostic Logs di Azure SQL catturano query e connessioni anomale.

Per le piattaforme SaaS come Snowflake o Firebase, gli audit log nativi della piattaforma sono l'unica sorgente. Monitorare export massivi, query su tabelle sensibili fuori dall'orario lavorativo, e accessi da IP o user-agent insoliti.

Il tuning è critico per evitare tsunami di falsi positivi. Mantenete aggiornate le whitelist:

• AllowedDBClients: account di servizio e automazione legittimati ad usare client database
• DumpFilePattern: pattern di filename per dump leciti (es. backup notturni con naming convention aziendale)
• TimeWindow: finestra temporale per correlare esecuzione client → scrittura file → trasferimento outbound
• IAMAccessPatterns: ruoli IAM autorizzati a operazioni database in cloud

Un buon alert correla almeno due dei tre stadi: esecuzione di un client database, creazione di un file di export, trasferimento di volume anomalo verso l'esterno. L'alert single-stage genera troppo rumore; quello multi-stage rileva il comportamento reale dell'attaccante.

Quando un'indagine punta verso l'esfiltrazione da database, la timeline deve ricostruire la catena completa: dall'accesso iniziale al database fino al trasferimento dei dati fuori dal perimetro. Gli artefatti variano enormemente tra ambienti on-premise e cloud, ma il filo conduttore è sempre lo stesso — chi ha eseguito cosa, quando e verso dove.

Su Windows, iniziate dai log di processo. Il registro eventi Security (EventID 4688) con audit delle command line attivo mostra le invocazioni di sqlcmd.exe, bcp.exe o tool JDBC/ODBC. Sysmon EventCode 1 offre un dettaglio superiore con hash del processo, parent process e working directory. Cercate la catena: un processo sospetto genera un client database, che a sua volta scrive file in %TEMP%, %USERPROFILE%\Downloads o directory di staging.

Gli artefatti del filesystem sono altrettanto eloquenti. File con estensione .sql, .bak, .csv creati in orari anomali o in directory inusuali sono indicatori forti. La MFT (Master File Table) e il $UsnJrnl conservano traccia della creazione e rinomina di questi file anche dopo la cancellazione. Prefetch files per sqlcmd.exe o tool simili dimostrano l'esecuzione anche se i log eventi sono stati cancellati.

Le chiavi di registro ODBC (HKLM\SOFTWARE\ODBC\ODBC.INI) possono rivelare configurazioni di connessione create dall'attaccante. Un DSN (Data Source Name) non documentato che punta a un server database interno è un artefatto prezioso che collega l'host compromesso al target.

Su Linux, i log di auditd sono la sorgente principale. Le regole per le syscall execve catturano ogni invocazione di client database con argomenti completi. La bash_history (o equivalente per la shell in uso) può contenere comandi di dump con credenziali in chiaro — un errore operativo comune anche per gruppi sofisticati. I file di dump nel filesystem vanno cercati con attenzione nelle directory /tmp, /var/tmp e nelle home directory.

Per le campagne documentate, i pattern sono indicativi. Nella campagna Leviathan Australian Intrusions (C0049), gli operatori hanno raccolto dati da SQL Server e sistemi BMS — cercate connessioni ODBC/JDBC verso server non standard. In APT41 DUST (C0040), il tool SQLULDR2 è stato usato per estrarre dati da database Oracle: la presenza di questo binario o dei suoi artefatti (file di configurazione, output CSV con naming specifico) è un indicatore ad alta confidenza.

Sui log del database stesso — se disponibili — le query anomale sono la prova più diretta. Statement SELECT * su tabelle sensibili, SHOW DATABASES, enumerazione di schemi e utenti (come fatto da FIN6) o export massivi lasciano tracce nei slow query log, general log (MySQL) o pg_log (PostgreSQL). Correlate il timestamp delle query con gli artefatti endpoint per chiudere la timeline.

L'accesso ai database come tecnica di collection è trasversale: coinvolge gruppi con motivazioni, capacità e geografie operative molto diverse. Analizzare i quattro gruppi mappati rivela pattern significativi per l'attribuzione e la previsione.

Sandworm Team (G0034) è il braccio cyber offensivo legato alla Russia, noto per operazioni distruttive e di spionaggio su larga scala. L'uso di Adminer per esfiltrare dati da database enterprise mostra un approccio pragmatico: piuttosto che sviluppare tool custom per l'accesso database, il gruppo sfrutta un tool di amministrazione PHP open source già presente o facilmente deployabile sulle webshell esistenti. Questo è coerente con la tendenza di Sandworm a privilegiare tool living-off-the-land quando l'obiettivo è la raccolta dati.

Sea Turtle (G1041) condivide con Sandworm l'impiego di Adminer, ma con un focus specifico su MySQL. L'uso del tool per il login remoto al servizio MySQL delle macchine vittima suggerisce un approccio incentrato sulla persistenza tramite accesso web-based ai dati. L'overlap di tooling tra Sea Turtle e Sandworm è un elemento rilevante per la threat intelligence, anche se i due gruppi operano con mandati e target distinti.

FIN6 (G0037) rappresenta la dimensione finanziaria. La raccolta di schemi e account utente da SQL Server non è fine a sé stessa: serve a mappare l'ambiente per il movimento laterale e a identificare dove risiedono i dati monetizzabili (numeri di carte, credenziali di pagamento). Il focus su SQL Server riflette il target tipico di FIN6 — ambienti retail e finanziari dove Microsoft SQL è predominante.

Turla (G0010), gruppo associato alla Russia con focus sullo spionaggio, si distingue per l'uso di un tool .NET custom per la raccolta documenti da database centrali interni. Questo approccio su misura è tipico di Turla, che investe nello sviluppo di strumenti proprietari difficili da rilevare con signature generiche. Il target — database documentali interni — suggerisce operazioni di intelligence gathering a lungo termine.

Le due campagne mappate completano il quadro. Leviathan Australian Intrusions (C0049), condotta tra aprile e settembre 2022, ha visto la raccolta da SQL Server e server BMS in Australia, con focus sull'esfiltrazione di credenziali valide. APT41 DUST (C0040), attiva da gennaio 2023 a giugno 2024 contro target in Europa, Asia e Medio Oriente nei settori shipping, logistica e media, ha impiegato SQLULDR2 per l'estrazione da Oracle — un tool specifico che indica conoscenza approfondita degli ambienti Oracle enterprise.

Il trend emergente è chiaro: l'accesso ai database non è più un'attività accessoria ma un obiettivo primario sia per gruppi di spionaggio che per attori a motivazione finanziaria. La diversificazione dei target — da MySQL a Oracle, da SQL Server a piattaforme SaaS — richiede capacità di detection trasversali.

Framework MITRE ATT&CK v16 — T1213.006, TA0009. Campagne: C0049 (Leviathan Australian Intrusions), C0040 (APT41 DUST). Detection ID: DET0242 (AN0676–AN0680). Tool di detection: Sysmon, auditd, AWS CloudTrail, Nmap. Integrato con conoscenza professionale per tool e procedure operative.