Manipolazione Dati Archiviati: Stored Data Manipulation (T1565.001)

In un ingaggio red team, la simulazione di Stored Data Manipulation richiede un approccio chirurgico che parte sempre da una fase di enumerazione del target dati. Su Windows, dopo aver ottenuto credenziali privilegiate, l'operatore mappa i file server con net share e identifica database o repository documentali attraverso query mirate. Per manipolare record SQL Server si può usare sqlcmd (incluso in SQL Server Command Line Utilities, gratuito):

sqlcmd -S SERVER -E -Q "UPDATE Transactions SET Amount=0 WHERE ID=12345"

Su istanze MySQL/MariaDB in ambienti Linux, dopo aver ottenuto credenziali dal file ~/.my.cnf o da configurazioni applicative, l'approccio simulativo passa per il client mysql con comandi UPDATE/DELETE mirati. Per emulare il pattern DYEPACK in laboratorio, si sviluppa uno script che intercetta transazioni e riscrive record dopo la conferma dell'operatore legittimo — l'obiettivo è dimostrare che il controllo di integrità applicativo non rileva la modifica.

Per i file Office, la manipolazione avviene via COM automation con PowerShell oppure tramite librerie come openpyxl (open source) per XLSX e python-docx (open source) per DOCX. Un pattern realistico modifica celle di report finanziari mantenendo intatti hash di sezioni non critiche:

from openpyxl import load_workbook wb = load_workbook('report.xlsx') wb['Sheet1']['B10'] = 999999 wb.save('report.xlsx')

Su macOS, i file plist di configurazione applicativa si modificano con defaults write oppure plutil -replace per alterare parametri persistenti. Per email archiviate, i file PST/OST su Windows possono essere manipolati con librerie come libpff (open source), mentre su Linux i mail spool in /var/mail/ sono file di testo modificabili direttamente.

Un pattern avanzato — ispirato al comportamento di SUNSPOT — consiste nel sostituire file sorgente durante build automatizzate: si crea un backup con estensione diversa, si scrive la versione modificata, e si effettua la sostituzione atomica con MoveFileEx (Win32 API). In laboratorio si può emulare con un semplice servizio che monitora FileSystemWatcher e sostituisce file al momento giusto.

Per occultare le tracce sul filesystem, tecniche ispirate a MultiLayer Wiper manipolano MFT su NTFS: strumenti come FTK Imager (gratuito) permettono di verificare in lab il risultato delle manipolazioni sui metadati. La regola d'oro è documentare ogni modifica in un log operativo per il rollback al termine dell'esercizio.

La detection di Stored Data Manipulation è tra le più complesse per un SOC perché l'attività si mimetizza tra operazioni legittime. La strategia efficace combina baseline comportamentali, file integrity monitoring e correlazione temporale con altri indicatori di compromissione.

Su Windows, la fonte primaria è Sysmon con configurazione orientata a EventID 11 (FileCreate), EventID 23 (FileDelete) e EventID 2 (FileCreateTime) mirati su directory sensibili come repository database, share documentali e archivi email. La regola base filtra le operazioni su percorsi come *C:\ProgramData*, share di file server e cartelle applicative, escludendo i processi legittimi (SQL Server, Exchange, applicativi ERP). Un alert ad alto valore correla EventID 4663 (Security log, richiede audit SACL abilitato) con processi non presenti in una whitelist di AuthorizedProcesses, entro finestre temporali brevi che indicano attività batch anomala.

Su Linux, auditd è lo strumento cardine. Una regola tipo:

-w /var/lib/mysql/ -p wa -k db_manipulation -w /var/mail/ -p wa -k mail_manipulation

genera eventi SYSCALL con contesto processo, UID e comando. La correlazione va fatta escludendo i binari legittimi (mysqld, postfix) e allertando quando bash, python o perl toccano direttamente file di dati strutturati. Su macOS, gli Unified Logs filtrati con log stream --predicate su subsystem di filesystem, combinati con osquery (open source) e query sulla tabella file_events, offrono visibilità comparabile.

Il File Integrity Monitoring resta cardine: Wazuh (open source), OSSEC (open source) o Tripwire (freemium) permettono di stabilire baseline crittografiche su file critici e allertare su ogni modifica. La configurazione va calibrata con FileIntegrityBaseline costruita durante finestre di quiete e aggiornata dopo change autorizzati.

Dal punto di vista D3FEND, le contromisure Detect rilevanti includono File Access Pattern Analysis e Database Query String Analysis: monitorare pattern di query DML massive (UPDATE/DELETE con WHERE poco selettivi) su database transazionali è un indicatore forte, integrabile in SIEM tramite audit log nativi (SQL Server Extended Events, MySQL general_log, PostgreSQL pgaudit).

I falsi positivi principali derivano da job batch schedulati, migrazioni dati e attività di manutenzione DBA fuori orario. La tuning strategy prevede una whitelist di service account, finestre temporali di manutenzione documentate e soglie basate sul volume di record modificati per singola sessione. Un alert su UPDATE che modifica oltre 10.000 record in transazioni finanziarie è raramente un falso positivo se non pre-annunciato.

L'analisi forense della manipolazione di dati archiviati richiede la ricostruzione di una timeline che intrecci artefatti filesystem, log applicativi e stato dei backup. Il primo passo è preservare l'evidenza secondo l'ordine di volatilità e acquisire immagini bit-a-bit con FTK Imager (gratuito) o dd prima di qualsiasi analisi.

Su Windows, la Master File Table (MFT) è la fonte primaria per ricostruire creazioni, modifiche e cancellazioni. Strumenti come MFTECmd di Eric Zimmerman (open source) parsificano la MFT estraendo timestamp $STANDARD_INFORMATION e $FILE_NAME: la discrepanza tra i due — pattern noto come timestomping — è un indicatore classico usato da malware come MultiLayer Wiper per ostacolare il recovery. Il USN Journal, analizzabile con MFTECmd stesso, conserva la sequenza di operazioni recenti sul volume e permette di identificare pattern di rename atomici tipici di SUNSPOT (backup con .bk, scrittura .tmp, MoveFileEx verso .cs).

Per i database SQL Server, i transaction log (file .ldf) contengono la storia delle modifiche e possono essere analizzati con fn_dblog o con strumenti commerciali come ApexSQL Log (a pagamento). Su MySQL/MariaDB il binary log (mysql-bin.xxxxxx) letto con mysqlbinlog espone ogni UPDATE/DELETE con timestamp e user. Per PostgreSQL, i WAL analizzati con pg_waldump forniscono equivalente visibilità.

Su Linux, gli artefatti chiave sono i log auditd (/var/log/audit/audit.log), i log applicativi in /var/log/ e gli inode conservati nel journal ext4. Il tool debugfs permette in alcuni scenari di recuperare inode di file cancellati, mentre extundelete (open source) tenta il recovery di file su ext3/ext4. Per XFS, xfs_undelete offre funzionalità simili con limiti maggiori.

Su macOS, gli FSEvents (in /.fseventsd/) conservano una storia delle modifiche a livello filesystem analizzabile con FSEventsParser (open source), mentre gli Unified Logs archiviati (log collect) forniscono contesto processo.

Dal punto di vista D3FEND, gli artefatti digitali rilevanti sono File, Database Record, Process e User Account. La timeline deve correlare le modifiche ai dati con logon events (EventID 4624/4625 su Windows, wtmp/btmp su Linux) per attribuire l'azione a una sessione utente specifica. Per il caso DYEPACK/APT38, la ricostruzione forense in ambito SWIFT ha richiesto correlazione tra log MQ, database transazionali e attività filesystem per identificare i record manipolati e ricostruire gli importi originali. Il confronto con backup offline immutabili resta lo strumento definitivo per identificare cosa è stato alterato: senza una copia di riferimento, la manipolazione sottile può essere impossibile da provare.

Il panorama delle minacce che sfruttano Stored Data Manipulation è dominato da attori altamente specializzati con obiettivi finanziari o di destabilizzazione operativa, non da commodity malware. La tecnica richiede investimento significativo in reconnaissance e conoscenza applicativa specifica del target.

APT38 rappresenta il caso di studio più documentato. Sottogruppo dell'ecosistema Lazarus attribuito alla Corea del Nord, APT38 è specializzato in operazioni cyber-finanziarie contro istituzioni bancarie e ha sviluppato DYEPACK come componente dedicato alla manipolazione dei record nei database SWIFT. Il modus operandi coinvolge una lunga fase di persistenza nella rete bancaria, mappatura dei sistemi di messaggistica finanziaria, e infine manipolazione dei database transazionali per alterare importi e destinatari, cancellando o modificando i record di conferma per ritardare la rilevazione della frode. L'attribuzione ad APT38 è supportata da overlap infrastrutturali e tooling con altre operazioni Lazarus, ma la specializzazione verso il settore bancario e SWIFT lo distingue nettamente.

Sul fronte del tool overlap, SUNSPOT rappresenta un pattern completamente diverso: non un tool di manipolazione di dati di business, ma un impianto di supply chain che manipola file sorgente durante la build di SolarWinds Orion per iniettare SUNBURST. Il pattern operativo — copia del sorgente originale con estensione .bk, scrittura del payload con estensione .tmp, rinomina atomica con MoveFileEx verso estensione .cs — dimostra come la manipolazione di dati archiviati possa essere strumento di attacchi supply chain di livello statale, con impatto su migliaia di organizzazioni downstream. L'attribuzione è verso attori russi legati al servizio di intelligence estero.

MultiLayer Wiper occupa uno spazio ibrido: pur essendo classificato come wiper, la sua caratteristica distintiva di manipolare i metadati dei file cancellati per ostacolare recovery lo colloca anche nel dominio della manipolazione dati. Questo pattern anti-forensics è tipico di operazioni distruttive dove l'attaccante vuole massimizzare il danno impedendo il ripristino.

I pattern geografici emergenti mostrano tre cluster distinti: attori nordcoreani focalizzati su frode finanziaria via manipolazione database (APT38), attori russi orientati a supply chain e destabilizzazione (SUNSPOT e famiglie wiper), e attori mediorientali associati a operazioni distruttive con componenti anti-forensics.

Il trend prospettico vede la manipolazione di dati archiviati come componente crescente di attacchi a settori critici: healthcare (manipolazione cartelle cliniche), utilities (dati di misurazione), finance (transazioni). L'adozione di storage immutabile (WORM, S3 Object Lock) e di blockchain per audit trail rappresenta la risposta difensiva più solida, forzando gli attaccanti a colpire anche l'infrastruttura di backup — pattern già osservato in alcuni ransomware moderni.

MITRE ATT&CK T1565.001 (Stored Data Manipulation), tattica TA0040. Gruppi: G0082 (APT38). Software: S0562 (SUNSPOT), S1135 (MultiLayer Wiper). Mitigazioni: M1022, M1029, M1041. Detection: DET0193 con analytics AN0555-AN0557. Framework MITRE D3FEND per mapping contromisure. Il documento integra conoscenza professionale verificata su tool forensi e di detection (Sysmon, auditd, Wazuh, MFTECmd, FTK Imager, osquery) e sintassi di comandi database standard, tutti con documentazione pubblica ufficiale.