Wednesday, August 5, 2026 Login
Breaking
Oded Fehr Returns as Ardeth Bay in The Mummy 4 What to expect from Pixel 11 HiLight notifications in Contacts Saudi Aramco backs India’s Mitti Labs to make Asia’s rice farming more water-resilient Delhi Premier League:Match 10 – Purani Delhi 6 vs Central Delhi Kings and Match 11 What You Sleep On Could Be Affecting Your Health More Than You Think – inc.com
Technology

Hackers Smuggle Post-Exploitation Toolkit Into Oracle Database Via Classic SQL Injection Flaw

A SQL injection vulnerability that many organisations might consider a decades-old, well-understood threat has been used as the entry point for a far more sophisticated attack, after threat actors were caught planting a custom-built, database-resident toolkit inside an Oracle database.

Security firm Huntress said it was alerted to suspicious activity on an endpoint hosting an Oracle database server on 27 July 2026, after detecting attempts to copy the SAM, SECURITY and SYSTEM Windows registry hives, files typically targeted by attackers seeking to extract and crack stored credentials.

Further investigation traced the intrusion back to a SQL injection flaw in a public-facing web application connected to the Oracle database. A form field within the application had failed to properly validate user input, allowing the attacker to submit malicious SQL statements that the application executed without question.

What happened next set the incident apart from a typical SQL injection case. Rather than simply querying or manipulating data, the attacker used the access to issue CREATE JAVA SOURCE commands, a legitimate Oracle database feature that allows developers to store and compile Java code as objects inside the database itself. The attacker abused this functionality to upload and compile a full post-exploitation toolkit, dubbed “khunt”, directly within the database engine.

Huntress noted that while the underlying technique, sometimes referred to as “oraexec”, has been discussed in security research circles for years, real-world use of it in an active attack has rarely been documented.

A toolkit built for the database layer

According to Huntress, the khunt toolkit was made up of several purpose-built modules compiled and stored as schema objects, including a tool that let the attacker run arbitrary operating system commands from within the database, and another that pulled usernames and password data directly out of Oracle’s internal user tables. Additional components allowed the attacker to browse the file system, confirm the toolkit was reachable, and unzip files, with several PL/SQL wrappers used to call the underlying Java methods.

Using the command-execution module, the attacker pivoted from the database to the underlying Windows server, running whoami to confirm they had SYSTEM-level privileges, effectively achieving full remote code execution that originated from the database layer. From there, the attacker used PowerShell and native Windows utilities, including the registry tool and the Extensible Storage Engine utility, to copy the SAM, SECURITY and SYSTEM registry hives and enumerate running services, saving the results to a directory on the compromised host.

A blind spot for traditional defences

Huntress warned that storing malicious code as a database object, rather than as a conventional file or in-memory process, creates a significant blind spot for many organisations’ existing security tooling. Traditional endpoint detection and antivirus products are generally built to monitor processes, binaries and files at the operating system level, and do not typically inspect Java classes or PL/SQL objects running inside a database engine.

The firm said the incident illustrates how a database can be repurposed from a system that simply stores and returns data into a beachhead from which further attacks are launched and that no novel or unpatched vulnerability was required to make it happen. The initial foothold came from a basic failure to validate user input in a web form.

To defend against similar attacks, Huntress recommended organisations ensure public-facing forms are properly protected against injection through input sanitisation and query parameterisation, and that database accounts are not overprovisioned. Even where SQL injection does succeed, the firm said, the compromised account should not have the privileges needed to create Java sources or execute stored procedures.

The findings serve as a reminder that even well-worn attack techniques like SQL injection can still yield serious consequences when combined with lesser-known platform features, and that database servers deserve the same level of scrutiny as endpoints and network infrastructure.

Source link

Related Stories

Leave a Comment

Your email address will not be published. Required fields are marked *