Threat reportMalwareTL-2026-1903
Khunt Post-Exploitation Toolkit Deployed via Oracle Database JVM (Huntress Discovery)
Khunt Post-Exploitation Toolkit Deployed via Oracle Database (TL-2026-1903), also tracked as khunt toolkit, is a critical-severity malware campaign, first published 2026-07-27. It has no confirmed attribution, affects Oracle Oracle Database Server (with JVM enabled), maps to 12 MITRE ATT&CK techniques (T1003, T1005, T1027), and is covered by 9 detection rules and 10 indicators of compromise.
- Severity
- CRITICALAssessed severity
- CVEs
- 0None referenced
- Techniques
- 12MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 10Indicators of compromise
Key facts for TL-2026-1903
- Threat ID
- TL-2026-1903
- Also known as
- khunt toolkit, Oracle JVM post-exploitation toolkit
- Severity
- CRITICAL
- Status
- ACTIVE
- Category
- MALWARE
- First published
- Last reviewed
- Attribution confidence
- LOW
- Motivation
- UNKNOWN
- Detection rules
- 9
- Indicators of compromise
- 10
Malware and tooling in Khunt Post-Exploitation Toolkit Deployed via Oracle Database
Malware and tooling: khunt, PowerShell, Reg - S0075, cmd - S0106, esentutl - S0404
How Khunt Post-Exploitation Toolkit Deployed via Oracle Database works
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.
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 techniques used in TL-2026-1903
Credential Access
T1003 OS Credential Dumping; T1555 Credentials from Password Stores
Collection
T1005 Data from Local System; T1560 Archive Collected Data
Defense Evasion
T1027 Obfuscated Files or Information
Discovery
T1057 Process Discovery; T1082 System Information Discovery
Execution
T1059 Command and Scripting Interpreter; T1106 Native API
Command and Control
T1071 Application Layer Protocol
Initial Access
T1190 Exploit Public-Facing Application
Persistence
Affected products and versions in Khunt Post-Exploitation Toolkit Deployed via Oracle Database
- Oracle — Oracle Database Server (with JVM enabled)
Vulnerable versions: 19.3 through 19.30; 21.3 through 21.21
Fixed in: Apply Oracle CPU July 2026 (beyond 19.31 / 21.22) - Apache — Tomcat
Vulnerable versions: Any version hosting Java application with SQLi-vulnerable endpoint
Fixed in: Input sanitization, parameterized queries - Microsoft — Windows Server
Vulnerable versions: Any version supporting Oracle Database
Fixed in: N/A — OS security posture depends on DB account privilege management
Remediation for Khunt Post-Exploitation Toolkit Deployed via Oracle Database
Patches
- Apply Oracle Critical Patch Update April 2026 for CVE-2026-35229 (Java VM vulnerability, CVSS 7.5)
- Apply Oracle Critical Patch Update July 2026 for CVE-2026-47039 (Java VM privilege escalation, CVSS 6.5)
- Keep Apache Tomcat and JDBC drivers updated with latest security patches
Immediate actions
- Identify and remove unauthorized Java source objects in Oracle DBMS (KhuntT, KhuntFS, KhuntFS2, KhuntCmd, KhuntHash, KhuntUnzip)
- Revoke CREATE JAVA SOURCE and CREATE PROCEDURE privileges from application database accounts
- Block IP 178.162.151.229 and monitor for connections from LeaseWeb ranges (178.162.128.0/18)
- Rotate all local Windows account credentials exposed in dumped registry hives
- Scan F:\Oracle\ directory for unauthorized .hiv and .txt files; secure and preserve for forensics
- Review Apache Tomcat access logs for SQL injection patterns targeting the autocomplete search endpoint
Workarounds
- Disable Oracle JVM if not required for application functionality (JAVA_POOL_SIZE=0 and remove JAVA_JIT_ENABLED)
- Implement web application firewall (WAF) rules to block SQL injection patterns in search/autocomplete parameters
- Enforce strict least-privilege for database accounts used by public-facing applications — no CREATE JAVA SOURCE, CREATE PROCEDURE, or DBA role
- Use parameterized queries / prepared statements to prevent SQL injection in all application endpoints
- Implement network segmentation to restrict Oracle listener access from application tier only
- Enable Oracle audit logging for DDL statements (AUDIT CREATE JAVA SOURCE BY ACCESS;)
Longer-term hardening
- Implement database activity monitoring (DAM) to detect anomalous DDL such as CREATE JAVA SOURCE
- Deploy SQL query monitoring for unusual Java stored procedure invocations and PL/SQL wrapper creation
- Regularly audit DBA_JAVA_CLASSES, USER_JAVA_CLASSES, and DBA_OBJECTS for unauthorized Java schema objects
- Monitor oracle.exe parent process for unexpected child processes (cmd.exe, powershell.exe, reg.exe, esentutl.exe)
- Implement detection rules for reg.exe save and esentutl.exe creating .hiv files outside backup windows
- If Oracle JVM is not required for business operations, disable the embedded JVM component
- Establish baseline of normal Java stored procedure usage and alert on deviations
Weaknesses (CWE) in Khunt Post-Exploitation Toolkit Deployed via Oracle Database
Timeline of Khunt Post-Exploitation Toolkit Deployed via Oracle Database
- Huntress forensic investigation discovers complete attack chain: SQL injection, CREATE JAVA SOURCE deployment, khunt toolkit components, SYSTEM-level access, and registry hive dumping. Apache access logs reveal attack originated from IP 178.162.151.229
- Huntress researchers detected credential theft indicators on the Oracle database server during proactive threat hunting
- Registry hive files likely exfiltrated over the SQL injection/C2 channel for offline credential cracking (exfiltration unconfirmed by Huntress)
- Attackers ran tasklist /svc to enumerate running services; output saved as F:\Oracle\khunttasks.txt
- Attackers used esentutl.exe to create an alternate copy of the SECURITY hive (khunt_SECURITY.hiv) as a second method of registry extraction
- Attackers used PowerShell and reg.exe to dump SAM, SECURITY, and SYSTEM registry hives to F:\Oracle\khuntSAM.hiv, khuntSECURITY.hiv, and khuntSYSTEM.hiv
- Attackers used KhuntCmd to run cmd.exe /c whoami, confirming SYSTEM-level privileges on the Windows Server hosting the Oracle database
- Khunt toolkit deployed via CREATE JAVA SOURCE commands injected through JDBC connection; compiled as Java schema objects inside Oracle database JVM
- Attackers exploited SQL injection in autocomplete search endpoint of public-facing Java/Tomcat application (date uncertain; pre-dates detection)
- Huntress publishes detailed technical report (Ben Nahorney and Michael Tigges); BleepingComputer (Lawrence Abrams) and IT Security Guru report findings publicly
Sources cited for Khunt Post-Exploitation Toolkit Deployed via Oracle Database
- Inside an Oracle Database SQL Injection Attack (Primary Source)
- Hackers run khunt post-exploitation toolkit from Oracle database
- 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)
- Oracle Critical Patch Update Advisory — April 2026
- CVE-2026-47039 — Oracle Database Server Java VM Privilege Escalation (July 2026 CPU)
- Oracle Critical Patch Update Advisory — July 2026
- From SQL Injection to RCE — Leveraging Vulnerability for Maximum Impact (Oracle Java Stored Procedures)
- raptor/raptor_oraexec.sql — Oracle extproc Command Execution Exploit
- Running OS Commands through Java (Oracle Hacker's Handbook)
- FalconFriday: Code Execution through Microsoft SQL Server and Oracle Database
- Metasploit Module: Oracle JVM OS Code Execution (10g/11g)
- Stored Java to Run an OS Command, Copy a File and Get a Directory Listing
- Huntress Threat Intelligence Repository (YARA Rules & IOCs)
Detection coverage for TL-2026-1903
As of 2026-07-27, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1903 across Splunk SPL, Microsoft KQL and Sigma, covering 10 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.