A threat actor exploited a SQL injection vulnerability in a public-facing web application to place a post-exploitation toolkit, known as khunt, directly inside an Oracle database. Instead of relying on malware files stored on the server, the attackers used the database itself to support deeper access to the surrounding network.

Researchers at Huntress identified the activity after the attackers abused a vulnerable autocomplete search feature in a Java application running on Apache Tomcat. The application did not properly sanitize user input, allowing SQL commands to travel through a JDBC connection to the backend Oracle database.

How the Oracle SQL Injection Attack Worked

The initial weakness was located in an autocomplete search function exposed through the public-facing Java application. Because the application accepted unsanitized input, the attackers were able to send SQL commands to the Oracle database.

From there, they used Oracle’s built-in CREATE JAVA SOURCE statement to compile and save malicious Java code as database schema objects. That approach allowed the attack toolkit to operate from within the Oracle environment rather than existing as conventional files on the Windows server.

Huntress noted that this technique had been theorized before but has rarely been documented in real-world attacks.

Khunt Toolkit Components Stored in the Database

The khunt toolkit included several components designed for different post-exploitation tasks. Java objects were connected through PL/SQL wrappers, allowing the attackers to invoke them with SQL statements.

The identified components included:

  • KhuntCmd: Executes operating system commands
  • KhuntHash: Extracts Oracle usernames and password data
  • KhuntFS: Browses the file system
  • KhuntFS2: Provides additional file-system browsing capability
  • KhuntT: Tests connectivity
  • KhuntUnzip: Extracts compressed files

By keeping these components inside the Oracle database, the attackers avoided the typical file-based footprint associated with malware installed directly on a server.

From Database Access to Windows System Privileges

After confirming that khunt was working, the attackers used KhuntCmd to run the whoami command. The result showed that they had SYSTEM-level privileges on the underlying Windows server.

With that level of access, the attackers used PowerShell and Windows utilities to copy the SAM, SECURITY, and SYSTEM registry hives. These files can be used to recover local account password hashes.

They also enumerated running services on the affected host.

Huntress traced the malicious requests to the IP address 178.162.151[.]229. However, it remains unclear whether the copied registry hives were successfully exfiltrated.

Why Database-Hosted Malware Can Evade Detection

Traditional endpoint detection tools commonly focus on operating system processes and files. They generally do not inspect Java classes or PL/SQL wrappers stored within Oracle databases.

In this case, the attackers used database objects to house their toolkit. That reduced reliance on files written to the Windows server and helped the activity evade file-based detection methods.

The incident points to a security gap for environments where public-facing applications connect to databases with elevated privileges. A vulnerable web application can become an entry point for malicious activity that extends beyond the database itself.

Huntress recommended input sanitization and query parameterization to reduce the risk of SQL injection.

The researchers also advised organizations to ensure that database accounts used by public-facing applications do not have permission to create Java sources or execute administrative stored procedures.

Restricting those permissions can limit what an attacker can do if a public-facing application is compromised through SQL injection.