Press "Enter" to skip to content

Category: Security

Tracking SQL Server Login Failures

Ed Pollack builds some infrastructure:

Failed logins are one of the clearest early-warning signs of trouble on a SQL Server – whether that’s a misconfigured connection string, an expired password, or an actual unauthorized access attempt. Yet, by default, SQL Server won’t proactively tell you when they happen; you have to go looking.

This guide walks through how to pull login failure data using sys.xp_readerrorlog, filter it by time and error type, parse it into readable columns, aggregate repeat offenders, and automatically email a summary report — turning a passive log file into an active security and troubleshooting tool.

Click through for the process and scripts.

Leave a Comment

False Enrichment from a SIEM

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

Full-Text Index Management Permissions

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.

Leave a Comment

The Downside to SQL Server’s Trigger Execution Model

Fabiano Amorim lays out an argument:

By default, SQL Server executes both DML (data manipulation language) and DDL (data definition language) triggers under the security context of the user whose statement causes the trigger to fire. The trigger author supplies the code, but the future caller supplies the privileges under which that code runs.

This is the default behavior of SQL Server triggers, and it creates a dangerous situation. One principal controls the trigger code, another supplies the execution privileges and, combined, the trigger can then potentially hijack the caller’s authority.

Additionally, a user who creates a trigger does not need permission to perform every operation contained in the trigger. They only need permission to create the trigger – and then an opportunity for a more privileged principal to fire it later.

Click through to see how things can go wrong and what alternatives would be possible for a new execution model.

Leave a Comment

Azure Arc-Enabled Privilege Escalations

Fabiano Amorim lets us know about a supposed non-issue:

Azure Arc-enabled SQL Server is designed to bring on-premises and multi-cloud SQL Server instances under centralized Azure management, but a newly documented privilege escalation technique shows how that same management workflow can be turned against the server it’s meant to protect.

By combining a database-level DDL trigger with the elevated identity the Azure Arc extension uses during onboarding and configuration, a login with nothing more than db_ddladmin permissions in a single database can escalate to full sysadmin control over the entire SQL Server instance. The result? Complete server compromise.

In this investigative guide, Fabiano Amorim explains how the vulnerability works, how to reproduce it in a lab environment, why Microsoft classified it as Low severity, why that classification is disputed, and what mitigations are available today.

I don’t think this is a “run around with your hair on fire” vulnerability, but I am somewhat disappointed in Microsoft’s response here.

Leave a Comment

Database Application Security and High Availability Checklist

Andreas Wolter has an update:

I have updated the SQL Server Database Application Security & High Availability Checklist and moved the current version to the Sarpedon Quality Lab website: View here

The checklist is written for two audiences:

Database application vendors who want their SQL Server-backed products to be easier to approve in enterprise environments.

DBAs, security administrators, and architects who need to evaluate whether a vendor application can be deployed securely.

Click through to see what’s new, and check out the link for the full checklist.

Leave a Comment

Building a SQL Server Estate Summary from Get-SqlSafe Reporting

Andreas Wolter digs into an environment and builds a report:

Have you ever needed to understand an unfamiliar SQL Server estate quickly? Perhaps you inherited an environment, started working with a new customer, or discovered that the existing server inventory is no longer trustworthy.

In the previous article, Running Get-SqlSafe at Scale Across a SQL Server Estate, I showed how to run Get-SqlSafe across a list of SQL Server instances.

Each report contains a System Overview section. I originally added this section to provide context for the security findings, but it also provides useful estate information such as the SQL Server version, build number, edition, and selected usage indicators.

Click through to see how.

Leave a Comment

Configuring OneLake Security for a Microsoft Fabric Lakehouse

Gilbert Quevauvilliers locks things down:

In this blog post, I will show you how to configure OneLake security for a Microsoft Fabric Lakehouse. We will remove the default broad-access role, grant the required Lakehouse access, configure object-, row-, and column-level security, and test the results. The goal is to create a secure-by-default setup in which users can access only the data they need.

Click through for the guide.

Comments closed

Assessing SQL Server Security across an Estate

Andreas Wolter scales things up:

Get-SqlSafe is a free SQL Server security assessment that checks for common configuration, access-control, authentication, auditing and generates a detailed HTML report.

It has been publicly available for a couple of months and has already received several valuable additions based on user feedback, including console-only mode, Amazon RDS for SQL Server support, and per-database reports.

It has been encouraging to see Get-SqlSafe being used in real environments, including some very large ones.

In this post, I will show how to run the assessment against dozens or even hundreds of SQL Server instances using only a small additional PowerShell wrapper.

Click through for that wrapper.

Comments closed

Building an Attack Profile for msdb

Fabiano Amorim takes us through a thought process:

SQL Server DBAs routinely rely on automation: SQL Server Agent jobs, maintenance plans, refresh processes, restore scripts, replication cleanup, CDC operations, cross-database modules, and temporary objects. These workflows are often trusted because they’re normal – and that’s precisely why they deserve more attention. 

The goal of this article is not to provide exploit recipes. Instead, it’s to help DBAs answer a practical question: how do I know whether my SQL Server instances are exposed to this kind of risk, what should I monitor, and what should I change when I find a problem? 

Click through for the process.

Comments closed