Los atacantes irrumpieron en la base de datos Oracle de una organización mediante una vulnerabilidad de inyección SQL en una aplicación web pública. Después de obtener acceso, instalaron un kit de herramientas de post-explotación sin escribir un ejecutable en el disco. En su lugar, alimentaron con código fuente Java a la base de datos, permitiendo que Oracle lo compilara en objetos de esquema almacenados, y ejecutaron comandos desde dentro del motor de la base de datos.
Huntress, que sigue el rastro del kit como khunt, investigó después de que se activaran alertas de robo de credenciales el 27 de julio de 2026, y rastreó la cadena hasta la ejecución de código a nivel de SYSTEM en el servidor Windows subyacente.
La vulnerabilidad se encontraba en la aplicación, donde un campo de búsqueda de autocompletado pasaba entradas no validadas a la base de datos a través de una conexión JDBC (Java Database Connectivity). La cuenta detrás de esa conexión tenía privilegios suficientes para crear objetos Java.
Ningún parche de Oracle cierra la vulnerabilidad de la aplicación ni el privilegio de la cuenta que la permite. Encontrar el kit implica buscar: examinar la instalación de Oracle en busca de nombres de objetos que comiencen con 'Khunt', y registros SQL con 'KHUNT%'.
Una clase Java compilada como objeto de esquema de base de datos no es un proceso, un binario ni un archivo en el sistema de archivos, y los productos de detección y respuesta de endpoints no suelen inspeccionar los internos de Oracle. Como lo plantea Huntress, la base de datos deja de ser algo que los atacantes consultan y se convierte en una cabeza de playa desde la que atacan.
Oracle incluye una máquina virtual Java integrada, y la declaración CREATE JAVA SOURCE permite a un usuario entregarle código Java que la base de datos compila y almacena como un objeto de esquema. En el esquema propio del usuario, la documentación de Oracle establece el requisito en un solo privilegio de sistema: CREATE PROCEDURE. Para lanzar un proceso del sistema operativo desde ese código se pasa por Runtime.exec, que necesita su propio permiso de ejecución de archivos, y Oracle dice que esos permisos solo son emitidos por administradores privilegiados.
Huntress no especifica qué concesiones tenía la cuenta comprometida, ni si los atacantes tuvieron que añadir alguna. La cadena tuvo éxito, por lo que la cuenta poseía ambos privilegios necesarios.
La técnica tiene al menos dos décadas de antigüedad. El raptor_oraexec.sql de Marco Ivaldi, fechado en 2006, crea un objeto fuente de Oracle con métodos de ejecución de comandos y lectura de archivos, y luego los publica a SQL mediante envoltorios PL/SQL. Los objetos khunt utilizan la misma arquitectura básica. "El uso de esta técnica en ataques reales rara vez ha sido documentado", señaló Huntress.
El kit estaba compuesto por seis objetos Java y varios envoltorios PL/SQL con nombres khunt_*:
- KhuntCmd: cargaba cmd.exe y ejecutaba comandos arbitrarios del sistema operativo pasados como SQL.
- KhuntHash: leía nombres de usuario y hashes de contraseñas de la tabla interna de usuarios de Oracle y los escribía en un archivo.
- KhuntFS y KhuntFS2: listaban, leían, buscaban y medían archivos.
- KhuntT: confirmaba que el kit era accesible, y KhuntUnzip desempaquetaba archivos.
La ejecución de cmd.exe /c whoami a través de KhuntCmd devolvió SYSTEM. Los atacantes luego usaron PowerShell y reg.exe para copiar las colmenas de registro SECURITY y SYSTEM en F:Oracle, ejecutaron tasklist /svc en khunttasks.txt, y copiaron las colmenas SAM y SECURITY con esentutl.exe.
Huntress observó que los archivos se almacenaban localmente, pero no estableció que fueran exfiltrados. La firma no nombró a un actor de amenazas y rastreó las solicitudes maliciosas hasta 178.162.151[.]229.
Estos indicadores son específicos de este kit, por lo que ninguna búsqueda de 'Khunt' o 'KHUNT%' revelará la técnica detrás de él. La solución es usar consultas parametrizadas y validación de entrada en la aplicación, además del principio de mínimo privilegio: una cuenta que atiende una aplicación pública no debería poder crear fuentes Java ni ejecutar procedimientos almacenados que no tenga razón de tocar.
Deja una respuesta