We manage and monitor backups for our clients and as part of our process, we perform audits to ensure backups can be restored.  Going on a tangent for a moment, the purpose of a backup is not to capture the data, the purpose is to restore data when there's data loss.  You would be surprised when the backup software reports a successful run and yet you're unable, or you have difficulty, restoring that data.  Not to get into the weeds too far, point being, it's important to test the restore function to see if your expectations and reality align.  

Back on topic.  In the process of testing the restore capability, we occasionally come across files with "password" in the title or some other title that leads us to believe a document contains passwords.  In a few previous posts, I've discussed various methods for hunting for sensitive data and cracking of various file protections.  In this post, I'm putting a couple of those together.

Typically, this situation for this type of discovery occurs on a Windows server and the file format of preference seems to be Excel.  That's the focus of this post.  

I've created a nested set of folders and in a couple of those folders, I've created two Excel documents.  One of the two documents is using Excel's native password encryption, the other is just wide open.

Taking a look at the folder structure:

This is the PowerShell script we're using to hunt for documents:






As I'm sitting here typing this out, I realize this PowerShell script is hunting inside of the files but it excludes looking at the titles.  Looking for titles would be a simple change to the script or it could simply be done with native Windows:







Regardless of how it's done, these documents have the potential for being discovered. 

Back to our script, we execute it:







During the process, we uncover a password protected file:







In yet another post, I wrote a PowerShell script to deal with this issue specifically instead of it getting hung up on the file.  Basically, because my script can't read inside of the document, it does what you would expect it to do when a user attempts to open the file -- it's asking for the password.  In my other script, it creates a list of the password protected files.  Think about that for a second -- exclude the word search for password and let's just hunt for protected files.  They might not contain passwords but they do contain something juicy.  Another topic for another day.  

With the above file hanging us up, we hit cancel and the script finishes:







When the process is complete, we get an output text file which contains the unprotected documents it discovered.  Opening the document listed in our output, we discover:








Back to our protected file, we were given the name and when we search:







We find it but it's protected -- we need to crack it.  Moving it over to a different machine, we use John the Ripper to create a password hash for cracking:







We move the hash over to our cracking machine:






In a little under two minutes, we went through 90,000 passwords from our password list and we discovered the password:  secrets

When we open the document, we discover:






Now maybe you're thinking that this process is far too easy because of the password and this would never happen to you because of your sup3rs3cret password:






Or maybe your desktop background image, or your Facebook post, or your browser history leads us to your love for your old Camaro:







Or maybe you're just really into football:






I think you get the point.  We like to believe we're being original with our passwords but if you've ever spent anytime hunting for various words through these lists, you'll quickly learn that we're not that unique.  

"But where should I store them??" -- A question we are often asked.  In a password manager!  1Password, LastPass, KeePass, or any number of other password managers.  With sensitive documents, you can also store them in your password manager or you can use encrypted containers, VeraCrypt for example.  This adoption process takes time.  It's a big leap but if you start slowly, you'll soon see the benefits.  Eventually, you'll just gravitate towards this centralized solution which is significantly more secure and actually quite easy to use.