Hackers hid their attack tools inside an Oracle database itself
A rarely seen technique let intruders run commands, steal password data and browse files from within the database, after breaking in through a sloppy search box.
Key points
- Huntress spotted the intrusion on 27 July 2026 after credential theft alerts fired on a server running an Oracle database.
- The attackers got in through a SQL injection flaw in a public-facing Java web application, using a search autocomplete box that failed to check user input.
- They installed a toolkit called khunt directly inside the Oracle database as Java code, a technique researchers say has rarely been seen in the wild.
- Commands run through the database had SYSTEM-level access on the Windows host, the highest level of privilege.
- The intruders copied Windows registry files that hold password data, likely to crack them offline.
Investigators at security firm Huntress have described an unusual intrusion where attackers turned a company's own Oracle database into the hiding place for their hacking tools.
The case, first reported by BleepingComputer, was picked up on 27 July 2026 when Huntress detected credential theft on a server hosting an Oracle database.
How did the hackers get in?
Through a search box. The company ran a public-facing Java web application on Apache Tomcat, a common piece of server software, and its autocomplete search feature did not properly check what users typed into it.
That gap let the attackers slip in SQL injection payloads: database commands smuggled inside what looked like an ordinary search query. The malicious traffic came from the IP address 178.162.151.229.
SQL injection is one of the oldest bugs in the book. It happens when a website passes whatever a visitor types straight through to its database instead of treating it as plain text.
What is the khunt toolkit?
It is a set of small hacking tools written in Java, and this is where the case gets interesting. Rather than dropping executable files onto the server, the attackers built and stored the toolkit inside the Oracle database itself.
Oracle databases have a built-in Java engine and a command, CREATE JAVA SOURCE, that lets administrators load Java code as a database object. That code can then be triggered by ordinary database queries, and if the database is set up permissively, it can run commands on the underlying server.
"The use of the technique in the wild has rarely been documented," Huntress said.
The khunt components each did one job:
| Component | What it did |
|---|---|
| KhuntCmd | Ran Windows commands via cmd.exe |
| KhuntHash | Pulled usernames and password data from Oracle's internal tables |
| KhuntFS / KhuntFS2 | Browsed, read and searched files on the server |
| KhuntT | A simple test to confirm the toolkit was installed |
| KhuntUnzip | Extracted compressed files |
The attackers ran whoami through KhuntCmd and confirmed their commands were executing with SYSTEM privileges, meaning full control of the Windows machine.
What did they steal?
They went straight for passwords. Using PowerShell and standard Windows tools, the intruders copied three registry files, SAM, SECURITY and SYSTEM, which together hold the scrambled password hashes for local Windows accounts.
Those files can be taken away and cracked at leisure on the attacker's own machine. Huntress believes the files were exfiltrated for that purpose, though the report does not confirm the copies left the network.
The attackers also ran tasklist /svc to list running services and saved the output to a file called khunttasks.txt, likely to plan their next move.
Should ordinary people be worried?
Not directly. This was a targeted break-in at one corporate network, not a mass-market scam. The victim has not been named and there is no public list of affected customers.
The wider lesson is for anyone running a database behind a website. Huntress recommends that database accounts used by public-facing apps should never have permission to create Java code, run administrative procedures, or reach into the operating system.
Sanitising user input, the boring fix to SQL injection that has been standard advice for two decades, would have stopped this attack at the search box.
