Attackers hid malware inside Oracle Database after SQL injection breach

Huntress has documented a case where the Oracle database itself became the malware host.

The security firm disclosed a campaign in which threat actors exploited a SQL injection vulnerability to store a custom post-exploitation toolkit, dubbed Khunt, inside an Oracle database using the platform’s built-in Java capabilities.

Huntress became aware of the intrusion after investigating a credential theft activity on a server running Oracle Database. The researchers learned that rather than simply executing commands through SQL injection, the attackers had leveraged Oracle’s embedded Java Virtual Machine (OJVM) to upload, compile, and execute malicious Java code directly from within the database.

The approach reportedly allowed the attackers to blend into legitimate database functionality while maintaining a persistent foothold on the compromised server.

“The attackers managed to gain initial access in this attack thanks to a classic SQL injection,” Huntress researchers said in a blog post. “There was no need for a novel vulnerability because the autocomplete search feature in the public-facing application was enough to reach PL/SQL and then the operating system.”

Exploitation beyond SQL injection

The attack revolved around Khunt, a Java-based toolkit that attackers stored as a database object using Oracle’s “CREATE JAVA SOURCE” functionality. Oracle Database includes an embedded Java Virtual Machine that allows organizations to execute Java code from within the database for legitimate business applications.

Once compiled inside the database, the Java code could be run through SQL statements to execute operating system commands on the underlying host where Oracle was configured. The malware inserted within the database schema would be considerably harder to detect, Huntress noted.

After setting up the code execution path from within the database, the attackers could (and did) carry out post-compromise activities, including credential theft.

In the incident Huntress investigated, the attackers ultimately compromised the Windows server hosting Oracle Database, escalating from SQL injection to SYSTEM-level command execution. With that level of access, they were able to dump the Windows SAM, SECURITY, and SYSTEM registry hives, enabling offline extraction of local account password hashes.

The campaign’s non-reliance on noisy malware binaries and incorporation of the malice entirely within Oracle’s native functionality was flagged by researchers as an evolved operation that calls for targeted detection.

Oracle did not immediately respond to CSO’s requests for comment.

Mitigation focused on post-exploitation toolkit 

While the SQL injection pathway provided the initial foothold, Huntress argues that the more important lesson lies in what happened after exploitation.

The attackers could have simply extracted or manipulated data through SQL injection, but instead, they expanded the exploit to include long-term persistence and remote command execution. Huntress warned that this is a dangerous evolution.

Features such as Oracle’s embedded JVM, while valuable for enterprise workloads, can also expand the blast radius with sufficient database privileges. “To avoid these types of attacks, it is important to ensure the forms aren’t injectable,” the researchers said. “It’s also important to ensure that users with the ability to execute queries aren’t overprovisioned.”

Huntress recommended looking beyond indicators of SQL injection during incident response. Examining Oracle environments for unexpected Java source objects, compiled Java classes, and stored procedures could indicate abuse of the embedded Java Virtual Machine, it said. The firm also shared indicators of compromise (IOCs), including file hashes, malicious Java artifacts, SQL statements, and search terms to help defenders identify affected systems.