Video summary

Windows Security: Secrets Storage & Credential Theft Protection (SAM, LSASS, LAPS, Guard)

Main summary

Key takeaways

Educational

Main ideas & lessons (Windows secrets storage & credential theft protection)

Where Windows stores “secrets” (and what attackers target)

  • SAM (Security Account Manager)

    • Stores local account credential hashes.
    • Stored as a hash database (not plaintext passwords).
    • Common attacker-target locations:
      • C:\Windows\System32\config\SAM
      • Mapped registry locations like HKLM\SAM / HKLM\SAM\SAM (as described).

  • LSASS / “LSA secrets” context (via LSA memory)

    • When a user logs in, Windows converts credentials and keeps derived secrets/tokens/hashes in LSA memory to support single sign-on (SSO).
    • Attackers steal from LSASS/LSA memory to enable:
      • Pass-the-Hash
      • Pass-the-Ticket
      • Lateral movement and privilege escalation.

  • LSA secrets (registry Security hive)

    • Located at C:\Windows\System32\config\SECURITY / corresponding registry “Secrets” keys.
    • Often contains service account credentials and other protected secrets.
    • Attacker goal: extracting plaintext service credentials (especially if practices are weak).

  • Credential Manager

    • Stores “saved credentials” (e.g., for RDP, SMB) encrypted using DPAPI (keys tied to the user’s secrets).
    • Typically more protected than LSA/LSA secrets, but still sensitive and should be limited.

  • Kerberos artifacts

    • Kerberos tickets found in LSA memory are important for attackers:
      • Ticket Granting Tickets (TGT)
      • Service tickets (TGS)

Weak vs strong credential types: LM vs NT/“NTLM hash” vs others

  • LM hashes

    • Deprecated and should be disabled.
    • Why they’re weak:
      • Forces uppercase conversion.
      • Password length limitations (max 14 characters).
      • Splits the password into two 7-character halves, making cracking easier:
        • If a password is ≤ 7 chars, the second half is predictable/default.
      • Attackers can infer password length characteristics.
      • Known plaintext string encryption behavior adds weakness.

  • NTLM hashes (“NT hash” / “anti-hash” as spoken in subtitles)

    • Uses newer hashing (described as MD4-based).
    • Still not “strong” enough to rely on if passwords are weak/short/guessable.

Offline cracking feasibility (key takeaway)

  • The presenter demonstrates/argues that short/simple passwords are crackable even without “powerful” hardware (in the demo environment).
  • Practical consequence:
    • Don’t rely on hash strength alone—use a strong password policy.

Methodology / recommendations (explicit instruction-style points)

A) Password policy guidance

  • Enforce password lengths

    • At least 12 characters for user accounts
    • At least 17 characters for administrator accounts

  • Enforce complexity for accounts (emphasized).

  • Enforce frequent rotation

    • At least once per year.

  • Avoid predictable or guessable secrets

    • No names, dates of birth, pet names, etc.
    • Prefer random passwords.

  • Logic emphasized:

    • Small increases in password length/complexity make brute-force/cracking exponentially harder.
    • Anything under ~12 characters is considered highly crackable (per presenter’s emphasis).

B) Disable or limit insecure credential mechanisms

  • Disable LM hashes

    • Enforced via Group Policy / security baselines.

  • Disable WDigest plain-text password caching

    • Controlled by a registry key.
    • Risk: enables plaintext credentials in LSA memory on login.

  • Avoid “delegation of default credentials”

    • Related to Remote Desktop/Remote App SSO style features.
    • Risk: plaintext credentials become available in memory for SSO convenience.

  • Enforce disabling plaintext credential-related options:

    • WDigest and other credential caching behaviors.
    • Keep credential delegation tightly controlled (use “fresh credentials” when possible; “default credentials” is called out as risky).

C) Use safer account models for service credentials (tiering & account selection)

  • Don’t use high-privilege domain admin accounts as service accounts

    • Anti-pattern highlighted:
      • A domain admin-style account used as a service identity for apps on “lower-tier” servers.
    • Consequence:
      • If an attacker compromises the server/application context, they can extract service credentials and escalate to domain admin.

  • Prefer service account types with managed rotation and reduced exposure

    • GMSA (Group Managed Service Accounts) recommended:
      • Password rotation described as every 30 days
      • Long, randomized password material (~120 characters “nonsense” per subtitles)
      • Device-scoped use to permitted systems

  • Ensure least privilege

    • Grant only needed rights.
    • Correctly align tier model:
      • If an account is for tier-1 assets, it must not contain tier-0 privileges.

D) Protect LSA/LSASS memory from credential theft

  • Use Protected Users group

    • Goal stated:
      • Prevent NTLM hash caching/usage in LSA memory (per demo).
    • Effect:
      • Shifts authentication toward Kerberos only (NTLM not stored/cached for those users).
    • Important nuance:
      • Kerberos tickets are still present and can be abused via pass-the-ticket.

  • Use Credential Guard (where supported)

    • Protects LSA secrets by isolating credential processing.
    • Requirements mentioned:
      • VBS
      • CPU virtualization support
      • SLAT (second level address translation)
      • UEFI secure boot
    • Behavior described:
      • Credentials/tickets/hashes are moved out of normal LSASS memory into an isolated secure mode (VTL1 / “LSI” isolation).
    • Limitations:
      • Credential Guard doesn’t remove every Kerberos attack path—tickets may still be stealable (pass-the-ticket remains possible).

E) Reduce credential persistence & what can be extracted

  • Avoid local admin reuse across many machines

    • Presenter notes admins often reuse one password across devices.
    • Countermeasure:
      • Use LAPS to rotate local admin passwords and store them centrally.

  • Avoid adding users to local Administrator group

    • Demonstrated as a risk factor enabling easier credential dumping with common tools.

What the demonstrations show (practical “how it plays out”)

  • Hash cracking demo

    • LM hashes crack quickly for short/simple passwords.
    • NTLM/“anti-hash” cracking time is similar for short passwords but becomes harder as password length increases.

  • LSA memory credential theft demo (Mimikatz-like tooling described)

    • With admin privileges, attacker can dump LSA memory secrets.
    • Demonstrated outcomes:
      • Pass-the-Hash
      • Plaintext passwords when WDigest is enabled
      • Plaintext credentials when default credential delegation is enabled
      • Service account password extraction from LSA secrets/registry when service accounts are misconfigured

  • Service account remediation demo

    • Switching from domain admin-based service account to GMSA.
    • Emphasis:
      • Delete old stored secret values in the registry for a clean cutover (presenter describes deleting old registry values under policy secrets).

  • Protected Users demo

    • When a user is in Protected Users, the demo shows NT hash material removed from LSA memory.
    • Kerberos remains (tickets still relevant).

  • Credential Guard demo

    • Enabling Credential Guard causes stolen secret material to become encrypted/isolated and not directly usable (LSA isolation observed).
    • Tickets still exist; protection focuses on preventing the most damaging credential theft paths.

Speakers / sources featured

  • David — narrator; system security engineer (course creator).

  • Microsoft — referenced technologies and mechanisms:

    • SAM, LSASS/LSA, Kerberos, LAPS, DPAPI, WDigest, credential delegation, Protected Users, Credential Guard/VBS, UEFI Secure Boot/SLAT concepts, Group Policy.

  • Tools / platforms mentioned

    • John the Ripper (hash cracking)
    • Mimikatz
    • Secure Secrets Dumper (named as a tool used in the demo)
    • Sysinternals (process execution approach mentioned)
    • LAPS (Local Administrator Password Solution)
    • AD Probe / Horizon Secured / acade academy / Link page (creator’s resources/website)

Original video