khunt: attackers ran a toolkit inside an Oracle database

An autocomplete search box took down a corporate network. Huntress published the incident on August 5: attackers hit a SQL injection flaw in a public-facing Java application, then used Oracle's own features to compile and run a post-exploitation toolkit inside the database engine. No malware file ever landed on the server's disk. If you run a web app with a database behind it — and you do — this is worth twenty minutes of your week.

What actually happened

The incident dates to July 27. Initial access came through a vulnerable search endpoint in a public-facing Java app on Apache Tomcat. The autocomplete feature did not validate input, which let the attackers issue arbitrary SQL to the Oracle backend over the app's own JDBC connection.

From there they used two legitimate Oracle features: CREATE JAVA SOURCE, which stores Java source as a database schema object, and Oracle's embedded JVM, which compiles and runs it. The toolkit, named khunt, went in as Java classes and was invoked through ordinary SQL.

The modules are exactly what you would build:

• KhuntCmd — launches cmd.exe and runs OS commands through SQL statements
• KhuntHash — reads Oracle's internal user table and writes out usernames and password data
• KhuntFS / KhuntFS2 — browse, read, search files and check sizes
• KhuntT — a ping to confirm the toolkit installed
• KhuntUnzip — extracts compressed files

They dumped the SAM, SECURITY, and SYSTEM registry hives plus a running services list for offline credential cracking. A SQL injection bug became SYSTEM-level Windows access without a single dropped binary.

Why database privilege matters for your business

Two assumptions broke here, and both are common in small-business software.

Your database is treated as a data store, not as an execution environment. Oracle can compile and run Java. SQL Server has CLR integration. PostgreSQL has untrusted procedural languages. If your app's database account can create procedural code objects, your database is a runtime, and it is one your EDR is not watching. Go check what your application user can actually do — most were provisioned once, granted generously, and never revisited.

Input validation is a security perimeter, not a UX nicety. The entry point was autocomplete. Not a login, not an admin panel, not an upload — a search-as-you-type field somebody built in an afternoon. Parameterize every query, everywhere, including the endpoints nobody thinks of as endpoints.

For detection, Huntress gives you cheap wins: search Oracle logs for object names matching KHUNT%, alert on unexpected Java class creation in the database, and flag reg.exe or esentutl.exe spawned from oracle.exe. That last one is a five-minute rule with no false-positive problem — your database server has no legitimate reason to dump registry hives.

Sources: Huntress, BleepingComputer.