Despite decades of awareness, SQL injection (SQLi) remains an effective technique for cybercriminals.
A recent Huntress investigation demonstrates how a seemingly routine SQL injection attack evolved into full operating system (OS) compromise through the abuse of Oracle database functionality.
Key takeaways of the SQL injection attack
- A SQL injection vulnerability in a public-facing Java/Tomcat application allowed attackers to gain initial access to an Oracle database and ultimately achieve remote code execution on the underlying Windows server.
- Attackers abused Oracle’s CREATE JAVA SOURCE functionality to deploy the khunt toolkit, demonstrating how legitimate database features can be weaponized to establish persistence and evade traditional endpoint security tools.
- Using the khunt toolkit, the threat actors executed operating system commands, stole credentials from Oracle and Windows, and collected registry hives for potential exfiltration and privilege escalation.
- Organizations can reduce the risk of similar attacks by combining secure coding practices, least-privilege database access, enhanced Oracle monitoring, regular penetration testing, and tested incident response plans.
How the Oracle SQL injection attack began
According to Huntress, the incident began on Jul. 27, 2026, when security analysts detected credential theft activity on a Windows endpoint hosting an Oracle database server.
Investigation revealed that a public-facing Java/Tomcat application failed to properly validate user input, allowing attackers to inject malicious SQL commands.
The vulnerable application passed those commands directly to the Oracle database through a Java Database Connectivity (JDBC) connection, providing the attackers with an initial foothold.
How attackers deployed the toolkit using Oracle Java
What made this attack noteworthy was the method used after the initial compromise.
Rather than deploying malware directly to the operating system, the threat actors uploaded a database-resident toolkit named khunt using Oracle’s CREATE JAVA SOURCE functionality.
Oracle databases include an embedded Java Virtual Machine (JVM), enabling developers to store Java code as database objects.
In this case, attackers abused that legitimate capability to compile and execute malicious Java code directly within the database, creating a stealthy persistence mechanism that traditional endpoint security tools may overlook.
The toolkit consisted of several specialized modules that expanded the attackers’ capabilities.
KhuntCmd enabled execution of arbitrary Windows operating system commands through SQL statements.
KhuntHash extracted Oracle usernames and password information into a file, while KhuntFS and KhuntFS2 provided file browsing, reading, and searching capabilities.
Additional components included KhuntT, which verified the toolkit was functioning correctly, and KhuntUnzip for extracting compressed files.
These modules effectively transformed the Oracle database into a post-exploitation platform capable of interacting directly with the underlying operating system.
How the Khunt toolkit enabled remote code execution (RCE) and credential theft
The khunt toolkit gave the attackers the ability to bridge the gap between the Oracle database and the underlying Windows operating system.
Through its KhuntCmd module, the toolkit allowed attackers to execute arbitrary OS commands by sending SQL statements to the database, effectively turning the database into a platform for remote code execution.
After deploying the toolkit, the attackers used KhuntCmd to execute the whoami command and confirmed they had SYSTEM-level privileges, demonstrating successful remote code execution from the Oracle database to the Windows OS.
They then used PowerShell and Windows utilities to copy the SAM, SYSTEM, and SECURITY registry hives, which contain password hashes that can be extracted for credential theft or privilege escalation.
Before preparing the data for potential exfiltration, the attackers also enumerated running services using tasklist /svc.
How to reduce risk from SQL injection attacks
The Huntress investigation demonstrates that even decades-old attack techniques can have devastating consequences when basic security controls are overlooked.
In this case, a SQL injection vulnerability allowed attackers to move beyond the database and achieve remote code execution by abusing legitimate Oracle functionality.
Organizations can reduce the risk of similar attacks by implementing layered security controls that strengthen prevention, detection, and response across their Oracle environments.
- Implement parameterized queries and proper input validation to protect against SQL injection vulnerabilities before they can be exploited.
- Enforce the principle of least privilege by limiting database accounts’ ability to create Java source objects, execute stored procedures, or perform administrative actions.
- Expand monitoring beyond endpoint detection by auditing Oracle database objects, SQL logs, and unexpected Java source creation for signs of malicious activity.
- Regularly search Oracle environments for known indicators of compromise, including suspicious Java objects, KHUNT% entries in SQL logs, and attacker-created registry hive artifacts.
- Harden Oracle and application environments by restricting unnecessary database features, securing database credentials, and segmenting database servers from public-facing applications.
- Incorporate penetration testing assessments into the software development lifecycle to identify vulnerabilities before deployment.
- Test incident response plans and use attack simulation tools with scenarios around SQL injection attacks and RCE.
Collectively, these steps can help organizations reduce their overall attack surface, limit the blast radius of successful compromises, and build long-term resilience.
Bottom line
The strategic risk isn’t the SQL injection alone — it’s what follows.
Once attackers established a foothold, they turned the Oracle database into an execution platform that enabled RCE while remaining largely outside the scope of conventional endpoint monitoring.
As adversaries continue to blend legitimate platform capabilities with established attack techniques, security leaders should reassess whether their detection strategy provides sufficient visibility into database-resident threats, not just activity occurring on the operating system.
Incidents like this also highlight the value of a Zero Trust architecture, which is designed to limit implicit trust and contain the impact of a successful compromise.