Category: Security

Emad Al-Mousa finds a way around:

Adversaries continuously exploit every available vector to exfiltrate sensitive data while evading detection. This risk is magnified because critical threats originate from both external cybercriminals and trusted insiders.

To counter this, robust database auditing acts as a foundational line of defense, enforcing tailored policies that align with corporate security and compliance mandates. By streaming these granular audit logs directly to a SIEM solution, Security Operations Center (SOC) analysts gain real-time visibility to spot anomalous queries and unauthorized modifications. Furthermore, these logs serve as an immutable evidentiary trail for post-incident forensics. Ensuring that the database security and logging engine functions reliably is therefore non-negotiable for enterprise risk mitigation, rapid incident response, and regulatory compliance.

The quick idea is that you can view database histogram data without tripping audit logs, and those histograms might contain some amount of the sensitive data that you don’t want people to see.

Fabiano Amorim offers some advice:

The SQL Server attack pattern is consistent: attackers do not always need a spectacular vulnerability. They often succeed by chaining normal features that were granted too broadly, trusted too much, or monitored too narrowly. 

In this article, I’ll focus on operational blind spots in SQL Server. These are the features DBAs use every day to keep SQL Server healthy: linked servers, traces, Dynamic Management Views, Extended Events, and session-management commands such as KILL.

These tools, while necessary, also create visibility, automation, and trust paths that attackers can abuse after compromising a low-privileged application account or a local database owner. 

Because of this, a SQL Server DBA should know the answer to the following questions at all times: where am I exposed, what should I monitor, and what should I change first? In this article, you’ll learn the answers to all three.

Click through for the advice.

Marlon Ribunal builds a checklist:

Here’s a follow up for our US Department of Defense STIG document. In my previous post, SQL Server Security Hardening Guide Using the DoD STIG Checklist, I walked through how I used the DoD STIG checklist as a starting point for reviewing and hardening a SQL Server environment.

After going through the checklist, I started thinking about what I would actually want to use the next time I perform a security review.

The DoD STIG for SQL Server is a great, solid starting point for establishing your security practices with SQL Server. In fact, it’s also a good template for your own STIG in your organization. So, you may want to create a custom checklist that makes sense from the perspective of your SQL Server environment.

The STIG is detailed, which is a good thing, but I found myself wanting something a little more practical for day-to-day DBA work. Something I could open, work through one item at a time, record what I found, and come back to later without having to navigate through the entire STIG document every time.

Click through to see what Marlon came up with.

Andreas Wolter shares some thoughts:

CISA recently published guidance on using cyber decoys, tripwires, breadcrumbs, and honeytokens to detect attackers who are already operating inside an environment: Using Cyber Decoys to Strengthen Detection and Response

Looking at this through my SQL Server lens, I think it is worth considering how these concepts can be applied to database systems.

Before building any kind of database honeypot, you need to ask yourself:

Click through for that list of questions, as well as additional thoughts from Andreas.

Fabiano Amorim explains a vulnerability:

SQL injection inside Microsoft-signed system stored procedures is not supposed to happen. Yet, as I’ve been documenting in this series, it happens more often than you may assume.

This article walks through another one I found and reported to the Microsoft Security Response Center (MSRC). It’s a textbook SQL injection sitting inside sys.sp_MSdeletefoldercontents, a system stored procedure used by SQL Server replication.

What makes it interesting is not the injection technique itself (there is no clever Unicode trick this time), but what it enables: a working execution path for xp_cmdshell on a server where xp_cmdshell is explicitly disabled by configuration.

Admittedly, I kind of shrug my shoulders at this one as well. You already need to be sysadmin, and sysadmins can enable xp_cmdshell whenever. I understand that the point of Fabiano’s post is that the procedure call ignores xp_cmdshell’s status, so there’s something to it. But I have trouble thinking that the SQL Server team made the wrong call in deciding it’s a low-risk vulnerability.