Hackers Hid the khunt Toolkit Inside an Oracle Database

Huntress has described an unusual attack discovered on July 27, 2026: its platform detected the theft of credentials on a server running an Oracle database. A review of the logs showed that the attackers had breached the corporate network through a vulnerability in a publicly accessible Java application on Apache Tomcat.

Point of Entry

The application improperly validated data coming in through the search-query autocomplete function. This allowed the attackers to send arbitrary SQL commands to the Oracle database. Huntress traced the malicious queries to the IP address 178.162.151[.]229.

A Toolkit Inside the DBMS

The most intriguing part is the method of persistence. Instead of leaving executable files on the server, the attackers placed the khunt post-exploitation kit directly inside the database as a Java object. Oracle has a built-in Java virtual machine and a CREATE JAVA SOURCE statement that lets you store and compile Java code as a schema object. Such objects can then be called through SQL and, with the right configuration, can execute commands on the host's operating system. Huntress notes that a technique like this has been documented extremely rarely in real-world attacks.

The kit consisted of several Java components and PL/SQL wrappers:

• KhuntCmd — launched cmd.exe and allowed OS commands to be run through SQL;
• KhuntHash — accessed Oracle's internal user table and dumped usernames and password data to a file;
• KhuntFS and KhuntFS2 — provided browsing, reading, and searching of files, along with checking their size;
• KhuntT — worked like a “ping,” confirming that the kit had been installed successfully;
• KhuntUnzip — unpacked compressed files.

What Came Next

Using KhuntCmd, the attackers ran cmd.exe /c whoami and confirmed that commands launched from the database had SYSTEM-level privileges on the Windows server. Then, with PowerShell and built-in utilities, they copied the SAM, SECURITY, and SYSTEM registry hives, from which the password hashes of local accounts can be recovered. With the tasklist /svc command they enumerated the running services and saved the output to a file, khunttasks.txt.

Huntress believes the registry hives were dumped in order to extract credentials, but the report cannot confirm that the files were successfully stolen.

Takeaways

The main recommendation is simple: validate all user input and limit the privileges of the accounts under which applications interact with the database. The accounts used by public-facing applications should not have the rights to create Java sources, run unnecessary stored procedures, or perform other administrative actions — it was precisely these excessive privileges that turned an ordinary SQL injection into full control over the server.

Source: Bleeping Computer