THREAT-Impact-ProductionDatabaseRecordTampering

Stored Data Manipulation — Unauthorized Bulk Modification of Production Database Records

Impact Last updated:

Unlike destruction or encryption, stored data manipulation (T1565.001) is a stealthy Impact objective: the adversary alters records in place — falsifying financial transactions, backdating timestamps, adjusting inventory or pricing data, or planting false log entries — specifically so the tampering is not immediately obvious and can influence downstream business decisions, financial reporting, or an investigation. Because the goal is integrity compromise rather than availability loss, the data remains accessible and the application keeps functioning normally, which means traditional outage-based monitoring never fires. The most reliable detection surface is the database's own audit log: a spike in UPDATE/DELETE statement volume from a single principal against production tables, especially when that principal is a service account not normally used for ad hoc interactive queries, or when the activity occurs outside any tracked change-management window. A second useful signal is direct execution of interactive query tools (ssms.exe, azuredatastudio.exe, mysql.exe, psql.exe) by a service account that should only ever connect programmatically — a strong indicator that stolen service-account credentials are being used for manual, off-process data tampering rather than application logic performing routine writes.

What is THREAT-Impact-ProductionDatabaseRecordTampering Stored Data Manipulation — Unauthorized Bulk Modification of Production Database Records?

Stored Data Manipulation — Unauthorized Bulk Modification of Production Database Records (THREAT-Impact-ProductionDatabaseRecordTampering) maps to the Impact tactic — the adversary is trying to manipulate, interrupt, or destroy your systems and data in MITRE ATT&CK.

This page provides production-ready detection logic for Stored Data Manipulation — Unauthorized Bulk Modification of Production Database Records, covering the data sources and telemetry it touches: Azure SQL Database Auditing (AzureDiagnostics, category SQLSecurityAuditEvents), Microsoft Defender for Endpoint (DeviceProcessEvents), On-prem SQL Server Audit / Extended Events (equivalent fields for non-Azure deployments). The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Impact
Microsoft Sentinel / Defender
kusto
// THREAT: Stored data manipulation - anomalous bulk UPDATE/DELETE volume + service-account interactive tooling (T1565.001)
// Requires Azure SQL Database Auditing ingested into AzureDiagnostics (category SQLSecurityAuditEvents)
let LookbackWindow = 1h;
let BulkWriteThreshold = 100; // UPDATE/DELETE statements from one principal in the window
let KnownServiceAccounts = dynamic(["svc_appserver", "svc_etl", "svc_reporting"]); // populate with legitimate application/ETL service principals
// Signal 1: bulk UPDATE/DELETE volume spike from a single principal against production tables
let BulkWriteSpike = AzureDiagnostics
| where Category == "SQLSecurityAuditEvents"
| where TimeGenerated > ago(LookbackWindow)
| where action_name_s in ("UPDATE", "DELETE", "BATCH UPDATE", "BATCH DELETE")
| summarize WriteCount=count(), TablesTouched=make_set(object_name_s, 20) by server_principal_name_s, database_name_s, bin(TimeGenerated, 15m)
| where WriteCount >= BulkWriteThreshold
| extend Indicator = "BulkUpdateDeleteVolumeSpike"
| extend RiskScore = iff(server_principal_name_s !in~ (KnownServiceAccounts), 90, 70)
| project TimeGenerated, server_principal_name_s, database_name_s, WriteCount, TablesTouched, Indicator, RiskScore;
// Signal 2: service account launching an interactive DB query tool (indicates manual, off-process access)
let ServiceAccountInteractiveTool = DeviceProcessEvents
| where Timestamp > ago(LookbackWindow)
| where FileName in~ ("ssms.exe", "azuredatastudio.exe", "mysql.exe", "psql.exe", "dbeaver.exe")
| where AccountName in~ (KnownServiceAccounts)
| extend Indicator = "ServiceAccountLaunchedInteractiveQueryTool"
| extend RiskScore = 85
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, Indicator, RiskScore;
union BulkWriteSpike, ServiceAccountInteractiveTool
| sort by RiskScore desc, TimeGenerated desc

Two-signal detection for stored data manipulation. Signal 1 aggregates Azure SQL Database audit events (SQLSecurityAuditEvents) by principal and database in 15-minute bins, flagging any principal issuing 100+ UPDATE/DELETE/BATCH statements — a volume anomaly inconsistent with normal application write patterns — with elevated risk when the principal is not on the known-service-account allowlist. Signal 2 flags a known service account launching an interactive database query GUI/CLI tool, which application service accounts have no legitimate reason to do, indicating the credential is being used manually rather than by its owning application.

high severity medium confidence

Data Sources

Azure SQL Database Auditing (AzureDiagnostics, category SQLSecurityAuditEvents) Microsoft Defender for Endpoint (DeviceProcessEvents) On-prem SQL Server Audit / Extended Events (equivalent fields for non-Azure deployments)

Required Tables

AzureDiagnostics DeviceProcessEvents

False Positives

  • Legitimate bulk data operations: month-end batch jobs, data migrations, ETL reprocessing, or scheduled cleanup jobs — exclude known batch-job service principals and their documented execution windows
  • Database administrators using SSMS/Azure Data Studio for legitimate maintenance under their own named account rather than a service account (this detection specifically targets service-account use of interactive tools, not DBA activity under personal accounts)
  • Application deployment/migration tooling that legitimately runs large schema or data updates during a release window
  • Reporting or analytics service accounts with unusually high but legitimate read-heavy query volume (this detection targets write volume, not reads, to minimize this overlap)

Sigma rule & cross-platform mapping

The detection logic for Stored Data Manipulation — Unauthorized Bulk Modification of Production Database Records (THREAT-Impact-ProductionDatabaseRecordTampering) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 2 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 1Simulate Bulk UPDATE Volume Spike

    Expected signal: Azure SQL/SQL Server audit log shows 120 UPDATE statements from the svc_test principal against TestTable within a 15-minute window.

  2. Test 2Simulate Service Account Launching Interactive Query Tool

    Expected signal: DeviceProcessEvents shows ssms.exe launched with AccountName=svc_appserver.


Response Playbook

Triage

  1. Identify exactly which tables and rows were touched by the flagged principal, and cross-reference against any open change-management ticket or scheduled batch job for that time window.
  2. For the bulk-write signal: determine whether the principal is a genuine application service account or has been recently reported as compromised (check for related credential-theft or phishing alerts on the same account).
  3. For the interactive-tool signal: confirm whether the service account credential is stored in a way that could plausibly have been extracted (config file, CI/CD secret, password manager) and check for any recent access to that credential store.
  4. Compare the modified records against the most recent known-good backup or transaction log to identify the specific values that were changed (before/after diff).
  5. Assess business impact: does the affected table hold financial, inventory, pricing, or audit-log data where tampering could materially affect reporting, fraud detection, or a concurrent investigation?

Containment

  1. Suspend or rotate credentials for the implicated service account immediately, and revoke any active sessions/tokens.
  2. If tampering is confirmed, restore the affected rows/tables from the most recent known-good backup or point-in-time restore rather than attempting manual row-by-row correction.
  3. Temporarily restrict the account's database permissions to read-only or the minimum required scope while investigation continues.
  4. If an interactive tool was used from an unexpected host, isolate that host and review it for other signs of compromise (credential theft, malware, unauthorized remote access).
  5. Notify finance/compliance stakeholders early if the affected data feeds financial reporting, billing, or regulatory audit trails — tampering here can have disclosure obligations.

Evidence Collection

  1. Full database audit trail for the implicated principal covering the affected time window: every statement, target table, and row count
  2. Before/after values for the modified records, reconstructed from transaction logs or point-in-time backups
  3. Authentication logs for the service account: source IP, host, and method of connection (application connection string vs. interactive tool)
  4. Endpoint process history for any host from which an interactive query tool was launched using the service account
  5. Change-management/ticketing system records for the affected time window to confirm or rule out an authorized batch operation

Escalation Criteria

  • ! Confirmed unauthorized modification of financial, billing, or regulatory audit-trail data
  • ! The service account credential appears to have been used from a host or location inconsistent with its normal application deployment topology
  • ! Modified records appear to correspond with an ongoing fraud, insider-threat, or law-enforcement investigation (tampering with evidence)
  • ! Evidence that the same credential was also used to access other systems, indicating broader compromise beyond the single database

Investigation Guide

Forensic Artifacts

  • > SQL Server Audit / Azure SQL Auditing / MySQL general or audit log entries for the affected time window
  • > Database transaction log (for point-in-time analysis of exact before/after row values)
  • > Endpoint process creation logs (Sysmon Event ID 1) showing the service account launching an interactive query tool
  • > Application connection logs correlating expected vs. observed connection sources for the service account
  • > Change-management ticket history for the affected database/table

Tuning Guidance

Build the KnownServiceAccounts allowlist from your actual application connection-string inventory, and separately track each account's normal write-volume baseline — a reporting service account with legitimate high write volume needs a different threshold than a low-volume microservice account. Exclude documented batch-job/ETL windows by time rather than disabling the detection for the whole account, so an anomalous write burst outside the scheduled window still alerts. The interactive-tool signal has very few legitimate false positives once the service-account list is accurate; treat any hit as high-priority.


Hunting Queries

30-day hunt for daily UPDATE/DELETE volume by principal to establish a per-account baseline, making it easier to right-size the BulkWriteThreshold and identify accounts whose write volume has crept upward gradually rather than spiking abruptly.

Hunting — KQL
kql
AzureDiagnostics
| where Category == "SQLSecurityAuditEvents"
| where TimeGenerated > ago(30d)
| where action_name_s in ("UPDATE", "DELETE")
| summarize WriteCount=count() by server_principal_name_s, database_name_s, bin(TimeGenerated, 1d)
| where WriteCount > 500
| sort by WriteCount desc
Hunting — SPL
spl
index=azure sourcetype="azure:diagnostics" Category="SQLSecurityAuditEvents" earliest=-30d action_name IN ("UPDATE","DELETE")
| bucket _time span=1d
| stats count AS WriteCount by server_principal_name, database_name, _time
| where WriteCount > 500
| sort - WriteCount

Atomic Red Team Tests

Test 1 Simulate Bulk UPDATE Volume Spike
windows

Issues a large number of UPDATE statements against a disposable test table using a designated test service account, simulating the bulk-write volume anomaly. Run only against a test/staging database, never production.

Command

powershell
sqlcmd -S test-sql-server -d TestDB -U svc_test -Q "DECLARE @i INT = 0; WHILE @i < 120 BEGIN UPDATE dbo.TestTable SET Value = Value + 1 WHERE Id = @i; SET @i = @i + 1; END"

Cleanup

powershell
sqlcmd -S test-sql-server -d TestDB -U svc_test -Q "UPDATE dbo.TestTable SET Value = 0 WHERE Id < 120"

Expected Telemetry

Azure SQL/SQL Server audit log shows 120 UPDATE statements from the svc_test principal against TestTable within a 15-minute window.

Expected Detection

Alert fires on BulkUpdateDeleteVolumeSpike indicator; RiskScore depends on whether svc_test is on the KnownServiceAccounts allowlist.

Test 2 Simulate Service Account Launching Interactive Query Tool
windows

Launches SQL Server Management Studio under a service account's credentials rather than an application context, simulating manual off-process database access using a stolen or misused service credential.

Command

powershell
runas /user:svc_appserver "C:\Program Files (x86)\Microsoft SQL Server Management Studio 19\Common7\IDE\ssms.exe"

Cleanup

powershell
taskkill /IM ssms.exe /F

Expected Telemetry

DeviceProcessEvents shows ssms.exe launched with AccountName=svc_appserver.

Expected Detection

Alert fires on ServiceAccountLaunchedInteractiveQueryTool indicator with RiskScore=85.

Related Detections

Tactic Hub

Detection Variants (1)

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