A caccia di prove di caricamento laterale di DLL con PowerShell e Sysmon
Recentemente, X-Force Red ha lanciato uno strumento chiamato Windows Feature Hunter, che identifica i target per il caricamento laterale di librerie a collegamento dinamico (DLL) su un sistema Windows utilizzando Frida. Per fornire una prospettiva difensiva di contromisure per il caricamento laterale di DLL, X-Force Incident Response ha rilasciato SideLoaderHunter, uno script di profilazione di sistema, e una configurazione Sysmon progettata per identificare le prove di caricamento laterale nei sistemi Windows. Questo post parlerà del motivo per cui IBM® X-Force ritiene che lo strumento sia necessario, ne descriverà le funzioni e analizzerà alcuni casi d'uso.
In Microsoft Windows, i programmi possono definire quali librerie vengono caricate nel tempo di esecuzione specificando un percorso completo o utilizzando un altro meccanismo come un manifesto. Un manifesto di programma è un file esterno o una risorsa incorporata all'interno di un'applicazione utilizzata per gestire i nomi e le versioni degli assembly affiancati condivisi su cui l'applicazione dovrebbe caricarsi all'esecuzione. Un manifesto di programma può includere reindirizzamenti DLL, nomi di file o percorsi completi. Se un manifesto si riferisce solo a un nome di file di libreria, è considerato un riferimento debole ed è vulnerabile a un attacco di caricamento laterale di DLL.
Se viene fatto un riferimento debole a una libreria, Windows tenta di localizzare la DLL tramite un ordine di ricerca predefinito. Il primo posti in cui Windows cercherà è la directory da cui è stata caricata l'applicazione.
Un attacco di caricamento laterale di DLL è una tecnica avversaria che mira a sfruttare i riferimenti deboli alle librerie e l'ordine di ricerca predefinito di Windows posizionando un file DLL malevolo che si spaccia per DLL legittima su un sistema, che verrà automaticamente caricato da un programma legittimo.
Per ulteriori informazioni sul caricamento laterale di DLL, fai riferimento alla tecnica MITRE ATT&CK T1574.002.
Newsletter di settore
Le ultime notizie nel campo della tecnologia, supportate dalle analisi degli esperti
Resta al passo con le tendenze più importanti e interessanti del settore relative ad AI, automazione, dati e oltre con la newsletter Think. Leggi l' Informativa sulla privacy IBM.
L'abbonamento sarà fornito in lingua inglese. Troverai un link per annullare l'iscrizione in tutte le newsletter. Puoi gestire i tuoi abbonamenti o annullarli qui. Per ulteriori informazioni, consulta l'Informativa sulla privacy IBM.
Il caricamento laterale di DLL non è una tecnica nuova, poiché la vulnerabilità del dirottamento dell'ordine di ricerca in Windows esiste fin da Windows XP. X-Force ha osservato il caricamento laterale di DLL utilizzato dal Trojan bancario Metamorfo, che rilascia file MSI dannosi che estraggono un binario firmato e una DLL dannosa per eseguire un caricatore malware di secondo stadio. A causa dell'ordine di ricerca predefinito integrato in Windows, il binario firmato caricherà la DLL dannosa e continuerà il flusso di esecuzione malevola.
Sebbene non sia la tecnica più comune utilizzata dagli attori delle minacce, il caricamento laterale di DLL viene sempre più utilizzato dagli operatori di ransomware, che hanno utilizzato il caricamento laterale di DLL per eseguire il payload ransomware ed evitare il rilevamento da parte dei prodotti di sicurezza.
Ad esempio, l'operatore di ransomware REvil ha sfruttato una vulnerabilità per il caricamento laterale di DLL all'interno di un eseguibile di Windows Defender (MsMpEng.exe) per caricare una DLL dannosa denominata mpsvc.dll contenente il payload del ransomware.
X-Force non ha osservato molti attori delle minacce o malware che sovrascrivono binari o moduli esistenti su un sistema per eseguire un attacco di caricamento laterale di DLL, perché ciò potrebbe causare il crash del sistema o creare errori che potrebbero portare al rilevamento.
Invece, gli attori delle minacce o i malware che hanno utilizzato il caricamento laterale di DLL si affidano in genere a due comportamenti prima di eseguire un attacco:
- Installano un eseguibile firmato in una directory di destinazione insieme alla DLL dannosa.
- Spostano un eseguibile Windows da System32 o SysWow64 sulla macchina di destinazione a una directory non standard e piantano la DLL dannosa nella stessa cartella.
Il primo caso d'uso è una metodologia di rilevamento abbastanza semplice. Sebbene il binario possa essere firmato, la sua esecuzione sarebbe comunque considerata un'anomalia all'interno di un set di dati di esecuzione di un programma. Nel precedente esempio di Metamorfo, il malware ha installato l'utility di dump di memoria di Avast AVDump32.exe, rinominata come jesus.exe, che ha caricato lateralmente una DLL dannosa denominata dbghelp.dll.
In questo esempio, l'identificazione di jesus.exe è stata realizzata eseguendo un'analisi di frequenza sui nomi di file registrati all'interno di un set di dati di esecuzione del programma.
Figura 1: Analisi della frequenza sul nome binario nel set di dati di esecuzione del programma
Il secondo caso d'uso può essere più difficile da rilevare poiché spesso utilizza applicazioni Windows standard e affidabili per eseguire la DLL dannosa, il che aiuta l'attività dannosa a integrarsi con i dati di esecuzione del programma non dannosi. Ci sono opportunità di rilevamento tramite l'analisi di frequenza del percorso completo del binario all'interno di un set di dati di esecuzione del programma; ma senza alcun tipo di filtraggio, quest'analisi è troppo inefficiente.
Invece, il set di dati di esecuzione del programma può essere filtrato solo per includere nomi di eseguibili che risiedono di default in System32 o SysWow64. In questo caso, l'analisi verrebbe eseguita su tutti i dati di esecuzione del programma associati agli eseguibili System32 o SysWow64 dove il percorso completo del binario non corrisponde al valore predefinito.
Per eseguire questa analisi, crea una tabella di ricerca degli eseguibili predefiniti System32 e SysWow64 dai sistemi Windows, che fungerà da set di dati di controllo, rispetto al quale i difensori possono identificare le anomalie.
Il seguente script di PowerShell enumererà gli eseguibili in System32 e SysWow64 ed esporterà i risultati in un file CSV.
L'uso di sysbins.csv come gruppo di controllo consente l'identificazione dell'esecuzione del programma e fornisce prove delle applicazioni Windows al di fuori delle loro directory System32 o SysWOW64 predefinite.
| $SysBinList = Get-ChildItem $env:SystemRoot\system32\ ,$env:SystemRoot\syswow64\ -Recurse -ErrorAction SilentlyContinue | Where-Object {($_.Extension -like “.exe”)} -ErrorAction SilentlyContinue | Select Name;$SysBinLobj = $SysBinList.Name | select -Unique | Select-Object @{Name=’Name’; Expression={$_}};$SysBinLobj | export-csv sysbins.csv -NoTypeInformation |
Figura 2: Analisi di frequenza sul percorso completo dei binari System32
È importante notare che gli attori delle minacce possono eludere il rilevamento usando la corrispondenza dei nomi file rinominando l'eseguibile binario, poiché la tecnica di caricamento laterale rimarrà valida indipendentemente dal nome dell'eseguibile.
Figura 3: Side-loadside-loading mspaint.exe (rinominato notmspaint.exe) con msftedit.dll
Un modo per rilevare gli eseguibili rinominati è attraverso ulteriori profilazioni dei valori hash degli eseguibili System32 e SysWow64 su macchine Windows o raccogliendo il nome interno dei file eseguibili dai sistemi di destinazione. Alcune soluzioni di monitoraggio dell'esecuzione dei processi come Sysmon catturano il nome interno di un eseguibile all'esecuzione. Inoltre, PowerShell ha la funzionalità di enumerare il nome del file originale di un eseguibile dopo che è stato rinominato.
Figura 4: Elenco con l'attributo del nome file originale in PowerShell
Lo script seguente elencherà un elenco di hash eseguibili nelle directory System32 e SysWow64, che possono anche essere utilizzati come set di dati di controllo per identificare gli eseguibili standard di Windows in posizioni non standard.
$binarray=@()$SysBinList = Get-ChildItem $env:SystemRoot\system32\,$env:SystemRoot foreach($bin in $SysBinList) { $binhash = Get-FileHash $bin.FullName -Algorithm SHA1 $binobject = New-Object psobject $binobject | Add-Member -MemberType NoteProperty -Name “Name” -Value $bin.Name $binobject | Add-Member -MemberType NoteProperty -Name “Hash” -Value $binhash.Hash $binarray += $binobject } $binarray | export-csv sysbinhash.csv -NoTypeInformation |
Figura 5: script PowerShell per raccogliere gli hash dei file
Tuttavia, i rilevamenti sopra menzionati sono più efficaci quando ci sono dati centralizzati sull'esecuzione dei processi e la capacità di stabilire basi di attività nel tempo all'interno di un ambiente. È molto raro durante un'indagine.
Per superare questa sfida, X-Force utilizza delle utility di raccolta dati per raccogliere metadati dagli endpoint su larga scala. Una di queste utility è SideLoadHunter, che profila l'endpoint per le DLL e gli eseguibili all'interno dei profili utente, System32 e SysWow64. Una volta che gli eseguibili e le DLL sono stati profilati, X-Force esegue un'analisi comparativa per identificare eventuali prove di caricamento laterale di DLL attraverso i nomi dei file, i valori hash e i nomi interni. Inoltre, gli artefatti di esecuzione del programma vengono analizzati per trovare prove di eseguibili caricati lateralmente che non esistono più sul disco. Questo strumento è stato trasferito su PowerShell ed è disponibile per il download qui.
Le funzioni principali di SideLoadHunter sono:
- Get-SideLoadDetect: funzione di analisi comparativa progettata per identificare le situazioni in cui un eseguibile System32/SysWow64 si trova in una directory userland insieme a una DLL che corrisponde al nome di una DLL System32/SysWow64 ma non è firmata da Microsoft.
- Get-SusShimcache: per fornire alcuni rilevamenti per gli eseguibili caricati lateralmente che non si trovano più sul disco, SusShimcache analizzerà le voci ShimCache per gli eseguibili System32 e SysWow64 eseguiti da una posizione non standard.
- Get-SusExecs e Get-SusDLLs: crea il profilo di un sistema per individuare i file eseguibili System32 e SysWow64 e i file DLL che non esistono nella loro posizione predefinita.
Figura 6: Esecuzione di Side-Loadhunter.ps1
Attraverso la continua ricerca di file eseguibili vulnerabili al caricamento laterale sui sistemi Windows, X-Force ha identificato un elenco di nomi eseguibili e le DLL associate che possono essere caricate lateralmente.
Un elenco completo dei bersagli del caricamento laterale è disponibile qui.
Per assistere nel rilevamento in tempo reale di questi bersagli del caricamento laterale, X-Force ha migrato l'elenco di caricamenti noti in una configurazione Sysmon volta a registrare i carichi dei moduli per gli eseguibili e le DLL associati.
La configurazione di Sysmon può essere trovata qui.
Figura 7: Evento Sysmon da Side-Loadhunter.xml
Sebbene, comunemente, malware e avversari prendano di mira gli eseguibili nelle directory System32 e SysWow64 per il caricamento laterale, la possibilità di caricare lateralmente una DLL in un eseguibile non è limitata a tali directory. Ad esempio, attraverso sforzi collaborativi tra X-Force Incident Response e X-Force Red, l'eseguibile OneDriveStandaloneUpdater.exe, che si trova di default all'interno di %userprofile%\appdata\local\Microsoft\OneDrive sui sistemi Windows 10, può essere installato via WofUtil.dll, che per impostazione predefinita risiede in %windir%\system32\.
Figura 8: Caricamento laterale di OneDriveStandaloneUpdater.exe con WofUtil.dll
X-Force sta attualmente conducendo ulteriori ricerche per creare un elenco più esaustivo dei file eseguibili e delle DLL che possono essere bersaglio per il caricamento laterale, quindi restate sintonizzati per futuri aggiornamenti.