Ciberataque Avanzado: Compilación de "khunt" en Oracle para Escalada de Privilegios a Nivel SYSTEM en Windows

Imagen generada por IA

 

Un reciente incidente de seguridad ha puesto de manifiesto una técnica de ataque sofisticada y preocupante, donde actores maliciosos lograron comprometer la infraestructura de una organización explotando una vulnerabilidad de SQL Injection en una aplicación web pública. El impacto de esta brecha se magnificó al permitir la instalación y ejecución de un conjunto de herramientas de post-explotación, denominado khunt por Huntress, sin dejar rastro de archivos ejecutables en el sistema de archivos del servidor Windows subyacente. La explotación culminó con la obtención de acceso a nivel de privilegios SYSTEM.

Contexto Técnico del Hecho Principal

La cadena de ataque se inició con una vulnerabilidad de SQL Injection presente en una aplicación web de cara al público. Un campo de búsqueda con funcionalidad de autocompletado en la aplicación procesaba entradas no validadas, transmitiéndolas a la base de datos Oracle a través de una conexión Java Database Connectivity (JDBC). La cuenta de base de datos utilizada para esta conexión poseía privilegios suficientes para la creación de objetos de esquema de Java dentro de la base de datos. Los atacantes aprovecharon esta capacidad para inyectar código fuente de Java directamente en la base de datos. Oracle, a su vez, compiló este código fuente inyectado, almacenándolo como objetos de esquema dentro de la base de datos. Posteriormente, los comandos maliciosos se ejecutaron desde el propio motor de la base de datos.

Análisis Técnico Profundo

La técnica empleada se basa en la capacidad de Oracle Database para compilar y ejecutar código Java embebido. Mediante la sentencia CREATE JAVA SOURCE, un usuario con los permisos adecuados puede introducir código fuente de Java que la base de datos compila y almacena internamente como un objeto de esquema. Este objeto, al no ser un proceso ni un archivo en el sistema de archivos, escapa a la inspección de muchas soluciones de Endpoint Detection and Response (EDR) convencionales. La base de datos, en lugar de ser un simple repositorio de datos consultado, se transforma en un punto de partida estratégico para el atacante.

La documentación de Oracle indica que la creación de un objeto de esquema de Java, dentro del esquema de un usuario, requiere un único privilegio del sistema: CREATE PROCEDURE. Sin embargo, la ejecución de un proceso del sistema operativo a partir de dicho código se realiza a través de Runtime.exec, una operación que demanda un permiso de ejecución de archivos específico. Oracle especifica que estos permisos solo son otorgados por administradores con altos privilegios. En el incidente investigado por Huntress, la cuenta comprometida debió poseer los privilegios necesarios, ya sea de forma preexistente o mediante elevación, para permitir la ejecución de comandos del sistema operativo y la posterior manipulación de datos críticos.

Este método de ataque, si bien su uso activo y documentado es escaso en la actualidad, no es novedoso. Una técnica similar fue descrita en 2006 por Marco Ivaldi con la herramienta raptor_oraexec.sql, la cual creaba objetos de origen de Oracle con funcionalidades de ejecución de comandos y lectura de archivos, expuestos a través de "wrappers" de PL/SQL. Los objetos del toolkit khunt observados en este incidente siguen una arquitectura base comparable. El toolkit khunt estaba compuesto por seis objetos Java y varios "wrappers" de PL/SQL (khunt_*):

1. KhuntCmd: Cargaba cmd.exe y ejecutaba comandos arbitrarios del sistema operativo que se pasaban como parámetros SQL.

2. KhuntUnzip: Descomprimía archivos de archivo. La ejecución de cmd.exe /c whoami a través de KhuntCmd retornó SYSTEM , confirmando la máxima elevación de privilegios. Posteriormente, los atacantes utilizaron PowerShell y reg.exe para copiar las colmenas de registro SECURITY y SYSTEM a una ubicación en el disco (F:\Oracle). También ejecutaron tasklist /svc para listar servicios y copiaron las colmenas SAM y SECURITY utilizando esentutl.exe.

Huntress observó que los archivos eran preparados localmente, pero no pudo confirmar la exfiltración de datos. La firma de seguridad no atribuyó el ataque a un actor de amenaza específico, aunque rastreó las solicitudes maliciosas hasta una dirección IP.

Implicaciones Empresariales

Este incidente subraya un riesgo operativo relevante: la explotación de vulnerabilidades en capas de aplicación para obtener acceso profundo a la infraestructura subyacente. La ejecución de código sin escribir archivos en disco presenta un desafío significativo para la detección basada en firmas o análisis de comportamiento de archivos en endpoints. Las organizaciones que dependen de bases de datos Oracle y exponen aplicaciones web con conectividad JDBC deben considerar la seguridad de sus conexiones y los privilegios asociados a las cuentas de servicio.

La ausencia de un parche específico para Oracle que aborde esta técnica, dado que reside en la capacidad intrínseca de la base de datos para compilar Java y la configuración de privilegios de las cuentas de aplicación, significa que la mitigación recae en prácticas de desarrollo seguro y administración de bases de datos rigurosas.

Tabla Analítica Comparativa: Técnicas de Ataque y Mitigación

Aspecto	Descripción	Impacto Potencial	Estrategia de Mitigación
SQL Injection (Aplicación Web)	Entrada de datos no validada que manipula consultas SQL.	Acceso a datos sensibles, ejecución de comandos en la base de datos.	Consultas parametrizadas, validación de entrada robusta en la aplicación.
Creación de Objetos Java en Oracle	Compilación y almacenamiento de código Java como objetos de esquema.	Ejecución de código arbitrario desde el motor de la base de datos, evasión de EDR.	Restricción del privilegio CREATE JAVA SOURCE, monitoreo de actividades de creación de objetos.
Ejecución de Procesos OS (Runtime.exec)	Capacidad de un código Java dentro de Oracle para iniciar procesos del sistema operativo.	Escalada de privilegios a nivel SYSTEM, acceso completo al servidor.	Aplicación del principio de mínimo privilegio para cuentas de base de datos, auditoría de permisos de ejecución de procesos.
Post-Explotación con khunt	Uso de un toolkit para comando y control, exfiltración de datos y manipulación del sistema.	Persistencia, movimiento lateral, robo de credenciales, acceso a información sensible del sistema (hashes SAM/SECURITY).	Monitoreo de patrones de acceso a esquemas específicos (khunt%), análisis de logs de SQL, identificación de objetos de esquema sospechosos.

Buenas Prácticas

Las organizaciones deben implementar un enfoque de defensa en profundidad que aborde tanto la seguridad de las aplicaciones como la protección de la infraestructura de bases de datos:

1. Validación de Entrada y Consultas Parametrizadas: Asegurar que toda la entrada de usuario sea validada rigurosamente en la capa de aplicación y utilizar consultas parametrizadas para prevenir vulnerabilidades de SQL Injection.

2. Detección Avanzada de Amenazas: Utilizar soluciones de seguridad que tengan la capacidad de monitorear la actividad interna de la base de datos, si es posible, o complementar la protección de endpoints con herramientas de análisis de comportamiento en la red.

Perspectiva MaclaTech

Nuestros análisis técnicos y estratégicos para organizaciones suelen enfocarse en:

1. Identificación de capacidades críticas relacionadas con la seguridad de la capa de aplicación y la base de datos.

2. Análisis de impacto operativo y continuidad tecnológica ante eventos de compromiso de datos o infraestructura.

Muchas organizaciones identifican vulnerabilidades críticas o dependencias de acceso únicamente cuando ocurre un incidente, interrupción o evento que afecta la operación.

¿Podría su organización identificar los vectores de acceso no autorizados a su base de datos antes de que un atacante los explote?

Conozca el nivel de riesgo de su organización

Conclusión

La técnica de ataque observada, que utiliza la compilación de código Java dentro de Oracle Database para obtener acceso a nivel de SYSTEM en un servidor Windows, es una clara demostración de cómo las capacidades legítimas de una plataforma tecnológica pueden ser abusadas. La ausencia de escritura de archivos ejecutables en disco complica la detección, haciendo imperativo que las organizaciones refuercen sus defensas en las capas de aplicación y base de datos mediante la aplicación estricta de principios de seguridad, monitoreo proactivo y una arquitectura robusta.

Fuentes

1. Attackers Compile khunt Inside Oracle to Turn SQL Injection Into Windows SYSTEM Access. (6 de agosto de 2026).

   The Hacker News. Recuperado de https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle.html

2. The five-step guide to SQL tuning | CloudWorld 2022 [Video]. (2022).

   YouTube. Recuperado de https://www.youtube.com/watch?v=bV8SmHo9B3w