Re: WHERE ARE NT4 OLD PASSWORDS STORED - summary of replies

From: Russ (Russ.Cooper_at_RC.ON.CA)
Date: 07/10/03

  • Next message: Russ: "Re: Alert: Microsoft Security Bulletin - MS03-023 - update"
    Date:         Thu, 10 Jul 2003 10:55:39 -0400

    So the question was, where are the NT 4.0 old passwords stored so password history will work? I've compiled 3 replies together;

    1. Tom Geairn pointed out that Bindview had a very good paper that included information about the subject. That paper was published on NTBugtraq in Dec. 1999;

    A prettier version can be seen on Bindview's site here;

    2. 314ns at wrote a detailed explanation of the key structure;

    > Where does NT4 keep the users old passwords
    > when the password history option is enabled ?
    What an excellent question Steve ! I'm really surprised nobody tried (and published !) the trick to retrieve the Windows NT password history at this time...
    > Also as I do not believe they are in the SAM,
    > I would also want to closely
    > audit the location where they are kept.
    You're guessing wrong : password history IS in the SAM database !
    > Any help or avenues of investigation would
    > be gratefully received. Else I will have to
    > image the whole drive and start checking all
    > files for changes.
    Please don't !
    Well....let's try to understand the structure of the entity that stores the passwords in a NT box, having a look at the famous pwdump V1.0 source code and...using a bit of guessing / hacking.
    The password hashes in Windows NT are stored in the registry under the SAM database. Precisely, hashes are stored in the HKLM/SAM/SAM/Domains/Account/Users key (or in the HKLM/SECURITY/Sam/Domains/Account/Users key, which is just a link on the same key - or vice-versa i don't remember).
    Under this key, you will find subkeys that represent RIDs of the users en hex (000001F4 for the Builtin Admin Account for example). Under each of theses keys, you get  "V" value that contains description of the user and...the password hashes, including the historical ones (how interresting isn'nt it ?).
    Now, let's hexadump a "V" Value :
    0x0C   Username offset
    0x10   Username lenght
    0x18   Full Username offset
    0x1C   Full Username lenght
    0x24   Comment offset
    0x28   Commen lenght
    0x48   Homedir offset
    0x4C   Homedir lenght
    0x9C   Password Hashes offset
    0xC4   Number of hashes in the history (new undocumented point !!! Warning : the number is reversed, ie 0x04 will be encoded as 0x40).
    To retrieve the REAL position of an entity, just add 0xCC to the corresponding offset (example : if the username offset at 0x0c is 0xA8, then the Username is at 0x0174 in the V value).
    At the position of the current password hashes, you will find : 16 bytes for the current lanman hash, followed by 16 bytes for the current NTLM hash.
    Please note that hashes are encrypted using a DES-EBC algorithm, the DES key is derivated from the user's RID, so you will have to decrypt the hashes for each user to obtain the real cryptograms.
    So, where are the old password hashes now ?
    Very simple, they are just stored AFTER theses current hashes, but in a weird order (that's the tiny hack i was talking about!).
    How ?
    Just that Way :
    Current (T) LM hash
    Current (T) NTLM hash
    (T-1) NTLM hash
    (T-2) NTLM Hash
    (T-n) NTLM Hash
    (T-1) LM Hash
    (T-2) LM Hash
    (T-n) LM Hash
    Now you should be able to modify the pwdump source code (as i did : believe me, it works fine !) to retrieve the whole password history.
    Have fun!
    3. PWDump source and execute can be found in the mirrors, one example being;
    4. James MacDonald wrote a step-by-step that will let you see the data in question;
    Actually they are stored in the SAM, but you have to set yourself up with permissions to read that portion of the SAM where they are located. Assuming you have a password history policy set for the Local Computer, here are the steps.
    1.      Create a Scheduler job as follows (you must have admin on the computer).
    P:\>at \\yourcomputername 15:49 /interactive cmd.exe
    Added a new job with job ID = 1
    2.      Confirm the job by:
    Status ID   Day                     Time          Command Line
    ---         1   Today                   3:49 PM       cmd.exe
    3.      Once the command prompt starts up, if you have WHOAMI.EXE from the RESKIT run it and you will get the following:
    This is very important, it must say SYSTEM, because even admins cannot read the SAM portion of the Registry. LSA (SYSTEM) is the only "account" with the permissions to access this.
    4.      From this command prompt, type REGEDIT.  You can now open the SAM portion of the Registry.  If you now open the Registry key:
    What you see is a series of hex numbers under Users.  Also, under Names you will see the account names in the clear.
    5.      Select one of account names and open the key. You will see a single hex number under the "Type" field.  Remember this number and open the key corresponding to this hex number under Users.
    6.      You now should see two REG_BINARY entries labeled F and V.  Open the V entry and note the length (size) of the field.
    7.      On NT 4 bring up MUSRMGR (in my case W2K, I went to Manage Computer) locate the account that you will be changing the password on and change the account.
    8.      Go back to the REGEDIT windows and re-check the length of the V REG_BINARY value and you will see that it has changed (and continues to change each time you change the password.
    At this point I believe you will be able to do what you want with the history.
    Russ - NTBugtraq Editor
    Are You "Certifiable"? Summer's Hottest Certification Just Got HOTTER!
    With a growth rate exceeding 110%, the TICSA security practitioner
    certification is one of the hottest IT credentials available.  And now, for
    a limited time, you can save 33% off of the TICSA certification exam! To
    learn more about the TICSA certification, and to register as a TICSA
    candidate online, just go to

  • Next message: Russ: "Re: Alert: Microsoft Security Bulletin - MS03-023 - update"