SQL Injection Led to Java Malware in Oracle DB

What Happened

Attackers exploited a SQL injection vulnerability to access an Oracle Database and used its Java capabilities to install a custom toolkit called Khunt. They used Oracle's CREATE JAVA SOURCE functionality to store malicious Java code directly in the database. This allowed them persistent access and the ability to execute system commands at the SYSTEM level on the Windows server.

Huntress discovered the incident and documented how attackers moved from web application compromise to database-level persistence using Oracle's development features.

Timeline

The attack progression is as follows:

1. Initial compromise: SQL injection in a web application with database access.
2. Privilege escalation: Attackers gained DBA-level permissions within the database.
3. Persistence establishment: Used CREATE JAVA SOURCE to install the Khunt toolkit as database objects.
4. Command execution: Escalated to SYSTEM-level OS access on the Windows host.
5. Detection: Huntress identified the malicious Java objects during investigation.

Which Controls Failed or Were Missing

Input validation and parameterized queries. The SQL injection indicates the application wasn't using prepared statements or validating user input. This was the entry point for the attack.

Principle of least privilege. The database account used by the application had permissions to create Java objects and execute system-level commands. Application service accounts shouldn't have CREATE JAVA SOURCE or JAVA_ADMIN privileges.

Database activity monitoring. The creation of Java objects and command execution should've triggered alerts. No monitoring system flagged unusual database behavior.

Network segmentation. The database server had direct outbound network access, allowing attackers to communicate with external command-and-control infrastructure. Database servers shouldn't route to the internet.

File integrity monitoring. Changes to database objects, particularly Java stored procedures, went undetected. The database didn't have monitoring for schema changes or new object creation.

What the Standards Require

PCI DSS v4.0.1 Requirement 6.2.4 mandates that web-facing applications protect against common attacks, explicitly listing SQL injection. Use parameterized queries or equivalent input validation.

OWASP ASVS v4.0.3 Section 5.3.4 requires that database queries use parameterized queries, stored procedures, or ORM frameworks to prevent SQL injection. String concatenation for query construction is prohibited.

PCI DSS v4.0.1 Requirement 7.2.2 requires that access to system components and data is based on users' job classification and function, following least privilege. A web application service account doesn't need DBA permissions or the ability to create Java objects.

NIST 800-53 Rev 5 Control AC-6 (Least Privilege) states that you should employ the principle of least privilege, allowing only authorized accesses necessary to accomplish assigned organizational missions. Database accounts should have the minimum permissions required for their function.

ISO/IEC 27001:2022 Control 8.3 (Information Access Restriction) requires restricting access to information and information processing facilities based on business requirements. Creating Java objects in a production database isn't a business requirement for a web application.

PCI DSS v4.0.1 Requirement 10.2.1.1 requires audit logs for all individual user access to cardholder data. Database activity monitoring should capture administrative actions like creating stored procedures or Java objects.

Lessons and Action Items for Your Team

Audit database permissions immediately. Run this query on your Oracle instances:

SELECT grantee, privilege 
FROM dba_sys_privs 
WHERE privilege LIKE '%JAVA%' 
   OR privilege LIKE '%CREATE%';

Any application service account with CREATE JAVA SOURCE, CREATE PROCEDURE, or JAVA_ADMIN needs immediate remediation. Your web application doesn't need these permissions.

Implement schema change monitoring. Configure alerts for:

• New Java objects created in the database
• Changes to existing stored procedures or functions
• Grants of elevated privileges
• Execution of system-level commands through database functions

Tools like Oracle Audit Vault or third-party database activity monitoring solutions can detect these actions in real time.

Review your SQL injection prevention. Don't assume your current controls are sufficient. Test them:

• Run static analysis on your codebase looking for string concatenation in SQL queries
• Deploy dynamic application security testing tools that specifically test for SQL injection
• Add SQL injection checks to your CI/CD pipeline

Segment your database network. Your database servers shouldn't have direct internet access. Configure firewall rules so databases can only communicate with:

• Application servers that need them
• Backup infrastructure
• Database administration hosts on a separate management network

Enable Java security manager restrictions. If you use Java in your Oracle Database, configure the Java security manager to restrict what Java code can do:

EXEC DBMS_JAVA.SET_PROPERTY('oracle.aurora.security.SecurityManager', 'on');

This limits Java's ability to access files, network resources, and system commands even if malicious code gets loaded.

Create a database object baseline. Document what Java objects, stored procedures, and functions should exist in your production databases. Monitor for deviations. Any new object that isn't part of a documented deployment should trigger investigation.

The attackers in this incident didn't exploit a zero-day or use sophisticated techniques. They used SQL injection (ranked #3 in the OWASP Top 10 2021) and then used documented Oracle features. Your existing controls should catch this if they're properly configured and monitored.

OWASP Top 10 2021