Local Accounts on Domain-Joined Machines

Golden Rule of the Local SAM

The local SAM database does NOT disappear when a machine joins an Active Directory domain.

The local machine Administrator account (RID 500) and the domain Administrator account (RID 500) are two completely separate cryptographic entities, sharing neither SID, hash, nor password.

Concept

When a Windows workstation or server joins an Active Directory domain:

1. The Local SAM Remains Fully Operational: Located at %SystemRoot%\System32\config\SAM, it continues to manage local machine accounts (.\Administrator, .\Guest, local maintenance accounts).
2. Two Coexisting Authentication Realms:
   • Local: Validated by local LSA against the SAM database (HOSTNAME\user).
   • Domain: Validated by Kerberos or Netlogon against Domain Controllers (DOMAIN\user).
3. Default Group Nesting: During the domain join process, Windows automatically inserts the domain group Domain Admins into the machine’s local Administrators security group, establishing administrative reach.

---

Why It Matters in DFIR

Local account usage on domain-joined machines is one of the most prolific lateral movement vectors in enterprise breaches:

• DC-Free Lateral Movement (Local Pass-the-Hash): If fleet systems were provisioned from a cloned golden image sharing the same local Administrator password, an attacker who dumps the local NTLM hash on one workstation can pivot via SMB across every other machine on the network without triggering a single authentication event on domain controllers!
• LAPS (Local Administrator Password Solution): LAPS mitigates this vulnerability by generating a randomized, unique password per machine, stored in an encrypted AD attribute (msLAPS-Password or legacy ms-Mcs-AdmPwd). In DFIR, auditing LAPS coverage and read events is vital.
• Bypassing Central SIEM Visibility: Authentications using local accounts (Logon Type 3 or 10) are logged exclusively in the local Security event log of the target endpoint. SIEMs collecting only DC logs will remain blind to this activity.

---

How It Works

Authentication Authority Resolution

Logon Attempt: "Administrator"
                     │
        Does string contain a domain prefix?
                    / \
                   /   \
           YES    /     \   NO
                 /       \
                ▼         ▼
    "DOMAIN\Administrator"    ".\Administrator" OR Workgroup host
                │                         │
                ▼                         ▼
   Validated by KDC / NTDS    Validated by local LSA / SAM
   SID: S-1-5-21-DOM-500      SID: S-1-5-21-MACHINE-500

1. LocalAccountTokenFilterPolicy Enforcement:
   • By default on modern Windows versions, non-RID 500 local accounts connecting over the network (SMB/WMI/WinRM) undergo UAC token stripping and lose administrative privileges (filtered to Medium Integrity).
   • Only the built-in local Administrator account (RID 500) retains full administrative network tokens, unless LocalAccountTokenFilterPolicy = 1 was configured by administrators.

---

What Is Possible

• Pivoting Host-to-Host via Identical Local Credentials: If the RID 500 account shares a password across machines, an attacker can execute Pass-the-Hash via psexec or wmiexec across the entire fleet without contacting a DC.
• Logging into Workstations During Network Outages: Local accounts guarantee break-glass access when network links or DCs are completely unavailable.
• Auditing LAPS Password Queries: Querying LAPS attributes in Active Directory logs Event ID 4662 on domain controllers, revealing who accessed local administrator passwords.

---

What Is Not Possible

• Accessing Domain Resources Using a Local Account: A local account can only authenticate to its local host. It possesses no identity in Active Directory and cannot access domain shares requiring domain credentials.
• Reviewing Local SAM Logons on Domain Controllers: Authenticators against .\Administrator generate zero events on Active Directory DCs.
• Automatic Password Synchronization Between Local SAM and AD: Updating a domain account password has zero effect on local machine accounts.

---

Common DFIR Confusions

Frequent Confusion	Verifiable Forensic Reality
”The attacker logged in as Administrator, so the domain is compromised.”	Check the SID: if the SID begins with the local machine prefix, it is a local account. The domain is not necessarily compromised.
”We collect all DC logs, so we see all Pass-the-Hash attacks.”	False. Pass-the-Hash leveraging local accounts never touches domain controllers and is completely invisible without endpoint log collection.
”Disabling the local Administrator account stops local lateral movement.”	If LocalAccountTokenFilterPolicy = 1 is configured, any local account in Administrators enables full lateral movement.

---

Concrete Forensic Example

During an incident response engagement at a mid-sized enterprise:

• Domain controllers showed zero abnormal events, yet 40 client workstations were encrypted by ransomware.
• Triage on the patient-zero machine revealed an LSASS memory dump that harvested the local Administrator NTLM hash (S-1-5-21-209384-500).
• This hash was identical across all 40 machines due to an unmanaged baseline image without LAPS.
• The threat actor used a PowerShell script to invoke wmiexec with the local hash across all subnet IPs.
• DFIR Finding: The entire ransomware outbreak bypassed domain controller visibility by riding on local accounts.

---

Key Forensic Artefacts

1. Local Endpoint Security Event Logs:
   • Event ID 4624 (Logon Type 3): TargetDomainName matches the local computer hostname; TargetUserSid begins with the machine SID prefix.
   • Event ID 4672: Privileges assigned to .\Administrator.
2. Active Directory LAPS Telemetry (on DCs):
   • Event ID 4662: Read operation against msLAPS-Password or ms-Mcs-AdmPwd.
3. Windows Registry:
   • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy.

---

Investigation Methods

1. Differentiate Local vs Domain Accounts in Telemetry: Compare TargetDomainName against the host computer name versus the AD NetBIOS domain name.
2. Audit LAPS Implementation Across All Workstations: Run Get-ADComputer -Filter * -Properties msLAPS-PasswordExpirationTime to verify LAPS coverage.
3. Detect Clustered Local Type 3 Logons: Search for identical source IP addresses establishing Type 3 sessions using local credentials across multiple endpoints.

---

Investigative Tooling

• PowerShell AD / LAPS Module:

  Get-ADComputer -Identity "WS-01" -Properties msLAPS-PasswordExpirationTime

• Kansa / Velociraptor: Hunts querying Event ID 4624 where TargetDomainName == ComputerName across all endpoints.

---

Key Takeaways

• The local SAM database remains active and independent on domain-joined machines.
• Local authentications never touch Active Directory domain controllers.
• Local password reuse allows massive lateral movement undetectable from DC logs alone.
• LAPS is the only architectural defense against local credential reuse.

---

References & Further Reading

• Microsoft Learn: Windows LAPS Overview
• Card 01 — Windows Identities: Local Accounts vs Domain Accounts
• Card 04 — Local Administrator vs Domain Administrator
• Card 06 — Windows Access Tokens and Security Context