Inside an Oracle Database SQL Injection Attack | Huntress

What it is

Huntress's incident writeup of a real-world SQL injection against a public-facing Java/Tomcat app with an Oracle backend, escalating to SYSTEM-level RCE and registry-hive theft via the database-resident khunt toolkit. The summary already covers the toolkit and the oraexec/CREATE JAVA SOURCE technique; what follows are the concrete detection and hunting artifacts the summary omits.

How it works

The injectable endpoint was an autocomplete search feature in the app — no novel vuln was needed. Tomcat passed the SQL over its JDBC connection to Oracle, where CREATE JAVA SOURCE compiled attacker Java into stored schema objects, wrapped by khunt_* PL/SQL. KhuntCmd then bridged from the database layer to the OS by loading cmd.exe.

Detection signals

• Process ancestry: reg.exe (and other OS tooling) spawned from an oracle.exe parent process. This is the pivot from DB to OS and the strongest single signal.
• On-disk artifacts written to F:\Oracle\:
• khuntSECURITY.hiv, khuntSYSTEM.hiv (via reg.exe through PowerShell)
• khunt_SECURITY.hiv, khuntSAM.hiv (via esentutl.exe)
• khunttasks.txt (output of tasklist /svc)
• Attacker infrastructure: source IP 178.162.151[.]229, traced via the volume of requests to the injectable endpoint in Apache access.log.
• Observed commands: cmd.exe /c whoami (used to confirm SYSTEM), tasklist /svc, plus reg.exe and esentutl.exe hive copies.

Note the attacker copied SECURITY twice using two different tools (reg.exe and esentutl.exe) — worth accounting for when scoping.

flowchart TD
  A[Autocomplete search field, no input validation] --> B[Tomcat -> JDBC -> Oracle]
  B --> C[CREATE JAVA SOURCE: khunt compiled as DB object]
  C -->|trust boundary: DB -> OS| D[KhuntCmd loads cmd.exe as SYSTEM]
  D --> E[reg.exe / esentutl.exe dump SAM/SECURITY/SYSTEM hives]
  A -. input validation cuts here .-> X[blocked]

What to do

The page's stated mitigation is fixing the root cause: validate/parameterize inputs so form fields cannot reach PL/SQL. It also flags the core defensive gap — because the toolkit lives as a database schema object rather than a file or memory-resident payload, traditional EDR can miss it, so hunt in Oracle for anomalous JAVA SOURCE objects and khunt_* PL/SQL wrappers in addition to the OS-level signals above.

Caveats

The writeup is a single incident narrative; it gives no CVE, no patch, and no exhaustive IOC list beyond the artifacts above. The oraexec technique itself is described as long-known but rarely seen in the wild — treat the specific file names and paths as this actor's convention, not a fixed signature.