Hackers Run khunt Post-Exploitation Toolkit from Oracle Database

Security researchers at Huntress have documented a novel in-the-wild attack technique in which threat actors compiled and executed a post-exploitation toolkit called khunt directly inside a victim's Oracle database — achieving Windows SYSTEM-level access without dropping a single file to disk. The technique abuses Oracle's embedded Java Virtual Machine (JVM) and represents a significant evolution in fileless attack methodology.

The Attack Chain

The intrusion began on July 27, 2026, when Huntress telemetry flagged anomalous activity: reg.exe registry hive-copy operations (targeting the SAM, SECURITY, and SYSTEM hives for credential extraction) with an unusual parent process — oracle.exe. That parent-process relationship is the hallmark of this attack.

Initial Access: SQL Injection

Attackers exploited a SQL injection vulnerability in a vulnerable autocomplete search endpoint of a public-facing Java application running on Apache Tomcat. The attacker IP traced was 178.162.151[.]229. Crucially, the database account associated with that application had been granted CREATE JAVA SOURCE privileges — a common but dangerous misconfiguration.

The khunt Toolkit

Once SQL injection was established, attackers used Oracle's CREATE JAVA SOURCE statement to compile khunt's components directly as Java schema objects inside the database's embedded JVM. No executables were written to the filesystem:

All components are wrapped in PL/SQL procedures, making them callable like any other database stored procedure. The result: a fully functional remote access toolkit hidden inside what looks like normal database objects.

Why This Is Significant

The technique — sometimes called "oraexec" in theoretical research — has been documented conceptually but this represents one of the first confirmed in-the-wild deployments. It is significant for several reasons:

Endpoint detection evasion: Traditional EDR products look for malicious executables on disk and suspicious process trees. When the attacker's code lives as Java schema objects inside oracle.exe, most endpoint tools see only a database process doing database things — until commands execute.

Privilege inheritance: Oracle databases on Windows frequently run as SYSTEM. Anything compiled and executed within the JVM inherits that privilege level, giving attackers the highest possible access from a SQL injection entry point.

Persistence via database objects: The compiled Java classes persist in the database until explicitly removed, surviving reboots and service restarts.

Affected Environments

Organizations are at risk if they:

• Run Oracle Database on Windows
• Have internet-facing Java/Tomcat applications connected to Oracle
• Allow the database account used by the application to have CREATE JAVA SOURCE privileges
• Lack input validation on search or autocomplete endpoints

Remediation

1. Audit Java privileges: Remove CREATE JAVA SOURCE, CREATE ANY JAVA, and related privileges from application service accounts
2. Review existing Java objects: Query DBA_JAVA_CLASSES and DBA_SOURCE for unexpected entries
3. Patch SQL injection: Validate and sanitize all user input; use parameterized queries
4. Monitor process trees: Alert on oracle.exe spawning cmd.exe, powershell.exe, or reg.exe
5. Apply least privilege: Application database accounts should only have SELECT, INSERT, UPDATE, DELETE on required tables

Key Takeaways

• khunt achieves fileless post-exploitation by compiling Java toolkit components directly inside Oracle's embedded JVM
• SQL injection in a connected web application was the initial access vector
• The attack achieved Windows SYSTEM access via Oracle's inherited process privilege
• CREATE JAVA SOURCE privilege on application accounts is the enabling misconfiguration
• Huntress detected the intrusion through anomalous process parentage: oracle.exe spawning reg.exe