{
	"id": "eb56bc1f-0f6b-4e6c-ad31-a4faab017d56",
	"created_at": "2026-04-06T00:08:15.190165Z",
	"updated_at": "2026-04-10T03:21:00.38172Z",
	"deleted_at": null,
	"sha1_hash": "9e743e7d7d69d9514eb93c6875e694d2e968d0d1",
	"title": "Dump Clear-Text Passwords for All Admins in the Domain Using Mimikatz DCSync",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1928016,
	"plain_text": "Dump Clear-Text Passwords for All Admins in the Domain Using\r\nMimikatz DCSync\r\nBy Sean Metcalf\r\nPublished: 2015-11-22 · Archived: 2026-04-05 22:53:38 UTC\r\nThe two key goals of any attack is access and persistence. This post covers elements of each.\r\nIn a post-exploitation scenario where the attacker has compromised the domain or an account with delegated\r\nrights, it’s possible to dump the clear-text passwords of admins without being a Domain Admin*. This method\r\nrequires the Active Directory Domain Functional Level (DFL) to be Windows Server 2008 or higher and a patient\r\nattacker (as well as appropriate rights).\r\n* depending on existing AD delegation or attacker configured delegation. Required rights are described at the end\r\nof this post\r\nI spoke about some of this information at several security conferences in 2015 (BSides, Shakacon, Black Hat,\r\nDEF CON, \u0026 DerbyCon).\r\nMimikatz DCSync Capability:\r\nThe Mimikatz DCSync capability is pretty amazing from an offensive perspective since it provides the capability\r\nto pull domain account password data remotely from the Domain Controller. The account that runs DCSync needs\r\nto have the proper rights since DCSync pulls account data through the standard Domain Controller replication\r\nAPI. Prior to this Mimikatz capability, added in late August, dumping all or selective account password hashes\r\nfrom Active Directory required code execution on the Domain Controller, pulling the AD database (ntds.dit) and\r\ndumping the contents, or running something like Invoke-Mimikatz over PowerShell Remoting.\r\nWith DCSync, and the proper rights, the attacker can pull useful password data on the account including\r\n(potentially):\r\nSAM Account name\r\nAccount Type\r\nUser Account Control options\r\nAccount Expiration\r\nPassword last set date\r\nSecurity ID (SID)\r\nRID\r\nCurrent and previous (password history) NTLM password hashes which shows the password history, at\r\nleast in NTLM hash format.\r\nCurrent and previous LM password hashes which shows the password history in LM hash format.\r\nClear text password (requires reversible encryption)\r\nhttps://adsecurity.org/?p=2053\r\nPage 1 of 12\n\nUser Account Password Encrypted, Not Hashed:\r\nThere’s a legacy feature for Active Directory accounts called “reversible encryption”. Normally a user’s password\r\nis hashed using the NT one-way function to create the NTLM password hash. The NTLM password hash can’t be\r\nreversed it would have to be cracked, meaning that a tool would have to be used to create passwords and perform\r\nhttps://adsecurity.org/?p=2053\r\nPage 2 of 12\n\nthe NT hash function to get the NTLM password hash. If the user’s password hash matches the generated one,\r\nthen the password was successfully guessed (known as brute force password guessing). If reversible encryption is\r\nenabled, then the user’s password is stored using encryption which means the encrypted data can be reversed back\r\nto the user’s password. The password stored with reversible encryption is not a hash since a function can be called\r\nto get back to the original clear-text password.\r\nThe next question is: once the account is enabled for reversible encryption, is the clear-text password for the\r\naccount immediately available?\r\nNo, the Domain Controllers only stores the user’s NTLM password hash, so the clear-text password is not\r\navailable. If reversible encryption is enabled on the account and the user changes the password after this\r\nconfiguration is set, then the clear-text password is saved in the Active Directory database. This occurs when the\r\nuser sends the clear-text password to the DC when changing the password (occurs over encrypted RPC).\r\nThere’s a few different ways to set an account to use “reversible encryption” which effectively has a clear-text\r\npassword in the Active Directory database (ntds.dit) on all the Domain Controllers in the domain.\r\n1. Modify the domain-linked Group Policy with the highest precedence that configures the domain password\r\npolicy so it enables reversible encryption. Modifying this GPO is much more likely to be noticed. The\r\npolicy option is Computer Configuration, Policies, Windows Settings, Security Settings, Account Policies,\r\nPassword Policy: “Store passwords using reversible encryption”. Check the box and set to Enabled and all\r\nuser accounts will have their passwords stored using reversible encryption after the next password change.\r\n2. Modify the individual user accounts to enable “AllowReversiblePasswordEncryption” by checking the box\r\nnext to “Store password using reversible encryption”. This is not very obvious and most organizations\r\nhttps://adsecurity.org/?p=2053\r\nPage 3 of 12\n\nprobably aren’t looking at this. An example of how to do this is shown in the “Defense” section at the end.\r\n3. If the Domain Functional Level is set to “Windows Server 2008” or higher, a new feature called “Fine-Grained Password Policy” is available to provide a wide-variety of password policies that can be applied to\r\nusers or groups (not OUs).\r\nI like the third option the best since it’s not obvious – no modifying a domain root-linked GPO or an admin\r\naccount directly. The only way to track this is to monitor group membership of domain-level admin accounts (and\r\nassociate with existing Fine Grained Password Policies). When group membership is actually monitored, the\r\nopposite is true: monitor the members of specific privileged groups, not the groups privileged users are members\r\nof. While Microsoft made Fine-Grained Password Policies available starting with Windows Server 2008 (DFL),\r\nthe Active Directory Administrative Center (ADAC) (which most admins still don’t use) wasn’t updated to\r\nsupport FGPP administration until Windows Server 2012. This means an attacker could configure new FGPP and\r\nthey probably wouldn’t be noticed, especially if called something benign (“Exchange users”, “SharePoint Users”,\r\netc). Enabling “Advanced Features” from the “View” menu option in Active Directory Users and Computers and\r\nthen browsing down to System, Password Settings Container (CN=Password Settings\r\nContainer,CN=System,DC=DOMAIN,DC=COM) will typically display any domain FGPP objects. Note that if\r\n“Advanced Features” is not enabled, the System container is not visible.\r\nhttps://adsecurity.org/?p=2053\r\nPage 4 of 12\n\nThe Scenario:\r\nCompromise a Domain Admin account or account with delegated rights to create Fine-Grained Password Policies\r\n(“Create msDS-PasswordSettings” objects which exist in CN=Password Settings\r\nContainer,CN=System,DC=DOMAIN,DC=COM).\r\nNote that the PowerShell cmdlets in this post are from the Active Directory module, although these are not strictly\r\nrequired for these operations, it makes it easier. HarmJ0y’s PowerView provides a lot of AD functionality in\r\nPowerShell without the Active Directory module.\r\nCreate a new group called something like “SharePont users” (misspelled on purpose so it won’t appear when\r\nadmins search for SharePoint groups) and add all domain accounts with the attribute “AdminCount” set to 1.\r\nAccounts with the AdminCount attribute set to 1 are members of certain privileged domain groups.\r\nOnce the group is created, find all AD domain accounts with AdminCount set to 1 and add them to the new group\r\n“SharePontUsers”.\r\nhttps://adsecurity.org/?p=2053\r\nPage 5 of 12\n\nCreate a Fine-Grained Password Policy (FGPP) called “SharePoint Policy” and apply to “SharePont users”.\r\nThe settings on this Fine-Grained Password Policy are interesting:\r\nComplexityEnabled: False\r\nThis determines whether the password complexity rules are required: 3 out of 4 categories including upper\r\nalpha, lower alpha, numeric, and symbols.\r\nThis should be set to TRUE\r\nLokoutDuration: 00:00:00\r\nThis determines how long the account should be locked out after the bad password attempt threshold is\r\ntriggered. 00:00:00 means the account is never locked out.\r\nThis should be set to a number if account lockout is desired.\r\nLockoutObservationWindow: 00:00:00\r\nThis determines the period during which the lockout threshold is monitored. If set to 00:05:00, the account\r\nlockout observation window is 5 minutes, so if the lockout threshold is set to 5 and there are 5 bad\r\npassword attempts in less than 5 minutes, the account is locked out.\r\nLockoutThreshold: 0\r\nThis combined with the LockoutObservationWindow determines when an account is locked out.\r\nMaxPasswordAge: 00:00:00\r\nThis determines how long a password may be used by the user. Typically this is set to a value between\r\n90:00:00 and 180:00:00 to ensure that users change their passwords at least once a year..\r\nMinPasswordAge: 00:00:00\r\nThis determines how long a new password must be kept before changing. Setting this value to 00:00:00\r\nmeans the user can change a password as frequently as they desire.\r\nMinPasswordLength: 0\r\nThis determines the minimum length of the password which effectively sets the standard password length\r\nfor all users in the domain.\r\nhttps://adsecurity.org/?p=2053\r\nPage 6 of 12\n\nPasswordHistoryCount: 0\r\nThis determines how many passwords the user must have before re-using a previous password. Typically\r\nset to 20 – 30.\r\nPrecedence: 1\r\nThis setting is specific to FGPPs since it determines which FGPP takes precedence if there are multiple\r\nFGPP applied to an account or accounts.\r\nReversibleEncryptionEnabled: True\r\nThis should be set to False. TThis sets all accounts associated with the FGPP (in this case, admin accounts)\r\nto store their passwords in clear text on the DCs at next password change.\r\nNote that the first item, “AppliesTo” is blank. Since we haven’t associated the new policy with an account or\r\ngroup, this is empty.\r\nOn to the next step: associate the new FGPP with the group we created.\r\nAfter associating the FGPP with the group, we re-run Get-ADFineGrainedPasswordPolicy to ensure it is properly\r\nassociated.\r\nThe new FGPP effectively zeros out all standard domain password security settings usually configured by the\r\nDefault Domain Policy at the domain root. should be set to False. ReversibleEncryptionEnabled sets all accounts\r\nassociated with the FGPP (in this case, admin accounts) to store their passwords in clear text on the DCs at next\r\npassword change. The clear-text password can be pulled using Mimikatz’s DCSync. Of course, initiating a\r\npassword change “this password has expired and must be set” could be fun as well.\r\nGranted, the attacker can get the hashes using Mimikatz’s DCSync feature, so why bother with clear-text\r\npasswords? Why not? 🙂\r\nClear-text passwords provide insight into password versioning and are useful for RDP access as well as other\r\n“normal” user activity while use of password hashes may be flagged as “suspicious”.\r\nNote: The fine-grained password policy could be configured directly on the user accounts, but that’s probably a\r\nlittle obvious.\r\nhttps://adsecurity.org/?p=2053\r\nPage 7 of 12\n\nAfter the FGPP is in place and the targeted user has changed his/her password, running DCSync shows the clear-text password.\r\nhttps://adsecurity.org/?p=2053\r\nPage 8 of 12\n\nRights Required:\r\nhttps://adsecurity.org/?p=2053\r\nPage 9 of 12\n\nIf an attacker gains access to an account in the Domain administrators or Domain Admins group, they have the\r\nnecessary rights for this configuration. Otherwise, here are the required rights:\r\nAction Rights Required\r\nCreate Group “Create Group object” in OU/domain.\r\nModify Group Membership “Read/Write Members” on group or OU/domain.\r\nModify User Account (enable\r\n“AllowReversiblePasswordEncryption”)\r\n“Write all properties” and “All Validated Writes” on\r\nuser objects in OU/domain.\r\nCreate Fine-Grained Password Policy (FGPP)\r\n“Create msDS-PasswordSettings objects” in the\r\nPassword Settings Container (in System).\r\nModify Fine-Grained Password Policy (FGPP)\r\n“Write all properties” on msDS-PasswordSettings\r\nobjects in the Password Settings Container (in System).\r\nUse Mimikatz DCSync to pull password data for\r\naccount.\r\n“Replicating Directory Changes” and “Replicating\r\nDirectory Changes All” (and sometimes “”Replicating\r\nDirectory Changes in Filtered Set”\r\nDefense:\r\nMonitor Fine-Grained Password Policies and the applied settings as well as who they apply to.\r\nMonitor privileged account group membership.\r\nhttps://adsecurity.org/?p=2053\r\nPage 10 of 12\n\nRegularly audit user accounts for potential issues: reversible encryption, password never expires, admin\r\naccounts that allow delegation, etc.\r\nReferences:\r\nFine-Grained Password Policies\r\nMimikatz DCSync Usage, Exploitation, and Detection\r\nPowerView\r\nhttps://adsecurity.org/?p=2053\r\nPage 11 of 12\n\n(Visited 75,709 times, 5 visits today)\r\nSource: https://adsecurity.org/?p=2053\r\nhttps://adsecurity.org/?p=2053\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://adsecurity.org/?p=2053"
	],
	"report_names": [
		"?p=2053"
	],
	"threat_actors": [],
	"ts_created_at": 1775434095,
	"ts_updated_at": 1775791260,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9e743e7d7d69d9514eb93c6875e694d2e968d0d1.pdf",
		"text": "https://archive.orkl.eu/9e743e7d7d69d9514eb93c6875e694d2e968d0d1.txt",
		"img": "https://archive.orkl.eu/9e743e7d7d69d9514eb93c6875e694d2e968d0d1.jpg"
	}
}