Office 2007 OOXML AES-128 — Hashcat Mode 9400
TL;DR — Office 2007 introduced the OOXML format (.docx, .xlsx, .pptx) — ZIP containers with XML inside. The encryption moved to AES-128 in CBC mode, with SHA-1-based key derivation iterated 50,000 times. The cipher itself is sound; recovery feasibility depends entirely on password complexity.
What changed with Office 2007
Microsoft Office 2007 introduced two major changes: a new file format (OOXML, formalised as ECMA-376) and a redesigned encryption scheme. OOXML files are ZIP containers — open one with 7-Zip and you'll see XML files inside that describe document content, formatting, relationships, and embedded media.
When password protection is enabled, the entire OOXML structure is wrapped in an OLE2 container with the encrypted content stream. The encrypted content uses AES-128 in CBC mode by default. Microsoft calls this 'Standard Encryption' and documents it in [MS-OFFCRYPTO] specification section 2.3.4.5.
Office 2007 also introduced 'Agile Encryption' as an option (extensible XML-driven encryption metadata), but the default for Office 2007 password-protected files is the Standard scheme — Hashcat mode 9400.
- File extensions: .docx, .xlsx, .pptx
- Container: OLE2 wrapping ZIP+XML
- Cipher: AES-128 in CBC mode
- KDF: SHA-1, 50,000 iterations
- Encryption type: Standard Encryption
The 50,000-iteration KDF
Office 2007 was the first Microsoft format to use a meaningfully iterated KDF. The password is hashed with SHA-1, mixed with a per-document salt, and iterated 50,000 times. The 50,000-round figure was a deliberate cost choice — high enough to slow brute-force per-attempt, low enough to keep legitimate file open times under a second.
By 2026 standards, 50,000 SHA-1 iterations is considered low — modern recommendations (PBKDF2 in NIST SP 800-132, scrypt, Argon2) suggest 100,000+ iterations. So per-second password verification rates on modern GPUs are still very high, which means recovery feasibility is governed primarily by password complexity, not by KDF cost.
Why mode 9400 reduces to password strength
AES-128 has 2^128 possible keys — a search space that no realistic compute budget can address. Specialised attacks on full-round AES-128 don't exist in 2026, so the cipher is effectively unbreakable by brute force.
Recovery operates exclusively at the password layer. A candidate password runs through the SHA-1×50000 KDF, the resulting AES key decrypts a known portion, the verifier hash matches if the password was correct. This is the same fundamental shape as any modern password-protected format.
Practical implication: a 6-character lowercase-only password is recoverable in seconds (26^6 = 308M candidates × 50000 iterations = tractable on a single GPU). A 14-character random password from a manager is effectively secure against any feasible compute budget. Password complexity decides everything.
Identifying mode 9400 files
File extension is a strong hint: .docx, .xlsx, .pptx with a password prompt → likely mode 9400 if the file was created in Office 2007 or by any tool that used Office 2007's default encryption settings.
Open the file in 7-Zip or any ZIP browser. If it opens as a ZIP archive with [Content_Types].xml visible, it's not password-protected. If it shows a single 'EncryptedPackage' file inside an OLE2 container, it's encrypted — and the EncryptionInfo stream tells you exactly which mode.
Tools like msoffice-crypt or office2john (John the Ripper) extract the password hash without needing the password. The output starts with `$office$*2007*` for mode 9400 (the *2007* is the version marker).
Office 2007 vs Office 2010+
Office 2010 introduced two changes: AES-128 KDF iterations rose from 50,000 to 100,000 (mode 9500), and a new 'Agile' encryption option allowed AES-256 with arbitrary KDFs. By Office 2013, the default was AES-128 with SHA-512-based KDF (mode 9600).
Newer modes are categorically harder to recover than mode 9400, primarily because of higher KDF iteration counts. Same cipher (AES); same overall design; just slower per-password verification.
When to attempt recovery
Recovery is realistic when the password is short, predictable, dictionary-based, or when the file owner remembers significant fragments. Without any hint, only common-pattern attacks remain feasible.
We do not publish recovery rates because they vary so much with password type. The honest position: tell us what you remember about the password's structure, run a free check, decide on a paid attempt based on real signal from the free phase.
Frequently Asked Questions
How does mode 9400 compare to mode 9500?
Can I tell from file extension alone?
Will I lose VBA macros after recovery?
Is there any cipher-level attack on AES-128?
Why is the KDF iteration count so important?
What about Office for Mac files?
What if my file was created by LibreOffice?
Related references
Have a file in this category?
Start with a free analysis. The encryption type is detected in your browser, then a free check runs through fast techniques before any paid attempt. You only pay if a recovery actually works.
Run a free Office analysis