Corporate Batch Recovery: Unlock 100+ Excel Files at Once

The enterprise scale problem

Password-protected Excel files accumulate in corporate environments for many reasons: departing employees did not document their passwords, departmental shared passwords are lost when the team restructures, legacy document management systems apply a blanket password on exported files, or M&A integration brings in thousands of files from an acquired company with unknown protection.

At scale (100+ files), the manual approach — open each file, identify protection type, apply the appropriate removal — becomes impractical. A single batch recovery pipeline can process hundreds of files overnight with minimal human intervention.

The first step is always classification: separate files by protection type (structural vs file-open encryption) and by encryption generation. Office 97-2003 files use RC4 (modes 9700/9800); Office 2007 and Office 2010 use AES-128 with a SHA-1 key derivation (modes 9400 and 9500); Office 2013 and later — including 2016, 2019, 2021, 2024 and 365 — all use the same AES-256 with SHA-512 scheme and are cracked as mode 9600. Attempting the wrong technique wastes time or corrupts files.

Batch structural removal — sheet and workbook protection

Sheet protection and workbook structure protection are the easiest to batch-remove because they are XML elements inside a ZIP archive. The approach: iterate through all .xlsx files, unzip each, delete the relevant XML elements, rezip.

A Python script using the zipfile and xml.etree.ElementTree modules handles this reliably. The script opens each .xlsx (which is a ZIP), parses the relevant XML files, removes the <sheetProtection> and/or <workbookProtection> elements, and writes back the modified ZIP. Full processing time per file is under a second.

For .xls (legacy binary) files with structural protection, the approach is different: use a hex editor script (or an OLE-aware tool) to locate and patch the protection bytes in the OLE2 compound document. The patch itself is instant — the runtime is dominated by reading and rewriting the container, so budget a few seconds per file for a naive script and less for one that patches the stream in place.

Critical: always process on copies, not originals. A single byte error during XML patching can corrupt the ZIP structure. Processing on copies with a verification step (open each output file and check that protection is removed) prevents data loss.

Batch VBA project password removal

VBA project passwords are also batch-removable. Each .xlsm contains a vbaProject.bin part inside the ZIP archive, and the PROJECT stream inside that part holds the ID/CMG/DPB/GC protection values — DPB is the obfuscated password verifier. A script can extract the part, replace the obfuscated DPB value (ideally the ID/CMG/DPB/GC set together, since they are keyed to the project ID) and put it back in the archive.

A legacy .xls is an OLE2 compound file, not a ZIP: it contains no vbaProject.bin part, and its VBA project lives in the _VBA_PROJECT_CUR storage, which has to be patched at the compound-document level. A Python script that walks a directory can handle both cases using an OLE-aware library, replacing the obfuscated DPB value (or the whole ID/CMG/DPB/GC set) and writing the file back.

For very large batches (10,000+ files), parallel processing with multiprocessing or a thread pool brings total runtime down to minutes. The operation is CPU-bound per file (each requires decompression or container rewrite, a binary edit and recompression) but scales linearly with core count.

Batch cryptographic recovery — file-open passwords

For files with file-open encryption (real encryption, not structural), batch recovery requires hashcat or a professional GPU service. Hashcat cracks a hash file containing many hashes in a single run: extract the hash from each file (using office2john from the John the Ripper suite), concatenate them into one hash file, and point hashcat at it. There is no 'batch mode' option to enable — multi-hash cracking is simply how hashcat works.

A single hashcat run on a batch of hashes is more efficient than running it separately per file. Hashcat cracks all hashes simultaneously in a single pass through the candidate list, which means weaker passwords in the batch are found early even if stronger ones take longer.

The challenge is that a batch of files likely has multiple different passwords. Hashcat handles this natively — it reports which hash (which file) was cracked by which candidate. You can split the batch: run a fast dictionary+ rules pass first (catches common passwords across the batch), then escalate each uncracked hash to individual mask attacks based on its specific password hints.

Enterprise recovery workflow architecture

A production batch recovery pipeline for an enterprise typically has four stages:

• Stage 1 — Inventory and classification: walk the file tree, classify each file by extension (.xlsx, .xlsm, .xls) and protection type. Output a CSV with file path, protection type, hash mode (if encrypted), and file size.
• Stage 2 — Structural removal: apply batch XML edit (for .xlsx) and oletools patch (for .xls) to all structurally protected files. Verify each output file opens correctly in a headless Excel-like validator.
• Stage 3 — Hash extraction: for remaining encrypted files, run office2john to extract hashcat-compatible hashes. Group the output by hash mode — 9400 = Office 2007, 9500 = Office 2010, 9600 = Office 2013 and later, 9700/9800 = Office 2003 and earlier — for efficient batch cracking. (The Office 2016-specific mode 25300 applies to sheet-protection hashes only, not file-open encryption.)
• Stage 4 — GPU cracking: run hashcat against the combined hash file, starting with dictionary + rules, then a Markov-driven mask attack, then plain masks; if a PCFG guesser such as pcfg_cracker is available, pipe its candidate stream in as an additional pass. Flag files that remain uncracked after exhaustive search for human review or professional escalation.

Tools and scripts for enterprise batch recovery

Python ecosystem: openpyxl (reading .xlsx metadata), zipfile + ElementTree (XML structural removal), oletools (binary .xls and VBA handling), office2john (hash extraction). For large file trees, os.walk or pathlib for directory traversal, concurrent.futures for parallelism.

Linux utilities: hashcat (GPU cracking), john (alternative cracking), unzip/zip (command-line ZIP manipulation), sed or xmlstarlet (command-line XML editing for simple cases).

For Windows-centric enterprise environments: PowerShell can handle ZIP manipulation and XML editing natively, though Python is more reliable for binary patching. Windows Subsystem for Linux (WSL) provides access to hashcat and John the Ripper.

Commercial enterprise tools: professional recovery services offer batch processing where you upload a ZIP of encrypted files and receive a report of recoverable passwords. This is the easiest option for IT departments without GPU infrastructure.

When to outsource vs build in-house

Build in-house if: you have a regular pipeline (monthly+ batches), your IT team includes someone comfortable with Python and hashcat, you have GPU hardware (even a single RTX 4090) or cloud GPU budget, and most files are structurally protected (cheap and fast to process).

Outsource if: this is a one-time or occasional cleanup, most files have file-open encryption (real AES), you lack GPU hardware or expertise, or the data is not sensitive enough to justify building infrastructure. Providers commonly offer batch and recurring-contract pricing, but terms vary — ask before uploading files one by one, and prefer pay-on-success arrangements.

Hybrid: do structural removal in-house (XML edit is trivial and free), then send only the remaining encrypted files to a professional service. This minimizes cost while retaining control over the easy-to-process files.

Setting up a batch recovery pipeline

1. 1

   Inventory all files

   Walk the directory tree. Separate by extension (.xlsx, .xlsm, .xls, .xltx) and file age. Back up everything before processing.

2. 2

   Classify protection type

   Test the container, not the ZIP listing: a structurally protected .xlsx/.xlsm opens as a ZIP with readable XML, while an encrypted one is not a ZIP at all — it opens as an OLE2 compound file holding a single EncryptedPackage stream alongside an EncryptionInfo stream. A file that is neither is a candidate for corruption or an old format.

3. 3

   Run batch structural removal

   For all structurally protected .xlsx files: unzip, delete <sheetProtection> and <workbookProtection>, rezip. Verify each output file with a quick open test.

4. 4

   Extract hashes for encrypted files

   Run office2john on all remaining .xlsx/.xls files. Group the output by hashcat mode: 9400 = Office 2007, 9500 = Office 2010, 9600 = Office 2013 and later, 9700/9800 = Office 2003 and earlier.

5. 5

   Run hashcat on the batch

   For each mode group, run hashcat against the concatenated hash file with dictionary + rules as the first pass — there is no 'batch mode' switch to enable. Escalate uncracked hashes to a Markov-driven mask attack, then plain masks, or to a professional service.

Frequently Asked Questions

Related Reading