Threat Overview
This report documents a sophisticated attack that leveraged SQL injection against a public‑facing Java/Tomcat application backed by an Oracle database. The adversary inserted a database resident post‑exploitation toolkit named khunt, allowing full remote control of the underlying Windows server. The operation demonstrates how attackers can transform a data store into a command and control platform, bypassing traditional perimeter defenses.
Initial Access via Classic SQL Injection
On 27 July 2026, Huntress detected credential theft on an endpoint running Oracle. Subsequent analysis revealed that the attacker exploited a form input field in the public application that failed to validate or parameterize user data before passing it to the database. By submitting crafted SQL statements through this vulnerable endpoint, the adversary injected PL/SQL procedures and Java source code into the Oracle instance.
Deployment of the khunt Toolkit
The attacker used the CREATE JAVA SOURCE statement to embed Java classes directly inside Oracle. The resulting objects included:
- KhuntCmd – Executes arbitrary OS commands via SQL.
- KhuntHash – Extracts usernames and passwords from Oracle’s internal tables.
- KhuntFS / KhuntFS2 – File explorers enabling list, read, search, and size operations on the Windows filesystem.
- KhuntT – A ping tool confirming toolkit operability.
- KhuntUnzip – Unzips files on the target machine.
These modules were wrapped in PL/SQL procedures that could be invoked by sending simple SQL queries, effectively turning the database into a command and control server.
Post‑Compromise Activities
After establishing remote code execution from the database to the OS, the adversary executed cmd.exe /c whoami, confirming SYSTEM privileges. They then launched PowerShell commands to copy critical registry hives – SECURITY and SYSTEM – saving them as F:\Oracle\khuntSECURITY.hiv and F:\Oracle\khuntSYSTEM.hiv. The attacker also exported the SAM hive using esentutl.exe, producing F:\Oracle\khuntSAM.hiv. Service enumeration was captured in F:\Oracle\khunttasks.txt. These artifacts provide a rich source for credential extraction and lateral movement.
Indicators of Compromise (IOCs)
Files:
[drive:][path]\Oracle\khuntSECURITY.hiv
[drive:][path]\Oracle\khuntSYSTEM.hiv
[drive:][path]\Oracle\khuntSAM.hiv
[drive:][path]\Oracle\khunt_SECURITY.hiv
[drive:][path]\Oracle\khunttasks.txt
Registry Dump Paths and Content
Attacker IP (sanitized): 178[.]162[.]151[.]229
SQL Object Names:
KHUNT%
KhuntT, KhuntFS, KhuntFS2, KhuntCmd, KhuntHash, KhuntUnzip
Mitigations and Recommendations
Application Hardening: Implement strict input validation and parameterized queries for all user inputs. Disable or restrict direct SQL execution capabilities for web application users.
Database Least‑Privilege: Ensure that database accounts cannot author CREATE JAVA SOURCE or execute arbitrary PL/SQL procedures. Limit privileges to read‑only or application‑specific roles.
Runtime Monitoring: Extend EDR and AV coverage to monitor for Java class creation within Oracle. Deploy database activity monitoring solutions that alert on unexpected object creation.
Registry Surveillance: Use Windows Defender Advanced Threat Protection (WAP) or similar tools to detect anomalous registry hive dumping or the presence of large hive files in non‑standard locations.
External References
Report Details:
hxxps://www[.]huntress[.]com/blog/khunt-malware-sql-injection-oracle
hxxps://otx[.]alienvault[.]com/pulse/6a74926f080493b4db7b59f3
Conclusion
This incident illustrates the evolving threat landscape where traditional data stores become weaponized platforms. By ensuring rigorous input sanitization, enforcing least‑privilege database roles, and extending monitoring into database internals, security teams can effectively disrupt such multi‑stage attacks before they compromise critical infrastructure.
