Where NT Stores Passwords

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Mark Joseph Edwards and David LeBlanc

winnt

Guard your system against attacks

Article from Windows NT Magazine

You probably know that passwords are the keys to most doors on a network, but do you realize where Windows NT 4.0 stores passwords? You can find them in many interesting places, so you'd be wise to become aware of these areas and provide adequate protection against prying eyes.

NT uses the SAM to store and retrieve user credentials such as passwords. Because the SAM stores its information in the SAM database, you can assume that NT is only as secure as its SAM data. And getting a handle on SAM security isn't easy unless you know all the places you might find a SAM database. This article will help you secure specific areas of your NT systems and find additional areas that need further configuration to strengthen security.

The SAM Registry Keys

NT stores a permanent working copy of the SAM database on your hard disk. You can access the database via the HKEY_LOCAL_MACHINE Registry hive under the SAM key by either writing a program or using a Registry editor (e.g., regedt32.exe). Ordinarily, users can't directly access the SAM key with a Registry editor because NT limits the permissions on the key to the built-in SYSTEM account, but administrative users can trick NT into providing SAM-key access under the user context of the SYSTEM account.

Disabling the NT Scheduler service. The trick involves using the NT Scheduler service to start the Registry editor and scheduling regedt32.exe to launch on the desktop at some predetermined time. By default, NT Scheduler runs under the user security context of the SYSTEM account. Thus, any program NT Scheduler launches has full system authority, including full access to the SAM database. Guarding against this risk is tough because you need to disable the service. Disabling NT Scheduler isn't always possible because a given system might require the service for routine tasks. If you can't disable the NT Scheduler service, consider configuring it to run under the user context of a user with only enough authority to perform any scheduled actions.

Using system key technology. Additionally, you can employ Microsoft's system key technology to further protect the SAM. This technology made its first appearance as part of a post-Service Pack 2 (SP2) hotfix, but system key technology made a bigger splash in SP3. (For information about SP3, see "Service Pack 3 Is Really Security Pack 3," August 1997.) In a nutshell, system key technology helps protect NT and its passwords by encrypting the SAM database and requiring the use of an encryption key to boot the OS.

You have three options for managing the system key:

Use a machine-generated random key as the system key, and store the key on the local system using a complex obfuscation algorithm.
Use a machine-generated random key, and store the key on a disk.
Use an administrator-chosen password to derive the system key.

For more details about each of these options, see the Microsoft article "Windows NT System Key Permits Strong Encryption of the SAM" (https://support.microsoft.com/default.aspx?scid=kb;en-us;143475&sd=tech).

Although the system key helps protect the SAM, you need to understand several concepts before you dive in and install it. Be aware that after you apply syskey.exe to a machine, no uninstall process exists, so carefully consider which key storage method is best for your network. After you install syskey.exe on a system, you must immediately make a new Emergency Repair Disk (ERD)—if you don't, you won't be able to adequately recover the system if you need to.

One real benefit of the system key is that if attackers manage to obtain a copy of your SAM database, they won't be able to extract valid password hashes. Attackers won't be able to use tools such as L0pht Heavy Industries' L0phtCrack to crack the passwords. Be aware that the system key won't stop users logged on with administrative authority from dumping the SAM database into a crackable format for use with tools such as L0phtCrack, so assign administrative authority carefully. For example, the Pwdump2 utility correctly extracts password hashes out of the SAM database even with the system key applied. Be aware of the potential risk such tools present.

Another benefit of a system key is that it can let you detect a little-known form of system attack in which people use bootable disks to gain access to the system. Of course, the attack is possible only where you can boot an NT system disk. But if the system boots, an attacker can move the SAM database to another location, then reboot the machine. When the system reboots, NT finds no SAM database and subsequently creates a new one that contains only two accounts: Administrator and Guest—both with blank passwords. Obviously, the attacker can now log on as Administrator using a blank password, do whatever he or she wants, then reboot with the disk and return the original copy of the SAM database to where it belongs.

With the system key installed, detecting this attack later is easy. If you have a system key applied when the machine boots, NT won't present the regular Logon dialog box. Even the most distracted administrator needs to notice this abnormality and immediately begin researching the problem.

Auditing the SAM. In any case, the prudent administrator needs to enable auditing of the SAM database to detect any suspicious activity in a timely manner. Of course, auditing requires that you monitor your event logs regularly and carefully. To enable auditing of the SAM, follow the steps in the sidebar "Setting Up Security Auditing." The Microsoft article "Enable Auditing of Microsoft Windows NT Server Password Registry" (https://support.microsoft.com/default.aspx?scid=kb;en-us;186374&sd=tech) also outlines these steps. Although you can enable auditing of the SAM database, auditing won't occur when someone boots the system from another OS.

At this point, you've applied the changes necessary to initiate auditing on the entire runtime SAM database. The event log will contain information revealing successful and failed access attempts on these SAM keys. But this information serves no purpose unless you monitor your logs carefully.

Enabling this level of auditing can generate a large number of log entries because the security subsystem accesses these keys repeatedly during normal system operation. Therefore, be sure to adjust your log settings to accommodate the larger number of entries and adjust any event log monitor tools you're using.

Programs running under the context of powerful accounts, such as Administrator or SYSTEM, can manipulate event logs and other items. Savvy intruders can easily remove traces of activity.

SAM on Storage Subsystems

NT can store the SAM database on a variety of storage subsystems, including disks, tapes, and hard disks. Copying the SAM database onto a disk or tape requires initial user intervention—this practice isn't ordinarily part of NT's operation. During day-to-day operations, NT is likely to store the SAM database in two places on a hard disk: the %systemroot% repair directory and the %systemroot%system32\config directory. Although the \config directory contains a working version of the SAM database that the live OS uses, programs such as Windows Explorer can't directly access the database for copying while the system is running. This inaccessibility results from the fact that the Local Security Authority (LSA) system process (lsass.exe) has locked the file for exclusive use.

But someone can still use an NT boot disk to copy the file. In such an instance, an intruder can shut down the system, reboot with a disk, and copy or move the SAM database. Here again, a system key can help protect the SAM against disk-based attacks because it has encrypted the SAM database. The same is true for backup tapes, in which any copy of a system key-encrypted SAM extracted from tape is basically useless to an attacker. Nonetheless, keep backup tapes under lock and key to safeguard against tape loss, tampering, and information extraction.

The \repair directory contains the same information as an ERD, which you create using rdisk.exe and use for system recovery. Both the \repair directory and the ERD contain copies of the SAM database and require ample protection. Protect your ERD with the same security as your backup tapes.

To protect the \repair directory, set the permissions to disallow unwanted users from accessing the directory and its files, especially the sam._ file, which contains a copy of the SAM database. To protect files in the \repair directory, carefully perform the following steps using cacls.exe from the Microsoft Windows NT Server 4.0 Resource Kit, or a similar tool.

Open a command prompt, navigate to %systemroot% (usually C:\winnt), and type

cacls repair /g administrators:F system:F /t

Alternatively, you can use Windows Explorer to perform the same steps:

Open Windows Explorer.
Locate the repair directory (usually C:\winnt\repair), right-click the repair folder, and select Properties.
Select the Security tab.
Select Permissions.
Enable Replace Permissions on Subdirectories and Replace Permissions on Existing Files.
Remove all users except Administrators and SYSTEM.
Verify that Administrators and SYSTEM both have Full Control.
Click OK.

You've now granted administrators and the system user full control to that subdirectory and all the files stored in it. Because you didn't choose to edit the ACL, NT has removed all other users' permissions.

In addition to the \repair and \config directories, NT is likely to write SAM-derived information in one of the following files, depending on your system configuration: pagefile.sys, memory.dmp, or user.dmp. NT uses pagefile.sys as an additional virtual memory space that adds to the system's installed hardware-based RAM. NT creates memory.dmp when it crashes and you have your system configured to write a memory dump to disk. NT creates user.dmp when a desktop application crashes and you have Dr. Watson configured to write a memory dump file.

When NT uses any of these files, it writes a considerable amount of memory to disk. In some cases, this information includes passwords that might have been memory-resident. Therefore, gaining access to these three files can become an easy way for an attacker to retrieve sensitive information that can lead to a system security breach.

Minimizing the risk the user.dmp and memory.dmp files present requires you to take one of the following actions:

Write a batch file to erase the files when you log on.
Set permissions on the files so that only administrators can access them.
Set a Registry key to erase the system's pagefile at shutdown.
Configure your system and Dr. Watson so that they don't create the files.

Configuring the system so that it doesn't create these two files is your best bet. However, this method creates a situation in which programmers who must debug a crash problem won't have any data to work with.

To configure Dr. Watson to not write user.dmp files, run drwtsn32.exe, clear the Create Crash Dump File check box, and close the program. To configure NT to not write a memory.dmp file, open the System applet in Control Panel and choose the Startup/Shutdown tab. Next, clear the Write debugging information to check box. If you must have the memory dumps from NT system crashes, consider configuring the system and Dr. Watson to store the dump files in a secure directory that only administrators can access.

As for pagefile.sys, only the OS opens this file and protects it against direct-access attacks. However, you might recall the incident last year in which the bundled NT-based Client Service for NetWare service was writing users' clear-text NetWare passwords directly into memory, and the passwords could've been written to pagefile.sys when NT paged memory space to disk. Anyone with a copy of the pagefile.sys file and a text editor could readily glean the passwords. Novell corrected this problem by having the service use an undocumented API call that encrypts the passwords before the service places them in the pagefile. But attackers can defeat that encryption—a savvy programmer from Russia discovered a way to decrypt the information after you retrieve it from the pagefile. To protect yourself from this type of attack, configure NT to erase the pagefile during system shutdown. (We'll explain this process later in the article.) Also, don't overlook the need for physical security to protect against unwanted access of pagefile.sys.

Although you can configure NT to erase the pagefile during a clean system shutdown, you guard against only intruders copying or corrupting the file when they boot another OS on that system (e.g., when an attacker uses a bootable disk or an alternative install of NT to boot the system). In those cases, most attackers will have already learned about gaining direct entry to your network by copying or moving the SAM database, so attacking the pagefile is essentially pointless.

Nonetheless, in situations in which a network requires you to have multiple OSs installed for legitimate use, erasing the pagefile during a clean system shutdown is a good safeguard to practice. Keep in mind that configuring NT to automatically erase the pagefile during system shutdown will introduce a lag in the system's startup and shutdown time, but this lag is inconsequential if you consider the security you'll gain by doing so. To configure NT to erase the pagefile during a clean shutdown, modify (or create) the ClearPageFileAtShutdown entry (type REG_SZ, value 1) in the HKEY_LOCAL_MACHINE SYSTEM\ CurrentControlSet\ Control\Session Manager\Memory Management Registry key.

Password Hashes in Memory

By default, NT caches the logon credentials for the past 10 users who logged on interactively. The purpose of this functionality is to let a user still log on to the system even if you disconnect the system from the network or if the domain controllers are unavailable. NT provides some protection for the logon credential cache, but if your environment requires a higher level of security, you might want to disable the caching completely because someone could attack it. Keep in mind that the logon cache credentials contain password hashes of other hashes, which makes this data difficult to crack or use for an unauthorized logon attempt. To date, no publicly known exploit of this cache has occurred. To disable credential caching, change the CachedLogonsCount entry (type REG_DWORD, value 0) in the HKEY_LOCAL_MACHINE \SOFTWARE Microsoft\Windows NT\CurrentVersionWinlogon Registry key.

SAM on the Network

NT uses the Server Message Block (SMB) protocol, which Microsoft, IBM, and Intel jointly developed. SMB defines a series of program-level commands that obtain or provide remote file services in a network environment. As you might suspect, an SMB session requires the transmission of sensitive packets of information over the network. Among other information, these packets typically contain an encrypted version of the NTLM challenge when NT transmits the packets during the authentication phase of an SMB session.

Attackers using a readily available packet sniffer can easily grab data sent across the network. Although the task of grabbing the right packets and extracting password information from them hasn't always been straightforward work, this situation changed dramatically with L0pht Heavy Industries release of SMB Packet Capture, an SMB sniffer tool that the company now tightly integrates into L0phtCrack. With L0phtCrack at your disposal, grabbing SMB-based password hashes off the network is easy.

L0phtCrack's built-in sniffer utility silently grabs SMB password hashes and stores them for cracking. Once cracked, these passwords provide easy access to whatever network resources the user account had access to—ouch! The risk here is obvious, and the prevention is simple.

To protect against such an attack, you'll need to use NTLMv2, which shipped with SP4 and SP5, or a VPN tool, such as Microsoft's PPTP. NTLMv2 should be sufficient to protect data as it travels over your internal LAN, and PPTP will help guard your information as it travels over untrusted networks (e.g., the Internet). If you implement PPTP, be certain to load the latest service pack and all the post-service pack hotfixes. We give you this warning because, at one time, compromising a PPTP connection was very easy. Microsoft has long since remedied those shortcomings, but you won't have these remedies in place unless you load the post-SP3 hotfixes or a later service pack.

Also, keep in mind that without a VPN and Microsoft's SMB signing technology in use on your network, a man-in-the-middle attack could potentially hijack an SMB session. Microsoft introduced SMB signing in SP3 and also includes it in later service packs. SMB signing causes the OS to authenticate each SMB packet before acting on it. However, implementing SMB signing has some far-reaching effects on network functionality, so be sure to see the Microsoft article "How to Enable SMB Signing in Windows NT" (https://support.microsoft.com/default.aspx?scid=kb;en-us;161372&sd=tech) for complete details.

To help thwart tools such as L0phtCrack, you might want to restrict NT from sending LanManager (LM) password hashes across the network. LM hashes are much easier to crack than NTLM challenge/response-based hashes because NTLM allows the use of case-sensitive passwords and can use extended keyboard characters, a feature that effectively expands the encryption key space by 26 characters. Remember that strong passwords are difficult for hackers to crack, even with tools such as L0phtCrack. Consider including a carriage return in your password because L0phtCrack doesn't handle this character very well. To insert a carriage return, press Alt+0+1+3 on your keyboard's numeric keypad.

Microsoft released a post-SP3 hotfix that implements a new Registry key for handling this problem. This fix is also present in service packs later than SP3. The new Registry entry is LMCompatibilityLevel (type REG_DWORD) in HKEY_LOCAL_MACHINE \SYSTEM CurrentControlSet\Control\Lsa.

Using NTLMv2, you can set the value to 0, 1, 2, 3, 4, or 5. Setting the value to 0 causes NT to send both NTLM and LM password forms across the network when NT authenticates a network connection (NT's default method of authentication compatibility). Setting the value to 1 causes NT to send both password hashes only if the server requests this action. Setting a value of 2 never lets NT transmit the LM password hash over the network. Setting a value of 3 causes the system to use only NTLMv2 authentication. A value of 4 causes domain controllers to refuse LM authentication, and a value of 5 causes a domain controller to accept only NTLMv2 authentication. Setting this value to 2 is safest, but keep in mind that with this setting, systems that support only LM-style authentication (e.g., Windows 95 and Windows for Workgroups—WFW—systems) can't connect to that particular NT system because they support only the LM type of authentication. For complete details about this configuration setting, see the Microsoft article "How to Disable LM Authentication on Windows NT" (https://support.microsoft.com/default.aspx?scid=kb;en-us;147706&sd=tech). Note that with the release of SP4, this Registry key value can have six possible settings.

Another type of attack exists if an intruder has physical access to a machine. Using a tool such as NT Locksmith or ERD Commander (you can find both at https://www.winternals.com) , attackers can access a system under any user account. To protect against these attacks, make sure you guard the machine to prevent physical access.

Take a Load Off

In this article, we've presented ideas and configuration areas that you need to consider when you implement and manage your NT network and its security. We've also mentioned a few NT-based application password concerns (see the sidebars "BackOffice Security," page 91, and "Securing Custom Applications") that highlight potential problems and help you find ways to discover and watch over password protection issues.

This article should help take a load off your mind, but don't get too relaxed. You've still got a network to closely monitor. Keep watching those event logs!

SIDEBAR 1 Setting Up Security Auditing

Log on with administrative authority.
Start User Manager. Select Policies, Audit and select the Audit These Events check box.
Choose the items to audit for Success or Failure—at a minimum, you should enable auditing Logon and Logoff attempts. Close the dialog box. At this point, you have enabled basic system auditing.
Under Control Panel, Services, set the Schedule service to run under the SYSTEM account and start (or restart) the service.
Open a DOS Command window and check the current system time.
Add one or two minutes to the time (e.g., if it's 11:30, use 11:32) and issue the following command at the DOS prompt:

at 11:32 /interactive "regedt32.exe"

This command establishes a scheduled event that launches REGEDT32 on the desktop at 11:32 running under the security context of the SYSTEM account.
Wait until 11:32, at which time the Schedule service launches the Registry Editor on the desktop. At this point you have complete access to the entire Registry, including the SAM database. Be careful when you edit the Registry; mistakes can render a system unable to boot.
Select the HKEY_LOCAL_MACHINE hive, then locate the SAM tree, and select it in the left pane.
Choose Security, Auditing.
In the Auditing dialog box, click Add, Show Users.

Add the SYSTEM account, the Domain Admins group, all of your trusted administrator accounts, and any other account that has the following User Rights:
- Take ownership of files or other objects
- Back up files and directories
- Manage auditing and security log
- Restore files and directories
- Add workstations to domain
- Replace a process level token
Select the Audit Permission on Existing Subkeys check box

Select the Success and Failure check boxes for the following entries:
- Query Value
- Set Value
- Write DAC
- Read Control
Click OK, Yes.
Repeat steps 10-14 for the SECURITY key if desired. Note: This step is not required if you want to audit only the keys containing passwords.
Exit the Registry editor.
Stop the Schedule service and reconfigure the service account to run under the account prior to Step 4. If you don't use the Schedule service, simply leave it stopped, or better yet, disabled.

SIDEBAR 2 BackOffice Security

Many Windows NT-based applications use passwords that the SAM database doesn't store. Applications such as Microsoft Outlook, Internet Explorer (IE), Internet Information Server (IIS), and SQL Server all store passwords in various locations on the system, so you should be aware of these locations and act to prevent unwanted access.

For example, one of the most widely used applications on NT is IE. Although using IE doesn't require a password, many Web sites you're likely to access with IE do. Poor Web site design leads to all kinds of security trouble, especially when cookies store usernames and passwords that the site requires for access. Cookies have a programmable lifetime, so you can set them to expire immediately. This action causes the cookies to remain in memory only for the duration that the site is using them in a live interactive Web session, so they are not written to disk. NT immediately writes cookies that contain usernames and passwords that don't expire to the %SYSTEMROOT%\Profiles\%username%\Cookies directory.

Anyone with access to a user's cookie directory also has access to all the cookies it contains, including those that contain sensitive information such as usernames and passwords. To make matters worse, a malicious Web site operator who knows which cookies to look for can extract them from the Cookies directory without the user's knowledge. This situation isn't a security flaw in IE, it is just the nature of the HTML cookie specification.

To protect yourself, you should habitually examine and delete cookies that contain sensitive information—just open the cookie files with a normal text editor and see what's in them. You should also complain loudly to sites that store sensitive information in disk-based cookie files, because this practice presents a huge security risk.

You should also know that although the Outlook client doesn't store passwords in clear text anywhere on the system during regular operation, if you're accessing a Post Office Protocol 3 (POP3) server, it will transmit passwords over the network in clear text. These passwords are easy to grab with a generic packet sniffer. POP3 requires the use of clear-text passwords, so Microsoft can't do anything to remedy this issue. Nonetheless, if you must use a POP server to get your mail, you should consider using Authenticated Post Office Protocol (APOP) instead of POP3 because APOP uses encrypted passwords.

Also be aware that SQL Server stores passwords in Registry keys when you configure it to handle its own user authentication. Those particular Registry keys have very little protection. For example, when you register a SQL Server using the SQL Executive, it writes the username and password for that server to the Registry under the HKEY_LOCAL_MACHINE \Software \Microsoft \MSSQLServer tree. Obtaining SQL Server passwords is easy, if not outright trivial work for any savvy user with interactive logon rights to the server, so be careful which users you grant the right to log on locally to your SQL Servers (or any servers for that matter). Now is probably a good time to remind you that you'd be wise to disallow remote Registry access on all NT systems that you can. But you must carefully plan this configuration because many network management packages and software installation routines require remote Registry access to operate correctly.

And speaking of installation routines, someone recently discovered that a flaw in Microsoft's BackOffice Server installation routine leaves user passwords written to disk in clear text and in areas of the file system that regular users can access. During BackOffice installation, the program creates the file, REBOOT.INI, in the \Program Files\Microsoft Backoffice directory. If a user chooses to install SQL Server, Exchange Server, or Microsoft Transaction Server (MTS) as part of a BackOffice 4.0 installation, the BackOffice installation program requests the name and password for the accounts associated with these services.

More specifically, the setup program asks for the account name and password for the SQL Executive Logon account, the Exchange Services Account, and the MTS Remote Administration account, and stores this information in clear text in the REBOOT.INI file. After the installation completes, the setup program fails to delete the file. So, make sure you delete this file manually after a BackOffice 4.0 installation is complete! And be certain to read Microsoft Knowledge Base article 217004, which addresses this problem in detail.

SIDEBAR 3 Securing Custom Applications

Many software companies don't design programs with high security in mind, and if you ask around, you'll probably find that programmers aren't necessarily security-minded individuals. For most programmers, security is an after-the-fact consideration that occurs only after attackers compromise programs, or after the programs have allowed the compromise of an entire system or network.

Various software products have security issues. One such product is Oracle's database software, which leaves sensitive information readily available on the system in clear text. During an Oracle install on NT, Oracle's SPOOLMAIN.LOG file records database passwords in clear text.

The moral is to protect yourself by examining your system very carefully before, during, and after installing new software products, especially if those products aren't mainstream commercial items. A good way to keep a close eye on the Registry is to use SYSDIFF in Microsoft Windows NT Resource Kit. With SYSDIFF you can make an image of the Registry before you install new products, then compare that image to the working Registry after you install the product. SYSDIFF reveals any changes between the two Registry images. As a great alternative, Mark Russinovich's REGMON tool (available at https://www.sysinternals.com) lets you watch Registry access in realtime, which makes it an awesome addition to your toolkit.

For file system changes, you can make a before-and-after comparison to help locate all files added or changed by installing a new product. To perform such a comparison, you can use WINDIFF, which is also available in the NT resource kit, to compare one text file to another.

To examine changes in the file system using WINDIFF, before you install a new product, open a DOS window and change to the root directory of the disk you want to watch (e.g., C:\). Then, create a text file containing your entire directory and file structure by issuing the command

dir /S > directory1.txt

This command creates the text file, directory1.txt, which contains a list of all directories and files on whichever drive you were on when you issued the command. Create such a file for all drives available on your system, using a different name for each drive, of course. When you complete your new software installation, create another set of files in the same manner, using different file names. Next, use WINDIFF to run a comparison of each matching set of directory listing files you've created, at which point any directories and files that an installation routine removed, added, or modified should become readily apparent in the WINDIFF display. Be sure to read the WINDIFF Help file for complete instructions on using the tool.

In addition to WINDIFF, you can use Mark Russinovich's FILEMON (also available at the Sysinternals Web site), which watches all file system activity. Using FILEMON and WINDIFF is a good idea because it will help catch third-party applications that might be reading sensitive system information without your knowledge. WINDIFF alone isn't capable of monitoring file access.

About the Authors

Mark Joseph Edwards is a writer and network engineer with more than 16 years of experience. He is a consultant and author of Internet Security with Windows NT (29th Street Press). You can reach him at mark@ntshop.net or mje@winntmag.com

David LeBlanc has more than 5 years of experience with Windows NT security and is a senior technologist for Microsoft's network security group. You can reach him at dleblanc@mindspring.com.

The above article is courtesy of Windows NT Magazine.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International Rights = English Only