The discovery of the KHunt post-exploitation toolkit operating directly from inside an Oracle Database demonstrates how an apparently ordinary web application vulnerability can escalate into complete control of the underlying server. The intrusion began when attackers exploited SQL injection in an autocomplete search function exposed by a public-facing Java application running on Apache Tomcat. Because the application failed to validate user-supplied input correctly, malicious SQL commands were passed through its JDBC connection to Oracle. The impact became considerably more serious because the database account used by the application possessed privileges far beyond those required to perform simple search queries, allowing the attackers to create Java source objects, compile executable code inside the database and reach the Windows operating system.

Instead of installing a conventional executable directly on the server, the attackers stored KHunt as Java schema objects inside Oracle. Oracle Database includes an embedded Java Virtual Machine and supports the CREATE JAVA SOURCEstatement, which allows Java source code to be stored, compiled and executed as part of the database environment. This capability exists for legitimate business logic and application integration, but in this case it gave the attackers a convenient mechanism for hiding their toolkit within the database itself. The malicious components could be invoked through SQL statements, allowing the database to function not merely as a source of information but as a command-and-control platform from which the attackers could execute operating-system commands, browse files, collect credentials and prepare additional data for removal.

KHunt consisted of several specialised Java components supported by PL/SQL wrappers. The KhuntCmd module launched cmd.exe and allowed the attackers to issue Windows commands through SQL statements, while KhuntHash accessed Oracle’s internal user information and wrote usernames and password-related data to a file. The KhuntFS and KhuntFS2 components provided filesystem browsing, searching, file-reading and size-checking capabilities, while KhuntUnzip allowed compressed files to be extracted. A separate test component, KhuntT, confirmed whether the toolkit had been installed successfully and remained available. This modular architecture gave the attackers a compact post-exploitation framework without requiring a traditional malware executable to remain visibly installed on disk.

The seriousness of the compromise became clear when the attackers used KhuntCmd to run a whoami command and confirmed that code launched through Oracle was executing with Windows SYSTEM privileges. This is one of the most powerful local security contexts on a Windows server and generally provides authority exceeding that of an ordinary administrator. Once attackers achieve this level of access, they can modify services, create accounts, disable security controls, alter logs, steal protected information and establish persistence elsewhere on the system. The incident therefore shows why SQL injection should not be treated solely as a database confidentiality issue. When a database service or application account can reach powerful execution features, a malicious query can become a route from a public web form to complete host compromise.

The attackers subsequently used PowerShell and legitimate Windows utilities to copy the SAM, SECURITY and SYSTEMregistry hives. Together, these files contain the information required to recover password hashes and other secrets associated with local Windows accounts. The attackers also ran tasklist /svc to enumerate active processes and services and saved the results to a file named khunttasks.txt. These actions suggest that the operators were conducting reconnaissance and staging credential material for possible exfiltration. Huntress assessed that the registry hives were likely intended for offline credential dumping, although the available evidence did not confirm whether the files were successfully removed from the compromised environment.

The initial SQL injection vulnerability was dangerous, but the excessive permissions granted to the application database account transformed it into a full server compromise. An autocomplete function generally requires permission to execute a limited parameterised query against a defined set of tables. It does not require authority to create Java source objects, compile code, inspect Oracle’s internal credential tables or invoke operating-system functionality. When public-facing applications connect to databases using administrative or broadly privileged accounts, every application vulnerability inherits those permissions. Least privilege is therefore not merely a compliance principle; it is a practical containment mechanism that limits what an attacker can accomplish after exploiting an application flaw.

Applications should use parameterised queries or prepared statements so that user-supplied values are treated as data rather than executable SQL syntax. Input validation can provide an additional layer by restricting expected characters, length and format, but filtering alone should not be considered a substitute for safe query construction. Attackers can frequently bypass incomplete input filters through alternate encodings, syntax variations or unexpected query structures. Web application firewalls may block known injection patterns and provide temporary protection, but they cannot permanently compensate for vulnerable application code. Secure development practices, code review and automated testing remain essential, especially for search, filtering and autocomplete functions that process external input continuously.

The attack also highlights a visibility gap between database monitoring and endpoint security. Traditional endpoint products focus on executables, processes, services, registry changes and files stored within the operating system. In this case, the core toolkit was stored as Java objects and PL/SQL wrappers inside Oracle, where ordinary antivirus scanning may not inspect it. Database teams may notice unfamiliar schema objects without understanding their host-level consequences, while endpoint teams may observe oracle.exe launching command shells without knowing which SQL operation triggered the behaviour. Detecting this type of intrusion requires correlation across the application, database and operating-system layers.

Organizations should centrally audit the creation and modification of Java sources, procedures, functions, triggers, jobs and PL/SQL wrappers. A database account associated with a public-facing application should almost never create executable Java objects during normal operation. Any such activity should generate an immediate alert. Security teams should also monitor for suspicious child processes launched by Oracle, including cmd.exe, PowerShell, registry utilities, archive tools and other administrative commands. The appearance of these processes under the Oracle service account is unusual enough to justify investigation even when the specific KHunt object names are not present.

Known objects such as KhuntCmd, KhuntHash, KhuntFS, KhuntFS2, KhuntT and KhuntUnzip provide useful indicators, but defenders should assume that attackers can rename the toolkit easily. Behavioural detection is therefore more reliable than searching only for published names. Administrators should review recently created Java source objects, especially those containing operating-system execution, filesystem access or process-management functionality. Database change-management records should provide a baseline of approved executable objects, making unauthorized additions easier to identify.

Oracle’s powerful database features must also be reviewed according to actual business need. Java stored procedures, external jobs, scheduler functions, directory objects and other execution mechanisms can cross the boundary between the database and the host operating system. Permissions to use these features should be limited to carefully controlled administrative accounts. Public application identities should not possess unrestricted Java execution rights or access to internal Oracle credential tables. The Oracle service itself should run under a dedicated operating-system identity with restricted filesystem and registry permissions rather than SYSTEM wherever the deployment allows it.

Network architecture can further limit the consequences of compromise. Public-facing applications should be separated from critical database systems through segmentation and tightly controlled service accounts. Only approved application servers should be able to reach the Oracle listener, and the database should accept only the minimum communication required for legitimate operation. Outbound connections from database servers should also be restricted, since a database generally has little reason to communicate freely with arbitrary internet destinations. Limiting outbound traffic can interfere with malware downloads, command-and-control activity and data exfiltration even after an attacker obtains code execution.

Incident response must extend well beyond deleting the known KHunt Java objects. Because the attackers executed commands with SYSTEM privileges, they may have created additional accounts, services, scheduled tasks, remote-access tools or persistence mechanisms outside Oracle. The affected server should be isolated and examined for suspicious PowerShell activity, registry changes, service creation, unusual executables and outbound network communication. Oracle audit logs, Apache access logs, application logs and endpoint telemetry should be correlated to reconstruct the complete attack sequence, beginning with the malicious autocomplete requests and continuing through the creation of Java objects and execution of Windows commands.

Credentials accessible from the server should be considered potentially compromised. Local Windows passwords, Oracle accounts, service credentials, database connection strings, API keys and administrative secrets may all require rotation after containment. Password changes should be performed from a trusted system only after the malicious access has been removed, otherwise the attackers may simply capture the replacement values. Where SYSTEM-level execution occurred and complete system integrity cannot be established, rebuilding the server from a trusted image is safer than attempting selective cleanup. The vulnerable application code and excessive database privileges must be corrected before the rebuilt environment returns to production, or the organization will simply provide the attackers with a clean server through the same exposed route.

The wider lesson from the KHunt attack is that databases are no longer passive repositories holding information for attackers to steal. Modern enterprise databases include programming languages, schedulers, external integrations and automation features capable of interacting with the operating system and connected infrastructure. These capabilities are valuable for legitimate applications, but they also provide powerful post-exploitation opportunities when attackers obtain sufficient privileges.

The incident began with an old and well-understood problem: unsafe handling of user input. What made it unusual was the attacker’s ability to move through Tomcat, JDBC and Oracle’s embedded Java environment until a simple autocomplete feature became a Windows SYSTEM command channel. Preventing similar attacks therefore requires controls at every stage. Applications must use parameterised queries, database accounts must follow least privilege, executable database features must be restricted, database services must run with limited host permissions and security teams must monitor activity across web, database and endpoint layers.

A search box should return matching information. It should not allow an attacker to compile a post-exploitation framework inside Oracle, dump Windows credentials and operate the server through SQL statements. When that path exists, the database does not merely become part of the breach. It becomes the attacker’s platform inside the organization.

Hackers exploited a SQL injection vulnerability to install a post-exploitation toolkit directly inside an Oracle database that was used to breach a corporate network. [...]

Source: Hackers run khunt post-exploitation toolkit from Oracle database via Bleeping Computer — published 05 Aug 2026.