Response playbooks, investigation guides, and Atomic Red Team tests are Pro-only. Upgrade to unlock the full detection package for THREAT-Impact-FinancialLedgerTampering.

Upgrade to Pro
THREAT-Impact-FinancialLedgerTampering IBM QRadar · QRadar

Detect Financial Ledger and Transaction Record Tampering via Direct Database Manipulation in IBM QRadar

An insider with legitimate database credentials, or an attacker who has obtained them, can bypass an application's business logic entirely and manipulate financial data at the source: connecting directly to the ledger, invoice, or transaction database with an interactive client (SQL Server Management Studio, Azure Data Studio, DBeaver, psql, mysql CLI) instead of through the application's service account, then issuing UPDATE or DELETE statements against tables such as general_ledger, invoices, journal_entries, gl_entries, ap_transactions, or account_balances. This is functionally identical to APT38's DYEPACK tool altering SWIFT transaction records to conceal fraudulent transfers, and to the classic 'ghost employee' or 'check kiting' fraud pattern where a trusted insider edits posted transactions after the fact rather than through a reversing journal entry (which would leave the expected audit trail). Three behaviors distinguish malicious tampering from legitimate maintenance: (1) the write originates from an ad-hoc/interactive client tool or an identity other than the application's own connection pool account — legitimate corrections almost always flow back through the application, which posts compensating entries rather than editing history in place; (2) the activity clusters off-hours or on weekends, when fewer people are watching and reconciliation staff are not online; and (3) the write is preceded by disabling the database's own audit trail for that table or database — SQL Server 'ALTER SERVER AUDIT ... WITH (STATE = OFF)', temporal-table system-versioning disablement, change-tracking disablement, or a DISABLE TRIGGER on an audit trigger — which is a strong signal since audit trails exist specifically to survive this kind of tampering and disabling one immediately before writing to financial tables has essentially no legitimate business justification. This detection watches SQL platform audit logs (Azure SQL Auditing / SQL Server Audit, or equivalent extended-events output) for the write pattern, the audit-disablement pattern, and the two-step sequence where disablement precedes writes within a short window.

MITRE ATT&CK

Tactic
Impact

QRadar Detection Query

IBM QRadar (QRadar)
sql
SELECT
  DATEFORMAT(starttime, 'YYYY-MM-dd HH:mm:ss') AS EventTime,
  "Action Name" AS ActionName,
  "Object Name" AS ObjectName,
  "Server Principal Name" AS ServerPrincipal,
  "Database Name" AS DatabaseName,
  "Application Name" AS ClientApp,
  CASE
    WHEN "Action Name" IN ('AUDIT_CHANGE_GROUP','SERVER_OBJECT_CHANGE_GROUP') THEN 'AuditDisable'
    WHEN "Action Name" IN ('UPDATE','DELETE') AND "Object Name" ILIKE ANY ('%ledger%','%invoice%','%transaction%','%payment%','%journal_entr%','%gl_entr%','%account_balance%') THEN 'FinancialWrite'
    ELSE 'Other'
  END AS Indicator
FROM events
WHERE
  LOGSOURCETYPENAME(logsourceid) ILIKE '%SQL%Audit%'
  AND (
    "Action Name" IN ('AUDIT_CHANGE_GROUP','SERVER_OBJECT_CHANGE_GROUP')
    OR (
      "Action Name" IN ('UPDATE','DELETE')
      AND "Object Name" ILIKE ANY ('%ledger%','%invoice%','%transaction%','%payment%','%journal_entr%','%gl_entr%','%account_balance%')
      AND "Succeeded" ILIKE 'true'
    )
  )
ORDER BY starttime DESC
LAST 24 HOURS
high severity medium confidence

QRadar AQL query over SQL Server / Azure SQL Audit log source events, labeling each matching row as AuditDisable or FinancialWrite. Recommend a QRadar rule that groups by ServerPrincipal/DatabaseName over a rolling window and fires when an AuditDisable indicator is followed within 6 hours by a FinancialWrite indicator for the same principal/database, plus a lower-severity standalone rule for FinancialWrite bursts from application names matching known interactive client tools.

Data Sources

SQL Server Audit / Azure SQL Auditing (via QRadar DSM or Universal DSM)

Required Tables

events

False Positives & Tuning

  • Approved DBA maintenance or data-correction work performed during a documented change window
  • Scheduled overnight batch reconciliation jobs from an ETL/reporting service account not yet allowlisted
  • Legitimate schema-migration work that disables change tracking or audit specifications temporarily

Other platforms for THREAT-Impact-FinancialLedgerTampering


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Disable SQL Server Audit Then Update Ledger Table

    Expected signal: SQL Server Audit / Azure SQL Auditing records: an AUDIT_CHANGE_GROUP event for test_ledger_audit_spec followed within minutes by an UPDATE action_name event against object_name dbo.general_ledger, both attributed to the same server_principal_name with application_name 'sqlcmd'.

  2. Test 2Off-Hours Bulk Update of Invoice Table via Interactive Client

    Expected signal: SQL Server Audit / Azure SQL Auditing records: 10 UPDATE action_name events against object_name dbo.invoices within a single 15-minute window, application_name 'Azure Data Studio', succeeded = true.

  3. Test 3Direct Deletion of Journal Entry Rows via psql

    Expected signal: Database audit log (pgaudit or equivalent forwarded into the SQLSecurityAuditEvents-equivalent schema): DELETE action_name events against object_name journal_entries, application_name 'psql', server_principal_name dbadmin, succeeded = true.

Unlock playbooks & atomic tests with Pro

Get the full detection package for THREAT-Impact-FinancialLedgerTampering — response playbook and atomic red team tests, plus investigation guidance and hunting queries.

df00tech Pro — £29/user/month

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections

Tactic Hub

Detection Variants (1)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.