Risoluzione Dinamica API: Dynamic API Resolution (T1027.007)
La tecnica T1027.007 - Dynamic API Resolution rappresenta una delle strategie di offuscamento più diffuse nel malware moderno. Invece di dichiarare staticamente le funzioni Windows utilizzate — lasciando tracce leggibili nell'Import Address Table (IAT) e come stringhe nel binario — l'attaccante risolve i puntatori alle API a runtime, sfruttando tipicamente LoadLibrary() e GetProcAddress() con nomi calcolati da hash o stringhe cifrate.
Questa tecnica ricade nella tattica TA0005 (Defense Evasion) e ha impatto diretto sulle fasi di analisi statica e reverse engineering: un binario che espone solo kernel32.dll con poche funzioni base risulta poco sospetto ai tool di triage automatizzato, mentre in realtà nasconde capacità di iniezione, keylogging o comunicazione C2. Le tecniche di calcolo dell'hash spaziano dal semplice DJB2 modificato (usato da TONESHELL) a routine custom con seed arbitrari come il 131313 di SplatDropper.
I dati MITRE ATT&CK registrano 2 gruppi APT e 13 famiglie di malware che implementano questa tecnica, con una forte concentrazione tra loader, stealer e framework offensivi commerciali come Brute Ratel C4. La sua diffusione trasversale — da ransomware come AvosLocker a strumenti di APT statali — la rende un pattern comportamentale ricorrente che i difensori devono trattare come indicatore forte anziché come curiosità tecnica.
Simulare Dynamic API Resolution in laboratorio è un esercizio didattico fondamentale per comprendere cosa vedono (e non vedono) i tool difensivi. Il pattern minimo consiste nel calcolare l'hash del nome della funzione target, iterare sulla Export Directory della DLL caricata in memoria, confrontare gli hash e recuperare l'indirizzo della funzione senza mai referenziarla come stringa.
Un red teamer può partire da progetti didattici pubblici come MalDevAcademy samples (open source) o dal noto HellsGate/HalosGate (open source su GitHub) per il direct syscall, che estende il concetto oltre le API user-mode. Per prototipazione rapida in C, il flusso tipico è: ottenere il PEB via gs:[0x60] (x64), enumerare InLoadOrderModuleList, individuare ntdll.dll o kernel32.dll, parsare l'header PE e la Export Address Table, calcolare l'hash di ogni nome esportato e confrontarlo con l'hash precomputato della funzione desiderata.
Per la generazione degli hash a compile-time si usano macro C++ constexpr o script Python di supporto. Un algoritmo DJB2 standard produce hash a 32 bit sufficienti per evitare collisioni nelle librerie comuni; molti loader in-the-wild aggiungono un XOR con seed per differenziarsi (il 131313 di SplatDropper ne è un esempio didattico da replicare).
Sul fronte tooling, per l'analisi comparata post-build sono utili:
- PE-bear (open source) e CFF Explorer (gratuito) per ispezionare l'IAT del payload compilato e verificare che le API sensibili non compaiano
- Detect It Easy (DIE) (open source) per misurare l'entropia delle sezioni contenenti tabelle di hash
- x64dbg (open source) con lo script ScyllaHide per il debug dinamico e il dump della IAT ricostruita a runtime
- api-monitor-v2 (gratuito) per intercettare le chiamate a
GetProcAddressdurante la fase di risoluzione
Un red team maturo integra il pattern in un loader che combina la risoluzione dinamica con AES o RC4 sui blob di hash, così da rendere inefficace anche una ricerca YARA su costanti note. Framework come Brute Ratel C4 (a pagamento) e Cobalt Strike (a pagamento) tramite BOF (Beacon Object Files) offrono già primitive di dynamic resolution pronte, mentre per esercizi OSS il progetto Nim-Loader e Freeze (open source) su GitHub mostrano implementazioni complete in Nim e Go.
Durante gli engagement, documentare quale porzione della catena viene intercettata dall'EDR è essenziale: un'API risolta dinamicamente ma poi chiamata normalmente resta visibile in ETW Threat Intelligence Provider.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo