# Khunt Post-Exploitation Toolkit Deployed via Oracle Database JVM (Huntress Discovery)

> Huntress researchers detected attackers exploiting a SQL injection vulnerability in a public-facing Apache Tomcat Java application to deploy the 'khunt' post-exploitation toolkit as Java objects inside an Oracle database via CREATE JAVA SOURCE. The toolkit achieved SYSTEM-level command execution (whoami), credential harvesting of SAM/SECURITY/SYSTEM registry hives via reg.exe and esentutl.exe, file system browsing, and service enumeration. The technique abuses Oracle's embedded JVM for fileless persistence that bypasses traditional EDR/AV inspection.

- **Published:** 2026-07-27T00:00:00Z
- **Last reviewed:** 2026-07-27T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1903
- **ID:** TL-2026-1903
- **Severity:** CRITICAL
- **Category:** MALWARE
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 10 (full data via the Threadlinqs MCP server — Purple tier)

## Description

On July 27, 2026, Huntress researchers detected credential theft on an Oracle database server during a proactive threat hunt. Forensic investigation revealed that attackers had exploited a SQL injection vulnerability in an autocomplete search endpoint of a public-facing Java application running on Apache Tomcat. The application failed to properly sanitize user-supplied input, allowing attackers to inject SQL commands through the JDBC connection to the backend Oracle database.

Rather than deploying executable binaries on disk, the attackers abused Oracle's embedded Java Virtual Machine (JVM) by issuing CREATE JAVA SOURCE statements through the SQL injection channel. This stored malicious Java source code as compiled schema objects directly inside the Oracle database — a technique that Huntress notes has 'rarely been documented' in wild attacks. The Java source was compiled and executed entirely within Oracle's JVM runtime, with PL/SQL wrapper functions providing SQL-callable interfaces to the Java methods.

The khunt toolkit comprised multiple Java modules: KhuntCmd (arbitrary OS command execution via cmd.exe), KhuntHash (Oracle user password hash extraction), KhuntFS and KhuntFS2 (file system browsing and searching), KhuntT (connectivity ping), and KhuntUnzip (file decompression). Once installed, attackers used KhuntCmd to execute cmd.exe /c whoami on the underlying Windows Server, confirming SYSTEM-level privileges. They then used PowerShell to invoke reg.exe save commands, dumping the SAM, SECURITY, and SYSTEM registry hives to F:\Oracle\khuntSAM.hiv, F:\Oracle\khuntSECURITY.hiv, and F:\Oracle\khuntSYSTEM.hiv. An alternate copy of the SECURITY hive was made using esentutl.exe (the Windows Extensible Storage Engine utility), saved as F:\Oracle\khunt_SECURITY.hiv. The attackers also ran tasklist /svc to enumerate running services, writing the output to F:\Oracle\khunttasks.txt. Huntress assessed that the registry hive files were likely exfiltrated for offline credential dumping, though exfiltration was not definitively confirmed.

The attacker's infrastructure was traced to IP 178.162.151.229, hosted on LeaseWeb Netherlands B.V. (AS60781). The broader LeaseWeb 178.162.0.0/16 range has historically been associated with multiple threat actors hosting C2 infrastructure, including RATs, Cobalt Strike beacons, and Gootkit malware campaigns. The khunt attack itself is notable for its operational security: by storing the entire toolkit inside the Oracle DBMS as database objects, the attackers evaded traditional endpoint detection and response (EDR) and antivirus tools that do not inspect Java classes and PL/SQL wrappers inside Oracle.

No specific threat actor attribution has been made. The attack required no novel zero-day exploit — only a common SQL injection vulnerability combined with over-privileged database accounts. Huntress recommends immediate restriction of CREATE JAVA SOURCE and CREATE PROCEDURE privileges for application database accounts, alongside proper input sanitization and parameterized queries. The technique is conceptually related to the 'oraexec' method (Marco Ivaldi's 2006 research, CVE-2004-1364) and the broader class of Oracle JVM abuse where attackers leverage Runtime.getRuntime().exec() through Java stored procedures for OS command execution. Oracle's April 2026 Critical Patch Update (CVE-2026-35229, CVSS 7.5) and July 2026 CPU (CVE-2026-47039, CVSS 6.5) both addressed Java VM component vulnerabilities in Oracle Database Server, underscoring the JVM attack surface.

## MITRE ATT&CK

- T1190 Exploit Public-Facing Application
- T1505 Server Software Component
- T1059 Command and Scripting Interpreter
- T1106 Native API
- T1027 Obfuscated Files or Information
- T1003 OS Credential Dumping
- T1555 Credentials from Password Stores
- T1082 System Information Discovery
- T1057 Process Discovery
- T1005 Data from Local System
- T1560 Archive Collected Data
- T1071 Application Layer Protocol

## Sources

- [Inside an Oracle Database SQL Injection Attack (Primary Source)](https://www.huntress.com/blog/khunt-malware-sql-injection-oracle)
- [Hackers run khunt post-exploitation toolkit from Oracle database](https://www.bleepingcomputer.com/news/security/hackers-run-khunt-post-exploitation-toolkit-from-oracle-database/)
- [Hackers Smuggle Post-Exploitation Toolkit Into Oracle Database via Classic SQL Injection Flaw](https://www.itsecurityguru.org/2026/08/05/hackers-smuggle-post-exploitation-toolkit-into-oracle-database-via-classic-sql-injection-flaw/)
- [CVE-2026-35229 — Oracle Database Server Java VM Vulnerability (April 2026 CPU)](https://nvd.nist.gov/vuln/detail/CVE-2026-35229)
- [Oracle Critical Patch Update Advisory — April 2026](https://www.oracle.com/security-alerts/cpuapr2026.html)
- [CVE-2026-47039 — Oracle Database Server Java VM Privilege Escalation (July 2026 CPU)](https://nvd.nist.gov/vuln/detail/CVE-2026-47039)
- [Oracle Critical Patch Update Advisory — July 2026](https://www.oracle.com/security-alerts/cpujul2026.html)
- [From SQL Injection to RCE — Leveraging Vulnerability for Maximum Impact (Oracle Java Stored Procedures)](https://medium.com/@0x3adly/from-sql-injection-to-rce-leveraging-vulnerability-for-maximum-impact-2fb356907eed)
- [raptor/raptor_oraexec.sql — Oracle extproc Command Execution Exploit](https://github.com/0xdea/exploits/blob/master/oracle/raptor_oraexec.sql)
- [Running OS Commands through Java (Oracle Hacker's Handbook)](https://www.oreilly.com/library/view/the-oracle-r-hackers/9780470080221/9780470080221_running_os_commands_through_java.html)
- [FalconFriday: Code Execution through Microsoft SQL Server and Oracle Database](https://falconforce.nl/falconfriday-code-execution-through-microsoft-sql-server-and-oracle-database-0xff19/)
- [Metasploit Module: Oracle JVM OS Code Execution (10g/11g)](https://www.rapid7.com/db/modules/auxiliary/sqli/oracle/jvm_os_code_10g/)
- [Stored Java to Run an OS Command, Copy a File and Get a Directory Listing](https://technology.amis.nl/it/stored-java-to-run-an-os-command-copy-a-file-and-get-a-directory-listing/)
- [Huntress Threat Intelligence Repository (YARA Rules & IOCs)](https://github.com/huntresslabs/threat-intel)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1903