How to Find and Replace Hardcoded Passwords in Windows and Active Directory

Why this isn't a "problem from 2009"​

It's easy to think of hardcoded passwords as old history. Recent events say otherwise. De Fremery's main example is Cisco's firewall manager. In July 2026, Cisco published its advisory for CVE-2026-20316, crediting Jimi Sebree of Horizon3.ai with the discovery of a static-credential flaw in the FMC web interface that lets an unauthenticated remote attacker log in with a hardcoded, low-privileged account and retrieve sensitive data. CISA added it to its Known Exploited Vulnerabilities catalog on July 29.

Ransomware crews then used it. According to Cloud Security Alliance research tracking Cisco Talos findings, a ransomware-as-a-service affiliate used CVE-2026-20316 for initial access, collected Active Directory and MySQL credentials, and went on to deploy Qilin ransomware. One lesson matters here beyond Cisco customers: compromise of a single FMC instance exposed Active Directory service-account credentials, database credentials, and network topology information across the perimeter it managed. A low-privilege web login turned into the domain's service-account passwords. That's the pattern this whole playbook is meant to break.

The cleanup advice has a catch too. Reporting on Cisco's guidance says affected organizations should rotate all credentials, keys, and certificates associated with the affected FMC instance, since patching alone stops future logins but does not remove any backdoor already planted. A patch closes the hole, but it doesn't make passwords that already leaked safe again.

The wider numbers point the same way. Sophos's 2026 Active Adversary Report covered 661 incident response and MDR cases handled between November 2024 and October 2025. It found that 67% of incidents were rooted in identity-related attacks, and that MFA was missing in 59% of cases. The Spiceworks piece puts compromised credentials at 42% of root causes. Sophos files that figure under credentials whose compromise method couldn't be determined, so it covers stolen credentials in general, not just hardcoded ones. The point still holds: attackers would rather sign in than break in, and an old password in a script is an easy way to sign in.

Section summary: Vendors still ship hardcoded credentials, and in-house scripts still contain them. One leaked service-account password can open up Active Directory. Patching doesn't fix exposures that have already happened.

Where the bodies are buried​

The playbook names four places to look. All of them are probably on your network right now.

• Devices with factory defaults. De Fremery cites the NSA and CISA joint advisory on the top ten cybersecurity misconfigurations. It lists default configurations, factory credentials included, among the most common problems their red teams find. Printers, scanners, VoIP phones, cameras and UPS management cards are typical examples. The advisory also warns that a device loaded with a privileged domain account (think scan-to-folder setups) can give an attacker a path into the rest of the network.
• Scripts and file shares. Old batch jobs, spreadsheets, .ps1 files and switch or firewall config backups often hold plaintext service-account passwords. Sometimes they hold domain admin passwords.
• Git repositories, including their history. Deleting a password from the current version of a file doesn't remove it from earlier commits.
• SYSVOL and Group Policy Preferences. This one is specific to Windows and needs its own section.

The cpassword problem from the Windows Server 2012 era​

Microsoft's 2014 MS14-025 write-up explains the problem plainly. Group Policy Preferences could set local administrator passwords, service and scheduled-task credentials, and drive-mapping credentials. Those passwords were encrypted with a static AES key that Microsoft had published in its own documentation. They were then written to XML files in SYSVOL, which any authenticated user can read. Microsoft said at the time that GPP abuse was among the most common ways attackers escalated privileges in a domain. Public tools such as Metasploit and PowerSploit decrypt these passwords automatically.

The MS14-025 update blocked creating or editing GPP items that contain credentials. However, Microsoft deliberately chose not to disable existing ones, to avoid breaking environments that depended on them. If an admin deployed local admin passwords through GPP in 2012, those XML files may still be in SYSVOL today. Because GPP was mostly used to set the same local admin password on every machine, one decrypted value can work on every machine in the fleet.

Microsoft released a PowerShell script called Enum-SettingsWithCpassword under KB2962486 to find affected GPOs. Run it. Delete anything it finds, and treat each finding as a credential that has already leaked.

Section summary: Check devices, shares, repos and SYSVOL. Leftover cpassword entries in an older domain are the highest-value target on that list, for you and for an attacker.

The four-pass audit, using free tools​

The playbook's audit costs nothing in licensing. It does cost time.

1. Scan repositories and script folders. Gitleaks and TruffleHog both search Git history or plain directories for secrets. TruffleHog can also check whether a credential it finds still works. Attackers know this too: the Spiceworks piece cites CrowdStrike's 2026 Global Threat Report, which describes intruders running TruffleHog inside compromised environments to harvest credentials. If you don't scan your own shares, someone else may.
2. Sweep the file shares. The same scanners work on shares. The NSA/CISA advisory also names Snaffler, an open-source tool built to search Windows networks for credentials inside documents. Point the tools at the IT drive, script archives and network-device config backups.
3. Check SYSVOL for cpassword leftovers. Run Microsoft's detection script. Any result at all counts as a live leak.
4. Test devices against factory defaults. Open the admin page of every device with a web interface you haven't touched since installation and try the documented default login. While you're there, confirm the interface isn't reachable from the internet.

Some cautions the cheerful version skips​

• Get authorization first. Running credential scanners across shares looks exactly like attacker reconnaissance, and EDR tools may flag it. Tell the system owners and your SOC before you start.
• Lock down the results. A scan report is a list of working passwords, so it's now one of the most sensitive files you have. Don't paste findings into tickets or chat.
• Only verify credentials you're authorized to test. TruffleHog's verification actually tries the credential against the service. Keep it to your own systems.
• Deleting the text doesn't fix the exposure. If a secret was committed, backed up or readable by others, rotate it and check how it was used.

Section summary: Four passes cover most environments. Treat the scan output as sensitive material and the findings as security incidents, not just tidying.

Replacing hardcoded passwords with credentials that manage themselves​

Once you have the list, every credential on it needs a better home. Windows has built-in answers for the two most common categories.

Shared local admin passwords → Windows LAPS​

According to Microsoft Learn, Windows LAPS automatically manages and backs up a local administrator password on each Microsoft Entra-joined or Active Directory-joined device. It rotates the passwords and limits who can read them. It's built into Windows and costs nothing. Backing up to AD has no extra licensing requirement, and backing up to Entra ID needs Entra ID Free or higher.

Some details matter in practice. A device can back up its password to Entra ID or to AD, but not both. Workplace-joined devices aren't supported. Legacy Microsoft LAPS is deprecated, and its installer is blocked on Windows 11 23H2 and later. Legacy emulation mode stores passwords in AD in clear text, so Microsoft describes it as a temporary step only. If you're still running the old MSI, migrating is now part of this cleanup.

Service accounts in scripts → gMSA (or dMSA)​

For domain services, Microsoft's service-account documentation describes group managed service accounts. With a gMSA, the domain controller computes the password and authorized hosts retrieve it automatically, so no admin types it and no script stores it. The default rotation interval is 30 days. The interval can only be set when the account is created and can't be changed afterwards. Windows Server 2025 adds delegated managed service accounts (dMSA). These can replace an existing traditional service account and disable its old password, tying authentication to specific machine identities.

Be honest about the limits. Not every application supports managed service accounts, and a gMSA won't help with a firewall admin login or a vendor portal password. Everything that doesn't fit belongs in a password manager or secrets vault, not a .ps1 file. The playbook doesn't recommend a specific vault, and neither do we. The right choice depends on your environment.

Section summary: Use LAPS for local admin accounts, gMSA or dMSA for services that support them, and a vault for everything else.

The painful part: rotation breaks things​

The Spiceworks playbook admits that nobody enjoys this step. Every password you change can break a script or service you forgot was using it. It points to a Spiceworks Community discussion about retiring a server that reached the same conclusion: the hard part is finding everything that depends on it.

A practical order of work, based on general industry practice:

1. Start with privileged and reused credentials, such as anything with domain admin rights or a local admin password shared across machines.
2. Map what depends on each one, including scheduled tasks, services, app pools and mapped drives, before you rotate it.
3. Rotate, update each consumer, then confirm the old value no longer works.
4. Write down where each credential now lives.

Is it worth the downtime risk? The playbook cites GitGuardian research finding that nearly 70% of credentials confirmed valid in 2022 still worked in January 2025. Leaked secrets don't expire on their own.

Making it a habit​

The playbook ends with prevention. Change default passwords before a new device even gets an IP address. Put service-account credentials in the vault on day one instead of in the code. Rerun the scanners once or twice a year. That cadence is de Fremery's suggestion, not a standard, and fast-changing environments should scan more often. Adding secret scanning to code review and credential checks to device onboarding and decommissioning makes the audit routine instead of a one-off project.

For WindowsForum readers, the takeaway is that you can't patch a vendor's hardcoded password yourself, but you can control everything around it. The Cisco FMC case showed how much damage follows when attackers get in and find credentials that were never rotated. Do the audit, and the next vendor slip-up means patching one product rather than wondering where else your passwords are stored.