{"id":561,"date":"2026-08-07T14:48:02","date_gmt":"2026-08-07T09:18:02","guid":{"rendered":"https:\/\/www.hexnode.com\/threat-watch\/?p=561"},"modified":"2026-08-18T14:55:34","modified_gmt":"2026-08-18T09:25:34","slug":"khunt-toolkit-runs-inside-oracle-database-after-sql-injection","status":"publish","type":"post","link":"https:\/\/www.hexnode.com\/threat-watch\/khunt-toolkit-runs-inside-oracle-database-after-sql-injection\/","title":{"rendered":"khunt Toolkit Runs Inside Oracle Database After SQL Injection"},"content":{"rendered":"

How did the khunt toolkit attack work?<\/h2>\n

The khunt toolkit was installed directly inside an Oracle database after attackers exploited a SQL injection vulnerability in a public-facing Java application. Rather than relying on a conventional executable payload, the attackers abused Oracle’s Java functionality and later achieved SYSTEM-level command execution on the underlying Windows server.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Attack stage<\/span><\/b>\u00a0<\/span><\/td>\nObserved activity<\/span><\/b>\u00a0<\/span><\/td>\n<\/tr>\n
Initial access<\/span><\/b>\u00a0<\/span><\/td>\nSQL injection through a Java autocomplete feature<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Application server<\/span><\/b>\u00a0<\/span><\/td>\nApache Tomcat<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Database<\/span><\/b>\u00a0<\/span><\/td>\nOracle Database<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Abused capability<\/span><\/b>\u00a0<\/span><\/td>\nOracle JVM and CREATE JAVA SOURCE<\/code><\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Post-exploitation toolkit<\/span><\/b>\u00a0<\/span><\/td>\nkhunt<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
OS execution<\/span><\/b>\u00a0<\/span><\/td>\nKhuntCmd\u00a0launching cmd.exe<\/code><\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Execution privilege<\/span><\/b>\u00a0<\/span><\/td>\nSYSTEM<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Host discovery<\/span><\/b>\u00a0<\/span><\/td>\ntasklist\u00a0\/svc<\/span>\u00a0<\/span><\/code><\/td>\n<\/tr>\n
Credential-access activity<\/span><\/b>\u00a0<\/span><\/td>\nSAM, SECURITY and SYSTEM registry hives copied<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Confirmed hive exfiltration<\/span><\/b>\u00a0<\/span><\/td>\nNo<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Threat actor attribution<\/span><\/b>\u00a0<\/span><\/td>\nUnknown<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

What makes the incident<\/a> notable is the role of the database. Oracle was not simply a target for unauthorized queries. The attackers used its legitimate Java functionality as part of the post-exploitation chain.<\/p>\n

How did the khunt Oracle attack begin?<\/h2>\n

The attackers exploited SQL injection<\/a> in an autocomplete search feature within a public-facing Java application running on Apache Tomcat.<\/p>\n

The feature did not adequately validate user-controlled input before passing it to the backend Oracle database. This allowed the attackers to issue commands against Oracle.<\/p>\n

Huntress discovered the intrusion after identifying credential-theft activity on the Windows server hosting the database. Apache access logs subsequently helped investigators trace the activity back to the vulnerable search endpoint.<\/p>\n

The SQL injection provided the initial foothold. However, the more distinctive part of the attack followed when the attackers began using Oracle’s Java capabilities for post-exploitation.<\/p>\n

How was the khunt toolkit installed inside Oracle?<\/h2>\n

The attackers abused Oracle’s embedded Java functionality, including CREATE JAVA SOURCE<\/code>, to create Java source schema objects for khunt; Oracle can also create class schema objects for classes defined by that source.<\/p>\n

Oracle Database includes an embedded Java Virtual Machine and supports Java code stored within the database. The attackers used this legitimate functionality to establish the khunt toolkit inside Oracle, with PL\/SQL wrappers exposing its capabilities.<\/p>\n

Observed khunt components included:<\/p>\n