Bug in Auditing allows for undetected Data Exfiltration by low privileged user

Last week, I was contacted by an IT Leader from Saudi-Arabia who previously found several CVE’s in Oracle and Microsoft SQL Server. He wanted my opinion on a newly discovered security issue in SQL Server Auditing.

Interestingly, his findings directly overlap with a topic I wrote about just last month: Using Data Classification to Audit Data Access.

Emad Al-Mousa identified two vulnerabilities in the SENSITIVE_BATCH_COMPLETED Audit Action Group. Microsoft Security Response Center (MSRC) acknowledged the issue but classified it as low priority – meaning it may not be addressed until a major release, if at all.

That assessment really piqued my curiosity – I wanted to test it firsthand and see what the real-world consequences might be.
Using my test setup with a table containing credit card information labeled as Highly Confidential and other Financial data using SQL Server’s Data Classification technology, I was able to reproduce the bug easily.

And yes—it’s a genuine security gap.

Any user with basic SELECT access to an audited table can bypass the auditing mechanism with trivial ease. Honestly, it’s surprising this slipped past automated testing, which should catch such cases by default.

The repro is as simple as this:

• Create an Audit Specification at the database or server level using SENSITIVE_BATCH_COMPLETED_GROUP (as I previously described in How to Use Data Classification to Audit specific Data Access in Microsoft SQL Server ).
• With nothing more than db_datareader or SELECT permissions, run:

Neither the SELECT INTO operation nor queries against the new table generate audit entries.

This means anyone with table access could exfiltrate sensitive data without detection. Even worse, the documentation explicitly claims this command is covered by the Audit Action Group.

Screenshot from: Data Discovery & Classification

The same loophole applies to the second vulnerability Emad discovered, involving DBCC CLONEDATABASE.

What does this mean for you?

Until Microsoft revises MSRC’s assessment and fixes SENSITIVE_BATCH_COMPLETED_GROUP, you cannot rely on it for auditing sensitive data access.

In the meantime:

• Audit ALL SELECT operations (this covers SELECT INTO).

• Enable auditing for DBCC_GROUP (which I generally recommend as best practice: Recommendation for Security Auditing for databases – with example for Microsoft SQL Server).

If you want to see this issue prioritized, I encourage you to comment on and re-share this post – or better yet, add your voice on LinkedIn.

Thank you for helping spread the word.

I have informed both the Microsoft SQL Server Auditing and Data Classification teams about this publication beforehand, and I have been told that they are going to fix it.

A big thank-you to Emad Al-Mousa for identifying and responsibly disclosing the issue. You can read his full write-up here: SQL Server Security Auditing Vulnerability For SENSITIVE BATCH COMPLETED Policy
And thank you to my ex-colleague Rohit Nayak for helping review this post.

Andreas