Why a published encryption key isn't really encryption

Group Policy Preferences' cpassword scheme technically used real AES-256 encryption, but the key was published by Microsoft itself in the MS-GPPREF protocol documentation, meaning anyone with the ability to read that public documentation — which is to say, anyone — has always had everything needed to decrypt any cpassword value. This is a textbook case of "security through obscurity failing the moment the obscurity is gone": the cryptographic operation was sound, but keeping the key fixed and published defeats the entire purpose of encrypting in the first place. Microsoft eventually addressed this via MS14-025 by removing the ability to set credentials through GPP at all, but that patch didn't retroactively scrub existing GPOs, backups, or SYSVOL exports.

Why this remains a live finding in real assessments

Because MS14-025 only prevented creating new GPP credentials rather than removing old ones, environments that used this feature before 2014 and never specifically went back to purge their GPO history can still have a live cpassword sitting in Groups.xml, Services.xml, or ScheduledTasks.xml inside SYSVOL — often readable by any authenticated domain user, since SYSVOL is broadly readable by design. Finding one during a security assessment or internal audit isn't a hypothetical risk exercise; it's decrypting a genuinely valid, currently-set local account password in seconds. That's exactly why this tool exists — to make confirming and remediating that exposure in your own environment as fast as an attacker would find it, rather than treating it as a theoretical historical vulnerability.