Category: Security

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.

Leave a Comment

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.

Leave a Comment

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.

Leave a Comment

Andreas Wolter notes some security requirements:

Azure Arc for SQL Server comes with a so-called “least privilege mode.”

But certain Azure Arc components still execute SQL Server operations with sysadmin authority, which can expose that authority to database-scoped code.

Fabiano Amorim recently demonstrated how a database-scoped principal can take advantage of exactly this privileged execution context to escalate to sysadmin through a database-level DDL trigger: How Azure Arc allows a DB admin to become SQL Server sysadmin – the vulnerability explained

Fabiano covers the exploit itself in detail. What I want to put under the magnifying glass here is the “least privilege” mode itself – a topic I have written about extensively:

Click through for Andreas’s take on this.

Leave a Comment

Andreas Wolter takes a look at an alert:

This week, early morning, a customer alerted me that my account was possibly involved in an incident.

The alert came from Rapid7 InsightIDR:

Andreas has an example in which the SIEM decided that his user account was the relevant one, despite there being no logged in user. It’s an interesting story around how it’s critical to understand your sources and what they’re actually telling you.

Leave a Comment

Emad Al-Mousa tests some permissions:

I was exploring SQL Server Text Indexes, and while exploring it I stumbled upon the function sys.dm_fts_index_keywords.

According to the “current” version of the documentation (up to 1 September 2026): https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-objects/sys-dm-fts-index-keywords-transact-sql?view=sql-server-ver17

sysadmin role is required to run this function, I found out that this is not true !

Click through for the test. Granted, this does require CONTROL on the database, so not something that J. Rando db_datawriter can do.

Comments closed