ca
ring z3ro labs
>
Threat Hunting

Threat Hunting: Detecció basada en la prevalença

Borja Merino Febrero
,
__wf_reservad_hereta

Una de les fases en les quals posem més èmfasi després d'acabar els nostres exercicis de Purple Team és la revisió, creació i millores de consultes que ens permeten identificar eficientment aquelles tècniques executades per l'Equip Roig que no han generat cap tipus d'alerta en el corresponent EDR. Aquest cicle de treball ens permet enriquir significativament les capacitats de detecció dels nostres clients. El resultat d'aquest tipus d'exercicis sol ser un conjunt de consultes automàtiques (de vegades eines) que cobreixen aquelles TTPs no identificades per la pròpia lògica de detecció de l'EDR per continuar ampliant l'escut de protecció davant un major nombre d'amenaces.

Generalment, les consultes basades en LFO i prevalença són els recursos que més utilitzem amb alguns clients per detectar anomalies que “escapen” de la línia base coneguda. L'objectiu d'aquest post és explicar precisament aquest segon criteri, prevalença, per ser de gran valor a l'hora d'identificar codi maliciós executat per Threat Actors i Equips Vermells.

MDATP permet enriquir, a través de la FileProfile () funció, la informació relacionada amb un fitxer que ha estat objecte d'una determinada consulta. Aquesta funció permet recuperar, per exemple, la mida del fitxer, si el fitxer és executable, l'estat de la seva signatura, etc. Un dels camps més atractius per identificar anomalies és GlobalPrevalencia que retorna el nombre d'instàncies observades per Microsoft globalment (altres camps, com GlobalFirstSeen i GlobalLastSeen, també són realment valuosos per a la caça). Des de Documentació pròpia de Microsoft, podeu veure diversos exemples d'ús:

DeviceFileEvents | where ActionType == "FileCreated" and Timestamp > ago(1d) | project CreatedOn = Timestamp, FileName, FolderPath, SHA1 | invoke FileProfile("SHA1", 500) | where GlobalPrevalence < 15
Nota: És important tenir en compte que la FileProfile () funció té diverses limitacions, tal com indica la seva documentació: “Les funcions d'enriquiment mostraran informació complementària només quan estiguin disponibles. La disponibilitat d'informació és variada i depèn d'una gran quantitat de factors”

Tot i que l'existència d'un fitxer amb baixa prevalença no vol dir necessàriament que sigui maliciós (fitxers temporals, actualitzacions de programari, etc.), si s'utilitza quirúrgicament per localitzar binaris sospitosos, pot ser de gran valor en la detecció d'amenaces avançades.

Vegem un exemple pràctic. Sabem que, fins al dia d'avui, tècniques basades en càrrega lateral popularitzat per grups com Korplug/Sogu (o el La CIA mateixa) i fins i tot el desenvolupament de connectors per a aplicacions signades de confiança segueixen sent força efectius per aconseguir l'execució de codi i eludir algunes solucions EDR. En un recent exercici d'equip morat, tractant de replicar aquest tipus d'accions, es va desenvolupar un plugin per a Notepad ++ per carregar i executar una balisa CS. El carregador (NppRust.dll), bàsicament, després de carregar i executar determinat codi brossa per retardar-ne l'execució uns segons, llegeix des d'un suposat fitxer de configuració (plugin.cfg) el corresponent stager (xifrat RC4) per recuperar i executar un beacon CS dins l'espai d'adreces Notepad++.

El camp GlobalPrevalencia proporcionat per MDATP és de gran valor contra aquest tipus d'atacs al permetre'ns generar regles de detecció que cerquen periòdicament esdeveniments de creació de processos (DeviceProcesseVents) amb DLL sospitoses sota certs criteris (comunament, moltes d'aquestes consultes tenen diverses excepcions i condicions per reduir falsos positius amb els quals ajustar la cerca a l'ecosistema del client).

Un possible criteri de cerca per a connectors de càrrega lateral o sospitosos és identificar DLL sense signar amb una prevalença baixa que es carreguen en processos signats. La imatge seg�ent mostra una consulta d'aquestes caracter�stiques, ordenant de manera ascendent el camp de la GlobalPrevalance, sobre la telemetria generada per l'implant anteriorment descrit.

Es nota que s'ha executat una DLL (NpRust.dll) amb una prevalença d'1 dins del procés “NotePad++.exe” la GlobalPrevalença del qual és 62817. Si observem la prevalença de la resta dels connectors carregats, es manifesta clarament una anomalia amb la DLL maliciosa.

Les possibilitats amb aquest camp a l'hora de construir consultes són il·limitades; per exemple, podem buscar processos amb una prevalença baixa executats a partir de certs camins, processos amb una prevalença baixa que executin determinats ActionType (“ProcessPrimaryTokenModified”, “queueUserApcremoteApiCall”, “CreateRemoteThreadApiCall”, etc.), processos amb una prevalença baixa que resolen dominis de Slack, Telegram, etc Seguint l'exemple anterior, si incorporem com a criteri processos signats que carreguen DLL sense signar que tenen baixa prevalença i que han creat una connexió exitosa, podem limitar encara més la cerca a DLL malicioses que aprofiten processos legítims.

En el nostre escenari, aquesta consulta retorna el C2 al qual es connecta l'implant, dades que ens permeten identificar nous implants que aprofiten la càrrega lateral (en l'exemple, un binari legítim de hp, discfcsn.exe).

Tot i que els exemples s'han realitzat amb sistemes MDATP, EDR, i solucions SIEM que recullen aquest tipus d'informació en la seva telemètrica, aporten un gran pes a Hunting alhora que limiten els Threat Actors i Red Team els seus camins d'execució (més encara quan tècniques basades en”Intèrpret de comandament i guió” també estan vigilats de prop). Els caçadors, en canvi, haurien de dirigir els seus esforços a polir les consultes basades en la prevalença d'una manera precisa per limitar i reduir al màxim el nombre d'FP.

Referències

Comparteix aquesta publicació

__wf_reservad_hereta
Borja Merino Febrero