The hash is fine. The password isn't: defending against a local Mac crack

R Rob Flanagan · Jul 2026 · 3 min read

A researcher's walkthrough copies a local Mac's password verifier and cracks it offline with hashcat. The attack runs in two stages, and a control you already manage sits on each one.

A security researcher published a lab walkthrough for pulling a local Mac account's password hash and cracking it with hashcat. The hash sits on the machine, and macOS ships the tools that extract it. If you manage Macs, skip the alarm and read it for structure, because the attack runs in two stages and a different control sits on each one.

An attacker first copies the stored verifier, then guesses against that copy offline. So your preventive controls have two jobs: stop the copy, or make guessing cost more than the attacker is willing to spend. Do either one well and this route dead-ends.

Stage one: getting the record

The first stage is just getting hold of the account record. On macOS 10.15 and later it sits under /var on the APFS data volume, and FileVault keeps that volume locked until someone unlocks it with a login credential or a recovery key. That leaves two ways in.

The walkthrough takes the live one: sudo on a running Mac. The other is reading the file straight off the disk, which only works if the volume is already unlocked or FileVault was off to begin with. Power the machine down with FileVault on and that door stays shut. On a running Mac, a standing admin account is an easy way to reach the live route; a standard-user session sitting unlocked is not.

Stage two: the guessing, and why it stops being scary

Then comes the guessing. In the walkthrough, that one account's verifier was salted PBKDF2-HMAC-SHA512 at 158,730 iterations, a stored cost that varies from one account and macOS version to the next, so the attacker pays it on every guess. Whether they ever land depends on whether the real password fits their budget, and the weak choices go first. Pick a passphrase nobody would guess and you can push the search past that budget even after they have the hash. That is the researcher's own takeaway, not mine.

One detail in the walkthrough has aged out, and it is worth knowing before you follow along. It presents trimming the stored entropy down to 128 hex characters as a step you have to take before hashcat will accept the hash. Current mode 7100 takes either 128 or 256 characters and decodes the first 128 itself, so that trim is optional now. The module source settles it: if ((hash_len != 128) && (hash_len != 256)) return (PARSER_HASH_LENGTH);. Nothing else in the attack changes, and neither does a single control below.

The controls sort themselves by stage

For getting the record, I lean on FileVault pushed through MDM with the recovery key escrowed, and I guard access to that escrowed key, because as long as the volume stays locked the readable-disk route is dead. Keeping people off local admin, controlling elevation, and short lock timeouts help too, but only against the live route. None of it slows an attacker who already has root.

The guessing half is all password. Once the verifier is copied, how guessable the password is becomes the only thing the user still controls, and the stored KDF cost and the attacker's hardware set the rest. So enforce length and screen out passwords already known to be compromised, which is where NIST's guidance has landed: favor length, block known-bad values.

I treat these as baseline controls for a managed Mac fleet. This walkthrough is a good reason to confirm yours are actually enforced, not just written down. The extraction chain is what makes the layers obvious, which is why it is worth reading in full. A false sense that the hash format alone protects you is the gap; the hash is fine, and the password is the part you still have to get right.

Sources

The attack is the researcher's own published walkthrough; the defenses trace to Apple's platform-security docs and NIST guidance:

← Back to Field Notes