Attackers Hide the khunt Toolkit Inside Oracle Databases to Gain SYSTEM Access

Share:

Huntress investigated a real intrusion where attackers broke into a public-facing web application
through a classic SQL injection flaw and turned it into full control of the underlying Windows server. The
attackers used the Oracle database behind the app to store and run a custom hacking toolkit, called
khunt, entirely inside the database, then used it to run system commands and steal the passwords held
on the server. Because the toolkit lives inside Oracle rather than as normal files, standard antivirus and
endpoint tools can easily miss it.

1. Campaign Timeline

On 27 July 2026, Huntress detected credential-theft activity on a Windows server running an Oracle database, traced to a reg.exe process spawned by oracle.exe. Apache access logs showed the entry point: SQL injection against an autocomplete search field in a public-facing Java and Tomcat application that did not validate input. The Tomcat app passed the injected SQL to Oracle over its JDBC connection. Huntress traced the attacker infrastructure to a single address, 178.162.151[.]229. The novel element was that the attackers stored their toolkit inside the database itself rather than dropping files on disk.

2. Attack Details

  • Initial access: Attackers exploited a SQL injection flaw in an autocomplete search field of a public-facing Java and Tomcat application, which passed unvalidated SQL to its Oracle backend over JDBC. No product vulnerability was needed, only missing input validation
  • Toolkit deployment: Through the injection, the attackers issued CREATE JAVA SOURCE statements to Oracle’s embedded Java Virtual Machine, compiling the khunt toolkit as stored schema objects directly inside the database, where file based EDR and antivirus do not look.
  • OS command execution: Using the KhuntCmd module, the attackers launched cmd.exe and ran whoami, confirming SYSTEM-level privileges and full remote code execution from the database layer to the Windows operating system.
  • Credential theft: The attackers copied the SAM, SECURITY, and SYSTEM registry hives with reg.exe and esentutl.exe to the F:\Oracle folder, and enumerated services with tasklist, staging local password hashes for extraction and exfiltration.

3. Payload Capabilities

khunt is a post-exploitation toolkit that lives inside the Oracle database as Java and PL/SQL objects:

  • Database-resident beachhead: khunt turns the Oracle database from a data store into an attack platform. Because its modules live as Java classes and PL/SQL wrappers inside Oracle, not as files or running processes, endpoint and antivirus tools that inspect the operating system routinely miss them.
  • OS command execution: The KhuntCmd module loads cmd.exe and runs arbitrary operating-system commands sent as SQL statements, giving the attacker a shell on the host from inside the database.
  • Credential and file access: KhuntHash reads Oracle’s internal user table and writes usernames and passwords to a file, while KhuntFS and KhuntFS2 list, read, and search files across the compromised server.

4. Adversary Toolkit

Tool / IndicatorTypeFunction
KhuntCmdOracle Java Source moduleLoads cmd.exe and runs arbitrary OS commands passed in through SQL statements.
KhuntHashOracle Java Source moduleReads Oracle’s internal user table and writes usernames and passwords to a file.
KhuntFS, KhuntFS2Oracle Java Source modulesFile explorers that list, read, search, and size files on the compromised host.
KhuntT, KhuntUnzipOracle Java Source modulesHealth-check ping tool and a file-unzipping utility for the toolkit.
khunt_ wrappers*PL/SQL wrappersCall the underlying Java methods that make up the toolkit.

5. Indicators of Compromise (IOCs)

Type – Indicator
IP – 178.162.151[.]229
FILENAME – [drive:][path]\Oracle\khuntSECURITY.hiv
FILENAME – [drive:][path]\Oracle\khuntSYSTEM.hiv
FILENAME – [drive:][path]\Oracle\khuntSAM.hiv
FILENAME – [drive:][path]\Oracle\khunt_SECURITY.hiv
FILENAME – [drive:][path]\Oracle\khunttasks.txt

6. Recommendations

  • Search Oracle databases behind public-facing apps for rogue Java Source objects named KhuntCmd,
  • KhuntHash, KhuntFS, KhuntFS2, KhuntT, or KhuntUnzip, and review SQL logs for KHUNT% and CREATE JAVA SOURCE activity.
  • Remove the khunt objects and PL/SQL wrappers from affected databases, delete the dumped hive and task files from the Oracle folder, and rebuild or forensically review any host confirmed compromised.
  • Reset local account passwords on the affected server and rotate any credentials stored in or reachable from the Oracle database, since the SAM, SECURITY, and SYSTEM hives were copied.
  • Fix the root cause: enforce input validation and parameterised queries on all application inputs, and restrict the database account so it cannot author Java sources or execute stored procedures it does not need.
  • Block the IOCs at their respective controls.

7. Sources

  • https://www.huntress.com/blog/khunt-malware-sql-injection-oracle
  • https://github.com/0xdea/exploits/blob/master/oracle/raptor_oraexec.sql

Enjoyed reading this Threat Intelligence Advisory? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn

No related posts found.

Ampcus Cyber
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Talk to an expert