From SQL Injection to SYSTEM Privileges: How Attackers Hide Backdoors Inside Oracle Databases

Attack Overview

On July 27, 2026, Huntress received an alert indicating credential theft on an Oracle database server. Investigation traced the intrusion to a publicly exposed Java/Tomcat web application whose backend Oracle database suffered an SQL injection vulnerability.

After injecting malicious SQL through the application's autocomplete search field, the attackers did not drop a traditional executable. Instead they compiled the post‑exploitation toolkit “khunt” directly into Oracle as Java objects, turning the database itself into a foothold.

Detailed Attack Chain

2.1 Initial Entry: Web Form SQL Injection

The autocomplete field accepted unchecked user input, concatenated it into a SQL statement and sent it via JDBC to Oracle. The malicious traffic originated from IP 178.162.151[.]229.

2.2 Oracle’s Built‑in Java Virtual Machine

Oracle ships an embedded JVM that allows creation of Java source code through the CREATE JAVA SOURCE statement. The database compiles the source and stores it as schema objects.

The attackers injected six Java objects and several PL/SQL wrapper functions prefixed with khunt_*:

KhuntCmd : loads cmd.exe and enables arbitrary OS command execution via SQL.

KhuntHash : extracts usernames and password hashes from internal Oracle user tables and writes them to files.

KhuntFS / KhuntFS2 : file explorer that can list, read, search and display file sizes.

KhuntT : connectivity test tool to verify the toolkit’s accessibility.

KhuntUnzip : utility for extracting archive files.

2.3 Lateral Movement to the Operating System

Using the KhuntCmd module, the attackers ran cmd.exe /c whoami, confirming they had acquired SYSTEM‑level privileges because Oracle on Windows runs as LocalSystem, and any code executed inside the database inherits that context.

2.4 Credential Theft and Local Staging

The attackers then performed the following steps:

reg.exe save hklm\SECURITY F:\Oracle\khuntSECURITY.hiv
reg.exe save hklm\SYSTEM F:\Oracle\khuntSYSTEM.hiv

They enumerated running services with tasklist /svc and saved the output to F:\Oracle\khunttasks.txt. Finally, they used esentutl.exe to copy the SAM and SECURITY hives:

esentutl.exe /y /d C:\Windows\System32\config\SAM /d F:\Oracle\khuntSAM.hiv

These registry hives can be used to extract and decrypt local account password hashes.

Technical Background: A Two‑Decade‑Old Technique Re‑emerges

Security researcher Marco Ivaldi published “raptor_oraexec.sql” in 2006, which also leveraged CREATE JAVA SOURCE to embed command execution and file‑read capabilities in Oracle. The khunt toolkit builds on the same architecture.

Huntress notes that, although the technique is well‑known, fully documented real‑world exploits are rare.

Blue‑Team Defense Recommendations

4.1 Application‑Layer Mitigations

Enforce strict input validation and filtering for all user‑supplied data.

Use parameterized queries (Prepared Statements) instead of string concatenation.

Restrict special SQL characters in autocomplete and other search features.

4.2 Minimal Database Account Privileges

Public‑facing applications should use database accounts that lack permissions to create Java objects or execute stored procedures, preventing malicious code compilation even if SQL injection succeeds.

4.3 Monitoring and Detection

Search Oracle for Java classes whose names start with “Khunt”.

Search SQL logs for strings matching “KHUNT%”.

Monitor the Oracle process (oracle.exe) for unexpected spawning of cmd.exe, reg.exe, or other system commands.

Watch the F:\Oracle\ directory for newly created suspicious files.

4.4 Service Account Isolation

Run Oracle on Windows under a dedicated low‑privilege service account rather than LocalSystem, limiting the impact of any code executed via the database.

Conclusion

The incident underscores two enduring issues: the persistent risk of classic SQL injection vulnerabilities and the stealth of compiling malicious code into internal database objects, which evades traditional EDR and antivirus solutions.

According to the MITRE ATT&CK framework, the attack employed techniques such as T1505.003 (SQL command execution via stored procedures), T1005 (data from local system), T1003.002 (SAM dump for credential extraction), and T1059.003 (command‑shell execution).