Evolución de instaladores ScreenConnect troyanizados: descargan varios RAT en un equipo

Autores: Ilia Dafchev, Eliad Kimhy

• Aumento del uso malintencionado de ScreenConnect: desde marzo de 2025, la Unidad de Investigación de Amenazas de Acronis (TRU) ha observado un incremento de los ataques que utilizan instaladores de ConnectWise ScreenConnect troyanizados para obtener acceso inicial a organizaciones de EE. UU. Lo que estamos viendo es una tendencia sostenida a largo plazo en el uso malintencionado de herramientas de RMM que sigue atrayendo a ciberdelincuentes, quizá debido a su gran eficacia.

• Instaladores de ClickOnce evasivos: los atacantes utilizan ahora un instalador ejecutable de ClickOnce para ScreenConnect, que carece de configuración incrustada y, en su lugar, descarga los componentes durante el tiempo de ejecución. Esta evolución reduce la eficacia de los métodos tradicionales de detección estática y complica las tareas de prevención, lo que deja a los defensores con pocas opciones fiables.

• Despliegue automatizado de dos troyanos de acceso remoto (RAT): justo después de instalarse ScreenConnect, los atacantes utilizan sus funciones de automatización para desplegar rápidamente dos troyanos de acceso remoto: el conocido AsyncRAT y un RAT personalizado basado en PowerShell. Este doble despliegue puede servir como redundancia, para probar herramientas o para reflejar una infraestructura compartida entre varios ciberdelincuentes.

• RAT de PowerShell personalizado: el equipo de TRU ha descubierto un nuevo RAT casero que no se había visto hasta ahora en ningún repositorio de código abierto. Este nuevo RAT realiza tareas de reconocimiento del sistema, exfiltra datos a través de Microsoft.XMLHTTP y emplea diversas técnicas de ofuscación. Su base de código única sugiere que lo desarrolló el propio atacante, posiblemente para eludir la detección basada en firmas.

• Evolución de las cadenas de infección: dos semanas después del incidente de seguridad, los atacantes actualizaron su cadena de infección para utilizar cargadores por lotes y VBS que recuperan y ejecutan ensamblados .NET codificados para desplegar AsyncRAT, lo que demuestra su adaptabilidad y la evolución en su infraestructura.

• Ingeniería social y reutilización de infraestructuras: los instaladores maliciosos se distribuyen con nombres de archivo que imitan documentos oficiales o financieros, probablemente a través de phishing. Los ciberdelincuentes también reutilizan máquinas virtuales de Windows Server 2022 preconfiguradas (con nombres de host coherentes) en varias campañas, lo que les permite volver a desplegar máquinas virtuales rápidamente y rotar su infraestructura.

• Recomendaciones defensivas: las organizaciones deben supervisar de cerca el uso de herramientas de RMM y examinar cuidadosamente los despliegues de ScreenConnect.

En los últimos meses, la Unidad de Investigación de Amenazas de Acronis (TRU) ha identificado varias campañas activas que utilizan versiones troyanizadas de ConnectWise ScreenConnect para obtener acceso inicial a las redes de las víctimas y comprometer los equipos objetivo. Nuestra investigación ha revelado que la frecuencia de estas campañas ha aumentado desde marzo de 2025 y, en la actualidad, la mayoría de las empresas víctimas se encuentran en Estados Unidos, aunque por el momento no hay indicios sobre la ubicación de los ciberdelincuentes.

Aunque no sea un fenómeno nuevo, el uso de ConnectWise ScreenConnect para establecer un punto de apoyo inicial ha experimentado varios cambios en estas campañas recientes, como el despliegue de instaladores más pequeños basados en ClickOnce en lugar de los instaladores completos. Estos instaladores de ClickOnce son más evasivos que los observados anteriormente, ya que ya no dependen de la configuración incrustada, lo que limita las posibilidades de detección. Una vez instalado, los atacantes pueden tomar el control del equipo comprometido, lo que les permite instalar otro malware, robar información, establecer persistencia y desplazarse lateralmente por la red.

El uso malintencionado del software de Administración y supervisión remotas (RMM) como ScreenConnect es cada vez más común, lo que se suma a la creciente lista de herramientas legítimas que los atacantes reutilizan con fines maliciosos. En estos tipos de ataques, los instaladores de ScreenConnect suelen estar firmados y aparecer como aplicaciones de confianza, pero conceden al atacante un amplio control sobre el equipo comprometido.

Los equipos de TI suelen utilizar ScreenConnect para acceder a los sistemas de forma remota para brindar soporte técnico o responder ante incidentes. Los ciberdelincuentes pueden convertir el software de RMM en una herramienta ofensiva a través de múltiples vías, desde el aprovechamiento de vulnerabilidades hasta el uso indebido o la manipulación del producto legítimo. Sea cual sea el método utilizado, el resultado final es un ejecutable que conecta el equipo de la víctima con un servidor controlado por los atacantes. Los atacantes pueden esperar días o incluso semanas antes de actuar, siempre y cuando el software de RMM malicioso pase desapercibido.

En este artículo se analizan las campañas recientes que utilizan ScreenConnect para obtener acceso inicial y se detalla el malware que se despliega después de la infección. Los equipos de seguridad pueden sacar provecho de los hallazgos y las recomendaciones que se exponen aquí para reforzar sus defensas y contrarrestar amenazas similares.

El ataque comienza con un ejecutable malicioso llamado agreement_support-pdf.Client.exe, que parece haberse descargado a través del navegador Microsoft Edge. Este archivo es un instalador de ClickOnce camuflado como un documento de soporte legítimo, un método de ingeniería social que se utiliza con frecuencia para engañar a los usuarios y hacer que ejecuten código no fiable. Es probable que el ataque proceda de una campaña de ingeniería social, distribuida principalmente mediante phishing por correo electrónico, aunque también cabe la posibilidad de que se haya empleado otro método.

Al ejecutarse, el instalador lanza ScreenConnect.ClientSetup.exe, que, una vez instalado, conecta el equipo de la víctima con el servidor de mando y control (C2) del atacante.

Como se ha mencionado previamente, estos instaladores se diferencian de ataques anteriores relacionados con ScreenConnect en que utilizan un instalador ejecutable basado en ClickOnce. Esta versión del instalador es más pequeña y no tiene la configuración incrustada. En su lugar, se conecta directamente al servidor de ScreenConnect configurado, mediante la descarga de las configuraciones y componentes necesarios para continuar con la instalación. Esto ayuda bastante a que los instaladores maliciosos pasen desapercibidos. En iteraciones anteriores de estos ataques, un producto de seguridad podía buscar frases específicas dentro de la configuración incrustada para detectar y bloquear las ejecuciones sospechosas de ScreenConnect. Sin embargo, en esta nueva versión ya no es posible. Los dos únicos métodos de prevención fiables que quedan serían incluir en una lista negra el dominio de C2 (lo que es difícil de saber de antemano) o bloquear ScreenConnect por completo.

Los investigadores de TRU descubrieron la dirección maliciosa a través de los parámetros de instalación presentes en el instalador. El instalador se ejecutó con los parámetros: e=Support&y=Guest&h=morco[.]rovider[.]net&p=8041, los cuales establecen conexión con un dominio controlado por el atacante, morco.rovider[.]net. El dominio se registró recientemente y está alojado en un servidor privado virtual (VPS) asociado a stealthrdp[.]com. También se ha observado que distribuye otras muestras maliciosas, lo que indica que forma parte de una infraestructura de campaña de malware más amplia.

Este ataque abusa de un tipo de instalador in situ para ScreenConnect. Dado que las instalaciones in situ deben ser independientes de la infraestructura en la nube, ConnectWise proporciona a los clientes los medios necesarios para configurar tanto un servidor como los clientes dentro de su propia red, sin tener que depender de ningún componente en la nube. Este sistema tiene dos componentes: un instalador para el servidor y un instalador para los clientes. En aplicaciones legítimas, el instalador del servidor se configurará con una dirección y podrá crear también instaladores para los clientes.

En este ataque, es probable que los atacantes hayan conseguido una versión manipulada del instalador del servidor que les permitió cambiar la dirección del servidor. Esta modificación permite a los atacantes crear instaladores que se conectan a su propio servidor malicioso de ScreenConnect, mientras aparentan ser legítimos ante los productos de seguridad. Sin conocer la dirección del servidor incrustada, la detección resulta difícil.

Con ScreenConnect instalado y conectado al servidor C2 del atacante, se desarrolla un modelo de ataque complejo a lo largo de aproximadamente dos meses. Los investigadores de TRU analizaron la evolución del ataque a lo largo del tiempo y descubrieron que el atacante desplegaba múltiples troyanos de acceso remoto (RAT) simultáneamente y los utilizaba alternándolos según su conveniencia. Uno de ellos era un RAT basado en PowerShell con funciones básicas, mientras que los demás eran herramientas consolidadas y ampliamente utilizadas, como AsyncRAT. Esta alternancia en el uso de RAT dificulta determinar con precisión si la responsabilidad recae sobre un único atacante o si la infraestructura se comparte entre varios operadores, ya que es posible que el acceso a dicha infraestructura se haya vendido a múltiples individuos que podrían no conocerse entre sí.

Mientras se instala ScreenConnect, se descargan dos cargas útiles en cuestión de minutos. Esto se debe a una funcionalidad de ScreenConnect que permite a los administradores definir automatizaciones específicas, como la ejecución de un script cuando el usuario se conecta por primera vez al servidor. Esto permite al atacante desplegar automáticamente un conjunto de RAT diferentes en cuestión de minutos tras la instalación.

Como primera carga útil maliciosa, el atacante utiliza ScreenConnect para que se descargue y se ejecute un archivo de proceso por lotes en el equipo de la víctima: BypaasaUpdate.bat. Este archivo de proceso por lotes inicial actúa como descargador y cargador inicial ("stager") para todas las demás fases de la infección de la primera carga útil, descargando y extrayendo posteriormente un archivo ZIP que contiene:

• 1.txt: un archivo de texto que contiene AsyncRAT.

• Pe.txt: un archivo de texto que contiene una técnica de evasión de AMSI en .NET y un mecanismo de persistencia.

• Skype.ps1: un script de PowerShell que procesa y carga los archivos txt mencionados anteriormente como ensamblados .NET.

• b.bat: un script por lotes que se utiliza para ejecutar el script de PowerShell mencionado anteriormente.

Una vez extraídos los archivos, se llama primero a "b.bat", que a su vez ejecuta "Skype.ps1". A continuación, "Skype.ps1" carga "Pe.txt" y "1.txt" como ensamblados .NET en la memoria.

El archivo "1.txt" es AsyncRAT, un troyano de acceso remoto (RAT) muy conocido y popular que se utiliza ampliamente tanto por parte de profesionales legítimos para llevar a cabo pruebas éticas de seguridad como por ciberdelincuentes. Por su parte, el archivo "Pe.txt" se emplea tanto para eludir la interfaz de análisis antimalware (AMSI), lo que permite que el script siga ejecutando scripts maliciosos, como para establecer mecanismos de persistencia.

La persistencia se consigue mediante la creación de un archivo adicional llamado "Microsoft.vbs", cuyo único propósito es volver a ejecutar "Skype.ps1". A continuación, se crea una tarea programada para ejecutar "Microsoft.vbs" una única vez al cabo de un minuto desde su creación. Cuando se ejecuta la tarea, "Microsoft.vbs" vuelve a ejecutar "Skype.ps1", lo que a su vez carga AsyncRAT y "Pe.txt" de nuevo y establece una nueva tarea programada para ejecutarse al cabo de un minuto. De esta forma se crea un mecanismo de persistencia en el que AsyncRAT se recarga en la memoria cada minuto y se vuelve a crear todo el mecanismo de persistencia.

Aunque esto implica que "Skype.ps1" intenta cargar AsyncRAT en la memoria cada minuto, "1.txt" (el archivo de texto que contiene AsyncRAT) comprueba si existe un mútex específico, AsyncMutex_al026, para verificar si AsyncRAT ya se está ejecutando y, si es así, finaliza su ejecución. De esta forma, AsyncRAT no se volverá a cargar cada minuto, sino solo cuando no esté ya en ejecución.

Por otro lado, cabe señalar que este mecanismo de persistencia genera una actividad excesiva y fácilmente detectable. Ejecutar un script de PowerShell cada minuto deja un rastro enorme, algo que los atacantes corregirán en una fase posterior del ataque.

Pocos minutos después de que AsyncRAT se cargue y se configure, observamos que ScreenConnect descarga y ejecuta otro script. No obstante, mientras que el primer script descargó una herramienta conocida, AsyncRAT, el segundo desplegó una nueva carga útil inesperada: una especie de troyano de acceso remoto casero (RAT). Este RAT está escrito como un script de PowerShell y proporciona algunas funcionalidades básicas, como la ejecución de programas, la descarga y ejecución de archivos y un mecanismo de persistencia sencillo. No parece ser ninguna herramienta de código abierto que hayamos visto hasta la fecha, y es posible que la haya escrito el propio atacante.

Es muy probable que se trate de otra ejecución automática, lo que plantea la siguiente cuestión: ¿por qué se han desplegado dos RAT en el equipo infectado? No hay respuestas claras, pero sí algunas hipótesis:

1.      Los atacantes podrían estar actuando con mucha cautela. Si se detecta una herramienta, se puede utilizar otra que sirva como "puerta trasera". También es posible que este segundo RAT disponga de funciones de evasión que no están presentes en el primero.

2.      Los atacantes podrían estar probando una nueva herramienta que están desarrollando y hayan decidido desplegar ambas.

3.      Varios atacantes utilizan la misma infraestructura (o se les ha vendido acceso a la misma).

Sea cual sea la razón, hemos detectado una nueva dirección del servidor C2, y en nuestro análisis del ataque observamos que ambos RAT se utilizaron en las semanas posteriores.

La cadena de ataque también parece más sencilla: comienza con un archivo JavaScript, aparentemente nombrado según el puerto de la dirección de C2, que se descarga en una carpeta temporal. El script ejecuta todo el RAT como un comando de PowerShell.

El propio comando, una vez desofuscado, revela un script que actúa como una especie de RAT casero capaz de llevar a cabo las siguientes acciones: deshabilita AMSI, configura un receptor de comandos, realiza tareas de reconocimiento inicial, establece mecanismos de persistencia y lanza un bucle infinito que funciona como gestor de comandos.

En primer lugar, el script realiza un reconocimiento del sistema. Para ello, recopila información sobre los nombres de los antivirus mediante consultas a WMI para detectar los antivirus instalados, así como el nombre y la arquitectura del sistema operativo, el UUID, el nombre del equipo y el nombre de usuario. A continuación, todo esto se transmite al servidor C2 del atacante mediante Microsoft.XMLHTTP, que también se utiliza para recibir comandos. Este es un uso bastante interesante de este objeto COM, ya que se emplea más comúnmente en scripts VBS. Es posible que el atacante haya optado por utilizar esta opción en lugar de los comandos integrados de PowerShell para evitar la detección, ya que muchos productos de seguridad buscan comandos de PowerShell que establezcan comunicaciones por internet.

El gestor de comandos está compuesto por un bucle que envía solicitudes POST al servidor C2 cada tres segundos y espera una respuesta. A continuación, el bucle ejecuta los comandos siguientes, en función de la respuesta recibida:

1.      RF ("Run File" [ejecutar archivo]): este comando permite al atacante escribir un archivo binario en una carpeta temporal y ejecutarlo.

2.      TR: recibe el código de PowerShell del atacante, lo escribe en el disco como un archivo .ps1 y lo ejecuta. Además, establece un mecanismo de persistencia mediante un script VBS. El script VBS está configurado para ejecutarse al iniciar el sistema mediante la carpeta de inicio y se utiliza para lanzar el script de PowerShell. Esto se puede utilizar para configurar cualquier número de puertas traseras adicionales, o bien cualquier otro script en el que el atacante quiera aplicar persistencia.

3.      Exc: permite al atacante escribir un script VBS en una carpeta temporal y ejecutarlo.

4.      Sc: realiza una acción similar al comando RF; sin embargo, este comando se utiliza para escribir en texto sin formato y probablemente se emplea para escribir y ejecutar scripts.

5.      Cl: finaliza el bucle y cierra el script.

6.      Un: finaliza el bucle y cierra el script.

La persistencia se establece al crear una copia de "8911.js" (el archivo JavaScript que originalmente lanza el script del RAT) en la carpeta de inicio con el nombre "FirefoxUpdate.js".

El script utiliza varias técnicas de ofuscación para eludir la detección y dificultar el análisis. Los nombres de las variables y funciones son deliberadamente largos, sin sentido o no relacionados con su propósito, mientras que la ejecución de los comandos se oculta tras alias calculados de forma dinámica. Las cargas útiles principales, como el script de persistencia VBS, se almacenan como matrices de códigos de caracteres ("charcode") y solo se descodifican durante la ejecución. Por su parte, el mecanismo para eludir AMSI se almacena como un ensamblado .NET codificado en Base64. El gestor de comandos utiliza códigos cortos y crípticos (como RF, TR, SC) en lugar de nombres descriptivos, y los archivos descargados reciben nombres aleatorios o basados en identificadores globales únicos (GUID).

El script utiliza objetos integrados de Windows, como Microsoft.XMLHTTP para la comunicación con el servidor C2 y Microsoft.VisualBasic.Interaction para la creación de objetos, mimetizándose con otras actividades legítimas del sistema. Los datos de reconocimiento del sistema se exfiltran a través de los encabezados HTTP en lugar de los parámetros obvios, y se suprimen los mensajes de error para evitar llamar la atención. Juntas, estas estrategias de ofuscación en capas dificultan que los productos de seguridad detecten y eviten automáticamente el verdadero comportamiento del script.

En definitiva, el análisis de este script resulta bastante interesante, sobre todo porque no hemos encontrado evidencia de que se haya utilizado en ningún otro ataque. Aunque se han reutilizado algunos fragmentos del código, el atacante parece haber escrito la mayor parte de este RAT casero. Esto podría suponer una gran ventaja para el atacante, ya que le permite ajustar la herramienta a sus necesidades específicas y evitar la detección basada en firmas o patrones bien conocidos. No obstante, por otro lado puede carecer de algunas de las funciones avanzadas que ofrecen otras herramientas. En resumen, se trata de un hallazgo interesante que plantea la cuestión de si más de un atacante está utilizando la misma infraestructura.

Dos semanas después de la primera infección, los ciberdelincuentes aprovecharon su acceso a ScreenConnect para desplegar una nueva versión de AsyncRAT, junto con una cadena de infección renovada.

La cadena de infección actualizada comienza con un script por lotes que lanza MicrosoftUpdate.vbs, un sencillo contenedor ("wrapper") para una instrucción de PowerShell en una sola línea que actúa como cargador. Este script de PowerShell descarga dos archivos, "logs.ldr" y "logs.ldk", en el directorio C:\Users\Public.

Ambos archivos, "logs.ldk" y "logs.ldr", son ensamblados .NET codificados. El script de PowerShell descodifica y ejecuta "logs.ldk" en primer lugar, que es una DLL de .NET denominada "Obfuscator.dll" y que tiene una doble finalidad: establecer la persistencia y actuar como cargador secundario para "logs.ldr", la carga útil real de AsyncRAT.

La persistencia se consigue mediante una tarea programada denominada "Skype Updater", configurada para ejecutar C:\Users\Public\Ab.vbs al iniciar sesión el usuario. Este script VBS refleja el comportamiento de MicrosoftUpdate.vbs, ya que funciona como un contenedor que invoca al cargador basado en PowerShell.

AsyncRAT ("logs.ldr") se descodifica finalmente y se carga en la memoria a través de la llamada al método "Obfuscator.dll" [Obfuscator.A]::Main($f2), utilizada desde dentro del script de PowerShell.

La nueva instancia de AsyncRAT desplegada tenía una configuración actualizada. Cabe destacar que utilizó una nueva cadena de mútex: "AsyncMutex_alosh20215" y se comunicó con el servidor de mando y control (C2) a través de los puertos 4501, 4502 y 4503.

La infraestructura de C2 permaneció intacta, y siguió alojada en 185.196.9.158.

Varios días después de que se desplegara el AsyncRAT actualizado, observamos que se entregaba otro RAT a través de WMI. La actividad tuvo lugar apenas unos minutos después de ejecutarse los scripts relacionados con AsyncRAT, y aunque no es posible atribuirla de forma definitiva con las pruebas disponibles, la proximidad temporal sugiere una alta probabilidad de que ambos eventos estén relacionados.

Se observó que el proceso WmiPrvSE.exe ejecutaba un comando de PowerShell que utilizaba Invoke-WebRequest para descargar un script denominado "NvContainerRecovery.ps1" en el directorio C:\Users\Public. Inmediatamente después, el mismo proceso WMI invocó de nuevo a PowerShell para ejecutar el script descargado.

El script NvContainerRecovery.ps1 establece la persistencia en primer lugar mediante la creación de un script VBS en la carpeta de Inicio. Este archivo VBS actúa simplemente como un contenedor para ejecutar el mismo script de PowerShell en cada inicio de sesión de usuario.

Tras la configuración de la persistencia, el script de PowerShell carga una DLL .NET que implementa el vaciado de procesos (también conocido como "process hollowing"). Este método se utiliza para inyectar otra biblioteca de ensamblado .NET en una instancia generada de RegAsm.exe. El ensamblado inyectado es responsable de descifrar y cargar una carga útil .NET final, identificada como PureHVNC RAT.

La instancia de PureHVNC está configurada para conectarse a 169.156.208.185 en el puerto 8020.

Una investigación de la infraestructura del ataque revela varios dominios diferentes que creemos que podría estar utilizando el atacante. Además de morco.rovider.net, también se incluyen otros dos dominios: gaza.rovider.net y lightc.rovider.net. Ambos están relacionados con los instaladores de ScreenConnect, con servidores alojados en stealthrdp.com. Asimismo, se ha descubierto que ambos dominios guardan relación con XWorm y DCRat, lo que podría indicar una infraestructura de ataque más amplia de lo que se había observado hasta ahora.

Por otro lado, hemos identificado numerosos casos en los que se utilizaban instaladores de ScreenConnect que se conectaban a servidores de ScreenConnect in situ probablemente manipulados. La inmensa mayoría de estos incidentes se produjeron en Estados Unidos, y los nombres de los instaladores sugieren claramente que se distribuyeron mediante phishing u otras técnicas de ingeniería social.

Los ejecutables suelen tener nombres que simulan documentos legítimos, con el fin de engañar a los usuarios para que los ejecuten. He aquí algunos ejemplos:

• Social_Security_Statement_Documents_386267.exe MD5: 2EECA7166487DDC0B4C36B718DF31C93

 ssa_view.exe MD5: C92D37BC45F6088458C70C1CF53C06F6

• Social-Security-Available-Statement-3025147.ClientSetup.exe MD5: BA261666A657BDE2E8E071EE6E7D5357

• agreement_support-pdf.Client.exe MD5: 34ED21AC2399CC08BD051A283FD59FCE

• SSADocumentViewer-nXpJ2.exe MD5: A58719D9DDE0179C25215637766C2AB0

• 2024 BUSINESS SCHEDULE COMPLETE ORGANIZERpdf.exe MD5: 316119C77032A24822A64C86C1E4B2A0

Este patrón de denominación indica un intento claro de camuflarse como documentos oficiales o financieros, principalmente relacionados con la seguridad social o acuerdos legales.

En estos casos, observamos sobre todo el despliegue de AsyncRAT y Remcos RAT.

En cuanto a Remcos, identificamos que el ciberdelincuente reutilizó la misma máquina virtual en varias campañas, aunque estaba alojada en diferentes direcciones IP. Según los resultados de Shodan, la máquina virtual ejecutaba Windows Server 2022, tenía RDP habilitado y alojaba un servidor de ScreenConnect. El nombre de host de la máquina virtual era coherente en todas las detecciones: WIN-BUNS25TD77J.

Al recopilar muestras adicionales de fuentes de inteligencia de amenazas, descubrimos otro nombre de host habitual que se había utilizado en varias campañas: COPY-OF-VM-2022. Parece que los atacantes pueden tener máquinas virtuales preconfiguradas que alojan en diferentes direcciones, lo que les permite realizar cambios rápidos en la infraestructura y en las configuraciones.

Redes:

• 169.156.208.185

• 185.196.9.158

• 185.196.8.100

• morco[.]rovider[.]net

• hxxps://eywordvailabom[.]com/sa/16-05.txt

• hxxps://systemwindowsupdate[.]com/alosh/logs.ldk

• hxxps://guilloton[.]fr/x.zip

Mútex:

• AsyncMutex_al026

• AsyncMutex_alosh20215

Archivos:

• agreement_support-pdf.Client

67A32455A94B3396AD956CBDDA81D8ED1CD3727315159E025299057118DEB6AC

• Skype.ps1

BB182B8545B8C825811C6D09C738C230FE54BC96ADF1F10A3683B7E5294B5289

• 1.txt

C260779FB1C9FF775739F6CF1853C9C33131ECF176737F6AF26B0AC60A6081DC

• Pe.txt

53AAD05571E86F22E2C75ED4FA6C8F553C3EBD58DCA8BE9FE8A143784AEF29D7

• BypaasaUpdate.bat

973A02FF597864E3920ED1041D24D629A0762CDE932EB69AEA066CD2235404F8

• Pe.txt descodificado (AMSI Patcher)

1DA9428DF9A04E6CA1D836D1E941B61E30B6AF952D24D7B451A8D1E906ECE0C0

• 1.txt descodificado (AsyncRAT)

E7C482E66EFA99EA98E2C79BEB0A31C5120B73E4951A5F33133066B17E009DA1

• logs.ldr

A4BF71F97C3A2F3FDA496D204B5E744D6F1DA8D888ACE3867DA08D072AF01245

• logs.ldk

6FA549F446A541856784695DB808DE2E5C67DA271C64ECC966C7C0B02622D58B

• Logs.ldr (descodificado)

10EEB21202E7EB055F9FAC37DAB96F86DFEB9F28C0510F33E4324D12087CACF2

• Logs.ldk (descodificado)

6AE546DA4D6D78D4262F3A2FF5E4F58C345294383ED9FF5E4DAA52466FE79E2F

• Powershell RAT

B82E616E956A956FF5D9AFFCC13C907CF5054439FB5EE5A6F7AA5FFEE030DA56

• NvContainerRecovery.ps1

EF66D80511CD46C5173BF13E750C51114EE891E833F4F256A23E7DE4790ACC73

• PureHVNC RAT

068504CB4AC18D504247EF7A2C19A76B17A85E795B52E541FA8A49DE69B91F01