Attackers hid malware inside Oracle Database — a SQL injection breach that went native

Attackers hid malware inside Oracle Database — a SQL injection breach that went native

Huntress researchers documented a campaign where the Oracle database itself became the malware host. Threat actors exploited a SQL injection flaw in a public-facing application, then used Oracle’s embedded Java Virtual Machine to upload, compile, and execute a custom post-exploitation toolkit directly from within the database.

The toolkit, dubbed Khunt, was stored as a database object using Oracle’s CREATE JAVA SOURCE functionality. Once compiled inside the database, the Java code could be executed through SQL statements to run operating system commands on the underlying host. The attackers moved from initial SQL injection to SYSTEM-level command execution on the Windows server hosting Oracle, ultimately dumping Windows registry hives for offline password hash extraction.

Why this matters for African enterprise

Oracle Database runs the core banking and transaction systems across much of the African fintech sector. A compromise at the database layer — especially one that lives inside legitimate database objects — bypasses traditional endpoint detection entirely. The malware never touched the filesystem as a binary; it lived in PL/SQL and Java source stored in the data dictionary.

This is not a theoretical risk. The Huntress investigation started with credential theft on a server running Oracle Database. The attackers used a classic SQL injection in an autocomplete search feature to reach PL/SQL, then the operating system. No zero-day required — just an unpatched injection flaw and an overprovisioned database account.

The blind spot in current defences

Most security tooling looks for malicious binaries, suspicious processes, or anomalous network traffic. Khunt produced none of those. The malicious Java code executed inside the Oracle JVM, invoked through legitimate SQL statements. To the operating system, it looked like normal database activity. To the database, it looked like legitimate Java stored procedures.

• No filesystem artefacts — the payload lives in USER_SOURCE and USER_OBJECTS
• No network beacon — command execution happens via SQL, not a reverse shell
• Persistence survives database restarts — the code is part of the schema

Huntress warns that incident responders must look beyond SQL injection indicators. Unexpected Java source objects, compiled Java classes, and stored procedures in Oracle environments can signal abuse of the embedded JVM.

Mitigation: reduce the blast radius

The researchers’ advice is practical: fix the injection flaws first, but also audit database privileges. Accounts that can execute arbitrary SQL should not have CREATE JAVA SOURCE or CREATE PROCEDURE privileges unless explicitly required.

For African operators running Oracle on-premises or in hybrid environments, this means:

1. Patch and WAF the application layer — the autocomplete search feature was the entry point
2. Enforce least privilege on database service accounts — remove Java privileges where not needed
3. Monitor DBA_SOURCE and DBA_OBJECTS for unexpected Java artifacts
4. Include Oracle JVM abuse in tabletop exercises — it is a blind spot for most SOC teams

eHawu operates at the network layer, where database traffic is visible before it reaches the application. Our agentless architecture sees the SQL injection attempt, the anomalous Java compilation, and the command execution flow — without installing anything on the database server. When the database itself becomes the attack platform, network-layer visibility is the only layer that catches the full chain.