Hunting de Living-off-the-Land Binaries en Windows con KQL

Un atacante competente no necesita dejar caer un binario firmado por Microsoft en el disco de la victima: usa lo que ya esta ahi. Rundll32, mshta, certutil, bitsadmin y regsvr32 son herramientas legitimas que Windows carga firmadas por la propia Microsoft, lo que hace que muchos EDR traten sus ejecuciones como ruido. El equipo Basilisk paso los ultimos seis meses analizando 47 incidentes en clientes hispanoamericanos y en 31 de ellos habia al menos un LOLBin en la kill chain. Este post entrega las consultas KQL que usamos en Microsoft Defender for Endpoint y Sentinel para convertir esas ejecuciones en detecciones accionables sin ahogar al SOC en falsos positivos.

Antes de escribir una regla hay que entender el baseline del entorno. Lanzamos un hunt amplio sobre DeviceProcessEvents agrupando por FileName y contando ejecuciones en 30 dias por host, identificando lo normal en esa flota. En un cliente retail con 8.200 endpoints, mshta.exe aparecia solo en 0,4% de las maquinas, todas de marketing corriendo un reporte legado. Esto significa que cualquier ejecucion de mshta fuera de ese grupo merece una alerta P2. Este enfoque de rareza estadistica es la base del hunting moderno y dialoga con lo que describimos en Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion, donde mostramos el paso del indicador crudo a regla Sigma versionada en Git.

La consulta base que recomendamos para rundll32 con linea de comando sospechosa es: DeviceProcessEvents | where FileName =~ 'rundll32.exe' | where ProcessCommandLine has_any ('javascript:', 'shell32.dll,Control_RunDLL', 'mshtml,RunHTMLApplication', '.cpl,', 'url.dll,OpenURL') | where InitiatingProcessFileName !in~ ('explorer.exe', 'svchost.exe') | project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName. En pruebas contra la tecnica T1218.011 de MITRE ATT&CK detecto 9 de 10 ejecuciones del beacon de Cobalt Strike en modo SMB pivot. El ajuste fino llega excluyendo procesos padre legitimos por departamento, algo que documentamos con detalle en Adversary Emulation con Caldera y MITRE ATT&CK en Laboratorio Corporativo.

Certutil merece capitulo propio. Es la navaja suiza del atacante porque descarga archivos (-urlcache), decodifica base64 (-decode) y genera hashes. Nuestra consulta cazadora es: DeviceProcessEvents | where FileName =~ 'certutil.exe' | where ProcessCommandLine has_any ('-urlcache', '-decode', '-decodehex', '-ping', 'http://', 'https://') | where ProcessCommandLine !contains 'CertificateServices' | extend Stage = case(ProcessCommandLine has '-decode', 'staging', ProcessCommandLine has 'http', 'download', 'recon'). En 2025 vimos certutil usado como segunda etapa en campanas que arrancaron con phishing de macro, flujo que describimos del lado ofensivo en Initial Access Simulado: Macros, LNK e ISO en un Lab Windows 11 Aislado y que el equipo azul debe correlacionar con eventos 4688 del AD.

Para mshta y regsvr32 (scriptlets remotos, T1218.010) la logica cambia. Mshta ejecutando URL casi siempre es malicioso fuera de sistemas de ayuda, asi que DeviceProcessEvents | where FileName =~ 'mshta.exe' | where ProcessCommandLine matches regex @'https?://|\\\\[A-Za-z0-9.-]+\\' genera tasa de falsos positivos bajo el 2% en la mayoria de las flotas que medimos. Combina con DeviceNetworkEvents en la misma ventana de 60 segundos usando join por DeviceId y ReportId para confirmar que la conexion salio del proceso sospechoso. Este tipo de correlacion multi-tabla separa el hunt de la mineria de log y conecta con Movimiento Lateral en Lab: SMB, WMI y WinRM con Foco en Deteccion, donde el atacante encadena LOLBins via WMI remoto.

Bitsadmin, msiexec /i http y wmic format remoto forman el trio que mas escapa de reglas por defecto. Para msiexec, nuestra heuristica favorita usa ProcessVersionInfoOriginalFileName para detectar binarios renombrados, algo que herramientas como Sliver hacen por default. Mira la discusion en Construyendo Infra de C2 con Sliver en Lab Aislado para Estudio Defensivo para entender el lado del operador. En Sentinel, materializamos estos hunts como Analytics Rules con entity mapping en Account y Host, frecuencia de 5 minutos y supresion de 1 hora por entidad, lo que mantiene el ruido controlado. Siempre exportamos la logica a Sigma para portabilidad entre SIEMs, misma filosofia de Purple Team en la Practica: Construyendo Ciclo de Feedback Red vs Blue.

Para cerrar con practica inmediata: ejecuta hoy en tu tenant la consulta DeviceProcessEvents | where Timestamp > ago(30d) | where FileName in~ ('rundll32.exe','mshta.exe','certutil.exe','regsvr32.exe','bitsadmin.exe','msiexec.exe') | summarize Total=count(), Hosts=dcount(DeviceName) by FileName, bin(Timestamp, 1d) | order by Timestamp desc. El resultado es tu mapa de baseline. Todo lo que se salga de ese patron en 3 desviaciones estandar se vuelve candidato a regla. Un LOLBin no se elimina, se observa con disciplina, y quien trata el baseline como producto vivo detecta intrusiones en horas, no en meses.