Windows Security Fundamentals

This lesson covers

Active Directory and why attackers love it → Group Policy as a security enforcement tool → Windows privilege model and UAC → The Windows Event Log — what to watch → Defender and the built-in security stack → PowerShell for security auditing

Windows runs the majority of corporate endpoints and most enterprise infrastructure. Active Directory alone manages authentication for hundreds of millions of user accounts worldwide. This makes Windows the primary target in most enterprise attacks — not because it's less secure than alternatives, but because it's where the valuable accounts, data, and business systems live. Understanding the Windows security model means understanding the battlefield most defenders actually work on.

Active Directory — the crown jewels

Active Directory (AD) is Microsoft's directory service — the centralised system that manages users, computers, groups, and policies across an entire organisation. When an employee logs into their workstation, accesses a file share, or authenticates to an internal application, AD is the authority that says yes or no. Compromise AD, and you effectively compromise the entire domain.

The most privileged account in an AD environment is the Domain Admin. A Domain Admin can log into any machine on the domain, read any file, reset any password, and create new accounts with any level of privilege. This is why Domain Admin credentials are the ultimate prize in most enterprise attacks — and why the first thing a mature attacker does after getting a foothold is start looking for a path to DA.

AD's structure organises objects into Organisational Units (OUs) — containers that group users, computers, and groups logically. Group Policies attach to OUs and apply settings to everything inside them. A single policy change at the domain level propagates to every machine in the domain within minutes. This centralised control is AD's greatest strength for administrators — and its greatest risk if an attacker reaches it.

Kerberoasting — attacking AD from the inside

Any authenticated domain user can request a Kerberos service ticket for any service account in AD. Those tickets are encrypted with the service account's password hash. An attacker with any valid domain account can request thousands of these tickets, take them offline, and crack them with a password cracker — no special privileges required. Service accounts with weak passwords and high privileges are the target. This attack requires zero elevation and works against every unpatched, misconfigured AD environment running today.

Group Policy — security enforcement at scale

Group Policy Objects (GPOs) are the primary mechanism for enforcing security settings across a Windows domain. A single GPO can configure password complexity requirements, lock screen timeouts, USB drive restrictions, software installation permissions, firewall rules, and hundreds of other settings — simultaneously, on every machine in the OU it applies to.

# PowerShell — audit Group Policy and security settings

# Show all GPOs applied to the current machine
gpresult /r

# Get detailed GPO report as HTML
gpresult /h C:\gpo-report.html

# List all GPOs in the domain (requires RSAT tools)
Get-GPO -All | Select-Object DisplayName, GpoStatus, CreationTime

# Check password policy currently enforced on the domain
Get-ADDefaultDomainPasswordPolicy

# Find accounts that have never had a password set (risky)
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires |
  Select-Object Name, SamAccountName

What just happened

gpresult /r shows every policy applied to the current machine and user — the starting point for understanding what's actually enforced versus what the policy document says should be enforced. The final command is a common audit finding: accounts with passwords that never expire are often forgotten service accounts or old admin accounts — exactly the kind of stale credential an attacker targets in a Kerberoasting or password spray attack.

The Windows privilege model

Windows uses a token-based privilege model. Every process runs with an access token that encodes the user's identity, group memberships, and privileges. When a process tries to access a resource, Windows compares the token against the resource's Access Control List (ACL) — a list of who is allowed to do what.

User Account Control (UAC) is the gate between standard and elevated tokens. When a standard user (or even a local admin) runs an application that requests elevation, UAC prompts for consent or credentials. The application runs in a restricted token by default — a separate elevated token is only created when explicitly approved. This is why even local administrators aren't running in a fully privileged context at all times.

Attackers target token manipulation as a lateral movement and privilege escalation technique. Pass-the-Hash and Pass-the-Ticket attacks steal authentication tokens or hashes from memory and reuse them to authenticate as another user without knowing their password. Tools like Mimikatz specifically extract these credentials from the LSASS process — Windows' credential store in memory.

# PowerShell — privilege and account auditing

# Check current user's privileges and group memberships
whoami /all

# List local administrators on the machine
Get-LocalGroupMember -Group "Administrators"

# Find domain accounts with admin rights on this machine
Get-LocalGroupMember -Group "Administrators" |
  Where-Object {$_.ObjectClass -eq "User"}

# Check if LSASS is running in protected mode (Credential Guard)
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" |
  Select-Object RunAsPPL, LsaCfgFlags

# List running processes with their owner
Get-Process | Select-Object Name, Id,
  @{N="Owner";E={(Get-Process -Id $_.Id -IncludeUserName).UserName}} |
  Sort-Object Owner

What just happened

whoami /all dumps the full token — privileges, group memberships, and SID — and is one of the first commands any attacker or pen tester runs after getting a shell. The LSASS registry check confirms whether Credential Guard is active: RunAsPPL = 1 means LSASS runs as a Protected Process Light, which blocks tools like Mimikatz from reading credentials out of its memory. If it returns 0 or nothing, credential dumping is significantly easier.

The Windows Event Log — the security record

The Windows Event Log is the primary source of security telemetry on Windows systems. Three channels matter most for security: Security (authentication, privilege use, object access), System (service starts/stops, driver issues, system events), and Application (application-level events). Every login, every privilege escalation, every failed authentication attempt leaves a trace here — if auditing is enabled and log retention is set high enough.

# PowerShell — Event Log triage for security events

# Failed logon attempts (Event ID 4625) — last 50
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} |
  Select-Object -First 50 TimeCreated, Message

# Successful logons (Event ID 4624) — look for unusual times/accounts
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Select-Object -First 20 TimeCreated, Message

# Account created (Event ID 4720) — persistence technique
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720} |
  Select-Object TimeCreated, Message

# Privilege escalation — special privileges assigned (Event ID 4672)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4672} |
  Select-Object -First 20 TimeCreated, Message

# PowerShell script block logging (Event ID 4104) — attacker commands
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=4104} |
  Select-Object -First 20 TimeCreated, Message

What just happened

These five Event IDs cover the fingerprints of the most common attack phases. 4625 is the brute-force detector. 4624 reveals lateral movement — an account logging in from a machine it has never used. 4720 is the persistence alert — new accounts created outside provisioning windows. 4672 fires every time a session is assigned sensitive privileges — Domain Admin logins appear here. 4104 is the most valuable for detecting PowerShell-based attacks: script block logging captures the actual commands run, even if they were obfuscated at execution time.

Windows Defender and the built-in security stack

Modern Windows ships with a security stack that is significantly more capable than its reputation suggests. Windows Defender Antivirus, Defender for Endpoint, Windows Firewall, BitLocker, Credential Guard, and Attack Surface Reduction rules collectively cover most of the attack surface that third-party tools were once required for.

# PowerShell — check and configure the Windows security stack

# Defender status — real-time protection, definitions date
Get-MpComputerStatus | Select-Object AMRunningMode,
  RealTimeProtectionEnabled, AntivirusSignatureLastUpdated,
  BehaviorMonitorEnabled, IoavProtectionEnabled

# Check Attack Surface Reduction rules and their current state
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions
# 0=Disabled, 1=Block, 2=Audit

# Windows Firewall — check all profiles are active
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction

# BitLocker status on all drives
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, ProtectionStatus

# Check if Credential Guard is running
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object SecurityServicesRunning

What just happened

This block audits the entire built-in security stack in one pass. ASR rules block specific attacker techniques at the OS level — rules like "Block Office applications from creating child processes" and "Block credential stealing from LSASS" directly counter the most common malware behaviours. Action value 2 (Audit) means the rule is logging but not blocking — a common state in environments where IT enabled the rules cautiously. Switching those to 1 (Block) hardens the system significantly without requiring any third-party tooling.

Instructor's Note

Windows security has a reputation problem. Years of default configurations that prioritised compatibility over security left the impression that Windows is inherently insecure. Modern Windows with hardened AD, enabled Credential Guard, ASR rules in block mode, and script block logging is a genuinely difficult environment to attack. The problem isn't the platform — it's that most organisations never turn the controls on. The PowerShell commands in this lesson run in under two minutes and tell you exactly which ones are off.

Practice Questions

An attack that allows any authenticated domain user to request service tickets encrypted with service account password hashes, then crack them offline — requiring no elevated privileges to execute. What is this attack called?

The Windows Security Event Log ID that records failed logon attempts — the primary event ID for detecting brute-force attacks against Windows accounts.

The registry value that, when set to 1, configures LSASS to run as a Protected Process Light — blocking credential dumping tools like Mimikatz from reading credentials out of memory.

Quiz

Up Next · Lesson 14

Network Security Basics

Packets, protocols, and the points where traffic can be inspected, filtered, or intercepted — the fundamentals every security professional needs to read a network.

← Previous Course Index Next →