# Logon Base concepts

## Base concepts for in detailed Knowledge  

### What is **Local Machine or Local Computer ?**

* A <mark style="color:blue;">**local machine**</mark> refers to a standalone computer running Windows that manages its own security, user accounts, and resources **independently**, without being part of a centralized domain (like Active Directory).

### **Key Components of a Local Machine ?**

* What is Windows NT ? \
  \
  &#x20;1\. The term "NT" in <mark style="color:blue;">**Windows NT**</mark> stands for **"**<mark style="color:blue;">**New Technology**</mark>**"** 7. This name was chosen because Windows NT represented a significant advancement in operating system design compared to previous versions of Windows. It introduced a completely new architecture that was more reliable, secure, and scalable \
  \
  2\. <mark style="color:blue;">**Windows NT**</mark> was built from the ground up with a new kernel, independent of the MS-DOS-based systems used by earlier versions like Windows 3.x. This made it more robust and capable of handling advanced tasks<br>
* 🔐 What Are Cached Credentials?\
  \
  1\. <mark style="color:blue;">**Cached credentials**</mark> are **secure, local copies** of a user's login information (specifically, a hash of the password, not the actual password). Windows stores these **after the first successful domain logon on Domain-Machine**, so the user can **still log in even if the domain controller or cloud provider isn’t available ,&#x20;**<mark style="color:red;">**because**</mark> the system stores a hashed version of their credentials locally.—like when they’re working offline or remotely.\
  \
  2\. <mark style="color:blue;">**Cached credentials**</mark> enable users to authenticate locally on a Windows machine without contacting a domain controller. This is particularly useful for remote or mobile users who may not always have network access.\
  \
  3\.  <mark style="color:blue;">**Cached Credentials**</mark>**&#x20;Exist Only on Domain (or Azure AD) Joined Machines,Not on Local-Only Machines(&#x20;**<mark style="color:blue;">**Mean by That cached credentials**</mark> <mark style="color:blue;"></mark><mark style="color:blue;">are</mark> <mark style="color:blue;"></mark><mark style="color:blue;">**not used**</mark> <mark style="color:blue;"></mark><mark style="color:blue;">on a computer that is</mark> <mark style="color:blue;"></mark><mark style="color:blue;">**not connected to any domain**</mark> <mark style="color:blue;"></mark><mark style="color:blue;">(also called a</mark> <mark style="color:blue;"></mark>*<mark style="color:blue;">local-only machine</mark>* <mark style="color:blue;"></mark><mark style="color:blue;">or</mark> <mark style="color:blue;"></mark>*<mark style="color:blue;">standalone machine</mark>*<mark style="color:blue;">)</mark> **) But** Local (standalone) machines **do not use cached credentials** in this context.<br>

  | Situation                           | Does It Use Cached Credentials? | Why?                                                     |
  | ----------------------------------- | ------------------------------- | -------------------------------------------------------- |
  | A PC at home with a local account   | ❌ No                            | The password is already stored locally in SAM data base. |
  | A company laptop joined to a domain | ✅ Yes                           | Needs cached credentials for offline access.             |

  \ <mark style="color:blue;">4. Cashed Credentials Security Considerations :</mark> \
  &#x20;\
  &#x20; 4.1. <mark style="color:blue;">**Storage Location**</mark>: Cached credentials are stored in the registry under `HKEY_LOCAL_MACHINE\Security\Cache\NL$n` \
  &#x20; \
  &#x20;4.2. <mark style="color:blue;">**Security Risks**</mark>: If a device is compromised, attackers with administrative privileges could potentially extract cached credentials using tools like Mimikatz.\
  \
  &#x20;4.3. <mark style="color:blue;">**Configuration**</mark>: Administrators can limit or disable credential caching by modifying the `CachedLogonsCount` registry value. Setting it to `0` disables caching entirely?\
  &#x20;      \
  &#x20;      4.3.1. <mark style="color:blue;">**Disabling the cached credentials feature**</mark>**&#x20;:** to disabling the cached credentials feature is that if the machine loses its network connection and can no longer reach the domain controller, any local login requests to that domain will fail. The number of cached logins can be forced to zero by using a Domain Security Policy. Set “Number of previous logins to cache (in case domain controller is not available),” which can be found under <mark style="color:blue;">**Computer Configuration → Security Settings → Local Policies → Security**</mark> Options, to zero. This change affects the CachedLogonsCount registry key on each member machine in the domain. <mark style="color:blue;">**This registry value can be found inside the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon**</mark>**&#x20;,**

  Inside this key, you'll find entries named like:

  ```bash
  NL$1, NL$2, NL$3, ..., NL$10 ----------> This Where is Stored in Windows NT system ?
  ```

  \
  &#x20; 4.4. The **registry path** where cached credentials are stored in Windows is:

  `HKEY_LOCAL_MACHINE\Security\Cache` \
  &#x20; \
  &#x20; 4.5. **HKEY\_LOCAL\_MACHINE\Security\Cache\NL$n: Purpose and Technical Details ?**\
  &#x20;      \
  &#x20;   4.5.1. <mark style="color:blue;">**What is**</mark><mark style="color:blue;">**&#x20;**</mark><mark style="color:blue;">**`NL$n`**</mark>**&#x20; :**&#x20;

  * <mark style="color:blue;">**Location**</mark>**:** `HKLM\SECURITY\Cache\NL$1`, `NL$2`, etc. (where `n` = numeric index)
  * <mark style="color:blue;">**Purpose**</mark>**:** Stores **secondary logon information** (<mark style="color:blue;">**The term "secondary logon information" in the context of**</mark><mark style="color:blue;">**&#x20;**</mark><mark style="color:blue;">**`HKLM\SECURITY\Cache\NL$n`**</mark><mark style="color:blue;">**&#x20;**</mark><mark style="color:blue;">**refers to backup authentication data that Windows stores locally to allow users to log in when primary domain authentication is unavailable.**</mark>) when:
    * A domain-joined machine loses network connectivity.
    * A user logs in with a **previously used domain account**.
  * <mark style="color:blue;">**Data Format:**</mark> Encrypted **NTLM hashes** (not plaintext passwords).<br>

  &#x20;   4.5.2. <mark style="color:blue;">**How Cached Credentials Work :**</mark>&#x20;

  #### &#x20;     **A. When Does Windows Cache Credentials?**

  1. Windows stores a **hashed copy** of the password in `NL$n`.
  2. If the machine goes **offline**, the user can still log in using the cached hash.
  3. User logs into a **domain-joined machine** while connected to the network.

  &#x20; \
  &#x20;  4.5.3. <mark style="color:blue;">**Technical Breakdown of**</mark><mark style="color:blue;">**&#x20;**</mark><mark style="color:blue;">**`NL$n`**</mark>  \ <mark style="color:blue;">**Hint < ' \_ ' >**</mark>**&#x20;reading `NL$n` directly from the registry is far harder** than extracting credentials from LSASS memory.

  | **Component**            | **Description**                                     |
  | ------------------------ | --------------------------------------------------- |
  | **Encryption**           | Uses **LSA secrets** (protected by SYSTEM account). |
  | **Hash Type**            | NTLM (v1 or v2, depending on OS version).           |
  | **Registry Permissions** | Only `SYSTEM` and `Administrators` can read.        |

  \
  &#x20; 4.5.4. <mark style="color:blue;">What is the</mark> <mark style="color:blue;"></mark><mark style="color:blue;">**LSA Key**</mark><mark style="color:blue;">?</mark>

  * **Definition:** A secure storage mechanism within the **LSASS (Local Security Authority Subsystem Service)** that holds sensitive system data Which called also as "<mark style="color:blue;">**LSA Secrets**</mark>", including:

    * Cached domain credentials (`NL$n`).
    * Auto-logon passwords.
    * Service account credentials.

    ⚠️ LSA Secrets are stored in two primary locations, both designed to protect their confidentiality and integrity:

    1. <mark style="color:blue;">**Registry: HKEY\_LOCAL\_MACHINE\SECURITY\Policy\Secrets**</mark>

       * <mark style="color:blue;">**Description**</mark>: This registry key contains encrypted LSA Secrets. Each secret is stored as a subkey under Secrets, with names like NL$n (for cached domain credentials, where n is a number from 1 to the maximum cached logons, typically 10 by default) or specific names for other secrets (e.g., DefaultPassword for auto-logon).
       * <mark style="color:blue;">**Encryption**</mark>: The data is encrypted using the **LSA encryption key**, which is derived from system-specific information and protected by the LSASS process. Only processes with appropriate privileges (e.g., SYSTEM) can access this key.
       * <mark style="color:blue;">**Access Control**</mark>: The SECURITY hive is locked down to prevent unauthorized access. By default, only the SYSTEM account has read/write access, and even administrators cannot view it directly without elevating privileges.
       * <mark style="color:blue;">**Purpose**</mark>: Storing secrets in the registry ensures persistence across reboots, allowing LSASS to retrieve them when needed for authentication or service operations.

    2. <mark style="color:blue;">**Memory: LSASS Process Space**</mark>
       * <mark style="color:blue;">**Description**</mark>: LSA Secrets are loaded into the memory of the LSASS process (lsass.exe) during system operation. This includes decrypted or partially decrypted forms of the secrets for real-time use in authentication tasks.

       * <mark style="color:blue;">**Protection**</mark>: Secrets in memory are protected by the Windows kernel and LSASS’s isolation mechanisms. However, they are vulnerable to memory-dumping attacks if an attacker gains sufficient privileges (e.g., SYSTEM or debug privileges).

       * <mark style="color:blue;">**Access**</mark>: Only privileged processes or threads running within LSASS can access these secrets. Tools like Mimikatz exploit vulnerabilities to extract secrets from LSASS memory, as discussed in various cybersecurity resources.

       * <mark style="color:blue;">**Purpose**</mark>: Storing secrets in memory allows LSASS to quickly access them during authentication, such as verifying cached credentials for offline logon or authenticating service accounts.

  > 🔐 Think of it as the “<mark style="color:blue;">**master password**</mark>” that Windows uses to guard other secrets.

  &#x20;\ <mark style="color:blue;">**2.**</mark> <mark style="color:blue;">**The LSA**</mark> Key is used to **encrypt and decrypt** several critical secrets in the system, including:

  <table><thead><tr><th width="206">🛡️ Protected Item</th><th>Description</th></tr></thead><tbody><tr><td><strong>LSA Secrets</strong></td><td>Includes cached credentials, service account passwords, RDP info, auto-logon credentials, etc.</td></tr><tr><td><strong>NL$KM</strong></td><td>The <strong>NTLM credential encryption key</strong> used by the system to store cached domain credentials.</td></tr><tr><td><strong>DPAPI Master Keys</strong></td><td>The root keys used to encrypt/decrypt files, browser passwords, Windows credentials, etc.</td></tr><tr><td><strong>Auto-logon Passwords</strong></td><td>Stored under <code>HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon</code> in plaintext, but encrypted using the LSA key if protected.</td></tr></tbody></table>

#### **⚠️What LSASS Stores in Memory**

The LSASS process manages Windows security functions and retains various types of credentials in memory for operational purposes:

| **Credential Type**      | **Description**                                                                                         | **Example**                          |
| ------------------------ | ------------------------------------------------------------------------------------------------------- | ------------------------------------ |
| **NTLM Hashes**          | Hashed versions of passwords (used for local/domain auth).                                              | `8846F7EAEE8FB117AD06BDD830B7586C`   |
| **Kerberos Tickets**     | Encrypted TGTs (Ticket-Granting Tickets) for domain authentication.                                     | `krbtgt` service tickets.            |
| **Plaintext Passwords**  | **Occasionally**, passwords may exist in clear text due to certain auth protocols or misconfigurations. | `Pa$$w0rd123`                        |
| **Cached Domain Logons** | Offline logon hashes (from `NL$n` registry entries).                                                    | Cached NTLM hashes for domain users. |
| **DPAPI Master Keys**    | Keys used to decrypt stored credentials (e.g., saved browser logins).                                   | `User123_DPAPI_KEY`                  |

#### **⚠️Why Plaintext Passwords&#x20;*****Sometimes*****&#x20;Appear in LSASS**

#### **A. Common Scenarios**

1. **WDigest Authentication (Legacy)**
   * Older Windows versions (pre-2014) stored plaintext passwords if WDigest was enabled.
   * **Patch KB2871997** disabled this by default, but admins can re-enable it (insecure).
2. **SSPI (Security Support Provider Interface) Calls**
   * Some applications (e.g., IIS, SQL Server) may pass plaintext creds to LSASS for authentication.
3. **Credential Delegation**
   * Used in scenarios like **Remote Desktop with "Allow Delegation"** enabled.
4. **Third-Party Software**
   * Poorly designed apps might inject plaintext passwords into LSASS for authentication.

#### **B. Example: WDigest Exploitation**

* **Before 2014:** Windows stored plaintext passwords in LSASS if WDigest was active.
* **After 2014:** Microsoft patched this, but attackers can re-enable it via:

  powershellCopy

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

  After a reboot, plaintext passwords reappear in LSASS.

### **What is the Windows LSA Key?**

* ➤ Definition:

  > <mark style="color:blue;">The</mark> <mark style="color:blue;"></mark><mark style="color:blue;">**LSA Key**</mark> <mark style="color:blue;"></mark><mark style="color:blue;">is a symmetric key used by the</mark> <mark style="color:blue;"></mark><mark style="color:blue;">**Local Security Authority Subsystem Service (LSASS)**</mark> <mark style="color:blue;"></mark><mark style="color:blue;">to</mark> <mark style="color:blue;"></mark><mark style="color:blue;">**encrypt and decrypt**</mark> <mark style="color:blue;"></mark><mark style="color:blue;">sensitive secrets stored in the Windows registry.</mark>

  It is stored in the **SYSTEM hive** and used to encrypt secrets found in the **SECURITY hive** of the registry.
* #### The LSA key is created **once**, during:

  * **Initial Windows setup** (e.g., when you install Windows for the first time)
  * Or **the first system boot** after installation, **before any user logs in**

  ####
* <mark style="color:green;">**Where is the LSA Key Stored?**</mark><br>

  It’s stored **obfuscated and encrypted** inside the Windows registry:<br>

  #### 📁 Location:

  ```
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  ```

  \
  More specifically, the actual key is hidden and extracted from a value under:<br>

  <pre><code><strong>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\JD
  </strong>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Skew1
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\GBG
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Data
  </code></pre>

These 4 values are **XOR-obfuscated and encoded**. When combined, they form the **LSA encryption key**.

* Flow of LSA Key Creation ? &#x20;

  ### Flow Diagram

  ```mermaid
  flowchart 
      A[Windows boots] --> B[LSASS starts]
      B --> C[LSASS reads SYSTEM hive]
      C --> D[Combines JD + Skew1 + GBG + Data]
      D --> E[Derives LSA Key]
      E --> F[Decrypts secrets from SECURITY hive]
      F --> G[LSASS uses the secrets (e.g., credentials, DPAPI)]
  ```
* We have a point , the LSA Key is initialized From LSASS.e Process to decrypt the LSA secrets That LSASS retain or load in LSASS process during runtime <br>
* ### <mark style="color:green;">Step-by-Step: LSA Key Creation Flow</mark>

  #### &#x20;1. **Windows OS Initialization**

  * During Windows installation or first boot:
    * The SYSTEM account is in full control.
    * LSASS (Local Security Authority Subsystem Service) is initialized.<br>

  #### 2. **LSASS Needs a Secret Storage Key**

  * Windows needs a persistent key to:
    * Encrypt/decrypt secrets like service account passwords, cached logons, and DPAPI master keys.
  * This is where the **LSA Key** is generated.<br>

  #### 3. **Key Material Is Created by SYSTEM**

  * Windows (under SYSTEM) generates a **random 128-bit or 256-bit symmetric key**.
    * Typically using the **Cryptographic API (CryptoAPI)** or **CNG (Cryptography Next Gen)** system libraries.
    * The key is strong and **unique per machine**.<br>

  #### 4. **The Key Is Stored in Obfuscated Form**

  * SYSTEM writes the **encrypted key** into the registry under:

  ```
  HKLM\SYSTEM\CurrentControlSet\Control\Lsa
  ```

  It is **split across 4 values**:

  * `JD`
  * `Skew1`
  * `GBG`
  * `Data`

  These values are:

  * **Binary blobs** stored in the SYSTEM hive.
  * Combined and **XORed together** to reconstruct the LSA key.

  This obfuscation helps hide the key from naive attackers or tools.

#### Then after we create LSA key , how we can use it ?

#### <mark style="color:blue;">**At Boot: LSASS Reconstructs the LSA Key**</mark>

* <mark style="color:green;">When Windows starts:</mark>
  * LSASS reads the 4 obfuscated registry values
  * Combines and decodes them using **XOR logic**
  * Loads the **real symmetric LSA key into memory**
* <mark style="color:green;">This key:</mark>
  * **Never leaves the LSASS process memory in plaintext(Inside LSASS is plaintext==Binary Format  but out side is encrypted)**
  * Is used throughout the session to:
    * Decrypt cached secrets
    * Decrypt DPAPI master keys
    * Decrypt stored service account credentials

<figure><img src="/files/RrT86T2he8CxvWfm7j1y" alt="" width="563"><figcaption><p>Inside &#x26; Outside LSASS process </p></figcaption></figure>

* ### Registry-Level View (Behind the Scenes)

  | Registry Hive | Path                                     | Description                                                 |
  | ------------- | ---------------------------------------- | ----------------------------------------------------------- |
  | SYSTEM        | `Control\Lsa\JD`, `Skew1`, `GBG`, `Data` | Contains the **encrypted and split** LSA Key                |
  | SECURITY      | `Policy\Secrets`                         | Contains **encrypted secrets**, decrypted using the LSA Key |

### What is Windows NT SYSTEM Access ?<br>

* What is "NT AUTHORITY\SYSTEM"?<br>

  #### <mark style="color:blue;">1. Common Name:</mark>

  * Full name: `NT AUTHORITY\SYSTEM`
  * Also known as: `LocalSystem`, `SYSTEM`, or `NT SYSTEM` <br>

  #### <mark style="color:blue;">2. Privilege Level:</mark>

  * **Highest privilege on a Windows machine**
  * Has full access to the **entire local system**
  * **More powerful than any Administrator account**

  <mark style="color:blue;">**3. Where Does SYSTEM Come From?**</mark>

  * It’s a **built-in Windows account**.
  * Created and managed by the **Operating System**, not visible in standard user account management.
  * Used by Windows **services**, **drivers**, and **core OS components** to perform actions that users or admins normally cannot.

  <mark style="color:blue;">**4. Common Uses of SYSTEM**</mark>

  | Component       | Uses SYSTEM Privilege                                |
  | --------------- | ---------------------------------------------------- |
  | `lsass.exe`     | Handles authentication and security policies         |
  | `services.exe`  | Manages system services                              |
  | `winlogon.exe`  | Handles user logon/logoff                            |
  | Device Drivers  | Run in kernel mode with SYSTEM privileges            |
  | Scheduled Tasks | If configured as SYSTEM, runs with full system power |

  <mark style="color:blue;">**5. Why Is SYSTEM So Critical?**</mark><br>

  #### <mark style="color:green;">1.</mark> <mark style="color:green;"></mark><mark style="color:green;">**Direct Kernel Access**</mark>

  * SYSTEM can call **native APIs**, access memory, the registry, and any file.
  * It can also **impersonate other users**, including administrators.

  #### <mark style="color:green;">2.</mark> <mark style="color:green;"></mark><mark style="color:green;">**Can Modify Security Descriptors**</mark>

  * It can bypass Access Control Lists (ACLs), even on files and registry keys administrators can't touch.

  #### <mark style="color:green;">3.</mark> <mark style="color:green;"></mark><mark style="color:green;">**Used by Windows Services**</mark>

  * Services running as SYSTEM can **persist**, **escalate privileges**, and **survive reboots**.

  #### <mark style="color:blue;">6. Why Attackers Want SYSTEM Access:</mark>

  <mark style="color:green;">Once an attacker has SYSTEM, they can:</mark>

  * Dump LSASS memory to extract credentials.
  * Create persistence mechanisms (like services or registry keys).
  * Disable antivirus and EDR.
  * Access SAM and SECURITY hives in the registry.
  * Install rootkits and run arbitrary code without restriction.<br>

  <mark style="color:blue;">**7. Common Tools/Techniques to Gain SYSTEM:**</mark>

  | Tool/Technique                              | Purpose                                  |
  | ------------------------------------------- | ---------------------------------------- |
  | `PsExec.exe -s`                             | Run a command as SYSTEM                  |
  | `Mimikatz`                                  | Dump SYSTEM-level secrets                |
  | Exploits (e.g., Token Privilege Escalation) | Elevate to SYSTEM                        |
  | Scheduled Tasks                             | Create a SYSTEM task                     |
  | Service DLL Hijacking                       | Replace a DLL loaded by a SYSTEM service |
  | UAC Bypass                                  | Some methods escalate to SYSTEM silently |

  \
  8\. In Windows, "<mark style="color:blue;">**SYSTEM**</mark>" (also called *<mark style="color:purple;">**LocalSystem**</mark>*) is the **highest privilege account** on a Windows machine. It’s even **more powerful than an&#x20;**<mark style="color:blue;">**Administrator**</mark>.

| Privilege Level                      | Description                                                                                                                     |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| 🧍 Standard User                     | Limited rights, can't install software or make system changes.                                                                  |
| 👑 Administrator                     | Can install programs, manage users, and control most of the system.                                                             |
| 🛡️ **SYSTEM** (NT AUTHORITY\SYSTEM) | **Full access** to everything on the local machine, including other users' data, LSASS memory, protected registry keys, et..... |

### What Are SYSTEM-Level Secrets?

* ➤ **Definition:**

  > <mark style="color:blue;">**SYSTEM-level secrets are security-critical pieces of information that are accessible only to processes running under the SYSTEM context or with kernel-level access.**</mark> &#x20;
* These include:

  | Type                       | Examples                                                   |
  | -------------------------- | ---------------------------------------------------------- |
  | **Credential secrets**     | NTLM hashes, clear-text passwords, Kerberos tickets        |
  | **Service secrets**        | DPAPI master keys, LSA secrets, machine account passwords  |
  | **Token secrets**          | Access tokens, security identifiers (SIDs), privilege info |
  | **Crypto secrets**         | Private keys, BitLocker keys, certificate keys             |
  | **Registry-based secrets** | SAM database, SECURITY hive, LSA secrets                   |

## DPAPI (Data Protection API) in Windows Internals

* ### ➤ What is DPAPI?

  > <mark style="color:blue;">**DPAPI (Data Protection API) is a Windows built-in encryption framework used to securely store and retrieve sensitive data, such as:**</mark>

  * Saved credentials
  * Wi-Fi passwords
  * Browser secrets (Chrome, Edge, IE)
  * RDP credentials
  * Certificates and private keys

  It’s available **since Windows 2000** and is used **transparently by applications** through simple APIs.<br>

### Window User Profiles&#x20;

* A <mark style="color:blue;">**Windows user profile**</mark> appears to be a way for the operating system to manage individual user settings and data.<br>
* **Windows User Profile ?**

> <mark style="color:blue;">**A Windows User Profile is a structured, user-specific container that holds personal data, application settings, user-specific registry settings, and security artifacts like "**</mark>**DPAPI keys**<mark style="color:blue;">**" and credentials also representing the user's characteristics and preferences within the operating system. It is loaded when a user logs on and unloaded upon logoff.**</mark> <mark style="color:blue;"></mark>&#x20;

* It is created the first time a user interactively logs onto a computer, not when accessing shared network folders, ensuring a personalized experience. The primary purpose is to save and load configuration information, such as desktop arrangements, network connections, and application settings, each time the user logs on, providing consistency and privacy.<br>

* <mark style="color:blue;">**User profiles provide the following advantages:**</mark>
  * When the user logs on to a computer, the system uses the same settings that were in use when the user last logged off.
  * When sharing a computer with other users, each user receives their customized desktop after logging on.
  * Settings in the user profile are unique to each user. The settings cannot be accessed by other users. Changes made to one user's profile do not affect other users or other users' profiles.

* <mark style="color:blue;">**Each profile is:**</mark>
  * **Linked to a unique SID (Security Identifier)**
  * **Stored on disk (usually under `C:\Users`)**
  * **Mapped to the registry hive `HKEY_CURRENT_USER`**
  * **Used to isolate user settings and secrets**

* <mark style="color:blue;">**Profile Structure on Disk/Location**</mark>&#x20;

  ```plaintext
  C:\Users\<Username>\
  ```

* <mark style="color:blue;">**Key Folders/Components**</mark>&#x20;

  * **AppData** (hidden): <mark style="color:blue;">**plays a crucial role in how applications store user-specific data.**</mark>&#x20;
    * **Local** (`AppData\Local`): Machine-specific data (e.g., cached files, temp files).
    * **Roaming** (`AppData\Roaming`): Syncs across devices (Like ... Outlook signatures, SSH keys).
    * **LocalLow** (`AppData\LocalLow`): Low-integrity data (Like ... browser sandboxed data).
  * **Documents**, **Desktop**, **Downloads**: User-created files.
  * **NTUSER.DAT**: Registry hive for the user (loaded as `HKEY_CURRENT_USER`).
  * **UsrClass.dat**: COM class registrations (loaded as `HKEY_CLASSES_ROOT`).

* <mark style="color:blue;">**Windows Profiles Internals**</mark>

  #### <mark style="color:green;">**Profile Creation Process**</mark>

  1. **First Logon**:

     * Copies the **Default User Profile** (`C:\Users\Default`) to create a new profile.
     * Assigns NTFS permissions to the user’s SID.\
       \ <mark style="color:blue;">**1.**</mark>**&#x20;NTFS permissions to the user’s SID** refers to the access control settings applied to a user’s profile folder (As ..... C:\Users\\\<Username>) using the **NT File System (NTFS)** security model, tied to the user’s **Security Identifier (SID)**.\
       \
       **2.** **Key Components**

       * **NTFS Permissions&#x20;**<mark style="color:blue;">**: These are rules defining who can access files or folders on an NTFS-formatted drive and what actions they can perform (e.g., read, write, modify, or full control).**</mark>
       * **User Profile Folder**: <mark style="color:blue;">**The folder storing a user’s personal data and settings (e.g., Documents, Desktop), typically located at C:\Users\\\<Username>.**</mark>
       * **SID (Security Identifier)**: <mark style="color:blue;">**A unique alphanumeric string assigned to each user account in Windows ( S-1-5-21-...). It identifies the user or group in the system, independent of the username, ensuring consistent access even if the username changes.**</mark>

       &#x20;**3.  W**hat It Means\ <mark style="color:blue;">**When a Windows user profile is created (e.g., upon first login), the system assigns NTFS permissions to the user’s profile folder, linking those permissions to the user’s SID. This ensures:**</mark>

       * **Exclusive Access**: <mark style="color:blue;">By default, only the user (identified by their SID) has full control over their profile folder. Other users, including administrators, are typically restricted to prevent unauthorized access to personal files.</mark>
       * **Security and Privacy**: <mark style="color:blue;">The SID-based permissions protect sensitive data (e.g., Documents, AppData) by ensuring only the account associated with that SID can access or modify the folder’s contents.</mark>
       * **Consistency Across Systems**: <mark style="color:blue;">For roaming profiles (used in network environments), the SID ensures the correct user retains access to their profile, even on different computers, as the SID remains constant.</mark>

     &#x20;      **4.** How It Works

     * When a user logs in for the first time, Windows creates their profile folder and sets NTFS permissions. The user’s SID is added to the folder’s **Access Control List (ACL)** with permissions like "Full Control."
     * The ACL might also include permissions for:
       * <mark style="color:blue;">**SYSTEM**</mark>: For system processes to manage the profile.
       * <mark style="color:blue;">**Administrators**</mark>: Often with limited or no access to user data, unless explicitly granted.
     * Other users’ SIDs are typically denied access to prevent unauthorized viewing or editing.
     * You can view these permissions by right-clicking the profile folder (C:\Users\\\<Username>), selecting **Properties** > **Security** tab, where the SID or resolved username appears with associated permissions.<br>
  2. **Registry Initialization**:

     * `NTUSER.DAT` is initialized from `Default User\NTUSER.DAT`  , Windows NT inherit all properties of the  default user for the first logon User.
     * Loaded into `HKEY_USERS\<SID>` and linked to `HKEY_CURRENT_USER`.

       <figure><img src="/files/p0ET1ytEzECKk4KVN2VE" alt=""><figcaption><p>Registry Hive we talk about<br></p></figcaption></figure>

       1\.  **What is HKEY\_USERS\\\<SID>** <br>

       **a.** When a user logs into Windows, the system loads their registry settings from **`NTUSER.DAT`** (stored in their profile folder) into the **`HKEY_USERS\<SID>`** hive and then creates a symbolic link to **`HKEY_CURRENT_USER` (HKCU)**. This process ensures that user-specific settings are available to applications in a standardized way.\
       \
       \
       **b.&#x20;**<mark style="color:blue;">**Step 1 ( User Authentication )**</mark>

       * When a user logs in, **`winlogon.exe`** triggers the **Local Security Authority Subsystem Service (LSASS)** to authenticate the user.
       * Upon successful login, the **User Profile Service (`ProfSvc`)** retrieves the user’s **Security Identifier (SID)** and checks:
         * **Local Profile**: `C:\Users\<Username>\NTUSER.DAT`
         * **Roaming Profile** (if domain-joined): `\\Server\Profiles\<Username>\NTUSER.DAT`

       **c.&#x20;**<mark style="color:blue;">**Step 2**</mark>**&#x20;Loading `NTUSER.DAT` into `HKEY_USERS\<SID>`**\
       \
       **d.&#x20;**<mark style="color:blue;">**Step 3**</mark>**&#x20;Linking `HKEY_CURRENT_USER`**&#x20;

       * After loading into `HKEY_USERS\<SID>`, Windows creates a **symbolic link**:
         * **`HKEY_CURRENT_USER`** → **`HKEY_USERS\<SID>`**
       * This allows applications to access user settings via a consistent **`HKCU`** path, regardless of the actual SID.

       #### Why are **other user SIDs** there too ?

       Even though **User One** is logged in, you might still see **other users’ SIDs** listed. Here’s why:<br>

       **1. Another user is still logged in**

       * Windows lets users switch without logging out (Fast User Switching).
       * If User Two is still logged in, their settings are still loaded too.

       &#x20;**2. Background processes**

       * Some programs or services might run as another user, which temporarily loads their registry settings.

       &#x20;**3. Domain or shared computers**

       * On work or school computers, profiles are sometimes cached.
       * If other people logged into the machine before, their settings might still be there.

       &#x20;**4. Admins loaded them manually**

       * IT people can open another user’s settings by loading their `NTUSER.DAT` file into the registry

       **e.** <mark style="color:blue;">Step 4</mark> <mark style="color:blue;"></mark><mark style="color:blue;">**Profile Loading (Logon Sequence)**</mark> <br>

       #### **Profile Loading (Logon Sequence)**

       1. <mark style="color:blue;">**Authentication**</mark>: LSASS (Local Security Authority Subsystem Service) validates credentials.
       2. <mark style="color:blue;">**Profile Selection**</mark>:
          * For domain users: Checks for roaming profiles.
          * For local users: Uses the local profile.
       3. <mark style="color:blue;">**Hive Mounting**</mark>:
          * The **User Profile Service (ProfSvc)** loads `NTUSER.DAT` into the registry.
          * Applies Group Policies and logon scripts.

       #### **d.&#x20;**<mark style="color:blue;">**Profile Unloading (Logoff Sequence)**</mark>

       * **Sync Changes**: For roaming profiles, uploads updates to the network share.
       * **Hive Unload**: Unmaps `HKEY_CURRENT_USER` and closes handles to `NTUSER.DAT`.

     <br>

     ### Types of User Profiles <a href="#types-of-user-profiles" id="types-of-user-profiles"></a>

     ### &#x20;

     ### **Types of User Profiles in Windows**

     #### 1. **Local User Profile**

     * **What it is:**\
       A profile created and stored **on the local machine** when a user logs in for the first time.
     * **Where it's stored:**\
       `C:\Users\<Username>`
     * **Used by:**\
       Users who log into **local accounts or domain accounts** on one computer.
     * **Example:**\
       If you log in as `John` on one computer, your settings and files are saved only on that computer.<br>

     #### <mark style="color:blue;">2.</mark> <mark style="color:blue;"></mark><mark style="color:blue;">**Roaming User Profile**</mark>

     * **What it is:**\
       A profile stored **on a network server**, not just the local machine.
     * **Where it's stored:**\
       Profile gets downloaded to the PC from a server at login and saved back to the server at logoff.
     * **Used by:**\
       Users in organizations using **Active Directory/domains** who move between PCs.
     * **Benefit:**\
       User gets the same desktop, settings, and files no matter which company computer they log into.\
       \ <mark style="color:blue;">**3. Default User Profile**</mark>

       * **What it is:**\
         A template profile that Windows uses to create a **new local user’s profile**.
       * **Stored in:**\
         `C:\Users\Default`
       * **Used for:**\
         Copying basic files and settings when a new profile is being created.
       * **Admins can modify** it to set default settings for new users.<br>

       ### Summary Table

       | Profile Type  | Stored Where      | Can Save Changes? | Used For                                |
       | ------------- | ----------------- | ----------------- | --------------------------------------- |
       | **Local**     | C:\Users\Username | ✅Yes              | Regular PC users                        |
       | **Roaming**   | Network share     | ✅ Yes             | Domain users on multiple PCs            |
       | **Mandatory** | Network share     | ❌ No              | Locked-down environments (labs, kiosks) |
       | **Temporary** | Temporary folder  | ❌ No              | Error fallback, profile load failed     |
       | **Default**   | C:\Users\Default  | N/A               | Template for creating new profil        |

     ### &#x20;    &#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xal3aref.gitbook.io/0xal3aref/active-directory-domain-controller/introduction-to-ad-domain-service/windows-system-internals-101/windows-sid/logon-base-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.