Entre el 25 y el 29 de septiembre de 2026, se detectó una intrusión vinculada al entorno de Viva Aerobus. Un grupo de hackers utilizó un Microsoft SQL Server como canal para ejecutar comandos y transferir archivos robados. Además, los atacantes expusieron accidentalmente sus propias herramientas de ataque y el material sustraído en un servidor público accesible para cualquier usuario de internet. La actividad incluyó la recolección de credenciales y el robo de código fuente.

Unos hackers convirtieron un servidor Microsoft SQL Server en un canal para ejecutar comandos y mover archivos recopilados en una intrusión vinculada a un entorno de Viva Aerobus. Su propio servidor, accesible públicamente, expuso posteriormente herramientas de ataque y material robado a usuarios de internet ajenos al caso.

La actividad, observada entre el 25 y el 29 de septiembre de 2026, incluyó la recolección de credenciales, la recopilación de código fuente y la preparación para acceder a sistemas adicionales.

La investigación no logró determinar cómo entraron los atacantes al entorno por primera vez ni identificar una familia de malware específica. Los registros disponibles describen un conjunto de herramientas en lugar de un único implante. Los investigadores de ThreatMon identificaron la infraestructura expuesta durante una búsqueda rutinaria de amenazas.

ThreatMon indicó en un informe que el servidor contenía 17 herramientas nombradas, ofreciendo una visión inusualmente detallada de la operación tras el compromiso inicial.

Los hallazgos revelan una segunda exposición superpuesta a la intrusión original, pero no una brecha confirmada de datos de pasajeros. Los investigadores no encontraron pruebas que demuestren el acceso exitoso a sistemas adicionales o el robo de datos sensibles de pasajeros, pagos o datos comerciales equivalentes.

Convirtieron un servidor Microsoft SQL Server en un canal de comandos

Los atacantes utilizaron xp_cmdshell, una función de SQL Server que puede ejecutar comandos del sistema operativo cuando está habilitada. Las herramientas recuperadas enviaban comandos de Windows y PowerShell codificado a través de sesiones de base de datos, permitiendo que el acceso a SQL se convirtiera en un canal operativo hacia el sistema Windows subyacente.

Este mecanismo se asemeja a casos anteriores de ataques a servidores SQL, donde el acceso a la base de datos permitía ejecutar comandos fuera de la propia base de datos.

Aquí, sin embargo, la evidencia recuperada describe la actividad posterior al compromiso, en lugar de probar una vulnerabilidad particular, un ataque de contraseñas u otro método de entrada inicial.

La misma conexión de base de datos también podía transportar archivos hacia el exterior. Las herramientas recuperadas leían el contenido de los archivos, los dividían en fragmentos más pequeños, convertían esos fragmentos en texto Base64 y los devolvían a través de la salida de la consulta SQL en lugar de abrir un canal de comunicación independiente.

Base64 es una forma de representar datos como texto, no es un cifrado. En este flujo de trabajo, hizo que el contenido de los archivos fuera transferible a través de las respuestas de la base de datos. Por lo tanto, una conexión utilizada para enviar comandos también podía devolver información recopilada sin requerir un servidor de control de malware convencional.

El peligro de la ejecución de comandos en bases de datos también ha aparecido en casos de explotación de la aplicación Mjobtime, aunque ThreatMon no vinculó esta intrusión con dicho software. La similitud relevante es el uso de la funcionalidad de la base de datos para alcanzar el sistema operativo y ejecutar comandos.

Los registros HTTP mostraron la recuperación de un payload por parte del entorno víctima a las 16:20 del 25 de septiembre. Un host no relacionado exploró el servidor expuesto entre las 16:21 y las 16:23, seguido de otros hosts que recuperaron herramientas y artefactos recopilados entre las 18:04 y las 18:05.

Exposición de Credenciales

El conjunto de herramientas expuesto incluía scripts para recolectar credenciales de navegadores y de Windows, probar inicios de sesión de SQL y transferir archivos.

Los artefactos de Mimikatz mostraron actividad de volcado de credenciales, una técnica también vista en las campañas de robo de credenciales de HiddenGh0st, aunque no se estableció un vínculo entre ambas operaciones.

Los investigadores también recuperaron el historial de conexiones de SQL Server Management Studio, nombres de usuario de bases de datos y material de contraseñas guardadas protegidas por Windows DPAPI.

Estos registros podrían ayudar a los atacantes a identificar objetivos adicionales, pero su presencia no significa que cada contraseña guardada haya sido descifrada con éxito.

El código fuente y los archivos de configuración recopilados hacían referencia a conexiones de bases de datos, OAuth, correo electrónico, SFTP e integraciones de pago o reportes.

ThreatMon omitió los valores sensibles, nombres de host de la víctima, nombres de usuario y otro material privado en su publicación pública para evitar exponer secretos potencialmente reutilizables.

Las utilidades recuperadas probaron combinaciones de credenciales contra otros sistemas SQL y verificaron el acceso a carpetas administrativas de SMB.

La evidencia respalda los intentos de reutilizar credenciales y la preparación para moverse a través de la red, no la confirmación de que los atacantes hayan comprometido exitosamente esos sistemas adicionales.

Tú, como defensor, deberías revisar las conexiones de red históricas comparándolas con los indicadores publicados y buscar en los endpoints hashes coincidentes y el directorio de trabajo reportado.

El uso inesperado de xp_cmdshell, PowerShell codificado u operaciones de archivos inusuales bajo una cuenta de servicio de SQL Server justifican una investigación inmediata.

Las conexiones de base de datos guardadas y los registros de contraseñas también deben tratarse como información sensible. ThreatMon advirtió que las credenciales o secretos que llegaron al servidor de staging expuesto deben considerarse comprometidos, ya que terceras partes accedieron al material y el atacante original no fue necesariamente el único receptor.

Fuentes:
https://cybersecuritynews.com/hackers-turned-a-microsoft-sql-server/