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

La simulazione di Runtime Data Manipulation in un contesto red team richiede un'infrastruttura di laboratorio isolata e una chiara autorizzazione scritta, dato che si opera su binari di produzione e su processi di business critici. L'obiettivo dell'esercizio non è distruggere dati, ma dimostrare che è possibile alterare ciò che l'utente finale vede senza toccare la sorgente autoritativa.

Su Windows, la catena tipica parte da un accesso privilegiato al sistema target, seguito dalla sostituzione o patching di un binario applicativo (ad esempio un visualizzatore PDF, un client contabile, un'applicazione di reporting). Un approccio di laboratorio consiste nell'usare Frida (open source), framework di dynamic instrumentation che permette di hookare funzioni API a runtime senza modificare il binario su disco. Un comando base è frida -p -l script.js, dove lo script JavaScript intercetta chiamate a funzioni di rendering come TextOutW o funzioni di parsing di formati proprietari.

Per scenari più persistenti si può ricorrere a Microsoft Detours (open source, licenza MIT) o alla libreria MinHook (open source) per implementare API hooking a livello utente. La logica è: identificare la funzione che legge i dati dal database, iniettare una hook che filtri o modifichi i record prima che raggiungano il layer di presentazione.

Su Linux, la tecnica classica è la sostituzione di librerie condivise via LD_PRELOAD. Un file .so custom può reimplementare funzioni come fread o sqlite3_step per alterare i dati restituiti. Il comando LD_PRELOAD=/tmp/evil.so /usr/bin/reporting-app carica la libreria malevola prima delle standard. In alternativa si può patchare direttamente un binario ELF con radare2 (open source) o Ghidra (open source) per modificare la logica di visualizzazione.

Su macOS, l'ostacolo principale è il code signing enforcement: modificare un application bundle invalida la firma e Gatekeeper blocca l'esecuzione. In lab si disabilita SIP e si usa DYLD_INSERT_LIBRARIES in modo analogo a LD_PRELOAD, oppure si opera con osquery (open source) per mappare quali binari maneggiano dati sensibili.

Per la validazione dell'esercizio è utile confrontare l'output dell'applicazione compromessa con una query diretta al database sottostante (ad esempio via sqlcmd o psql), documentando la discrepanza. Questa evidenza è ciò che rende il report red team incisivo per il management: dimostra che i controlli basati sulla sola verifica applicativa sono aggirabili.

La detection di Runtime Data Manipulation è particolarmente sfidante perché l'attività malevola si consuma nello spazio di memoria di processi legittimi, spesso senza traffico di rete anomalo e senza creazione di nuovi processi. La strategia efficace ruota attorno a tre pilastri: integrità dei binari, osservazione del comportamento dei processi e correlazione con anomalie di business.

Su Windows la baseline parte da Sysmon (gratuito) con una configurazione che copra almeno gli Event ID 1 (Process Create), 7 (Image Loaded), 11 (File Create) e 13 (Registry Value Set). L'obiettivo è rilevare quando un'applicazione business-critical carica DLL non firmate o non presenti nella baseline, oppure quando il suo eseguibile principale cambia hash rispetto al golden image. La detection AN1097 suggerisce di correlare WinEventLog:Sysmon e WinEventLog:Security per individuare mismatch di hash sui binari monitorati. Una query Splunk indicativa è index=sysmon EventCode=7 Image="C:\Program Files\ReportingApp\app.exe" | search NOT ImageLoaded IN (baseline_dll_list).

Su Linux (detection AN1098), la fonte primaria è auditd con regole che tracciano syscall open, openat e mmap verso directory applicative sensibili, oltre a ptrace che è indicatore forte di injection. Una regola auditd tipica è -w /opt/business-app/bin -p wa -k app_integrity. Va integrata con controlli periodici di integrità tramite AIDE (open source) o Wazuh (open source) che calcolano hash SHA-256 delle librerie condivise e generano alert su variazioni non pianificate.

Su macOS (detection AN1099), l'Unified Log e osquery permettono di verificare la validità della firma dei bundle applicativi e di individuare l'uso di DYLD_INSERT_LIBRARIES nelle variabili d'ambiente dei processi in esecuzione.

I controlli preventivi allineati a D3FEND includono Executable Allowlisting (WDAC su Windows, SELinux su Linux), Code Signing Verification e File Integrity Monitoring continuo. La segmentazione di rete (M1030) e le restrizioni sui permessi filesystem (M1022) riducono la superficie: applicare icacls per rimuovere permessi di scrittura su directory applicative e monitorare ogni tentativo di modifica con Event ID 4670 (Permissions on an object were changed).

I falsi positivi più comuni derivano da aggiornamenti software legittimi, patch di sicurezza automatiche e caricamento di plugin. La mitigazione passa da una whitelist di processi di update (WSUS, SCCM, Jamf) e dalla correlazione temporale con finestre di change management. Un alert isolato su hash mismatch fuori finestra di patching, associato a un processo che apre connessioni verso database di produzione, merita triage immediato.

L'analisi forense di Runtime Data Manipulation è un esercizio di ricostruzione delicato: l'attività malevola può non lasciare tracce persistenti su disco se implementata puramente in memoria, e la vittima primaria — l'utente che ha preso decisioni sulla base di dati falsati — spesso non si accorge di nulla per settimane o mesi. La timeline forense deve partire dal momento in cui emerge la discrepanza tra dato sorgente e dato visualizzato.

Su Windows gli artefatti chiave da raccogliere sono: Prefetch (C:\Windows\Prefetch) per confermare l'esecuzione dei binari applicativi sospetti e le loro tempistiche; Amcache.hve (C:\Windows\AppCompat\Programs\Amcache.hve) che conserva hash SHA-1 dei PE eseguiti, permettendo di confrontarli con la baseline vendor; ShimCache per evidenze aggiuntive di esecuzione; e le Windows Event Logs in Security.evtx e Application.evtx per correlare login degli operatori con l'accesso ai dati manipolati. Se disponibile un dump di memoria, Volatility 3 (open source) con i plugin windows.malfind, windows.dlllist e windows.modules permette di identificare DLL iniettate o regioni di memoria eseguibile non mappate a file su disco — pattern tipico di API hooking.

Su Linux l'analista deve acquisire: log auditd (/var/log/audit/audit.log), contenuto di /proc//maps per processi ancora attivi (mostra librerie caricate incluse eventuali .so iniettate via LD_PRELOAD), variabili d'ambiente in /proc//environ, e timestamp delle librerie in /usr/lib e /opt. Il comando find /opt/app -newer /tmp/reference -type f aiuta a isolare file modificati dopo una data di riferimento. Per l'analisi di binari ELF sospetti, radare2 e Ghidra (open source) consentono di identificare sezioni patchate o trampoline di hook.

Su macOS l'Unified Log (log show --predicate con filtri sul processo target) e l'analisi di ~/Library/Preferences e degli application bundle in /Applications con verifica di codesign --verify --deep --strict rivelano tampering sui componenti firmati.

La timeline dovrebbe correlare tre assi: momento della compromissione iniziale (spesso mesi prima), finestra di manipolazione attiva dei dati, e istante di scoperta. Nel caso APT38/DYEPACK.FOX documentato da MITRE, l'analisi forense richiede il confronto tra i record SWIFT autoritativi (log di rete SWIFT, database backend) e i PDF visualizzati dagli operatori: la discrepanza è l'unica evidenza diretta della manipolazione. Preservare copie forensi dei report generati durante il periodo sospetto è essenziale per la ricostruzione dell'impatto finanziario e per eventuale azione legale.

Il panorama degli attori che impiegano Runtime Data Manipulation è ristretto e altamente qualificato. La tecnica richiede reverse engineering di applicazioni verticali, sviluppo di impianti custom e persistenza prolungata nell'ambiente vittima: caratteristiche che la rendono appannaggio di gruppi state-sponsored con obiettivi strategici di frode o disinformazione, più che di attori commodity.

Il profilo dominante nei dati MITRE è APT38, cluster attribuito alla Repubblica Popolare Democratica di Corea e operativamente collegato al più ampio ecosistema Lazarus. APT38 si distingue dagli altri sottogruppi nordcoreani per la focalizzazione esclusiva su obiettivi finanziari di grande scala, in particolare istituti bancari collegati alla rete SWIFT. L'impianto DYEPACK.FOX documentato è stato progettato specificamente per manipolare la visualizzazione di documenti PDF contenenti conferme di transazioni SWIFT, rimuovendo dalle schermate degli operatori le evidenze dei bonifici fraudolenti già eseguiti. Questa capacità ha permesso al gruppo di prolungare il tempo tra l'esecuzione della frode e la scoperta, massimizzando la finestra utile per il riciclaggio dei fondi attraverso conti in giurisdizioni cooperative.

Il pattern operativo di APT38 evidenzia diversi elementi ricorrenti utili per l'attribuzione. In primo luogo, una fase di ricognizione interna prolungata — spesso mesi — durante la quale il gruppo studia i workflow bancari, identifica gli operatori con accesso ai sistemi SWIFT e mappa i formati di reporting utilizzati. In secondo luogo, l'uso di malware modulare custom con componenti dedicati a ciascuna fase: accesso iniziale, movimento laterale, esecuzione della transazione fraudolenta, e manipolazione delle prove. DYEPACK.FOX appartiene a quest'ultima categoria e non è riutilizzabile in contesti diversi da quello per cui è stato sviluppato.

Dal punto di vista geografico, le vittime storiche di APT38 comprendono istituti in Bangladesh, Vietnam, Ecuador, Filippine, Taiwan e diversi paesi africani, con importi contestati che superano complessivamente il miliardo di dollari. La selezione dei target privilegia banche con maturità cybersecurity intermedia connesse a SWIFT, dove la superficie d'attacco è significativa ma le capacità di detection limitate.

Il trend evolutivo suggerisce che tecniche di runtime manipulation possano essere adottate anche da altri attori con obiettivi diversi dalla frode diretta: sabotaggio di sistemi ERP per alterare bilanci, manipolazione di dashboard SCADA in contesti industriali, o falsificazione di risultati in sistemi di conteggio elettorale. La difesa richiede quindi un approccio che vada oltre il perimetro finanziario, applicando controlli di integrità applicativa a qualunque sistema il cui output guidi decisioni ad alto impatto. La combinazione di M1022 (restrizione permessi) e M1030 (segmentazione di rete) resta il fondamento preventivo, ma senza detection comportamentale continua l'attacco può passare inosservato per l'intero ciclo operativo.

MITRE ATT&CK T1565.003 (Runtime Data Manipulation), tattica TA0040 (Impact). Gruppo G0082 (APT38) con impianto DYEPACK.FOX. Mitigazioni M1022 (Restrict File and Directory Permissions) e M1030 (Network Segmentation). Detection DET0391 con analytic AN1097 (Windows), AN1098 (Linux), AN1099 (macOS). Framework difensivo MITRE D3FEND per Executable Allowlisting e File Integrity Monitoring. Parti operative su Sysmon, auditd, Volatility, Frida, radare2, Ghidra, Wazuh, AIDE e osquery derivano da conoscenza professionale su tool open source consolidati nella pratica DFIR.