Ataque Khunt: Hackers convierten una base de datos Oracle en una plataforma de ataque invisible

El kit Khunt: Viviendo dentro de la base de datos como objetos Java

En lugar de implementar archivos de malware tradicionales en el servidor comprometido, los atacantes utilizaron la Máquina Virtual Java (JVM) integrada de Oracle y la instrucción CREATE JAVA SOURCE para compilar y almacenar todo el kit de herramientas de post-explotación como objetos de esquema Java dentro de la base de datos Oracle . Este enfoque hizo que el kit fuera invisible para las defensas estándar a nivel del sistema operativo, ya que las herramientas EDR y antivirus se centran en procesos, binarios y archivos en el sistema operativo; por lo general, no inspeccionan las clases Java y los wrappers PL/SQL almacenados dentro de Oracle .

El kit khunt incluía estos componentes, cada uno almacenado como un objeto de base de datos:

Logrando el control total del sistema: De la base de datos al sistema operativo Windows

Los atacantes no se detuvieron en el acceso a nivel de base de datos. Utilizaron el kit khunt para pivotar desde la capa de la base de datos al sistema operativo Windows subyacente en un proceso de varios pasos:

1. Ejecución de comandos del SO a través de KhuntCmd: Usaron el módulo KhuntCmd para ejecutar cmd.exe /c whoami, lo que confirmó que se estaban ejecutando con privilegios de nivel SYSTEM en el servidor Windows, estableciendo una ejecución remota de código (RCE) desde la base de datos al sistema operativo .
2. Robo de credenciales: Usaron PowerShell para invocar reg.exe y copiar los archivos del registro SECURITY y SYSTEM, guardándolos como khuntSECURITY.hiv y khuntSYSTEM.hiv en F:\Oracle\ .
3. Enumeración de servicios: Ejecutaron tasklist /svc y guardaron la salida como khunttasks.txt .
4. Extracción adicional de archivos del registro: Usaron esentutl.exe para copiar los archivos SAM y una segunda copia de SECURITY, guardándolos como khuntSAM.hiv y khunt_SECURITY.hiv .

Los archivos del registro exfiltrados podrían usarse sin conexión para extraer y decodificar los hashes de contraseñas de todas las cuentas locales del sistema .

Puntos ciegos en la defensa: Hallazgos clave de Huntress

La investigación de Huntress reveló varios puntos ciegos críticos que permitieron que este ataque tuviera éxito y evadiera la detección:

• La base de datos como plataforma de ataque: La base de datos se transformó de un almacén de datos pasivo a una plataforma de ataque activa, con el kit malicioso viviendo dentro de la base de datos en lugar de en el disco o en la memoria .
• Evasión de EDR/AV: Las herramientas tradicionales de detección y respuesta en endpoints (EDR) y antivirus no inspeccionan las clases Java y los wrappers PL/SQL almacenados dentro de Oracle, lo que hace que el kit sea invisible para las defensas estándar a nivel del sistema operativo .
• Vulnerabilidad clásica, entrega novedosa: La inyección SQL inicial era una clase de error bien conocida. No se necesitó ningún día cero. La función de búsqueda con autocompletado fue suficiente para llegar a PL/SQL y luego al sistema operativo, lo que demuestra que los fallos básicos de validación de entrada pueden llevar a un compromiso profundo cuando el motor de la base de datos tiene capacidades a nivel de sistema operativo .
• Cuentas de base de datos con privilegios excesivos: Incluso después de que una inyección SQL tiene éxito, el daño es limitado si la cuenta de usuario de la base de datos no tiene privilegios para crear fuentes Java o ejecutar procedimientos almacenados. Las organizaciones a menudo otorgan privilegios excesivos a las cuentas de la base de datos, dando a los atacantes los permisos adicionales necesarios para implementar khunt .

Mitigaciones recomendadas por Huntress

Basándose en este ataque, Huntress recomendó varias mitigaciones :

• Sanitización adecuada de entradas y parametrización de consultas para todas las entradas web
• Restringir los privilegios de los usuarios de la base de datos para que incluso las consultas inyectadas no puedan crear fuentes Java o ejecutar procedimientos almacenados arbitrarios
• Ampliar el alcance de la monitorización para incluir objetos de la base de datos (clases Java, wrappers PL/SQL) en lugar de solo artefactos a nivel del sistema operativo

Este ataque sirve como un claro recordatorio de que los motores de base de datos con entornos de programación integrados (como la JVM de Oracle) pueden convertirse en plataformas de ataque sigilosas cuando se combinan con un solo campo de entrada no validado. Los equipos de seguridad deben extender su monitorización más allá del sistema operativo para incluir la capa de objetos de la base de datos.