A newly documented attack uncovered by Huntress demonstrates how a decades-old SQL injection vulnerability can still lead to devastating enterprise compromises but with a dangerous modern twist.
Researchers have identified a sophisticated post-exploitation toolkit named khunt, which attackers embedded directly inside an Oracle database after exploiting a vulnerable public-facing web application. Instead of simply stealing database records, the attackers transformed the database itself into a launchpad for operating system-level attacks, eventually obtaining Windows SYSTEM privileges and attempting to steal credential data from the compromised server.
The findings illustrate an important shift in attacker tradecraft: databases are no longer just repositories of valuable information—they are increasingly becoming active platforms for persistence, privilege escalation, and remote command execution.
A Classic SQL Injection with a Modern Twist
According to Huntress, the incident began on July 27, 2026, when security analysts detected suspicious credential theft activity originating from an Oracle database server.
Further investigation revealed that attackers had exploited a vulnerable Java/Tomcat web application connected to an Oracle database through JDBC. Poor input validation allowed malicious SQL statements to be executed directly against the backend database, enabling attackers to bypass normal application logic.
While SQL injection itself is one of the oldest web application attacks, what followed surprised investigators.
Instead of immediately deploying malware onto the Windows operating system, the attackers uploaded Java source code directly into Oracle using the database’s built-in Java Virtual Machine (JVM). Oracle compiled this code internally as legitimate database objects, effectively allowing malicious functionality to live inside the database rather than on disk.
The khunt Toolkit: Malware Hidden Inside Oracle
The embedded toolkit, dubbed khunt, consisted of several specialized modules designed for post-exploitation activities.
Among the most significant components were:
- KhuntCmd – Executes arbitrary Windows operating system commands.
- KhuntHash – Extracts Oracle usernames and password hashes.
- KhuntFS / KhuntFS2 – File browsing and manipulation utilities.
- KhuntT – Connectivity testing tool.
- KhuntUnzip – Archive extraction utility.
- Multiple PL/SQL wrappers enabling seamless execution from SQL.
Unlike conventional malware stored as executable files, these components existed as Oracle database objects, making detection significantly more difficult for traditional endpoint security products that primarily monitor files, processes, and memory.
This represents one of the most notable aspects of the attack and demonstrates how threat actors are increasingly abusing legitimate enterprise technologies to evade security controls.
From Database Access to Windows SYSTEM
Once the toolkit was installed, attackers pivoted from the Oracle database to the underlying Windows operating system.
Using KhuntCmd, they successfully launched cmd.exe through the Oracle process and executed:
cmd.exe /c whoami
The result confirmed that the attackers possessed SYSTEM-level privileges, effectively giving them unrestricted control over the Windows server.
From there they:
- Executed PowerShell commands
- Dumped Windows registry hives
- Copied the SAM, SECURITY and SYSTEM databases
- Enumerated running services
- Prepared credential material for offline password extraction
These registry hive files can later be used to recover password hashes, facilitating lateral movement throughout an enterprise network.
Investigators also identified attacker infrastructure associated with the campaign, including the IP address:
178.162.151.229
along with several Indicators of Compromise (IOCs) related to khunt database objects and registry hive filenames.
Why This Attack Matters
This incident highlights an evolution in attacker methodology.
Historically, databases were considered targets for data theft.
In this campaign, however, Oracle itself became the attack platform.
Because the malicious code resides inside Oracle schema objects rather than traditional executables, many Endpoint Detection and Response (EDR) and antivirus products may never inspect or detect the malicious Java classes.
For defenders, this means database monitoring must become an integral part of enterprise detection strategies not merely endpoint monitoring.
Industry Impact
Organizations running Oracle-backed enterprise applications—including ERP systems, financial platforms, healthcare applications, manufacturing systems, telecommunications infrastructure, and government services—should carefully review database permissions and application security.
The attack also reinforces that secure software development practices remain one of the strongest cybersecurity defenses. The initial compromise did not rely on a newly discovered Oracle vulnerability but rather on insecure coding practices that failed to sanitize user input.
At the same time, Oracle continues to encourage customers to remain on supported software versions and rapidly apply its regular Critical Patch Updates to reduce exposure to known vulnerabilities.
Why Traditional Security May Miss It
Traditional security tools generally monitor:
- Executable files
- Running processes
- DLL injections
- Memory manipulation
However, they rarely inspect:
- Oracle Java Source objects
- Stored Java classes
- PL/SQL wrappers
- Database-resident execution chains
This creates a visibility gap that advanced threat actors are beginning to exploit.
The khunt toolkit demonstrates how attackers can leverage legitimate Oracle functionality to establish persistence while avoiding many conventional detection mechanisms.
10 Recommendations for Security Teams
Security teams should consider implementing the following defensive measures:
- Eliminate SQL injection vulnerabilities through strict input validation.
- Use parameterized SQL queries rather than dynamically building SQL statements.
- Apply the principle of least privilege to Oracle database accounts.
- Prevent application service accounts from creating Java Source objects unless absolutely necessary.
- Audit Oracle environments for unexpected
CREATE JAVA SOURCEactivity. - Monitor Oracle schema objects for unusual Java classes or PL/SQL wrappers.
- Inspect database audit logs for suspicious object creation and compilation events.
- Regularly update Oracle software with the latest Critical Patch Updates.
- Correlate database events with endpoint telemetry to detect unusual parent-child process relationships involving
oracle.exe. - Conduct regular secure coding and developer awareness training to reduce SQL injection risks.
MEA Perspective
Although the attack is globally relevant, its implications are particularly important across the Middle East and Africa, where Oracle databases underpin critical sectors including banking, telecommunications, energy, healthcare, education, and public administration.
Many organizations continue to modernize legacy enterprise applications while exposing new digital services to the internet. Without secure application development practices and continuous database monitoring, similar attacks could provide adversaries with direct access to critical national infrastructure.
As digital transformation accelerates across the region, protecting database platforms must become a core component of enterprise cyber resilience.
Conclusion
The Huntress investigation serves as a reminder that even mature attack techniques like SQL injection remain highly effective when basic security controls fail.
What makes this campaign particularly significant is not the initial compromise but the attackers’ ability to weaponize Oracle’s legitimate Java capabilities, transforming the database into an invisible post-exploitation platform capable of executing operating system commands and harvesting credentials.
For defenders, the lesson is clear: protecting enterprise databases requires more than patching and perimeter defenses. Continuous monitoring of database activity, secure application development, least-privilege access, and proactive threat hunting are now essential to preventing databases from becoming hidden attack platforms.
