mssql module fails on Windows auth with known correct credentials

[axzhandul]

Describe the bug
I am trying to use Hydra to brute-force MSSQL logins (disclaimer: authorized). Before running larger user and password lists, I am trying to verify accurate function of hydra against the SQL Server with a known username and password. Using the Hydra mssql module, I cannot get this to work correctly, although I know for a fact (both by connecting successfully and cracking successfully with other tools) these credentials work.

I believe the issue may be related to Windows authentication, which is the default for MSSQL and also the configuration setting of the server, meaning that my username requires a domain in addition to the password to successfully connect. I have tried all of the following forms of command to no avail (actual username, password, host, and port redacted).

hydra -l DOMAIN\\username -p password -s 7777 mssql://10.10.10.51:7777 -V
hydra -l "DOMAIN\\username" -p password -s 7777 mssql://10.10.10.51:7777 -V
hydra -l username@DOMAIN -p password -s 7777 mssql://10.10.10.51:7777 -V
hydra -l "username@DOMAIN" -p password -s 7777 mssql://10.10.10.51:7777 -V
hydra -l username -p password -s 7777 mssql://10.10.10.51:7777 -V

All of these commands result in the same similar output as below:

Hydra v9.2 (c) 2021 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2022-03-10 18:08:02
[DATA] max 1 task per 1 server, overall 1 task, 1 login try (l:1/p:1), ~1 try per task
[DATA] attacking mssql://10.10.10.51:7777/
[ATTEMPT] target 10.10.10.51 - login "DOMAIN\username" - pass "password" - 1 of 1 [child 0] (0/0)
1 of 1 target completed, 0 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2022-03-10 18:08:03

To Reproduce
Execute Hydra with a command similar to the one above against a SQL Server configured to support Windows authentication only and with a domain username.

Expected behavior
With a correct username and password, I'd expect Hydra to properly connect and identify that the credentials were correct.

Screenshots
N/A

Desktop (please complete the following information):

• OS:

└─$ cat /etc/os-release                                       
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2021.4"
VERSION_ID="2021.4"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian

• Hydra version:

Hydra v9.2 (c) 2021 by van Hauser/THC & David Maciejak 

• MS SQL SERVER:

Microsoft SQL Server 2014, 12.0.6433.1 (X64)

Additional context
N/A

Any help getting this working would be greatly appreciated.

[vanhauser-thc]

That is not supported, someone would need to add this.

[axzhandul]

Thank you for the response, I really appreciate the status (saves more experimentation). If I’m not mistaken, Windows authentication (which supports domain specification) is now the default authentication mode in MSSQL, and there are 3 modes: Windows auth only (default and recommended best-practice), SQL auth only, and mixed-mode (supports both). It would be a great addition to the doc to specify which modes are supported for travelers which come after, as it will save them a lot of testing time (it would have me).

This seems to be an area not very well covered by similar testing tools. Of the tools I’ve tested, most don’t support Windows auth at all, and the ones which do have some kind of problem with them. Of the tools I’ve tested, the Metasploit mssql-login module is the only one which I can get to work at all, though it has problems too.

• THC Hydra: doesn’t support
• Medusa: doesn’t appear to support
• Ncrack: doesn’t appear to support
• Nmap’s ms-sql-brute: appears to support (based on doc and parameters) but doesn’t work — crashes every time with an identical stack trace to an issue reported back in 2019 which is still open. Based on the error output, it appears perhaps there may have been an evolution in the auth protocol which is now returning an unexpected data structure which hasn’t been supported.
• MSF mssql-login: supports and works for individual username / password combinations and very short lists of passwords (~ < 50). However, any list longer usually crashes with an “Unable to connect” error. I’ve experimented thoroughly with the BRUTEFORCE_SPEED parameter and that setting appears to have no effect on whether it crashes (it does) or how long the list can be / how many entries it takes before it crashes. The problem appears unrelated to the rate of login attempts. I imagine it may be related to a resource leak in the module or framework.

So the sum of my experience thus far is that I know of no tool which either supports all MSSQL authentication modes, nor any tool that can run Windows authentication mode with a password list without crashing. If there is such a tool, it would be most welcome if someone could direct me to it, and I’ll gladly check it out.

Unless I’ve totally missed it (entirely possible), seems like a pretty big hole in password brute-forcing platform coverage. If someone has a desire to implement, I suppose a step in the right direction would be checking out the MSF mssql-login source, which at least can accomplish a Windows auth successfully.

Thanks again for the response.

[vanhauser-thc]

Unless I’ve totally missed it (entirely possible), seems like a pretty big hole in password brute-forcing platform coverage. If someone has a desire to implement

could be that there is currently no tool. maybe that motivates you enough to code it and and send a PR :)

[axzhandul]

Hey, thx for the response. Motivation is no problem, I’d love to be able to add this — time is the limited commodity, which is why getting the doc updated with supported authentication modes for the MSSQL service might help make this happen. Had I known the limitations up front, testing time could have possibly been spent adding it. In fairness, this is kind of the case with all of the tools I mentioned — none really go into the capabilities (of MSSQL support, that is) in detail, and so I spent several days testing / debugging just to figure out what the tools would / not do. Perhaps when time permits I can circle back.

Good tool, well done, and I really appreciate the response.