Una inyección SQL en Oracle puede ser mucho más que una puerta de entrada para leer o alterar datos. En el caso investigado recientemente, el ataque recorrió una cadena completa: comenzó con una vulnerabilidad en una aplicación web pública, continuó con la compilación de código Java dentro de la base de datos y terminó con ejecución de comandos con privilegios SYSTEM en el servidor Windows.
El punto diferencial fue que los atacantes no “plantaron” binarios en el disco del endpoint. En lugar de eso, aprovecharon mecanismos de Oracle para que la propia base compilara y almacenara objetos que, luego, actuaron como una plataforma desde la que orquestar comandos del sistema operativo.
La vía inicial: una búsqueda en autocompletado sin validación
El origen del incidente estuvo en una aplicación web que incluía un campo de búsqueda con autocompletado. Ese componente enviaba la entrada del usuario hacia Oracle mediante JDBC, pero el dato no se validaba antes de llegar a la base. Con esa debilidad, los atacantes lograron ejecutar una cadena de acciones usando inyección SQL en Oracle a través de la conexión a la base de datos.
Además, la cuenta usada detrás de esa conexión contaba con permisos suficientes como para crear objetos que Oracle podía compilar y guardar como parte del esquema. En otras palabras: el fallo de inyección funcionó, pero también hizo falta que la credencial no estuviera limitada.
Qué es lo “nuevo” en la técnica: compilar Java dentro de Oracle
El toolkit identificado por los investigadores (asociado a un nombre observado como khunt) se apoyó en una idea clave: usar la funcionalidad de Oracle para compilar Java desde sentencias SQL. Oracle incorpora una Java Virtual Machine embebida, y el comando CREATE JAVA SOURCE permite que un usuario proporcione código Java que el motor de base de datos compila y almacena como objetos de esquema.
Desde ahí, los atacantes no necesitaron generar un archivo ejecutable tradicional en el servidor. Los objetos resultantes viven dentro de la base de datos y actúan como un “puente” hacia operaciones del sistema, ejecutando comandos mediante el flujo de ejecución disponible desde Java (por ejemplo, a través de mecanismos como Runtime.exec).
Del objeto en la base al comando en Windows
Para que el salto a SYSTEM ocurriera, el proceso necesitó encadenar permisos y capacidades. La investigación señala que crear objetos Java en un esquema requiere ciertas autorizaciones; en documentación de Oracle se describe que, en esquemas de usuario, el umbral puede situarse en un privilegio como CREATE PROCEDURE. En el entorno afectado, la cuenta comprometida tenía la capacidad necesaria para que el encadenamiento funcionara.
La ejecución de comandos desde Java, a su vez, requiere permisos asociados a la posibilidad de ejecutar procesos o acceder a operaciones del sistema. En el relato del caso no se detalla exactamente qué grants tenía la cuenta, pero el resultado final indica que el atacante dispuso de lo imprescindible para ambos pasos del encadenamiento.
El toolkit khunt y sus módulos
El equipo de Huntress, que estudió la actividad tras saltar detecciones vinculadas al robo de credenciales el 27 de julio de 2026, reconstruyó un conjunto de componentes alrededor de khunt. En el hallazgo se describen seis objetos Java y varios envoltorios PL/SQL (por ejemplo, con prefijos como khunt_*) que daban forma a funciones reutilizables.
En términos de comportamiento, se observaron módulos con finalidades distintas:
- KhuntCmd: cargaba cmd.exe y ejecutaba comandos arbitrarios pasados desde SQL.
- KhuntHash: obtenía nombres de usuario y hashes desde tablas internas de Oracle y los volcaba a un archivo.
- KhuntFS y KhuntFS2: listaban, leían, buscaban y dimensionaban archivos en el sistema.
- KhuntT: verificaba que el toolkit era alcanzable.
- KhuntUnzip: desempaquetaba archivos comprimidos.
Esta división por funciones es importante porque muestra cómo una inyección SQL en Oracle no tiene por qué limitarse a “ejecutar una consulta”. Puede convertirse en un entorno de administración/operación para el atacante, usando la base como motor de automatización.
Ejecución como SYSTEM: comandos, PowerShell y acceso a registros
El salto a Windows quedó evidenciado cuando se ejecutó cmd.exe /c whoami a través de KhuntCmd, devolviendo el contexto SYSTEM. A partir de ahí, los atacantes extendieron las acciones para aumentar el impacto y preparar la recolección de información.
Entre los pasos descritos se incluyen el uso de PowerShell y reg.exe para copiar hives de registro (las secciones SECURITY y SYSTEM) hacia F: iles dentro del contexto del entorno de Oracle. También se observó el uso de tasklist /svc para listar servicios, con una salida almacenada en un archivo (por ejemplo, khunttasks.txt).
Además, se copiaron hives como SAM y SECURITY usando esentutl.exe. Los investigadores mencionan que se registró el “staging” de archivos localmente, aunque no se pudo confirmar el paso de exfiltración en el análisis presentado.
Cómo detectar el abuso: buscar nombres de objetos y registros SQL
Cuando la técnica se apoya en objetos que viven dentro de Oracle, la detección cambia. Huntress propone que, al buscar este toolkit en particular, la cacería se enfoque en:
- Revisar la instalación de Oracle en busca de objetos cuyos nombres empiecen por Khunt.
- Consultar logs SQL para coincidencias con patrones como KHUNT%.
Esta recomendación es coherente con el comportamiento del ataque: los objetos están almacenados en la base como parte del esquema, y muchos sistemas de seguridad de endpoint no inspeccionan “el interior” del motor de base de datos para detectar compilaciones Java o invocaciones internas.
En esa lógica, el rol de la base cambia: deja de ser solo algo que el atacante consulta y pasa a convertirse en un punto de apoyo para operar contra el entorno.
Por qué no hay un parche directo para el conjunto del problema
El informe remarca que no existe una corrección de Oracle que, por sí sola, cierre el camino del incidente. El fallo está en la aplicación (la forma en que procesa y envía la entrada mediante JDBC) y, en paralelo, en la falta de contención por parte de permisos excesivos.
Por eso, la mitigación no puede limitarse a “actualizar Oracle”. La aplicación debe usar consultas parametrizadas y validación de entrada. Y, en la capa de acceso a Oracle, se debe aplicar mínimo privilegio: una cuenta que atiende una aplicación pública no debería poder autorizar la creación de fuentes Java ni acciones almacenadas que no necesite.
Qué aprender: los permisos determinan si la inyección escala
Un detalle clave del caso es que el eslabón crítico no fue únicamente la vulnerabilidad. La inyección SQL en Oracle funcionó porque el contexto de ejecución tenía permisos para crear objetos que luego permitieron ejecutar acciones del sistema. Si la cuenta hubiera estado restringida, el mismo vector probablemente se habría quedado en un impacto menor.
Además, la investigación señala que esta idea existe desde hace tiempo: ya en 2006 se documentaba un enfoque (por ejemplo, en el script raptor_oraexec.sql) que crea objetos de fuente Oracle con capacidades para ejecución de comandos y lectura de archivos mediante wrappers PL/SQL. Lo que menos se había visto “en la vida real” fue su uso encadenado de manera tan clara y documentada.
Recomendaciones prácticas para reducir el riesgo
Si administras entornos con Oracle detrás de aplicaciones web, estas acciones ayudan a reducir la superficie:
- Revisa y corrige el flujo de entrada: evita concatenar texto en consultas. Implementa consultas parametrizadas y valida lo que llega desde formularios y componentes como autocompletado.
- Audita el usuario JDBC: revisa qué privilegios tiene la cuenta de la aplicación. Quita permisos para creación de objetos o procedimientos que no sean estrictamente necesarios.
- Aplica monitoreo específico: complementa alertas generales con revisión de patrones de objetos y consultas asociadas a compilación o creación de fuentes Java.
- Reduce impacto con segmentación y privilegios: aunque haya un fallo, limita qué puede hacer la cuenta comprometida.
Conclusión
La historia demuestra que una inyección SQL en Oracle puede escalar hasta SYSTEM cuando el atacante encuentra dos condiciones: una vía de entrada sin validación y credenciales con permisos suficientes para convertir la base de datos en un “motor de ejecución”. En lugar de dejar rastros típicos de malware en forma de ejecutables en el disco, el abuso se apoya en objetos compilados y almacenados dentro de Oracle.
La lección práctica es clara: corrige la aplicación, valida la entrada y aplica mínimo privilegio. Así reduces la probabilidad de que un fallo puntual se convierta en una cadena completa de acceso y control del servidor.
Fuente: https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle.html
