khunt Toolkit Runs Inside Oracle Database After SQL Injection

How did the khunt toolkit attack work?

The khunt toolkit was installed directly inside an Oracle database after attackers exploited a SQL injection vulnerability in a public-facing Java application. Rather than relying on a conventional executable payload, the attackers abused Oracle’s Java functionality and later achieved SYSTEM-level command execution on the underlying Windows server.

What makes the incident notable is the role of the database. Oracle was not simply a target for unauthorized queries. The attackers used its legitimate Java functionality as part of the post-exploitation chain.

How did the khunt Oracle attack begin?

The attackers exploited SQL injection in an autocomplete search feature within a public-facing Java application running on Apache Tomcat.

The feature did not adequately validate user-controlled input before passing it to the backend Oracle database. This allowed the attackers to issue commands against Oracle.

Huntress discovered the intrusion after identifying credential-theft activity on the Windows server hosting the database. Apache access logs subsequently helped investigators trace the activity back to the vulnerable search endpoint.

The SQL injection provided the initial foothold. However, the more distinctive part of the attack followed when the attackers began using Oracle’s Java capabilities for post-exploitation.

How was the khunt toolkit installed inside Oracle?

The attackers abused Oracle’s embedded Java functionality, including CREATE JAVA SOURCE, to create Java source schema objects for khunt; Oracle can also create class schema objects for classes defined by that source.

Oracle Database includes an embedded Java Virtual Machine and supports Java code stored within the database. The attackers used this legitimate functionality to establish the khunt toolkit inside Oracle, with PL/SQL wrappers exposing its capabilities.

Observed khunt components included:

• KhuntCmd: Executed operating system commands through cmd.exe.
• KhuntHash: Accessed Oracle user information and could write username and password data to a file.
• KhuntFS and KhuntFS2: Supported file browsing, reading, searching and file-size operations.
• KhuntT: Validated the toolkit’s installation.
• KhuntUnzip: Provided archive-extraction functionality.

This database-resident design distinguishes khunt from post-exploitation tooling deployed primarily as conventional executable files.

File-focused monitoring alone may provide an incomplete view when malicious code is stored as database objects. Once khunt interacted with Windows, however, the attack also generated activity at the endpoint layer.

How did khunt achieve SYSTEM-level execution on Windows?

Khunt achieved SYSTEM-level Windows execution through KhuntCmd, which caused cmd.exe to launch as a child process of oracle.exe.

The attackers executed:

cmd.exe /c whoami

The output showed that commands launched through Oracle were running with SYSTEM-level permissions on the Windows server.

They also executed:

tasklist /svc

This command enumerated running processes and their associated Windows services. Its output was written to khunttasks.txt.

This marked a critical transition in the attack chain. A vulnerability in a public-facing application had progressed through Oracle to privileged operating system execution. Although khunt resided inside the database, the resulting child-process execution created host-level activity that defenders could investigate.

Did the khunt attackers steal Windows credentials?

Confirmed Windows credential theft has not been established. The attackers copied the SAM, SECURITY and SYSTEM registry hives, but available reporting does not confirm successful exfiltration or credential recovery.

The attackers used PowerShell and native Windows functionality to copy:

• SAM
• SECURITY
• SYSTEM

The SAM, SYSTEM and SECURITY hives can provide credential-related material used in Windows credential-dumping workflows, including local account password hashes and other stored secrets.

Therefore, the distinction between credential-access activity and confirmed credential theft is important. Copying the hives demonstrates collection of credential-relevant data, but it does not establish that the attackers successfully removed the files from the environment or recovered usable credentials.

How can organizations defend against attacks like khunt?

Defending against the khunt attack path requires controls across the application, database and endpoint layers, particularly input validation, least-privilege database access, Oracle Java auditing and endpoint investigation.

Prevent SQL injection at the application layer

Use prepared statements with parameterized queries to keep SQL code separate from user-supplied data, supported by appropriate server-side input validation.

In this incident, the vulnerable autocomplete feature provided the initial route into Oracle.

Restrict application database privileges

Application-facing database accounts should have only the permissions required for their intended functions.

If an application does not need to create Java source objects, the associated database account should not have that capability. As a result, least privilege can limit the actions available to an attacker after an application-to-database connection is compromised.

Audit unexpected Oracle Java activity

Organizations using Oracle Java functionality should identify where they expect Java schema objects and investigate any unexpected creation or modification.

In the khunt attack, the attackers used Oracle’s Java capabilities to establish the post-exploitation toolkit inside the database.

Investigate execution that crosses onto the host

Database compromise should not be investigated in isolation once database-resident code begins launching operating system processes.

Unexpected cmd.exe or PowerShell execution, unusual command lines, registry access and file operations can provide evidence of post-exploitation activity on the underlying server.

Featured resource

Introduction to Hexnode XDR

Explore how Hexnode XDR brings endpoint visibility, threat detection, investigation and response together for enterprise security teams.

Download the Presentation

How can Hexnode XDR help investigate khunt-related endpoint activity?

Hexnode XDR supports endpoint investigation and response when attacks following the khunt pattern generate suspicious process, file or registry activity on supported endpoints. Its role in this attack chain begins at the endpoint layer.

Hexnode XDR does not address the initial SQL injection, inspect Oracle SQL statements or identify malicious Java schema objects within Oracle. Application security and database-specific controls address those stages of the attack.

Once malicious activity reaches the endpoint, Hexnode XDR provides endpoint-focused detection, investigation and response capabilities. Security teams can use its endpoint telemetry to investigate documented events, including:

• Process creation
• Process access
• Process termination
• File creation or deletion
• Registry key creation or deletion

For remediation, Hexnode XDR supports targeting an associated process tree during process termination. It also supports response actions including:

• Process termination
• Endpoint isolation
• File quarantine

These capabilities complement application security and Oracle database monitoring rather than replace them. That distinction is particularly relevant to the khunt attack: the toolkit resided inside the database, while part of its post-exploitation activity occurred on the Windows host.

What can security teams learn from the khunt attack?

The primary lesson from khunt is that defenders need visibility across the point where database compromise becomes operating system execution.

The incident began with SQL injection, but its impact expanded because the attackers could use Oracle Java functionality to establish database-resident tooling and execute Windows commands with SYSTEM privileges.

The attack highlights four practical priorities:

• Prevent SQL injection through secure input handling and parameterized queries.
• Apply least privilege to application-facing database accounts.
• Audit unexpected creation or modification of Oracle Java objects.
• Investigate suspicious endpoint activity when database processes interact with the operating system.

The khunt toolkit incident is ultimately defined by its SQL-to-SYSTEM transition. Malicious code did not need to arrive as a conventional Windows executable to produce significant host-level activity.

Security teams can follow that execution path from the vulnerable application to Oracle and then to Windows to assess the scope of the compromise and determine where to investigate and respond.