Things To Understand Prior

AD Components

Understanding The Core Concept

🔹 What is Active Directory?

Active Directory (AD) is a directory service developed by Microsoft that serves as the backbone of identity and access management in a Windows-based corporate network. It stores information about all network resources—such as

• Users

• computers

• groups

• printers

and enables centralized administration and security enforcement. Through AD, administrators can manage authentication (verifying user identity) and authorization (determining access rights), making it possible to securely organize and control access to everything within the network, from a single console.

🔐 Microsoft Definition:

“Active Directory enables centralized, secure management of an entire network, which might span a building, a city or multiple locations throughout the world.”

🧱 Active Directory Components

Here are the core components that make AD powerful and scalable:

🔹 Schema

• Schema = Blueprint defining what objects and attributes can exist in AD

The schema in AD acts as the blueprint or DNA of the directory. It defines all the object types (e.g., users, computers, groups) and their attributes (e.g., username, email, department). For example, a user object might have username, email, and department, while a computer object might include hostname and OS. The schema ensures consistency, maintains data integrity, and prevents the creation of invalid or unsupported objects across the environment.

🔹 Query and Index Mechanism

AD’s query and index mechanism enables fast searching and retrieval of directory data. It uses LDAP (Lightweight Directory Access Protocol) for communication. AD creates indexes on frequently queried attributes like samAccountName (username) and objectClass (type) to optimize performance. This mechanism is critical in large networks for tasks like finding users, identifying unused devices, or searching groups efficiently.

🔹 Global Catalog

The Global Catalog (GC) is a read-only, partial replica of all objects from every domain in the forest. It contains a subset of attributes that are commonly used in searches and is hosted on Global Catalog Servers (often Domain Controllers).

The GC enables cross-domain authentication such as logging into a system in one domain using credentials from another. e.g., logging into hr.company.com from a sales.company.com computer and allows forest-wide searches(e.g., finding any user from any domain). It plays a crucial role in login performance and resource discovery across the network.

What GC Stores

Suppose:

Forest

│

├── corp.local

│    ├── Daniel

│

├── dev.local

│    ├── John

│

└── sales.local

     ├── Mike

You search: John

GC can immediately answer:

John exists in dev.local

without contacting every domain.

Think:

Domain Controller

= Full copy of one domain

Global Catalog

= Partial copy of entire forest

Think of the GC as a phonebook with just the names and numbers—not full profiles.

🔹 Replication Service

The replication service ensures that all Domain Controllers (DCs) have an up-to-date and synchronized copy of the AD database. Changes—such as password resets or new user creation—are automatically replicated to other DCs. e.g.,You change your password in Delhi, and it gets replicated to DCs in Mumbai, Bangalore, etc.

Timestamp?

Partially.

AD uses:

• Update Sequence Numbers (USNs)

• Invocation IDs

• Replication metadata

• Version numbers

• Timestamps

Not timestamps alone.

When two DCs compare data:

Which object changed?

Which version is newer?

Replication metadata determines the winner.

⏱ Replication Interval

Depends.

Same Site (Default)

• Every 15 seconds after change notification

Then nearby DCs notify partners.

Very fast.

Usually:

15 sec → notify partner

3 sec → next partner

3 sec → next partner

Different Sites

• (Default) 180 minutes (3 hours)

because WAN links may be slow.

Admins can modify this.

📶 Two types of replication:

1. Intra-site (within the same site): Fast, frequent

2. Inter-site (between different sites): Scheduled, optimized

AD uses timestamps and version numbers to resolve conflicts and ensure data integrity across the domain.

Without replication, your AD environment would become inconsistent and unreliable.

Active Directory Structure

🔹 Forest

A forest is the topmost level of organization in Active Directory.

It represents the entire Active Directory environment and acts as a security boundary.

• It can contain one or more domains.

• All domains in a forest share a common schema (structure of objects and attributes)global catalog, and configuration.

• Forests allow different parts of an organization (like departments or regional offices) to be connected while maintaining administrative independence.

• Domains inside a forest can trust each other and share resources, but no access is allowed from outside the forest unless explicitly configured.

• Forests are ideal when different business units or companies require some level of isolation but still want shared resources and trust relationships.

👉 Think of a forest like a container for multiple trees (domains) that all live under the same environment.

🔹Domain

A domain is a logical group of users, computers, groups, and other objects that share the same Active Directory database and security policies.

• Each domain has its own policies, security settings, and domain controllers (servers that manage authentication and directory services).

• Domains are the core unit for authentication, authorization, and policy enforcement

• Domains are used to organize and manage network resources efficiently.

• Every domain has a unique name (like sales.company.com) can have trust relationships with other domains to facilitate resource sharing across the network.

👉 A domain is like a tree inside the forest. It can stand on its own, but still be part of a larger group (the forest).

Example of Domain and Forest.

✅ Example of a Domain

Let’s say your company is called TechCorp.

You create a domain called:

techcorp.com

This domain will contain:

• All your employees’ user accounts

• All computers joined to the domain

• Groups for teams like HR, IT, Sales

• Policies and permissions for everything

Everyone in the company logs in using something like jane@techcorp.com.

This is one domain, and if it’s the only one, then your forest also only has one domain.

✅ Example of Multiple Domains in a Forest

Now imagine TechCorp expands globally.

You want different teams or regions to manage their own systems, so you create:

us.techcorp.com      (for the US office)

eu.techcorp.com      (for the Europe office)

asia.techcorp.com    (for the Asia office)

Each of these is a separate domain, but they are all part of the same forest:

🔒 techcorp.com forest

They share:

• Trust relationships (users from one domain can access resources in another if allowed)

• A global catalog (so you can search users across domains)

• The same schema and configuration base

✅ Example of Multiple Forests

Now suppose TechCorp buys another company:

CyberSecure Inc.

They have their own AD setup with their own structure:

cybersecure.com

This is a separate forest, because:

• They have their own schema

• They don’t trust TechCorp domains unless configured

• It’s an entirely isolated security boundary

Unless you create a trust relationship, users from cybersecure.com can’t access techcorp.com resources.

🔹Organizational Unit (OU)

An Organizational Unit (OU) is a folder within a domain that is used to group objects logically based on business structure or function (e.g., departments like IT, HR). OUs allow administrators to apply Group Policies and delegate administrative tasks at a more granular level, without creating new domains. For instance, an OU for the Finance team can have unique password policies and administrative permissions that differ from other departments, making OUs essential for scalable and flexible administration.

An Organizational Unit (OU) is like a folder inside a domain in Active Directory. It helps you organize and manage objects such as:

• Users 👤

• Computers 💻

• Groups 👥

• Other OUs 📁

It allows for logical grouping of resources based on business needs (like departments, locations, or functions) and makes administration easier and more flexible.

🔐 Why are OUs important?

1. 🔧 You can apply Group Policies (like password rules, desktop settings) to specific OUs.

2. 👨‍💻 You can delegate administrative control—give someone rights to manage only the objects in a specific OU.

3. 📁 Helps in organizing large domains into manageable pieces.

In the domain techcorp.com, you might have OUs like:

• OU=HR

• OU=IT

• OU=Finance

In OU=IT, you store:

• User accounts: john.doe, jane.smith

• Computers: IT-PC01, IT-Laptop23

• Groups: IT Admins, HelpDesk

You can then apply specific policies to OU=IT like access to IT servers only, remote desktop allowed, Admin tools installed by default

Meanwhile, the Finance OU can have different users and rules—like access to payroll systems and stricter login policies.

Think of a domain as a school, and OUs as classrooms. Each classroom has its own students and rules but is part of the same school.

Trusts:

A trust is essentially a link between two AD domains or forests that allows security principals (users, groups, computers) in one domain to be trusted by another domain for access to resources.

When a trust exists:

• Authentication requests can be forwarded from one domain to another.

• Users don’t need to re-enter credentials.

• Access to resources can be controlled using ACLs.

Domains can allow access to shared resource outside of their boundaries by using a trust. Forest trusts allow users to access resources in any domain in the other forest, as well as logon to any domain in the forest.

Example

Forest, Tree, Forest root domain, child domain with help of tree diagram.

🌐 1. Forest

A Forest is the topmost level in an Active Directory (AD) environment. It represents the entire AD infrastructure and acts as a security boundary for all objects, trusts, and policies within it.

• It contains one or more Trees.

• All domains in the forest share a common schema (rules and object types) and global catalog (used for searching objects across domains).

• Forests can be used to separate different parts of an organization (like different business units or subsidiaries), while still allowing them to communicate if needed.

🧠 Example:

mycompany.com is a forest.

It includes domains like:

• mycompany.com (root domain)

• sales.mycompany.com

• hr.mycompany.com

• Another tree: techdivision.com

🔐 Security Boundary: Admins in one forest cannot control or see objects in another forest unless a trust is explicitly created.

The first domain you create in a new forest is called the “forest root domain”, and its name becomes the same as the forest’s name.

In above image foobank.inc is forest and its has only one domain which has same name as forest. When a new domain will be added it will added to this forest it will have some other name.

🌳 2. Tree

A Tree is a collection of domains(Root Domain + all its Child Domains) that share a contiguous namespace.

It starts with a root domain, and then you can create child domains under it.

• A tree allows logical grouping, often based on departments or regions.

• Domains in a tree automatically trust each other (transitive two-way trusts).

• You can have multiple trees inside a forest if needed.

🧠 Example:

• In Tree 1:
  • mycompany.com (root domain)
  • hr.mycompany.com (child domain)
  • sales.mycompany.com (child domain)
• In Tree 2 (same forest, different namespace):
  • techdivision.com (root domain)
  • dev.techdivision.com (child domain)

🌐 All these domains are still part of one forest — mycompany.com.

🌲 3. Root Domain

The Root Domain is the first domain created in a forest or tree. It is the anchor of the tree and forms the base of the domain hierarchy.

• It is responsible for maintaining the forest-wide roles (such as Schema Master and Domain Naming Master).

• Other domains (child domains) branch off from the root.

🧠 Example:

• mycompany.com is the tree root domain of Tree 1.

• techdivision.com is the tree root domain of Tree 2.

🔄 The first root domain created in a forest(mycompany.com in this case) is known as the Forest Root Domain.

Additional info:

• 🟢 A forest can contain:

  • Multiple domain trees (like mycompany.com , techdivision.com)
  • Each tree has its own tree root domain (e.g., mycompany.com is the root of its tree)

• 🔴 But there is only one forest root domain — the very first domain created in the forest (e.g., mycompany.com if it was created first).

• so mycompany.com is forest root domain as well as tree root domain, where as techdivision.com is only tree root domain.

The forest root domain can (and usually does) have the same name as the forest.

🔍 Explanation:

• The forest name is not a separate object — it’s actually named after the first domain created in the forest.

• This first domain is called the Forest Root Domain.

✅ So:

• When you create the first domain (e.g., corp.com), it becomes:
  • The Forest Root Domain
  • The name of the forest itself

So by default design, both the forest and the forest root domain are named the same.

🧠 Think of it like this:

💡 But remember — you can have other trees in the same forest (like eurocorp.local), and they will have different names, while still being part of the same forest.

🧱 4. Child Domain

A Child Domain is a subdomain of a root domain. It is used to:

• Organize resources by department, region, or function.

• Delegate administrative control more securely.

• Apply Group Policies specific to that domain.

🧠 Example:

• hr.mycompany.com is a child of mycompany.com

• dev.techdivision.com is a child of techdivision.com

🔗 Child domains inherit trust relationships from their parent domain.

🗂 5. Organizational Unit (OU)

An Organizational Unit (OU) is a logical container within a domain used to group users, groups, computers, and other OUs.

• Helps apply Group Policy Objects (GPOs) to only specific users/computers.

• Allows delegation of administration (e.g., HR can manage their own users).

• OUs exist only within domains (they don’t span across domains).

🧠 Example:

In the domain sales.mycompany.com:

• OU: SalesTeam → contains users sales1, sales2

• OU: SalesDevices → contains Sales-PC1, Sales-PC2

🎯 Ideal for applying GPOs like password policy, screen lock settings, etc.

OUs = Logical folders that help you organize AD objects and apply management or security policies efficiently.

Example of what can be done using OUs

Every domain and its child domains in Active Directory can have separate Organizational Units (OUs), as each child domain is separate in terms of administration and can have its own OUs.

In Active Directory, you can have multiple levels of nested OUs — also known as sub-OUs.

Eg:

Employee OU has two sub OUs which are Finance and HR.

🖥 6. Domain Controller (DC)

A Domain Controller (DC) is a Windows server that runs Active Directory services and does the following:

• Authenticates users (logins)

• Authorizes access to resources()

• Manages domain data (user accounts, passwords, policies)

• Replicates AD data to other DCs

Each domain must have at least one DC, but usually there are multiple for redundancy.

🧠 Example:

• DC1 might be Domain Controllers for mycompany.com

• DC2 could be for hr.mycompany.com

🔁 DCs replicate data between each other to keep AD updated.

Additional Info:

Each domain and child domain in Active Directory has its own Domain Controllers (DCs) and they cannot share the exact same Domain Controllers

Single domain can (and should) have multiple Domain Controllers (DCs) — and it’s actually considered best practice in Active Directory environments

Why can’t domains share DCs:

Each Domain Controller (DC):

• Holds a copy of the domain’s database (i.e., NTDS.dit)

• Manages authentication, authorization, and replication specific to that domain

• Is tied to a single domain only

So:

• A DC for corp.com can only handle corp.com domain objects

• A DC for hr.corp.com can only manage hr.corp.com objects

Even though they don’t share DCs, there is a default two-way transitive trust between parent and child domains.That means users can access resources across domains , if permissions

allow.

7. Group Policy Objects (GPOs)

Group Policy Objects are configurations used to manage the behavior of users and computers in an Active Directory environment. They allow admins to enforce security settings, software installations, scripts, and much more centrally and automatically.

🔹 GPOs can be linked to:

• Sites

• Domains

• Organizational Units (OUs)

🔹 GPOs are applied in the following order:

1. Local

2. Site

3. Domain

4. OU (including nested OUs, from top to bottom)

⚠️ GPOs do not cross domain boundaries but can be replicated within the domain using Domain Controllers.

🧠 Examples of Group Policies:

• Enforce password complexity and lockout settings.

• Disable USB access on company laptops.

• Install antivirus software on all devices in a specific OU.

• Configure desktop wallpaper and disable control panel.

Additonal Info:

“GPOs are linked to OUs (or domains/sites), and they contain policy settings. The Domain Controller enforces those policies by applying them to the users and computers located in the linked OU during login or system startup.”

Where GPO can be linked to:

So it the GPOs are directly linked to domain then the DC will enforce policy to all the OUs and child domain(unless it is blocked) present within the domain.

Trusts

🧩 Types of Trusts in Active Directory

Trusts can be broadly categorized by:

✅ 1. Direction of Trust

• One-way trust: Domain A trusts Domain B — users from B can access A, but not vice versa.

• Two-way trust: Both domains trust each other — users from both sides can access resources across.

✅ 2. Scope of Trust

🔁 Transitive vs Non-Transitive Trust

• Transitive: Trust extends beyond the two domains directly involved (e.g., if A trusts B and B trusts C, A trusts C).

• Non-Transitive: Trust exists only between the two specified domains.

🔓 Example Scenario

• You have DomainA.com and DomainB.com in different forests.
  • A forest trust allows users from DomainB.com to access shared folders in DomainA.com.
• You add a shortcut trust between Sales.DomainA.com and HR.DomainA.com to speed up logon time for users frequently accessing resources between the two.

🛡️ Trusts in Red Teaming

• Trusts can expand the attack surface.

• If you compromise a user or DC in one domain, you may pivot into another trusted domain.

• Enumeration tools like BloodHound can reveal trust relationships that red teamers exploit.

AD Authentication

Active Directory Authentication

• Active Directory (AD) authentication is the process by which users and computers verify their identities to gain access to network resources within an Active Directory domain.

• It plays a critical role in ensuring secure access to resources while maintaining centralized control over authentication and access management.

• As far as authentication on Active Directory is concerned, the most common way for users to authenticate is by providing a username and password.

• Active Directory (AD) supports several authentication protocols that facilitate secure communication and user authentication within an AD domain environment.

• These protocols play a crucial role in ensuring the confidentiality, integrity, and authenticity of authentication exchanges. Here are some of the key AD authentication protocols:

  • Kerberos
  • NTLM
  • LDAP

Kerberos

Kerberos is the primary authentication protocol used by Active Directory for user authentication.

How it works:

1. When a user attempts to log in, their client computer requests a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC), which is typically a domain controller.

2. The domain controller verifies the user’s credentials and issues a TGT if authentication is successful.

3. The TGT is then used to obtain Service Tickets for accessing specific network resources.

In Detailed working of Kerberos:

Step-by-Step Kerberos Authentication:

Let’s assume a user named Alice (alice@corp.local) wants to access a file server (fileserver.corp.local).

1️⃣ AS-REQ (Authentication Service Request)

🔹 Alice logs into her computer, which is joined to the AD domain.

🔹 Her machine sends a AS-REQ Request to the Key Distribution Center (KDC), which is a service that runs on a Domain Controller (DC).

🔹 The request includes:

• Alice’s username (not password)

  • A timestamp - encrypted using the Alice’s long-term key (derived from the AES or RC4, hash). (This step is Optional - required only if pre-authentication enabled for the user. Note:- pre-authentication is default for modern environments).

• The realm/domain name.

• Encryption types supported.

✅ Goal: Ask for a TGT (Ticket Granting Ticket)

Additional Info:

What is pre authentication?

In Kerberos, pre-authentication is a mechanism to verify that the user actually knows their password before the Key Distribution Center (KDC) hands out a Ticket Granting Ticket (TGT).

Why Pre-Authentication Exists (Its Strength):

• Prevents unauthenticated users from requesting tickets for any account.

• Ensures that the person requesting a TGT actually knows the password.

• Helps prevent replay attacks — the timestamp changes with every login, so old requests are invalid.

2️⃣ AS-REP (Authentication Service Reply)

• The KDC decrypts this timestamp using the stored password hash from Active Directory (AD).
  • If decryption is successful, the user must have the correct password — this proves the user(Alice) is legitimate.

🔹 If the username and timestamp are correct, the KDC sends back:

• A TGT (Ticket Granting Ticket): encrypted with the KDC’s secret key - specifically, the krbtgt account key(A special account in Active Directory).

• A session key: encrypted using the user’s long-term key (which is derived from the user’s password hash, typically NT hash).

✅ Alice’s computer can now use this TGT to request access to services(via a TGS-REQ) without resending the password.

Aditional Information:

When Pre-Authentication is Disabled (for AS-REP Roasting):

• In this misconfiguration, the KDC skips the need for encrypted timestamp.

• The attacker can send a bare AS-REQ with just the username.

• KDC replies with AS-REP, where the session key is encrypted with the user’s NTLM hash (technically: a key derived from it, usually AES or RC4 based).

✅ In this insecure setup:

AS-REP is directly encrypted with the NTLM hash (or key derived from it), making it crackable offline.

3️⃣ TGS-REQ (Ticket Granting Service Request)

🔹 Alice now wants to access .corp.local.

🔹 Her machine sends the TGT to the KDC and requests a Service Ticket for the file server.

✅ This request includes:

• TGT (proves she’s authenticated)

• Service Principal Name (SPN) of the target (like cifs/fileserver.corp.local)

Additonal Info:

Step-by-Step Use of TGT and Session Key

✅ 1. User wants to access a service (e.g., a file share or SQL server)

• The user sends a TGS-REQ (Ticket Granting Service Request) to the KDC (Ticket Granting Service).

• This request includes the TGT and is encrypted with the session key that was previously shared during AS-REP.

🔐 2. Use of Session Key

• The session key is used to:
  • Encrypt the authenticator (timestamp + username) the user sends to KDC along with the TGT.
  • Secure the communication between the user and the KDC.
• It ensures the authenticator is fresh (not reused) and the request is coming from the legitimate user who has the session key.

4️⃣ TGS-REP (Ticket Granting Service Reply)

🔹 KDC validates the TGT

• The KDC decrypts the TGT using the krbtgt password hash (since it created it).

• Then, the KDC uses the session key inside the TGT to decrypt the authenticator.

🔹 If all checks pass KDC issues :

• A Service Ticket(ST)/ Ticket Granting Service(TGS)- encrypted with the file server’s secret key(file server’s NTLMhash)

• A session key to be used between Alice and the file server

✅ Now, Alice has a ticket that the file server will trust.

Additonal Information:

The service Ticket or TGS contains:

• Client’s identity (username, SID, groups)

• Authorization data, like group membership (including nested groups, universal groups, etc.)

• Ticket lifetime

• Service name (SPN)

• Session key (encrypted with the service account’s key)

NOTE:- TGT takes care of authentication where as TGS take care of authorization

5️⃣ Client Accesses the Service

🔹 Alice’s machine sends the Service Ticket to fileserver.corp.local.

🔹 The file server decrypts it using its secret key and validates it.

🔹 If valid, access is granted to the shared folder.

Additional information:

What is a PAC in Kerberos?

PAC (Privilege Attribute Certificate) is a structure embedded inside the TGS (and sometimes the TGT) that contains:

• User SID

• Group memberships (domain groups, nested groups)

• User privileges

• User profile info (e.g., logon time, expiry, etc.)

It’s like a mini Active Directory snapshot of the user’s permissions.

🔒 Purpose of PAC Validation

PAC validation ensures:

• The authorization data hasn’t been tampered with.

• The domain controller (KDC) vouches for this data.

Without validation, a compromised client could forge group memberships (e.g., add themselves to Domain Admins).

NOTE:- PAC Validation is a optional step.

📌 When Does PAC Validation Happen?

PAC validation happens after the user presents the TGS to the target service, in this step:

Step 5: Service decrypts the TGS and validates the PAC

• Service decrypts the TGS using its own key.

• It extracts the PAC and validates it to ensure:

  • It was issued by a trusted KDC
  • It hasn’t been tampered with

• Validation may be done locally or by contacting the KDC.

Step 6: Authorization and access decision

• Service uses the PAC info (SIDs, groups) to check its ACLs.

• Grants or denies access based on user’s permissions.

Additional Info:

The timestamp is optional in some specific cases, then how the client authentication is done without timestamp?

🧩 What if the timestamp is not used?

There is an alternate method (legacy or compatibility mode), where instead of sending an encrypted timestamp, the client may request the TGT without pre-authentication.

However:

• This is only allowed if Pre-Authentication is disabled for the account in AD.

• In this case, the KDC still encrypts the session key using the user’s password hash which is stored in AD.

• The client must then decrypt it using the correct password.

💡 So even without a timestamp, the user must prove knowledge of the correct password — because otherwise, it can’t decrypt the session key.

🛡️ Bonus: Why Timestamp Is Usually Required

• Timestamps prevent replay attacks.

• Without it, an attacker could reuse a previously captured request.

• That’s why Kerberos pre-authentication is enabled by default — to force proof that the user knows the password now, not at some earlier time.

🎯 Example Summary (With Entities)

Features:

• Mutual authentication: Both the client and the server verify each other’s identities.

• Single Sign-On (SSO): Users authenticate once and can access multiple resources without re-entering credentials.

• Ticket-based: Authentication exchanges rely on encrypted tickets, reducing the risk of credential theft.

NTLM

NTLM is a legacy authentication protocol used primarily in older versions of Windows systems before Kerberos became the default. It was the default authentication method in Windows NT systems.

Kerberos is the default authentication method in Active Directory for domain authentication in Windows environments (since Windows 2000).

If Kerberos fails due to misconfiguration or some issue, the system falls back to NTLM.

• Windows systems are designed to fall back to NTLM if:
  • The KDC (Domain Controller) is not reachable
  • The client or service does not support Kerberos
  • Clock skew or SPNs are misconfigured

🧾 How NTLM Authentication Works (Step-by-Step):

👉 Step 1: User sends username to the server

The client sends only the username (not password) to the server.

👉 Step 2: Server sends a challenge

The server responds with a random 16-byte challenge (nonce).

👉 Step 3: Client encrypts the challenge using a hash of the user’s password

The client:

• Hashes the password using NT hash.

• Uses this hash to encrypt the challenge.

• Sends this encrypted value back to the server.

👉 Step 4: Server verifies the response

The server contacts a Domain Controller (DC):

• It sends the username and the challenge-response.

• The DC retrieves the stored NT hash of the user, encrypts the challenge the same way, and compares it.

✅ If both match → Authentication is successful.

⚠️ Key Points:

• No tickets involved (unlike Kerberos).

• Does not require a Domain Controller (DC), making it usable in workgroup environments.

• It relies on password hashes, making it vulnerable to:

  • Pass-the-Hash attacks
  • NTLM Relay attacks
  • Brute-force

• NTLM is still used in fallback scenarios when Kerberos fails (e.g., during domain misconfigurations or cross-domain issues).

🧠 Real-World Example:

You try to access a shared folder on another computer that’s not part of the domain — NTLM is used to authenticate your credentials.

Features:

Compatibility: NTLM is supported by older Windows systems and applications.

Simplicity: NTLM authentication does not require the complexity of Kerberos, making it easier to implement in certain environments.

Security: NTLM has security limitations compared to Kerberos, including susceptibility to pass-the-hash attacks and lack of mutual authentication.

LDAP

LDAP (Lightweight Directory Access Protocol) is primarily used to query and manage directory information (like Active Directory users, groups, OUs). However, it also supports user authentication via bind operations.

There are two common ways LDAP is used for authentication:

🔹 1. Simple Bind (Username + Password)

• The client connects to the LDAP server (Domain Controller).

• Sends username (Distinguished Name or UPN) and password.

• The LDAP server validates the credentials against the directory.

• If correct → user is authenticated.

⚠️ If not using LDAPS (port 636), the credentials are sent in plain text – a big security risk.

🔹 2. SASL Bind (Kerberos or NTLM integration)

• LDAP can delegate authentication to other secure methods like Kerberos or NTLM via SASL (Simple Authentication and Security Layer).

• This is more secure and common in domain environments.

🔁 LDAP vs NTLM for Authentication

🧠 Real-World Example:

• In enterprise web apps, LDAP (via LDAPS) is often used to authenticate users logging into internal tools.

• In Windows login, Kerberos is preferred, with NTLM as a fallback. LDAP may still be used after authentication to fetch user details.

Kerberos Authentication

Understanding The Core Concept

• Legitimate User: Begins the communication for a service request.

• Application Server: The server with the service the user wants to access.

• Key Distribution Center (KDC): KBRTGT account acts as a service account for the Key Distribution Center (KDC) and separated into three parts: Database (db), Authentication Server (AS) and Ticket Granting Server (TGS).

• Authentication Server (AS): Verify client authentication. If the logged user is authenticated successfully the AS issues a ticket called TGT.

• Ticket Granting Ticket (TGT): confirms to other servers that user has been authenticated.

• Ticket Granting Server (TGS): User request for TGS from the KDC that will be used to access the service of the application server.

1️⃣ Roles: Who’s Who in Kerberos (DC vs KDC)

In a Windows domain:

🧠 Domain Controller (DC)

The DC:

• Stores user & service account secrets (not plaintext passwords)

• Stores:

  • NT hash
  • Kerberos long-term keys (AES/RC4 derived from passwords)

• Hosts the KDC service

🎟️ Key Distribution Center (KDC)

The KDC is a service running on the DC.

It has two logical parts:

So in Windows:

DC = the server

KDC = a service running on the DC

AS + TGS = logical parts of the KDC

2️⃣ What Does the DC Store for Each Account?

When a user sets a password:

Example user:

Username: alice

Password: Winter@2024

The DC stores:

• ❌ NOT the password

• ✅ Derived secrets (keys) from the password:

RC4_Key   = KDF_RC4("Winter@2024")

AES256_Key = KDF_AES256("Winter@2024", salt)

Same for service accounts:

Service: MSSQL

Account: sqlsvc

Password: S3rvice!Pass

DC stores:

RC4_Key(sqlsvc)

AES256_Key(sqlsvc)

These are called long-term keys.

Authentication Steps ( Main )

🔁 Step-by-Step Kerberos Authentication

Let’s break Kerberos down into 6 simple steps that happen behind the scenes:

✅ Step 1: AS-REQ — Authentication Request

🧠 Goal: Get a Ticket Granting Ticket (TGT)

• Alice logs into her domain-joined Windows machine.

• Her machine sends an AS-REQ to the Domain Controller (KDC):

  • Her username
  • A timestamp encrypted with her password-derived key
  • Realm and encryption details

📢 “Here’s who I am and proof that I know my password.”

✅ Step 2: AS-REP — Authentication Reply

🧠 Goal: Receive a TGT and session key

• The KDC verifies Alice’s identity and replies:
  • A TGT (Ticket Granting Ticket) — encrypted with the KDC’s key
  • A session key — encrypted using Alice’s key

📢 “Here’s your TGT and a session key to talk securely.”

✅ Step 3: TGS-REQ — Requesting Service Access

🧠 Goal: Access a specific service (e.g., file server)

• Alice wants to access a service like \\fileshare.corp.local.

• Her machine sends the TGT and a new authenticator to the TGS part of the KDC.

• It also includes the SPN of the service she wants.

📢 “Here’s my TGT. I’d like access to this service.”

✅ Step 4: TGS-REP — Receiving a Service Ticket

🧠 Goal: Get a service ticket to access the requested resource

• The KDC replies with:
  • A Service Ticket (encrypted with the service’s key)
  • A new session key (encrypted for Alice)

📢 “Here’s your access ticket for that service.”

✅ Step 5: AP-REQ — Accessing the Service

🧠 Goal: Use the service ticket to prove identity

• Alice’s system sends the service ticket and an authenticator to the target service.

📢 “Here’s my ticket and proof I’m really using it right now.”

✅ Step 6: Authorization with PAC

🧠 Goal: Service verifies permissions

• The service decrypts the ticket and reads Alice’s PAC (Privilege Attribute Certificate).

• It checks:

  • Who she is
  • What groups she’s in
  • Whether she’s allowed access

📢 “Access granted. You have the required permissions.”

Getting TGT ( InDepth )

Step-by-Step Kerberos Login (User Gets TGT) — With Meaning

🎯 Goal:

User wants to log in and get a TGT (Ticket Granting Ticket) so they don’t have to re-type the password for every service.

Step 1️⃣ User types username + password (Client-side only)

Username: alice

Password: Winter@2024

Client derives keys locally:

UserKey = KDF("Winter@2024")

What this means (important conceptually):

• The password is never sent to the network.

• The derived key is never sent either.

• The key is just a cryptographic representation of the password.

• Both the client and the KDC can independently compute the same key because they both know the password-derived secret (the KDC from storage, the client from user input).

Think of it like:

The password becomes a cryptographic “lock key” used to open messages, but the lock itself is never transmitted.

Step 2️⃣ Client asks KDC for TGT (AS-REQ)

Client → KDC:

"Hi KDC, I am alice"

What’s really happening:

• This is just an identity claim, not proof.

• The KDC doesn’t trust the client yet.

• At this point, anyone can say “I am alice.”

• The real proof comes in the next step when the client must decrypt something that only the real alice can decrypt.

Step 3️⃣ KDC creates a TGT for Alice

KDC looks up alice in the DC database:

Stored_UserKey = KDF("Winter@2024")

KDC creates the TGT:

TGT = {

  username: alice,

  user_sid: S-1-5-21-...,

  groups: [Domain Users],

  session_key: random_key,

  expiry: 10 hours

}

Encrypted with KDC’s secret key.

What this means:

• The TGT is basically Alice’s passport inside the domain.

• It proves: “This user was authenticated by the KDC.”

• The TGT is encrypted with the KDC’s own key so:

  • Clients cannot read or modify it
  • Only the KDC can validate it later

This prevents:

• Ticket forgery

• Privilege tampering (no one can edit their group membership inside the ticket)

Step 4️⃣ KDC sends TGT + session key encrypted for user (AS‑REP)

Encrypted_For_User = Encrypt(UserKey, session_key)

KDC → Client:

  - TGT (encrypted for KDC)

  - Encrypted session key (encrypted for alice)

KDC encrypts the session key using Alice’s password‑derived key:

Encrypted_For_User = Encrypt(UserLongTermKey, logon_session_key)

KDC sends:

KDC → Client:

  - Encrypted_TGT

  - Encrypted_For_User

✅ Meaning

This is the real authentication challenge:

“If you are really Alice, you can decrypt this session key using your password‑derived key.”

The KDC still never sees Alice’s password.

Step 5️⃣ Client decrypts using its derived key

session_key = Decrypt(UserKey, Encrypted_For_User)

✔ If password correct → decrypt works

❌ If password wrong → decrypt fails

What this proves:

• The client has proven knowledge of the password without sending it.

• This is how Kerberos avoids:

  • Password transmission
  • Replay attacks
  • Network sniffing credential theft

At this point:

Alice is authenticated and holds a TGT, which she can reuse for hours without retyping her password.

Getting TGS ( InDepth )

Step-by-Step: Accessing a Service (Getting TGS)

Now Alice wants to access SQL.

Step 6️⃣ Client asks for TGS (TGS-REQ)

Client sends:

• TGT

• Authenticator (timestamp encrypted with session_key)

• SPN: MSSQL/sql01.domain.local

What this means:

• The TGT proves Alice authenticated earlier.

• The Authenticator proves:

  • This is Alice right now (not a replayed packet)

• The SPN tells the KDC:

  • “I want a ticket for this specific service.”

Session Key sent by KDC on step 4 ( AS-REP )

TGS_REQ = {

TGT: <ticket_granting_ticket_from_step_4>,

Authenticator: Encrypt(session_key, current_timestamp),

SPN: "MSSQL/sql01.domain.local"

}

This prevents:

• Replay attacks

• Ticket reuse by attackers who captured old traffic

Step 7️⃣ KDC builds the Service Ticket (TGS)

TGS = {

  user: alice,

  groups: [Domain Users],

  session_key_user_service: random_key,

  expiry: 8 hours

}

Encrypted using service account key:

Encrypted_TGS = Encrypt(ServiceAccountKey, TGS)

What this means:

• The KDC is vouching for Alice to the service.

• The ticket is encrypted with the service’s password-derived key so:

  • Only that service can open it

• This is how the service trusts the user:

  • “If the KDC encrypted this for me, I trust the contents.”

This is the exact design that enables Kerberoasting:

Attackers steal this encrypted blob and try to crack the service account password offline.

Step 8️⃣ Client presents TGS to service

Client → SQL:

Here is my TGS

Service decrypts:

Decrypt(ServiceAccountKey, Encrypted_TGS)

✔ Works → user authenticated

❌ Fails → ticket is fake or corrupted

What this means:

• The service never talks to the KDC directly.

• The service trusts the KDC because:

  • Only the KDC could encrypt something using the service account’s secret

• The service now has:

  • User identity
  • Group memberships
  • Session key to securely talk to the user

This is mutual trust:

KDC trusts the service.

Service trusts the KDC.

User trusts the KDC.

🔐 How Kerberos Achieves Password-less Access After Login

The secret lies in a clever use of tickets. Here’s how it flows, step by step:

1. Login (Initial Authentication)

   When you log in, your username and password are used once to request a special ticket called the TGT (Ticket Granting Ticket) from the Authentication Service (AS) — part of the KDC (Key Distribution Center).

   ✅ Your password isn’t stored or reused — it’s used just to prove who you are.

2. TGT Stored Securely

   This TGT is stored securely on your system and can be reused to request other tickets — it’s like your personal pass that proves your identity.

3. Accessing a Service (e.g., File Server)

   When you try to access a service (like a file share or a web app), your system doesn’t ask you for your password again. Instead, it sends the TGT to the Ticket Granting Service (TGS) — also part of the KDC — and says:

   “Hey, I need a ticket to access this service. Here’s my TGT as proof I’m allowed.”

4. Service Ticket Issued

   If the TGT is valid, the TGS issues a Service Ticket, which your computer then sends to the target service (e.g., a file server).

5. You’re In! 🎉

   The service reads the ticket, verifies it, and grants you access — no password prompt needed.

PAC (Privilege Attribute Certificate)

Understanding PAC

Great fundamental question. Let me build this up from scratch.

What is PAC? (Simple Definition)

PAC = A certificate inside a Kerberos ticket that tells services what permissions you have.

Think of it like this:

Your Kerberos Ticket = Your ID card

├─ Name: John Doe

├─ Department: Engineering

│

AND ALSO INCLUDES:

│

└─ PAC = A stamp from HR department saying:

   ├─ "John Doe is in these groups"

   ├─ "John Doe has these permissions"

   ├─ "John Doe is allowed to do X, Y, Z"

   └─ "This was signed by an authorized person"

The service doesn’t have to go check with Active Directory every time you access it. It just reads the PAC in your ticket.

Historical Context: Why PAC Was Created

Before PAC (Pre-Windows 2000)

Client requests access to file share:

Server (CIFS/SMB)

├─ Receives: Your Kerberos ticket

├─ Validates: "Ticket signature is valid"

├─ Thinks: "User is authenticated, allow access"

└─ Problem: Server has NO IDEA what permissions you have!

   └─ Server must make separate call to AD: "What groups is this user in?"

Issues:

├─ Extra network traffic

├─ Extra latency

├─ AD server load increases

└─ Complexity: Every service needed AD query capability

After PAC (Windows 2000+)

Client requests access to file share:

Server (CIFS/SMB)

├─ Receives: Your Kerberos ticket

├─ Extracts: PAC from ticket

├─ Reads: "User is in Domain Admins, Domain Users"

├─ Validates: "PAC signature is correct"

├─ Result: "I know your permissions instantly, no AD call needed!"

Benefits:

├─ No extra AD queries needed

├─ Faster access decisions

├─ Services are offline-capable

└─ Everything is self-contained in the ticket

PAC Structure (What’s Inside)

A PAC is a binary blob that lives inside your Kerberos ticket. It contains multiple buffers:

PAC (inside your Kerberos ticket)

│

├─ Buffer 0: PAC_LOGON_INFO ◄─── THE MOST IMPORTANT

│  │

│  ├─ User Identity

│  │  ├─ User Name: "jdoe"

│  │  ├─ User RID: 1106 (unique ID in domain)

│  │  └─ Domain SID: S-1-5-21-DOMAIN-ID

│  │

│  ├─ Group Memberships

│  │  ├─ Primary Group RID: 513 (Domain Users)

│  │  ├─ Group Count: 3

│  │  └─ Group RIDs/SIDs:

│  │     ├─ S-1-5-21-DOMAIN-513 (Domain Users)

│  │     ├─ S-1-5-21-DOMAIN-512 (Domain Admins) ← Would add this

│  │     └─ S-1-5-21-DOMAIN-1234 (Engineers)

│  │

│  ├─ User Flags

│  │  ├─ Account disabled?

│  │  ├─ Password expired?

│  │  ├─ Account locked?

│  │  └─ Home directory, profile path

│  │

│  └─ Other user details

│     ├─ Logon count

│     ├─ Failed logon count

│     ├─ Last interactive logon time

│     ├─ Password last set

│     └─ Account expiration time

│

├─ Buffer 1: PAC_CREDENTIAL_INFO

│  ├─ User credentials (encrypted)

│  ├─ Used for delegation

│  └─ Encrypted with session key (can't read without ticket session key)

│

├─ Buffer 2: PAC_RESOURCE_GROUPS

│  ├─ Domain-local groups from resource domains

│  ├─ Used in multi-domain forests

│  └─ Less important for single domain

│

├─ Buffer 3: PAC_DEVICE_INFO

│  ├─ Device/computer information

│  ├─ Added in Windows 10+

│  └─ For device-based access control

│

├─ Buffer 6: PAC_SERVER_CHECKSUM ◄─── CRITICAL SIGNATURE #1

│  ├─ Type: HMAC-SHA256 (or SHA1)

│  ├─ Signed over: PAC_LOGON_INFO

│  ├─ Key: KRBTGT master key

│  ├─ Length: 32 bytes (SHA256)

│  └─ Purpose: "Prove logon info wasn't tampered"

│

└─ Buffer 7: PAC_PRIVSVR_CHECKSUM ◄─── CRITICAL SIGNATURE #2

   ├─ Type: HMAC-SHA256 (or SHA1)

   ├─ Signed over: All OTHER buffers (except server checksum)

   ├─ Key: KRBTGT master key

   ├─ Length: 32 bytes (SHA256)

   └─ Purpose: "Prove everything else wasn't tampered"

Visual: Where PAC Lives in the Ticket

┌──────────────────────────────────────────────────────────┐

│              KERBEROS TICKET (TGT or Service Ticket)     │

├──────────────────────────────────────────────────────────┤

│                                                          │

│ Plaintext parts (not encrypted):                        │

│ ├─ Version number (5)                                  │

│ ├─ Ticket type (krbtgt or service)                     │

│ ├─ Realm (DOMAIN.COM)                                  │

│ └─ Server name                                         │

│                                                          │

├──────────────────────────────────────────────────────────┤

│                                                          │

│ Encrypted part (ENC_PART):                             │

│ │                                                       │

│ ├─ flags (renewable, forwarded, etc.)                  │

│ ├─ session key (for this ticket)                       │

│ ├─ client name (your username)                         │

│ ├─ timestamps:                                         │

│ │  ├─ auth_time (when you authenticated)              │

│ │  ├─ start_time (ticket valid from)                  │

│ │  ├─ end_time (ticket expires)                       │

│ │  └─ renew_till (can renew until)                    │

│ │                                                       │

│ └─ *** AUTHORIZATION DATA ***                          │

│    │                                                    │

│    └─ [CONTAINS THE PAC] ◄────── This is what we care │

│       │                          about for attacks     │

│       ├─ PAC_LOGON_INFO                               │

│       ├─ PAC_CREDENTIAL_INFO                          │

│       ├─ PAC_SERVER_CHECKSUM                          │

│       └─ PAC_PRIVSVR_CHECKSUM                         │

│                                                          │

└──────────────────────────────────────────────────────────┘

How PAC is Used in Real Authentication

Step 1: User Logs In (AS-REQ → AS-REP)

Your computer:

├─ You enter username & password

├─ Sends: AS-REQ to DC

│

DC (Domain Controller):

├─ Validates: "Password is correct"

├─ Creates: Kerberos ticket (TGT)

├─ Creates: PAC for your user

│  └─ Queries AD: "What groups is jdoe in?"

│     └─ Answer: "Domain Users, Engineers, Sales"

├─ Puts PAC inside TGT

├─ Encrypts: TGT with KRBTGT key

├─ Sends: Encrypted TGT back to you

│

You now have:

└─ TGT with your PAC inside (encrypted)

Step 2: Request Service Access (TGS-REQ → TGS-REP)

Your computer wants to access: \\fileserver\documents

You send: TGS-REQ

├─ "Here's my TGT (encrypted)"

├─ "I want service ticket for CIFS/fileserver"

│

DC processes:

├─ Decrypts your TGT

├─ Extracts your PAC

├─ Reads: "jdoe is in Domain Users, Engineers, Sales"

├─ Creates: Service Ticket for CIFS

├─ COPIES: Your PAC into service ticket

│  └─ (This is important! DC trusts your original PAC)

├─ Encrypts: Service ticket with service account key

├─ Sends: Service ticket back

│

You now have:

└─ Service Ticket with your PAC inside

Step 3: Access Resource with Service Ticket

File Server (fileserver.domain.com):

│

You send: Service ticket + request for \documents

├─ "Here's my service ticket"

├─ "I want to read \documents"

│

File Server:

├─ Decrypts: Service ticket (uses its own account key)

├─ Extracts: Your PAC from ticket

├─ Reads: "This user is in Domain Users, Engineers, Sales"

├─ Checks: Access Control List (ACL) on \documents

│  ├─ "Domain Users: Read"

│  ├─ "Engineers: Read+Modify"

│  ├─ "Domain Admins: Full Control"

├─ Validates: "User is in Engineers, so allow Read+Modify"

├─ Grants: Access with Engineer permissions

│

Result:

└─ You can read and modify documents

Key point: The file server never calls AD. It just reads your PAC.

PAC Validation (The Critical Security Step)

When a service receives your ticket, it does this:

Service receives ticket with PAC:

1. DECRYPT ticket

   ├─ Key: Service account password (known locally)

   └─ Output: Plaintext ticket contents

2. EXTRACT PAC from ticket

   ├─ Find authorization_data section

   └─ Find PAC buffer

3. VALIDATE PAC_SERVER_CHECKSUM

   ├─ Calculate: HMAC-SHA256(KRBTGT_key, PAC_LOGON_INFO)

   ├─ Compare: Against PAC_SERVER_CHECKSUM value

   ├─ Result: "Is this PAC authentic?"

   │

   ⚠️ PROBLEM: Service doesn't have KRBTGT key!

   ├─ So services send ticket back to DC

   └─ DC validates the checksum

4. SERVICE VALIDATES USER RIGHTS

   ├─ Reads: Groups from PAC (Domain Users, Engineers)

   ├─ Checks: ACLs on resource

   ├─ Grants: Access based on group memberships

   │

   ✅ This is fast, no AD query needed!

Why PAC Matters for Diamond Ticket Attack

This is where it all connects:

Normal TGT (from legitimate DC):

│

├─ Encrypted with: KRBTGT key

├─ Contains PAC showing: "jdoe is in Domain Users"

├─ PAC signed by: KRBTGT key

│

When you modify it (Diamond Ticket):

│

├─ You decrypt with: KRBTGT key (you stole it!)

├─ You change PAC to: "jdoe is in Domain Admins"

├─ You re-sign with: KRBTGT key (you stole it!)

├─ You re-encrypt with: KRBTGT key (you stole it!)

│

Result:

│

├─ Signature is valid ✓ (because you signed with correct key)

├─ Encryption is valid ✓ (because you encrypted with correct key)

├─ Services accept it ✓ (signatures check out)

└─ You get admin access ✓ (PAC says you're admin)

PAC Example (Actual Data Structure)

If we dumped a real PAC with Rubeus, it would look like:

PAC_LOGON_INFO:

├─ UserName: jdoe

├─ UserRid: 1106

├─ PrimaryGroupId: 513

├─ GroupCount: 2

├─ GroupIds:

│  ├─ 513 (Domain Users) ← Normal group

│  └─ 512 (Domain Admins) ← Added by attacker!

│

├─ UserFlags:

│  ├─ AccountDisabled: false

│  ├─ PasswordExpired: false

│  ├─ PasswordNotRequired: false

│  ├─ LockoutTime: 0

│  └─ BadPasswordCount: 0

│

├─ LogonTime: 2024-06-23 10:30:45 UTC

├─ LogoffTime: 2024-06-23 20:30:45 UTC

├─ KickoffTime: 2024-06-24 10:30:45 UTC

│

└─ LogonServer: DC01

   UserAccountControl: 0x00000210

   └─ (Normal user, password not required for Kerberos)

PAC_SERVER_CHECKSUM:

├─ ChecksumType: HmacSHA256 (23)

└─ Checksum: A3F2E1D0... (32 bytes, HMAC-SHA256 digest)

PAC_PRIVSVR_CHECKSUM:

├─ ChecksumType: HmacSHA256 (23)

└─ Checksum: B4G3F2E1... (32 bytes, HMAC-SHA256 digest)

Quick Comparison: PAC vs No PAC

With PAC (Modern Windows)

User logs in → Gets TGT with PAC

    ↓

User requests file access

    ↓

Service reads PAC from ticket

    ↓

Service checks: "User is in this group"

    ↓

Instant decision: Grant/Deny

No AD query needed! ✓

Fast! ✓

Offline capable! ✓

Without PAC (Older systems or special cases)

User logs in → Gets TGT without PAC

    ↓

User requests file access

    ↓

Service receives ticket

    ↓

Service doesn't know user's groups

    ↓

Service calls AD: "What groups is jdoe in?"

    ↓

AD responds

    ↓

Service checks ACLs

    ↓

Slow! ✗

Extra network traffic! ✗

AD must be online! ✗

PAC in Different Scenarios

Scenario 1: Normal User Access

PAC shows:

├─ User: jdoe

├─ Groups: Domain Users, Engineers

Result:

├─ Can access: Engineering shares

├─ Can't access: Finance shares

├─ Can't access: Admin shares

Scenario 2: Service Account

PAC shows:

├─ User: svc_sqldb

├─ Groups: Domain Users, SQL-Service-Accounts

Result:

├─ Can access: Database servers (specific ACL)

├─ Can't access: User file shares

├─ Can't do domain admin operations

Scenario 3: Domain Admin (Normal, Legitimate)

PAC shows:

├─ User: admin_user

├─ Groups: Domain Users, Domain Admins, Enterprise Admins

Result:

├─ Can access: Everything

├─ Can modify: Anything

├─ Can run: Privileged operations

Scenario 4: Domain Admin (Forged Diamond Ticket)

Original PAC shows:

├─ User: jdoe

├─ Groups: Domain Users ← Low privilege

Attacker modifies PAC to show:

├─ User: jdoe ← Still jdoe!

├─ Groups: Domain Admins ← FORGED!

Result:

├─ jdoe appears to be admin

├─ Can access: Admin shares

├─ But behavior anomaly: Low-priv user as admin

└─ Detection: Why is jdoe accessing admin resources?

Summary: What is PAC?

PAC = Permission certificate in your ticket

It contains:

├─ Your username

├─ Your user ID (RID)

├─ Your group memberships (SIDs)

├─ Your account flags

└─ Cryptographic signatures proving DC created it

Why it exists:

├─ Services don't need to call AD every time

├─ Tickets are self-contained

├─ Faster authorization decisions

└─ Can work offline

Why it's important for attacks:

├─ If you modify PAC → you change permissions

├─ But you need KRBTGT key to sign it

├─ Services validate signature (but trust KRBTGT)

└─ This is the core of Diamond Ticket attack

Security:

├─ Protected by: HMAC-SHA256 signatures

├─ Signed with: KRBTGT key

├─ Validated by: Services (implicitly trusting DC)

└─ Compromised by: Anyone with KRBTGT key

Sam Security & System

Overview

• The SAM database stores local user account hashes on Windows.

• Having access to SAM hashes enables offline password cracking, which means we don’t need to maintain an active session with the target while trying to crack passwords.

• To extract hashes, you need local admin access on the target machine.

• You will copy registry hive files related to SAM, transfer them to your attack machine, then dump the hashes using tools like Impacket’s secretsdump.py, and finally crack the hashes offline using Hashcat.

Key Registry Hives to Copy

• Technically, sam and system are necessary.

• security can be helpful if domain credentials are cached.

🗃️ What Are Registry Hives in Windows?

Registry Hives are logical groupings of keys, subkeys, and values in the Windows Registry — a centralized database used to store configuration settings for the operating system, hardware, users, and applications.

Each hive is a root of a section of the registry and is backed by a corresponding file on disk.

📂 Common Registry Hives

🧠 Internal View (System Hives)

When performing credential attacks or forensic analysis, the most important hives are:

• SAM: Security Account Manager — stores local user accounts and password hashes.

• SECURITY: Stores LSA secrets like service passwords.

• SYSTEM: Contains system settings like boot info and control sets (used with SAM/SECURITY).

• SOFTWARE: Installed applications and configuration data.

These are found in:

C:\Windows\System32\config\

🔥 1. WHAT EXACTLY ARE THE HIVES + WHERE THEY ARE STORED

Windows stores local system configuration and secrets in file-based “hives” located at:

C:\Windows\System32\Config\

These hives are loaded into memory during boot.

⚙️ 2. WHY THESE HIVES EXIST (THEIR PURPOSE)

Windows needs:

• a place to store local accounts → SAM

• a place to store encryption keys & system secrets → SECURITY

• a place to store system configuration + the BootKey → SYSTEM

They are core components of Windows login and encryption mechanisms.

If any one hive is missing → Windows cannot boot.

🔵 3. SYSTEM Hive (Root of Trust)

System hive contains:

• The BootKey (SysKey): fundamental key used to decrypt SAM & SECURITY hives

• System-wide configuration

• ControlSets (device drivers, services, etc.)

Registry Location:

HKLM\SYSTEM

BootKey fragmentation location:

HKLM\SYSTEM\ControlSet00X\Control\Lsa\JD

HKLM\SYSTEM\ControlSet00X\Control\Lsa\Skew1

HKLM\SYSTEM\ControlSet00X\Control\Lsa\GBG

HKLM\SYSTEM\ControlSet00X\Control\Lsa\Data

Windows uses these 4 keys → concatenates → permutes → BootKey.

Why stored here?

Because Windows needs a machine-level encryption root accessible at boot BEFORE authentication.

SYSTEM hive = root crypto anchor.

🔵 4. SAM Hive (Local Account Database)

SAM hive contains:

• Local user records

• RIDs

• NTLM hashes (encrypted)

• Password history

• Account metadata

Registry location:

HKLM\SAM

File location:

C:\Windows\System32\Config\SAM

Why stored here?

SAM = Windows needed a local user database before Active Directory even existed.

It is still required for:

• Local Administrator

• Local users on standalone machines

• Laptop local account logins (even domain-joined laptops have local accounts)

• Services running under local accounts (LocalService, NetworkService)

• Recovery console / Safe Mode logins

SAM is ALWAYS present. The OS cannot function without it.

🔵 5. SECURITY Hive (LSA Secret Storage)

Contains:

• LSA secrets (service account passwords, cached domain creds, DPAPI system keys, etc.)

• Secret encryption key (“LSA Key”)

• Policy information

Registry location:

HKLM\SECURITY

File:

C:\Windows\System32\Config\SECURITY

Why stored here?

Because the Local Security Authority (LSA) needs a secure store to record:

• system-wide cryptographic secrets

• sensitive policy data

• service account credentials

• secret keys

If this hive is missing → LSA cannot decrypt anything → all authentication breaks.

🧠 6. How These Hives Work Together (Crypto Flow)

SYSTEM hive creates the BootKey

↓

BootKey decrypts:

• SAM Key in SAM hive

• LSA Key in SECURITY hive

↓

SAM Key decrypts user password hashes

(then RID-based DES decryption yields final NT hashes)

↓

LSA Key decrypts stored secrets

This is a layered security architecture.

🔥 7. ARE THESE HIVES PRESENT ON ALL SYSTEMS? (YES!)

Every Windows machine has all 3 hives.

They are built-in core OS components.

🏛️ 8. Then why do Domain Controllers also have a SAM?

DCs store domain credentials in:

NTDS.dit

NOT in the SAM hive.

However, DCs STILL USE SAM for:

✔ 1. Local system accounts (different from domain accounts)

• Administrator (RID 500)

• LocalSystem

• LocalService

• NetworkService

These exist even on DCs.

✔ 2. Boot-time authentication

Before NTDS initializes, Windows still uses SAM for:

• system startup processes

• recovery mode / DSRM (Directory Services Restore Mode)

✔ 3. Offline repair mode

DSRM password is the password for the DSRM Administrator account → stored in SAM, not NTDS.

✔ 4. LSA still needs SAM for local policies

Active Directory doesn’t replace the local security subsystem.

🔥 So even DCs cannot get rid of SAM.

🧪 9. Do Domain-Joined Workstations Still Use SAM?

YES. Absolutely.

They authenticate:

• Local accounts (local admin, local users)

• Machine account passwords (machine$)

• Services running as local accounts

When a user logs in with a domain account, the credential verification happens using the domain controller — NTDS.dit.

But the machine STILL uses SAM to store:

• the machine account password

• local users

• system accounts

So a domain-joined machine has 2 credential ecosystems:

🧨 10. Why Windows Didn’t Move Everything to NTDS.dit?

Because:

✔ NTDS.dit exists ONLY on Domain Controllers

✔ Workstations and member servers must still function without AD (offline login)

✔ Local accounts are needed for:

• system boot

• safe mode

• recovery

• local services

• fallback admin access

Windows architecture relies on local security even inside a domain.

⚡ MASTER SUMMARY (Super Clean)

Lssas & LSA

Understanding Lsass + Lsa + Wdigest

✅ 1. What is LSA?

LSA = Local Security Authority

LSA is a Windows security subsystem responsible for:

• Authentication

• Authorization

• Local Security Policy

• Token generation

• Password validation

• SID ↔︎ Username mapping

• Credential management (via packages)

LSA is a set of DLLs & internal APIs, NOT a process.

Key DLLs LSA loads internally:

Important:

LSA is responsible for everything; LSASS is simply the process running LSA code.

✅ 2. What is LSASS?

LSASS = Local Security Authority Subsystem Service

This is the process running LSA.

• Process name: lsass.exe

• Location: C:\Windows\System32\lsass.exe

• Runs as SYSTEM

• Protected by PPL (Protected Process Light) on modern Windows

LSASS:

• Hosts LSA

• Holds all sensitive credential material in memory

• Communicates with SAM, SECURITY, SYSTEM hives

• Generates & manages tokens

• Stores Kerberos tickets, cached NTLM hashes, DPAPI master keys

• Stores plaintext passwords under certain conditions

✅ 3. DIFFERENCE: LSA vs LSASS (super clear)

In simple terms:

⮞ LSA is the brain.

⮞ LSASS is the body that runs the brain.

⮞ Attackers dump LSASS because the secrets exist in RAM inside LSASS.

✅ 4. Does LSASS store cached passwords?

Yes — but not “cached logon credentials” from registry.

Let’s clarify:

✔ LSASS stores:

• NTLM password hashes

• Kerberos TGT sessions / tickets

• WDigest plaintext passwords (if enabled)

• CredMan credentials (saved RDP passwords, mapped drives)

• DPAPI master keys

• LMSessionKey / NTLM Session keys

• Kerberos service tickets

• Cleartext passwords during interactive login briefly

❌ LSASS does NOT store:

MS-Cache v1/v2 cached domain logon hashes

Those are stored in registry under:

HKLM\SECURITY\Cache

Cached domain logon hashes ≠ plaintext, and LSASS does not load them into memory unless group policy / auth packages require it.

❗ Does LSASS store plaintext passwords?

Yes, depending on authentication package loaded.

So plaintext appears during:

• interactive logon

• RDP logon

• RunAs

• Unlocking machine

• Some SSO flows

After authentication, plaintext might persist in LSA memory depending on packages.

⭐ What LSASS 100% stores in memory

• NT hash of logged-on users

• Kerberos TGT & service tickets

• DPAPI Master Keys → Needed to decrypt browser creds, wifi creds

• LsaSecrets (machine account passwords, cached service creds)

• Credential Manager vault entries (saved passwords)

This is why tools like:

• mimikatz.exe

• pypykatz

• comsvcs.dll mini dump

• procdump + sekurlsa

  are used to dump LSASS.

✅ 5. Cached Credentials (Registry) vs Credentials in LSASS (Memory)

✔ Cached DOMAIN LOGON credentials (Registry)

Location:

HKLM\SECURITY\Cache\NL$1 ... NL$10

Contains:

• MS-Cache v2 hashes

• Used when domain controller unavailable

• Not plaintext

• Benefit: Can log into laptop offline

These DO NOT come from LSASS memory.

✔ Credentials LSASS stores in Memory

These are “live session credentials”:

• password → maybe plaintext

• NT hash

• Kerberos TGT

• DPAPI key

• RDP creds

• Token handles

Big difference:

• Registry cached creds: used only for domain fallback

• LSASS creds: used for active sessions → what Mimikatz extracts

🔐 What is WDigest?

• As part of WDigest authentication provider, Windows versions up to 8 and 2012 used to store logon credentials in memory in plaintext by default, which is no longer the case with newer Windows versions.

• It is still possible, however, to force WDigest to store secrets in plaintext.

🔐 WDigest on Modern Windows Servers (2012 R2 / 2016 / 2019 / 2022)

✅ Does WDigest Still Exist?

✔ Yes

✔ Microsoft did not remove WDigest

✔ WDigest is still loaded by LSASS as an authentication package

✔ It sits alongside:

➜ Kerberos

➜ NTLM

➜ Negotiate

➜ WDigest

🚫 What Changed After Security Updates?

Older Windows:

✔ User logs in

✔ LSASS stores plaintext password

✔ Credential dumping tools could recover it

Modern Windows:

✔ User logs in

✔ WDigest still exists

❌ Plaintext password caching disabled by default

Result:

➜ Username visible

➜ Domain visible

➜ Password often unavailable

👨‍💼 Can An Administrator Re-Enable It?

✔ Yes

A local administrator can change the WDigest configuration.

After enabling:

✔ Future authentication events may cause plaintext credentials to be cached again.

⚠ Important Detail Most Students Miss

Imagine:

09:00

✔ User Daniel logs in

WDigest plaintext caching disabled.

10:00

✔ Administrator enables WDigest

At this point:

❌ Daniel’s existing password does NOT suddenly appear in LSASS.

Why?

Because LSASS never stored it during the earlier login.

✅ What Must Happen Next?

A fresh authentication event.

Examples:

✔ User logs out and logs in again

✔ User unlocks workstation

✔ User reconnects via RDP

✔ User authenticates to Windows again

Then:

New Authentication

        ↓

WDigest Enabled

        ↓

Password Cached

Now LSASS may contain the plaintext credential.

🧠 Is The Password Visible On Screen?

❌ No

Many beginners imagine:

Username : Daniel

Password : Password123

appearing somewhere.

That is NOT how it works.

Password is stored:

✔ Inside LSASS process memory

✔ In protected memory structures

✔ Not visible to normal users

✔ Not displayed in CMD

✔ Not displayed in Event Viewer

✔ Not displayed in Task Manager

🔍 Why Do Attackers Care Then?

Because if an attacker gains:

✔ Local Administrator

or

✔ SYSTEM privileges

they may be able to inspect LSASS memory and recover credentials that are present there.

🔐 What About Domain Admins?

Suppose:

✔ Domain Admin logs into Server01

WDigest plaintext caching enabled.

Then:

Domain Admin Login

        ↓

LSASS

        ↓

Plaintext Credential Cached

Now that server becomes a very attractive target.

Because compromising the server could expose highly privileged credentials.

🛡️ Credential Guard Changes Things

Modern enterprises often enable:

Windows Defender Credential Guard

Credential Guard:

✔ Isolates secrets

✔ Protects many credentials from normal LSASS dumping

✔ Makes credential theft significantly harder

Now as an attacker, we can modify the following registry key to force the WDigest to store credentials in plaintext next time someone logs on to the target system:

sekurlsa::wdigest

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1

Say, now the victim on the target system spawned another shell:

victim@local

runas/user:mantvydaspowershell

Running mimikatz for wdigest credentials now reveals the plaintext password of the victim user mantvydas:

❓ Does LSASS store domain credentials if the machine is domain joined?

Yes.

When a user logs in to a domain-joined machine:

• DC sends Kerberos TGT

• LSASS stores TGT, session key

• NT hash of the user is stored (not always, but usually)

• Machine account password is stored as an LSA secret

• CredMan stored entries are in LSASS memory

❓ Why does LSASS store credentials?

Because Windows requires:

1. Single sign-on (SSO)

To access SMB, LDAP, RPC, WinRM, Kerberos tickets → LSASS needs your credentials.

2. Token re-creation

If your session needs to impersonate or access network resources, LSASS must re-use keys.

3. DPAPI

Decrypting saved credentials & browser passwords requires DPAPI master keys → stored in LSASS.

❓ Does LSA store passwords on disk?

No.

Only these files contain static secrets:

SAM hive → local user password hashes

C:\Windows\System32\config\SAM

SECURITY hive → LSA secrets + cached domain creds

C:\Windows\System32\config\SECURITY

SYSTEM hive → BootKey to decrypt SAM & SECURITY

C:\Windows\System32\config\SYSTEM

LSASS loads the decrypted content of SAM + SECURITY into memory.

🔥Summary (extremely clear):

LSA

• Windows security subsystem

• Implements authentication logic

• Stores LSA secrets (conceptually)

LSASS

• Process executing LSA

• Runtime memory contains:

  ✔ NTLM hashes

  ✔ Kerberos tickets

  ✔ Plaintext passwords (sometimes)

  ✔ DPAPI master keys

  ✔ Credential Manager entries

  ✔ LSA secrets

👑 Final Clear Answers to Your Doubts

Does LSA store cached passwords?

LSA → No direct storage

LSASS → Yes, keeps live credentials in memory

Registry → stores cached domain password hashes

Does LSASS store cached passwords?

Not MS-Cache, but stores live session creds, including plaintext.

Does LSASS store plaintext?

Yes — depending on authentication package (e.g., WDigest, NTLM, RDP logon).

Do all Windows systems use SAM/SYSTEM/SECURITY?

Yes → Both domain-joined & standalone

Domain joined also uses NTDS.dit on DCs (only if machine IS the domain controller).

🔐 Protected Process Light (PPL) Deep Dive

This is a very common topic in:

• Red Team Interviews

• Windows Internals Interviews

• Active Directory Assessments

• EDR Bypass Discussions

📜 What is PPL?

PPL (Protected Process Light) is a Windows security mechanism that prevents even highly privileged processes from opening or manipulating certain protected processes.

Introduced by Microsoft to protect security-critical components such as:

• LSASS

• Credential Guard components

• Antivirus processes

• EDR processes

🚀 When Was It Introduced?

Windows Vista (2007)

Microsoft introduced:

Protected Process (PP)

Used mainly for:

• DRM

• Media Protection

Examples:

• Audio DRM

• Video DRM

Very restrictive.

Windows 8.1 / Server 2012 R2 (2013)

Microsoft introduced:

Protected Process Light (PPL)

Purpose:

• Protect security products

• Protect LSASS

• Protect AV/EDR

This is the version everyone refers to today when discussing LSASS protection.

🎯 Why Was PPL Needed?

Before PPL:

Administrator → Open LSASS → Read memory → Dump credentials

Tools like:

• Mimikatz

• ProcDump

• Task Manager

• Custom malware

could directly access LSASS.

🤔 What is LSASS?

LSASS

(Local Security Authority Subsystem Service)

Responsible for:

✔ User Authentication

✔ Kerberos

✔ NTLM

✔ Token Creation

✔ Security Policy Enforcement

What LSASS Contains

After users authenticate:

LSASS may contain:

NTLM Data

• NTLM hashes

• Cached credentials

Kerberos Data

• TGTs

• Service Tickets

Access Tokens

Example:

User logs in → Windows creates token → LSASS tracks authentication state

Credential Material

Depending on configuration:

• Cached domain credentials

• SSP secrets

• Delegated credentials

💀 Why Attackers Love LSASS

Imagine:

Domain Admin logs into server.

LSASS now contains:

• Domain Admin TGT

• NTLM material

• Authentication tokens

Attacker dumps LSASS. → Extracts credentials. → Moves laterally. →Compromises domain.

This was one of the most common AD attack paths for years.

🛡️ How PPL Protects LSASS

Lets see it in action on Windows Server 2012 R2. Before the change you can see I am able to dump the lsass process to a file from task manager:

This file could then be used with mimikatz on or offline to extract NTLM password hashes for cached credentials.

Lets make the change, and reboot:

And after:

Good! And if we try to run mimikatz on the server:

This doesn’t offer total protection however if we can slow down our adversaries and try to stay one step ahead we are in a better place than before. Clearly if you have plugins in your environment that need to interact with the lsass process this may break things so testing is a must, there is an auditing mode highlighted here that will help identify any that fail.

🔍 What Actually Happens Internally?

Every process gets a:

Protection Level

Stored in kernel structures.

Examples:

When another process attempts:

• OpenProcess()

• ReadProcessMemory()

• DuplicateHandle()

Kernel checks:

“Is caller trusted enough?”

If not:

❌ Request denied

even if:

• Local Administrator

• SYSTEM

in many cases.

🏗️ Protection Hierarchy

Think:

Normal Process → SYSTEM Process → Protected Process Light → Protected Process

Higher levels can access lower levels.

Lower levels cannot access higher levels.

Example

Attacker obtains:

SYSTEM Shell

Without PPL:

SYSTEM → Open LSASS → Read Memory

Success.

With PPL:

SYSTEM → Open LSASS → Kernel Protection Check → Denied

Failure.

Why Mimikatz Suddenly “Stopped Working”

Years ago:

Admin → Run Mimikatz →sekurlsa::logonpasswords → Hashes dumped

Today:

Admin → Run Mimikatz → LSASS is PPL → Access denied

This is one of the main reasons organizations enable PPL.

🚩 Common PPL Bypasses

The key idea:

PPL is enforced by the Kernel

Therefore:

If attacker controls kernel → PPL becomes irrelevant.

1️⃣ Kernel Exploitation

Concept

Exploit a vulnerable kernel component.

User Mode → Kernel Vulnerability → Kernel Execution → Disable PPL

Why It Works

Kernel is above PPL.

PPL trusts the kernel.

If attacker gains kernel execution:

✔ Remove protection

✔ Modify process structures

✔ Access LSASS

Example

Historical examples:

• Win32k vulnerabilities

• Privilege escalation bugs

Such as:

CVE-2021-1732

Flow:

User→ Exploit Win32k→ Kernel Access → Bypass PPL → Dump LSASS

2️⃣ BYOVD (Bring Your Own Vulnerable Driver)

Most important modern bypass.

Interview favorite.

Concept

Instead of exploiting Windows:

Bring a vulnerable signed driver.

Flow:

Admin Rights → Load Vulnerable Driver→ Driver Executes In Kernel→ Disable PPL → Read LSASS

Why So Powerful?

Driver runs in:

Ring 0

Kernel Mode

PPL cannot stop kernel code.

Famous Drivers Seen in Attacks

Attackers abuse vulnerable drivers from:

• MSI

• ASUS

• Gigabyte

• Dell

These are legitimate signed drivers.

Common Tools

Examples seen in red teaming:

• PPLKiller

• EDRSandblast

• KDU

All heavily rely on driver abuse concepts.

3️⃣ Direct Kernel Object Manipulation (DKOM)

Advanced technique.

Windows stores process metadata in:

EPROCESS

Kernel structure.

Contains:

• PID

• Token

• Protection Level

Attacker with kernel access:

Find EPROCESS → Locate Protection Field → Modify Value → LSASS no longer protected

PPL removed.

4️⃣ Exploiting a Trusted PPL Process

Concept:

A trusted process already has permission.

Instead of attacking LSASS:

Attack trusted process.

Example:

Security Product → Code Injection Vulnerability → Execute inside trusted process→

Access LSASS

Rare but possible.

5️⃣ Token Theft / SYSTEM Access

⚠️ Common interview trap.

Many people think:

“Getting SYSTEM bypasses PPL.”

This is FALSE.

SYSTEM

❌ Does not automatically bypass PPL

Kernel still enforces protection.

SYSTEM is useful because:

SYSTEM→ Load Driver → Exploit Driver → Gain Kernel → Bypass PPL

SYSTEM alone ≠ PPL bypass

6️⃣ PPL Downgrade Attack

Goal:

Convert:

LSASS (PPL)

↓

LSASS (Unprotected)

Requires:

• Kernel access

or

• Vulnerable driver

Attacker modifies protection fields.

Result:

Normal tools can access LSASS again.

7️⃣ DMA / Physical Attacks

Less common.

Examples:

• PCILeech

• DMA hardware

Hardware device→ Direct Memory Access → Read RAM → Extract LSASS Data

PPL cannot stop hardware memory reads.

📊 Most Common Modern Real-World Bypass

If you’re interviewing:

#1 Answer

BYOVD

Reason:

• Doesn’t require zero-day exploit

• Frequently seen in ransomware

• Frequently seen in APT operations

• Frequently used against EDRs

Many modern attacks:

Admin Rights → Load Vulnerable Signed Driver→ Kernel Access→ Disable PPL→ Dump LSASS

Enabling PPL - Registry Modification Explained

Breaking Down the Registry Path

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\

│

├─ HKEY_LOCAL_MACHINE (HKLM)

│   └─ Registry hive on local computer

│

├─ SYSTEM

│   └─ Stores hardware & kernel settings

│

├─ CurrentControlSet

│   └─ Active configuration (Control Set 1, 2, or 3)

│   └─ Windows uses this during boot

│

├─ Control

│   └─ System control settings

│

└─ Lsa

    └─ Local Security Authority settings

       (where LSASS protection configs live)

The DWORD Entry: RunAsPPL

What is it?

Name:  RunAsPPL

Type:  REG_DWORD (32-bit integer)

Value: 1 = Enabled | 0 = Disabled

What it Controls

RunAsPPL = 1  →  LSASS runs as Protected Process Light

RunAsPPL = 0  →  LSASS runs as normal process

Why It Requires a Reboot

The Timeline:

CURRENT STATE (Before Reboot)

├─ Windows already booted

├─ LSASS.exe already running in memory

├─ Registry change made (RunAsPPL = 1)

└─ But LSASS doesn't know about it yet!

              ↓ RESTART ↓

BOOT PROCESS (During Reboot)

├─ Windows reads registry

├─ Kernel reads HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL

├─ Sees value = 1

├─ Loads LSASS as Protected Process Light

└─ Protection now active ✓

Why Not Immediate?

LSASS is a kernel-level process that starts very early in boot:

1. Registry is loaded

2. Kernel initializes

3. LSASS starts → reads RunAsPPL value

4. Kernel applies PPL protection to LSASS

5. LSASS now protected for entire session

You can't change LSASS protection while it's running because:

- It's a kernel-level decision

- Changing process protection mode requires kernel reload

- LSASS can't modify its own protection

How to Make the Change (Step-by-Step)

Method 1: Registry Editor GUI

1. Press Win + R

2. Type: regedit

3. Navigate: HKLM → SYSTEM → CurrentControlSet → Control → Lsa

4. Right-click in empty space → New → DWORD (32-bit) Value

5. Name it: RunAsPPL

6. Set value: 1

7. Click OK

8. Close regedit

9. Restart Computer

Method 2: PowerShell (Admin)

powershell

# Add or modify the registry entry

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\" `

                 -Name "RunAsPPL" `

                 -Value 1 `

                 -Type DWord -Force

# Verify it was created

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\" -Name RunAsPPL

# Output should show:

# RunAsPPL : 1

Method 3: Command Prompt (Admin)

cmd

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL

What Happens During Boot

Without RunAsPPL (Normal):

Boot → LSASS starts → No PPL protection → Vulnerable to attacks

With RunAsPPL = 1 (Protected):

Boot → Kernel reads registry → RunAsPPL = 1 →

``LSASS starts with PPL → Protection enabled → Resistant to attacks

Registry Hive Explanation (Interview Question)

Q: Why does it have to be in CurrentControlSet?

“Windows maintains multiple Control Sets (usually 3) for redundancy. CurrentControlSet is a symbolic link pointing to the active configuration (usually ControlSet001). During boot, the kernel reads this Control Set to determine system settings. If you modify the wrong Control Set, the changes won’t apply until Windows switches to it.”

Verification: Is PPL Enabled?

After Reboot, Verify:

powershell

# Method 1: Check Registry

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\" -Name RunAsPPL

# Method 2: PowerShell (check LSASS process)

Get-Process lsass | Format-List *

# Method 3: Check Event Logs for PPL activation

Get-EventLog -LogName System -Source "lsass" | Select-Object TimeGenerated, Message

Visual Confirmation (Task Manager):

1. Open Task Manager

2. Find lsass.exe

3. If PPL is active: "LSASS.EXE" shows as protected

4. Right-click → Properties → some options are greyed out

Important Details for Interview

Why Reboot is Mandatory (Deep Dive)

LSASS Protection is a KERNEL-LEVEL feature:

Registry entry only influences KERNEL decisions during boot

├─ Kernel reads registry early in boot sequence

├─ Decides: "Is RunAsPPL enabled?"

├─ If yes → Applies protection to LSASS before it fully loads

└─ This happens before any user-mode code executes

You CAN'T change kernel-level protection of a running process

because:

1. LSASS is already loaded and protected

2. Windows kernel only reads this setting during initialization

3. Changing it mid-session would require stopping LSASS

   (which would crash the system - can't stop LSASS while Windows is running)

4. Therefore: Reboot is the only safe way

Real Scenario (Interview Answer)

Q: I need to enable PPL. What do I do?

“I would:

1. Open regedit as Administrator

2. Navigate to HKLM
   

3. Create a new DWORD entry named RunAsPPL with value 1

4. Reboot the system

5. After reboot, LSASS runs with PPL protection

6. Verify with Get-ItemProperty command

The reboot is required because PPL is a kernel-level protection that’s applied during the boot process, before LSASS fully initializes.”

Common Mistakes (Don’t Do This!)

❌ Creating in wrong location — Wrong Control Set

❌ Wrong data type — String instead of DWORD

❌ Typo in name — RunAsPPL not RunAsProtectedProcess

❌ Forgetting reboot — Change won’t take effect

❌ Without admin rights — Permission denied error

Understanding Credentials Guard

🎯 Why Credential Guard Was Introduced

Problem with PPL (Protected Process Light)

✅ PPL protects LSASS from:

• Memory dumping

• Unauthorized process access

• Common Mimikatz-style attacks

❌ Limitation:

• If an attacker gains kernel-level access, PPL protections can often be bypassed.

• Traditional Windows treats the kernel as the highest privilege boundary.

Traditional Security Model

User Mode → Kernel Mode

Once an attacker reaches the kernel:

• They can access almost anything in the OS.

• LSASS protections become much weaker.

• Credentials become exposed.

Microsoft’s Goal

Create a security boundary where:

• Compromising LSASS is not enough.

• Compromising the Windows kernel is not enough.

• Credentials remain isolated from the normal operating system.

🎯 What Credential Guard Is

Credential Guard is a security feature built on:

• Virtualization-Based Security (VBS)

• Hypervisor-enforced isolation

• Secure Kernel

• Isolated User Mode (IUM)

Purpose:

• Protect NTLM secrets

• Protect Kerberos secrets

• Protect derived credential material

• Prevent credential dumping from LSASS

🔹 Traditional Boot Process

Without VBS:

System Startup

1. Hardware starts.

2. Windows Kernel loads.

3. LSASS starts.

4. Authentication services start.

Result:

• Windows Kernel is the highest authority.

• LSASS secrets ultimately depend on kernel security.

🔹 VBS Boot Process

With VBS enabled:

System Startup

1. Hardware starts.

2. Hypervisor loads first.

3. Standard Windows Kernel loads.

4. Secure Kernel loads in an isolated environment.

Result:

• Hypervisor becomes the highest authority.

• Windows Kernel is no longer the top privilege boundary.

🎯 Virtual Trust Levels (VTLs)

Credential Guard separates components into security worlds called:

Virtual Trust Levels

VTL0

Normal Windows Environment

Contains:

• Windows Kernel (ntoskrnl.exe)

• Drivers

• LSASS

• Applications

• EDR agents

Think:

👉 Everything attackers normally compromise.

VTL1

Secure Environment

Contains:

• Secure Kernel (securekernel.exe)

• Credential Guard components

Think:

👉 Protected security world.

🔥 Why VTL Separation Matters

Suppose attacker obtains:

• SYSTEM privileges

• LSASS access

• Kernel access

They still only control:

VTL0

They do NOT automatically control:

VTL1

To reach VTL1 they would need:

• Hypervisor compromise

• Hypervisor escape vulnerability

This is significantly harder.

🎯 Secure Kernel

Process:

securekernel.exe

Runs inside:

VTL1

Responsibilities:

• Secure cryptographic operations

• Credential isolation

• Secret protection

• Managing secure services

Think:

👉 Security kernel separate from normal Windows.

🎯 Isolated User Mode (IUM)

The Secure Kernel has a user-mode companion called:

Isolated User Mode (IUM)

Purpose:

• Host highly sensitive applications.

• Keep them separated from normal Windows.

Applications running inside IUM are called:

Trustlets

🎯 What Are Trustlets?

Trustlets are security-sensitive applications running inside the isolated environment.

Characteristics:

✅ Run inside protected memory

✅ Separate from Windows user-mode

✅ Protected by Secure Kernel

✅ Must be Microsoft signed

Important Restriction

A trustlet can only load if:

• Signed by Microsoft

• Trusted by the Secure Kernel

Result:

❌ Attackers cannot simply load custom code into IUM.

❌ Attackers cannot load arbitrary DLLs.

🎯 Credential Guard Trustlet

Credential Guard uses a special trustlet:

lsaiso.exe

Known as:

Isolated LSA

Think:

👉 Protected version of authentication services.

Isolated LSA Responsibilities

Handles:

• NTLM support

• Kerberos support

• Authentication-related operations

• Credential processing

Purpose:

• Keep secrets away from LSASS memory.

Communication Methods

lsaiso.exe communicates through:

ALPC

Advanced Local Procedure Call

Used for:

• Local secure communication.

RPC

Remote Procedure Call

Used for:

• Service communication.

Architecture Summary

Normal World (VTL0)

Contains:

• LSASS

• Applications

• Windows Kernel

Secure World (VTL1)

Contains:

• Secure Kernel

• lsaiso.exe

• Credential Guard trustlets

Communication occurs through controlled interfaces.

🎯 Critical System Process

lsaiso.exe is considered:

Critical System Process

Consequences:

❌ Cannot stop it

❌ Cannot restart it

❌ Cannot kill it

If terminated:

👉 Windows crashes (BSOD)

🎯 One-Time Context Handles

NTLM and Kerberos interfaces expose:

Initialization Functions

These functions return:

Context Handles

Think:

👉 Secure references allowing communication with isolated authentication services.

Important Security Design

These initialization functions:

✅ Can only be called once

✅ Are executed during boot

✅ Are called by LSASS

After boot:

❌ Other applications cannot obtain these handles.

Why This Matters

Attackers cannot simply:

• Open a handle

• Talk to Credential Guard

• Request secrets

Because the required handles already belong to LSASS.

🎯 Cryptography Protection

The Isolated LSA does not directly protect secrets itself.

Instead it asks:

Secure Kernel

to perform cryptographic operations.

Secure Kernel Functions

Used functions:

EncryptData

Encrypt sensitive data.

DecryptData

Decrypt sensitive data.

Session Key Protection

These functions rely on:

Per-Session Key

Characteristics:

✅ Randomly generated

✅ Created every Secure Kernel initialization

✅ Different after reboot

Security Benefit

Even if encrypted credential blobs are stolen:

• Keys are isolated.

• Keys change every boot.

• Decryption requires Secure Kernel cooperation.

🎯 KerberosIum and NtlmIum

Credential Guard exposes:

KerberosIum

Handles Kerberos operations.

NtlmIum

Handles NTLM operations.

Meaning of “Ium”:

Isolated User Mode

What Changed Compared To Old LSASS?

Before Credential Guard:

LSASS stored:

• NTLM hashes

• Kerberos keys

• Derived credentials

often in recoverable form.

With Credential Guard:

LSASS stores:

• Encrypted blobs

instead of usable credential material.

Key Concept

LSASS no longer owns the secrets.

Instead:

lsaiso.exe + Secure Kernel

own the secrets.

Kerberos Example

Suppose LSASS needs:

AP-REQ Authenticator

Normally:

• LSASS would create it itself.

With Credential Guard:

• LSASS asks KerberosIum.

• KerberosIum performs the operation.

• Secret keys never leave the isolated environment.

Why Traditional Credential Dumping Fails

Previously:

Dump LSASS

→ Recover NTLM hashes

→ Recover Kerberos keys

→ Recover tickets

With Credential Guard:

Dump LSASS

Only reveals:

• Encrypted blobs

• Protected structures

Not usable secrets.

🎯 What Would An Attacker Need To Do?

To directly interact with isolated secrets:

Option 1

Inject code into:

• lsass.exe

Option 2

Load custom Security Support Providers (SSPs)

Then:

• Obtain context handles

• Talk to Credential Guard interfaces

• Request operations

Why Is This Difficult?

EDR Problem

Modern EDRs heavily monitor:

• LSASS access

• Memory injection

• Handle operations

Result:

🚨 High detection risk.

PPL Problem

If LSASS runs as PPL:

• Code injection becomes much harder.

• Process manipulation becomes restricted.

Trustlet Problem

Custom security packages would require:

• Trusted signatures

• Approved loading

Attackers cannot simply load arbitrary code.

🔥 Final Interview Summary

PPL

Protects:

• LSASS process

Weakness:

• Kernel compromise may bypass it.

Credential Guard

Protects:

• Actual credential material

Uses:

• Hypervisor

• VBS

• Secure Kernel

• Isolated LSA (lsaiso.exe)

Main Security Idea

Before:

Secrets stored inside LSASS

After:

Secrets stored in an isolated environment outside LSASS

Why Credential Guard Is Powerful

Even if an attacker gains:

✅ Administrator

✅ SYSTEM

✅ LSASS dump

✅ Kernel access (VTL0)

They still cannot directly obtain:

• NTLM secrets

• Kerberos secrets

• Authentication keys

because those secrets live behind:

Hypervisor → VTL1 → Secure Kernel → lsaiso.exe.

How to verify if Credential Guard is enabled or disabled

You can use one of the below methods to check the status of Windows Credential Guard on a single PC.

Method 1: Using System Information

• Right-click on the Start button and select Run

• Enter msinfo32 in the Run dialog and click OK

• Click on System Summary in the left navigation panel

• In the right panel, scroll down to Virtualization-based Security Services Configured

• Credential Guard will be listed in the Value field for Virtualization-based Security Services Configured if it is enabled

If Windows Credential Guard is disabled or not available on your system, it will not appear.

Method 2: Using Group Policy Editor

You can also use the Group Policy Editor to check the enforcement status of Windows Credential Guard:

• Right-click on the Start button and select Run

• Enter gpedit.msc and click OK to open the Group Policy Editor

• Navigate to Computer Configuration/Administrative Templates/System/Device Guard

• Locate the Turn On Virtualization-based Security policy and open it

• If the policy is Enabled, you can check the options to see whether it’s enforced with UEFI (preventing it from being disabled) or not

If the policy is set to Not Configured, Credential Guard is not enforced by Group Policy (but still may be enabled by default)

Method 3: Checking the Windows Event Viewer

The Windows Event Viewer can be used to see information logged by Credential Guard.

• Search for and open Event Viewer from the Start menu

• Locate the Windows Credential Guard logs at Applications and Services Logs/Microsoft/Windows > DeviceGuard

• Open the Operational log

You can then verify that Credential Guard is working by inspecting the log entries. If there are no logs present, Device Guard may not be supported or enabled on your system. To aid in visualizing the verification process, you may view this video: ‘How to Verify if Device Guard is Enabled or Disabled in Windows’.

Method 4: Using PowerShell commands

The Get-CimInstance PowerShell cmdlet can be used to check whether or not Credential Guard is enabled or disabled by following these steps:

• Open PowerShell as Administrator

• Run the following PowerShell command

bool.SecurityServicesRunning.Contains(2)

• If this command returns True, Credential Guard is active

Pro Tip: If you want a more detailed breakdown without the True/False logic, simply run:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Look at the SecurityServicesRunning property. If it includes the number 2, Credential Guard is active.

NTDS.dit

Understanding The Core Concept

📘 Introduction

Active Directory (AD) is a directory service for Windows domain networks, commonly used in enterprise environments. It centralizes authentication, authorization, and management of computers and users.

🔎 Why Target AD?

• AD is often the heart of an enterprise network.

• Credentials stored in AD, especially in the NTDS.dit database, are valuable to attackers.

• Gaining access to AD can lead to full domain compromise.

🔐 Windows Authentication After Domain Join

Once a Windows machine joins a domain:

• It stops using the local SAM database for domain account authentication.

• All authentication requests are sent to a Domain Controller (DC).

• Local accounts can still log in using:

  • hostname\username
  • .\username (on logon screen)

Key components:

• lsass.exe: Local Security Authority Subsystem Service

• Authentication packages: NTLM, Kerberos

• AD DS (Active Directory Domain Services)

🧠 What is NTDS.dit (At Its Core)

NTDS.dit is the Active Directory database used by Domain Controllers (DCs).

Think of it as:

🗄️ The master identity database of the entire domain

It stores:

• All domain users

• All computers

• All groups

• All password hashes

• Kerberos-related secrets

If you compromise NTDS.dit → you own the domain.

📍 Where is NTDS.dit Stored?

Default path on a Domain Controller:

C:\Windows\NTDS\NTDS.dit

⚠️ You cannot copy it while Windows is running because:

• It’s locked

• Actively used by lsass.exe

🧱 Internal Structure of NTDS.dit

NTDS.dit is an ESE database (Extensible Storage Engine).

Major Tables Inside

The most valuable data lives in datatable.

🔑 What Secrets Are Stored Inside?

1️⃣ User Password Hashes

Each user has:

Stored as:

unicodePwd → encrypted → NT hash

🔐 Passwords are never stored in plaintext.

2️⃣ Kerberos Secrets

a) Kerberos Long-Term Keys

Used for:

• AS-REQ / AS-REP

• TGT creation

Includes:

• AES256

• AES128

• RC4 (NT hash)

b) krbtgt Account Hash ⭐

This is the most critical secret.

• Used to sign all Kerberos tickets

• Compromise = Golden Ticket attacks

• Allows forged tickets forever (until reset twice)

3️⃣ Cached Credentials (for DC)

• Machine account hashes

• Trust relationship secrets

• Inter-domain trust keys

🔐 Why SYSTEM + SECURITY Hive Is Required

NTDS.dit alone is useless.

You also need:

C:\Windows\System32\config\SYSTEM

C:\Windows\System32\config\SECURITY

Why?

Because:

• Hashes in NTDS.dit are encrypted

• The BootKey is stored in the SYSTEM hive

• Decryption flow:

SYSTEM hive → BootKey

BootKey → decrypt PEK

PEK → decrypt password hashes

Without SYSTEM → hashes stay encrypted.

🧪 Authentication Flow (Where NTDS.dit Is Used)

NTLM Authentication

User → NT hash

LSASS → compares hash

NTDS.dit → stores reference hash

Kerberos Authentication

User → AS-REQ

KDC (on DC) → reads NTDS.dit

krbtgt key → signs TGT

So:

• Every domain login

Every Kerberos ticket

→ touches NTDS.dit

🧨 How Attackers Access NTDS.dit

1️⃣ Offline (Disk Access)

Examples:

• DC backup

• Shadow Copy

• Disk snapshot

• Mounted VHD

Classic methods:

• Volume Shadow Copy

• IFM backup

• NTDSUTIL

No LSASS interaction → stealthier

2️⃣ Online (Memory / Replication)

a) DCSync Attack ⭐

Abuses Directory Replication privileges:

ReplicatingDirectoryChanges

ReplicatingDirectoryChangesAll

Effect:

• DC sends password hashes

• No file access

• No NTDS.dit touching

This logically equals dumping NTDS.dit.

b) LSASS Dump (DC)

If you dump LSASS on a DC:

• NTDS secrets are accessible

• Extremely noisy

• Often detected

🧰 Tools That Parse NTDS.dit (Conceptual)

These tools:

• Parse ESE format

• Decrypt using SYSTEM hive

• Output hashes + Kerberos keys

🧬 What Attackers Do With Extracted Data

1️⃣ Pass-the-Hash (PtH)

• NT hash → authenticate

• No password needed

2️⃣ Pass-the-Ticket (PtT)

• Reuse Kerberos tickets

3️⃣ Golden Ticket

• Using krbtgt hash

• Unlimited persistence

4️⃣ Silver Ticket

• Service-specific forgery

🛡️ Defensive View (Very Important)

How to Protect NTDS.dit

🔹 Restrict Replication Rights

Only Domain Controllers should have:

ReplicatingDirectory Changes

🔹 Monitor DCSync

Event IDs:

• 4662

• 4742

• 4624 (DC replication patterns)

🔹 Protect SYSTEM Hive

• Prevent DC backup abuse

• Secure VSS access

🔹 Reset krbtgt Properly

• Reset twice

• With delay between resets

🧠 Mental Model (Easy Recall)

NTDS.dit = Identity Vault

SYSTEM hive = DecryptionKey

krbtgt = Domain MasterKey

DCSync =  Remote NTDS extraction

🔚 Final Summary

🔐 Why This Matters

The NTDS.dit file contains:

• All usernames and password hashes.

• AD schema and domain configuration.

• Credentials for privileged accounts.

Once exfiltrated, it can be cracked using tools like:

• secretsdump.py

• hashcat / john

📌 Dumping Techniques:

• Volume shadow copy (VSS)

• Impacket tools (secretsdump.py)

• Mimikatz

• Ntdsutil + DSInternals

🔄 Example with Impacket:

bash

secretsdump.py -just-dc -system SYSTEM -ntds ntds.dit LOCAL

💡 What You Get:

• NTLM hashes

• RID, username

• Useful for Pass-the-Hash or offline cracking

🔐 Key Takeaways

📘 Summary

• AD is central to Windows enterprise security.

• Usernames can be harvested via OSINT techniques.

• Dictionary attacks are useful but noisy and must be used wisely.

• Dumping NTDS.dit gives attackers access to entire domain credentials.

• Post-exploitation access to a DC unlocks full potential for hash dumping and lateral movement.

Dpapi ( Credential Manager )

Understanding The Core Concept

🟦 1. Why DPAPI Exists

DPAPI = Data Protection API

Purpose: Encrypt user-specific secrets so only that specific user account can decrypt them.

It protects:

• Browser saved passwords (Chrome, Edge, Brave → Login Data)

• Windows Credentials (Credential Manager)

• Wi-Fi passwords

• RDP saved passwords

• Cloud tokens (Outlook, OneDrive)

• App secrets (VPN clients, Git clients)

• MS Office credentials

• DPAPI-encrypted certificates

• GPG passphrases

• Password vault entries

DPAPI = user-bound encryption system

If you steal the file alone → useless

You need:

• The user’s password or

• The user’s DPAPI MasterKeys

  To decrypt.

🟦 2. Where DPAPI Stores Data

DPAPI has 2 main storage locations:

**🟥 2.1 C:<UserName>*

This folder stores:

Credential Blobs

Files with long, random hex-like names (e.g., 3C9A1F6D...).

These represent encrypted entries from Windows Credential Manager.

You see these when running:

cmdkey /list

rundll32.exe keymgr.dll,KRShowKeyMgr

Each file contains:

• DPAPI header

• Encrypted password/token

• Metadata

These files are called:

✔ CredBlobs

🟦 2.2 C:

Inside this folder:

You will see 1 or 2 random folders → These contain:

✔ DPAPI MasterKeys

The REAL keying material used to decrypt Credential Blobs and other DPAPI items.

These files look like:

C:\Users\User\AppData\Roaming\Microsoft\Protect\S-1-5-21-4024337825-2033394866-2055507597-1115\

    3c02f7d4-a84f-4e3f-a00e-6a4a31fb0798

    9bf1d01a-62f9-4dd4-aa6c-e37519b90877

Each file is a MasterKey file.

🟦 3. Why There Are “Two Random Folders” in Protect

Inside:

Microsoft\Protect\<SID>\

You may sometimes see 2 subfolders:

✔ Folder 1 — User Context

✔ Folder 2 — System Context

Windows uses multiple DPAPI profiles depending on:

• Roaming profile

• User migration

• Group Policy backup keys

• Password changes

• Domain cached keys

• Automatic Wi-Fi / WebCreds migrations

So 2 folders = 2 key sets.

This is normal.

🟥 4. What Is a MasterKey?

A DPAPI MasterKey is the actual symmetric key that decrypts encrypted secrets.

✔ MasterKey = Used to decrypt Credential Blobs

✔ MasterKey itself is encrypted using:

• User login password (local)

• Or domain DPAPI backup key (domain-joined)

You can think of it like:

User Password → Decrypt MasterKey → Decrypt Credential Blobs

Are browser passwords stored in Credential Blobs?

Answer:

Chrome/Edge passwords DO NOT use credential blobs.

They use a SQLite database:

AppData\Local\Google\Chrome\User Data\Default\Login Data

But the encryption key in Login Data is protected by DPAPI MasterKey.

Meaning:

• Browser secrets use DPAPI indirectly

Firefox:

• Does NOT use DPAPI

• Uses key4.db + logins.json

• Master password optional

• Cracked differently

🟥 9. What is stored in Credential Blobs?

Typical items:

• RDP saved credentials

• Windows Vault entries

• Wi-Fi passwords

• Outlook tokens

• OneDrive tokens

• VPN credentials

• Generic “Saved Passwords”

Not browser credentials directly.

Chrome/Edge use DPAPI but not via CredBlobs.

🟩 10. Final Summary (Clean)

Dpapi Decryption Example

Step 1 — Extract prekey

pypykatz dpapi prekey password 'S-1-5-21-4024...-1115' Zer0the0ne | tee pkf

Meaning:

• Using user SID

• Using user password “Zer0the0ne”

• Generate a dpapi pre-key file (pkf) → decrypts MasterKeys

Step 2 — Decrypt DPAPI MasterKeys

pypykatz dpapi masterkey dpapi1 pkf -o mkf1

pypykatz dpapi masterkey dpapi2 pkf -o mkf2

Meaning:

• For each masterkey file (dpapi1, dpapi2)

• Use the pkf file to decrypt it

• Output decrypted masterkey → mkf1, mkf2

Step 3 — Decrypt CredBlob

pypykatz dpapi credential mkf credblob

Meaning:

• Use decrypted masterkey

• Open the credblob file

• Output the decrypted credential

  (usually a username/password pair)

Step 4 — UTF-16LE decode

data.decode('utf-16le')

Because DPAPI secrets are stored in:

✔ Windows Unicode → UTF-16 Little Endian

Decryption Logic

        USER PASSWORD

          ↓

    NT Hash (password)

          ↓

    SID + NT Hash → Prekey

                    ↓

        Decrypt master key

                    ↓

        Decrypt credential blob

                    ↓

                PLAINTEXT

1. “Master key we get from /Protect/ folder”

✔ Correct.

The files inside:

C:\Users\<User>\AppData\Roaming\Microsoft\Protect\<SID>\

are the encrypted master key files.

2. “For generating the prekey we need user SID + password”

✔ Correct.

The prekey is derived from:

SID + User password (NT hash)

This is exactly what pypykatz does when you run:

pypykatz dpapi prekey password "S-1-5-..." <password>

3. “Using the prekey we decrypt the master key”

✔ Correct.

Master key files are encrypted with key material derived from the prekey.

Command:

pypykatz dpapi masterkey dpapi1 pkf -o mkf1

Outputs the decrypted master key.

4. “Then using the master key we decrypt the DPAPI blob”

✔ Exactly correct.

Credential blob location:

AppData\Roaming\Microsoft\Credentials\<GUID>

Contains the encrypted secret.

Command:

pypykatz dpapi credential mkf credblob

Final decode:

data.decode('utf-16le')

✔ Correct — DPAPI secrets are UTF-16LE encoded.

🎯 Final Confirmation

Your overall DPAPI explanation is correct:

User SID + Password --> Prekey

Prekey + MasterKeyFile --> MasterKey

MasterKey + CredentialBlob --> Decrypted Secret

This is the exact internal process used by Windows DPAPI

and the same process used by mimikatz/pypykatz.

Ekeys

Understanding The Core Concept

1. What Exactly Are EKEYS? (Deep Technical Meaning)

When you run:

sekurlsa::ekeys

Mimikatz extracts the Kerberos long-term keys stored inside the LSASS process memory.

These keys are normally protected but LSASS keeps them to:

• Validate Kerberos tickets

• Sign PAC structures

• Decrypt TGT/TGS

• Handle SSO authentication

• Work with DPAPI

These keys are derived from the user’s password and represent the user’s cryptographic identity in Kerberos.

🚀 2. What Keys Do We Get? (Why They Matter)

Typical output contains:

✔ AES256_HMAC Key

• Strongest Kerberos key

• Used for encrypting/signing TGTs

• Used for encrypting TGS

• Required for modern Kerberos authentication

• Always present in Windows Server 2008+ domains

✔ AES128_HMAC Key

• Same purpose as AES256

• Older systems or fallback

✔ RC4_HMAC_NT (NTLM Hash)

Same as NTLM hash (MD4(password))

Used for:

• NTLM authentication

• RC4-HMAC Kerberos (older domains)

• Pass-the-Hash

• Craft

dont directly go for mimikatz

Understood.

You want a full, deep, detailed explanation of EKEYS — first conceptually, then how they are used, then later show the attack, not immediately jumping into Mimikatz output.

Here is the clean, structured, detailed “from zero → deep” format.

⭐ 1. What Are Kerberos EKeys? (Core Concept)

In Active Directory, every user has Kerberos long-term keys derived from their password.

These long-term keys are called:

✔ Encryption Keys (EKeys)

These are cryptographic keys used by Kerberos to:

• Prove the identity of a user

• Encrypt TGT (Ticket Granting Ticket)

• Encrypt TGS (Service Ticket)

• Sign the PAC (Privilege Attribute Certificate)

• Validate ticket integrity

• Authenticate without storing passwords

They are NEVER passwords, but cryptographic representations of the password.

⭐ 2. How Are Kerberos EKeys Created?

When a user sets a password:

Kerberos derives several keys from the password:

So the password is never used directly.

Kerberos uses these derived keys to identify and authenticate the user.

⭐ 3. Why Are These Keys Stored in LSASS?

LSASS caches them in memory because:

✔ Users login

LSASS must validate tickets presented by the user.

✔ Services authenticate

Services need to verify users’ TGS tickets.

✔ SSO requires tickets

For seamless logon, LSASS must have the user’s encryption material.

This is why tools like Mimikatz / Rubeus can extract them.

⭐ 4. Why EKeys Are Extremely Valuable to Attackers

Because these keys are the full identity of the user in Kerberos.

If you have these keys, you can:

✔ Authenticate without password

This is called Pass-The-Key.

Kerberos will accept AES/RC4 key instead of the real password.

✔ Get a Ticket Granting Ticket (TGT)

Using AES key:

asktgt /aes256:<key>

✔ Do Pass-The-Hash using RC4/NTLM

RC4 key = NTLM hash

So NTLM-based auth works too.

✔ Forge Silver Tickets

Using the service account’s AES/RC4 keys.

✔ Decrypt encrypted tickets

Kerberos session keys become decryptable.

✔ Get long-term persistence

AES256 key is valid until password changes.

Example - Format

⭐ 1. Example of EKeys (Random Example)

(This is NOT mimikatz output yet — just showing the concept)

User: alice

Domain: CORP.LOCAL

Kerberos Long-Term Keys:

  AES256     : a1b7f3d2e246bc1f539c48d6efe7c0d4ac93821f44efcf1c20d52a310ee9b8c

  AES128     : 85e4d8ab1c7b32f0a2f8d4a3f516a959

  RC4-HMAC   : 5f4dcc3b5aa765d61d8327deb882cf99   ← NTLM hash

  SHA1       : 9c3e73429aa21e7b85ffcc433c29b1d12

✔ AES256 = used for strongest Kerberos authentication

✔ AES128 = fallback

✔ RC4-HMAC = NTLM hash (Pass-The-Hash compatible)

✔ SHA1 = PAC integrity

⭐ 7. How Attackers Use These EKeys

✔ A. Pass-The-Key (Kerberos)

Using AES256 key to request TGT:

asktgt /domain:corp.local /user:alice /aes256:a1b7f3d2e246bc...

→ DC issues a TGT because AES key is valid.

You now impersonate Alice without password.

✔ B. Pass-The-Hash (NTLM)

Using RC4/NTLM hash → SMB/WinRM/etc.

psexec.py -hashes :5f4dcc3b5aa765... alice@corp.local

✔ C. Silver Ticket Forging

Using service account AES key:

• CIFS

• HOST

• MSSQLSvc

• HTTP

kerberos::golden /service:cifs /target:server.corp.local /aes256:<key>

✔ D. Persistence

If password never changes → ekey never changes.

Attacker stays forever.

⭐ 8. Why AES Key Is Better Than RC4

So attackers always prefer AES256 → best for Pass-the-Key.

⭐ 9. Final Summary (Simple & Powerful)

✔ Kerberos EKeys = AES/RC4 keys derived from a user’s password

✔ They are the user’s identity inside LSASS

✔ If you get these keys, you do NOT need the password

✔ Using AES256/EKeys you can:

• Request a TGT

• Request service tickets

• Authenticate via Kerberos

• Forge silver tickets

• Lateral move

• Maintain persistence

✔ Using RC4 you can:

• Do pass-the-hash

• Do legacy RC4 Kerberos

• Authenticate to older services

🔥 RID Enumeration — Deep Dive (Core Logic + Brute Force Working) + User Enumeration

✅ 1. First, understand SIDs

Every Windows AD user has a SID (Security Identifier):

S-1-5-21-AAA-BBB-CCC-RID

• AAA-BBB-CCC → Domain identifier (same for all users in that domain)

• RID → Relative ID (unique per user)

Example:

Administrator → RID 500

Guest         → RID 501

John          → RID 1103

HRUser        → RID 1432

The ONLY part that changes per user is the RID.

🧠 2. Anonymous SID Lookup Leak (The Vulnerability)

Windows exposes an API:

LookupAccountSid()

If you give it a SID, it returns:

• Username

• Object type (user/group)

• Domain name

Even for unauthenticated users unless the admin explicitly restricts it.

This is the vulnerability.

📌 These two different codes allow enumeration

Tools detect:

🔍 3. How enumeration tools exploit it

Tools like:

• Impacket lookupsid.py

• CrackMapExec

• enum4linux-ng

• RID brute-force modules

They follow the same logic:

Step 1 — Get the domain SID (without passwords!)

The tool asks for the SID of user “null session” or uses a query to fetch the domain SID:

Example:

S-1-5-21-555444333-777888999-123456789

This is constant for the entire domain.

🚀 4. Now brute forcing begins

The tool loops through RIDs:

Start RID = 500

End RID   = 20000    (or 100000 depending on tool)

For each RID:

Step 2 — Construct a test SID

Example:

TestSID = DomainSID + "-" + 500

TestSID = S-1-5-21-555444333-777888999-123456789-500

Step 3 — Ask Windows: Who is this?

Send:

LookupAccountSid(TestSID)

Step 4 — If Windows responds with a name

You’ve found a real user or group.

Example output:

S-1-5-21-…-500  → Administrator

S-1-5-21-…-501  → Guest

S-1-5-21-…-1104 → HRUser

Step 5 — If Windows returns “NO MAPPING”

RID doesn’t exist → skip and continue.

📘 5. What is actually being brute-forced?

You are brute-forcing:

Every possible RID number.

**NOT passwords.

NOT usernames.

ONLY numerical RIDs.**

You try tens of thousands of RIDs and see which ones exist.

🟦 6. Why this works even without credentials

Because Windows allows ANONYMOUS SID → username lookups unless hardened.

Domain Controller replies:

• If SID exists → returns username

• If SID does not exist → returns ERROR_NO_SUCH_USER

This difference is what allows enumeration.

🧨 7. Example — RID brute force logic in pseudocode

domain_sid = get_domain_sid()   # S-1-5-21-555-666-777

for rid in range(500, 20000):

    sid = domain_sid + "-" + rid

    username = LookupAccountSid(sid)

    if username != ERROR:

        print("Found user:", username, "RID:", rid)

    else:

        continue

This is exactly what Impacket lookupsid.py does internally.

🟣 8. Example (Realistic Output)

[*] S-1-5-21-555-666-777-500   Administrator

[*] S-1-5-21-555-666-777-501   Guest

[*] S-1-5-21-555-666-777-502   krbtgt

[*] S-1-5-21-555-666-777-1104  John

[*] S-1-5-21-555-666-777-1500  BackupSvc

[*] S-1-5-21-555-666-777-2103  HRUser

Boom → full domain user enumeration without credentials.

🛡 9. How to stop RID enumeration (Defender View)

RID enumeration works when:

Anonymous SID lookup is allowed

To stop it:

✔ Turn off ANONYMOUS SAM lookups

Local Security Policy:

Network access: Restrict anonymous access to SAM

✔ Harden SMB

Disable anonymous sessions.

✔ Use “Deny anonymous enumeration of SAM accounts” via GPO.

Once enabled → enumeration tools get Access Denied.

⭐ FINAL SUMMARY

RID Enumeration works because:

1. All domain users share the same domain SID

2. Only the RID changes

3. Windows leaks SID→Name resolution

4. Tools loop through all possible RIDs

5. If Windows returns a name → that user exists

6. No password or login required

It brute-forces RID numbers (500–50000), not usernames or last 3 digits.