Active Directory Password Audit

For the ones that crack, yes — and we would rather say so plainly than dress it up. There is no way to measure whether a password would survive a real attack without running that attack and recovering the plaintext. What matters is what happens next. A named, restricted team handles the material on encrypted, isolated systems; the analysis you receive is presented statistically and by pattern; and the report's privacy mode places usernames and recovered passwords in separate tables rather than one name-and-password roster, so it can be circulated to the people who need to act without becoming a list of individual colleagues' passwords. That is a circulation and dignity control, not true anonymisation — your security staff can still cross-reference the tables to reset a specific account, which they need to be able to do. We are explicit about that limit rather than overselling it.

They are extracted from a domain controller or a recent system-state backup, which requires directory replication rights — so unlike our Active Directory Security Audit, this one genuinely does need privileged access. We prefer your own team to perform the extraction under our guidance, so the credential material never leaves your control until it is already encrypted. Transfer is over an encrypted channel to a named recipient, agreed in writing before anything moves, and never by email attachment.

The hashes, the recovered plaintexts and every intermediate working file are securely destroyed once the report is delivered and you have confirmed receipt. They are not retained for benchmarking, not fed into a wordlist for the next client, and not kept 'in case you want a comparison next year' — if you want a year-on-year comparison we re-run the audit from a fresh extraction. Destruction is confirmed to your named data owner in writing.

Because the policy is the floor, and people build directly on top of it. A fourteen-character minimum with complexity is satisfied perfectly by Summer2026!!! — and by the same construction across half your organisation. The gap between what a policy permits and what people choose is the entire finding, and the only way to measure it is to attack the hashes.

It is the usual pairing, and the combination is stronger than either alone: the directory audit establishes who holds privilege and where the escalation paths are, and the password audit establishes whether the credentials guarding them would hold. Recovered passwords are matched back against the enumerated accounts, so a cracked password on a Tier 0 account is reported as exactly that. See /services/active-directory/.

Critical findings are reported to your named contact immediately, during the engagement rather than in the report, so the account can be reset the same day. A cracked privileged account is the clearest example of that — we do not sit on it for the sake of a tidier write-up.