Durante la Segunda Guerra Mundial, a Abraham Wald se le pidió que determinara dónde añadir blindaje a los bombarderos. La intuición de los militares era estudiar los aviones que regresaban y reforzar las zonas donde se concentraban los impactos de bala. Wald dijo que había que hacer lo contrario. Los aviones que tenía delante ya habían sobrevivido a los impactos en esos puntos; exactamente por eso podía estudiarlos. Los aviones que sufrieron impactos en el motor o en la cabina jamás regresaron para ser estudiados.
La ingeniería de detección tiene el mismo punto ciego, y es fácil pasar por alto porque los aviones que sobreviven parecen ofrecer una imagen completa si nunca te preguntas qué es lo que no está frente a ti. Cada regla que escribimos y cada patrón que denominamos «conocido como malicioso» proviene de paquetes de atacantes que lograron regresar hasta nosotros, lo que significa que fueron capturados. Estamos estudiando los agujeros de bala de los aviones que regresaron y pretendemos que eso sea la imagen completa de lo que hay ahí fuera. Los criminólogos tienen un nombre para la versión de esto con la que lidian: la cifra negra del delito. Es el espacio entre los incidentes que se detectan y los incidentes que ocurren. Cada estadística criminal se basa en los delincuentes que fueron atrapados. Quienes estudian el tema lo saben y lo tienen en cuenta.
La implicación para la creación de reglas es incómoda pero importante. Las reglas a nivel de cadenas de texto solo pueden detectar a atacantes que reutilizan artefactos que ya hemos visto. Por definición, no pueden detectar a un atacante lo suficientemente sofisticado como para no haber aparecido nunca en nuestros datos de rastreo, de la misma manera que por mucho que estudiemos los aviones que regresaron, nunca veremos dónde recibieron impactos los que no volvieron. Las reglas a nivel de comportamiento son nuestra única oportunidad real ante lo desconocido. El atacante aún tiene que exfiltrar los datos, ejecutar el código y comunicarse con su servidor de comando y control. Lo que hace está limitado. Lo que nombra, cómo lo ofusca y a dónde lo envía, no lo está.
Pero la identificación de comportamientos solo sirve si sabemos cómo se supone que debe ser lo normal en primer lugar. Wald pudo señalar los aviones que faltaban porque ya sabía cómo era un avión completo e intacto. Eso fue lo que le permitió comparar cada impacto de bala en cada avión que regresaba con una forma esperada completa: alas, fuselaje, cola, motor, cabina, todo. Una vez que tuvo ese mapa completo, lo que destacó no fue dónde estaban los daños, sino dónde no estaban.
La ingeniería de detección no consigue eso de forma gratuita. Si no tenemos una imagen clara y completa de cómo es el comportamiento normal de un paquete, una llamada de red inesperada o la ejecución de un proceso desconocido no se registran como un fallo en nada. Simplemente parecen más ruido en un sistema que no está mapeado.
El verdadero coste de un conjunto de datos de comportamiento incompleto va más allá de una o dos reglas faltantes. Consiste en que perdemos la capacidad de reconocer incluso la forma de lo que falta. Un atacante que nunca aparece en nuestras detecciones basadas en cadenas de texto sigue teniendo que actuar, y esa acción solo es visible como anómala si hemos definido la línea base de la que se desvía. Sin esa línea base, los paquetes invisibles siguen siéndolo por un segundo motivo además del primero. No solo evitaron dejar una firma, sino que también operan en el espacio que nunca nos molestamos en describir, por lo que nada en ellos parece incorrecto a menos que examinemos las capacidades y los comportamientos de los paquetes.
Las reglas económicas de cadenas de texto e IOC son un uso racional del esfuerzo. Las estrategias utilizadas en la gran mayoría de los paquetes maliciosos son de baja sofisticación y reutilizadas, con la misma carga útil copiada en toda una ola de paquetes. Una regla de cadenas desechable captura toda esa ola sin prácticamente ningún coste, deja de ser útil en cuanto el atacante rota y se vuelve a escribir con el mismo bajo coste. Que las reglas de cadenas baratas «mueran jóvenes» es el nivel económico haciendo exactamente el trabajo para el que fue creado. Exigir una línea base de comportamiento costosa para amenazas que una regla de cadenas de cinco minutos ya detiene sería un uso ineficiente del tiempo.
La respuesta es una cartera de reglas en toda la pirámide. Las reglas baratas de nivel inferior gestionan el alto volumen. Las reglas costosas de nivel superior son nuestros únicos medios para alcanzar al pequeño grupo sofisticado que se oculta en las cifras oscuras. Diferentes niveles, diferentes trabajos, y a cuál recurrir depende enteramente de qué atacante estés intentando atrapar. Eso es exactamente lo que expone la siguiente pirámide adaptada.
Una pirámide adaptada
La pirámide del dolor de David Bianco [1] nos ofrece una forma de pensar sobre esto en capas en lugar de tratar la detección como una categoría plana, adaptada aquí para el contexto de la cadena de suministro de software. Podemos clasificar los tipos de indicadores según el coste que le supone a un atacante cambiarlos, desde lo trivial hasta lo casi imposible. Esto abarca desde sucesos fortuitos como los valores hash hasta comportamientos abiertamente deliberados como técnicas y estrategias.
Todos los niveles, excepto el superior, representan algo elegido por el atacante. Un dominio, un esquema de codificación, incluso una herramienta; todo es una decisión, y las decisiones se vuelven a tomar en el momento en que dejan de funcionarle al atacante. Eso es lo que convierte al nivel más alto de la pirámide en el lugar ideal para crear reglas duraderas, y también exactamente el más difícil para redactar una, ya que las detecciones a nivel de técnica y estrategia necesitan una línea base real que las respalde o, de lo contrario, no funcionan en absoluto.
Lo que plantea la pregunta obvia de dónde proviene esa línea base, porque la pirámide no nos la entrega hecha. Clasificar los indicadores según el coste que implica cambiarlos nos dice dónde residen las reglas duraderas, pero no cómo detectar una desviación en primer lugar. La forma más práctica de construir esa imagen es dejar de buscar una línea base universal (que no existe) y, en su lugar, mapear el comportamiento normal según el tipo de paquete. Una herramienta de compilación, una utilidad de línea de comandos, un framework web y una pequeña utilidad de función pura son tipos de software diferentes con capacidades distintas.
Una herramienta de compilación que genera procesos secundarios y accede al sistema de archivos durante la instalación se comporta como se espera, mientras que un asistente de formato de cadenas que hace lo mismo, no. Las capacidades y acciones del paquete determinan el comportamiento aceptable, y las mismas categorías de paquetes tienden a comportarse de forma similar en npm, PyPI y NuGet, por lo que el perfil es lo suficientemente estable como para reutilizarlo. Si logramos que ese mapa sea lo suficientemente completo, una acción desconocida dejará de interpretarse como ruido para convertirse en un indicio de anomalía, que es precisamente el objetivo. Es una gran cantidad de trabajo, y el mapa siempre será parcial, pero es el trabajo que hace que la cima de la pirámide sea alcanzable.
Mapeo de formas
Cada paquete que ingiere Aikido Security se analiza de forma estática y se ejecuta en un entorno aislado (sandbox) que registra lo que hizo realmente. Esa parte es ordinaria. Lo que ha cambiado es que ahora un indicador aporta una estructura que va más allá del simple hecho de haberse activado. Cada uno describe lo que el código coincidente es capaz de hacer y qué tipo de evidencia representa, de modo que una señal que por sí sola significa poco puede sopesarse frente a las que la rodean.
Eso permite que una regla de detección describa una forma en lugar de una cadena de texto. Código que se ejecuta en el tiempo de instalación, buscando credenciales que no tiene ningún motivo para tocar, enviando información al exterior, en un paquete cuyo trabajo declarado no explica nada de esto. No hay ningún dominio en una regla así, ni hash, ni nombre de paquete. Nada que un atacante pueda rotar.
El 4 de agosto de 2026, señalamos una versión recién publicada de Keyv, que se hacía pasar por la misma utilidad de clave-valor popular y de confianza que se ha descargado 600 millones de veces de NPM. Sin embargo, esta vez, durante la instalación, ejecutó un archivo JavaScript altamente ofuscado que luego descargó Bun (un ejecutable de JavaScript alternativo a Node.js) y, por último, ejecutó otro archivo JavaScript ofuscado. Esas herramientas y técnicas de comportamiento fueron suficientes para que nuestro sistema lo detectara. Si solo hubiéramos usado indicadores con nombre, nos habríamos perdido este paquete. Pero como buscamos lo inesperado, somos capaces de capturar estos paquetes que de otro modo caerían en ese espacio oscuro.
Nuestro sistema concluyó correctamente lo siguiente, a pesar de no poder ver el panorama completo debido a la intensa ofuscación: «La combinación de ejecución encubierta en tiempo de instalación, recuperación de binarios remotos, preparación y lanzamiento de la carga útil es suficiente para emitir un veredicto de malware con un alto nivel de confianza, incluso aunque el comportamiento final de la carga útil y cualquier objetivo de robo de datos no se hayan decodificado por completo».
Actualmente es, y ha sido al menos, difícil decodificar y comprender el malware ofuscado, especialmente desde el punto de vista del análisis estático. Al fin y al cabo, por eso los atacantes lo ponen ahí. Lo que sí podemos demostrar, en cambio, es que el comportamiento de los paquetes maliciosos es suficiente para que encontremos los elementos ocultos.
Aún existen algunos pequeños elementos ocultos. Wald nunca vio los aviones derribados. Lo que le permitió averiguar dónde habían recibido los impactos fue conocer lo suficientemente bien la forma de un avión completo como para notar dónde se rompía el patrón. nuestra versión de esa forma es una línea base de cómo es el comportamiento ordinario de un paquete —mantenida actualizada en lugar de dada por sentada—, y cada paquete que triajeamos aporta información a esta base. Los atacantes que aún no hemos atrapado siguen estando limitados por lo que el código tiene que hacer para robar algo. Cada una de esas restricciones es un agujero cuya ubicación ya conocemos en un avión que no ha regresado.
Descubre lo que estamos cazando en Aikido Intel. Detectamos malware en cuestión de minutos. Conecta tu repositorio a Aikido para escanear continuamente las dependencias de tus aplicaciones en busca de paquetes maliciosos.
Referencias
[1] Bianco, D. J. (2013). The Pyramid of Pain. Enterprise Detection and Response. http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html (revisado el 17 de enero de 2014, añadiendo el nivel de valores hash).
