Database Audit Log Detection Guide: Turning Engine Audit Trails Into Reliable Alerts

Most database breaches are visible in the database's own audit trail, but in many organisations that trail is switched off, kept on the same server as the data, or never reaches the SOC. Attackers who steal a database or warehouse credential, abuse an application account through SQL injection, or misuse administrator rights all leave logins, permission changes and unusual queries behind. Detection engineers usually start from the log they have, so this guide is organised by log source: what SQL Server Audit, Oracle Unified Auditing, PostgreSQL and pgAudit, MySQL, MongoDB, Amazon RDS Database Activity Streams and Snowflake actually record, how those events map to ATT&CK, which detections are worth building, and how to keep the logs trustworthy when the administrators are in scope. It is for detection engineers, SOC analysts and database administrators. For the wider control set see the Database Security Guide.

Key takeaways

• Nothing is captured until you define it. SQL Server audits are created disabled, pgAudit logs nothing at its default, MySQL Enterprise Audit is an Enterprise Edition feature and Database Activity Streams capture only the policies you activate.
• Start with identity events, not query text. Logins, failed logins, role membership changes, new principals and audit configuration changes are low volume and catch most credential abuse.
• Superusers can blind local auditing. The pgAudit documentation states superusers cannot be reliably audited; ship logs off the host quickly and use platform features that DBAs cannot change, such as Activity Streams.
• Audit logs can leak secrets. Statement logging can record plaintext passwords and sensitive literals, so the audit store needs its own access control.
• Service accounts are the baseline that matters. Application and integration logins are predictable; a service account logging in from a new address or client tool is one of the strongest signals in this data.

What each engine records

Engine-specific hardening is covered in the Microsoft SQL Server Security Guide, Oracle Database Security Guide, PostgreSQL Security Guide, MySQL Security Guide and MongoDB Security Guide.

Mapping attacker behaviour to database events

ATT&CK v20 ties detections to data components. Database audit trails mostly supply DC0002 User Account Authentication, DC0014 User Account Creation, DC0010 User Account Modification and DC0038 Application Log Content.

A baseline audit configuration per engine

Begin with identity and configuration events everywhere, then add object-level auditing only for crown-jewel tables.

• SQL Server: one server audit with a server audit specification containing FAILED_LOGIN_GROUP, SUCCESSFUL_LOGIN_GROUP, SERVER_ROLE_MEMBER_CHANGE_GROUP, SERVER_PRINCIPAL_CHANGE_GROUP, LOGIN_CHANGE_PASSWORD_GROUP, AUDIT_CHANGE_GROUP and BACKUP_RESTORE_GROUP; database audit specifications with DATABASE_ROLE_MEMBER_CHANGE_GROUP, DATABASE_PERMISSION_CHANGE_GROUP, DATABASE_OBJECT_PERMISSION_CHANGE_GROUP and SCHEMA_OBJECT_ACCESS_GROUP scoped to sensitive schemas. Remember to set STATE = ON. Use BATCH_COMPLETED_GROUP sparingly: it records full batch text, and Microsoft's tables disagree on whether it needs SQL Server 2019 or 2022.
• Oracle: keep ORA_SECURECONFIG and ORA_LOGON_FAILURES enabled, add policies for privilege grants, user management and DDL on application schemas, and grant AUDIT_ADMIN only to a security role separate from DBAs. Give the SOC AUDIT_VIEWER.
• PostgreSQL: log_connections = 'receipt,authentication,authorization' (PostgreSQL 18 syntax; older releases take a boolean), log_disconnections = on, a log_line_prefix with user, database, application and client address, and log_destination including jsonlog or csvlog for parsing. Load pgAudit through shared_preload_libraries, run CREATE EXTENSION pgaudit, set pgaudit.log = 'role, ddl', and use pgaudit.role for object auditing of sensitive tables. Set pgaudit.log_catalog = off to cut noise from client tools.
• MySQL: on Enterprise Edition, install the audit_log plugin with filters for connection events and table access on sensitive schemas. On community builds, use a supported audit plugin from your distribution or vendor rather than the general query log, which records everything and is hard to protect.
• MongoDB: set an audit destination and filter on atype values such as authenticate, createUser and dropCollection; enable auditAuthorizationSuccess only for targeted collections because it adds load. Note the server terminates if it cannot write to the audit destination, so monitor disk space.
• Amazon RDS for Oracle and SQL Server: enable Database Activity Streams on the primary, then create and activate the engine audit policies; DAS captures nothing without them.
• Snowflake: pull LOGIN_HISTORY and query and access history into the SIEM on a schedule that accounts for view latency. See the Snowflake Security Guide.

Rollout order:

1. Inventory databases and classify them; pick the crown jewels.
2. Enable identity and configuration auditing on all production instances and confirm events arrive in the SIEM.
3. Measure volume and performance on a pilot instance for a week before enabling object-level auditing.
4. Add object-level read and write auditing for sensitive tables only.
5. Build detections, run them in report-only mode for two to four weeks, then promote to alerting.
6. Rollback: audit specifications and policies can be disabled individually, so remove the noisiest object policy first rather than turning auditing off.

Detection use cases worth building

• Service account anomaly: an application or integration login from a source address, host or client type not seen in the last 30 days. Service accounts have stable patterns, so this is high fidelity. See the Database Credential and Access Security Guide.
• Human login without MFA on a warehouse: Snowflake SECOND_AUTHENTICATION_FACTOR is null for a human user. Treat REPORTED_CLIENT_TYPE as a hint only, because it is self-reported.
• Failed then successful login: many failures for one login followed by a success from the same source.
• Privilege change outside change windows: any server role, sysadmin, DBA or superuser grant, and any new login, correlated with your change tickets.
• Audit tampering: any AUDIT_CHANGE_GROUP event, Oracle audit policy change, pgAudit setting change, or a source that stops sending for longer than its normal interval.
• Bulk access: row counts or result volumes well above the baseline for that account on sensitive tables, or warehouse unloads to new external locations.
• Destructive bursts: several DROP or TRUNCATE statements in a short window from one session. Pair this with cloud control plane logs, because deletion can bypass the database entirely: in the PocketOS database deletion an AI coding agent removed a production database and its backups through a single platform API call with an over-scoped token.

Correlate database events with identity provider and network logs: a database login is far more suspicious when the same account had an impossible-travel sign-in an hour earlier.

Tuning noise and volume

Database audit volume grows with workload, and the pgAudit documentation warns that logs can exhaust disk space and add latency to busy transactional systems. Plan for this rather than discovering it in production.

Small versus large organisations: a small team with a handful of databases should enable identity events everywhere and object auditing on one or two critical tables, then rely on managed services such as Activity Streams or warehouse views. A large estate needs a central audit standard per engine, deployed as code, with exceptions approved and recorded.

Keeping the audit trail trustworthy

• Separate duties: the people who administer the database should not administer its audit. Oracle's AUDIT_ADMIN role and RDS Activity Streams, where the documentation states DBAs cannot alter the audit policy or remove audit logs, support this.
• Ship off-host fast: pgAudit is best-effort and not transactional, and MongoDB may lose buffered events if the server stops. Forward continuously rather than in nightly batches.
• Protect sensitive content: PostgreSQL warns that logged statements can contain plaintext passwords; keep log_file_mode at 0600 and restrict SIEM indexes holding database statements.
• Retain long enough to scope: breach scoping often needs months of login history; align retention with your notification obligations. See the CIS Control 8 Audit Log Management Guide.
• Record enough context: user, client address, application name, database and object for every event, so an analyst can answer who, from where and what without going back to the server.

Measuring coverage

• Share of production databases sending identity and configuration audit events to the SIEM (target: 100 percent).
• Share of crown-jewel tables with object-level read auditing.
• Median delay from event to SIEM availability, per engine.
• Number of service accounts with a baselined behaviour profile.
• Silent-source alerts raised and closed within one working day.
• Detections for the techniques in the mapping table that have been tested with a safe simulation in the last 12 months.

Framework mapping

Common failure patterns

• Auditing created but never enabled. SQL Server audits and specifications are off until STATE = ON; teams pass a configuration review and capture nothing.
• Everything or nothing. Turning on full statement logging fills disks and is switched off within a week; start with identity events.
• Logs stay on the database host. An attacker with superuser rights, or a ransomware operator, removes the evidence along with the data.
• No baseline for service accounts. Shared application logins used by people and tools make anomaly detection impossible.
• Warehouse logs ignored. Cloud data platforms log well, but the views are never pulled into the SIEM.
• Secrets in the audit store. Statement text containing passwords ends up readable by everyone with SIEM access.

Lessons from incidents

In the Snowflake customer breaches of 2024, a threat group used infostealer credentials to log in to customer accounts that had no MFA and no network restrictions, then stole data from around 165 organisations. The behaviour was visible in exactly the fields this guide recommends watching: logins from unfamiliar addresses and commercial VPNs, new client tools, no second factor, and large data copy operations to temporary stages. The lesson is that warehouse login and query history should be in the SIEM with alerts on those conditions before an incident, not exported afterwards for scoping. For the response side see the Database Breach Response Playbook.

Practitioner checklist

• List every production database and warehouse with its audit mechanism and current state.
• Enable login, failed login, principal, role and audit-change events on all of them.
• Add object-level auditing for crown-jewel tables after a volume test.
• Forward audit events off-host continuously with user, client address, application and object fields.
• Separate audit administration from database administration.
• Baseline service account logins and alert on new sources and client types.
• Alert on any audit configuration change and on silent sources.
• Restrict access to audit stores that contain statement text.
• Pull cloud warehouse login and query history into the SIEM on a schedule.
• Test detections with safe simulations at least yearly.

Standards and references

• Microsoft Learn: SQL Server Audit Action Groups and Actions
• Oracle: Introduction to Auditing (Database Security Guide 19c)
• PostgreSQL: Error Reporting and Logging
• pgAudit: PostgreSQL Audit Extension
• MySQL: MySQL Enterprise Audit
• MongoDB: Auditing
• AWS: Overview of Database Activity Streams
• Snowflake: LOGIN_HISTORY view

Related NHI Mgmt Group resources: Database Security Guide · Database Breach Response Playbook · Database Credential and Access Security Guide · CIS Control 8 Audit Log Management Guide