Una inyección SQL convierte una base de datos Oracle en una plataforma para atacar Windows

El acceso inicial se produce a través de un endpoint de búsqueda

Huntress detectó el 27 de julio de 2026 una actividad de robo de credenciales en un servidor que alojaba una base de datos Oracle.

El acceso habría comenzado mediante una inyección SQL en un endpoint público de búsqueda y autocompletado. La función, integrada en una aplicación Java ejecutada en Apache Tomcat, no validaba correctamente las entradas recibidas.

Los atacantes pudieron insertar comandos SQL en las solicitudes enviadas a la base de datos. La actividad maliciosa se atribuyó a la dirección 178.162.151[.]229.

No se han dado a conocer las versiones de Oracle, Apache Tomcat, Java y Windows implicadas.

Khunt se instala directamente en el esquema de Oracle

En lugar de copiar un ejecutable al servidor, los atacantes introdujeron el toolkit de post-explotación khunt en la base de datos como un objeto Java.

La técnica aprovecha la JVM integrada en Oracle y la instrucción CREATE JAVA SOURCE, que permite almacenar y compilar código Java dentro del esquema. Posteriormente, estos objetos pueden invocarse mediante SQL.

Cuando cuentan con los permisos necesarios, estos objetos pueden ejecutar comandos en el sistema operativo. Huntress describe esta técnica como poco documentada en ataques reales.

El toolkit incluye varios módulos:

• KhuntCmd, para ejecutar comandos mediante cmd.exe e instrucciones SQL;
• KhuntHash, para acceder a la tabla interna de usuarios de Oracle y escribir en archivos los nombres de usuario y las contraseñas;
• KhuntFS y KhuntFS2, para explorar, leer y buscar archivos, así como comprobar su tamaño;
• KhuntT, para verificar si la instalación se realizó correctamente;
• KhuntUnzip, para extraer archivos comprimidos;
• wrappers de PL/SQL destinados a la ejecución de comandos, el robo de credenciales y la gestión de archivos.

Comandos de Windows y posible volcado de credenciales

Los atacantes ejecutaron:

cmd.exe /c whoami

El resultado indicaba privilegios de SYSTEM en el servidor Windows, el nivel operativo más elevado descrito en este caso.

Posteriormente utilizaron PowerShell y utilidades de Windows para copiar los hives de registro SAM, SECURITY y SYSTEM. Estos archivos pueden emplearse para recuperar los hashes de las contraseñas de las cuentas locales.

Huntress considera probable que se produjera una actividad de volcado de credenciales, pero no confirma que los hives fueran realmente exfiltrados del sistema.

Los atacantes también ejecutaron:

tasklist /svc

La salida, que contenía la lista de procesos y servicios activos, se guardó en el archivo khunttasks.txt.

La cadena de ataque convirtió la base de datos Oracle en un punto de persistencia y ejecución con privilegios elevados dentro de la red corporativa. La fuente no asigna una puntuación CVSS ni una clasificación formal, pero la relevancia operativa es alta.

Controles y medidas para reducir el riesgo

Las aplicaciones expuestas deben validar y sanitizar todas las entradas, incluidas las funciones de búsqueda y autocompletado. Además, las cuentas utilizadas para conectarse a Oracle deberían disponer únicamente de los permisos imprescindibles.

En particular, conviene impedir que estas cuentas puedan:

• crear fuentes Java mediante CREATE JAVA SOURCE;
• ejecutar procedimientos almacenados innecesarios;
• realizar operaciones administrativas en la base de datos o el sistema.

Los equipos de seguridad deberían revisar los logs de Apache y las consultas SQL anómalas, prestando especial atención a la creación de objetos Java en Oracle.

En el sistema Windows deben monitorizarse el inicio de cmd.exe, PowerShell y tasklist, así como los accesos o copias de los hives SAM, SECURITY y SYSTEM. Cada indicador, considerado de forma aislada, puede tener una explicación legítima; su combinación requiere una investigación inmediata.