We're back for day two! The series here are going great hehe. Last time we talked a lot about AD Fundamentals, be that Terminology, Objects, Roles, ...

Today will be about AD Protocols and Users - are you excited? - you should be, in a few posts time we'll be all in working with AD Labs and cool CTFs hehe.

Kerberos - Tickets, Trust and a Whole Lot of Magic

Kerberos is like the bouncer system of a very secure, very exclusive club - Active Directory. Instead of asking for your password every time you want access to something, you get a stamp (ticket) that says "yes, this person has been checked", and you can wave it around to get into other rooms.

What is Kerberos, Really?

Kerberos is the default authentication protocol in Windows domains since Windows 2000. It was designed to avoid sending passwords over the network. Instead, it uses tickets (encrypted blobs) that prove your identity and authorize access to services, like digital hall passes.

Key Concepts You Need to Know

How Kerberos Authentication Works

Let’s go through the real-world login and ticket flow, like logging into your work laptop and opening an internal SharePoint page.

Step 1: Logging In (AS-REQ / AS-REP)

1. You type your username + password.
2. Your computer encrypts a timestamp using a key derived from your password.
3. It sends that encrypted blob to the KDC (remember, Key Distribution Center) (on a Domain Controller) - that's called the AS-REQ, or Authentication Service Request
4. The KDC decrypts it using its copy of your password hash (from AD).
   • If it works: you're authenticated.
   • It sends you a TGT, encrypted with the krbtgt account's secret key - that's called the AS-REP, or Authentication Service Response

This is the Authentication Service (AS) exchange, the request named KRB_AS_REQ and the response KRB_AS_REP.

Step 2: Requesting Access to a Service (TGS-REQ / TGS-REP)

You now want to access, say, a file server.

You present your TGT to the KDC and ask:

"Hey, I’d like to talk to FILE01.corp.local, please."

The KDC responds with a TGS (Ticket Granting Service, remember?) ticket for that specific service.

It's encrypted with the NTLM hash of the service account (e.g., the machine account of FILE01) - we'll get to NTLM later in this post.

This is the Ticket Granting Service (TGS) exchange, the request named KRB_TGS_REQ and the response KRB_TGS_REP.

Step 3: Accessing the Resource (AP-REQ)

You hand over the TGS ticket to the file server.

It decrypts the TGS using its own password (machine account hash).
If valid: you're allowed access.

This is the Application Service (AP) request.

Why This Matters

• Your password is never sent over the wire, only used to encrypt the initial auth request.
• Kerberos is stateless; the KDC doesn't track session data; the ticket is the proof.
• All tickets have expiration times, short lifespans reduce risk.

Practical Enumeration Tip

💡 Port 88 = Kerberos

When scanning an AD environment with tools like Nmap:

nmap -p 88 -sV <YOUR_TARGET> --open

You can often identify Domain Controllers by detecting open port 88 (Kerberos service).

Attacker POV: Why We Love Kerberos

Kerberos is powerful and attackable. Some common tactics:

Kerberos TL;DR

• Kerberos uses port 88 (TCP/UDP)
• Runs on Domain Controllers
• No passwords over the network
• Tickets prove identity, reduce risk, and enable fast access

DNS - The Phonebook of Active Directory

Or in the previous analogy: If Kerberos is the bouncer, then DNS is the front desk, telling you where everyone is and how to reach them.

In Active Directory, DNS (Domain Name System) is used constantly behind the scenes. It resolves names into IP addresses and helps clients find critical services, like the nearest Domain Controller. Without DNS, Active Directory would be like a company where nobody knows anyone else’s office number.

Why DNS Matters in AD

When a user logs in, opens Outlook, or accesses a file share, they don't type IP addresses, they use names:

• file01.inlanefreight.local
• corp.inlanefreight.local
• academy-ea-dc01

These names are resolved by DNS into actual IP addresses.

User: barbara.jones
  └── wants to access → FILE01.INLANEFREIGHT.LOCAL  ← a file server

DNS Query Flow:
  ├── barbara.jones sends a query to the DNS server:
  │     "Hey, what's the IP address of FILE01.INLANEFREIGHT.LOCAL?"
  ├── DNS server checks its internal records (zone database)
  ├── DNS finds a match:
  │     FILE01.INLANEFREIGHT.LOCAL → 172.16.6.25
  ├── DNS responds with IP address → 172.16.6.25
  ├── barbara.jones’s system uses the IP to send an HTTP request to the file server
  └── FILE01 replies with an HTTP response (e.g. a login page, a file, etc.)

But in Active Directory, DNS does more than just name → IP:

• It tells clients where Domain Controllers are
• It helps DCs talk to each other
• It tracks services with special records called SRV records

How it Works: DNS in AD

1. A client joins the network.
2. It asks DNS: "Where’s a Domain Controller for inlanefreight.local?"
3. DNS replies with an SRV record, pointing to a hostname.
4. The client then resolves that hostname to an IP address.
5. Now the client can talk to the DC and log in.

Ports used:

• UDP 53 (default, for small queries)
• TCP 53 (used when responses are too big (> 512 bytes) or TCP is required/ communication is no longer possible)

DNS in Action

Here are a few super practical commands you'll use all the time when enumerating AD.

Forward DNS Lookup (Name → IP)

PS C:\USER> nslookup INLANEFREIGHT.LOCAL

Server:  172.16.6.5
Address: 172.16.6.5

Name:    INLANEFREIGHT.LOCAL
Address: 172.16.6.5

Use this to find the IP address of a domain name: like a DC, server, or host.

Reverse DNS Lookup (IP → Name)

PS C:\USER> nslookup 172.16.6.5

Server:  172.16.6.5
Address: 172.16.6.5

Name:    ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL
Address: 172.16.6.5

This helps you identify hosts on the network, super helpful after Nmap or masscan.

Lookup by Hostname (Short or Fully Qualified Domain Name (FQDN))

PS C:\USER> nslookup ACADEMY-EA-DC01

Server:   172.16.6.5
Address:  172.16.6.5

Name:     ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL
Address:  172.16.6.5

You don’t always need the full FQDN. DNS can figure it out as long as your suffix settings are right.

Why Attackers Love DNS in AD

• DNS tells us where the Domain Controllers are.
• SRV records show what services exist and where they live.
• If DNS is misconfigured, it's a goldmine of open enumeration.

Tools like:

• nslookup, dig, or Resolve-DnsName (PowerShell)
• dnsrecon, dnscan, fierce, or nmap -sU -p 53

...are your best friends when doing internal recon.

Fun Fact: SRV Records in AD

SRV (Service) records look something like this:

_kerberos._tcp.dc._msdcs.inlanefreight.local

They tell clients things like:

“Hey, you can find the Kerberos service over TCP on port 88 at this host.” Without these records, Kerberos and LDAP clients wouldn’t know where to authenticate.

DNS TL;DR

LDAP – The Language of Active Directory

Imagine you’re walking into a massive digital library called Active Directory. You know the name of the person you’re looking for, or maybe just a clue, “someone in the IT department.” You don’t want to manually check every page.

So you ask the librarian at the front desk:

“Hey, who is barbara.jones, and what groups does she belong to?”

That librarian is LDAP: the Lightweight Directory Access Protocol.

What is LDAP, in Simple Terms?

LDAP is a protocol, a standard language that applications and services use to search, read, and modify directory data.

Think of it like SQL for directories. Just as you might use SQL to query a database:

SELECT * FROM users WHERE name = 'barbara.jones';

You’d use LDAP to query AD:

(&(objectClass=user)(sAMAccountName=barbara.jones))

It’s how systems like web apps, email servers, or internal portals ask Active Directory questions like:

• Who is this user?
• What computers are in this OU?
• Is this account disabled?
• Which users are in the Domain Admins group?

If Active Directory is a giant address book, LDAP is the search engine for that book. If AD is a restaurant kitchen, LDAP is the waiter taking and delivering your orders.

The latest LDAP version is Version 3, published as RFC 4511.

How LDAP Works in AD

LDAP runs on port 389 (TCP) by default. When encrypted (via SSL/TLS), it runs on port 636, known as LDAPS. Domain Controllers listen for LDAP requests; basically, clients asking questions or making changes.

Here’s what a typical LDAP flow looks like:

Client → "Hey, can I speak to AD?"
↓
LDAP BIND request → "Here's my username and password, please authenticate me"
↓
If valid, LDAP allows search or modify actions
↓
Client sends query (e.g., "Find user barbara.jones")
↓
LDAP returns attributes like email, last login, group membership, etc.

LDAP Authentication – “BIND” Operations

LDAP uses a concept called a bind to log in and establish the user's identity before allowing any further requests.

There are two major types of bind/auth:

1. Simple Bind (Common, but Weak)

Username and password are sent in plaintext unless LDAPS is used. Often used by internal apps. Can be:

• Anonymous (no creds)
• Unauthenticated (username, no password)
• Username + Password

Tip: If LDAP simple bind is used without SSL/TLS, credentials are sniffable via tools like Wireshark.

2. SASL Bind (Stronger, More Secure)

SASL = Simple Authentication and Security Layer

• Delegates the authentication to Kerberos, NTLM, or others.
• Securely authenticates users by separating the auth method from the LDAP protocol.
• Most common in enterprise environments where Kerberos + LDAP go hand in hand.

LDAP for Attackers & Pentesters

LDAP is one of the first places to look after getting domain user credentials or a shell on a domain-joined machine.

It lets you enumerate:

• All users in the domain
• Group memberships (especially privileged groups)
• Computer objects (what systems exist)
• Password policy objects
• Trust relationships
• SPNs (useful for Kerberoasting)

Tools:

• ldapsearch
• PowerShell’s Get-ADUser, Get-ADComputer
• SharpLDAP or BloodHound (via ingestors like SharpHound)
• ADExplorer (GUI-based enumeration)

LDAP Security Concerns

• Cleartext creds: If not using LDAPS, credentials can be captured by sniffing internal traffic.
• Anonymous binds: Some misconfigured environments allow basic LDAP enumeration without auth.
• Over-permissive queries: Internal web apps might expose LDAP queries to users unintentionally.

Mitigations:

• Force LDAPS, disable anonymous binds.
• Use access control to limit who can query what via LDAP.
• Audit application and user LDAP queries for unexpected patterns.

LDAP Examples

Getting User Info via PowerShell

Get-ADUser -Filter * -Property * | Select-Object Name, LastLogonDate

What it does:

• Queries all users in AD (-Filter *)
• Pulls all LDAP attributes (-Property *)
• Displays only the Name and LastLogonDate

Useful when:

• Enumerating users after gaining access to a domain-joined box
• Auditing stale accounts
• Looking for recently active users for lateral movement targets

Searching with ldapsearch (Linux)

ldapsearch -x -h 172.16.6.5 -b "dc=inlanefreight,dc=local" "(objectClass=user)"

What it does:

• Connects to LDAP server at 172.16.6.5
• Performs an anonymous/simple bind (-x)
• Sets search base to the domain root
• Filters for all objects with class user

Useful when:

• You want to dump user info from a Linux box after network access
• Testing for anonymous bind access
• Starting recon after grabbing internal network creds

Authenticated LDAP Search (Linux, with creds)

ldapsearch -x -H ldap://172.16.6.5 -D "CN=admin,DC=inlanefreight,DC=local" -w 'Password123!' -b "DC=inlanefreight,DC=local" "(objectClass=computer)"

This one:

• Binds with a username/password
• Queries for computer objects
• Great for checking network assets

TL;DR: LDAP

MSRPC – Microsoft’s Remote Procedure Call (RPC)

MSRPC stands for Microsoft’s implementation of Remote Procedure Call, and it’s a core piece of how Windows systems talk to each other behind the scenes, especially within an Active Directory environment. Imagine it like a walkie-talkie system: a client says “Hey! I need something done!” and the server listens, understands the message, and does the job; whether it’s checking a user’s password, reading group membership, or replicating AD data. These “messages” travel across MSRPC interfaces, and as attackers (or defenders), understanding these is critical, because they allow enumeration, replication, authentication, and more.

MSRPC runs on:

• TCP port 135 (for initial binding)
• Then dynamically assigns high-numbered ports (called "ephemeral" ports)

Let’s break down the four major interfaces MSRPC uses in AD environments and what they mean for you:

lsarpc – Local Security Authority RPC

What it does: Talks to the LSA (Local Security Authority), which controls audit policies, security policies, and auth mechanisms.

Example Usage:

• Query domain password policy
• Enumerate trusted domains
• Access security descriptor info

Tip: Pentesters can use tools like rpcclient or Impacket’s lsadump to pull out sensitive domain security settings. Admins should harden policies and restrict who can call LSA functions remotely.

netlogon – Domain Authentication Helper

What it does: Handles authentication for users and services. It’s like the gatekeeper that logs people in.

Example Usage:

• Machine password changes
• Credential validation
• Domain join operations

Attacker Insight: Exploited in attacks like Zerologon (CVE-2020-1472) where attackers abuse insecure netlogon cryptography to gain Domain Admin privileges without a password..

samr – Security Account Manager RPC

What it does: Accesses the SAM (Security Account Manager): the database of users, groups, and their relationships.

Red Team Goldmine:

• Enumerate users & groups
• Reveal who’s in Domain Admins
• Map out trust relationships and nested group memberships

Example Tooling:

• BloodHound (via SharpHound)
• Impacket’s lookupsid.py
• rpcclient and enumdomusers

Defensive Tip: By default, any authenticated user can query the domain via samr. Change the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM to harden and block this!

drsuapi – Directory Replication Service

What it does: Manages replication of Active Directory between Domain Controllers (DCs). Think of it as the sync engine behind all of AD.

Attacker Superpower:

• Used in DCSync attacks via Mimikatz: lsadump::dcsync /user:Administrator
• Pulls password hashes of any user from AD — including krbtgt, enabling full Golden Ticket forgery

Behind the scenes: This is how attackers get NTDS.dit data without touching the filesystem.

Defensive Tips:

• Limit who can replicate directory data
• Monitor for DCSync behavior
• Use Privileged Access Workstations (PAWs) and Tiered Admin models

TL;DR: MSRPC Interfaces in AD

Real-World Scenario

Imagine an attacker has compromised a regular domain user account. Without needing admin rights:

• They use SAMR to list Domain Admins
• Use LSARPC to query password policy
• Plan a DCSync using drsuapi if replication rights are misconfigured

This is why understanding MSRPC interfaces isn’t optional, it’s essential for hardening Active Directory and thinking like an attacker.

NTLM Family: LM, NTLM, NTLMv1, NTLMv2

Before we move on, let's pause and catch our breath.

We're about to dive into the murky waters of NTLM authentication, one of the most well-known, widely abused, and misunderstood components of the Windows authentication world.

🔒 Why split this into two parts? Because we want you to truly understand it, not just memorize acronyms. So we’re going to do this in two digestible chunks:

• This section: all about the NTLM family; what it is, how it evolved, where it's used, and how it can be abused.
• Next section: we’ll explore Domain Cached Credentials (MSCache); how Windows handles authentication when it's off the network, and how you (as a pentester) can dig into that.

What Is NTLM Anyway?

NTLM stands for NT LAN Manager. It’s a challenge-response authentication protocol that Microsoft used before Kerberos became the default in Windows 2000.

But even today, NTLM is still everywhere:

• Older systems and apps still use it.
• Many tools, APIs, and misconfigured services fall back to NTLM when Kerberos fails.
• It's the backbone of some of the most common attacks in Windows networks: Pass-the-Hash, NTLM Relay, Cracking, and more.

NTLM is built on a family of hash types and authentication protocols:

• Hash types: LM and NT (aka NTLM hash)
• Authentication protocols: NTLMv1 and NTLMv2, which use the above hashes in various ways

Let’s break them down.

LM – The Legacy Dinosaur

LM (LAN Manager) is the grandfather of Windows authentication. Born in the ‘80s, it:

• Converts passwords to uppercase only
• Splits them into two 7-character chunks
• Hashes them with DES, then glues them back together

Vulnerabilities

• It ignores case and limits you to 14 characters
• Brute-forcing LM hashes is ridiculously fast
• Even visually, if a password is 7 characters or less, the second half of the hash will always be the same!

Example LM hash:

299bd128c1101fd6

Windows Vista and newer disable LM by default, but it's still sometimes lurking in legacy systems.

NT Hash (a.k.a. NTLM Hash)

This is the modern Windows hash format. It's what NTLMv1/v2 protocols rely on.

How it works

• Takes your password
• Converts it to UTF-16 little-endian
• Hashes it with MD4

NT Hash = MD4(UTF-16-LE(password))

Example NT hash:

b4b9b02e6f09a9bd760f388b67351e2b

The NT hash is often what we steal and re-use in pass-the-hash attacks!

NTLM Authentication: The Protocols

NTLM uses a 3-message exchange:

1. NEGOTIATE_MESSAGE: client introduces itself
2. CHALLENGE_MESSAGE: server sends a random value
3. AUTHENTICATE_MESSAGE: client responds with a hash of the challenge using its password hash

This is used in:

• NTLMv1 (older, weak)
• NTLMv2 (newer, stronger)

NTLMv1 – The Flawed First Draft

NTLMv1 was the original implementation of this protocol.

• Uses the NT hash (and sometimes the LM hash)
• The server sends an 8-byte challenge
• The client encrypts it with three DES keys derived from the password

response = DES(K1, C) | DES(K2, C) | DES(K3, C)

Example NTLMv1 hash:

9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41

Problems:

• Can be cracked offline easily
• Weak to NTLM Relay
• Doesn’t support mutual authentication

Completely disable NTLMv1 in modern environments. It's a ticking time bomb.

NTLMv2 – Slightly Less Terrible

NTLMv2 is the improved version, introduced in Windows NT4 SP4 and default since Server 2000.

It includes:

• Stronger cryptographic challenge/response
• HMAC-MD5 over various values (username, domain, time, challenge)
• Some resistance to replay and spoofing

LMv2 = HMAC-MD5(v2-Hash, ServerChallenge, ClientChallenge)
NTv2 = HMAC-MD5(v2-Hash, ServerChallenge, ClientChallenge*)

Example NTLMv2 hash:

admin::domain:LMv2:NTv2

While harder to crack, NTLMv2 is still vulnerable to:

• Relay attacks
• Capture via Responder
• Replay in poorly configured environments

Practice: CrackMapExec Pass-the-Hash

Let’s say we stole an NT hash. Here’s how we’d use it:

crackmapexec smb 10.129.41.19 -u rachel -H e46b9e548fa0d122de7f59fb6d48eaa2

If the user is a local admin: Access granted. You didn’t need their password; just the hash.

TL;DR: NTLM basics

Next up, we’ll look at Domain Cached Credentials, what Windows does when it can’t talk to a domain controller, and how that opens another door for attackers.

Domain Cached Credentials (MSCache2)

So far, we've looked at authentication when everything's working as expected, the client contacts the Domain Controller (DC), gets a ticket or challenge, and proceeds. But what happens when a domain-joined machine is offline, or can't reach the DC; say, a laptop on a train or during a VPN outage? 🔑 Microsoft had to solve this problem.

That’s where Domain Cached Credentials (DCC), also called MSCache v1/v2, come in.

What Are Cached Credentials?

Think of it like this:

Windows remembers the last people who logged in, just in case it can’t verify them later.

By default, Windows stores the last 10 logins for domain accounts, so users can still log into their machine even when it's disconnected from the network.

These cached credentials live here:

HKEY_LOCAL_MACHINE\SECURITY\Cache

These aren't passwords, they're hashes of the password + salt + user info, derived using the MSCache algorithm.

How It Works (Simplified)

Here’s what happens under the hood:

1. A user logs into a domain-joined machine.
2. If authentication succeeds, Windows generates a MSCache2 hash of their password.
3. This hash is stored locally in the registry.
4. If the user tries to log in without a DC connection, Windows checks the cached hash instead.

Attacker Use Case

To read these hashes, you need local admin on the machine. Once you have that, you can extract them with tools like:

• mimikatz secretsdump.py (Impacket)
• pwdump

The output looks like this:

$DCC2$10240#bjones#e4e938d12fe5974dc42a90120bd9c90f

Where:

• bjones is the username
• The big hex string is the DCC2 hash (MSCache v2)

Key Limitations

You can't pass-the-hash with MSCache hashes. They're not usable like NTLM hashes.

They’re very slow to crack. Even high-end GPUs struggle unless:

• You know the user’s weak password (e.g. Spring2024!)
• You use targeted dictionaries with rules

That’s because MSCache uses PBKDF2-style stretching; hashes are intentionally slow to calculate. In other words: these are only useful if you're lucky or patient.

Pentester Tips

• Extract them post-exploit from compromised workstations or laptops.
• Use them to guess or crack a user's password offline.
• Store them; if you get password reuse across systems or future engagements, they may help.
• Combine with social engineering: if you know bjones uses Welcome123! somewhere else, you might get in.

TL;DR: Cached Credentials (DCC)

Aaand with that, you’ve made it through the AD Protocols gauntlet.
You now understand Kerberos, DNS, LDAP, MSRPC, NTLM, and MSCache, not just what they are, but how to attack (or defend) them.

Next up? Maybe Users, Groups, and Privilege Escalation; let’s turn knowledge into access.