Pass-the-hash and credential replay

Objective 4.2 in this course covers authentication attacks — CompTIA names brute-force, pass-the-hash and credential stuffing. Lesson 25 took the guessing attacks; this is replay, and it is the applied lab for the objective. Runs between two machines you built, in the lab from lesson 2.

Why this matters

CompTIA names pass-the-hash explicitly, so it is examinable by name. It is also the technique that most changes how people think about passwords, because it severs the link between knowing a password and using one.

Once you understand it, a great deal of enterprise security design makes sense: tiering, credential guard, restricted admin modes and the advice never to log in to a workstation with domain administrator credentials all exist because of this.

The lesson

Why a hash is a credential

Many authentication protocols never send the password. Instead the client proves it knows the password by performing a calculation with a stored derivative of it — a hash — and the server checks the result.

The consequence is the whole lesson: if the protocol only ever uses the hash, then possessing the hash is sufficient. You do not need to crack it, reverse it, or learn the password. The hash is not a protected form of the credential; for that protocol, it is the credential.

This is why "the passwords are hashed, so we're fine" is wrong in this context. Hashing protects the password against being read and reused elsewhere — which matters for the reuse in lesson 25 — but it does not protect the system whose protocol accepts it.

Where hashes sit in memory and on disk

To replay a credential you must first obtain it, and there are a few places it lives:

• In memory on a machine the user has logged into. Single sign-on requires the system to retain something reusable, so a host holds material for every account currently or recently signed in. This is why compromising one workstation can yield an administrator's credential.
• In the local account database on the host.
• In the directory database on a domain controller, which holds every account and is therefore the highest-value target in the environment.
• On the wire, in challenge-response exchanges that can be captured and either relayed live or cracked offline.
• In backups of any of the above, which are frequently protected far less carefully than the systems themselves.

Extracting any of it requires administrative rights on that host, which is why this lesson follows privilege escalation in practice even though it precedes it in the plan: pass-the-hash is usually how you turn one compromised machine into many, not how you get the first one.

Replay across hosts, and the trust that permits it

The reason a captured credential works elsewhere is that the accounts are shared across hosts, and the second host has no way to tell a replayed proof from a genuine one.

Two patterns make this devastating in practice:

• A shared local administrator password across many machines. Recover it once and every machine that shares it is reachable. This is the single most productive finding of its kind in enterprise testing.
• Domain accounts used everywhere. An administrator who logs in to a workstation to fix something leaves reusable material on that workstation. Compromise it later and you inherit their reach.

The instinct to build: credentials flow downhill from wherever they are used. Using a powerful account on a weak machine exposes it to whoever owns that machine, now or later. That is the whole argument for tiering.

Demonstrating it between two machines you built

The applied lab for objective 4.2, on two lab hosts from lesson 2, with accounts and passwords you chose.

1. Build two machines sharing a local administrator password, which is the condition you are demonstrating.
2. Compromise the first by any route — you already have one from lesson 24.
3. Obtain the stored credential material for that account.
4. Authenticate to the second machine using it, without ever knowing the password.
5. Read both machines' logs, which is where the lesson is.

The thing to notice in step 5: on the second machine, the logon looks normal. A successful authentication by a valid account. There is no "invalid credential" event, because the credential was valid. That is what makes this hard to detect and what makes the remediation structural rather than a matter of alerting.

Then change one variable — give the machines different local administrator passwords — and watch the attack stop working. Demonstrating the fix is what turns the exercise into a finding with a recommendation attached.

The controls that actually stop it

Worth knowing precisely, because the obvious answers do not work and the exam tests that.

Does not help: a longer password (the hash is used, not the password); complexity rules; frequent rotation, unless it is fast enough to beat the attacker, which it rarely is.

Does help:

• Unique local administrator passwords per machine, managed automatically. This single change removes the most productive version of the attack.
• Tiering. Administrative accounts for servers never log in to workstations, so their credentials never reach a weaker machine.
• Protecting credential material in memory, with the platform features built for it, so an administrator on the host cannot simply read it out.
• Restricted administrative logon modes that avoid leaving reusable material on the target host.
• Multi-factor authentication for interactive administrative access.
• Monitoring for the shape — the same account authenticating to many hosts in a short window, or an administrative account appearing on a workstation.

What to take into the exam

• If a protocol authenticates with the hash, the hash IS the credential — no cracking required.
• Credential material sits in memory on hosts users log into, in local and directory databases, on the wire, and in backups.
• A shared local administrator password across machines is the most productive version of this finding.
• Credentials flow downhill: using a powerful account on a weak machine exposes it. That is the argument for tiering.
• Longer passwords, complexity and rotation do not stop it; unique per-machine local passwords, tiering, in-memory credential protection and restricted admin logon do.
• A replayed logon looks like a normal successful authentication, which is why the remediation is structural rather than alert-based.