{
	"id": "83e370ce-e789-4633-ac5e-898c0b4e8637",
	"created_at": "2026-04-06T00:07:41.877711Z",
	"updated_at": "2026-04-10T03:21:52.821851Z",
	"deleted_at": null,
	"sha1_hash": "f5235a55e21b8facad388f3809230c65b2895dfe",
	"title": "Passwords stored using reversible encryption: how it works (part 2)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 34402,
	"plain_text": "Passwords stored using reversible encryption: how it works (part\r\n2)\r\nArchived: 2026-04-05 23:42:24 UTC\r\nIn part one of this article, I described how the reversible encryption of Windows domain passwords works. In this\r\npart, we will look at the security of this mechanism.\r\nTo decrypt the password you need the following components:\r\n- The encrypted password (G$RADIUSCHAP)\r\n- The 16 byte random (G$RADIUSCHAPKEY)\r\n- The global LSA secret (G$MSRADIUSCHAPKEY)\r\n- A static key hardcoded in RASSFM.DLL\r\nThe hardest thing to get is that global LSA secret. This is stored in active directory and synchronized between\r\ndomain controllers. To access this key, you need domain administrator privileges. An obvious risk here is that\r\nonce someone gains domain administrator privileges, he won’t need to crack any passwords, but can simply\r\ndecrypt them. Of course, if an attacker gains domain administrator privileges on your domain, you are already in\r\nbig trouble anyway.\r\nHowever, the other components are all semi-public information. The static key is hardcoded in RASSFM.DLL\r\nwhich comes with every Windows server, so is easy to get. The G$RADIUSCHAP and G$RADIUSCHAPKEY\r\nare stored in active directory in the userParameters structure. If you have a user account on a domain you can use\r\nAD Explorer to access the Active Directory database and read this information. Of course, to decrypt the password\r\nyou will still need that LSA secret.\r\nThe encrypted version of the password can be interesting though; by looking at the encrypted password you can\r\nderive the length of the plaintext password. Two examples I used in my presentation:\r\nPwd1 encrypted: 0f53 8420 9418 05ce 01ad\r\nPwd12 encrypted: 5d69 9375 6f92 1b63 7728 439f\r\nSo, by looking at the encrypted passwords you should notice that the encrypted version of Pwd12 is two bytes\r\nlonger than the encrypted version of Pwd1. So, although we cannot determine from just looking at the encrypted\r\npassword that they are very similar, we can determine their length. What this means is, that as a domain user, you\r\ncan determine the length of other people’s passwords, which could be quite interesting.\r\nIf you obtain the LSA secret somehow (maybe because you temporarily gain domain administrator privileges),\r\nfrom that point on you can decrypt passwords stored using reversible encryption. This could be used as a nice\r\nbackdoor, just steal the LSA secret, enable reversible encryption (if it hasn’t been enabled yet) and you can grab\r\nthe domain administrator password with just a normal user account.\r\nhttp://blog.teusink.net/2009/08/passwords-stored-using-reversible_26.html\r\nPage 1 of 2\n\nSomeone in the HAR 2009 audience had a very nice question: Is it possible to recreate the LSA secret if you’re\r\nafraid it has been stolen. Of course the better option is to recreate the entire domain, but this is not always an\r\noption. To recreate the LSA secret you need to write a program that sets the LSA secret to NULL. According to the\r\ndocumentation, Windows will delete the LSA secret. It will generate a new LSA secret when it needs to encrypt\r\nanother password. Of course, Windows won’t be able to decrypt the passwords stored before that point anymore.\r\nHowever, it will still try to decrypt them using the new LSA secret, which will result in gibberish most of the time.\r\nIf you’re really unlucky it could decrypt the first two bytes to NULL, which basically means the password is\r\nsuddenly empty. So if you ever have to do this, resetting all passwords immediately is probably a good idea.\r\nSource: http://blog.teusink.net/2009/08/passwords-stored-using-reversible_26.html\r\nhttp://blog.teusink.net/2009/08/passwords-stored-using-reversible_26.html\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"http://blog.teusink.net/2009/08/passwords-stored-using-reversible_26.html"
	],
	"report_names": [
		"passwords-stored-using-reversible_26.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434061,
	"ts_updated_at": 1775791312,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f5235a55e21b8facad388f3809230c65b2895dfe.pdf",
		"text": "https://archive.orkl.eu/f5235a55e21b8facad388f3809230c65b2895dfe.txt",
		"img": "https://archive.orkl.eu/f5235a55e21b8facad388f3809230c65b2895dfe.jpg"
	}
}