Database-Resident 'KHunt' Malware Turns Oracle SQL Injection Into Full Host Compromise
Attackers bypassed traditional security tools by installing a post-exploitation toolkit directly into an Oracle database as Java objects.
A critical security breach has revealed a sophisticated method for achieving full system control by treating a database not as a target, but as a staging ground for malware. By exploiting a standard web vulnerability, attackers deployed a custom toolkit called 'khunt' directly into an Oracle database, bypassing traditional endpoint detection and response (EDR) tools to gain SYSTEM-level access to a Windows server.
The attack began with a SQL injection flaw in the autocomplete search feature of a public-facing Java/Tomcat application that connected to an Oracle database via JDBC. Once inside, the attackers abused Oracle's embedded Java Virtual Machine (JVM) and the 'CREATE JAVA SOURCE' functionality. This allowed them to compile the khunt toolkit as schema-resident Java objects and PL/SQL wrappers. Because the malware resided entirely within the database engine rather than as binaries on the disk, it remained invisible to file-based antivirus and EDR scanners.
The Anatomy of KHunt
The khunt toolkit was designed for comprehensive post-exploitation. The toolkit featured several specialized modules: KhuntCmd for executing operating system commands, KhuntHash for dumping credentials, and KhuntFS/KhuntFS2 for exploring the file system. Additionally, the attackers utilized KhuntT for reachability checks and KhuntUnzip for extracting archives.
This architecture allowed the attackers to operate with the privileges of the Oracle service. Because the database was running with SYSTEM rights on the Windows host, the attackers inherited these permissions. This enabled them to use native tools like reg.exe and esentutl.exe to dump the SAM, SECURITY, and SYSTEM registry hives, effectively compromising the entire server's identity and credential store.
A Shift in the Threat Model
This incident highlights a catastrophic failure in the principle of least privilege. The application's database account was over-privileged, granting it the ability to create and execute Java sources. As a result, a vulnerability at the web tier was escalated into a total host compromise.
This materially shifts the Oracle threat model. The database itself becomes attacker infrastructure, not just a data store. By avoiding the filesystem, the malware avoids the primary triggers that security tools use to flag suspicious activity, as the malicious actions appear to originate from the trusted oracle.exe process.
Detection and Future Outlook
The activity was eventually detected by Huntress on July 27, 2026. The breach was uncovered after telemetry flagged suspicious registry hive-copy operations originating from the oracle.exe process, which is not typical behavior for a database engine.
Security teams are now urged to audit database permissions, specifically restricting the ability to create Java sources and ensuring that database services do not run with SYSTEM-level privileges. The case serves as a warning that database-resident malware can provide a stealthy, persistent foothold that evades traditional perimeter and endpoint defenses.