Durante la Segunda Guerra Mundial, le preguntaron a Abraham Wald dónde debía añadirse blindaje a los aviones bombarderos. El instinto de los militares era estudiar los aviones que regresaban y reforzar aquellas zonas en las que se concentraban los agujeros de bala. Wald respondió que había que hacer lo contrario. Los aviones que tenía delante ya habían sobrevivido a impactos en esos puntos. Precisamente por eso podía estudiarlos. Los aviones que habían recibido impactos en el motor o en la cabina nunca regresaban para ser estudiados.
La ingeniería de detección tiene el mismo punto ciego, y es fácil pasarlo por alto porque los planos que sobreviven parecen ofrecer una imagen completa si nunca te preguntas qué es lo que no tienes delante. Cada regla que escribimos y cada patrón que calificamos como «malicioso conocido» se extrae de los paquetes de los atacantes que nos han llegado, lo que significa que han sido detectados. Estamos estudiando los agujeros de bala en los aviones que han regresado y lo consideramos el panorama completo de lo que hay ahí fuera. Los criminólogos tienen un nombre para la versión de este fenómeno con la que trabajan: la «cifra oculta de la delincuencia». Se trata del espacio entre los incidentes que se detectan y los que realmente ocurren. Todas las estadísticas sobre delincuencia se basan en los delincuentes que han sido capturados. Quienes las estudian lo saben y lo tienen en cuenta.
Las implicaciones para la creación de reglas son incómodas, pero importantes. Las reglas a nivel de cadena solo pueden detectar a los atacantes que reutilizan artefactos que ya hemos visto. Por su propia naturaleza, no pueden detectar a un atacante lo suficientemente sofisticado como para no haber aparecido nunca en nuestros datos de seguimiento, del mismo modo que por mucho que se analicen los aviones que regresaron, nunca se sabrá dónde fueron alcanzados los que no regresaron. Las reglas a nivel de comportamiento son nuestra única oportunidad real frente a lo desconocido. El atacante sigue teniendo que extraer los datos, sigue teniendo que ejecutar el código y sigue teniendo que «llamar a casa». Lo que hace está limitado. Lo que le llama, cómo lo ofusca y adónde lo envía, en cambio, no lo está.
Pero la identificación de comportamientos solo resulta útil si, para empezar, sabemos cómo se supone que debe ser lo normal. Wald pudo señalar los aviones desaparecidos porque ya sabía cómo era un avión íntegro y sin daños. Eso fue lo que le permitió comparar cada agujero de bala de cada avión que regresaba con la forma completa esperada: alas, fuselaje, cola, motor, cabina, todo ello. Una vez que tuvo ese mapa completo, lo que más llamaba la atención no era dónde estaban los daños, sino dónde no los había.
La ingeniería de detección no dispone de eso de forma gratuita. Si no tenemos una visión clara y completa de cómo es el comportamiento normal de un paquete, una llamada de red inesperada o la generación de un proceso desconocido no se registran como una brecha en ningún sistema. Simplemente parecen más ruido en un sistema que no está mapeado.
El coste real de un conjunto de datos de comportamiento incompleto va más allá de la falta de una o dos reglas. Se trata de que perdemos la capacidad incluso de reconocer la forma de lo que falta. Un atacante que nunca aparece en nuestras detecciones basadas en cadenas de caracteres tiene que actuar de todos modos, y esa acción solo se percibe como anómala si hemos definido la línea de referencia de la que se desvía. Sin esa línea de referencia, los paquetes invisibles siguen siendo invisibles por una segunda razón, además de la primera. No solo han evitado dejar una firma, sino que además operan en un espacio que nunca nos hemos molestado en describir, por lo que nada de lo que hacen parece sospechoso a menos que analicemos las capacidades y los comportamientos de los paquetes.
Las reglas de cadenas y IOC baratas suponen un uso racional del esfuerzo. Las estrategias utilizadas en la inmensa mayoría de los paquetes maliciosos son poco sofisticadas y se reutilizan, con la misma carga útil copiada en toda una oleada de paquetes. Una regla de cadena desechable detecta toda esa oleada casi sin coste alguno, deja de ser efectiva en el momento en que el atacante cambia de estrategia y se reescribe con la misma facilidad. Que las reglas de cadenas baratas «mueran pronto» significa que el nivel económico cumple exactamente la función para la que fue diseñado. Exigir una línea de base de comportamiento costosa para amenazas que una regla de cadena de cinco minutos ya detiene supondría un uso ineficiente del tiempo.
La respuesta es un conjunto de reglas que abarca toda la pirámide. Las reglas baratas de nivel inferior se encargan del gran volumen. Las reglas caras de nivel superior son los únicos medios de que disponemos para llegar a los pocos atacantes sofisticados que se esconden en la figura oscura. Diferentes niveles, diferentes funciones, y la elección de cuál utilizar depende totalmente del tipo de atacante al que se intente atrapar. Eso es exactamente lo que ilustra la siguiente pirámide adaptada.
Una pirámide adaptada
La «pirámide del dolor» de David Bianco [1] nos ofrece una forma de analizar esto por niveles, en lugar de considerar la detección como una única categoría plana, adaptada aquí al contexto de la cadena de suministro de paquetes. Podemos clasificar los tipos de indicadores según el esfuerzo que supone para un atacante modificarlos, desde lo trivial hasta lo casi imposible. Esto abarca desde sucesos fortuitos, como los valores hash, hasta comportamientos claramente deliberados, como las técnicas y estrategias.
Todos los niveles, excepto el más alto, son elegidos por el atacante. Un dominio, un esquema de codificación, incluso una herramienta: todo ello es una decisión, y las decisiones se revisan en el momento en que dejan de servirle al atacante. Eso es lo que hace que el nivel más alto de la pirámide sea el lugar ideal para crear reglas duraderas, y también es precisamente el lugar más difícil para redactarlas, ya que las detecciones a nivel técnico y estratégico necesitan una base sólida que las respalde o, de lo contrario, no funcionan en absoluto.
Lo cual plantea la pregunta obvia de dónde proviene esa referencia, ya que la pirámide no nos la proporciona. Clasificar los indicadores según lo costoso que resulta modificarlos nos indica dónde se encuentran las reglas duraderas, pero no cómo detectar una desviación en primer lugar. La forma más práctica de construir ese panorama es dejar de buscar una referencia universal (que no existe) y, en su lugar, trazar un mapa del comportamiento normal por tipo de paquete. Una herramienta de compilación, una utilidad de línea de comandos, un marco web y una pequeña utilidad de función pura son tipos diferentes de software con capacidades distintas.
Una herramienta de compilación que genera procesos hijos y accede al sistema de archivos durante la instalación se comporta según lo esperado, mientras que una función auxiliar de formateo de cadenas que hace lo mismo no lo hace. Las capacidades y acciones del paquete determinan el comportamiento aceptable, y las mismas categorías de paquetes suelen comportarse de manera similar en npm, PyPI y NuGet, por lo que el perfil es lo suficientemente estable como para reutilizarlo. Si conseguimos que ese mapa esté lo suficientemente completo, una acción desconocida deja de interpretarse como ruido y empieza a interpretarse como un hueco en la forma esperada, que es precisamente de lo que se trata. Supone una gran cantidad de trabajo, y el mapa siempre será parcial, pero es ese trabajo el que hace que la cima de la pirámide sea alcanzable en absoluto.
Representación gráfica de la forma
Cada paquete que procesa Aikido Security se analiza de forma estática y se ejecuta en un entorno aislado que registra lo que realmente ha hecho. Esa parte es habitual. Lo que ha cambiado es que ahora un indicador lleva consigo información más allá del mero hecho de que se haya activado. Cada uno describe lo que el código coincidente es capaz de hacer y qué tipo de indicio representa, de modo que una señal que por sí sola no signifique gran cosa pueda sopesarse en relación con las demás que la rodean.
Eso permite que una regla de detección describa una forma en lugar de una cadena de caracteres. Código que se ejecuta durante la instalación, accediendo a credenciales que no tiene motivos para tocar, enviando algo al exterior, en un paquete cuya función declarada no explica nada de ello. En una regla como esa no hay ningún dominio, ni hash, ni nombre de paquete. No hay nada en ella que un atacante pueda manipular.
El 4 de agosto de 2026, detectamos una versión recién publicada de Keyv, que se presentaba como la misma utilidad de clave-valor popular y de confianza que se ha descargado 600 millones de veces desde NPM. Esta vez, sin embargo, al instalarla se ejecutaba un archivo JavaScript muy ofuscado, que a su vez descargaba Bun (un ejecutor de JavaScript alternativo a Node.js) y, finalmente, ejecutaba otro archivo JavaScript ofuscado. Esas herramientas y técnicas de comportamiento fueron suficientes para que nuestro sistema lo detectara. Si solo hubiéramos utilizado indicadores con nombre, este paquete se nos habría pasado por alto. Pero como buscamos lo inesperado, somos capaces de detectar estos paquetes que, de otro modo, pasarían desapercibidos.
Nuestro sistema llegó a la siguiente conclusión correcta, a pesar de que no pudo ver el panorama completo debido a la intensa ofuscación: «La combinación de ejecución oculta en el momento de la instalación, la recuperación remota de binarios, la preparación de la carga útil y su lanzamiento es suficiente para emitir un veredicto de malware con un alto grado de confianza, aunque el comportamiento final de la carga útil y cualquier objetivo de robo de datos no se hayan descifrado por completo».
En la actualidad, y siempre ha sido así, resulta, como mínimo, difícil descifrar y comprender el malware ofuscado, especialmente desde el punto de vista del análisis estático. Al fin y al cabo, esa es precisamente la razón por la que los atacantes lo incluyen. Lo que sí podemos demostrar, en cambio, es que el comportamiento de los paquetes maliciosos nos basta para detectar las cifras ocultas.
Aún queda una pequeña silueta oscura. Wald tampoco vio los aviones derribados. Lo que le permitió averiguar dónde habían sido alcanzados fue conocer la forma de un avión completo lo suficientemente bien como para darse cuenta de dónde se rompía el patrón. Nuestra versión de esa forma es una referencia de cómo se comporta normalmente un paquete, que se mantiene actualizada en lugar de basarse en suposiciones, y cada paquete que clasificamos la amplía. Los atacantes que aún no hemos capturado siguen estando limitados por lo que el código tiene que hacer para robar algo. Cada una de esas limitaciones es un agujero cuya ubicación ya conocemos en un avión que no ha regresado.
Descubre lo que estamos detectando en Aikido Intel. Detectamos malware en cuestión de minutos. Conecta tu repositorio a Aikido para analizar de forma continua las dependencias de tu aplicación en busca de paquetes maliciosos.
Referencias
[1] Bianco, D. J. (2013). «La pirámide del dolor». Enterprise Detection and Response. http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html (revisado el 17 de enero de 2014, con la incorporación del nivel de valores hash).
