Manipolazione dei Dati a Runtime: Runtime Data Manipulation (T1565.003)

La simulazione di T1565.003 in laboratorio richiede di dimostrare che un dato visualizzato dall'utente può differire da quello effettivamente memorizzato. L'approccio più diretto è la manipolazione dei binari applicativi o l'hooking delle funzioni di rendering.

Scenario 1 — Patching di un binario PDF viewer. Il concetto è modificare un viewer PDF affinché alteri il contenuto durante il rendering. In un ambiente lab, puoi usare Ghidra (open source) per analizzare il binario di un lettore PDF leggero, identificare la funzione di rendering testo e iniettare una patch che sostituisca una stringa specifica con un'altra. Il flusso operativo prevede: apertura del binario in Ghidra, localizzazione della funzione tramite ricerca di stringhe note, modifica dell'istruzione di caricamento e riesportazione del binario patchato.

Scenario 2 — API hooking su Windows con Frida. Frida (open source) consente di agganciare funzioni a runtime senza modificare il binario su disco. In un contesto di test puoi iniettarti in un processo e intercettare le chiamate di lettura file o rendering testo.

frida -p <PID_target> -l hook_script.js

Lo script JavaScript caricherà un hook su funzioni come ReadFile o DrawText nelle librerie Windows, alterando il buffer dati prima che raggiunga lo schermo. Questo replica fedelmente ciò che un malware sofisticato farebbe in produzione.

Scenario 3 — Manipolazione LD_PRELOAD su Linux. Puoi creare una shared library malevola che sovrascrive funzioni standard come fopen o fread, facendo sì che quando un'applicazione legge un file specifico, riceva contenuto alterato.

gcc -shared -fPIC -o hook.so hook.c -ldl LD_PRELOAD=./hook.so /usr/bin/applicazione_target

Questo approccio è particolarmente realistico: non altera nulla su disco, non modifica il binario e lascia tracce minime. La libreria intercetta le chiamate libc e restituisce dati manipolati.

Per il reporting, documenta sempre il delta tra il dato reale e quello visualizzato, catturando screenshot dell'interfaccia e dump esadecimali del file sorgente. Questo dimostra al cliente che l'integrità percepita non coincide con l'integrità effettiva, un concetto che nei settori regolamentati ha implicazioni di compliance immediate.

Rilevare la manipolazione a runtime è una delle sfide più complesse per un SOC, perché l'attacco si manifesta nello strato applicativo e spesso non lascia signature di rete evidenti. La strategia vincente combina File Integrity Monitoring, monitoraggio dei processi e validazione crittografica dei binari.

Su Windows, le log source primarie sono Sysmon e il Security Event Log. Configura Sysmon (open source, distribuito da Microsoft Sysinternals) per catturare EventCode 11 (FileCreate) e EventCode 7 (ImageLoaded) sulle directory delle applicazioni business-critical. L'obiettivo è individuare quando un binario applicativo viene sostituito o quando una DLL inattesa viene caricata nel processo di rendering. Crea una baseline degli hash crittografici dei binari legittimi e genera un alert ogni volta che un processo carica un modulo con hash non presente nella whitelist.

Sysmon64.exe -i sysmon-config.xml

La configurazione XML deve includere regole specifiche per le directory monitorate — ad esempio i percorsi di installazione dei software ERP, dei client di messaggistica finanziaria o dei viewer documentali. Un mismatch di hash su un binario in queste directory merita indagine immediata.

Su Linux, il framework auditd è il pilastro. Monitora le syscall open, write e execve sulle directory applicative critiche, cercando scritture non autorizzate su librerie condivise e binari ELF.

auditctl -w /opt/applicazione_critica/bin/ -p wa -k runtime_manip

Questo genera un record audit ogni volta che un file nella directory viene scritto o i suoi attributi cambiano. Integra questa regola con controlli periodici di integrità tramite AIDE (open source) o Wazuh (open source), che possono confrontare automaticamente gli hash correnti con la baseline e generare alert nel SIEM.

Su macOS, il Unified Log cattura eventi relativi alla code signing e al caricamento di framework. Monitora le violazioni di code signing con EventCode associati a Gatekeeper e verifica che le applicazioni che trattano dati sensibili mantengano firme valide. osquery (open source) consente query schedulate per verificare l'integrità dei bundle applicativi.

Per la gestione dei falsi positivi, il tuning è essenziale: gli aggiornamenti software legittimi modificano i binari e generano alert. Integra il processo di patch management con la pipeline di baseline hash — ogni aggiornamento autorizzato deve aggiornare anche la whitelist. Senza questa correlazione, il SOC verrà sommerso da falsi positivi a ogni patch Tuesday.

L'analisi forense di un caso T1565.003 richiede un approccio stratificato: l'artefatto primario è il binario alterato (o la libreria iniettata), ma la timeline deve ricostruire l'intera catena — dall'accesso iniziale alla directory applicativa fino all'ultimo momento in cui il dato manipolato è stato visualizzato da un utente.

Su Windows, parti dall'analisi del filesystem NTFS. I timestamp MFT ($MFT) rivelano quando i binari applicativi sono stati modificati: confronta i timestamp di creazione, modifica e accesso con le date di installazione e aggiornamento note. Usa MFTECmd di Eric Zimmerman (open source) per estrarre i record MFT e identificare anomalie temporali.

MFTECmd.exe -f "C:$MFT" --csv output_dir

Cerca binari nella directory dell'applicazione target con timestamp di modifica successivi all'ultima installazione legittima. Poi verifica gli hash di ogni binario contro quelli pubblicati dal vendor: una discrepanza è prova di manomissione. I log Sysmon, se erano attivi, forniscono la catena causale — quale processo ha scritto il file modificato (EventCode 11), da quale utente e con quale parent process.

Analizza anche il registro eventi di Windows per creazioni di servizi sospette (EventCode 7045 nel System log) e per accessi anomali ai file (EventCode 4663 nel Security log con audit object access abilitato). Il Prefetch può rivelare l'esecuzione di tool non standard nella directory dell'applicazione — file .pf con nomi incongruenti rispetto al software installato.

Su Linux, auditd è la fonte primaria se era configurato. Cerca record di tipo SYSCALL con syscall write o rename sulle directory applicative. In assenza di audit, analizza i timestamp ext4 con debugfs e confronta i metadati inode dei binari sospetti.

debugfs -R "stat <percorso_binario>" /dev/sdX

Verifica anche la variabile d'ambiente LD_PRELOAD nella configurazione del servizio — se un attaccante ha usato questa tecnica, potrebbe aver inserito un riferimento persistente in /etc/ld.so.preload o negli script di avvio del servizio. Ogni libreria referenziata va estratta e analizzata.

Per la correlazione con le campagne note, il caso APT38 è emblematico: il gruppo ha utilizzato DYEPACK.FOX per alterare la visualizzazione di documenti PDF relativi a transazioni SWIFT, rimuovendo le tracce di operazioni fraudolente. In un'indagine su sistemi finanziari, cerca specificamente modifiche ai componenti di rendering PDF e discrepanze tra i log delle transazioni nel database e il contenuto dei documenti generati — il delta tra questi due punti è la prova della manipolazione.

APT38 — La frode finanziaria come missione di stato

APT38 (G0082) è il gruppo che definisce il paradigma operativo di questa tecnica. Associato alla Corea del Nord e specializzato in attacchi al settore finanziario, APT38 ha sviluppato un approccio chirurgico alla manipolazione dei dati a runtime con l'uso di DYEPACK.FOX, un componente progettato specificamente per intercettare e alterare documenti PDF relativi a transazioni SWIFT. Il meccanismo non cancellava le transazioni fraudolente dal database — le nascondeva dalla vista degli operatori, permettendo al denaro di fluire verso conti controllati dal gruppo mentre gli schermi mostravano un quadro regolare.

Questo modus operandi rivela una caratteristica fondamentale: APT38 non improvvisa. La capacità di sviluppare un tool che opera a livello di rendering PDF per un sistema finanziario specifico presuppone mesi di ricognizione, comprensione delle architetture interne, e probabilmente accesso a documentazione riservata o ambienti di test. Il profilo è quello di un attore che investe in operazioni a lungo termine, con team di sviluppo dedicati e obiettivi finanziari quantificabili nell'ordine delle centinaia di milioni di dollari.

Pattern analitici e proiezioni

La T1565.003 è una tecnica ad alto investimento e alto rendimento. Richiede competenze specialistiche che la collocano quasi esclusivamente nel dominio degli attori stato-nazione o dei gruppi criminali con risorse equivalenti. Il settore finanziario resta il target primario, ma il principio è applicabile ovunque le decisioni dipendano da dati visualizzati: sistemi SCADA, piattaforme di trading, dashboard di comando e controllo militare.

Il pattern geografico punta verso attori con motivazione economica diretta — furto di fondi — o strategica — sabotaggio di processi decisionali. La Corea del Nord ha dimostrato entrambe le motivazioni. L'assenza di altri gruppi documentati su questa tecnica non significa assenza di utilizzo: indica piuttosto la difficoltà di rilevamento, poiché la manipolazione a runtime è tra le forme di compromissione più difficili da identificare post-incidente.

Per il monitoraggio proattivo, concentrati su indicatori di compromissione dei sistemi finanziari — in particolare anomalie nei componenti di rendering documentale e discrepanze tra i record transazionali e i documenti di conferma. La convergenza tra accesso privilegiato a sistemi SWIFT e modifiche non autorizzate a binari applicativi dovrebbe essere trattata come indicatore ad altissima priorità.

Framework MITRE ATT&CK v16 — tecnica T1565.003, tattica TA0040, gruppo G0082, mitigazioni M1030 e M1022. Tool di detection: Sysmon, auditd, AIDE, Wazuh, osquery. Integrato con conoscenza professionale per tool e procedure operative.