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. The walkthrough locates it under /var; on macOS 10.15 and later, mutable system data lives on the APFS Data volume. FileVault encrypts the volume, so an offline reader still needs access to an unlocked volume or recovery material.

The walkthrough takes the live route: sudo on a running Mac. The other is reading the file from the disk, which requires the volume to be unlocked, FileVault to be off, or access to recovery material. 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. NIST's verifier guidance requires at least 15 characters for a single-factor password and a blocklist of commonly used, expected, or compromised values. Translate that into the local-account policy your fleet can actually enforce.

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 alongside the parser caveat above. 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. For the complementary case where a user-session stealer gets credentials without local admin, see the CrashStealer response path.

Sources

Sources retrieved 2026-07-29. The lab details remain attributed to the researcher's walkthrough; platform controls trace to Apple and password-verifier guidance to NIST:

← Back to Field Notes