Explotación cambiaria: aún no ha muerto


La explotación masiva de los servidores Trade ha sido una llamada de atención, y será necesario que todas las partes actúen en concierto para que la industria reaccione, responda y se recupere.

«March Madness» es un apodo jovial para el tercer mes del año, pero en 2021, la industria de la ciberseguridad sintió la peor parte de la locura de marzo por una razón distinta al baloncesto: la explotación masiva de los servidores Microsoft Trade. Casi dos meses después, todavía vivimos las secuelas de este incidente generalizado.

El 1 de marzo, Huntress se enteró de las nuevas vulnerabilidades que ofrecerían a un actor no autorizado el control full de un servidor de Microsoft Exchange. Estas vulnerabilidades aún no se revelaron, pero las organizaciones empresariales y las pequeñas y medianas empresas ya estaban siendo explotadas. El 2 de marzo, Microsoft publicó su primer aviso de seguridad, advirtiendo a las empresas sobre estas peligrosas vulnerabilidades. Desafortunadamente, parecía que el anuncio inicial de Microsoft no acertó.

Lo que se denominó «Exchange Marauder», que Microsoft describió originalmente como «limitado y específico (en su alcance)», sin embargo, prácticamente todas las versiones de Exchange eran vulnerables, y estos servidores se enfrentan públicamente en la Internet abierta. Si bien los servidores en la nube no se vieron afectados y solo las instalaciones locales de Exchange fueron susceptibles a este ataque, pronto se supo que más de 30,000 organizaciones solo en los EE. UU. Se vieron afectadas.

Algunos expertos dicen que los ataques que usan estas vulnerabilidades comenzaron el 6 de enero. Un exploit exitoso encadenó múltiples vulnerabilidades para eventualmente obtener ejecución remota de código (RCE) en el host de destino colocando un «Web shell» en una ubicación de acceso público. Estos shells world wide web eran archivos únicos que procesarían y evaluarían el código en el servidor mismo y permitirían a cualquiera que conociera la clave o parámetro específico ejecutar comandos y controlar completamente la máquina como usuario administrativo.

Los primeros días del mes estuvieron llenos de caos e incertidumbre. Era difícil determinar si los parches iniciales que lanzó Microsoft estaban en vigor, y si había presencia de algún shell world-wide-web, ya estaba comprometido y el parche no ayudaría. La industria de la ciberseguridad se volvió rudimentaria: notificábamos a las personas a través de Reddit, realizamos búsquedas de amenazas e inteligencia en Twitter, compartíamos indicadores de compromiso en GitHub y Pastebin … cualquiera que fuera el método más rápido para difundir información.

Mientras la industria gritaba desde los tejados para parchear, parchear, parchear, también queríamos contribuir a la inteligencia de amenazas y ayudar a informar a las organizaciones sobre posibles indicadores de compromiso (IoC). El IoC más flagrante es un shell world-wide-web en sí mismo. Estos shells world-wide-web siguen la estructura de un «China Chopper», un apodo dado a un estilo de sintaxis very simple y minimalista para ejecutar un comando proporcionado como parte de la solicitud website.

Por lo general, estos se encuentran en el directorio o subdirectorios C: inetpub wwwroot aspnet_consumer, con nombres de archivo desconocidos o aleatorios y una extensión .aspx. (Hemos visto una gran cantidad de variaciones en estos shells website y los hemos estado archivando aquí.)

Inicialmente, estos shells website parecían pasar por alto la mayoría de los antivirus (AV), detección y respuesta de endpoints (EDR) o soluciones de seguridad preventiva.

Un extracto de nuestros shells web inventariados, que indica el nombre del archivo, cuándo se modificó y el software de seguridad preventiva instalado en el host. Las marcas de tiempo indicadas en rojo son nuestro primer compromiso identificado, días antes del informe inicial de Microsoft. Crédito: Cazadora

Un extracto de nuestros shells world-wide-web inventariados, que indica el nombre del archivo, cuándo se modificó y el program de seguridad preventiva instalado en el host. Las marcas de tiempo indicadas en rojo son nuestro primer compromiso identificado, días antes del informe inicial de Microsoft. Crédito: Cazadora

La prevención es difícil. Ahora, casi todos los productos AV y EDR se adelantarán a esto. Sin embargo, muestra que esta pequeña y easy sintaxis se escapó y sacudió la industria.

Una vez que el shell world-wide-web está en su lugar y los actores de amenazas han obtenido acceso, la pregunta es «¿qué harán a continuación?» ¿Qué pasa con estos objetivos y víctimas después del compromiso? Si bien los piratas informáticos tienen acceso administrativo completo, podrían lanzar ransomware, convertir esta máquina en una botnet, desfigurar los sitios web de la víctima, robar y vender datos … lo que quisieran.

Desde entonces, hemos visto indicadores de ransomware dirigidos a estos servidores Trade comprometidos denominados «DearCry». DearCry utiliza criptografía AES y RSA y deja los archivos cifrados con un «¡DEARCRY!» encabezado en la parte exceptional del contenido del archivo.

Sorprendentemente, más a menudo que el ransomware es evidencia de mineros de criptomonedas. Una antigua familia de malware de criptominería, «LemonDuck», ha resurgido.

LemonDuck se esconde a través de múltiples cargas útiles ofuscadas, pero united states RSA para validar cada etapa. Si bien hay muchos dominios e IoC asociados con LemonDuck, el más frecuente que Huntress ha visto en marzo ha sido http (:) // t (.) Zker9 (.) Com y http (:) // t (. ) dominios zz3r0 (.) com.

Un punto de apoyo persistente de LemonDuck united states of america PowerShell para descargar otro programador y lo valida con RSA.

Un truco inteligente que usan los stagers como este es agregar la fecha u hora true como una variable al solicitar datos de un servidor externo. Esto evita el almacenamiento en caché HTTP y garantiza que el contenido que se recibe sea siempre la última copia.

Luego, el código descargado se ejecuta con técnicas de «malware sin archivos» utilizando la sintaxis IEX, un alias de PowerShell para «Invoke-Expression» que evalúa el código sobre la marcha. La siguiente capa de código que extrae ejecuta otra etapa en la memoria, que se ofusca mediante el uso de cadenas invertidas. Todas estas técnicas son intentos de que este malware no sea detectado por soluciones automatizadas o productos AV / EDR.

Después de seis etapas de ofuscación, vemos el código fuente sin procesar de este malware LemonDuck escrito en PowerShell. Comprueba la arquitectura de la víctima, detecta el tipo de procesador y descarga el software program de minería adecuado. LemonDuck instala su propia persistencia para que pueda continuar ejecutándose al reiniciar y limita los recursos de la computadora para ganar más dinero para el atacante.

Desafortunadamente, alrededor del 6% de los servidores Trade de hoy no han sido parcheados y siguen siendo vulnerables. Estos exploits pueden resultar en un compromiso de dominio completo y no se pueden tomar a la ligera.

Microsoft ha publicado su Actualización de seguridad de abril, que revela vulnerabilidades aún más críticas contra Exchange. Al parecer, estas vulnerabilidades se han explotado en la naturaleza, pero el ímpetu para parchear debería ser el mismo que en marzo. Dos de estas nuevas vulnerabilidades no requieren autenticación y pueden activarse sin la interacción del usuario, obteniendo finalmente el RCE del atacante. Estas vulnerabilidades son graves y no deben pasarse por alto. Los cazadores de amenazas y los investigadores de seguridad continuarán monitoreando cualquier IoC y compartiendo nueva información a medida que se publique.

No podemos confiar solo en soluciones automatizadas. La automatización es divina, pero el análisis guide y la investigación humana son imprescindibles. Los proyectiles de China Chopper Net pasaron desapercibidos, el malware posterior al acceso y los troyanos continúan eludiendo las defensas con ingeniosas técnicas de ocultación y evasión, y esta investigación requiere contexto y experiencia por parte de los profesionales de la seguridad. Si bien la explotación masiva de los servidores Trade ha sido una llamada de atención, se necesitan todas las partes para que la industria reaccione, responda y se recupere.

John Hammond es investigador de seguridad en Huntress, así como instructor de ciberseguridad, desarrollador, equipo rojo y entusiasta de CTF. John es un ex desarrollador del program de estudios de la Academia de Entrenamiento Cibernético del Departamento de Defensa y profesor del curso de Emulación de Amenazas Cibernéticas, educando … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia original