Evolución de las amenazas informáticas en el segundo trimestre de 2024

Ataques selectivos

XZ backdoor: Un emergente ataque contra la cadena de suministro

El 29 de marzo, un mensaje en la lista de correo Openwall OSS-security señalaba el descubrimiento de una puerta trasera en XZ, una utilidad de compresión integrada en muchas distribuciones populares de Linux. La biblioteca backdoored es utilizada por el proceso sshd del servidor OpenSSH. En varias distribuciones basadas en systemd, como Ubuntu, Debian y RedHat/Fedora Linux, OpenSSH está parchado para utilizar las características de systemd, y por lo tanto está ligado a esta biblioteca (Arch Linux y Gentoo no están afectados). El código fue insertado en febrero y marzo de 2024, principalmente por Jia Cheong Tan, una identidad quizá ficticia. Creemos que el objetivo del ataque era introducir la capacidad exclusiva de ejecución remota del código en el proceso sshd atacando el proceso de compilación de XZ; y luego distribuir el código oculto a las principales distribuciones de Linux como parte de un ataque a gran escala a la cadena de suministro.

Cronología de los acontecimientos
2024.01.19 El sitio web de XZ es trasladado a las páginas de GitHub por un nuevo responsable (jiaT75)
2024.02.15 “build-to-host.m4” se añade a .gitignore
2024.02.23 se introducen dos “archivos de prueba” que contenían las etapas del script malicioso
2024.02.24 Lanzamiento de XZ 5.6.0
2024.02.26 commit en CMakeLists.txt que sabotea la función de seguridad Landlock
2024.03.04 la puerta trasera conduce a problemas con Valgrind
2024.03.09 se actualizan dos “archivos de prueba”, se modifican las funciones CRC, se “arregla” el problema de Valgrind
2024.03.09 Lanzamiento de XZ 5.6.1
Se descubre un fallo en 2024.03.28, Debian y RedHat notificados
2024.03.28 Debian retrotrae la versión XZ 5.6.1 a la 5.4.5-0.2
2024.03.29 se publica un correo electrónico en la lista de correo OSS-security
2024.03.29 RedHat confirma que Fedora Rawhide y Fedora Linux 40 beta incluían el backdoored XZ
2024.03.30 Debian cierra las compilaciones e inicia el proceso para reconstruirlas
2024.04.02 El desarrollador principal del XZ reconoce el incidente de la puerta trasera

A diferencia de los ataques anteriores a la cadena de suministro que hemos visto en Node.js, PyPI, FDroid y el Kernel de Linux, que consistían principalmente en parches maliciosos atómicos, paquetes falsos y nombres de paquetes con errores tipográficos, este incidente fue una operación de varias etapas que casi logró comprometer servidores SSH a nivel mundial.

La puerta trasera en la biblioteca liblzma se introdujo en dos niveles. El código fuente de la infraestructura de compilación que generaba los paquetes finales se modificó ligeramente (introduciendo un archivo adicional build-to-host.m4) para extraer el script de la siguiente etapa que estaba oculto en un archivo de prueba(bad-3-corrupt_lzma2.xz). A su vez, este script extraía un componente binario malicioso de otro archivo de prueba (good-large_compressed.lzma) que se enlazaba con la biblioteca legítima durante el proceso de compilación para ser enviado a los repositorios de Linux. A su vez, los principales proveedores distribuyeron el componente malicioso en versiones beta y experimentales. Al compromiso de XZ se le asignó el identificador CVE-2024-3094 y se le dio una puntuación de gravedad máxima de 10.

El objetivo inicial de los atacantes era enganchar con éxito una de las funciones relacionadas con la manipulación de claves RSA. En nuestro análisis del proceso hook, nos enfocamos en el comportamiento del backdoor dentro de OpenSSH, concretamente la versión 9.7p1 OpenSSH portable (la más reciente). Nuestro análisis reveló una serie de detalles interesantes sobre la funcionalidad del backdoor.

• El atacante estableció una función antirrepetición para evitar la posible captura o secuestro de la comunicación de la puerta trasera.
• El autor utilizó una técnica de esteganografía personalizada en el código x86 para ocultar la clave pública.
• El backdoor engancha la función de registro para ocultar sus registros de conexiones no autorizadas al servidor SSH.
• El backdoor engancha la función de autenticación de contraseña para permitir al atacante utilizar cualquier nombre de usuario/contraseña para iniciar sesión en el servidor infectado sin más comprobaciones. Lo mismo ocurre con la autenticación de clave pública.
• El backdoor tiene capacidades de ejecución remota del código que permiten al atacante ejecutar cualquier comando del sistema en el servidor infectado.

Queda claro que se trata de una amenaza muy sofisticada. Los atacantes utilizaron la ingeniería social para obtener un acceso prolongado al entorno de desarrollo y lo extendieron mediante interacciones humanas ficticias a plena vista. Disponen de amplios conocimientos sobre el funcionamiento interno de proyectos de código abierto como SSH y libc, así como de experiencia en la ofuscación de código/script utilizada para iniciar el proceso de infección. Varias cosas hacen de esta amenaza algo único, como la forma en que la información de la clave pública está incrustada en el propio código binario, lo que complica el proceso de recuperación, y la meticulosa preparación de la operación.

Los productos de Kaspersky detectan objetos maliciosos asociados al ataque como HEUR:Trojan.Script.XZ y Trojan.Shell.XZ. Además, Kaspersky Endpoint Security for Linux detecta códigos maliciosos en la memoria del proceso sshd como MEM:Trojan.Linux.XZ (como parte de la tarea Análisis de áreas críticas).

Para más información, lea nuestro análisis inicial, la evaluación del incidente y el análisis en profundidad del gancho.

La campaña DuneQuixote apunta a Oriente Próximo

En febrero, descubrimos una nueva campaña de malware dirigida a entidades gubernamentales de Oriente Próximo a la que denominamos “DuneQuixote”. Nuestra investigación descubrió más de 30 muestras de droppers de DuneQuixote empleadas activamente en esta campaña. Algunos eran droppers normales, otros eran archivos de instalación manipulados de una herramienta legítima llamada “Total Commander”. Los droppers llevaban un código malicioso para descargar un backdoor que hemos bautizado como “CR4T”. Aunque sólo hemos identificado dos de estos implantes, creemos que podría haber otros en forma de un malware completamente distinto. El grupo detrás de la campaña tomó medidas para impedir la recopilación y el análisis de sus implantes e implementó métodos de evasión prácticos y bien diseñados tanto en las comunicaciones de red como en el código del malware.

El dropper inicial es un archivo ejecutable de Windows x64, escrito en C/C++, aunque también existen versiones DLL del malware que comparten la misma funcionalidad. Tras la ejecución, el malware inicia una serie de llamadas a la API señuelo que no tienen ningún propósito práctico. Estas llamadas implican principalmente funciones de comparación de cadenas, ejecutadas sin ningún salto condicional basado en los resultados de la comparación. Las cadenas especificadas en estas funciones son fragmentos de poemas en español. Varían de una muestra a otra, alterando así la firma de cada muestra para eludir la detección con metodologías de detección tradicionales.

El objetivo principal del implante CR4T es dar a los atacantes acceso a una consola para la ejecución de líneas de comandos en el ordenador infectado. También facilita la descarga, carga y modificación de archivos.

Además, descubrimos una versión Golang del implante CR4T, que comparte capacidades similares con la versión C. Una diferencia notable de esta versión es su capacidad para crear tareas programadas mediante la biblioteca Go-ole de  Golang, que utiliza interfaces de objetos del Modelo de Objetos Componentes de Windows (COM) para interactuar con el servicio Programador de tareas.

Mediante el despliegue de implantes de sólo memoria y droppers que se hacen pasar por software legítimo, imitando al instalador de Total Commander, los atacantes muestran superiores capacidades y técnicas de evasión. El descubrimiento de versiones tanto en C/C++ como en Golang del implante CR4T subraya la adaptabilidad y el ingenio del actor de la amenaza que está detrás de esta campaña.

ToddyCat: hacer agujeros en su infraestructura

La amenaza ToddyCat se dirige principalmente a organizaciones gubernamentales de la región Asia-Pacífico, sobre todo para robar datos confidenciales. En nuestro artículo anterior, describimos las herramientas que utilizan los atacantes para recopilar y extraer archivos (LoFiSe y PcExter). Hace poco, investigamos cómo este actor de la amenaza obtiene acceso constante a la infraestructura comprometida, la información que interesa a los atacantes y las herramientas que utilizan para extraerla.

Nuestra investigación reveló que ToddyCat había estado robando datos a escala industrial. Para robar grandes volúmenes de datos, los atacantes necesitan automatizar el proceso de recolección de datos en la medida de lo posible, y proporcionar varios medios alternativos para acceder y supervisar continuamente los sistemas que atacan.

ToddyCat utilizó varios métodos para conseguirlo. Una fue creando un túnel SSH inverso.

Para ello utilizaron el cliente SSH del kit de herramientas OpenSSH para Windows, junto con la biblioteca necesaria para ejecutarlo, un archivo de clave privada OPENSSH y un script, a.bat, para ocultar el archivo de clave privada. Los atacantes transfirieron archivos al host de destino a través de SMB con la ayuda de carpetas compartidas.

El actor de la amenaza también utilizó la utilidad de servidor (VPN Server) del paquete SoftEther VPN para crear los túneles. Este paquete es una solución de código abierto desarrollada como parte de la investigación académica en la Universidad de Tsukuba que permite la creación de conexiones VPN a través de muchos protocolos populares, como L2TP/IPsec, OpenVPN, MS-SSTP, L2TPv3, EtherIP y otros.

Otra forma en la que ToddyCat accedía a la infraestructura remota era mediante un túnel a un proveedor legítimo de la nube: una aplicación que se ejecuta en el host del usuario con acceso a la infraestructura local puede conectarse a través de un agente legítimo a la nube y redirigir el tráfico o ejecutar determinados comandos

Ngrok es un agente ligero capaz de redirigir el tráfico de los puntos finales a la infraestructura de la nube y viceversa. Los atacantes instalaron Ngrok en los hosts objetivo y lo utilizaron para redirigir el tráfico C2 (Mando y Control) desde la infraestructura de la nube hacia un puerto determinado de estos hosts.

También utilizaron Krong, un proxy que cifra los datos transmitidos a través suyo mediante la función XOR, ocultando el contenido del tráfico para eludir la detección.

Después de crear túneles en los hosts de destino utilizando OpenSSH o SoftEther VPN, el actor de la amenaza instaló adicionalmente el cliente FRP, un proxy inverso rápido escrito en Go que permite el acceso desde Internet a un servidor local situado detrás de un NAT o  un cortafuegos.

ToddyCat utilizó varias herramientas para recopilar los datos. Utilizaron una de las herramientas, que denominamos “cuthead” (el nombre procede del campo de descripción del archivo de la muestra que encontramos), para buscar documentos. Utilizaron “WAExp”, un ladrón de datos de WhatsApp, para buscar y recopilar archivos de almacenamiento local del navegador que contenían datos de la versión web de WhatsApp. También utilizaron una herramienta llamada “TomBerBil” para robar contraseñas de los navegadores.

Para protegerse contra este tipo de ataques, recomendamos que las organizaciones añadan los recursos y las direcciones IP de los servicios de nube que proporcionan túneles de tráfico a la lista de denegación de su cortafuegos. También recomendamos limitar la gama de herramientas que los administradores están autorizados a utilizar para acceder a los hosts de forma remota: cualquier otra herramienta debe ser prohibida o monitoreada a fondo como un posible indicador de actividad sospechosa. Además, los empleados deben evitar almacenar contraseñas en los navegadores, ya que esto ayuda a los atacantes a acceder a información crítica. Además, la reutilización de contraseñas en distintos servicios plantea el riesgo de que los atacantes dispongan de más datos.

Otros programas maliciosos

QakBot ataca con el día cero de Windows

A principios de abril, investigamos la vulnerabilidad de elevación de privilegios de la biblioteca central de Windows DWM (Desktop Window Manager) (CVE-2023-36033), que se había descubierto como un día cero explotado en el Internet. Mientras buscábamos muestras relacionadas con este exploit, y ataques que lo utilizasen, encontramos un curioso documento subido a VirusTotal el 1 de abril. Este documento llamó nuestra atención porque tenía un nombre de archivo descriptivo que indicaba que contenía información sobre una vulnerabilidad de Windows.

En su interior encontramos una breve descripción de una vulnerabilidad DWM de Windows y de cómo podría explotarse para obtener privilegios del sistema, todo ello escrito en pésimo inglés. El proceso de explotación descrito en este documento era idéntico al utilizado en el ya mencionado exploit de día cero para CVE-2023-36033, pero la vulnerabilidad era diferente.

La mala calidad de la redacción, y el hecho de que al documento le faltaran algunos detalles importantes sobre cómo activar realmente la vulnerabilidad, sugerían que la vulnerabilidad descrita era completamente inventada o estaba presente en un código al que los atacantes no podían acceder ni controlar.

Sin embargo, una comprobación rápida reveló que se trata de una verdadera vulnerabilidad de día cero que puede utilizarse para escalar privilegios, por lo que informamos rápidamente a Microsoft sobre nuestros hallazgos. La vulnerabilidad fue designada CVE-2024-30051 y se publicó un parche como parte del Martes de parches del 14 de mayo.

También empezamos a vigilar de cerca nuestras estadísticas en busca de exploits y ataques que aprovecharan este día cero, y a mediados de abril descubrimos un exploit. Hemos visto este día cero utilizado junto con QakBot y otro malware, y creemos que múltiples actores de amenazas tienen acceso a él.

Los productos de Kaspersky detectan la explotación de CVE-2024-30051 y malware relacionado con los siguientes veredictos:

• PDM:Exploit.Win32.Generic;
• PDM:Trojan.Win32.Generic.

Uso del creador de LockBit para generar ransomware selectivo

El año pasado publicamos nuestra investigación sobre el constructor LockBit 3.0. Filtrado en 2022, este constructor hizo que crear ransomware personalizado fuese mucho más fácil.

El archivokeygen.exe genera claves públicas y privadas que se utilizan para cifrar y descifrar. El archivo builder.exe genera la variante según las opciones establecidas en el archivoconfig.json. Todo el proceso se automatiza con el script build.bat.

El constructor también permite a los atacantes elegir exactamente lo que quieren cifrar. Si conocen la infraestructura del objetivo, pueden generar malware adaptado a la configuración específica de la arquitectura de red del objetivo, como archivos importantes, cuentas administrativas y sistemas críticos.

Esto les ha permitido a los atacantes generar versiones personalizadas de esta amenaza según sus necesidades, logrando así ataques más eficaces.

En febrero, el grupo policial de tarea internacional, Operation Cronos, consiguió conocer las operaciones de LockBit tras desmantelar el grupo. En esta acción participaron organismos policiales de 10 países. Se logró incautar la infraestructura del grupo, obtener claves de descifrado privadas y preparar un conjunto de herramientas de descifrado basado en una lista de identificación de víctimas conocidas. Sin embargo, pocos días después, el grupo de ransomware anunció que volvía a la acción.

En una reciente intervención de respuesta a incidentes, nos enfrentamos a un ataque de ransomware que implicaba una muestra de ransomware creada con el mismo creador filtrado. Los atacantes fueron capaces de encontrar las credenciales de administrador en texto plano. Generaron una versión personalizada del ransomware que utilizó esta credencial de cuenta para propagarse por la red y realizar actividades maliciosas, como eliminar Windows Defender y borrar los registros de eventos de Windows con el fin de cifrar los datos y cubrir sus huellas. En nuestro último artículo, volvimos a examinar los archivos del constructor de LockBit 3.0 y analizamos los pasos que siguieron los atacantes para infectar la red.

Stealers, stealers y más stealers

Los stealers ocupan un lugar destacado en el panorama de las amenazas. Su objetivo es recopilar contraseñas y otros datos confidenciales de los ordenadores infectados que pueden utilizarse posteriormente en otros ataques, con las consiguientes pérdidas económicas para las víctimas. En el último año hemos publicado varios informes públicos y privados sobre ladrones recién descubiertos. Recientemente, escribimos informes sobre Acrid, ScarletStealer y Sys01: los dos primeros son nuevos, el último ha sido actualizado.

Acrid, un nuevo stealer descubierto en diciembre de 2023, está escrito en C++ para sistemas de 32 bits, a pesar de que la mayoría de los sistemas son ahora de 64 bits. Tras una inspección más detallada, quedó claro que los autores lo habían compilado para un entorno de 32 bits con el fin de utilizar la técnica “Heaven’s Gate”, que permite a las aplicaciones de 32 bits acceder al espacio de 64 bits para eludir determinados controles de seguridad. Este malware está diseñado para robar datos del navegador, monederos locales de criptomonedas, archivos con nombres específicos(wallet.dat, password.docx, etc.) y credenciales de aplicaciones instaladas (gestores FTP, mensajeros, etc.). Los datos recogidos se comprimen y se envían al C2.

El pasado mes de enero, analizamos un descargador al que apodamos “Penguish”. Uno de los payloads que descargaba era un ladrón desconocido hasta entonces llamado “ScarletStealer”, un ladrón extraño, ya que la mayor parte de su funcionalidad está contenida en otros binarios (aplicaciones y extensiones de Chrome) que descarga. Cuando se ejecuta ScarletStealer, verifica la presencia de criptomonedas y criptocarteras comprobando determinadas rutas de carpetas (por ejemplo, %APPDATA%\Roaming\Exodus). Si se detecta algo, comienza a descargar los ejecutables adicionales mediante PowerShell. La mayoría de los ejecutables de ScarletStealer tiene firma digital. Este ladrón está muy poco desarrollado en términos de funcionalidad y contiene muchos errores, fallos y código redundante. Dado el esfuerzo que supone instalar este malware a través de una larga cadena de descargadores, de los cuales el último es Penguish, resulta extraño que no sea más avanzado.

SYS01 (también conocido como Album Stealer y S1deload Stealer), un malware relativamente desconocido que existe desde al menos 2022, ha evolucionado de un stealer de C# a un stealer de PHP. Algo que no ha cambiado es el vector de infección. Se engaña a los usuarios para que descarguen un archivo ZIP malicioso camuflado como video para adultos a través de una página de Facebook.

El archivo contiene un binario legítimo que carga una DLL maliciosa. Esta DLL abre un video para adultos y ejecuta la siguiente carga útil, que es un archivo PHP malicioso codificado con ionCube. El archivo PHP ejecutado llama a un script, install.bat, que en última instancia ejecuta la siguiente etapa mediante la ejecución de un comando PowerShell. Esta capa se llama convenientemente “runalayer” y ejecuta lo que parece ser la carga útil final llamada “Newb”. Sin embargo, hemos encontrado una diferencia entre la última versión y las versiones anteriores del ladrón divulgadas públicamente. El stealer actual (Newb) contiene funcionalidades para robar datos relacionados con Facebook y enviar los datos robados del navegador al C2. También incluye funciones de puerta trasera. Pero encontramos que el código que realmente recoge los datos del navegador enviados por Newb en una muestra diferente, se llama “imageclass”. No está muy claro cómo se introdujo imageclass en el sistema, pero observando el código backdoor de Newb, concluimos con un alto grado de certeza que imageclass se introdujo posteriormente a través de Newb en la máquina infectada. El archivo ZIP inicial también contiene otro archivo PHP malicioso, include.php: tiene una funcionalidad de puerta trasera similar a la de Newb y acepta muchos de los mismos comandos en el mismo formato.

ShrinkLocker: convertir BitLocker en un ransomware

En una reciente intervención de respuesta a incidentes, descubrimos un ransomware, denominado “ShrinkLocker”, que utiliza BitLocker para cifrar los equipos comprometidos. BitLocker es la utilidad de cifrado de disco completo integrada en Windows, diseñada para evitar la exposición de datos de equipos perdidos o robados.

ShrinkLocker se implementa como un complejo VBScript. Si el script determina que se está ejecutando en Windows 2000, XP, 2003 o Vista, se apaga. Pero para versiones posteriores de Windows, ejecuta la parte relevante de su código para el sistema operativo específico. ShrinkLocker reduce las particiones del disco duro del ordenador en 100 MB y utiliza este espacio sobrante para crear una partición de arranque para sí mismo. El malware modificaba el registro para configurar BitLocker de forma que se ejecutara con la configuración del atacante. A continuación, desactiva y elimina todos los protectores predeterminados de BitLocker para evitar la recuperación de claves y activa la opción de protección con contraseña numérica. Después, el script genera esta contraseña e inicia el cifrado de todas las unidades locales, antes de enviar la contraseña y la información del sistema al servidor C2 del atacante. Finalmente, el malware se borra a sí mismo y reinicia el sistema.

Si el usuario intenta utilizar la opción de recuperación mientras la máquina se está iniciando, verá un mensaje indicando que no hay opciones de recuperación de BitLocker disponibles.

ShrinkLocker cambia las etiquetas de todas las unidades del sistema a la dirección de correo electrónico del atacante en lugar de dejar una nota de rescate.

Puede leer nuestro análisis completo de ShrinkLocker aquí.