Oracle Database Hijacked for Tool Storage

A sophisticated post-exploitation toolkit has been discovered residing directly within an Oracle database as compiled schema objects. This method allows attackers to maintain command execution capabilities on a Windows server from a location that traditional endpoint security solutions are not designed to monitor.

Huntress identified this activity on July 27 after spotting credential theft alerts on a host that was running an Oracle database server. The firm subsequently released an analysis of the incident on August 5.

Entry Via SQL Injection

The initial breach did not rely on a software vulnerability. Instead, attackers utilized SQL injection within the autocomplete search feature of a public-facing Java application that was running on Apache Tomcat.

The application transmitted unvalidated input to the database via a Java Database Connectivity (JDBC) connection. Critically, the connection used an account that held permissions to create Java objects, which provided the necessary leverage for the attackers to establish their foothold.

Database as a Foothold

Oracle databases include an embedded Java Virtual Machine (JVM) along with a statement that allows for the storage of Java source code as a database object. By feeding this specific statement through the injection point, the attackers prompted the database to compile the code into stored schema objects.

The resulting toolkit is known as khunt. Its modular nature allows it to operate from within the database environment, effectively masking its presence from standard security monitoring tools that typically focus on external files, processes, or memory-resident payloads.

“To avoid these types of attacks, it's important to ensure the forms aren't injectable,” Huntress wrote. “Practice proper input sanitization and query parameterization for any inputs. It's also important to ensure that users with the ability to execute queries aren't overprovisioned.”

— Huntress, in their published analysis.

Avoiding Endpoint Detection

The primary challenge highlighted by the incident is the visibility gap in conventional security tooling. Because the toolkit exists as Java classes and PL/SQL wrappers inside the Oracle database, it remains outside the scope of most endpoint detection products.

By storing the toolkit as a database object rather than a traditional file, the attackers effectively transformed the database from a repository for data into a functional base of operations. This approach allows for persistent command execution while remaining largely invisible to standard security telemetry.

Mitigation and Implications

The incident underscores the risk posed when database service accounts are granted excessive privileges. When an application is allowed to create Java objects within a database, any successful SQL injection can be escalated into full server-side control.

For organizations, the primary defense involves rigorous input validation and the principle of least privilege. Ensuring that database users are not overprovisioned is essential to preventing attackers from leveraging legitimate database features to hide malicious toolkits and evade detection systems.