En 2025, el 82% de las detecciones que registró CrowdStrike no incluían malware. Ni un fichero nuevo que escanear, ni una firma que reconocer. El adversario entraba con credenciales válidas y se movía usando programas que ya estaban en la máquina, firmados por Microsoft y con permiso para ejecutarse.
Ese dato, publicado en el Global Threat Report 2026 de la firma, era del 51% cinco años antes. La técnica tiene un nombre asentado en la jerga defensiva, living off the land, y describe al atacante que no trae herramientas porque le bastan las tuyas. El problema para quien defiende es que si la actividad maliciosa la ejecuta un binario legítimo, el antivirus tradicional no tiene nada contra qué comparar.
¿Qué es exactamente un LOLBin?
LOLBin es la contracción de living-off-the-land binary. Un ejecutable que viene con el sistema operativo, firmado y de uso cotidiano, que además de su función declarada puede hacer algo útil para un atacante: descargar un fichero de Internet, ejecutar un script, inyectar código en otro proceso o saltarse una lista de aplicaciones permitidas.
El catálogo comunitario que documenta estos abusos, el proyecto LOLBAS, recoge más de un centenar de binarios de Windows con capacidades de este tipo. Ninguno es una vulnerabilidad. certutil.exe existe para gestionar certificados, y también sabe descargar y descodificar ficheros. rundll32.exe carga bibliotecas, y también ejecuta código bajo demanda. Son funciones legítimas que, sacadas de contexto, sirven a un propósito muy distinto. MITRE ATT&CK las agrupa bajo la técnica System Binary Proxy Execution (T1218) y varias afines.
La consecuencia es que la frontera entre administración legítima y ataque deja de estar en el fichero y pasa a estar en el contexto. El mismo PowerShell que tu equipo de sistemas usa para desplegar una actualización es el que un intruso emplea para descargar la siguiente fase. La diferencia la marca quién lo invoca, desde dónde, con qué argumentos y qué hace justo después.
Por qué el antivirus y el control de aplicaciones no lo ven
Tres propiedades hacen que estas técnicas atraviesen los controles pensados para malware. La primera es la firma. Estos binarios están firmados por Microsoft, así que un control basado en reputación de fichero o en firma digital los da por buenos, porque efectivamente lo son.
La segunda es que no cae nada nuevo al disco. Un antivirus que vigila la aparición de ficheros no tiene evento que analizar cuando el atacante se limita a llamar a un programa que ya estaba ahí. Y el control de aplicaciones por lista blanca, si no está afinado, permite estos binarios precisamente porque son componentes del sistema que muchas tareas legítimas necesitan.
La tercera es que la parte peligrosa vive en la línea de comandos; el ejecutable en sí es inofensivo. Toda la intención (la URL desde la que se descarga, la ruta donde se escribe, el script que corre) viaja como argumento. Si no estás registrando líneas de comando completas, tu telemetría solo ve que se lanzó un binario de sistema y poco más. Es la misma clase de punto ciego que describimos al hablar de los ángulos muertos del EDR, solo que aquí el hueco lo abre la profundidad del registro y no un dispositivo sin agente.
Las familias que conviene reconocer
No hace falta memorizar el centenar de binarios del catálogo. Es más útil entender en qué categorías de comportamiento encajan, porque la detección se organiza mejor por función que por nombre.
Intérpretes y motores de scripting
PowerShell, cscript, wscript y mshta ejecutan código arbitrario por diseño. Son la herramienta favorita de quien ya está dentro y, a la vez, una utilidad cotidiana de administración, de modo que bloquearlos sin más rompe operaciones legítimas. La detección se apoya aquí en el registro de bloques de script y en la línea de comandos, más que en impedir que el intérprete exista.
Binarios de descarga y transferencia
certutil, bitsadmin, curl y, desde hace años, hasta tar traen a la máquina la siguiente fase de un ataque sin necesidad de un descargador a medida. La señal defensiva es el contexto: certutil invocado con un argumento que parece una URL es anómalo en la mayoría de los parques de equipos, porque casi nadie gestiona certificados así.
Proxy de ejecución
rundll32, regsvr32 y mshta ejecutan código en nombre de otro, lo que rompe la relación padre-hijo que un analista espera. Un documento de ofimática que lanza rundll32, que a su vez abre una conexión de red, es una secuencia que casi nunca corresponde a trabajo normal.
Herramientas de doble uso
wmic, PsExec, schtasks o las utilidades de administración remota mueven al atacante de una máquina a otra con exactamente los mismos mecanismos que tu equipo de sistemas emplea para gestionar el parque. La firma aquí no aporta nada; lo único que sirve es saber qué es normal en tu entorno y qué no.
La guía conjunta que publicaron CISA, la NSA, el FBI y sus socios internacionales en 2024, redactada tras los incidentes del grupo estatal chino Volt Typhoon en infraestructura crítica, describe estas categorías con detalle y coincide en el diagnóstico: la brecha está menos en la falta de herramientas de defensa que en la ausencia de una línea base capaz de distinguir lo raro de lo rutinario.
Si la firma no sirve, ¿qué se mira?
El desplazamiento mental que exige esta amenaza es dejar de preguntar qué es un fichero y empezar a preguntar qué está haciendo un proceso. Cuatro señales concentran casi todo el valor.
- La línea de comandos completa. Es el dato más rentable y el que más se descuida. Sin argumentos registrados, un evento de ejecución de certutil no dice nada; con ellos, la URL de descarga queda a la vista. Windows lo permite con la auditoría de creación de procesos y el registro de línea de comandos (evento 4688), y Sysmon lo enriquece.
- La relación padre-hijo. Quién lanza un proceso dice tanto como el proceso mismo. Word que engendra PowerShell, o un servicio de sistema que arranca un intérprete de scripts, son cadenas que rara vez se dan en trabajo legítimo y saltan a la vista en cuanto se representan como árbol.
- La secuencia de operaciones. Un binario aislado puede ser inocente; la cadena no. Descargar, escribir en una ruta temporal, ejecutar y abrir una conexión saliente, todo en segundos y encadenado, es un patrón de comportamiento con independencia de qué binario firmado ejecute cada paso.
- La integridad de la telemetría. Cuando una fuente que debería emitir de forma continua se queda en silencio, ese silencio es en sí mismo una alerta. Un adversario que manipula el registro de eventos o detiene un agente deja un hueco, y un hueco donde antes había señal merece investigarse.
Ese cambio de foco, del artefacto al comportamiento, es la misma tesis que sostiene la ingeniería de detección moderna: una regla que cuenta técnicas cubiertas no predice si vas a detectar al atacante, porque a un intruso que vive de la tierra lo delata la anomalía de su conducta y no la coincidencia con una firma.
La detección empieza en la telemetría, no en la herramienta
Cazar los abusos de binarios legítimos exige un tipo específico de telemetría, y buena parte de los parques de equipos no la está recogiendo con la profundidad necesaria.
El punto de partida es el registro de creación de procesos con línea de comandos, en el endpoint y centralizado. Sysmon aporta además la relación padre-hijo, los hashes y la actividad de red por proceso, y su configuración determina casi por completo lo que después podrás ver. Sobre esa base, un análisis de comportamiento de usuarios y entidades ayuda a fijar qué es normal para cada equipo, de modo que una invocación fuera de lo habitual destaque en lugar de perderse. Nada de esto funciona sin decidir antes qué fuentes importan y cuánto tiempo se conservan, que es justo la conversación que planteamos sobre qué logs enviar a un SIEM.
La caza proactiva parte de una hipótesis (por ejemplo, que alguien está usando un binario de descarga fuera de las ventanas de mantenimiento) y la contrasta contra la telemetría, en lugar de esperar a que salte una regla. Es un trabajo que descansa en tener los datos y en conocer el entorno, y es la clase de servicio que en Hard2bit, como empresa de ciberseguridad, prestamos con un servicio de threat hunting apoyado en un SOC gestionado.
Reducir la superficie antes de tener que detectar
Detectar es la mitad del trabajo, la otra mitad es quitarle al atacante los binarios que no necesitas que estén disponibles, para que abusar de ellos deje de ser fácil.
Microsoft mantiene una lista de reglas de bloqueo recomendadas para el control de aplicaciones, que neutraliza los binarios de los que más se abusa sin romper el sistema. A eso se suma un conjunto de reglas de reducción de superficie de ataque que cortan patrones definidos, como que una aplicación de ofimática engendre procesos hijo. Aplicar las reglas de bloqueo para el control de aplicaciones de Windows y afinar la lista de aplicaciones permitidas para que estos ejecutables solo corran donde de verdad hacen falta reduce el margen del atacante de forma apreciable.
Un binario de descarga solo sirve si puede alcanzar el servidor del atacante, así que restringir a dónde pueden conectarse las máquinas y vigilar las conexiones hacia destinos no habituales cortan la utilidad de buena parte de estas técnicas. Ninguna de estas medidas es nueva ni exótica; lo que suele faltar es la decisión de aplicarlas y el bastionado que las sostiene.
¿Qué significa esto para quien dirige la seguridad?
Para un comité o un responsable de seguridad, este cambio tiene una implicación incómoda de presupuesto. La inversión histórica se concentró en prevenir la entrada de ficheros maliciosos, y ese control sigue siendo necesario, pero ya no cubre la mayor parte de la actividad intrusiva que hoy se detecta. El adversario que entra con credenciales válidas y opera con binarios firmados no dispara ninguna de esas defensas.
Las preguntas útiles para el proveedor o el equipo interno son directas. ¿Registramos líneas de comando completas en todo el parque, o solo el nombre del proceso? ¿Cuánto tiempo retenemos esa telemetría? ¿Sabemos qué es normal en nuestros servidores críticos, o solo tenemos reglas genéricas? ¿Alguien caza de forma proactiva, o esperamos a que salte una alarma? Si las respuestas revelan que la visibilidad se queda en el nombre del binario, ese es el hallazgo, y arreglarlo cuesta más disciplina de datos que dinero en herramientas nuevas.
Este mismo desplazamiento del artefacto al comportamiento atraviesa otras amenazas actuales, desde el secuestro de sesión en Microsoft 365 hasta el mando y control que se esconde en tráfico corporativo legítimo. El patrón de fondo se repite: cuando el atacante usa lo que ya confías, defenderse depende de conocer tu propio entorno con suficiente detalle para notar cuándo algo se sale del guion.
Datos y marcos citados en este artículo: el CrowdStrike Global Threat Report 2026, la guía conjunta de CISA, NSA, FBI y socios internacionales sobre técnicas living off the land (febrero de 2024), el proyecto comunitario LOLBAS y la documentación de MITRE ATT&CK y de Microsoft. Reflejan la información disponible el 22 de agosto de 2026. El artículo describe controles de detección y bastionado desde la perspectiva del defensor y no contiene procedimientos de ataque reproducibles. Los nombres de binarios se citan por su relevancia para la detección y corresponden a componentes legítimos del sistema operativo.
Las recomendaciones de telemetría, reglas de bloqueo y bastionado deben validarse en un entorno controlado antes de aplicarlas en producción. Restringir intérpretes de scripts o binarios de administración puede afectar a tareas legítimas si no se afina para cada organización.
