Hackers Hid a Remote-Control Toolkit Inside Oracle to Take Over a Windows Server

A routine web application weakness has been tied to a serious Windows Server compromise after attackers used SQL injection to plant a remote-control toolkit inside an Oracle database.

The incident shows how a poorly protected form can become a path from a public website to the operating system behind it.

The attackers targeted a public-facing Java and Tomcat application connected to Oracle.

By submitting database commands through an autocomplete search feature that did not properly check input, they were able to make the database process commands and prepare the next stage of the intrusion.

Researchers at Huntress identified the activity after detecting attempts to steal credentials from a server hosting Oracle.

The investigation found copies of Windows SAM, SECURITY, and SYSTEM registry hives, material that can help an intruder recover password hashes and widen access.

Huntress said in a report shared with Cyber Security News (CSN) that the case matters because the malicious code was not first placed on disk as a typical malware file.

Instead, it was stored and compiled within Oracle, where it could be harder for endpoint-focused monitoring to spot before it was used to control the Windows host.

Hackers Hid a Remote-Control Toolkit Inside Oracle

The attackers used Oracle’s embedded Java capability to create Java source objects directly in the database.

Commands sent through the application’s JDBC connection were compiled as stored schema objects, turning the database into a concealed launch point rather than simply a place to hold business data.

The toolkit, named khunt, included components for running Windows commands, collecting Oracle usernames and passwords, browsing files, checking that the toolkit was active, and unpacking files.

This database-resident approach gave the operator tools for exploring the server without relying on one obvious malicious executable.

One component opened a command shell and ran a command to identify the current user.

It returned SYSTEM-level permissions, confirming that the attacker had crossed from database access to operating-system control, a risk also illustrated by the Windows Netlogon RCE threat facing exposed server environments.

The activity then moved to credential collection. The intruder used Windows utilities to copy registry hives and listed running services, creating files in the Oracle directory that could be taken away for offline analysis. Similar registry hive credential theft can reveal credentials for local accounts.

The initial access came from SQL injection, not a newly disclosed software flaw. That distinction is important because it places attention on application design and database permissions, not only patching.

Closing the Database-to-Server Path

Organizations should review every public form and search field that can reach a database, especially legacy features that may be overlooked during testing.

Input should be sanitized and database queries parameterized so supplied text cannot be interpreted as executable SQL, a basic safeguard against the kind of improper validation seen in the Windows Active Directory flaw. Database accounts also need the smallest practical set of rights.

An account used by a web application should not be able to create Java source objects, run sensitive stored procedures, or gain broad operating-system access, limiting the damage even when an injection bug slips through. Defenders should look beyond ordinary file scans when investigating Oracle servers.

Searching database objects for unexpected Java classes, reviewing PL/SQL wrappers, and checking web and SQL logs for unusual commands can expose activity that endpoint tools may miss; administrators should also keep up with June Microsoft security updates for the Windows systems that support these workloads.

The reported attacker infrastructure and artifact names give incident responders practical leads for threat hunting.

A review should prioritize unusual Oracle-created files, unexpected database objects, and signs that oracle.exe spawned command-line or registry tools, then isolate affected systems and reset credentials if credential material may have been copied and preserve relevant logs for a complete forensic review before rebuilding trust in the host.

Indicators of Compromise (IoCs):-

Type	Indicator	Description
File path	[drive:][path]\Oracle\khuntSECURITY.hiv	Registry hive file dumped by the attacker
File path	[drive:][path]\Oracle\khuntSYSTEM.hiv	Registry hive file dumped by the attacker
File path	[drive:][path]\Oracle\khuntSAM.hiv	Registry hive file dumped by the attacker
File path	[drive:][path]\Oracle\khunt_SECURITY.hiv	Registry hive file dumped by the attacker
File path	[drive:][path]\Oracle\khunttasks.txt	File containing a list of running tasks
IP address	178.162.151[.]229	Attacker IP address
Oracle object	KhuntT	Database object name to hunt for
Oracle object	KhuntFS	Database object name to hunt for
Oracle object	KhuntFS2	Database object name to hunt for
Oracle object	KhuntCmd	Database object name to hunt for
Oracle object	KhuntHash	Database object name to hunt for
Oracle object	KhuntUnzip	Database object name to hunt for
SQL log string	KHUNT%	String to search for in SQL logs

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world