Attackers Compile khunt Inside Oracle to Turn SQL Injection Into Windows SYSTEM Access

# When the Database Becomes the Weapon: Inside Oracle's khunt Compromise

The autocomplete search bar on a public web application. That's where this one started. Not a zero-day. Not a sophisticated supply chain attack. An input field nobody validated, connected to a database account with more privileges than it had any business holding.

What happened next is the part that should concern anyone running Oracle on Windows — and probably a few people who thought their EDR had them covered.

## The Autocomplete That Opened a Beachhead

Huntress traced the attack after credential-theft detections fired on July 27, 2026. The chain led back to a JDBC connection serving a search field. User input was flowing straight into database queries, unsanitized. The account behind that connection could create Java objects inside Oracle.

From there, the attackers did something most defenders aren't watching for: they didn't drop a binary. They didn't write an executable to disk. They handed Java source code to the database itself, and let Oracle's embedded JVM compile it.

Oracle has shipped a built-in Java Virtual Machine for a long time. The CREATE JAVA SOURCE statement lets a sufficiently privileged user feed it code that gets compiled and stored as a schema object. The resulting objects aren't processes. They aren't files on the filesystem. They live inside Oracle's internals, invisible to the endpoint detection tools watching for suspicious executables and unusual process trees.

The six objects Huntress calls the "khunt" toolkit divide the labor cleanly:

PL/SQL wrappers published the Java methods as callable SQL functions. Running cmd.exe /c whoami through KhuntCmd returned SYSTEM. The attackers then used PowerShell and reg.exe to copy the SECURITY and SYSTEM registry hives into Oracle's directory, ran tasklist /svc, and extracted SAM and SECURITY hive copies via esentutl.exe. Classic credential-staging playbook — whether those files left the network, Huntress couldn't confirm.

## A Twenty-Year Technique Finally Gets Its Documented Outing

The raw technique isn't new. Marco Ivaldi published raptor_oraexec.sql in 2006 — same basic architecture, Java objects in Oracle schema, Runtime.exec to the OS. Researchers have known Oracle's embedded JVM could be weaponized this way for two decades. What's notable here is how rarely it's shown up in actual incident reports.

Huntress said as much directly: "the use of the technique in the wild has rarely been documented."

That's worth sitting with. A two-decade-old attack primitive, documented in public research, with the mechanism well understood — and until now, barely any evidence of real-world exploitation. A few possibilities explain the gap: most attackers don't need this level of sophistication against typical targets; Oracle databases running on Windows with public-facing JDBC connections aren't everywhere; or — and this is the uncomfortable one — defenders simply haven't been looking in the right place.

Oracle schemas aren't where your SOC is hunting. Log aggregation from Oracle's internals requires deliberate configuration. EDR products that watch process creation and file writes don't have visibility into what's running inside the database engine. The khunt toolkit exploits exactly that gap.

## What Defenders Should Be Doing Right Now

The indicators are specific to this toolkit, but the hunting approach generalizes:

For Oracle installations:

The structural fix: parameterized queries and input validation at the application layer, combined with least-privilege enforcement at the database layer. An account serving a public search field should not be able to author Java sources. That combination of privileges — web-exposed + Java-authoring — is the attack surface here, and closing one or the other breaks the chain.

Oracle's own documentation says that CREATE JAVA SOURCE requires only the CREATE PROCEDURE system privilege within a user's schema, which is a lower bar than most administrators probably assume. Audit your grants accordingly.

No Oracle patch exists because no Oracle vulnerability exists in the traditional sense. The application failed. The account was overprivileged. Oracle performed exactly as designed.

## HackWire Analysis

The khunt incident is a useful corrective to how the security industry talks about detection coverage. The conventional narrative is that modern EDR, combined with behavioral analytics, has made "living off the land" attacks increasingly visible. That's broadly true for the Windows attack surface: LOLBAS techniques, process injection, credential dumping from LSASS — defenders have gotten meaningfully better at catching these.

But "living off the database" sits outside that coverage map, and it has for years. Oracle's embedded JVM, SQL Server's xp_cmdshell, PostgreSQL's COPY TO/FROM PROGRAM — database engines with OS-interaction capabilities represent a class of execution primitive that most EDR vendors have underinvested in detecting, partly because it requires deep integration with the database internals rather than the host OS.

The two-decade lag between Ivaldi's 2006 proof-of-concept and this documented incident doesn't mean the technique was dormant. It might mean we weren't seeing it. Absence of evidence in incident reports is not evidence of absence in actual intrusions. Attacks that don't trigger endpoint alerts don't generate incident reports.

What's changing now: attackers with SQL injection footholds increasingly have database accounts with more privileges than they should, because applications were built without least-privilege discipline. As organizations move Oracle databases to Windows environments with tighter network perimeters, the database-as-beachhead pattern becomes more attractive — the OS is reachable through the database when the network path is blocked.

The fix isn't exotic. Parameterized queries and least-privilege accounts would have stopped this cold. The fact that a 2026 breach started with an unvalidated autocomplete field and an overprivileged JDBC account is a failure of fundamentals, not a failure of tooling.

Every Oracle shop running Windows should be auditing schema object permissions this week. The khunt objects are specific; the underlying technique is not.

— HackWire Editorial

---

## Related Coverage