Introduction

In a previous article (Protecting your Veeam Backup and Replication Server is critical | Working Hard In IT), I discussed my script for decrypting the datacenter credentials from the Veeam Backup & Replication database. Since then, that PowerShell code has been published dozens of times all over the internet in various articles.

However, three relevant things have changed since my original blog post:

1. Veeam v12.1 introduced a new encryption method.
   Firstly, in Veeam 12.1, the method of encrypting passwords has changed. That means the old script no longer works (always) as it only uses the legacy method.
2. Veeam published its encryption and decryption methods.
   Secondly, Veeam has published the methods used to encrypt and decrypt passwords in the spirit of full disclosure and to preempt anyone who attempts to claim that Veeam is insecure. Those individuals or companies demonstrate only ignorance and malicious intentions. The good news is that the article has all the information we need to write a new script.
3. Veeam now supports PostgreSQL, in addition to Microsoft SQL Server.
   Finally, Veeam now also supports MySQL as a database, in addition to Microsoft SQL. That means we need to ensure that we can retrieve the necessary data from both database types.

Background Info & approach

I based the script on information found in the Veeam KB article “How to Recover Account Credentials From the Veeam Backup & Replication Database” (https://www.veeam.com/kb4349).

Instead of having two scripts, my old one and a newer one. I decided to create one that would work on VBR v12 and lower, as well as on VBR 12.1 and higher.

What Changed in Encryption

Until version 12, Veeam used its internal .NET static method:

[Veeam.Backup.Common.ProtectedStorage]::GetLocalString($encryptedPassword)

That method leverages the native Microsoft Data Protection API (DPAPI) under the hood. It was part of the Veeam.Backup.Common.dll and worked well up to version 12. In v12.1 and beyond, this method no longer exists. Instead, Veeam now leverages the native Microsoft Data Protection API (DPAPI), directly:

[System.Security.Cryptography.ProtectedData]::Unprotect($bytes, $salt, ‘LocalMachine’)

Since both leverage the native Microsoft Data Protection API, I figured I could also use the [System.Security.Cryptography.ProtectedData]::Unprotect static method to decrypt those legacy passwords as long as I don’t try to leverage the optionalEntropy parameter for them. The good news is that in the KB article, Veeam provides instructions on how to differentiate between the legacy and new types of password encryption. That allows me to write logic to determine the version and execute the corresponding decryption method accordingly.

By the way, once you update a password on v12.1 or up, it will be encrypted with the new method. As time passes, by rotating the passwords, legacy encryption phases out.

The new script

I did not want to maintain two separate scripts, one for the legacy password decryption method and one for the newer one. That’s why  I’ve consolidated everything into a single, unified PowerShell script. It supports:

• Supports VBR v10 through v12.3+ and decrypts Veeam credentials from registry and database.
  • The Veeam Backup & Replication encryption salt in the registry lives here: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\Data.
  
  
• • The Veeam database info in the registry lives here:
    Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\DatabaseConfigurations\
    
• Per-user counters and clean output formatting
• Supports MSSQL and PostgreSQL configurations
• Handles multiple password formats:
  • ‘v12 and lower’
  • ‘v12.1 and up (with encryption salt)’
• Optional filtering by username
• Optional export to file (`Veeam_Credentials.txt` on Desktop)
• Graceful error handling and informative console output
  

The script runs on Windows only, because DPAPI is a Windows-native feature. With VBR v13 introducing Linux-based deployments, this script won’t work in those environments. That’s a different challenge for another day.

Getting the script

You can find the script on GitHub at https://github.com/WorkingHardInIT/Revised-script-for-decrypting-datacenter-credentials-from-the-Veeam-Backup-Replication-database. You will also find the documentation there.

Why do I need this script?

The IT world, like everywhere else, is not a perfect place, and I need a way to deal with imperfection. It is that simple. If we are honest, we all know that  IT environments aren’t always in pristine condition. Whether it’s a lab, a forgotten backup server, or an entire backup fabric for a production environment abandoned by a previous IT partner, credentials are often missing. Documentation is sparse. And when disaster strikes, you need access, fast.

My script has already helped IT teams recover access to critical systems when no one else could. I know because I’ve seen it happen. Before Veeam ever published its KB article, my original script was quietly saving the day in real-world scenarios.

Conclusion

Knowledge is power. And while power inherently allows abuse, hiding knowledge under the guise of “security” is just security theater. Security through obscurity is not security but window dressing.

That’s why I’m glad Veeam documented their credential encryption methods. It empowers administrators to recover access responsibly. And it exposes the charlatans who twist transparency into baseless accusations of insecurity. I just felt compelled to create a handy, functional script around it that I can use when needed.

If someone uses this information to claim Veeam is irresponsible, they could not be more wrong. They prove themselves to be untrustworthy. To me, they’ve lost their reputation and credibility.

This script isn’t about hacking. It’s about recovery, accountability, and clarity. And if it helps you regain control of your environment when all else fails, then it’s done its job.