{
	"id": "b3251188-38ca-44ce-a616-0eba641c5af4",
	"created_at": "2026-04-06T02:12:59.561883Z",
	"updated_at": "2026-04-10T13:13:09.790494Z",
	"deleted_at": null,
	"sha1_hash": "365258a15d3a3866f6e38481ebacbfac51c7fc62",
	"title": "Finding Passwords in SYSVOL \u0026 Exploiting Group Policy Preferences",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 331320,
	"plain_text": "Finding Passwords in SYSVOL \u0026 Exploiting Group Policy\r\nPreferences\r\nBy Sean Metcalf\r\nPublished: 2015-12-28 · Archived: 2026-04-06 02:08:57 UTC\r\nAt Black Hat and DEF CON this year, I spoke about ways attackers go from Domain User to Domain Admin in\r\nmodern enterprises.\r\nEvery Windows computer has a built-in Administrator account with an associated password. Changing this\r\npassword is a security requirement in most organizations, though the method for doing so is not straight-forward.\r\nA standard method is to use Group Policy to set the local Administrator password across a large number of\r\nworkstations. A major issue with this is that all of the computers have the same local Administrator password.\r\nWindows is extremely helpful when it comes to local accounts since if two (or more) computers have the same\r\nlocal account name and password, Windows will authenticate the account as if it is local, meaning that by gaining\r\nknowledge of the administrator credential on one system, the attacker can gain admin access to all of them (that\r\nhave the same local administrator credentials).\r\nSYSVOL\r\nOne of these methods is mining SYSVOL for credential data.\r\nSYSVOL is the domain-wide share in Active Directory to which all authenticated users have read access.\r\nSYSVOL contains logon scripts, group policy data, and other domain-wide data which needs to be available\r\nanywhere there is a Domain Controller (since SYSVOL is automatically synchronized and shared among all\r\nDomain Controllers).\r\nAll domain Group Policies are stored here: \\\\\u003cDOMAIN\u003e\\SYSVOL\\\u003cDOMAIN\u003e\\Policies\\\r\nCredentials in SYSVOL\r\nA big challenge for administrators has been ensuring that the local Administrator account (RID 500) on all\r\nWindows computers. The traditional method for doing this (other than buying a product) has been to use a custom\r\nscript to change the local administrator password. This issue with this is that frequently the password is stored in\r\nclear-text within the script (such as a vbs file) which is often in SYSVOL. Here’s an example of one of the top\r\nresults when searching for a VBS script that changes the local Administrator password. The vbs script is still\r\navailable on the Microsoft TechNet gallery and the password is obvious. Remember this script is stored in\r\nSYSVOL which every domain user has read access to and the password is the local Administrator password for\r\nevery computer the Group Policy is applied to.\r\nhttps://adsecurity.org/?p=2288\r\nPage 1 of 5\n\nPlease don’t use this script to change the local Administrator password.\r\nGroup Policy Preferences\r\nIn 2006, Microsoft Bought Desktop Standard’s “PolicyMaker” which they re-branded \u0026 released with Windows\r\nServer 2008 as “Group Policy Preferences.” One of the most useful features of Group Policy Preferences (GPP) is\r\nthe ability to store and use credentials in several scenarios. These include:\r\nMap drives (Drives.xml)\r\nCreate Local Users\r\nData Sources (DataSources.xml)\r\nPrinter configuration (Printers.xml)\r\nCreate/Update Services (Services.xml)\r\nScheduled Tasks (ScheduledTasks.xml)\r\nChange local Administrator passwords\r\nThat’s very helpful for administrators since it provides an automated mechanism for what previously required a\r\ncustom solution such as a script. It provides useful capability to leverage Group Policy to “deploy” scheduled\r\ntasks with explicit credentials and change the local admin passwords on large numbers of computers at once –\r\nprobably the two most popular usage scenario.\r\nCredential Storage in Group Policy Preferences\r\nThe question at this point should be: how is the credential data protected?\r\nWhen a new GPP is created, there’s an associated XML file created in SYSVOL with the relevant configuration\r\ndata and if there is a password provided, it is AES-256 bit encrypted which should be good enough…\r\nhttps://adsecurity.org/?p=2288\r\nPage 2 of 5\n\nExcept at some point prior to 2012, Microsoft published the AES private key on MSDN which can be used to\r\ndecrypt the password. Since authenticated users (any domain user or users in a trusted domain) have read access to\r\nSYSVOL, anyone in the domain can search the SYSVOL share for XML files containing “cpassword” which is\r\nthe value that contains the AES encrypted password.\r\nExploiting Group Policy Preferences\r\nWith access to this XML file, the attacker can use the AES private key to decrypt the GPP password. The\r\nPowerSploit function Get-GPPPassword is most useful for Group Policy Preference exploitation. The screenshot\r\nhere shows a similar PowerShell function encrypting the GPP password from an XML file found in SYSVOL.\r\nOddvar Moe notes a quick way to search for these:\r\nfindstr /S /I cpassword \\\\\u003cFQDN\u003e\\sysvol\\\u003cFQDN\u003e\\policies\\*.xml\r\nFrom what I can find, the issues with GPP credentials was first written about by Emilien Gauralt in the post\r\n“Exploiting Windows 2008 Group Policy Preferences” in January 2012. Unfortunately the link is dead and the\r\ncontent offline. A few months later in May, Chris Campbell – wrote the article “GPP Password Retrieval with\r\nPowerShell” as well as the first PowerShell code to exploit this issue. Chris later updated the PowerShell code and\r\nadded Get-GPPPassword to PowerSploit. About a month later, in June, “Rewt dance” posted a GPP exploitation\r\nexpanded reference (link offline – google cached version). I also recently discovered Alexandre Herzog’s post\r\n“Exploit credentials stored in Windows Group Policy Preferences” (dated April 2012).\r\nI have written about the problems with credentials in Group Policy Preferences and the GPP patch (KB2962486).\r\nhttps://adsecurity.org/?p=2288\r\nPage 3 of 5\n\nI continue to find administrative credentials (including Domain Admin credentials) in Group Policy Preference\r\nXML files in SYSVOL, especially for scheduled tasks running under the context of admin accounts.\r\nThe Group Policy Preference Credential Patch (KB2962486)\r\nThe obvious question for defenders is how to protect against this?\r\nMicrosoft released a patch in May 13, 2014 : “MS14-025 Vulnerability in GPP could allow elevation of privilege”\r\n(KB2962486). This patch needs to be installed on all systems that administer Group Policy using the Remote\r\nServer Administration Tools (RSAT). This patch prevents admins from putting password data into a Group Policy\r\nPreference.\r\nNote that existing Group Policy Preference files with passwords are not removed from SYSVOL\r\nMicrosoft provides a sample PowerShell script for finding GPP passwords in SYSVOL:\r\nhttps://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevation-of-privilege-may-13,-2014\r\nGroup Policy Preference Exploitation Detection:\r\nXML Permission Denied Checks\r\nhttps://adsecurity.org/?p=2288\r\nPage 4 of 5\n\nPlace a new xml file in SYSVOL \u0026 set Everyone:Deny.\r\nAudit Access Denied errors.\r\nSing the associated GPO doesn’t exist, there’s no legitimate reason for access.\r\nGroup Policy Preference Exploitation Mitigation:\r\nInstall KB2962486 on every computer used to manage GPOs which prevents new credentials from being\r\nplaced in Group Policy Preferences.\r\nDelete existing GPP xml files in SYSVOL containing passwords.\r\nMicrosoft Local Administrator Password Solution (LAPS)\r\nThe best Microsoft provided method for changing local Administrator passwords is the “Local Administrator\r\nPassword Solution” aka LAPS.\r\nReferences:\r\nSean’s presentation slides \u0026 videos on Active Directory security\r\nGroup Policy Preferences AES private key on MSDN\r\nUsing Group Policy Preferences for Password Management = Bad Idea\r\nGPP Password Retrieval with PowerShell\r\nThe PowerSploit function Get-GPPPassword\r\nGroup Policy Preferences Password Vulnerability Now Patched\r\nMicrosoft Local Administrator Password Solution (LAPS)\r\n(Visited 242,127 times, 13 visits today)\r\nSource: https://adsecurity.org/?p=2288\r\nhttps://adsecurity.org/?p=2288\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://adsecurity.org/?p=2288"
	],
	"report_names": [
		"?p=2288"
	],
	"threat_actors": [],
	"ts_created_at": 1775441579,
	"ts_updated_at": 1775826789,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/365258a15d3a3866f6e38481ebacbfac51c7fc62.pdf",
		"text": "https://archive.orkl.eu/365258a15d3a3866f6e38481ebacbfac51c7fc62.txt",
		"img": "https://archive.orkl.eu/365258a15d3a3866f6e38481ebacbfac51c7fc62.jpg"
	}
}