"The use of the technique in the wild has rarely been documented," Huntress said.
Huntress discovery on July 27, 2026
Security firm Huntress detected credential-theft activity on a server hosting an Oracle database on July 27, 2026. Its platform flagged credential theft and, after investigation, the team traced malicious requests to the IP address 178.162.151[.]229. Apache access logs showed the attackers had abused a vulnerable search endpoint in a public-facing Java application running on Apache Tomcat to reach the database.
SQL injection through an autocomplete search endpoint
The intrusion began with a classic web-layer weakness: an autocomplete search feature that failed to validate user-supplied input. According to Huntress, that missing validation let attackers inject SQL commands into the Oracle database. The vulnerable component was identified in a public-facing Java application served by Apache Tomcat, and the access logs provided the forensic trail linking the activity to the external IP address recorded by Huntress.
Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coverageAbuse of Oracle’s embedded JVM and CREATE JAVA SOURCE
Rather than dropping executable files on disk, the attackers installed a post-exploitation toolkit directly inside the Oracle database as a Java object. Huntress detailed how the attackers leveraged Oracle’s embedded Java Virtual Machine and the CREATE JAVA SOURCE statement, which permit Java source code to be stored and compiled as a database schema object. Those database-resident Java objects can be executed via SQL statements and, if the database is configured to allow it, can run commands on the host operating system. Huntress emphasized that using this technique in live intrusions has been only rarely documented.
khunt toolkit components and observed actions
Huntress identified the toolkit stored in the database as the khunt post-exploitation toolkit. The toolkit included multiple Java components and PL/SQL wrappers that the attackers used to execute commands, harvest credentials, and manipulate files. Huntress listed the components and their observed capabilities:
- KhuntCmd — launched cmd.exe and allowed operating-system command execution through SQL statements; Huntress recorded the attackers running cmd.exe /c whoami to verify privileges.
- KhuntHash — accessed Oracle’s internal user table and wrote usernames and password data to a file.
- KhuntFS and KhuntFS2 — provided file browsing, reading, searching, and file-size checking capabilities.
- KhuntT — acted as a ping-like test to confirm successful installation of the toolkit.
- KhuntUnzip — extracted compressed files.
Using KhuntCmd, the attackers confirmed that commands executed through the Oracle database ran with SYSTEM-level permissions on the Windows server. Huntress observed the actors using PowerShell and Windows utilities to copy the SAM, SECURITY, and SYSTEM registry hives — artifacts that can be used to recover password hashes for local Windows accounts. Huntress noted the registry hives were likely intended for credential-dumping, but the report does not confirm whether those files were successfully exfiltrated. The attackers also ran tasklist /svc and saved the output to a file named khunttasks.txt.
Recommendations and defensive posture for database-backed apps, security teams, and defenders
Huntress offered specific remediation guidance tied to the mechanisms observed. At the application level, organizations should sanitize all user-supplied input to prevent SQL injection. At the database-account level, Huntress recommends limiting the privileges granted to accounts used by public-facing applications: such accounts should not have privileges sufficient to create Java sources, execute unnecessary stored procedures, or perform other administrative actions within the database. Those constraints would prevent attackers who achieve SQL injection from compiling and executing Java objects inside the database.
Huntress’ findings also underline detection gaps: the source notes a cited statistic — "Security teams log 54% of successful attacks and alert on just 14%." That observation, included in the same reporting, frames why attackers embedding tooling in a database can move stealthily if logging and alerting are insufficient.
Conclusion
This incident illustrates a less-often-discussed escalation path: once an attacker can send SQL to an Oracle instance, they can compile and run Java code inside the database itself and, under permissive configurations, execute operating-system commands with high privileges. Huntress’ recommendations — sanitize inputs and strip excessive database privileges from public-facing accounts — map directly to the observed attack chain and represent the immediate, actionable steps cited to reduce this specific risk.
