DEV Community

Anoymask
Anoymask

Posted on

khunt: SQL Injection to Resident Threat Inside Oracle Database Stealing Credentials with SYSTEM Privileges

#security #threatintel

khunt: SQL Injection to Resident Threat Inside Oracle Database Stealing Credentials with SYSTEM Privileges

1. Basic Information

  • Article Title: Inside an Oracle Database SQL Injection Attack
  • Publisher: Huntress
  • Publication Date: August 5, 2026
  • Original Source: Huntress
  • Related Sources: BleepingComputer
  • Related Malware & Tools: khunt, KhuntCmd, KhuntHash, KhuntFS, KhuntFS2, KhuntT, KhuntUnzip, khunt PL/SQL wrappers
  • Related Products: Apache Tomcat, Oracle Database, Oracle JVM, JDBC, Windows
  • Related CVEs & Threat Groups: Specific CVEs and threat groups are unknown. Application-specific SQL Injection.
  • Severity: High

On July 27, 2026, Huntress detected credential theft on an Oracle Database server. The entry point was a SQL Injection vulnerability in the autocomplete search feature of a public Java/Tomcat application. The attacker used Oracle's CREATE JAVA SOURCE to save and compile khunt as a database schema object instead of a regular executable file.

2. Executive Summary

This attack chains a public web application SQL Injection to Oracle's built-in JVM. It keeps a Java/PLSQL post-exploitation toolkit resident inside the database, and then uses oracle.exe to run OS commands with SYSTEM privileges, dump registry hives, and steal credentials.

3. Attack Flow

Chain A: Deploying Toolkit from Web App into Database

  1. The attacker sends a crafted input to the autocomplete endpoint of a public Tomcat application.
  2. Poor input validation and flawed parameterized queries cause a SQL Injection.
  3. The SQL/PLSQL query reaches Oracle from Tomcat through a JDBC connection.
  4. The attacker runs CREATE JAVA SOURCE using an over-privileged application database account.
  5. The khunt Java source is saved and compiled as an Oracle schema object.
  6. KhuntCmd, KhuntHash, KhuntFS/FS2, KhuntT, KhuntUnzip, and PL/SQL wrappers are registered.

Chain B: Pivoting from Oracle to Windows OS

  1. KhuntT checks the installation and reachability of the toolkit.
  2. KhuntCmd runs cmd.exe /c whoami.
  3. It inherits the privileges of oracle.exe and confirms SYSTEM privileges.
  4. KhuntFS/FS2 enumerates and searches the filesystem.
  5. KhuntHash dumps username and password data from the internal Oracle user table.

Chain C: Staging Windows Credentials

  1. PowerShell runs reg.exe to copy the SECURITY and SYSTEM hives.
  2. It runs tasklist /svc and saves the output to khunttasks.txt.
  3. esentutl.exe copies the SAM and SECURITY hives.
  4. The files are staged as F:\Oracle\khunt*.hiv.
  5. The attacker likely tried to exfiltrate the data, but public reports do not confirm successful exfiltration.

4. Attacker Locations and Execution Points

  • External Attacker: Connected to the public web endpoint from IP 178.162.151[.]229.
  • Initial Execution: Tomcat application process and JDBC connection.
  • Toolkit Storage and Execution: Oracle Database Java schema objects and PL/SQL wrappers.
  • OS Execution: cmd.exe, PowerShell, reg.exe, and esentutl.exe spawned from oracle.exe on Windows.
  • Privileges: SYSTEM.
  • Staging: Inside the Oracle install/data drive paths.

5. Visibility for Victims and Administrators

Web administrators see many abnormal requests to the autocomplete endpoint. DBAs see CREATE JAVA SOURCE, KHUNT% objects, and Java compilation events. Windows SOC teams see cmd.exe, PowerShell, reg.exe, and esentutl.exe spawned by oracle.exe. However, because the main toolkit is a database object instead of a normal EXE orDLL, EDR and AV tools easily miss the initial deployment.

6. Conditions for Success and Failure

Conditions for Success

  • An internet-facing application has a SQL Injection vulnerability.
  • The application database account has permissions to run CREATE JAVA SOURCE or stored procedures.
  • Oracle JVM is available.
  • The Oracle service runs with high privileges.
  • Database auditing or application/database correlation monitoring is missing.

Conditions for Failure

  • Parameterized queries and server-side input validation are implemented.
  • Java source creation and compilation permissions are removed from the application database account.
  • The Oracle service runs with the least privileges necessary.
  • CREATE JAVA SOURCE and new schema objects are monitored and restricted.
  • EDR blocks shells and registry hive access originating from database processes.

7. What Happens Upon Success

The attacker turns the database from a query target into a beachhead for OS attacks. They can execute commands with SYSTEM privileges, perform service discovery, explore the filesystem, obtain Oracle credentials, and dump Windows local account hashes. Unless the database object is deleted, the toolkit remains even after the web exploit is fixed.

8. Observable Logs

Email

  • Not used as an initial vector in public reports.

Proxy / SWG / DNS

  • Repeated requests from external IP 178.162.151[.]229 to public endpoints.
  • HTTP requests containing SQL keywords, Java source fragments, and long payloads.

Endpoint / EDR

  • oracle.exe → cmd.exe /c whoami
  • oracle.exe or shell → PowerShell → reg.exe
  • oracle.exe → esentutl.exe
  • F:\Oracle\khuntSECURITY.hiv, khuntSYSTEM.hiv, khuntSAM.hiv, khunt_SECURITY.hiv
  • F:\Oracle\khunttasks.txt

Identity / IdP

  • DDL / Java source creation by the application database account.
  • Unusual access to Oracle internal user tables.
  • Subsequent use of local account hashes.

SaaS / Cloud

  • No SaaS/cloud usage reported.

Network

  • Tomcat → Oracle JDBC.
  • Unusual egress traffic from the Oracle host (potential exfiltration or C2).
  • OS network connections immediately following the SQL Injection.

9. Determining Attack Success

  • Contact Only: Abnormal HTTP requests or SQL errors only.
  • User Action: Not required.
  • Initial Execution: Malicious SQL succeeds using the application database account.
  • Malware Success: KHUNT% Java/PLSQL objects are created and compiled.
  • Authentication and OS Compromise Success: Shell spawned from oracle.exe and SYSTEM privileges confirmed.
  • Credential Staging Success: Registry hives, Oracle credentials, and task list files are created.
  • Exfiltration Confirmation: Requires proof of outbound data transfer or stolen data on the attacker's side (not confirmed in reports).
  • Subsequent Compromise Confirmation: Login to other hosts using stolen hashes, lateral movement, or new persistence mechanisms.

10. Investigation Playbook

Trigger

  • Shells or credential dumping spawned by oracle.exe.
  • KHUNT% database objects.
  • khunt*.hiv files in the Oracle directory.
  • SQL Injection against public endpoints.

Initial Checks

  1. Review web access logs to identify the initial malicious request, source IP, and session.
  2. Check the JDBC connection user and database privileges.
  3. Use Oracle audit, redo, and general logs to find the creation time of the Java source and PLSQL objects.
  4. Correlate EDR process trees with database transactions chronologically.

Endpoints and Servers

  • Preserve registry hives, task outputs, PowerShell logs, Prefetch, and Amcache.
  • Check child processes and network connections of oracle.exe.
  • Analyze both the Oracle filesystem and exported schema objects.

Identity and Cloud

  • Rotate Oracle application and user credentials.
  • Treat local accounts as compromised at the exact time the SAM/SECURITY/SYSTEM hives were dumped.
  • Search for the use of the same credentials on other hosts and services.

Subsequent Actions

  • Check for lateral movement, remote services, new services/tasks, and RDP/SMB activity.
  • Investigate egress volume and destinations from the Oracle host.

Containment

  • Block or patch the web endpoint.
  • Strip excessive privileges from the application database account.
  • Isolate the compromised Oracle host.
  • Preserve evidence, delete the khunt objects, and consider rebuilding the server.
  • Rotate all related credentials.

Incident Status Categories

  • SQLi Attempt / SQLi Confirmed / Database Object Implant Confirmed / SYSTEM RCE Confirmed / Credential Staging Confirmed / Exfiltration Confirmed / Lateral Movement Confirmed

11. Defense and Detection Ideas

Single Events

  • CREATE JAVA SOURCE executed by an application account.
  • oracle.exe spawning cmd.exe, PowerShell, reg.exe, or esentutl.exe.
  • Creation of registry hives inside the Oracle directory.

Chronological Correlation

Public endpoint SQLi → JDBC DDL → Java object compilation → oracle.exe child shell → hive copy → network egress

Threat Hunting

  • Search DBA_OBJECTS for object names starting with KHUNT%.
  • Look for recently created or modified Java sources and PLSQL wrappers.
  • Check for unusual DDL actions executed by application accounts.
  • Look for LOLBins with database processes as parent processes.
  • Hunt for .hiv files and task/process list files on the Oracle host.

Log Gaps

  • Web request bodies.
  • Oracle unified audit logs, DDL logs, and Java source contents.
  • EDR child process command lines.
  • File creation and network egress logs.

Priority Mitigations

  1. Remove Java and DDL permissions from application accounts.
  2. Patch SQL Injection vulnerabilities and apply virtual patching via WAF.
  3. Enforce security policies blocking child processes spawned by database services.
  4. Integrate database audit logs into the SIEM.
  5. Run Oracle services with the least privileges necessary.

12. Facts, Inferences, and Hypotheses

Facts

  • The attacker reached the Oracle database via a SQL Injection in a public Tomcat application.
  • They used CREATE JAVA SOURCE to save and compile khunt as a database object.
  • They executed OS commands with SYSTEM privileges using KhuntCmd.
  • They saved the SAM, SECURITY, and SYSTEM hives along with a service list to files.
  • Successful exfiltration has not been confirmed.

Inferences

  • Database objects easily bypass normal file-based IOC scanning and can remain even after web applications are patched.
  • Once registry hives are created, local credentials should be considered compromised and must be rotated immediately.

Hypotheses

  • Correlating DDL audits and EDR process graphs can detect database-resident malware execution with high accuracy.
  • There may be active campaigns reusing the same IP address or khunt object names against other organizations.

13. MITRE ATT&CK Mapping

High Confidence

  • T1190 Exploit Public-Facing Application
  • T1059.003 Windows Command Shell
  • T1059.001 PowerShell
  • T1505 Server Software Component
  • T1003.002 Security Account Manager
  • T1003.004 LSA Secrets
  • T1518.001 Security Software Discovery (tasklist /svc can also be evaluated as Software Discovery)
  • T1083 File and Directory Discovery
  • T1074.001 Local Data Staging

Medium Confidence

  • T1213 Data from Information Repositories: Dumping Oracle internal user data.
  • T1027 Obfuscated/Compressed Files: Actual use of KhuntUnzip is unconfirmed.
  • T1041 Exfiltration Over C2 Channel: Successful data exfiltration is unconfirmed.
  • T1078 Valid Accounts: Subsequent use of stolen hashes is unconfirmed.

14. Unknowns and Areas for Further Investigation

  • Vulnerable application/product names and patch status.
  • Full text of the SQL Injection request.
  • khunt source code, file hashes, and compilation timestamps.
  • Duration of persistence via database objects.
  • Actual exfiltration status of registry hives and Oracle credentials.
  • C2 and exfiltration destinations.
  • Attacker groups and other victim organizations.

15. Impact on SOCs and General Enterprises

Enterprise environments using Oracle Databases alongside Tomcat and JDBC often run with overly permissive application database accounts for long periods. Security teams must correlate three layers—web logs, database audits, and OS processes—while including database schema objects in compromise assessments. Specifically, shells and registry access originating from oracle.exe are extremely rare and represent high-priority signals.

16. Summaries for SOCs, Administrators, and Users

For SOCs

  • Prioritize investigating shells, PowerShell, reg.exe, and esentutl.exe spawned by oracle.exe.
  • Correlate web SQLi, database DDL, and OS credential dumping into a single incident.
  • Search for KHUNT% schema objects in addition to checking the filesystem.

For Administrators

  • Remove excessive permissions such as CREATE JAVA SOURCE from application accounts.
  • Patch vulnerable endpoints and run Oracle services with the least privileges necessary.
  • If a compromise is suspected, rotate all related credentials and consider rebuilding the server.

For Users

This is a server-side attack that does not require user interaction. Even if you do not notice any unusual behavior on your end, please follow all instructions from administrators regarding service outages and credential changes.

Top comments (0)