A public-facing web application with an Oracle database backend recently became the entry point for a full server takeover. Researchers at Huntress traced the attack back to a SQL flaw that let attackers execute commands directly through the database engine. What made this incident stand out wasn’t the initial break-in, but what the attackers did once they were inside.
Rather than dropping a traditional executable, the attackers stored an exploitation toolkit as Java objects inside the Oracle database.
How Did the Attack Start?
The breach began with a SQL injection vulnerability in an autocomplete search field. This field passed unvalidated input directly to the Oracle database over a JDBC connection. Because the database account had more access than it needed, the attackers could go well beyond searching for stored data.
Huntress detected the intrusion after credential theft alerts were triggered in late July 2026. Their investigation traced the activity back to SYSTEM-level access on the underlying Windows server. That level of access meant the attackers had full control over the machine.
How the Flaw Weaponized a Database
Oracle databases include a built-in Java Virtual Machine, and a single system privilege allows a user to compile Java code directly into the database as a schema object. Attackers exploited this feature to build a post-exploitation toolkit called khunt.
Although security researchers have documented similar database exploitation methods for approximately 20 years, they haven’t been observed in many attacks. The khunt toolkit included several components:
- Command execution: One module loaded cmd.exe and ran operating system commands through SQL.
- Credential theft: Another module read usernames and password hashes from Oracle’s internal tables.
- File access: Additional modules listed, searched, and read files on the server.
- Archive handling: A separate module unpacked compressed files as needed.
How Database Access Turned Into Full Control
Using khunt, the attackers achieved remote code execution and confirmed SYSTEM-level access on the Windows server. They then used PowerShell and native registry tools to copy sensitive system hives to a local directory. This gave them what they needed to extract password hashes for local accounts.
Researchers observed registry hive copies being staged locally but couldn’t confirm whether any data left the network. Even without confirmed exfiltration, the incident shows how much damage a single unvalidated input field can enable.
What Made This SQL Flaw Hard To Detect?
Traditional security tools watch for suspicious processes and files written to disk. Khunt itself lived as compiled objects inside the database, where most endpoint detection tools don’t look.
Organizations can search their Oracle environments for unusual schema object names as one detection method. However, this only catches the specific toolkit, not the underlying technique.
How To Protect Your Organization
Preventing this kind of attack starts with basic application security practices. Parameterized queries and proper input validation stop SQL injection before it starts. Limiting database account privileges also reduces what an attacker can do even if they get in.
Accounts serving public-facing applications shouldn’t have the ability to compile Java source code or run stored procedures unrelated to their purpose. This SQL flaw is a reminder that database permissions deserve the same scrutiny as network access.
