> ## Content Index > Fetch the complete content index at: https://niklas-heringer.com/llms.txt > Use this file to discover other available public pages before exploring further. # Active Directory Protocols Unpacked: A Practical Learning Journey - Day Two - URL: https://niklas-heringer.com/penetration-testing/active-directory-journey-day-two/ - Published: 2025-06-12T13:57:00.000Z - Updated: 2025-11-19T18:37:59.000Z - Author: Niklas Heringer - Tags: ad-challenge, ad-infrastructure, penetration-testing, kerberos, ldap, ntlm, msrpc, dns, active-directory 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**](https://niklas-heringer.com/penetration-testing/introduction-to-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 | Term | What it Means | Analogy | | ---------------------------------------- | ----------------------------------------------------------------------- | ---------------------------------------- | | **KDC (Key Distribution Center)** | Lives on Domain Controllers. It authenticates users and issues tickets. | The bouncer at the front door | | **TGT (Ticket Granting Ticket)** | Proves who you are, allows you to request access to services. | A VIP wristband you get at check-in | | **TGS (Ticket Granting Service) ticket** | Lets you access a specific service like SMB, SQL, etc. | A room-specific access card | | **krbtgt account** | A special AD account used to encrypt TGTs. | The ticket printer at the bouncer’s desk | ## 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: ```bash nmap -p 88 -sV --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: | Attack | How It Works | | ------------------- | ------------------------------------------------------------------------------------------------------------------- | | **Kerberoasting** | Request service tickets (TGS) for service accounts, then extract and crack them offline (bruteforce the NTLM hash). | | **AS-REP Roasting** | If a user doesn’t require Kerberos pre-auth, you can request an AS-REP and crack it offline : no login required. | | **Golden Ticket** | Once you have the krbtgt hash, you can forge your own TGTs. Full domain persistence. | | **Silver Ticket** | If you have the hash of a service account, you can forge a TGS directly for that service. No TGT needed. | ## Kerberos TL;DR | Step | Action | Protocol Part | | ------ | --------------------- | ----------------- | | Step 1 | Login → TGT | AS-REQ / AS-REP | | Step 2 | Request service → TGS | TGS-REQ / TGS-REP | | Step 3 | Use TGS → access app | AP-REQ | - 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**. ```bash 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) ```powershell 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) ```powershell 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)) ```powershell 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: ```bash _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 | What DNS Does in AD | Why It Matters | | ------------------------ | ---------------------------------------- | | Finds Domain Controllers | Required for logon, Kerberos, LDAP | | Resolves names to IPs | Core to all client-server interaction | | Hosts SRV records | Tells clients which services exist where | | Uses TCP/UDP port 53 | Useful for network scans + enum | | Enables Dynamic DNS | Hosts can auto-register their name + IP | --- ## Sign up for Niklas Heringer Cybersecurity & Math: Aspiring penetration tester at ERNW, exploring risk, automation, and offense through analysis and experience. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. --- # 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: ```sql SELECT * FROM users WHERE name = 'barbara.jones'; ``` You’d use LDAP to query AD: ```bash (&(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](https://tools.ietf.org/html/rfc4511?ref=niklas-heringer.com), 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: ```bash 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 ```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) ```bash 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) ```bash 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 | Term | Description | | -------------------------- | -------------------------------------------------------------- | | **LDAP** | Protocol for querying and modifying directory services like AD | | **Port 389 / 636** | Default and SSL-secured LDAP ports | | **Bind** | The process of logging in to LDAP | | **Simple Auth** | Basic auth, often unencrypted | | **SASL** | Secure method, often using Kerberos | | **LDAPS** | LDAP over SSL/TLS – secure | | **Directory System Agent** | Another name for an LDAP server | | **Common Usage** | Get users, groups, computers, GPOs, etc. | --- # 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 | Interface | Role | Attacker Use | Defense Tip | | --------- | ------------------------------- | --------------------------- | --------------------------- | | lsarpc | Manage domain security policies | Dump policy settings | Harden LSA permissions | | netlogon | Handle authentication/logon | Zerologon (CVE) | Patch & restrict access | | samr | Query users/groups in AD | Recon, BloodHound | Limit anonymous SAM access | | drsuapi | Sync AD data across DCs | DCSync, password hash theft | Restrict replication rights | ## 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** ```text 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 ```text response = DES(K1, C) | DES(K2, C) | DES(K3, C) ``` **Example NTLMv1 hash**: ``` 9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41 ``` **Problems**: - Can be **cracked offline** easily - Weak to [**NTLM Relay**](https://en.hackndo.com/ntlm-relay/?ref=niklas-heringer.com) - 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 ```text 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: ```bash 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 | Thing | Type | Crackable? | Pass-the-Hash? | Should I care? | | ----------- | ------------- | ------------ | -------------- | -------------- | | **LM** | Password hash | ✅ Super easy | ❌ | 🚫 Disable it | | **NT Hash** | Password hash | ✅ (Harder) | ✅ | ✅ Core target | | **NTLMv1** | Auth protocol | ✅ Easy | ❌ | 🚫 Disable it | | **NTLMv2** | Auth protocol | ❗Medium | ✅ | ✅ Learn it | 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) | Feature | Value | | ---------------- | ---------------------------------------- | | Location | HKLM\\SECURITY\\Cache | | Max Stored Users | 10 (by default) | | Extract With | Mimikatz, secretsdump, pwdump | | Crack With | Hashcat (slow, targeted) | | Reusable? | Not for pass-the-hash | | Useful for | Offline brute-force, weak password reuse | --- > 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*.