khunt — Oracle In-Database Java Post-Exploitation Toolkit

Huntress published incident research on 2026-08-05 describing an intrusion that began with a textbook SQL injection flaw and ended with operating-system remote code execution as NT AUTHORITY\SYSTEM. The entry point was an autocomplete/search form on a public-facing Java application fronted by Apache Tomcat that failed to validate input; the application passed the attacker's SQL straight through its JDBC connection to a backend Oracle Database. No CVE, no zero-day, no novel exploit: the vulnerability was unparameterised input.

What makes this pack worth building is what the attacker did after the injection. Rather than dropping a binary, they used Oracle's embedded JVM and the CREATE JAVA SOURCE statement to compile and store a post-exploitation toolkit named khunt directly inside the database as schema objects, then exposed it to SQL callers through khunt_* PL/SQL wrappers. The toolkit shipped six components: KhuntCmd (launches cmd.exe and runs arbitrary OS commands from a SQL statement), KhuntHash (reads Oracle's internal user table and writes usernames and password data to a file), KhuntFS and KhuntFS2 (file listing, reading, searching, size checks), KhuntT (a ping-style liveness check for the toolkit), and KhuntUnzip (archive extraction).

With the toolkit installed, the actor ran cmd.exe /c whoami, confirmed SYSTEM-level privileges inherited from the Oracle service, enumerated services with tasklist /svc, and copied the SAM, SECURITY and SYSTEM registry hives using PowerShell-invoked reg.exe and esentutl.exe, staging everything into the Oracle installation directory. The detection that started the investigation was the credential-theft activity, not the injection: reg.exe spawned from an oracle.exe parent.

The highest-value defensive angle is the process-lineage break. Endpoint tooling does not inspect Java classes or PL/SQL wrappers living inside an Oracle schema, so the toolkit itself is effectively invisible to EDR. What is not invisible is the moment the database process forks a shell. Every OS-level action in this intrusion descends from oracle.exe, and a healthy database server almost never spawns cmd.exe or powershell.exe.

Defender priority: hunt for command interpreters and credential-access binaries whose parent or grandparent is an Oracle service process (oracle.exe, tnslsnr.exe, extproc.exe, oradim.exe). Then go into the database itself and enumerate JAVA SOURCE / JAVA CLASS objects — the toolkit is a schema object, so no file-based scan will ever find it.

Research notes and decisions

• No hashes exist to ship. The toolkit never lands on disk as a file, so no vendor published a SHA256. Any hash row in the IOC CSV would be invented. The CSV therefore ships the IP and the four staged artifact filenames, and says so explicitly in a comment.
• No CVE. This is an application input-validation defect, not a product vulnerability. Do not wait for a patch — there is nothing to patch.
• The technique is old, the sighting is not. Huntress notes the approach has been described for years (they reference an oraexec-style technique) but is rarely documented in the wild. Treat the TTP as durable and the infrastructure as perishable.
• Victim and environment details deliberately omitted. The reported staging path was on an F: volume; this pack matches on the \Oracle\ directory component and the khunt filename prefix rather than a drive letter, so the detections port to any environment.
• Gap: no source describes the exact SQL payload, the specific application, or any post-hive-dump lateral movement. Hunt content for those steps is hypothesis-driven, not intel-driven, and is marked as such in the coverage map.

Attack chain

Hunt hypotheses (ordered by fidelity)

1. H1 — Database service spawns a command interpreter. If khunt (or any in-database RCE technique) is used, an Oracle service process becomes the parent of cmd.exe or powershell.exe. Covers T1190/T1505.001/T1059.003. Falcon: ProcessRollup2. Expected FP: RMAN/OPatch wrapper scripts. Confidence: high.
2. H2 — Registry hive export from a database-parented process. Credential access via reg save or esentutl against SAM/SECURITY/SYSTEM. Covers T1003.002/T1003.004. Falcon: ProcessRollup2. Expected FP: backup and DR tooling. Confidence: high.
3. H3 — khunt-named artifacts appear in command lines. Any reference to khunt in a process command line is campaign-specific. Falcon: ProcessRollup2. Expected FP: negligible. Confidence: high (but only fires on this exact tooling).
4. H4 — Web tier spawns a shell. The Tomcat/Java process forking a command interpreter is the generic form of the same entry point and also catches JSP webshells. Falcon: ProcessRollup2. Expected FP: build agents, Java apps that legitimately shell out. Confidence: medium.
5. H5 — Discovery burst under a database-parented shell. whoami, tasklist, systeminfo, net executed in short order beneath an Oracle process. Falcon: ProcessRollup2 aggregated. Confidence: medium-high.
6. H6 — Local data staging in the Oracle install directory. Hive and text artifacts written into \Oracle\. Covers T1074.001. Confidence: medium.
7. H7 — Contact with the reported attacker infrastructure. Inbound or outbound traffic involving the published source IP. Falcon: NetworkConnectIP4 / NetworkReceiveAcceptIP4. Confidence: medium and highly perishable.
8. H8 — Anomalous child-process baseline for Oracle services. Stack-count every child of the Oracle binaries and review the long tail. Confidence: low individually, high as a triage surface.

Steps 2, 3, 4 and 10 have no endpoint telemetry. They live entirely inside the database engine and are only reachable through the Oracle audit trail and data-dictionary queries in section 7. A pack that only runs the CQL will miss the persistence mechanism itself.

No file hashes are published for khunt and none are invented here. The toolkit exists as compiled Oracle schema objects, so there is no on-disk sample to hash. If your own IR produces one, add it to the CSV in section 10.

These are the checks that find the parts of this intrusion EDR cannot see. Run them as a read-only DBA and treat any hit as an incident, not a finding. All statements below are enumeration only — they read the data dictionary and the audit trail and change nothing.

A. Oracle — enumerate Java objects in the database

-- Every Java object in the database, newest first. On a clean system the only
-- rows should be Oracle-shipped objects owned by SYS / SYSTEM / ORDSYS / MDSYS.
SELECT owner, object_name, object_type, created, last_ddl_time, status
  FROM dba_objects
 WHERE object_type IN ('JAVA SOURCE','JAVA CLASS','JAVA RESOURCE')
 ORDER BY created DESC;

-- The vendor-recommended name search. Matches the six khunt Java classes and the
-- khunt_* PL/SQL wrappers in one pass.
SELECT owner, object_name, object_type, created
  FROM dba_objects
 WHERE UPPER(object_name) LIKE 'KHUNT%';

-- Java objects owned by anything that is not an Oracle-shipped schema.
SELECT owner, COUNT(*) AS java_objects
  FROM dba_objects
 WHERE object_type LIKE 'JAVA%'
   AND owner NOT IN ('SYS','SYSTEM','ORDSYS','MDSYS','XDB','CTXSYS','EXFSYS','OLAPSYS')
 GROUP BY owner
 ORDER BY java_objects DESC;

B. Oracle — audit trail for Java-source creation and OS bridging

-- Unified auditing: any DDL that authored a Java source, or any call into the
-- DBMS_JAVA package. Requires unified auditing to be enabled (playbook 2).
SELECT event_timestamp, dbusername, os_username, userhost, client_program_name,
       action_name, object_schema, object_name, sql_text
  FROM unified_audit_trail
 WHERE (UPPER(sql_text) LIKE '%CREATE%JAVA%SOURCE%'
     OR UPPER(sql_text) LIKE '%DBMS_JAVA%'
     OR UPPER(sql_text) LIKE '%KHUNT%')
 ORDER BY event_timestamp DESC;

-- Shared-pool residue: cached SQL text that touched Java or the khunt objects.
-- Useful even without auditing, but volatile -- capture it before any restart.
SELECT sql_id, parsing_schema_name, last_active_time, sql_fulltext
  FROM v$sql
 WHERE UPPER(sql_fulltext) LIKE '%JAVA SOURCE%'
    OR UPPER(sql_fulltext) LIKE '%KHUNT%';

-- Stored PL/SQL source that references a Java call spec or DBMS_JAVA.
SELECT owner, name, type, line, text
  FROM dba_source
 WHERE UPPER(text) LIKE '%LANGUAGE JAVA%'
    OR UPPER(text) LIKE '%DBMS_JAVA%'
    OR UPPER(name) LIKE 'KHUNT%';

C. Oracle — privilege audit on the application account

-- Which accounts can author Java or run arbitrary procedures? The application
-- schema should appear in NONE of these result sets.
SELECT grantee, privilege
  FROM dba_sys_privs
 WHERE privilege IN ('CREATE ANY PROCEDURE','CREATE PROCEDURE',
                     'CREATE ANY LIBRARY','CREATE LIBRARY',
                     'EXECUTE ANY PROCEDURE','JAVA SYSCLASS',
                     'CREATE ANY TABLE','ALTER SYSTEM')
 ORDER BY grantee;

-- EXECUTE on the Java bridge packages granted to PUBLIC or to an app account.
SELECT grantee, owner, table_name AS package_name, privilege
  FROM dba_tab_privs
 WHERE table_name IN ('DBMS_JAVA','DBMS_JAVA_TEST','DBMS_SCHEDULER','UTL_FILE','DBMS_LOB')
   AND privilege = 'EXECUTE'
 ORDER BY grantee;

-- Java runtime permissions -- the row that lets a Java class shell out is a
-- java.io.FilePermission ... execute, or a java.lang.RuntimePermission.
SELECT grantee, type_name, name, action, enabled
  FROM dba_java_policy
 WHERE UPPER(type_name) LIKE '%RUNTIMEPERMISSION%'
    OR UPPER(action) LIKE '%EXECUTE%';

D. Tomcat / Apache access log — the injection itself

# The reported source IP, across every rotated access log.
grep -rF "178.162.151.229" /var/log/apache2/ /opt/tomcat/logs/

# SQL keywords in query strings -- the injectable endpoint was an autocomplete
# search, so the payload arrives URL-encoded in a GET parameter.
grep -rEi "(create[+ %]java|union[+ %]select|dbms_|utl_|%27|'--|xp_cmdshell)" \
     /var/log/apache2/access.log*

# Request-volume outliers against a single endpoint. The original investigation
# identified the actor purely from how much traffic one source sent to one path.
awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -25

E. Windows event log — the OS half, if Falcon is not deployed

• Security 4688 (process creation, requires command-line auditing): filter ParentProcessName ending in oracle.exe, tnslsnr.exe, extproc.exe or oradim.exe. Any hit is worth reading.
• Security 4663 / 4656 (object access) on %SystemRoot%\System32\config\SAM and ...\SECURITY, once SACLs are in place.
• Sysmon 1 (process create) with the same parent filter; Sysmon 11 (file create) for *.hiv and khunt* anywhere on the volume.
• System 7045 / 7036 — confirm which identity the Oracle services run as. If it is LocalSystem, every khunt command would have run as SYSTEM.
• PowerShell 4104 (script block logging) for reg save, esentutl, and any script writing into the Oracle directory.

None of these queries carry an in-query time filter. Set the window with the console time picker; each card records the intended lookback as a // LOOKBACK: comment. Start every hunt at Q1 — it is the single highest-value query in this pack.

// HUNT: Oracle database service spawning a Windows command interpreter
// MITRE: T1190, T1505.001, T1059.003, T1059.001 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 on Windows hosts running Oracle Database
// FALSE POSITIVES: RMAN / OPatch / OEM agent wrapper scripts legitimately shell out
// TUNING: exclude your own maintenance wrappers by path, e.g. append
//   | CommandLine!=/\\opatch\\|\\rman_backup\\|\\oem_agent\\/i
// LOOKBACK: 30d -- set the window in the console time picker
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(oracle|tnslsnr|extproc|extproc32|oradim|emagent)\.exe$/i
| FileName=/^(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|bash)\.exe$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, TargetProcessId])
| sort(@timestamp, order=desc, limit=200)

// HUNT: SAM / SECURITY / SYSTEM registry hive export to a file
// MITRE: T1003.002, T1003.004 | CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2 with command lines on Windows servers
// FALSE POSITIVES: backup / DR / server-migration agents legitimately export hives
// TUNING: exclude your backup agent lineage, e.g. append
//   | ParentBaseFileName!=/^(veeamagent|backupexec|acronis|dpm|ntbackup)\.exe$/i
// LOOKBACK: 30d -- set the window in the console time picker
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(reg|reg32|esentutl|regedit)\.exe$/i
| CommandLine=/(hklm\\(sam|security|system)|\\config\\(sam|security|system)|\.hiv\b)/i
| table([@timestamp, aid, ComputerName, UserName, GrandparentBaseFileName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc, limit=200)

// HUNT: second-generation descendants of an Oracle service process
// MITRE: T1505.001, T1059.003, T1003.002 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 with GrandparentBaseFileName populated
// FALSE POSITIVES: OPatch and OEM agent job chains produce multi-level trees
// TUNING: if OPatch is noisy, append | CommandLine!=/\\opatch\\/i
// LOOKBACK: 30d -- set the window in the console time picker
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| (ParentBaseFileName=/^(oracle|tnslsnr|extproc|oradim)\.exe$/i or GrandparentBaseFileName=/^(oracle|tnslsnr|extproc|oradim)\.exe$/i)
| FileName!=/^(conhost|werfault|oracle|tnslsnr)\.exe$/i
| table([@timestamp, aid, ComputerName, UserName, GrandparentBaseFileName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc, limit=200)

// HUNT: khunt toolkit artifact and object names on the command line
// MITRE: T1074.001, T1003.002, T1007 | CONF: high  FP: low  COST: medium
// REQUIRES: ProcessRollup2 with command lines
// FALSE POSITIVES: essentially none -- the string is campaign-specific
// TUNING: none needed; if a benign internal tool uses the prefix, anchor on the
//   full artifact names only by dropping the bare khunt alternative
// LOOKBACK: 90d -- set the window in the console time picker
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| CommandLine=/(khunttasks\.txt|khuntsam\.hiv|khuntsecurity\.hiv|khunt_security\.hiv|khuntsystem\.hiv|khuntcmd|khunthash|khuntfs2|khuntfs|khuntunzip|khunt_)/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc, limit=200)

// HUNT: connections involving the reported khunt injection source address
// MITRE: T1190 | CONF: medium  FP: low  COST: low
// REQUIRES: NetworkConnectIP4 / NetworkReceiveAcceptIP4
// FALSE POSITIVES: none expected; the address is not shared hosting per the report
// TUNING: not required at FP low -- but expire this indicator on 2026-11-06
// LOOKBACK: 90d -- set the window in the console time picker
#event_simpleName=/^(NetworkConnectIP4|NetworkReceiveAcceptIP4)$/
| RemoteAddressIP4="178.162.151.229"
| table([@timestamp, aid, ComputerName, LocalAddressIP4, LocalPort, RemoteAddressIP4, RemotePort, ContextBaseFileName])
| sort(@timestamp, order=desc, limit=200)

// HUNT: application server (Java / Tomcat / IIS) spawning a shell or discovery tool
// MITRE: T1190, T1059.003, T1505.003 | CONF: medium  FP: medium  COST: low
// REQUIRES: ProcessRollup2 on internet-facing application servers
// FALSE POSITIVES: build agents, CI runners, Java apps that shell out by design
// TUNING: scope to internet-facing hosts and drop known build servers, e.g. append
//   | ComputerName!=/^(BUILD|CI|JENKINS)-/i
// LOOKBACK: 30d -- set the window in the console time picker
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(java|javaw|tomcat\d*|catalina|httpd|nginx|w3wp)\.exe$/i
| FileName=/^(cmd|powershell|pwsh|whoami|net|net1|systeminfo|tasklist|reg|esentutl|certutil|bitsadmin)\.exe$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc, limit=200)

// HUNT: clustered host/service discovery under a database-parented shell
// MITRE: T1033, T1007, T1057, T1082 | CONF: medium  FP: medium  COST: medium
// REQUIRES: ProcessRollup2 with command lines
// FALSE POSITIVES: DBA troubleshooting and monitoring agents run the same binaries
// TUNING: raise the Hits floor from 2 to 4 in a noisy estate, and exclude your
//   monitoring service account with | UserName!=/^svc_monitor$/i
// LOOKBACK: 7d per run -- set the window in the console time picker
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| GrandparentBaseFileName=/^(oracle|tnslsnr|extproc|oradim|java|javaw)\.exe$/i
| FileName=/^(whoami|tasklist|systeminfo|net|net1|ipconfig|nltest|quser|hostname|arp)\.exe$/i
| groupBy([aid, ComputerName, UserName, GrandparentBaseFileName], function=[count(as=Hits), count(FileName, distinct=true, as=DistinctTools), collect(CommandLine, limit=25)], limit=400)
| DistinctTools > 2
| sort(Hits, order=desc, limit=100)

// HUNT: rarest child processes of Oracle service binaries (baseline builder)
// MITRE: T1505.001, T1059 | CONF: medium  FP: high  COST: medium
// REQUIRES: ProcessRollup2 across all Oracle database hosts
// FALSE POSITIVES: this is a stack-count, not a detection -- most rows are benign
// TUNING: review only rows where Hosts = 1; promote the frequent, benign rows into
//   the exclusion list used by Q1 and Q3 rather than tuning this query itself
// LOOKBACK: 90d -- set the window in the console time picker
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(oracle|tnslsnr|extproc|extproc32|oradim|emagent)\.exe$/i
| groupBy([ParentBaseFileName, FileName], function=[count(as=Hits), count(aid, distinct=true, as=Hosts), collect(CommandLine, limit=5)], limit=1000)
| sort(Hits, order=asc, limit=200)

Two of the eight queries are strong enough to promote from Investigate-only to a Custom IOA. The rest stay as scheduled hunt searches. Build IOAs under Endpoint security → Custom IOA rule groups → Process Creation, and run each in Monitor for at least seven days before switching to Detect or Block.

IOA-1 — Database service spawns a command interpreter (from Q1)

IOA-2 — Hive export by a shell-parented process (from Q2 + Q3)

Stays as a scheduled search (Investigate-only)

• Q4 — named-tooling match. Very high precision but zero recall against a renamed toolkit; better as a daily scheduled search with email alerting than as an IOA.
• Q5 — single-IP indicator. Put it in Falcon IOC Management with detect, not in an IOA.
• Q6, Q7 — medium FP; run weekly and tune before considering promotion.
• Q8 — baseline stack-count. Never an IOA; run quarterly to refresh the exclusion lists for IOA-1.

Falcon cannot see inside the Oracle schema. No IOA, IOC or ML model will detect the khunt objects themselves — only the moment they touch the OS. The database-side controls in sections 7, 12 and 13 are not optional extras here, they are the other half of the coverage.

Gate 1 — Telemetry ready

• Confirm the Falcon sensor is installed and reporting on every Oracle database host. Run #event_simpleName=/^ProcessRollup2$/ | ComputerName=/^DB/i | groupBy([ComputerName], limit=200) and reconcile against the DBA team's inventory. Database servers are a classic sensor-coverage hole.
• Confirm command-line capture is on. If CommandLine is empty, Q2, Q4, Q6 and Q7 all silently return nothing.
• Confirm GrandparentBaseFileName is populated in your tenant's process events — Q3 and Q7 depend on it.
• Confirm Oracle unified auditing is enabled and reaching the SIEM. Without it, four of the ten attack-chain steps have no evidence source at all.

Gate 2 — Benign baseline

• Run Q8 over 90 days before enabling anything. Record every child process the Oracle binaries legitimately launch in your estate; that list becomes the exclusion set for IOA-1.
• Run Q2 over 30 days and identify every backup or DR product that exports hives on schedule. Note the parent process, not the file path — an attacker can drop a binary at the same path.
• Run Q6 across the web estate and separate build/CI hosts from genuinely internet-facing ones.

Gate 3 — Positive tests (authorised lab only)

• On a lab database host, have a DBA start a benign child process from a scheduled Oracle job and confirm Q1 and Q8 both surface it. This validates the lineage fields without simulating the attack.
• Export a SYSTEM hive on a lab server using your normal backup tool and confirm Q2 fires and that your backup exclusion correctly suppresses it.
• Create a harmless Java source object in a lab schema (CREATE JAVA SOURCE returning a constant) and confirm the section 7 data-dictionary query and the unified audit policy both catch it. This is the single most important test in the pack, because it validates the only control that sees the persistence mechanism.
• Do not attempt to reproduce OS command execution from the database. The enumeration test above proves the detection without creating an exploitable object.

Gate 4 — Promotion criteria

• IOA-1 moves Monitor → Detect after seven consecutive days with zero unexplained hits.
• IOA-2 moves Monitor → Block after the backup exclusion has been verified against a full backup cycle, including monthly and quarterly jobs.
• The Oracle audit policy is considered deployed only once its events are queryable in the SIEM, not once it is enabled on the host.

This intrusion needed three separate failures to reach SYSTEM: unvalidated input in the application, an over-privileged database account, and a database service running as LocalSystem. Fixing any one of them breaks the chain. The controls below are ordered by how much of the chain they remove per unit of deployment friction.

Every step below changes production state. Run each in a non-production clone first, and read the Rollback line before you run the command, not after.

Playbook 1 — De-privilege the application database account

Prerequisites: DBA (SYSDBA) access; the exact application schema name; an agreed maintenance window; a confirmed database backup. Reboot required: no — but the application should be restarted to refresh pooled connections. Rollback: re-grant with the recorded output of step 1 (the SPOOL file captures the pre-change state verbatim; each revoked privilege maps to one GRANT statement).

-- 1. CAPTURE THE CURRENT STATE FIRST. This file is your rollback script.
SPOOL /secure/backout/app_privs_2026-08-06.log
SELECT 'GRANT ' || privilege || ' TO ' || grantee || ';'
  FROM dba_sys_privs WHERE grantee = UPPER('&app_schema');
SELECT 'GRANT ' || granted_role || ' TO ' || grantee || ';'
  FROM dba_role_privs WHERE grantee = UPPER('&app_schema');
SPOOL OFF

-- 2. Revoke the privileges that made CREATE JAVA SOURCE possible.
REVOKE CREATE ANY PROCEDURE FROM &app_schema;
REVOKE CREATE PROCEDURE     FROM &app_schema;
REVOKE CREATE ANY LIBRARY   FROM &app_schema;
REVOKE CREATE LIBRARY       FROM &app_schema;
REVOKE EXECUTE ANY PROCEDURE FROM &app_schema;
REVOKE JAVA SYSCLASS        FROM &app_schema;

-- 3. Remove the PUBLIC grants on the PL/SQL-to-Java bridge packages.
REVOKE EXECUTE ON DBMS_JAVA      FROM PUBLIC;
REVOKE EXECUTE ON DBMS_JAVA_TEST FROM PUBLIC;

-- 4. Confirm. Both queries must return zero rows.
SELECT grantee, privilege FROM dba_sys_privs
 WHERE grantee = UPPER('&app_schema')
   AND privilege IN ('CREATE ANY PROCEDURE','CREATE PROCEDURE',
                     'CREATE ANY LIBRARY','CREATE LIBRARY',
                     'EXECUTE ANY PROCEDURE','JAVA SYSCLASS');
SELECT grantee FROM dba_tab_privs
 WHERE table_name IN ('DBMS_JAVA','DBMS_JAVA_TEST') AND grantee = 'PUBLIC';

-- 5. Restart the application's connection pool and run a full functional test.
--    If the application genuinely needs one of these privileges, grant back the
--    single narrowest one from the spool file rather than reverting the lot.

Playbook 2 — Audit Java-source creation and ship it to the SIEM

Prerequisites: Oracle 12c or later with unified auditing available; SYSDBA; a SIEM collector already reading from the database host or via a database connector. Reboot required: no (a database restart is required only when converting from mixed-mode to pure unified auditing). Rollback: NOAUDIT POLICY khunt_java_watch; then DROP AUDIT POLICY khunt_java_watch; — this removes the policy and stops collection with no other side effects.

-- 1. Create a policy covering the toolkit-delivery actions.
CREATE AUDIT POLICY khunt_java_watch
  ACTIONS CREATE JAVA SOURCE,
          ALTER JAVA SOURCE,
          DROP JAVA SOURCE,
          CREATE PROCEDURE,
          CREATE LIBRARY,
          EXECUTE ON DBMS_JAVA,
          EXECUTE ON DBMS_JAVA_TEST;

-- 2. Enable it for everyone, including privileged users.
AUDIT POLICY khunt_java_watch;

-- 3. Verify the policy is live.
SELECT policy_name, enabled_option, user_name
  FROM audit_unified_enabled_policies
 WHERE policy_name = 'KHUNT_JAVA_WATCH';

-- 4. Prove collection works: create and immediately drop a harmless Java source
--    in a LAB schema, then confirm it appears in the trail and in the SIEM.
SELECT event_timestamp, dbusername, userhost, action_name, object_name, sql_text
  FROM unified_audit_trail
 WHERE unified_audit_policies LIKE '%KHUNT_JAVA_WATCH%'
 ORDER BY event_timestamp DESC FETCH FIRST 20 ROWS ONLY;

-- 5. Set a retention that survives an incident: audit data an attacker with
--    SYSTEM can purge locally is not evidence. Forward it off-host.

Playbook 3 — Move the Oracle Windows services off LocalSystem

Prerequisites: local administrator on the database host; a dedicated service account (managed service account or domain user with a long random password held in your PAM tool); a full outage window; a tested restore. This is the highest-impact and highest-risk change in the pack. Reboot required: yes — services must be stopped and the host restarted after the ACL changes. Rollback: set each service back to LocalSystem with sc.exe config <service> obj= LocalSystem and reboot; the ACL grants added in step 3 are additive and can be left in place or removed with icacls /remove.

# 1. Inventory the services and their current identity. Record this output --
#    it is the rollback state.
Get-CimInstance Win32_Service |
  Where-Object { $_.Name -like 'Oracle*' } |
  Select-Object Name, StartName, State, PathName |
  Format-Table -AutoSize

# 2. Confirm which of them are running as LocalSystem.
Get-CimInstance Win32_Service |
  Where-Object { $_.Name -like 'Oracle*' -and $_.StartName -eq 'LocalSystem' } |
  Select-Object Name, StartName

# 3. Grant the new service account what Oracle needs on the Oracle Home and the
#    data/diag directories BEFORE changing the service identity.
$svc = 'DOMAIN\REPLACE_WITH_ORACLE_SERVICE_ACCOUNT'
icacls 'C:\app\oracle\product' /grant "${svc}:(OI)(CI)M" /T
icacls 'C:\app\oracle\oradata' /grant "${svc}:(OI)(CI)M" /T
icacls 'C:\app\oracle\diag'    /grant "${svc}:(OI)(CI)M" /T

# 4. Grant the account "Log on as a service" via your GPO or secedit, then
#    switch each service over. Do ONE service, verify, then continue.
sc.exe config OracleServiceREPLACE_WITH_SID obj= "$svc" password= "REPLACE_WITH_PASSWORD"
sc.exe config OracleREPLACE_WITH_HOME_TNSListener obj= "$svc" password= "REPLACE_WITH_PASSWORD"

# 5. Reboot, then confirm the database is healthy AND that the identity changed.
Get-CimInstance Win32_Service |
  Where-Object { $_.Name -like 'Oracle*' } |
  Select-Object Name, StartName, State

# 6. Post-change validation: from a SQL session, confirm that any OS-touching
#    call now runs without SYSTEM rights. The Falcon-side check is that Q1 and Q3
#    now show a non-SYSTEM UserName for any legitimate Oracle child process.

Playbook 4 — LSA protection and hive-access auditing on database servers

Prerequisites: local administrator or GPO edit rights; confirmation that no third-party authentication provider or smart-card DLL on the host is unsigned (RunAsPPL blocks unsigned LSA plugins); a pilot ring of one non-production database server. Reboot required: yes — RunAsPPL takes effect at boot. Rollback: delete the RunAsPPL value and reboot (see step 4); on hardware with UEFI lock enabled, removal additionally requires the documented Microsoft UEFI-lock removal procedure, so pilot before enabling the lock.

# 1. PRE-FLIGHT: list LSA plugins that would break under PPL. Investigate any
#    unsigned result before continuing.
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Notification Packages"
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Security Packages"

# 2. Enable LSA protection (no UEFI lock, so it stays reversible).
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' `
  -Name 'RunAsPPL' -Value 1 -PropertyType DWORD -Force

# 3. Audit access to the hive files themselves, so a copy attempt is logged even
#    if the process lineage is missed. Enable Object Access auditing first.
auditpol /set /subcategory:"File System" /success:enable /failure:enable
$sam = "$env:SystemRoot\System32\config\SAM"
$acl = Get-Acl $sam -Audit
$rule = New-Object System.Security.AccessControl.FileSystemAuditRule(
  'Everyone','Read','None','None','Success')
$acl.AddAuditRule($rule)
Set-Acl -Path $sam -AclObject $acl

# 4. ROLLBACK for step 2, if an authentication provider breaks after reboot:
#    Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' `
#      -Name 'RunAsPPL' -Force ; then reboot.

# 5. Verify after reboot -- event 12 from Wininit confirms LSASS started
#    as a protected process.
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Wininit'} -MaxEvents 20 |
  Select-Object TimeCreated, Id, Message

Do not restart the database or the host before evidence capture. The shared pool (V$SQL) holds the attacker's SQL text and is lost on restart, and it may be the only record of the injection if unified auditing was not enabled.

Analyst triage checklist for a single Q1 or Q3 hit

1. What is the full process tree? Record parent, grandparent, and the command line of each.
2. Is the parent genuinely an Oracle service binary, or a same-named binary in a non-Oracle path? Check ImageFileName, not just ParentBaseFileName.
3. What identity did the child run as? NT AUTHORITY\SYSTEM on a database-parented shell is the reportable condition.
4. Is there an interactive logon on the host in the same window? A DBA at a console explains a lot; no logon explains nothing.
5. Does a scheduled Oracle job, RMAN backup or OPatch run cover this timestamp? Ask the DBA before escalating, and ask for the job definition, not a verbal yes.
6. Run Q4 on the host. Any hit ends triage and starts an incident.
7. Run the section 7A object query on the instance. This is the step analysts skip and it is the one that finds the toolkit.
8. Check the Apache/Tomcat logs for injection-shaped requests in the hours before the process event, and pull the source addresses.

Read the gaps honestly. Five of fourteen rows are gaps and every one of them sits inside the database engine. That is the defining property of this threat, not a shortcoming of the queries: Falcon has no visibility into Oracle schema objects, so the CQL in section 8 covers the OS-facing half of the intrusion well and the in-database half not at all. A team that deploys only the queries will detect this actor at the moment they run whoami — which is real value, and is exactly how the original incident was found — but will never see the toolkit, will not know it persists after cleanup, and will not detect a quieter operator who stays inside the database. Closing those rows requires the Oracle-side controls: unified auditing (playbook 2), the data-dictionary hunts in section 7, and eventually Database Activity Monitoring. Detection validation for all of this is in section 11; the single most important test there is gate 3's benign CREATE JAVA SOURCE, because it is the only one that proves the gap rows are covered by something.