Hackers run khunt post-exploitation toolkit from Oracle database

I'll pull the BleepingComputer article so the paragraphs stay grounded in real details rather than invented numbers.Pulling the BleepingComputer piece and the Huntress write-up for concrete technical facts.Hackers exploited a SQL injection flaw in a public-facing Java application on Apache Tomcat to install a post-exploitation toolkit named **khunt** directly inside an Oracle database, then used it to breach the underlying Windows server. Huntress detected the intrusion on July 27, 2026 after credential-theft activity fired on an endpoint hosting the Oracle service. Apache access logs showed abuse of an autocomplete search endpoint that accepted unvalidated SQL and forwarded it over JDBC to the database. Malicious traffic was traced to the IP address 178.162.151.229.

Technically, the attackers abused Oracle’s embedded Java Virtual Machine and the **CREATE JAVA SOURCE** statement to compile and store the toolkit as schema objects rather than drop binaries on disk. The package included **KhuntCmd** (launch cmd.exe and run OS commands via SQL), **KhuntHash** (pull usernames and password data from Oracle’s internal user table into a file), **KhuntFS** and **KhuntFS2** (list, read, search, and size files), **KhuntT** (a reachability “ping” to confirm install), **KhuntUnzip**, and several **khunt_*** PL/SQL wrappers. Through **KhuntCmd** they ran `cmd.exe /c whoami` under the **oracle.exe** parent process and confirmed **SYSTEM**-level rights, then used PowerShell, **reg.exe**, and **esentutl.exe** to copy the **SAM**, **SECURITY**, and **SYSTEM** registry hives under paths such as F:\Oracle\khuntSAM.hiv, and dumped service enumeration to khunttasks.txt via `tasklist /svc`.

For engineers and builders, the chain matters because a routine form-validation failure became full OS remote code execution without a novel Oracle CVE. The database stopped being a data store and became a persistent beachhead: malicious Java classes and PL/SQL wrappers live inside the engine, where process- and file-centric EDR and AV rarely inspect. Application DB accounts that can create Java sources or run broad stored procedures turn every injectable query path into a host-compromise path.

In market and competitive terms, SQL injection is decades old and still effective when public Tomcat apps sit on privileged Oracle backends—classic web risk plus database-hosted code execution. Related **oraexec**-style techniques have been discussed for years, but Huntress noted in-the-wild use of this pattern is rarely documented, so defenders may underweight it next to flashier zero-days. That gap favors attackers who prefer durable, low-noise footholds over one-shot file drops.

Practical takeaways: parameterize and sanitize every user-facing input, especially autocomplete and search endpoints; run app DB accounts with least privilege so they cannot **CREATE JAVA SOURCE** or execute unnecessary procedures; hunt Oracle object names matching **KhuntCmd**, **KhuntHash**, **KhuntFS**, **KhuntFS2**, **KhuntT**, **KhuntUnzip**, and SQL logs for **KHUNT%**; and alert on **reg.exe**, **esentutl.exe**, or hive dumps spawned from **oracle.exe**. Watch for copies of SAM/SECURITY/SYSTEM under Oracle install paths and for further abuse of database-resident Java as a persistence and lateral-movement channel.