Global war on local Administrator

{LANG_NAVORIGIN} Operating System Microsoft Windows 2000 and NT
By: Sergey V. Gordeychik, 07/22/2004



All seemed to be going well. The users' privileges have been minimized. User was not able to log on another user's workstation. No other programs than business-purposed were installed on user computers. According to system policy, user passwords must be changed once in a fortnight, and all the users obey orderly. Their password phrases resemble the programmer's cat name or the randomizer output. The management people use the two-way authentication hardware, so you can stop checking their CAPS LOCK status. But all of a sudden, one day you realize that user accounts are moved from Users group to Administrators, and the group of operators has now got full control on the root folder of "C:" volume. Now, who is responsible for all the trouble?

By default, Windows 2000 operating systems create two accounts. Guest account is normally blocked. The rights are extremely limited. Administrator accounts are granted with unlimited rights for the computer, and suffer most furious attacks. After the workstation is included into a domain, the Administrator account is normally unused. You may want to use Administrator account as a last resort, for example, when you have to restore the operating system. However, the one logged as Administrator can block the group policy inheritance, extend the rights of domain users, and finally, receive Local System rights. You cannot block this account (this feature is available in Windows XP and later). Local administrator's password is usually set up by the maintenance people or the users themselves. Centralized control over the administrator's password is unavailable. You can crack the administrator's password using the network connection, because the blocking policy does not affect this account.

If the workstation can be accessed physically, the local administrator password can be picked or just reset in a few minutes. However, there are certain operations to ensure that the network is not so much dependent on the local administrator's actions. In some cases, they recommend to rename the local administrator's account. This operation can be performed locally or by using the group policy. Though, you can easily find out which account belongs to the local administrator. However, don't miss an opportunity to set up one more protection.

When the administrator's account is renamed, you have to choose the account to use for system restores. This can be a local or a domain account. The local account can be used for system restore even if the connection to the domain had been lost. Using a domain account, you ensure more safety, because in this case, the password cannot be reset physically. Besides, in such case the system restore cannot be performed easily without a strong network connection. It is recommended to use the local account in normally protected server systems with strong requirements to the restore operation. In this case, you should create an account different to the local administrator's. According to Dave Kleiman's recommendation (Dave Kleiman dave@netmedic.net), you'd better include special symbols in the account name, e.g., ALT+251. The researches demonstrate that the account names containing such symbols cannot be displayed correctly when using the programs like sid2user or showmbrs. Besides, such names make it difficult to pick out the password using L0phtCrack or like utilities. For the full list of such symbols and the detailed analysis of their usage, refer to Dave Kleiman, Defeating password cracking, from the focus-ms@securityfocus.com mailing.

For system restores on the workstations, we recommend using the domain accounts. Before starting the restore, you should limit the number of the users who can log to the workstation locally and set the number of logons to cache. This number cannot exceed the number of the users who can log locally. The support group should use domain accounts to perform the workstation setup to ensure that the password will be cached on the local host.

The next task is group policy change limitation. Group policy objects include Computer SettingsAdministrative settingsSystemGroup PolicyUser Group Policy loopback processing mode (MS KB Q231287). With this feature, you can modify the method of calculating the resultant group policy. You can use either the Merge Mode or the Replacement Mode. When the local system uses the Replacement Mode, and no other policies affect this value, the resultant group policy is determined only by which organizational unit the workstation belongs to, regardless of a user logged on. Thus, the local administrator derives a possibility of walking around the group policy limitations like applications running, Start menu access or other user's limitations applied to all the users on the workstation. To avoid such a situation, you should set the User Group Policy loopback processing mode property of the domain-level group policy with No Override status to Disabled. When the computers predictably use this method, you should prevent their users from accessing the group policy controlling this mode.

The next step includes the restriction of local group membership. You can do it using group policies too. GPO Restricted Groups property allows you to specify which accounts should be included into a particular group. The domain administrators and the accounts of technical support staff must be included into the group of local administrators. Because these accounts may differ depending on the organizational unit, apply such policies on the level of organizational units. When all these values are set, a user with administrator's rights can only include another user to the administrators group for the period between group policy updating. If a local account is used for the system restore, you should also include this account to the local administrators group using group policies. After that, it is recommended to perform a centralized change of the local administrator's password. Besides, you should also change the password of the local account which is used for the system restore of the domain workstations. SetPassword method of User object allows you to change the user's password from both current and remote computer (Listing 1).

Set objUser = GetObject("WinNT://" & strComputer & "/Administrator")
objUser.SetPassword strPassword
objUser.SetInfo

Listing 1. Using VBScript to change the local administrator's password

Using Startup Scripts for changing the local administrator's password is not recommended by safety means. The reason is that in such case the password should be specified in the script. Microsoft Script Encoder utility used for encoding the script files cannot provide enough protection because its output files can be decoded without difficulty. Most safe script presumes to periodically start up the application that changes all the local administrator's passwords in the domain. The list of domain computers is contained in a file. The passwords may differ for the local administrator of different computer groups. See Listing 2 for the example of such a script.

'On Error Resume Next 
iaPass = "..bL@nK P/ssw0rd!!"
Sub Error_(i)
 s = Err.Number
 WScript.echo "Error " & s & " " & Err.Description
 if i<>0 Then Err.Clear	
End Sub
Set Args = WScript.Arguments
Sub chPass(host)
' On Error Resume Next 
 strComputer = host
 Set objUser = GetObject("WinNT://" & strComputer & "/Administrator")
 objUser.SetPassword iaPass
 objUser.SetInfo
 If Err.Number<>0 Then
 s = Err.Number
 WScript.echo host & " × Error " & s & " " & Err.Description
 Err.Clear
 End If
End Sub
Sub ReadHostFile(filename)
 Dim fso, f
' On Error Resume Next 
 Set fso = CreateObject("Scripting.FileSystemObject")
 Wscript.Echo "Read hosts file"
 Set f = fso.OpenTextFile(filename, 1, False)
 if Err.Number<>0 then
 	call Error_(0)
	else
	while not f.atEndOfStream
		s = f.ReadLine
		Call chPass(s)
		Err.Clear
	wend
 	f.Close
 end if 
End Sub
for i=0 to args.count-1
	If Args(i) = "-f" Then	
		iaComputers = Args(i+1)
	Else If Args(i) = "-p" Then
		iaPass = Args(i+1)
	Else If Args(i) = "-h" Then
		iaHost = Args(i+1)
	End If
	End If
	End If
Next
If Err=0 Then
If iaHost<>"" Then
	Call chPass(iaHost)
	If Err.Number<>0 Then
		 call Error_()
	End If
	Else
	Call ReadHostFile(iaComputers)
End If
End If
if Err <> 0 Then
 Wscript.Echo "" 
 Wscript.Echo "lapass [-f filename] [-h hostname] [-p] password" 
 Wscript.Echo "" 
 Wscript.Echo "-f get hostÒs list from file" 
 Wscript.Echo "-h change password for one host" 
 Wscript.Echo "-p new password" 
 Wscript.Echo "" 
End If

Listing 2. lapass.vbs script

Consider several schemes of the script's operation. To change the local administrator's password on the workstation, you should type the following command in the Run dialog box:

cscript lapass.vbs -h . -p pass 

To change the local administrator's password on the workstations, whose names are stored in the hosts.txt file, you should type the command with the following parameters:

cscript lapass.vbs -f host.txt -p pass

The application creates a list of computers whose administrator's password could not have been changed. This list can be used on the next iteration. The list is also useful to decide which computers have a setup that goes against the domain security policy. Include special symbols into the administrator's password to make password guessing more difficult.

As a next step, you can forbid the local administrator to access the computer through the network or to log on locally. Remember that preventing the administrator from logging on may cause a lot of difficulty in case of system crash, unless there is another user with the administrator's rights on this computer. Therefore, it is not recommended to forbid the domain server's administrators to log on locally. Restraining the local administrator's possibilities of remote log on is preferable. To deny the administrator's remote logon (MS KB Q281140), specify the administrator's account in Computer SettingsWindows SettingsSecurity SettingsLocal PolicesUser Right AssigmentsDeny access to this computer from the network. Another parameter regulating the local logon is resided in the same group policy section. Denying the remote access does not remove the danger of picking the password through the network (SMB, SMTP, HTTP etc). The group policy is applied after the authentication is complete: the message reading that the remote access is prohibited for this user appears after the right password has been entered.

To avoid such situation, you can use passprop tool from the Windows NT Reskit. This tool allows locking out the administrator account in case the counter of unsuccessful remote logins has been exceeded. The number of attempts is set using the Computer SettingsWindows SettingsSecurity SettingsLocal PolicesAccount Lockout PolicyAccount lockout threshold parameter. The lockout does not affect the local logon attempts. It is recommended to set up short periods (10 minutes) of lockout after 20-30 failed logon attempts because there can be additional local accounts (such as an application users) in the system. This method is more efficient if the passwords change periodically.

The methods above provide more effective protection from the majority of common schemes that involve getting local administrator's rights and illegal usage of administrative privileges. Another protection layer allows you to spot timely the successful logons to accounts with the rights of the local administrators. For this purpose, you should follow the workstations journal's events with EventID 528 or 540 whose Domain value concurs with Workstation Name value. Unfortunately, Windows 2000 operating system does not include a system with monitoring and real-time response functions. There are a number of host-level attack detection systems and the systems for central management of network infrastructure. As a simple solution, we can recommend the usage of Start Scripts to assign a special log on script to the local users. This script should notify the network administrator of the user logon.

on error resume next

Set objWMIService = GetObject("winmgmts:.rootcimv2")
Set Query = "Select * from Win32_OperatingSystem"
Set colItems = objWMIService.ExecQuery(Query,,48)
For Each objItem in colItems
	path = objItem.SystemDirectory
Next

Set fso = CreateObject("Scripting.FileSystemObject")
path = path+"Repl"
fso.CreateFolder(Path)
path = path+"import"
fso.CreateFolder(Path)
path = path+"scripts"
fso.CreateFolder(Path)
Set f = fso.OpenTextFile(path+"Echo.vbs", 2, True)

f.WriteLine "Set WNetwork = Wscript.CreateObject(""Wscript.Network"")"
f.WriteLine "If WNetwork.ComputerName = WNetwork.Userdomain Then"
f.WriteLine "Set WshShell = WScript.CreateObject(""WScript.Shell"")"
f.WriteLine " WshShell.Run ""net send w2k10 Local logon "" &"_
 & " WNetwork.UserName"
f.WriteLine "End If"

f.Close


Set objUser = GetObject("WinNT://./Administrator")
objUser.Put "LoginScript", "Echo.vbs"
objUser.SetInfo

Listing 3. Script.vbs script

This script finds out the path to the Windows system folder and attempts to create there the subfolder ReplImportScripts. This folder contains user scripts. By default, this folder is created on the domain controllers only. After that, the Echo.vbs file is created in this folder. This file is assigned to local users as a start script. The script determines whether the logged account is local or domain. In the former case, the script notifies the domain administrator. Script.vbs script is applied each time the computers start and rewrites the Echo.vbs script. Besides, the script updates the assignments of user start scripts to this file. The Echo.vbs file is applied when a local user logs to the system. You can extend the Script.vbs's script functions to changing all local users' startup scripts.

The methods above cannot protect the system from skilled hackers who can replace the computer's operating system but provide effective protection from middle-level attacks.


Sergey V. Gordeychik gordey@infosec.ru














Your IP address will be sent with this e-mail

From e-mail to e-mail