Press "Enter" to skip to content

Category: Security

Microsoft Fabric Eventstream Network Security Features

Alex Lin looks at network security features:

Eventstream in Fabric Real-Time Intelligence stream data from both inside and outside the Fabric platform. When your external sources sit behind firewalls or in private networks, choosing the right network security feature is essential. This post breaks down the available options in Eventstream and helps you determine which one fits your scenario.

Click through for more information.

Leave a Comment

New SQL Server CVEs

Rebecca Lewis takes a look at a few more vulnerabilities Microsoft has patched in SQL Server:

This week’s Patch Tuesday landed three new SQL Server CVEs. Two are elevation-of-privilege bugs — familiar territory, we had three of those last month. The third one is different. CVE-2026-33120 is a remote code execution flaw in SQL Server 2022. CVSS 8.8. An authenticated, low-privileged login on the network can execute arbitrary code on your SQL Server.

Go. Patch. Now.

Click through for more information and be sure to get these patched.

Leave a Comment

Cracking SQL Server 2025 SQL Auth Passwords with hashcat

Vlad Drumea has a great post:

Last year I wrote about SQL Server 2025’s new PBKDF2 hashing algorithm: what that means from a security perspective, as well as how it impacts online cracking.
And even how to enable it in SQL Server 2022.

Vlad created a module that cracks SQL Server 2025 passwords offline (versus actually connecting to the SQL Server instance itself and extrapolates it to online cracking (connecting to the SQL Server instance and trying different passwords). Vlad has some really good news on the whole and this post serves to explain why Microsoft introduced PBKDF2 as part of the hashing algorithm for SQL Server 2025.

Leave a Comment

Preventing SQL Injection in Stored Procedures

Vlad Drumea fixes a procedure:

In the past few years, I’ve seen quite a few stored procedures that rely on dynamic T-SQL without properly guarding for SQL injection.

Some cases were reporting stored procedures, while others were maintenance type stored procedures (e.g. stats updates) that could be kicked off from the app, or even stored procedures that handled app upgrades/patching.

In all these cases, certain portions of the dynamic T-SQL relied on input provided by users via input parameters.

Read on for an example. The solution is still the classic combination of QUOTENAME() and sp_execute_sql whenever you have user input.

Leave a Comment

Syncing Logins across Failover Groups for Managed Instances

Andy Brownsword gets replicating:

Failover Groups for Managed Instances are a great option to replicate data, but they don’t replicate key instance elements – one of which is logins that live in the master database. If left unchecked, failovers leave systems unable to connect and panic ensues.

To alleviate this we’ll look at a script to synchronise logins and permissions across replicas.

Click through for a link to the script and an explanation of what’s going on with it.

Leave a Comment

Cross-Database Ownership Chaining and Why to Avoid It

Fabiano Amorim provides a public service announcement:

A dangerous privilege-escalation path exists in SQL Server when cross-database ownership chaining, system database defaults, and overly permissive permissions are combined. Under these conditions, a low-privilege authenticated user can escalate to sysadmin, gaining full control of the instance. This article walks through how an attacker can abuse these mechanics.

Click through for a detailed explanation of the problem. Then, check out module signing as an alternative that is considerably more secure.

Leave a Comment

Comparing Schemas between PostgreSQL and Oracle

Laurenz Albe makes a comparison:

Recently, somebody asked me for a reference to a blog or other resource that describes how schemas work differently in Oracle. I didn’t have such a reference, so I’m writing this article. But rather than just describing Oracle schemas to a reader who knows PostgreSQL, I’ll try to present the topic in a way that helps Oracle users understand schemas in PostgreSQL as well. Since I already wrote about the difference between database transactions in Oracle and PostgreSQL, perhaps this can turn into a series!

Click through for the comparison. As far as SQL Server, here’s my off-the-cuff take:

  • Users and schemas — SQL Server follows the same model PostgreSQL does.
  • Schemas as namespaces — SQL Server follows roughly the same model Oracle does.
  • Schemas and object ownership — Different from the two, based on my reading. Objects are owned by the security principal that owns the schema. This is closer to the Oracle model but isn’t quite the same.
  • Schemas and privileges –Because of how object ownership works, there’s more flexibility to the SQL Server model, but also more complexity. In practice, it’s closer to the way PostgreSQL works.
  • Default schema — Different from the two. With one-part naming, SQL Server will first try the user’s default schema. If the object is not there, it checks dbo. That check, by the way, takes a small amount of time but can add up if you’re talking hundreds of thousands of transactions per second. Just ensuring you have consistent two-part naming can be a marked performance improvement on extremely busy servers.
  • System schemas — The sys schema includes system tables and Dynamic Management Views, and INFORMATION_SCHEMA provides the types of information the ANSI SQL standard requires.
Leave a Comment

The Scope of ##MS_DatabaseManager##’s Exposure

Andreas Wolter expands upon a prior post:

In my previous post (SQL Server Privilege Escalation via DatabaseManager-role: Newly discovered Attack Paths Explained), I showed how a privilege escalation can be achieved by modifying a stored procedure in msdb, based on research shared by Emad Al-Mousa.

When I looked into this more closely, it became clear pretty quickly:
It is not just about a few specific procedures.

Mind you, Andreas is not some kind of shrinking violet, and he was involved in the creation of this role in the first place. There are approximately zero people outside of Microsoft (and the number inside I could probably count on one hand) I would trust more to understand the nature and scope of this issue. This is definitely worth reading.

Leave a Comment

Privilege Escalation via the DatabaseManager Role

Andreas Wolter looks into a security issue:

First of all: full credit to Emad Al-Mousa for identifying and publishing two privilege escalation paths.

His findings show how members of the ##MS_DatabaseManager## server-role in SQL Server can escalate to sysadmin by chaining existing functionality in unexpected ways.

He has published his findings responsibly after more than 8 months’ notice to MSRC: Microsoft SQL Server Privilege Elevation Through ##MS_DatabaseManager## Role [CVE-2025-24999]

Read on to learn more about the issue.

Microsoft fixed a separate privilege escalation issue but has updated the documentation for ##MS_DatabaseManager## to indicate that “Members of this role can potentially elevate their privileges under certain conditions. Apply the principle of least privilege when assigning this role and monitor all activity performed by its members.”

Leave a Comment

New Permissions in SQL Server 2025

Andreas Wolter digs into some new permissions:

This article provides a brief overview of the new permissions introduced with SQL Server 2025 and the few adjustments to existing ones.

Overall, the changes are subtle – which is not surprising. The past couple of years have focused heavily on SQL Database in Fabric, Entra ID integration, and incremental improvements rather than major changes to the core permission model.

All newly introduced permissions are tied to new functionality. The underlying permission model itself remains unchanged since its last significant evolution in SQL Server 2022.

Even so, click through to see what’s new and what granting EXECUTE across the board can net you in SQL Server 2025.

Comments closed