THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Argenis Fernandez

On the Topic of Lost SA Passwords on SQL Server 2000…


Since it looks like everything I blog about lately is showing how to get onto SQL instances to which you don’t have formal credentials, I figured what the heck – let’s do a post on SQL 2000.

Earlier on today Saurabh Sapra [twitter] sent a tweet to SQL Server MVP Thomas LaRock [blog|twitter]:


To which Tom replied:


I was flattered. But I had no posts on that subject. So in turn, I replied:



It turns out that it is straightforward. And I will show you how to do just that – recover the SA password of a SQL 2000 instance. It’s easier than you think. As a matter of fact, I’m going to show you how to recover the password for any SQL login that has a current session established against a SQL 2000 instance.

Caveat – and this is important – you cannot recover the password if the user does not have a session established. I.E., if it is not logged on to SQL. I haven’t heard of a way to recover an SA password if there isn’t a connection established to SQL. If you know how to do this, please drop me a line.

Let’s dive right into it.

On Enterprise Manager, I registered the local instance using the SA login – then dropped the BUILTIN\Administrators login.


Nothing shocking there – just showing you that there is at least one active connection to SQL (Enterprise Manager itself) and that there are no other SQL logins on the box.

Next, I opened up a CMD window, and created a memory dump of the sqlservr.exe process. I can do this because I am a local Windows Administrator on this box. To achieve this I used the SysInternals’ ProcDump utility. Then I took the memory dump and parsed it through strings.exe, another SysInternals utility, essentially filtering from the memory dump anything that doesn’t look like a string.


Now I opened dump.txt in Notepad, and searched for the host name of my SQL 2000 box immediately followed by sa. In this case my VM is named “HURRICANE”, so I searched for “HURRICANEsa”


And there you have it. The password is found between the string “HURRICANEsa” and the string “MS SQLEM(LOCAL)ODBC”. The SA password for this instance is “Password@99!”.

Obviously your memory dump will look different than mine, given that your SQL client string will probably be different than the one Enterprise Manager uses – which I leveraged for this example. Also, my SQL 2000 instance had just been restarted, so I had less ‘stuff’ in memory than you probably will. You might even get a false positive. My point: YMMV.

As I mentioned above, this technique also works for any SQL login with an established connection, regardless of its privileges on the server. Moreover, this technique also works on SQL Server 2005 and (I believe – haven’t tested it) some builds of 2008 and 2008 R2. It wasn’t too long ago that the SQL team at Microsoft started to finally clear this area of memory after a session’s credentials have been verified.

Hope this was useful.




UPDATE: A couple of folks asked me which build I used to test this. I originally tested it on SP4a, and later confirmed with a more recent build, 8.00.2187 (but not the latest one that’s available only to customers with support agreements).

Published Friday, January 20, 2012 12:42 AM by Argenis
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



John said:

Is there a way of doing something similar for newer versions of SQL Server? There are plenty of posts explaining how to reset it to something you know or gain access to an instance you are locked out of, but nothing explaining how to tell you what it is.

January 21, 2012 2:18 PM

Argenis said:

@John no, I'm not aware of any means to do that. The SA password is kept in encrypted blobs in newer versions, in a way that I am not familiar with.

You can definitely capture the password from memory if it has been reset very recently though. But it's very short lived.

January 22, 2012 4:26 AM

K. Brian Kelley said:

@John, for 2005+, in memory or by brute force. You can export it, but I've not seen anyone figure out any weaknesses in the hash like with 2000 (where an all uppercase version of the password was hashed and included, thereby reducing the # of possibilities per slot and making brute forcing quicker). The reason this is important is that, unlike Windows, the SQL Server based logins contain a salt, thereby eliminating rainbow tables.

2000 (and 7) is also susceptible to intercept across the network by looking at a packet trace if the sa account is used and the connection isn't encrypted.

February 14, 2012 9:45 PM

Nice job! said:

Congrats for your explanation.

However, please tell me if you see anything wrong in the way I´m trying to do so:

1) from my windows, I log on a sqlserver 2000 8.0.2039 ap4. Say the user is server is myserve and user is john

2) once logged, I procdump -ma sqlservr.exe (always from my windows box)

3) then I string it as in your exemple.

4) then I try to search for myserverjohn, myserver and john and get no results.

Thanks a lot,


May 20, 2013 9:56 AM

Argenis said:


I unfortunately don't have a test rig for this blog post anymore - I guess I'd have to ask: was there a session established to the server under the "john" login? Also, is the "myserve" a typo in your comment?

May 29, 2013 6:01 PM

Argenis said:

Please note that I cannot vouch for any products or technologies mentioned here. Use at your own risk.

February 26, 2014 11:52 AM

aescart1 said:


this helped me a lot ! Brilliant, I was really stuck without that !

October 7, 2014 4:45 PM

Guy R said:

Thanks for this .. 10 year old system .. password lost in the mists of time ... time to upgrade and no SA password to be found .. bugger.

November 24, 2014 5:45 PM

Leave a Comment

Privacy Statement