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 ProDetect Financial Ledger and Transaction Record Tampering via Direct Database Manipulation in CrowdStrike LogScale
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
LogScale Detection Query
#event_simpleName=/SQLAudit/
action_name=/^(UPDATE|DELETE)$/
object_name=/(?i)(ledger|invoice|transaction|payment|journal_entr|gl_entr|account_balance)/
succeeded="true"
| IsInteractiveClient := if(match(field=application_name, regex="(?i)(Management Studio|Azure Data Studio|DBeaver|psql|mysql|sqlcmd)"), then=1, else=0)
| groupBy([server_principal_name, database_name, application_name], function=[count(as=WriteCount), sum(IsInteractiveClient, as=InteractiveCount), collect(object_name, limit=20), collect(action_name, limit=20)])
| test(InteractiveCount > 0 and WriteCount >= 5)
| sort(WriteCount, order=desc)CrowdStrike LogScale query over ingested SQL Server / Azure SQL Auditing events, flagging identities that issue 5 or more UPDATE/DELETE statements against financial-sounding table objects from an interactive database client, grouped by principal, database, and application name. Pair with a companion query filtering on AUDIT_CHANGE_GROUP / SERVER_OBJECT_CHANGE_GROUP action names for the same principal/database to manually correlate audit-disablement precursors during triage.
Data Sources
Required Tables
False Positives & Tuning
- Approved DBA data-correction scripts run through interactive clients during a documented change window
- Overnight batch reconciliation jobs from an ETL/reporting identity not yet excluded
- Schema-migration maintenance that temporarily disables audit specifications
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.
- 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'.
- 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.
- 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.
References (6)
- https://attack.mitre.org/techniques/T1565/001/
- https://attack.mitre.org/techniques/T1565/
- https://attack.mitre.org/tactics/TA0040/
- https://learn.microsoft.com/en-us/azure/azure-sql/database/auditing-overview
- https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1565.001/T1565.001.md
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
Related Detections
Tactic Hub
Detection Variants (1)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.