Hunting Passwords In SYSVOL

Introduction:

By default, all windows operating systems have a built-in Administrator account which has local administrator rights for the particular system.  Windows active directory provides centralized management for windows system and as per compliance requirements, built-in administrator name and passwords can be changed from there. This can be achieved by any of the following approaches:

  1. Manually setting password to each system (This may become tedious when the number of systems increase, thus complicating password management)
  2. Using Logon script (VBScript, BAT script, or PowerShell Script) to change passwords for more than one system in the domain.
  3. Using group policy preferences.
  4. Opting for any solution such as Local admin password management solution by Microsoft to manage the passwords for local accounts.

When a Password is changed using a common script, the common script will set the same password for all the systems in the domain, now if this password is compromised, the attacker will get administrator privileges to not only one but all the systems.

SYSVOL folder:

Every domain controller has a shared folder in its local file system, the file system component of Active Directory. This shared folder is the SYSVOL folder, it contains files and folders that must be available and synchronized between domain controllers in a domain. This folder also has all the group polices, scripts etc.

Figure 1: SYSVOL Folder
Figure 1: SYSVOL Folder

Finding the password:

Password for the local admin can be found out by looking at all the scripts in the SYSVOL folder. In this case, the administrator has taken a simple approach and configured a batch script and VB script to reset the local administrator password.

  • To reach SYSVOL folder: run> %Logonserver%
Figure 2: Finding SYSVOL folder
Figure 2: Finding SYSVOL folder
Figure 3: SYSVOL folder
Figure 3: SYSVOL folder
Figure 4: Policies in SYSVOL
Figure 4: Policies in SYSVOL
  • Search for scripts:

Search for XML, VBS or Batch file that is used to change the password. This can be done by searching for the mentioned file types (with specific search keywords). The password reset script is to be found.

Figure 5: Local admin password in BAT file
Figure 5: Local admin password in BAT file
Figure 6: Local admin password in VBS file
Figure 6: Local admin password in VBS file
Figure 7: Local admin password in VBS file
Figure 7: Local admin password in VBS file

Other locations where you can find the password are group policy preferences,

Group Policy preferences were introduced for windows server 2008 operating systems, prior to that settings were done using scripts.

Figure 8: GPP Control Panel settings
Figure 8: GPP Control Panel settings
Figure 9: GPP Windows settings
Figure 9: GPP Windows settings
Figure 10: GPP User Configuration
Figure 10: GPP User Configuration

For settings done via group policy preference, data is stored in an XML file in the SYSVOL folder. For some of the settings user credentials are required, such as:

  • Map drives (Drives.xml)
  • Create Local Users (unattend.xml)
  • Data Sources (DataSources.xml)
  • Printer configuration (Printers.xml)
  • Create/Update Services (Services.xml)
  • Scheduled Tasks (ScheduledTasks.xml)
  • Change local Administrator passwords
  • Group policy preferences (Groups.xml)

These XML files can be searched in the SYSVOL folder using key word search. Passwords in the XML file can be searched using the key value “cpassword”. The encryption is 32-byte AES as per Microsoft’s documentation, the encryption key is:

4e 99 06 e8  fc b6 6c c9  fa f4 93 10  62 0f fe e8
f4 96 e8 06  cc 05 79 90  20 9b 09 a4  33 b6 6c 1b

Since we have the key and encrypted password, we can decrypt it to obtain the plain-text administrator password.

The above process of searching and decrypting the weakly encrypting the cpassword, can be automated using Get-GPPPassword.ps1 script from the Powersploit framework. If you have access to the Active Directory module in PowerShell, then Find-GPOPasswords.ps1 does a more comprehensive job.

Mitigation:

Microsoft released a security update (MS-14-025) to fix this issue in May 13, 2014. One needs to install the patch KB2962486.

Some alternate workarounds to resolve this issue are:

References:

  •  
  •  
  •  
  • 1
  •  
  •  
  •