Oracle Database Exploited to Hide Post-Exploitation Toolkit

"To avoid these types of attacks, it's important to ensure the forms aren't injectable," Huntress wrote.

Huntress detected the intrusion on July 27 and published analysis on August 5

Huntress discovered the activity on July 27 after credential-theft alerts fired on a host running an Oracle database server, and published its analysis on August 5. Researchers traced the initial interaction to requests in Apache access logs that pointed to a single IP address. The firm’s timeline links a public-facing Java application to the first successful action by the attacker.

SQL injection in an autocomplete search of a Java app running Apache Tomcat

The entry vector was SQL injection in the autocomplete search feature of a public-facing Java application running on Apache Tomcat. Huntress emphasized that no vulnerability in the server software was exploited; instead, the application passed unvalidated input to the database over a Java Database Connectivity (JDBC) connection. Crucially, that JDBC account was permissioned to create Java objects in the database — a capability the attacker used to escalate from query to code execution.

Oracle's embedded JVM let attackers compile a toolkit inside schema objects

Oracle Database ships with an embedded Java Virtual Machine and provides a statement that stores Java source code as a database object. Through the injection point, the attacker fed that statement to the database; Oracle compiled the supplied Java into stored schema objects. Huntress identified the resulting toolkit as khunt, a name reflected across module names and files the attack wrote to disk.

khunt's components: shell, credential dumper, explorers, unzip, and PL/SQL wrappers

Huntress cataloged khunt’s modules. They included a component that opened a Windows command shell to run arbitrary operating-system commands and a credential dumper that read Oracle’s internal user table and wrote usernames and passwords to a file. The toolkit also contained two file explorers, an unzip utility, a reachability check to confirm the toolkit was live, and a set of PL/SQL wrappers used to invoke the underlying Java methods.

From database foothold to SYSTEM-level activity and copied registry hives

After compiling in the database, the attacker pivoted to the operating system by opening a Windows command shell and confirmed SYSTEM-level privileges. Using PowerShell, they invoked the Windows registry tool to copy the SECURITY and SYSTEM hives, enumerated running services, and then copied the SAM and SECURITY hives using the Extensible Storage Engine utility. Huntress assessed that the hives were staged for credential dumping and probable exfiltration, and described the activity as an attempt rather than a confirmed theft.

What this means for technologists, enterprises, and policymakers

• Technologists and security teams: The immediate detection gap Huntress highlights is that storing a toolkit as database schema objects places it outside the focus of most endpoint tools, which generally inspect processes, binaries and files rather than Java classes and PL/SQL wrappers inside Oracle. Huntress’s mitigation guidance is direct: ensure inputs are not injectable, practice proper input sanitization and query parameterization, and avoid giving query-execution privileges to overprovisioned accounts.
• Enterprises and procurement leaders: Organizations running public-facing applications should review JDBC account privileges (particularly the ability to create Java objects), monitor database-supplied JVM artifacts and unexpected schema objects, and correlate web server logs with database activity — Apache access logs were key to attributing this intrusion to a single IP in Huntress’s analysis.
• Policymakers and regulators: The case demonstrates a technical blind spot where conventional endpoint-focused controls can miss persistent footholds kept inside database schema. That gap may inform guidance or requirements around secure application development practices, least-privilege database accounts, and logging/monitoring expectations for critical database services.

Huntress labeled the use of Oracle’s embedded JVM in this way as a notable, if not entirely novel, tactic: documented cases have been rare, but the firm warned that the technique turns a database from a data store into a persistent foothold. Its closing prescription reiterates the basics that stopped this attack vector at the start — sanitize inputs, parameterize queries, and reduce unnecessary privileges for accounts that can execute queries.

https://www.infosecurity-magazine.com/news/khunt-toolkit-oracle-database-sql/