Una cadena de intrusión observada en ataques reales muestra cómo una inyección SQL puede terminar en ejecución de comandos en Windows con privilegios de SYSTEM. El salto se apoya en Oracle Database y su capacidad para cargar y compilar Java dentro del propio motor, una función potente que también amplía la superficie de ataque si se mantiene habilitada sin control.
Una intrusión que empezó con una simple inyección SQL en una aplicación expuesta a Internet acabó escalando hasta la ejecución de comandos en un servidor Windows con privilegios de SYSTEM. El punto de giro no estuvo en una vulnerabilidad nueva del sistema operativo, sino en una capacidad legítima de Oracle Database: la posibilidad de cargar, compilar y ejecutar Java dentro de la base de datos como parte de su lógica interna.
Tras obtener acceso a la base de datos Oracle, los atacantes introdujeron código fuente Java y lo convirtieron en objetos del esquema, compilándolo en el propio servidor. Esta forma de post explotación resulta especialmente incómoda para la defensa porque reduce la dependencia de binarios clásicos en disco y desplaza parte del tooling al interior del motor de base de datos, que en muchos entornos se monitoriza menos que el sistema operativo o el servidor web.
La actividad se asoció a un artefacto denominado khunt, ligado a telemetría de Huntress. El objetivo final consiste en convertir una puerta de entrada a nivel de aplicación en una vía para ejecutar acciones en el host. Cuando el proceso de Oracle corre con permisos elevados en Windows, cualquier ejecución encadenada desde el contexto de la base de datos puede terminar heredando privilegios muy altos, hasta SYSTEM, con el consiguiente riesgo para el resto de la máquina y los datos que alberga.
La cadena refuerza una idea conocida, pero que se incumple con demasiada frecuencia: la defensa empieza en la aplicación. Corregir la inyección SQL exige abandonar concatenaciones de entradas y aplicar consultas parametrizadas y validación estricta. A partir de ahí, toca mirar a la base de datos: si Java en Oracle no resulta imprescindible, conviene deshabilitarlo o limitarlo al máximo, porque amplía el alcance de lo que un atacante puede hacer tras un primer acceso.
En paralelo, los equipos de seguridad pueden ganar visibilidad vigilando señales muy concretas dentro de Oracle. Sentencias y eventos como CREATE JAVA SOURCE, CREATE JAVA CLASS y operaciones de compilación deben encender alertas si aparecen en producción sin una razón clara. También ayuda restringir quién puede ejecutar DDL relacionado con Java, revisar el usuario de base de datos que usa la aplicación con enfoque de mínimo privilegio, y endurecer el propio host Windows, empezando por evitar que el servicio de Oracle funcione con privilegios innecesarios.
En la información disponible no aparecen CVE concretos para el acceso inicial ni se detallan versiones exactas de Oracle Database o configuraciones del entorno. Aun así, el patrón encaja con un riesgo recurrente: cuando una plataforma crítica, como la base de datos, mantiene habilitadas funciones potentes sin gobernanza ni auditoría, un fallo clásico como la inyección SQL deja de ser ‘solo’ un problema de datos y pasa a convertirse en un problema de control del sistema.
Más información
- The Hacker News – Attackers Compile khunt Inside Oracle to Turn SQL Injection Into Windows SYSTEM Access : https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle-to-turn-sql-injection-into-windows-system-access.html
- Oracle Documentation – Loading Java Classes : https://docs.oracle.com/cd/A97630_01/java.920/a96659/02_load.htm
- Oracle Documentation – Server-Side Internal Driver : https://docs.oracle.com/en/database/oracle/oracle-database/26/jjdbc/server-side-internal-driver.html
Deja una respuesta