A post-exploitation toolkit was discovered compiled and stored inside an Oracle database as schema objects, allowing attackers to execute commands on the underlying Windows server from a location that conventional endpoint security tools don't inspect. Huntress detected the intrusion on July 27 after credential theft alerts triggered on a host running an Oracle database server, and published its analysis on August 5. The entry point was SQL injection in the autocomplete search feature of a public-facing Java application running Apache Tomcat, where the application passed unvalidated input to the database over a Java Database Connectivity (JDBC) connection.
The attacker exploited a JDBC connection using an account with permissions to create Java objects, feeding a statement through the injection point that stored Java source code as a database object. Oracle's embedded Java Virtual Machine then compiled the code into stored schema objects. The toolkit, named khunt after the naming convention used across its modules and disk-written files, included a module that opened a Windows command shell for arbitrary operating system commands and a credential dumper that read Oracle's internal user table and wrote usernames and passwords to a file. Additional components included two file explorers, an unzip utility, a reachability check to confirm the toolkit was operational, and a set of PL/SQL wrappers to call the underlying Java methods. The attacker pivoted from the database to the operating system by opening a Windows command shell and confirming SYSTEM-level privileges, then used PowerShell to invoke the Windows registry tool, copying the SECURITY and SYSTEM hives, enumerating running services, and copying the SAM and SECURITY hives with the Extensible Storage Engine utility.
Huntress assessed the hives were staged for credential dumping and probable exfiltration, describing the activity as an attempt rather than a confirmed theft, with Apache access logs tracing the requests to a single IP address. The firm called the technique's use here a novel aspect of the attack, noting that documented cases in the wild have been rare. According to the report, storing the toolkit as a database object rather than a file or memory-resident payload leaves it outside the scope of most security tooling, since endpoint products focus on processes, binaries, and files rather than Java classes and PL/SQL wrappers inside Oracle.
The detection problem centers on how security tooling approaches databases. When attackers store malicious code as database objects instead of traditional files or in-memory payloads, they operate in a space that endpoint detection products typically ignore because those tools inspect processes, executables, and file systems but not the internal structure of database schemas. This transforms the database from something attackers query for data into a foothold they can operate from, giving them a persistent presence that scans won't catch. The report recommends ensuring forms aren't injectable through proper input sanitization and query parameterization for any inputs, and ensuring that users with the ability to execute queries aren't overprovisioned. Organizations running Oracle databases with public-facing applications need to audit both the security of their input validation and the privilege levels granted to database accounts used by those applications. The gap between where attackers can hide and where security tools actually look represents a structural blind spot that won't close without rethinking how databases themselves are monitored. For enterprises treating databases purely as data stores rather than potential attack platforms, this incident suggests a fundamental reassessment of where defensive resources should focus.