Windows Internals for Defenders Guide: Processes, Tokens, Registry and LSASS

Most Windows intrusions are not exotic: they abuse ordinary operating system mechanics such as access tokens, privileges, services, autorun registry keys and the credentials held by LSASS, and defenders who do not understand those mechanics cannot tell normal from malicious. This guide explains how Windows decides who a process is and what it may do, where persistence lives, how credentials are held and protected, and which telemetry sources (ETW, the Security log, Sysmon, AMSI) show it. It starts in plain language and then goes to practitioner depth: real privilege names, registry paths, event IDs and settings. It is written for SOC analysts, detection engineers, endpoint and identity engineers who need a working model of Windows rather than a hardening checklist, which is covered separately.

Key takeaways

• Every process runs with an access token that carries the user SID, group SIDs, privileges and an integrity level, and almost every Windows access decision is made against that token.
• A handful of privileges are effectively administrator: SeDebugPrivilege, SeImpersonatePrivilege, SeTcbPrivilege, SeLoadDriverPrivilege, SeBackupPrivilege and SeRestorePrivilege should be granted to as few accounts as possible and watched through event 4672.
• Services are non-human identities: each one runs under an account, from LocalSystem to a virtual account or a gMSA, and the choice decides how much damage a compromised service can do on the host and on the network.
• LSASS holds the credentials attackers want, so turn on LSA protection (RunAsPPL) and Credential Guard where supported, and treat any unexpected access to lsass.exe as a high-severity signal.
• Visibility comes from layers: ETW is the engine underneath, the Security log records logons and privilege use, Sysmon adds process and registry detail, and AMSI lets security tools inspect scripts at run time.

Processes, threads and the security context

A process is a container: it owns a virtual address space, open handles and one primary access token. A thread is what actually executes code, and by default each thread uses its process's primary token. A thread can also hold an impersonation token, which lets a server thread act with a client's security context for one request. Microsoft documents that a thread impersonating a client holds both tokens.

• Parent and child: a new process normally inherits a copy of its parent's token. This is why process ancestry is the backbone of endpoint detection: winword.exe starting powershell.exe is suspicious because of the relationship.
• Handles: to read another process's memory a caller must open a handle with rights such as PROCESS_VM_READ. The access check against the target's security descriptor, and privileges such as SeDebugPrivilege that bypass it, are what defenders monitor when they watch for access to lsass.exe (Sysmon event ID 10, ProcessAccess).
• Injection: because code runs in threads, an attacker who can open a process with write and thread creation rights can run code inside it and inherit its token. ATT&CK tracks this as T1055 Process Injection, and token theft as T1134.001 Token Impersonation/Theft.

Access tokens, privileges and integrity levels

Microsoft defines an access token as an object that describes the security context of a process or thread. It contains the user SID, group SIDs, a logon SID, the list of privileges and whether each is enabled, an owner SID, a default DACL, optional restricting SIDs, the token type (primary or impersonation) and impersonation level. Two points matter for defenders: AdjustTokenPrivileges only enables or disables privileges already in the token, it cannot add new ones, so a privilege an account was never granted cannot appear; and privileges are granted through User Rights Assignment (Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment).

Privileges that matter most

Microsoft's documentation for event 4672 (Special privileges assigned to new logon) lists these and a few more as "sensitive" privileges and recommends alerting when 4672 fires for an account that is not LOCAL SYSTEM, NETWORK SERVICE, LOCAL SERVICE or an expected administrator, and correlating with 4624 on the Logon ID.

Integrity levels

Mandatory Integrity Control adds a label to every token and securable object. The levels are Low (S-1-16-4096), Medium (S-1-16-8192, standard users and unlabelled objects), High (S-1-16-12288, elevated administrators) and System (S-1-16-16384, services). By default every object carries a no-write-up policy, so a Low process cannot write a Medium object even if the DACL allows it, and the integrity check is made before the DACL check. A new process receives the lower of the user's level and the executable file's level. For detection, a High or System integrity process launched from a Medium parent without a consent event is worth investigating.

User Account Control

When a member of Administrators signs in, Windows creates two tokens: a filtered standard user token, with administrative privileges and SIDs removed, and a full administrator token. Explorer runs with the filtered token, so applications run as a standard user until the user consents (consent prompt, the default for administrators in Admin Approval Mode) or supplies administrator credentials (credential prompt, the default for standard users). Prompts appear on the secure desktop by default. Microsoft presents UAC as a way to reduce the ability of malicious code to run with administrator privileges; practitioners should not treat it as a hard boundary, because UAC bypass is a well catalogued technique (ATT&CK T1548.002 Bypass User Account Control). The durable control is not giving daily-use accounts local administrator rights at all. See the Endpoint Privilege Management Guide.

Services and service accounts

A Windows service is a program the Service Control Manager (SCM) starts, usually at boot, under a configured account. When the service starts, the SCM logs on to that account and the system creates the token for the service process. Service definitions live under HKLM\SYSTEM\CurrentControlSet\Services\<name> (ImagePath, ObjectName for the account, Start type). Every service is therefore a non-human identity with a credential, privileges and a network identity.

• Decision guidance: prefer a virtual account for a local service, a gMSA for anything spanning hosts, and LocalSystem only when the vendor documents why. A traditional account with a static password is the weakest option and is the main target of Kerberoasting (T1558.003). See the gMSA Guide and the Service Account Security Guide.
• Service creation is a persistence and escalation route (T1543.003 Windows Service). Event 7045 in the System log (a service was installed) and 4697 in the Security log (requires Audit Security System Extension) record new services; an ImagePath pointing at a user-writable folder or a cmd.exe one-liner is a strong indicator.
• Small vs large organisations: a small estate can inventory services by hand; a large one needs an automated inventory of every service's ObjectName. The Service Account Inventory Template gives a starting structure.

The registry and autoruns locations

The registry is a hierarchical configuration database backed by hive files. Microsoft lists the system hives in %SystemRoot%\System32\Config: SAM, SECURITY, SOFTWARE, SYSTEM and DEFAULT, each with .log transaction files, while each user's profile hive is NTUSER.DAT, loaded under HKEY_USERS and seen by that user as HKEY_CURRENT_USER. The SAM hive holds local account password hashes and SECURITY holds LSA secrets, which is why copying these hives (T1003.002 Security Account Manager) is a credential theft technique and why SeBackupPrivilege is sensitive.

Baseline these locations on a known-good build and alert on change rather than trying to judge every value in isolation. Registry modification is tracked as T1112 Modify Registry. Sysmon event IDs 12, 13 and 14 record registry object creation, value set and rename for the keys your configuration includes. For which artefacts survive for investigation, see the Windows Forensic Artefacts Guide.

LSASS, credentials and their protection

The Local Security Authority Subsystem Service (lsass.exe) enforces local security policy, authenticates users and creates their tokens, and caches credential material so that single sign-on to network resources works. That cache (NTLM hashes, Kerberos tickets and keys) is why reading LSASS memory is the classic credential theft technique, ATT&CK T1003.001 LSASS Memory. The detection and response side is covered in the Credential Dumping Guide; here is how the protections work.

Rollout: enable LSA protection audit mode first by setting AuditLevel = 8 under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe and review the CodeIntegrity Operational log for events 3065 and 3066 (a plug-in or driver would be blocked). Audit mode is on by default on Windows 11 22H2 and later. Then enforce on a pilot ring with value 2, which can be rolled back through policy, before moving to value 1 with UEFI lock on high-value systems. Removing the UEFI-locked setting needs Microsoft's opt-out tool, so do not use value 1 until the pilot is clean.

Kerberos and NTLM in one page

Domain authentication on Windows uses two protocols, and their artefacts appear in different event IDs.

• Kerberos (TCP/UDP 88): the client proves its identity to a domain controller's Key Distribution Centre and receives a ticket-granting ticket (event 4768), then asks for service tickets for each service it uses (event 4769). Service tickets are encrypted with a key derived from the service account's password, which is why weak service account passwords are crackable offline and why gMSAs, with long random passwords, defeat Kerberoasting. See the Kerberos Security Guide and Kerberos Delegation Security Guide.
• NTLM: a challenge-response protocol that proves knowledge of the password hash, so the hash itself works as a credential (pass the hash). Domain controllers record NTLM validation as event 4776. NTLM can also be relayed to another server; see the NTLM Relay Guide.
• Logon types in 4624: 2 interactive, 3 network, 4 batch (scheduled task), 5 service, 9 NewCredentials (runas /netonly), 10 RemoteInteractive (RDP). A service account appearing with logon type 2 or 10 means a human is using it, which is a policy breach worth alerting on.

Event details and audit policy settings are in the Windows Event Log Guide.

Telemetry: ETW, the Security log, Sysmon and AMSI

Event Tracing for Windows (ETW) is the kernel-level tracing facility most Windows telemetry is built on. Microsoft describes three parts: providers generate events, controllers start and stop trace sessions and enable providers, and consumers read events from a session in real time or from a log file. EDR products consume ETW providers (including the Microsoft-Windows-Threat-Intelligence provider, available only to protected anti-malware processes) alongside their own kernel callbacks. Attackers who stop sessions or tamper with providers fall under ATT&CK v20 T1685 Disable or Modify Tools, so a session that stops reporting is itself a signal. ETW also drops events when buffers are full or a consumer is slow, so measure lost events rather than assuming completeness.

AMSI (Antimalware Scan Interface) lets applications hand content to the installed anti-malware product for scanning. Microsoft lists UAC elevation, PowerShell (scripts, interactive use and dynamic code evaluation), Windows Script Host, JavaScript and VBScript, and Office VBA macros as integrated components. Because AMSI scans memory and streams, it sees a script after it has been decoded for execution, which is what makes it valuable against obfuscated and fileless scripts. Pair it with PowerShell Script Block Logging (event 4104).

What to monitor and how to measure it

• Privilege use: 4672 for accounts outside your expected list, and any grant of SeDebugPrivilege or SeImpersonatePrivilege through a GPO change.
• LSASS access: Sysmon 10 or EDR alerts where the target is lsass.exe and the source is not a known security or system binary.
• Persistence: new services (7045, 4697), new scheduled tasks (4698) and changes to the Run, Winlogon and Image File Execution Options keys.
• Service account misuse: interactive or RDP logons (4624 types 2 and 10) by accounts tagged as service accounts.

Metrics that show progress:

1. Percentage of Windows endpoints and servers with LSASS running as a protected process (WinInit event 12 seen since last boot).
2. Percentage of eligible devices with Credential Guard running.
3. Number of services running as traditional domain user accounts, trending down, and percentage of multi-host services on gMSAs.
4. Number of accounts holding SeDebugPrivilege on servers outside the documented exception list (target zero).
5. Percentage of hosts reporting Sysmon or EDR telemetry within the last 24 hours.
6. Mean time to triage an LSASS access alert.

Framework mapping

In CIS Controls v8.1 the same material sits mainly under Control 4 (Secure Configuration), Control 5 (Account Management), Control 6 (Access Control Management) and Control 8 (Audit Log Management).

Common failure patterns

• Everyone is a local administrator. Filtered tokens and UAC prompts then become the only barrier, and one consent click or bypass gives a High integrity token on every machine the user touches.
• Services left on LocalSystem or a domain admin account. A vulnerable web application or backup agent then hands over SYSTEM on the host or domain-wide rights.
• RunAsPPL turned on without audit. A smart card or security plug-in fails to load, the change is rolled back estate-wide and never reintroduced. Use audit mode and a pilot ring.
• Telemetry assumed, not measured. Process command line auditing off, Sysmon on a subset of hosts, or an ETW session silently stopped, so the investigation has gaps exactly where the attacker was.
• Autoruns reviewed without a baseline. Analysts cannot tell a vendor updater from a persistence implant, so either everything or nothing is escalated.

Practitioner checklist

• Remove standing local administrator rights from daily-use accounts and manage elevation centrally.
• Review User Rights Assignment on servers and restrict SeDebugPrivilege, SeImpersonatePrivilege, SeBackupPrivilege, SeRestorePrivilege and SeLoadDriverPrivilege to documented accounts.
• Inventory every service's logon account; move multi-host services to gMSAs and local ones to virtual accounts.
• Enable LSA protection in audit mode, review CodeIntegrity events 3065 and 3066, then enforce in rings; confirm with WinInit event 12.
• Confirm Credential Guard is running on eligible clients and member servers and record the exceptions.
• Deploy Windows LAPS so no two devices share a local administrator password.
• Enable process creation auditing with command line, Audit Special Logon, Security System Extension and Other Object Access Events, plus PowerShell Script Block Logging.
• Deploy Sysmon or equivalent EDR telemetry with rules for lsass.exe access and autorun key changes, and alert on hosts that stop reporting.
• Baseline Run keys, Winlogon values, Image File Execution Options, services and scheduled tasks on gold images.

Standards and references

• Microsoft Learn: Access Tokens
• Microsoft Learn: Mandatory Integrity Control
• Microsoft Learn: Configure added LSA protection
• Microsoft Learn: Credential Guard overview
• Microsoft Learn: Understand service accounts
• Microsoft Learn: 4672 Special privileges assigned to new logon
• Microsoft Learn: Antimalware Scan Interface (AMSI)
• MITRE ATT&CK: OS Credential Dumping: LSASS Memory

Related NHI Mgmt Group resources: Windows Endpoint Hardening Guide · Windows Event Log Guide · Credential Dumping Guide · gMSA Guide · Linux Fundamentals for Defenders Guide