khunt Alert: Post-Exploitation Toolkit Runs Directly Inside Oracle Database

Huntress researchers say attackers exploited a SQL injection flaw in a public-facing Java application to install the khunt post-exploitation toolkit directly inside Oracle Database, instead of dropping a traditional executable on the server.

Key points of the incident

According to BleepingComputer, Huntress discovered the attack on July 27, 2026 after its monitoring platform detected signs of credential theft on a server running Oracle Database. Apache logs showed the entry point was an autocomplete search endpoint in a Java application running on Apache Tomcat.

The application did not strictly validate input, allowing the attackers to send SQL commands to the Oracle database. From there, they installed khunt as a Java object inside the database, abusing Oracle's embedded Java Virtual Machine and the ability to store and compile Java code with the CREATE JAVA SOURCE statement.

Why this technique is dangerous

The troubling part is that the payload does not necessarily appear as a familiar malware file on the filesystem. Once a Java object and PL/SQL wrapper are stored in the database schema, attackers can execute operating-system commands through SQL if the application account has excessive privileges.

Huntress observed khunt components capable of running Windows commands, accessing Oracle internal user tables, browsing and reading files, searching for files, checking file sizes, and extracting data. One test command showed code executing as SYSTEM on the Windows host, significantly increasing the risk of post-exploitation escalation.

Signals and impact to watch

After installing the toolkit, the attackers used PowerShell and Windows utilities to copy the SAM, SECURITY, and SYSTEM registry hives. These files are commonly used in local credential theft or cracking workflows. The attackers also listed running services with tasklist /svc and saved the output to a file on the system.

BleepingComputer says Huntress traced the malicious request to IP address 178.162.151[.]229. The report has not confirmed whether the registry data was exfiltrated, but the behavior clearly points to an attempt to expand control after initial access.

Defensive Recommendations

Organizations running web applications that connect directly to databases should review their input validation layer, especially search, autocomplete, and dynamic-query endpoints. SQL injection is an old risk, but its impact can be far more serious when the database account is granted more privileges than the business function requires.

For Oracle Database, strictly limit the ability to create Java source, run unnecessary stored procedures, and hold administrative privileges from public-facing application accounts. Operations teams should also monitor for unusual schema objects, PL/SQL wrappers, Java object creation, access to internal user tables, and registry hive copying on Windows servers.

The khunt incident is a reminder that database defense does not stop at patching and firewalls. Least privilege, deep logging, and periodic checks for unusual database objects can decide whether an intrusion is detected before attackers move on to credential theft.

VNCyberS compiled from BleepingComputer and Huntress