LSA, LSASS, SAM, and NTDS: Which component manages what?

1. Core mechanism

The path from an application on a Windows host through SSPI/LSA interfaces, the LSASS process boundary, and the local SAM store; domain authentication additionally reaches a domain controller and its AD DS directory store. This lesson locates the components; token internals are covered in 02.03, and credential storage and protection in 10.x.

Interfaces and specifications

• LSA: security-authority and subsystem functions that provide local security policy, logon, and authentication-package architecture.
• LSASS: the critical system-process boundary that hosts LSA functions and authentication/security package components.
• SAM: the local user and group account store present on each Windows system.
• AD DS/NTDS: the directory service for domain objects and its persistent store on a domain controller; Ntds.dit is not a member-workstation store.
• SSPI and LSA authentication-package interfaces: the boundary through which applications work with security packages; normal application flow does not read SAM or Ntds.dit directly.
• 4611 Version 0: records a trusted logon process registering with LSA in the Security channel.

Architectural function, running process, and storage are different layers

LSA names the authority functions of Windows’s local security policy and logon architecture. LSASS is the protected process boundary for these functions and authentication packages.

SAM is the store for local accounts. Using SAM to verify a local account does not make SAM the same component as LSASS.

This distinction keeps incident analysis precise: the presence of lsass.exe does not prove credential access, and the presence of the SAM file does not prove that anyone read it.

A domain account does not create NTDS on a member host

AD DS stores domain objects on domain controllers and replicates directory data between DCs. Ntds.dit is the persistent file that contains that data on a DC.

When a member workstation receives a domain-account logon request, its local LSA and security packages communicate with the domain authority. Using a domain account does not place a full Ntds.dit store on the workstation.

The local SAM and the domain directory belong to different authorities. The flow must preserve which authority owns an account, especially when short account names match.

Interfaces define a boundary; they are not direct store access

Applications and services normally use package interfaces in the SSPI and LSA authentication model. A supported logon flows from those interfaces to a security package and then to the appropriate local or domain authority.

A local flow may use SAM-backed verification; a domain flow sends the request to the domain authority on a DC. A successful result becomes a logon session and security context on the client host.

Privileged direct access to a store file requires a different security event and different prerequisites from the normal authentication interface.

State and data flow

1. The application or logon component supplies credential information through a supported security interface.
2. The appropriate authentication package inside local LSA/LSASS processes the request.
3. Local-account verification relies on the local SAM authority.
4. For a domain account, the client-side security package communicates with the security authority on a domain controller.
5. The domain controller uses AD DS account data to produce the protocol result.
6. A successful result becomes a logon session and security context on the client or service host.
7. Process telemetry, security events, and store-access evidence remain distinct evidence types.

2. Exploitation

Broken trust assumption

The broken assumption is that only trusted code can load into or access LSASS, and that only authorized security components can reach SAM or AD DS stores.

Technical prerequisites

• High local privilege, unprotected process access, or permission to install a trusted security/authentication extension on the target host.
• Privileged file or system access on the host for a local store such as SAM.
• Separate access and sufficient privilege on a domain controller for the AD DS store.

Exploitation mechanism

Accessing LSASS memory or registering a trusted package targets the process boundary. Accessing SAM or Ntds.dit follows a separate store path with separate prerequisites. Evidence for one path does not prove that the other occurred.

Do not confuse the process boundary with the store boundary

A process attempting to open LSASS supports a memory-access hypothesis, but it does not show that SAM or Ntds.dit was read. Store access requires separate authorization and telemetry.

Conversely, access to a store file does not prove that code loaded into LSASS. Incident analysis should classify the mechanism supported by the evidence.

DC storage has a different security boundary

High local privilege on a member host increases risk to that host's LSASS and SAM, but does not itself grant access to Ntds.dit on a domain controller.

The DC store requires separate access and DC-specific privilege. This lesson does not describe credential extraction or store-copying procedures.

3. Defense & Detection

Telemetry scope

• Audit Security System Extension / Success produces 4611 when a trusted logon process registers; this subcategory has no Failure event.
• 4611 is recorded in the source Windows host's Security channel and uses Version 0.
• Sysmon Event 10 ProcessAccess provides process-open visibility only when Sysmon is installed and configured with appropriate filters.
• Do not hard-code Sysmon fields into the content model without checking the deployed version's sysmon -s schema.
• Evaluate added LSA protection changes with audit mode and compatibility observation before enforcement.

Events and relevant fields

• 4611 / SubjectUserSid, SubjectUserName, SubjectDomainName, SubjectLogonId: the registering subject context.
• 4611 / LogonProcessName: the name registered with LSA for the trusted logon process.
• 4611 / Version 0: the only event version documented; available from Windows Vista/Server 2008.
• Sysmon 10 / ProcessAccess: records one process opening another with the source and target process context; LSASS memory access visibility is only an example.
• CodeIntegrity Operational 3065/3066 audit events and 3033/3063 enforcement events must be interpreted in the context of LSA protection compatibility and applicable operating-system conditions.

4611 shows process registration, not store access

4611 reports that a trusted logon process registered with LSA. It does not show that LSASS memory was read, SAM was opened, or Ntds.dit was accessed.

The event is primarily informational. A Subject or LogonProcessName outside the expected baseline can start an investigation, but is not a conclusion.

Process access requires separate telemetry

Microsoft cites Sysmon Event 10 for inter-process open activity and LSASS memory-access visibility. This telemetry does not replace built-in 4611 and does not exist without Sysmon.

Do not write a portable query with fixed Event 10 fields until the installed Sysmon schema has been verified. Expected EDR, diagnostic, and management tools can produce false positives.

Detection logic · Sigma

title: LSA ile kaydolan trusted logon process
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4611
  condition: selection
fields:
  - SubjectUserSid
  - SubjectUserName
  - SubjectDomainName
  - SubjectLogonId
  - LogonProcessName
falsepositives:
  - Isletim sistemi baslangici ve normal logon bilesenleri
level: low

Query assumptions

• The rule selects only 4611 records; deciding whether one is anomalous requires a host- and operating-system-specific allowlist.
• Subject or LogonProcessName is not evidence of malicious intent alone.
• This query does not detect LSASS ProcessAccess, SAM access or Ntds.dit access.
• The rule was not run on a real SIEM or data set.

False positives

• Normal trusted logon process registrations during operating-system startup.
• Supported authentication or security extension components.
• Documented and approved components of enterprise security products.

Hardening

• Evaluate added LSA protection/PPL against supported operating-system and plug-in compatibility; review audit-mode results first.
• Maintain an inventory of authentication and security packages; compare new 4611 LogonProcessName values with approved change records.
• If you use Sysmon ProcessAccess, verify the version-specific schema and filters, then baseline expected diagnostic and security tools.
• Do not treat DC and member-host protection as equivalent; apply DC-specific least privilege, backup protection, and management boundaries to AD DS store access.
• Pilot hardening changes, monitor CodeIntegrity audit/enforcement events, and keep a rollback path ready.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" />
    <EventID>4611</EventID>
    <Version>0</Version>
    <Channel>Security</Channel>
    <Computer>HOST01.besiktas.example</Computer>
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-18</Data>
    <Data Name="SubjectUserName">HOST01$</Data>
    <Data Name="SubjectDomainName">BESIKTAS</Data>
    <Data Name="SubjectLogonId">0x3e7</Data>
    <Data Name="LogonProcessName">SyntheticLogonProcess</Data>
  </EventData>
</Event>

Two reality checks

Assumption: LSA, LSASS, SAM and NTDS are four names of the same database.

In fact: LSA denotes security-authority and architectural functions; LSASS is the process boundary that hosts them; SAM is the local account store; and NTDS is the AD DS directory store on a domain controller.

Assumption: Signing in to a workstation with a domain account means the workstation contains the domain database.

In fact: The member computer's local security components communicate with the domain authority. The full domain directory store resides on domain controllers; a member workstation does not gain Ntds.dit.

Sources

• Microsoft · Credentials Processes in Windows Authentication
  Windows credentials authentication overview, Local Security Authority and Security Accounts Manager database.
• Microsoft · LSA Authentication Model
  The LSA authentication-package and SSPI extension model.
• Microsoft · Active Directory Domain Services Overview
  The directory store and replication between domain controllers.
• Microsoft · Directory data store
  Paragraph describing Ntds.dit as the directory data store on a DC; archived Server 2003/R2 source.
• Microsoft · 4611(S) A trusted logon process has been registered with the Local Security Authority
  Event Description, Event XML, Field Descriptions and Recommendations.
• Microsoft · Audit Security System Extension
  Subcategory description, event volume, and Events List.
• Microsoft Sysinternals · Sysmon
  Event ID 10: ProcessAccess and the Operational channel description.
• Microsoft · Configure added LSA protection
  Audit mode; CodeIntegrity 3065/3066 and 3033/3063; automatic-enablement conditions.