In this blog post I demo cracking SQL Server 2025 login passwords offline with hashcat, including the current stable release (7.1.2) which doesn’t officially support MSSQL 2025.
Note: If you’re here for tips on cracking pre-2025 SQL Server login passwords then check out this post.
Table of contents
Disclaimer
This post is purely for educational and security purposes.
Use hashcat and the information in this post responsibly and only for environments where you have permission to do so.
Intro
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.
Long story short: cracking SQL Server 2025 login hashes online isn’t feasible due to the new hashing algorithm.
I’ve made a detailed duration comparison between the 2025 hashes and the pre-2025 ones, but the gist of it is:
SQL Server 2025’s PBKDF2 hashing algorithm turns 45 seconds worth of password brute-forcing into an estimated 154008 seconds.
To better understand the new hashing algorithm I’ve also made a pure T-SQL implementation of it.
So what options are there for folks that do security audits and/or pen-tests when it comes to SQL Server 2025?
What’s offline cracking?
Password cracking is the process of obtaining the clear text version of a password from the scrambled (hashed) version of said password, usually by means of brute-forcing which implies trying multiple password candidates until you identify the one that, when the same hashing algorithm that generated the original hash is applied, results in an identical hash to the one you were trying to identify the password for.
Offline cracking consists of getting one or more username and password hash pairs and attempting to carry out the cracking process outside of the system where those user and password hash pairs reside, in this case the system being a SQL Server instance.
This tends to be faster because of specialized tools such as hashcat that can take full advantage of CPU and/or GPUs to achieve higher password cracking speeds, especially when you’re working with lots of login passwords.
The gotcha
The current release of hashcat (7.1.2) only supports the previous versions of SQL Server hashing algorithms, and the same goes for John The Ripper (which kinda feels like abandonware at this point).
At this point you might feel like this post is some late April Fools prank, but I promise, it’s not.
Introducing hashcat module 1732
For folks who might not be familiar with it:
- hashcat is a password auditing/recovery software purposefully built for offline password cracking
- a module in hashcat is a self-contained plugin that tells hashcat how to recognize, parse, and crack a specific type of cryptographic hash.
Armed with patience, minimal C knowledge from back when I was studying for my OSCP exam, a working and well-documented T-SQL implementation of SQL Server 2025’s new hashing algorithm, and GitHub Copilot in VS Code, I’ve managed in the past 4 days to put together hashcat module 1732 designed to crack SQL Server 2025’s login passwords.
Disclaimer: I dunk a lot on LLMs and the iffy results I’ve had with them on various occasions.
But, this time, GHCP managed to pull through surprisingly well, albeit with a decent amount of iterating, correcting, and pushing in the right direction.
My PR to add the new module in a future hashcat release is still pending review, but that shouldn’t stop folks from using it.
As a result, you can find both the source code and the compiled binaries for Windows and Linux in my blog’s GitHub repo.
Hardware
Before I continue with all the interesting stuff, I’m just making a note of the hardware used for the testing done in this post.
I’m using SQL Server 2025 container.
SQL Server version and edition info:
Microsoft SQL Server 2025 (RTM-CU3) (KB5077896) – 17.0.4025.3 (X64)
Feb 25 2026 20:54:27
Copyright (C) 2025 Microsoft Corporation
Enterprise Developer Edition (64-bit) on Linux (Ubuntu 24.04.4 LTS)
Container host specs:
- CPU – AMD Ryzen Embedded V1500B Quad-core CPU 4 cores/8 threads
- RAM – 32GB
Hardware used for hashcat:
- CPU – AMD Ryzen 9 5950X 16 cores/32 threads
- RAM – 128GB 3200MT/s DDR4
- GPU – NVIDIA RTX 4070 12GB GDDR6X
- OS – Windows 11 Pro 25H2
Test cracking SQL Server 2025 passwords offline
Preparing hashcat
I download the latest stable release of hashcat (7.1.2 at the time of writing) from here.
Then I extract it as hashcat-7.1.2.
Note: for this example, my hashcat-7.1.2 directory is in D:\InfoSec\ , adjust paths to match your environment.
Then I download the required files from my repo and place them in their specific hashcat directories as follows:
| File | target hashcat-7.1.2 directory |
|---|---|
| m01732-pure.cl | D:\InfoSec\hashcat-7.1.2\OpenCL |
| module_01732.dll (Windows specific) | D:\InfoSec\hashcat-7.1.2\modules |
| module_01732.so (Linux specific, so it’s not required on Windows) | D:\InfoSec\hashcat-7.1.2\modules |
Note, if you want to compile hashcat yourself from source with this module, I’ve added instructions in the README.md file.
Establishing a baseline
While I’m at it, I also want to compare password brute-forcing speeds between online, inside SQL Server 2025, and offline via hashcat using the new module.
I create a login whose password won’t be part of the generated password candidates.
| 1 2 3 4 5 | USE [master] GO CREATE LOGIN [test_login] WITH PASSWORD = N'$up3R-S3Cur3P@22'; GO |
And then I use PWDCOMPARE with time statistics to get a baseline for hashing and comparing passwords inside SQL Server.
| 1 2 3 4 5 6 7 8 9 10 11 12 | SET STATISTICS TIME ON; SELECT [name], PWDCOMPARE(N'$up3R-S3Cur3P@22', [password_hash]) AS [password_match] FROM sys.sql_logins WHERE [name] = N'test_login'; SELECT [name], PWDCOMPARE(N' ', [password_hash]) AS [password_match] FROM sys.sql_logins WHERE [name] = N'test_login'; |
The result looks like this:
And the time statistics output looks like this:
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
(1 row affected)
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 156 ms.
(1 row affected)
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 152 ms.
Ignore the “parse and compile time” since that’s just the time SQL Server takes to parse the T-SQL and compile a plan, not the actual duration of PWDCOMPARE.
So, an average duration of 154 milliseconds for hashing using SQL Server 2025’s PBKDF2 hashing algorithm.
From my tests, these times are consistently above 110ms regardless of CPU.
For example, on an AMD Ryzen 9 5950X I get an average of 120ms.
And, since the process is single-threaded, the number of cores involved doesn’t matter, the differentiator here is single-core speed.
Setting up the test environment
I create a database and 4 more logins.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | CREATE DATABASE [AdventureWorks2022] GO CREATE LOGIN [sa1] WITH PASSWORD = N'Welcome123??'; GO /*Login with a database name + special character as password*/ CREATE LOGIN [AppAdmin] WITH PASSWORD = N'AdventureWorks2022$'; GO /*Login that uses a password derived from a provided base word*/ CREATE LOGIN [Dev1] WITH PASSWORD = N'(Contoso22)'; GO /*The kind of password that the ID Admin team at my former job used to provide*/ CREATE LOGIN [Dev2] WITH PASSWORD = N'SUMMER20!', CHECK_POLICY = OFF; GO |
Unlike my test setup from last year’s post, I’m not adding these logins to roles because they’re not relevant for this test.
Generating password candidates with sp_GeneratePasswordCandidates
I’ve made a stored procedure, sp_GeneratePasswordCandidates, specifically for this, derived from my QuickSQLPassAudit.sql script.
The stored procedure generates password candidates based on:
- the comma-separated terms provided for the
@BaseWordsListparameter - instance information (database names, instance name, login names) if
@UseInstInfois set to 1 - 17 common words (season names, words and keyboard walks) – hard-coded in the script
| 1 2 | EXEC dbo.sp_GeneratePasswordCandidates @BaseWordsList = N'contoso', @UseInstInfo = 1; |
Generating password candidates in the #WordList table Generated 171121 password candidates.
I paste these into a new text file named 171121_wordlist.txt.
If you want to run through the same steps to “check my homework”, you can find the test word-list here.
Extracting login names and password hashes from SQL Server 2025
I’m reusing the same method here that I’ve used for my previous post about offline SQL Server password cracking.
| 1 2 3 4 | SELECT @@SERVERNAME + N'_' + [name] + N':' + CONVERT(NVARCHAR(256), password_hash, 1) FROM sys.sql_logins WHERE [name] NOT LIKE N'##%'; |
The resulting rows are in the format [InstanceName]_[LoginName]:[Hash], this makes it hashcat-friendly which expects a [UserName]:[Hash] format.
I paste the result in a file named sqlserver2025_hashes.txt.
Running hashcat with module 1732
With the hashes and password candidates waiting in their respective files, I can proceed with running hashcat.
| 1 | .\hashcat.exe --username -a 0 -m 1732 D:\InfoSec\sqlserver2025_hashes.txt D:\InfoSec\171121_wordlist.txt |
Parameters:
--usernamespecifies that the provided list of hashes contains usernames as well.-a 0tells hashcat that this is a dictionary attack.-m 1732stands for the SQL Server 2025 hash type.D:\InfoSec\sqlserver2025_hashes.txtis the txt file that I’ve created earlier containing the usernames and hashes.D:\InfoSec\171121_wordlist.txtis a file containing the password candidates.
The module is loaded ok, and hashcat is able to start.
Since the current word-list consists of 171121 password candidates, hashcat is able to run more efficiently.
Otherwise, you’d get a warning about decreased performance when using too few password candidates.
4 out of the 6 hashes submitted have been cracked at an average speed of 10813 hashes/second.
This is to be expected since sa and test_login have passwords that are outside the scope of what sp_GeneratePasswordCandidates can generate.
The total password cracking process took 86 seconds (based on Started and Stopped timestamps).
Displaying the identified passwords
To view the clear text passwords I just run the following command:
| 1 | .\hashcat.exe --username --show -a 0 -m 1732 D:\InfoSec\sqlserver2025_hashes.txt |
You can safely ignore that warning about --show and --username, since the results contain the login names as well, the --username option is required.
How does this stack up against online password cracking times?
Ok, at this point I have all the relevant numbers, I’m just putting them here in a more organized way:
- SQL Server 2025 hashing speed for a single password is 154 milliseconds.
- Hashcat’s average hashing speed is 10813 hashes/second, and was done in 86 seconds.
- We’re checking 171121 password candidates against the 6 login hashes.
I just have to do some math for the SQL Server side to get the total duration.
| 1 2 | SELECT (6 * 171121 * 154.)/ 3600000. AS [time_in_hours], (6 * 171121 * 154.)/ 1000. AS [time_in_seconds]; |
| Platform | Avg hashes/second | Total duration (seconds) |
|---|---|---|
| SQL Server 2025 | 6.5 | 158115.8 |
| hashcat | 10813 | 86 |
| SQL Server 2022* | 14460 | 71 |
So, doing the same amount of password brute-forcing work that takes hashcat 86 seconds would take SQL Server 158115 seconds, or a little under 44 hours.
*For comparison’s sake I’ve also added the timings here for the same password brute-forcing exercise done in a SQL Server 2022 container running on the same hardware as the 2025 one.
Hashcat performance SQL Server 2025 vs. 2012-2022
I ran hashcat in benchmark mode for both the hash type used in SQL Server 2012 through 2022:
| 1 | .\hashcat -m 1731 -b |
And the SQL Server 2025:
| 1 | .\hashcat -m 1732 -b |
The results are pretty noteworthy.
While hashcat is blazing fast at cracking SQL Server 2025 passwords when compared to SQL Server itself, its speed of 11783 hashes/s pales in comparison with the 2579.5 Megahashes/s* that it’s able to achieve for the previously used algorithm.
*that’s not a typo. On my environment, hashcat reaches a speed of 2579.5 million hashes per second when using the module for SQL Server 2012-2022 password cracking.
Conclusion
I know this post was a bit on the lengthy side, but bear with me here.
The adoption of the PBKDF2 hashing algorithm makes cracking SQL Server 2025 login passwords both online and through repeated connection attempts* pretty much impossible.
It also deals a significant performance blow to offline cracking via hashcat when compared to SQL Server 2012-2022.
*If you don’t have your logins set to lock up after a fixed number of failed authentication attempts, as well as alerting put in place for those events, you might want to sort that out sooner rather than later.
One thing hasn’t changed: folks still need to ensure they’re setting up SQL logins with strong passwords.
The addition of this module also means security auditors can properly assess their SQL Server 2025 deployments, identify logins with weak passwords and address them before they’re leveraged by potential attackers.