13 — Credential and Active Directory Attacks

Level: Intermediate · Time: ~22 min · Prerequisites: Lesson 12 — Social Engineering and Phishing

Why this matters

An attacker with valid credentials is not breaking in — they are logging in. Every perimeter control you own was designed to stop an outsider, and a stolen login makes the attacker an insider on the first packet. This is why credential abuse is the most common way into organisations and also the least often fixed: the traffic looks like normal work, from a real user, at a plausible hour. You cannot defend identity with a firewall, and you cannot detect credential abuse with signatures, because there is no exploit to match on. This lesson gives you the vocabulary to read an Active Directory finding or a log line and know what happened.

The mental model: identity is the battlefield

What the attacker needs	Cost	What you can do about it
A vulnerability with an exploit	high — finding and weaponising one	patch, isolate, monitor for exploitation
A phishing click	medium — a believable pretext	email filtering, awareness, DMARC (Lesson 12)
A valid credential	low — credentials leak constantly, from other breaches	MFA, least privilege, monitoring for use
A privilege path in Active Directory	low once inside — often just a mis-set permission	tiering, auditing your own ACLs (this lesson)

The last two rows are why the industry says identity is the new perimeter. Note the practical consequence for you: detection moves from "was there an exploit" to "was this login expected". That requires knowing what normal looks like, which is the baseline theme of Lessons 22 and 23.

Password attacks, and what each looks like in your logs

Six families, six different log signatures. If you only learn one table from this lesson, learn this one.

Attack	How it works	Signature in logs	Why the usual fix fails
Online brute force	many attempts against one account	a burst of failures for one username from one source	easy to detect, easily blocked by lockout — attackers rarely bother
Password spraying	one or two common passwords against many accounts (e.g. `Spring2026!`)	one or two failures per account, spread across hundreds of accounts, from few sources	lockout never triggers because each account stays under the threshold
Credential stuffing	replaying username/password pairs leaked from other breaches	successful logons with no preceding failures, often from a new country or hosting provider	no password policy helps; only MFA and reuse detection do
Dictionary / rule-based guessing	a wordlist plus mangling rules (`Password` → `P@ssw0rd1`)	steady failures against a few accounts, often days apart to stay under thresholds	complexity rules are predictable and produce exactly these patterns
Rainbow tables	precomputed hash → password lookup	nothing online — the work happens offline	defeated entirely by per-account salts, which is why modern schemes use them
Offline cracking	after the hash file is stolen, crack at leisure on a GPU	nothing online — the breach already happened earlier	only hash strength, password length and cracking cost matter now

Two things follow. First, length beats complexity: each extra character multiplies attacker work, whereas a ! at the end is predicted by every rule set. Second, once a hash leaves your building you have already lost the argument — the time to care is before the dump, which is why credential theft detection (below) matters more than password policy tuning.

[!IMPORTANT] A salt (random data stored with each hash) makes two identical passwords hash differently, so a precomputed rainbow table is useless and cracking must be done per account. Modern systems use salts plus deliberately slow functions — bcrypt, scrypt or Argon2 — which is why "the hashes were strong" is a meaningful defence even after an offline breach.

When MFA is the target

MFA removed the "guess the password" problem, so attackers now attack the second factor instead. All four methods below are real, common and worth recognising.

Technique	How it works	What it looks like to the victim	What helps
Push fatigue (MFA bombing)	the attacker has the password and sends approval prompts until the user taps "approve"	a flood of unexpected push notifications, often at night	number matching, rate limits, blocking repeated denials, user training to deny and report
Real-time phishing proxy	a reverse proxy sits between the user and the real login page, relaying the password and the OTP as they are typed	a login page that looks correct, sometimes with the URL off by a character	phishing-resistant factors, conditional access, session-bound tokens, URL filtering
SIM swapping	the attacker ports the victim's number to their own SIM, then receives SMS codes	sudden loss of mobile service	never make SMS the only factor for privileged accounts; use an app or a hardware key
Session-token theft	steals the cookie or token after authentication, so no factor is needed at all	nothing visible — the attacker is already logged in	token binding, short session lifetimes, device compliance checks

This is the practical reason phishing-resistant factors (passkeys/FIDO2 and hardware security keys) change the equation: the credential is bound to the origin, so a proxy on a different domain cannot use it, and there is no OTP to relay. Lesson 20 covers how to deploy them; the key point here is that "we have MFA" is not a yes/no answer — it describes a spectrum from SMS to a hardware key.

Windows and Active Directory: the concepts you must recognise

You do not need to run these techniques to defend against them. You need to recognise the words in a report, a log or a ticket.

NTLM and Kerberos coexisting

Real domains run both. Kerberos is the default and issues tickets from the Key Distribution Center on the domain controller: a TGT (ticket-granting ticket, proving who you are) then a TGS (service ticket, granting access to one service). NTLM is the older challenge/response protocol that still handles local accounts, workgroup access and anything that connects by IP address rather than by name — Kerberos needs a service name to build a ticket. That coexistence is not a detail: everyone who understands it knows NTLM is the fallback an attacker aims for.

Stealing credentials from memory and disk

Once an attacker has administrative rights on a machine, the credentials of everyone logged into it are within reach: password material cached in the LSASS process, and local account hashes in the SAM database (or NTDS.dit on a domain controller). What the attacker gains is not a password but a hash — and a hash is often enough, because NTLM accepts the hash directly as proof of identity. What you see if you are watching: a process opening LSASS, Sysmon logging a suspicious process access, EDR alerts on credential-access behaviour, or (worse, because it means success) nothing at all because the tooling was renamed.

Pass-the-hash and pass-the-ticket

Pass-the-hash uses the stolen NT hash to authenticate without ever cracking the password. The uncomfortable part is the fix: rotating the user's password does not solve it, because the reason it works is that the same local administrator hash is reused on hundreds of machines, and an attacker who still has a foothold simply dumps a fresh one. The durable fixes are unique local administrator passwords (LAPS), refusing to reuse local admin credentials, credential protection for privileged accounts, and disabling NTLM where you can.
Pass-the-ticket steals a Kerberos ticket from memory and reuses it, so no credential is touched at all. Tickets have lifetimes (default TGT life of 10 hours, renewable for 7 days), so this buys the attacker time rather than permanence — which is exactly why short ticket lifetimes and prompt detection matter.

Kerberoasting and AS-REP roasting

Attack	What it abuses	What the attacker gets	What defends it
Kerberoasting	any authenticated user may request a service ticket for an account that has a Service Principal Name, and part of that ticket is encrypted with the service account's password hash	a blob crackable offline — only as strong as the service account's password	long random service-account passwords, group managed service accounts (gMSA), no user accounts used as services, alert on bulk ticket requests
AS-REP roasting	accounts configured with "do not require Kerberos pre-authentication" will return a response encrypted with the account's hash to anyone who asks	an offline-crackable hash, without even authenticating	turn pre-authentication on for every account; alert when it is off

Both are quiet, both need no elevation, and both are defeated by password entropy on accounts that nobody watches.

Forged tickets: Golden and Silver

A Golden Ticket is a forged TGT signed with the password hash of the krbtgt account — the account whose key signs every ticket in the domain. It grants domain-wide access and, because the attacker chose the contents, can be given a lifetime of years. Recovering requires rotating the krbtgt password twice, with a replication interval in between, because tickets are still valid while the old key remains in the domain. A Silver Ticket is the same idea scoped to one service: a forged TGS encrypted with a computer or service account's key, granting access to that service with no domain controller involvement at all — which is why it can be invisible to DC-side logging.

DCSync and directory replication abuse

Domain controllers replicate each other constantly, and replication means "send me the password hashes". An account holding the replication permissions (DS-Replication-Get-Changes and Get-Changes-All) can imitate a domain controller and pull the whole directory's credentials without ever running code on a DC. Legitimate replication from a DC is expected; replication requests from anything that is not a domain controller are an emergency.

LDAP reconnaissance and attack paths

The directory is readable by design: LDAP queries can enumerate every user, group, group membership, session and permission. Attack tools such as BloodHound query exactly this, then build a graph showing the shortest path from the account you hold to Domain Admin — a user whose session sits on a server where a mis-set ACL grants write access to a group that can log on to a DC, and so on.

[!TIP] Run the same graph on your own domain. The output is not an attack plan, it is a finding list: every edge on that path is a permission someone granted by accident, and each one you remove is a step the attacker loses. Attack-path mapping is the single highest-value thing a small team can do in Active Directory.

Hardening Active Directory — what to change

Control	What it means in practice	The attack it removes
Tiered administration	separate admin accounts and separate admin workstations per tier: Tier 0 identity, Tier 1 servers, Tier 2 endpoints. An admin never browses email or the web with an admin token	credential theft from a workstation being reused on a domain controller
LAPS	a unique, rotated local administrator password per machine	pass-the-hash between machines
Disable NTLM	audit first (`Network security: Restrict NTLM` in audit mode), then block where applications allow	relay and hash-reuse attacks
gMSA	service accounts whose passwords are 240 characters and rotate automatically	Kerberoasting
Protect privileged groups	Domain Admins, Enterprise Admins, Administrators: membership audited, changes alerted, no nesting, no service accounts inside	one mis-click granting permanent domain control
Restrict delegated permissions	review ACLs on OUs and objects; grant on a specific object, not a whole subtree	the attack path the graph found
Honeytokens	a decoy privileged-looking account or a stored credential that nothing legitimate uses, alerted on any use	gives you an early, high-confidence detection instead of a needle in a haystack

Detection: what to alert on

Name these event IDs, know what each reveals, and log them centrally — a domain controller's local log is useless if nobody reads it.

Event ID	Meaning	Why it matters
4624	successful logon	the payload of credential abuse; the logon type and source tell the story
4625	failed logon	brute force and spraying, in aggregate
4648	logon using explicit credentials	a process running as another user — common in lateral movement and admin tooling
4672	special privileges assigned to a new logon	someone has administrative rights on this session
4720	a user account was created	persistence or a fabricated identity
4728	a member was added to a global security group	new Domain Admin accounts arrive this way
4768	Kerberos TGT requested (AS-REQ)	the AS-REP roasting target and the logon that precedes everything
4769	Kerberos service ticket requested (TGS-REQ)	Kerberoasting — look for bulk requests and weak encryption types
4771	Kerberos pre-authentication failed	Kerberos-side password guessing (the 4625 equivalent)
4776	NTLM credential validation	NTLM is still in use — and where it is used, hashes matter
4662	an operation was performed on a directory object	DCSync shows here as replication access from a non-DC
7045	a service was installed	how much persistence and attacker tooling arrives

The event IDs are the raw material; the behaviours are what you alert on: failures sprayed across many accounts from one source; a new member of Domain Admins or any privileged group; service tickets requested in bulk or with weak encryption; TGT requests for accounts without pre-authentication; directory replication from a host that is not a domain controller; an account logging on from a workstation it has never used before.

Attack it / Defend it

The attack	How it works	The control that stops it
Password spraying	common passwords against many accounts, under the lockout threshold	MFA, banned-password lists, alerting on distributed failures rather than lockout alone
Credential stuffing	passwords leaked from other breaches, reused by your staff	MFA, breach-password screening, awareness that reuse is the risk
Offline hash cracking	a stolen hash cracked at leisure	strong slow hashing, long unique passwords, and preventing the dump in the first place
Push fatigue / MFA bombing	repeated prompts until one is approved	number matching, prompt rate limits, training to deny and report
Pass-the-hash	authenticate with a stolen hash, no cracking	unique local admin passwords (LAPS), no local admin reuse, NTLM restricted, credential protection
Kerberoasting	request tickets encrypted with a weak service account key, crack offline	gMSA, long random service passwords, no user accounts with SPNs, bulk-ticket alerting
DCSync	imitate a domain controller and pull every hash	audit and remove replication permissions, restrict who is a DC, alert on replication from non-DCs
Golden Ticket	forge a TGT using the krbtgt key	rotate `krbtgt` twice, tiered administration, monitor for anomalous ticket lifetimes
Attack-path abuse	follow a chain of misconfigured permissions to Domain Admin	audit ACLs, least privilege, attack-path graphing of your own directory
Credential dumping	read LSASS/SAM on a host you already control	EDR and Sysmon process-access alerting, credential protection, tiering so that account is never there

Key takeaways

Attackers prefer your credentials to your vulnerabilities, because credentials are cheaper to obtain and leave no exploit signature. Where your detection looks only for exploits, you are blind to the most common intrusion.
Password spraying defeats lockout policies by staying under the threshold — you need MFA plus distributed-failure alerting, not a stricter lockout.
A hash is as good as a password for NTLM, which is why stopping the dump and removing local admin reuse matter more than any password policy.
Service accounts with weak passwords are the soft centre of Active Directory. gMSA and long random secrets remove the entire Kerberoasting class of attack.
The krbtgt account is the crown jewel — whoever holds its key can mint any identity in the domain — and every path that leads there is a permission someone granted, so graph your own directory before an attacker walks it.

Check yourself

You see one failed logon for each of 400 different accounts in ten minutes from two source IPs. What attack is this, and why did the account lockout policy not fire?
An attacker steals a local administrator hash from one workstation and logs into thirty others. Why would resetting the IT administrator's password not stop them?
What does Kerberoasting actually give the attacker, and which single change makes it useless?
A service ticket is requested from a workstation directly to a file server, with no domain controller traffic in between. What kind of forged ticket should you suspect?
Name three event IDs you would alert on for "someone just gained domain-wide privilege", and what each shows.