Windows 2000's built-in Administrator account needs special protection against attacks because of several idiosyncrasies that Win2K inherited from Windows NT. Each Win2K Professional workstation and Win2K member server (e.g., not a domain controller—DC) has a local SAM database that always contains at least two user accounts: Administrator and Guest. Both of these accounts are potential targets for intruders, and you can't delete either account. Although Win2K disables the Guest account by default, which reduces the associated risk as long as you keep this account disabled, the Administrator account is different. For example, even though you can specify an account lockout policy for the local system using the Local Security Policy Microsoft Management Console (MMC) snap-in, Win2K ignores this policy for the Administrator account. In other words, you can't lock out the Administrator account no matter how many times you try to log on.
According to Win2K’s Help text, Microsoft made these exceptions so "that you never lock yourself out of the computer by deleting or disabling all the administrative accounts." Although this decision sprang from good intentions for inexperienced or careless users, it leaves serious security administrators who need to harden systems out in the cold. Attackers know that the Administrator account exists; that this account must be enabled; that it is all powerful; and that no matter how long they pound on this account with password guesses, it won’t lock out.
To make matters worse, a Windows NT Server 4.0 Resource Kit tool called Passprop that helps NT administrators strengthen the Administrator account doesn't work on Win2K, and Microsoft hasn’t included an updated version of Passprop in the Windows 2000 Resource Kit. In NT, you can use Passprop with the /adminlockout switch to lock out the Administrator account according to the system’s lockout policy for network logons; however, the account remains available for interactive logons (at the system’s local keyboard and screen). This approach provids a nice balance between security and preventing a completely locked out system. If you install the NT resource kit on Win2K, you can run Passprop with the /adminlockout switch, but the Administrator account doesn’t lock out even though Passprop completes successfully. Even without this tool, you can take several actions to reduce the risks associated with the Administrator account.
Start by creating a hard-to-guess password for the Administrator account, and keep it secret. This tactic might sound obvious, but I've seen several systems with a blank or trivial password for this all-powerful and well-known account, especially on workstations. Many PC rollout technicians aren't properly trained on security issues and frequently neglect to give the Administrator account a password when installing the OS.
Next, you can protect against remote attacks by removing the local Administrator account's Access this computer from the network right. To access any native resource (e.g., the file system, registry, SAM, event log, or services) on a Win2K system from over the network, the user account you use to connect must have this right. If the Administrator account doesn’t have this right, it doesn’t matter whether attackers do find and guess the account password, they still won’t be able to log on to the system. The easiest way to remove this access is by assigning the Administrator account the Deny access to this computer from the network right. This deny right takes precedence, even if you've assigned its counterpart right, Access this computer from the network, to the Administrator account.
As further protection, you can rename the Administrator account to make it more difficult for attackers to find. However, the old hacker tool, RedButton, which reveals the new name of the Administrator account on NT systems, works on Win2K workstations and member servers. RedButton connects to a system anonymously and enumerates all the local user accounts and their corresponding SIDs. RedButton can find the Administrator account, even if you rename it, because the built-in Administrator account’s SID always ends in 500. To defeat RedButton on Win2K, open Local Security Policy and set Additional restrictions for anonymous connections to Do not allow enumeration of SAM accounts and shares, as Figure 1 shows. To defeat RedButton on a Win2K system that belongs to a domain, implement the same setting in a Group Policy Object (GPO) in Active Directory (AD). If you rename the Administrator account, don’t forget to also change the account’s description because this description can tip off an attacker to the account’s real identity.
In addition to renaming the Administrator account, you might want to create a decoy account called Administrator. Don’t give this account any permissions or rights on the system and remove it from the Users group using the Local Groups and Users section of the Computer Management MMC snap-in.
Finally, monitor the system’s local Security log for logon activity involving the Administrator account. I recommend assigning all legitimate administrators their own administrative accounts. By using individual accounts, you don't ever have to use the built-in Administrator account and you can treat all generic administrative logon attempts as suspicious and investigate them. Failed logons events as a result of a bad password will show up in the local system’s Security log as event ID 529 with the built-in Administrator’s account name in the description section of the event. Logon attempts that fail because you deny the Administrator account the right to log on locally show up as event ID 534. You should be even more suspicious of any successful logons for this account (event ID 528) because they likely signify a successful break in or an administrator that isn’t using his or her account and thus breaking policy. In addition, if you create a decoy Administrator account, you should be vigilant in checking for event IDs 528 and 529 for this account as well.
The Administrator account is a well-known and attractive target for attackers and takes some extra effort to protect in Win2K. Don’t forget that good passwords are your first line of defense. If you follow best practice and assign each an account to each administrator, you can deny the built-in Administrator account the Access this computer from the network right that protects you against all but local attacks. You can rename the Administrator account, but make sure you back that measure by disabling anonymous connections so that RedButton doesn't discover the real Administrator account's new name. Finally, create a decoy Administrator account and monitor for event IDs 528, 529, and 534 in connection with both of these accounts.