Agradecimientos: Un agradecimiento especial a Lindsey O'Donnell-Welch por sus contribuciones a esta investigación y a la redacción de este informe.
Contexto
El 27 de julio de 2026, Huntress recibió una alerta sobre actividad de robo de credenciales en un endpoint que alojaba un servidor de base de datos Oracle. El atacante había logrado hacer copias de varios registros (SAM, SECURITY, SYSTEM), probablemente para exfiltrarlos y extraer las credenciales que contenían.
Tras una investigación más profunda, los investigadores de Huntress determinaron que este ataque fue el resultado de un ataque de inyección SQL (SQLi). Los ataques de inyección SQL existen desde hace décadas y suelen deberse al manejo incorrecto de las entradas enviadas al servidor SQL, en lugar de vulnerabilidades explotables.
En este caso, una aplicación pública con un backend de Oracle aceptaba y ejecutaba comandos SQL ingresados en un formulario de la aplicación que no verificaba si el contenido ingresado era válido. Por ejemplo, toma un campo de formulario diseñado para ingresar un nombre de usuario. Cuando existe una validación adecuada y se ingresa una instrucción SQL en un formulario, la aplicación rechaza el SQL. No contar con estas verificaciones puede permitir que un atacante tome el control de un sistema vulnerable.
Sin embargo, lo que sucedió después nos llamó la atención. Tras realizar la inyección SQL, el actor de amenazas logró cargar un kit de herramientas post-explotación residente en la base de datos, llamado khunt. Esta es una técnica que se ha discutido previamente y descrito a lo largo de los años, incluyendo una técnica descrita como oraexec; sin embargo, el uso de esta técnica en el mundo real rara vez se ha documentado.
La base de datos de Oracle tiene una máquina virtual Java (JVM) integrada, y la instrucción CREATE JAVA SOURCE permite a los usuarios tomar código fuente Java y almacenarlo como un objeto de base de datos. Esto es lo que hicieron los atacantes durante este incidente: enviaron comandos CREATE JAVA SOURCE a la base de datos Oracle desde Tomcat, a través de la conexión JDBC, y el código fuente Java contenido se compiló directamente dentro de la base de datos como un objeto de esquema almacenado.
A continuación, describimos los distintos componentes de khunt, el uso de este vector de ataque y su impacto, y cómo los defensores pueden mitigar este ataque.
Tradecraft del atacante
El acceso inicial
Cuando se activaron las primeras detecciones de robo de credenciales, observamos que el comando provenía de un proceso (C:\Windows\System32\reg.exe) generado desde un proceso principal oracle.exe.
Figura 1: Detecciones activadas por actividad sospechosa de robo de credenciales
Por ello, para conocer más información sobre el ataque y el vector de acceso inicial, estudiamos los registros de acceso de Apache (access.log). Estos nos mostraron cómo los actores de amenazas obtuvieron entrada: utilizando inyección SQL contra un endpoint en una aplicación pública Java/Tomcat que carecía de protecciones adecuadas contra la entrada de instrucciones SQL. La aplicación Tomcat, al estar conectada a la base de datos Oracle mediante una conexión JDBC, enviaba los comandos SQL a la base de datos.
El archivo access.log también nos dio un vistazo a la infraestructura del adversario: según el volumen de solicitudes al endpoint inyectable en la aplicación vulnerable durante el periodo de interés, rastreamos la IP del atacante hasta 178.162.151[.]229.
El kit de herramientas khunt
Usando este vector de ataque, los actores de amenazas inyectaron varios objetos que, en conjunto, conformaron el kit de herramientas. Estos incluían lo siguiente:
KhuntCmd: un módulo que carga cmd.exe en el sistema y permite al atacante ejecutar comandos arbitrarios del sistema operativo enviando instrucciones SQL a la base de datos que los incluyen.KhuntHash: esta herramienta accede directamente a la tabla interna de usuarios de Oracle y extrae nombres de usuario y contraseñas, guardándolos en un archivo.KhuntFSyKhuntFS2: dos exploradores de archivos que permiten todo tipo de funciones, como listar, leer, buscar y verificar el tamaño de archivos. Estos permiten efectivamente al atacante explorar el sistema comprometido.KhuntT: una herramienta sencilla tipo "ping" diseñada para confirmar que el kit de herramientas está instalado, funcionando y accesible antes de continuar con el ataque.KhuntUnzip: una herramienta para descomprimir archivos.Varios envoltorios PL/SQL
khunt_*usados para llamar a los métodos Java subyacentes.
El atacante usó algunos de estos módulos para lanzar las distintas fases de sus ataques.
Más actividad posterior al compromiso
En este punto, el actor de amenazas pasó de la base de datos Oracle al sistema operativo subyacente del servidor Windows. Hizo esto aprovechando el módulo KhuntCmd para abrir un shell de comandos de Windows, ejecutando cmd.exe /c whoami. Esto le permitió determinar que tenía permisos de nivel SYSTEM, y confirmó la ejecución remota de código (RCE) desde la capa de base de datos hasta el sistema operativo.
Figura 2: La actividad maliciosa del atacante se originó en el proceso principal oracle.exe
Poco después, el atacante ejecutó comandos de PowerShell para invocar la herramienta del Registro de Windows (reg.exe) y hacer copias de los registros SECURITY y SYSTEM, guardándolas en F:\Oracle\khuntSECURITY.hiv y F:\Oracle\khuntSYSTEM.hiv.
Luego, el atacante ejecutó tasklist /svc para enumerar los servicios en ejecución, guardándolos en un archivo junto con los registros como F:\Oracle\khunttasks.txt.
Finalmente, el atacante copió los registros SAM y SECURITY usando esentutl.exe, la utilidad Extensible Storage Engine, guardándolos en F:\Oracle\khuntSAM.hiv y F:\Oracle\khunt_SECURITY.hiv.
Las copias de los registros se pueden usar para extraer y decodificar hashes de contraseñas de las cuentas locales de este sistema.
Mitigaciones para los defensores
Los atacantes lograron obtener acceso inicial en este ataque gracias a una inyección SQL clásica. No fue necesaria una vulnerabilidad novedosa, ya que la función de búsqueda con autocompletado en la aplicación pública fue suficiente para llegar a PL/SQL y luego al sistema operativo.
Colocar el kit de herramientas khunt directamente en Oracle plantea algunas cuestiones que vale la pena considerar desde la perspectiva de defensa: esto convierte la base de datos de algo que los atacantes consultan para obtener datos en una cabeza de playa desde la cual los actores de amenazas pueden lanzar ataques. Tener un kit de herramientas malicioso almacenado como un objeto de base de datos, en lugar de residir en un archivo o en memoria, hace que sea fácil pasarlo por alto. El EDR y los antivirus tradicionales se enfocan en procesos, binarios y archivos del sistema operativo, y generalmente no inspeccionan clases Java ni envoltorios PL/SQL dentro de Oracle.
Para evitar este tipo de ataques, es importante asegurarte de que los formularios no sean inyectables. Aplica una sanitización adecuada de las entradas y parametrización de consultas para cualquier entrada. También es importante asegurarte de que los usuarios con la capacidad de ejecutar consultas no tengan permisos excesivos. Incluso si ocurre una inyección SQL, la cuenta de usuario utilizada no debería ser capaz de crear fuentes Java, ejecutar procedimientos almacenados ni nada similar.
Indicadores de compromiso (IOC)
Elemento | Descripción |
|---|---|
| Archivos de registro extraídos por el atacante. |
| Archivo de texto que contiene una lista de tareas. |
| Dirección IP del atacante. |
| Busca dentro de la instalación de Oracle instancias de object_name que coincidan con estos nombres. |
| Busca esta cadena en los registros de SQL. |
