Is it possible to extract (not reset) the sa or other passwords from SQL Server? Let me start out that I do not need to reset the SA password, I know how to do that and there are plenty of resources on this site and elsewhere that give detailed step by step tutorials.

We have SQL servers set up on site at clients premises, the problem I am having is 3rd party companies are logging in to the server using our own service logins and doing data mining and data pushing. We are trying to stop this behavior (I know this is a impossible goal, but I am trying to convince other people of this fact).

We have figured out how they are getting our logins currently and will be fixing that, however what I would like to know is: Is there any known tool or process that can "extract" login passwords from a sql server instance (be it a offline attack or via intercepting and snooping a valid connection)?

I think there is likely a way to do it but management would like proof that it can be done.

Does anyone know of any set of tools or processes that it can be done with so I can demonstrate a proof of concept to management?
Depending on access rights to the server and the context in which it operates, there are a variety of ways someone might surreptitiously obtain a SQL username and password.

For example, if a user:


Has rights to attach a debugger to the client application or to the SQL Server process, they could read the password when it’s in memory.
Is able to temporarily redirect the client application away from the SQL Server (e.g. by editing DNS/hosts file, editing a SQL alias, temporarily stopping the SQL Server process then capturing the port used by that process, etc.), they could write a simple program that mimics TDS’s prelogin and login stages, have the client application connect to it, then walk away with the SQL authentication credentials used by the client application.
Is able to access the SQL login’s password hash (e.g. they have rights to sys.sql_logins), they could pull off a brute force attack using SQL queries (e.g. using PWDCOMPARE). At first, this may seem to require extraordinary computing resources and so be unlikely to succeed. However, if the user has some knowledge about the password (e.g. they’ve watched it being typed in and determined that it’s exactly 10 characters long and that only one letter is capital), the amount of effort required for them to do a brute force attack to crack the password is drastically reduced.
Has the private key to SQL Server’s SSL certificate, they potentially could intercept credentials by using a wire sniffer to decrypt TDS's login message.