Windows Internals — Tokens, Services, Registry, ETW and Security Boundaries — DedSec Project

Purpose: Build a Windows internals model for defensive research, secure configuration review, reverse engineering, and incident investigation.

Learning objectives

• Understand processes, threads, access tokens, integrity levels, privileges, and security descriptors.
• Explain the Service Control Manager, Windows services, registry security, object namespaces, and IPC boundaries.
• Understand UAC as an elevation/consent boundary rather than a replacement for account separation.
• Recognize ETW and Windows logging as observability infrastructure.
• Review local privilege boundaries without attempting elevation exploits.

Windows object/security model

Windows represents many resources as kernel objects with handles and security descriptors. Files, registry keys, processes, threads, events, mutexes, sections, tokens, and named pipes have distinct object types and access masks.

A process does not simply “have access” to an object. It opens a handle requesting specific rights; the Security Reference Monitor evaluates the caller's token against the object's security descriptor and other policy.

Access tokens

An access token describes the security context of a process or thread. It can contain:

• user SID;
• group SIDs and attributes;
• privileges;
• integrity level;
• restrictions;
• session-related context;
• elevation information.

Threads can impersonate another security context for specific operations, which is critical in servers handling requests from different clients.

SIDs and groups

Windows security principals are identified by Security Identifiers (SIDs). Human-readable account names can change; the SID is the durable identity used by access-control structures. Nested groups create transitive authority and should be reviewed as a graph.

Privileges

Token privileges are capabilities for sensitive OS operations. They are distinct from ordinary object ACL rights. A process may carry a privilege disabled until enabled, and some privileges are extremely powerful.

Defensive review should inventory which service identities receive sensitive privileges and remove unnecessary assignments.

Integrity levels

Mandatory Integrity Control adds an integrity label that can restrict lower-integrity subjects from writing to higher-integrity objects even where discretionary ACLs might otherwise allow access. Browsers and sandboxed components may use low/app-container integrity mechanisms as part of containment.

Integrity is one layer, not a full security model.

UAC

User Account Control separates a standard/elevated token experience for administrative users and introduces explicit elevation prompts/consent. UAC helps reduce accidental administrative execution but should not be treated as equivalent to using a separate non-admin identity for routine activity.

Enterprise hardening still benefits from standard-user operation and dedicated privileged identities.

Services

Windows services are managed by the Service Control Manager. A service definition includes executable path, startup behavior, service account, dependencies, recovery settings, and permissions controlling who can reconfigure/start/stop it.

Service security review asks:

• who can modify the service configuration?
• who can write the executable or its directory?
• what identity does it run as?
• are command-line arguments/config files writable by lower privilege?
• are recovery actions safe?
• is the service unnecessarily privileged?

Do not “test” by replacing executables; ACL evidence is sufficient in a lab review.

Registry

The registry stores system/application configuration in hierarchical hives/keys with ACLs. Security-sensitive areas include service configuration, startup behavior, authentication/security policy, application settings, and COM-related metadata.

Treat writable configuration consumed by a privileged process as a potential authority edge. Verify expected ACLs with administrative read-only tools.

Named pipes and RPC

Windows services often communicate over named pipes, RPC/ALPC, COM, or sockets. A privileged server must authenticate/authorize its client before performing sensitive work. Named object ACLs also matter: an unexpected user-writable IPC endpoint can allow spoofing or data manipulation.

Model local IPC exactly like a network trust boundary.

Process creation and parentage

Windows process creation includes executable path, command line, environment, token, inherited handles, mitigation policies, and parent/process attributes. Security telemetry frequently uses process image, signer, command line, parent, user, integrity, and hash together.

Parent-child relationships are useful context but are not infallible proof of causality.

DLL loading

Applications load DLL dependencies according to Windows loader rules and application configuration. Secure deployments protect directories, avoid unsafe search-path assumptions, and use supported mitigations/signing. Review writable directories and dependency provenance rather than attempting library hijacking.

ETW

Event Tracing for Windows (ETW) is a high-performance event infrastructure used by Windows and applications. Providers emit events consumed by diagnostic/security tooling. Some security products use ETW-derived telemetry alongside Windows Event Log, Sysmon, Defender, and other sources.

Understanding the telemetry path helps defenders distinguish “no event generated” from “event generated but not collected.”

Windows Event Log

Audit policy determines which security events are emitted. Domain controllers, endpoints, PowerShell, Defender, and application logs each provide different visibility. Collection architecture should preserve timestamps, host/user identity, event source, and correlation fields.

Avoid memorizing event IDs without context; Windows versions and auditing configuration matter.

Safe local review lab

On a disposable Windows VM:

• inspect your own process token/group membership;
• inspect ACLs on a temporary file and registry key you create;
• create a harmless test service only if you are comfortable administering the VM, then inspect its configuration and permissions;
• review recent process/security events generated by your own activity.

Do not change protected system services or attempt privilege escalation.

Security-boundary checklist

• standard users cannot modify privileged executables/configuration;
• service identities use least privilege;
• sensitive token privileges minimized;
• privileged groups reviewed;
• IPC endpoints authenticate clients;
• elevated tasks are auditable;
• logs cover process/service/account changes;
• writable search/config paths are controlled;
• admin identities separated from daily use.

Guided study workflow

Before you begin

Complete Modules 32, 37, 44, 62, and 72.

Practice task

Create a table of ten Windows objects in your lab, the subject accessing each, requested rights, enforcement mechanism, and relevant telemetry.

Evidence to keep

Token/group output, synthetic file/registry ACLs, service configuration if created, and selected event-log evidence.

Common mistakes to avoid

• treating UAC as a full security boundary between malicious code and admin intent;
• assuming ACL and privilege are the same concept;
• modifying production/system services for a learning task;
• trusting parent process alone as definitive evidence;
• memorizing event IDs without audit-policy context.

Mastery check

Explain how a token and security descriptor produce an access decision and how a writable privileged service configuration becomes a security risk.

Continue with

Modules 72, 80, 81, and 85.