Huntress reported attackers used SQL injection to plant khunt inside Oracle and pivot to Windows for command execution and credential theft.
Security vendor Huntress recently disclosed an intrusion targeting an Oracle database. The attacker first infiltrated the system through a SQL injection entry point, then wrote a post-exploitation toolkit named khunt into the Oracle database, and finally used the database as a pivot to execute malicious commands on a Windows host and attempt credential theft.[1][4]
This technique drew attention because the attacker did not drop the toolkit as a conventional executable or file. Instead, they used Oracle’s built-in Java VM and CREATE JAVA SOURCE to store the Java source code directly as a database object, allowing the tool to persist as a database object. Huntress noted that this is a relatively uncommon approach, but one that has been discussed in research as an oraexec-type technique.[1][4]
The overall attack chain can be divided into initial compromise, database persistence, and host-level expansion. First, the attacker exploited a web application that failed to properly handle input, triggering SQL injection and gaining control of the Oracle database.[4]
Next, the attacker abused OJVM and CREATE JAVA SOURCE to compile khunt’s Java code into an internal object that could be called through SQL. This design allowed the malicious code to exist not as a disk file or merely as a memory-resident payload, but directly inside the database, increasing the visibility blind spots of common endpoint defenses.[1][4][16]
khunt includes multiple modules. KhuntCmd can invoke Windows cmd.exe through Java, allowing the attacker to turn specific SQL statements into OS command execution. KhuntHash can read Oracle internal user tables and export account names and password hashes. KhuntT is used to confirm that the toolkit has been deployed successfully. KhuntUnzip is used to extract compressed files.[4][16]
In this incident, the attacker actually used KhuntCmd to open a Windows command shell, achieving remote code execution through cmd.exe and obtaining SYSTEM privileges.[2][16] They later used reg.exe, esentutl.exe, and PowerShell to manipulate the Windows Registry, copying the SECURITY, SYSTEM, and SAM registry hives to facilitate later extraction and decoding of local account password hashes.[2][6][16]
The key issue in this type of attack is not only data theft via SQL injection, but the conversion of the database into an execution platform. Once the malicious object resides inside the database, the attacker can repeatedly trigger Java methods through SQL and PL/SQL wrappers, creating a complete attack chain from web application to database to Windows OS.[1][4][6]
The direct risk of this incident is that both the Oracle database–hosted application services and the Windows host are exposed to high-privilege compromise. If the attacker successfully obtains SYSTEM-level control, they can not only execute arbitrary OS commands, but also further access registry hives, account hashes, and system settings, increasing the risk of credential leakage and lateral movement.[2][16]
More importantly, traditional EDR and antivirus products usually focus on process behavior, function calls, and file activity, and have limited visibility into Java classes and PL/SQL wrappers inside the Oracle database. As a result, even when host-level protections are in place, the attacker may still persist quietly at the database layer and repeatedly execute commands.[1][16]
From a defensive perspective, the affected surface is not just a single database, but any environment that exposes Oracle databases to web applications and lacks input validation and parameterized queries. If the database account has excessive privileges, an attacker may escalate from ordinary user queries to the ability to create Java source and invoke stored procedures, creating a highly impactful privilege abuse scenario.[1][4]
First, application-layer input sanitization and query parameterization must be implemented to prevent user input from flowing directly into SQL statements. This is the fundamental control for blocking SQL injection and the most important control point at the front of the entire attack chain.[1][4]
Second, Oracle database account privileges should be reviewed strictly, especially whether accounts are allowed to create Java source, call high-risk stored procedures, or access unnecessary system capabilities. If database privileges are too broad, even an attacker who obtains only a normal account may be able to expand into OS command execution with elevated privileges.[1][4]
Third, enterprises should not rely solely on EDR or antivirus. Because this kind of malicious toolkit exists as a database object, organizations should also strengthen SQL auditing, alert on abnormal object creation, and review CREATE JAVA SOURCE, PL/SQL wrappers, and suspicious stored procedures.[1][16]
Fourth, organizations should minimize exposure for externally facing Java/Tomcat applications and Oracle databases, avoiding unnecessary external connections and keeping management interfaces off the Internet. The larger the attack surface, the easier it is for attackers to find a SQL injection point with a low barrier to entry.[4][19]
Fifth, if suspicious Java objects, unusual SQL statements, or coordinated use of reg.exe, esentutl.exe, and PowerShell appear on Windows hosts, incident response should begin immediately. This includes isolating the host, checking whether registry hives were exfiltrated, reviewing database object change logs, and rebuilding affected accounts and credentials.[2][16]
5-Step Remediation Checklist