Windows Security and Active Directory

Over 90% of Fortune 500 companies run Microsoft Active Directory. It's the central nervous system of Windows enterprise environments — managing authentication, authorisation, group membership, and Group Policy configuration for every device and user in the domain. It's also the primary target once an attacker gets a foothold, because Domain Admin access to AD means access to everything.

This module covers the Windows and AD security model: how AD stores and protects credentials, what Group Policy Objects (GPOs) can enforce, how tiered administration limits the blast radius of compromise, the top AD misconfigurations attackers look for (and you should fix), and how BloodHound reveals attack paths through trust relationships that administrators didn't know existed.

Active Directory — The Core Concepts

Active Directory is a hierarchical directory service built on LDAP (Lightweight Directory Access Protocol). It stores objects — users, computers, groups, GPOs, and service accounts — in a tree structure of domains and organizational units (OUs).

AD structure:

Forest: CORP.LOCAL             ← Root of the trust hierarchy
  Domain: CORP.LOCAL           ← Primary domain
    OU: Workstations           ← Organizational Unit
      Computer: DESKTOP-01
      Computer: LAPTOP-42
    OU: Servers
      OU: Production
        Computer: WEB-01
        Computer: DB-01
      OU: Development
        Computer: DEV-01
    OU: Users
      OU: Executives
        User: ceo@corp.local
      OU: IT
        User: admin@corp.local
      OU: Staff
        User: jsmith@corp.local
    OU: Service Accounts
      User: svc_backup
      User: svc_monitoring
    OU: Groups
      Group: Domain Admins
      Group: Enterprise Admins
      Group: IT-Helpdesk

Domain Controller (DC): Runs AD services
  - Authentication (Kerberos KDC, NTLM)
  - LDAP directory (AD database in NTDS.dit)
  - DNS (AD-integrated DNS)
  - Sysvol share (GPOs stored here)
  - Global Catalog (cross-domain object search)

Key privileged groups:
  Domain Admins:      Full control of domain
  Enterprise Admins:  Full control of entire forest (all domains)
  Schema Admins:      Can modify AD schema (rarely needed)
  Administrators:     Local admin on Domain Controllers
  KRBTGT:             Fake service account — its hash enables Golden Tickets

How credentials are stored in AD:

NTDS.dit file:
  Location: C:WindowsNTDSNTDS.dit (on Domain Controllers only)
  Format: Extensible Storage Engine (ESE) database
  Contains: All domain user attributes including:
    - NT hash (MD4 of password)
    - LM hash (legacy, disabled by default)
    - Kerberos keys (DES, RC4, AES-128, AES-256)
    - Password history
    - Account flags (disabled, locked, etc.)

Encryption:
  NT hashes in NTDS.dit are encrypted with:
    1. Domain-wide encryption key
    2. Per-account salt derived from account's SID
  This prevents extracting raw hashes directly from the file

DCSync attack bypasses this:
  MS-DRSR protocol allows one DC to sync hashes from another DC
  An account with Replicating Directory Changes + All can perform DCSync
  secretsdump.py decrypts hashes client-side using the Domain encryption key
  Result: all plaintext-equivalent NT hashes for all domain accounts

Group Policy — Enforcing Security Across the Domain

Group Policy Objects (GPOs) are the primary mechanism for enforcing security configuration across thousands of Windows machines. A GPO is a collection of settings that applies to users and computers in an OU when they log in or at regular refresh intervals (every 90 minutes by default). Security hardening via GPO is far more scalable and reliable than manual configuration.

GPO processing order (LSDOU — later overwrites earlier):
  1. Local Policy        (Local Group Policy on each machine)
  2. Site Policy         (Applied to AD sites)
  3. Domain Policy       (Applies to entire domain)
  4. OU Policy           (Applies to specific OU, most specific wins)

Last writer wins — OU GPOs override Domain GPOs which override Local.

Critical security GPOs to configure:

Account Policy (Domain level only):
  Password Length: 14+ characters
  Password Complexity: Enabled
  Password History: 24 passwords remembered
  Maximum Password Age: 90 days
  Account Lockout Threshold: 5 attempts
  Account Lockout Duration: 15 minutes
  Reset Lockout Counter After: 15 minutes

Security Options:
  Interactive logon: Display user information when session locked → Do not display
  Interactive logon: Machine inactivity limit → 900 seconds
  Network security: LAN Manager authentication level → Send NTLMv2 only
                    ← Disables LM and NTLMv1 (old, crackable)
  Network access: Do not allow anonymous enumeration of SAM accounts → Enabled
  Network access: Do not allow anonymous enumeration of SAM accounts and shares → Enabled
  User Account Control: Run all administrators in Admin Approval Mode → Enabled

Windows Firewall via GPO:
  Configure Windows Defender Firewall with domain, private, public profiles
  Block all inbound connections by default
  Allow only specific ports needed (e.g., 445 for SMB between file server and clients)

Windows Update:
  Configure WSUS or Windows Update for Business
  Automatic installation: Critical and Security updates
  Deadline: 3 days for Critical patches

PowerShell logging — catch attacker activity:

# GPO → Computer Configuration → Administrative Templates
#      → Windows Components → Windows PowerShell

Module Logging:
  Enable: Log all PowerShell module activity
  This captures: PowerShell commands executed, their output
  Logs to: Event ID 4103

Script Block Logging:
  Enable: Log all PowerShell script blocks (including obfuscated scripts)
  Key: Windows decodes the script before logging — obfuscation is irrelevant
  Attacker runs: powershell -enc <base64>
  Log captures: decoded script content
  Logs to: Event ID 4104

Transcription:
  Save all PowerShell session output to a text file
  Configure path: \serverpslogs%computername%_%date%.txt
  Logs to: Configured path

Command Line Logging:
  Enable: Include command line in process creation events
  GPO path: Audit Policy → Object Access → Audit Process Creation
  Logs command lines to: Security Event Log, Event ID 4688

# These four settings together make PowerShell-based attacks
# nearly fully visible in SIEM logs

Active Directory Tiered Administration Model

The Active Directory Tiered Administration Model (also called the Administrative Tier Model) is Microsoft's recommendation for isolating privileged credentials from credential theft attacks. The core insight: credentials used on Tier 2 (workstations) should never touch Tier 0 (Domain Controllers). If a workstation is compromised, the attacker shouldn't be able to harvest credentials that give them access to higher-tier systems.

Three-tier model:

Tier 0: Domain Controllers, AD, PKI, ADFS
  Highest value, highest risk
  Controls: Only Tier 0 admins can administer Tier 0 systems
  Tier 0 admins: Separate accounts (DA-jsmith) used ONLY on Tier 0 systems
  Tier 0 admin workstations: Dedicated, hardened, internet-restricted PAWs

Tier 1: Servers (web, app, file, database)
  Medium value
  Controls: Tier 1 admins (SA-jsmith) can administer servers
            Tier 1 admin accounts CANNOT log into Tier 0 or Tier 2
  Tier 1 admin workstation: Dedicated PAW for server management

Tier 2: Workstations and devices
  Lowest tier, most exposed (users browse web, open email)
  Controls: Helpdesk accounts (HD-jsmith) can administer workstations
            Helpdesk accounts CANNOT log into Tier 0 or Tier 1

PAW (Privileged Access Workstation):
  Dedicated, locked-down workstation for admin tasks only
  No email, no web browsing, no user apps
  No local admin for the PAW user (admin tasks via credential prompts)
  Outbound internet blocked (admin tools only)
  USB restricted, full disk encryption, Credential Guard enabled

Enforcement via Group Policy:
  Deny logon rights: DA-jsmith cannot log into workstations
    User Rights Assignment → Deny logon locally → Domain Admins
    User Rights Assignment → Deny logon via RDP → Domain Admins
  Logon restrictions: Only Tier 0 admins can log into DCs

Real-world impact:
  Before tiering: IT helpdesk logs into workstations as Domain Admin
                  Workstation compromised → Domain Admin hash extracted
                  → Full domain compromise

  After tiering:  IT helpdesk uses HD-jsmith on workstations
                  Workstation compromised → HD-jsmith hash extracted
                  HD-jsmith has no access to servers or DCs
                  → Lateral movement blocked at workstation tier

Top Active Directory Misconfigurations

AD misconfigurations are the attack surface that red teams and attackers target after initial access. These aren't theoretical vulnerabilities — they're found in virtually every enterprise environment because they accumulated over years of "quick fixes" and "temporary" exceptions.

# PowerShell commands to audit AD misconfigurations

# 1. Find service accounts with Domain Admin membership:
Get-ADGroupMember -Identity "Domain Admins" | Where-Object {
    (Get-ADUser $_.SamAccountName -Properties ServicePrincipalName).ServicePrincipalName -ne $null
}

# 2. Find accounts with unconstrained delegation:
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
    Select-Object Name, TrustedForDelegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
    Select-Object Name, TrustedForDelegation

# 3. Find accounts with "Do not require Kerberos pre-authentication" (AS-REP roasting):
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth |
    Select-Object Name, DoesNotRequirePreAuth

# 4. Find accounts that haven't changed passwords in 180+ days:
$cutoff = (Get-Date).AddDays(-180)
Get-ADUser -Filter {PasswordLastSet -lt $cutoff -and Enabled -eq $true} -Properties PasswordLastSet |
    Select-Object Name, PasswordLastSet

# 5. Find stale computer accounts (not logged in 90+ days):
$cutoff = (Get-Date).AddDays(-90)
Get-ADComputer -Filter {LastLogonTimeStamp -lt $cutoff -and Enabled -eq $true} -Properties LastLogonTimeStamp |
    Select-Object Name, @{N='LastLogon';E={[DateTime]::FromFileTime($_.LastLogonTimeStamp)}}

BloodHound — Mapping Attack Paths Through AD

BloodHound is an open-source tool that collects Active Directory relationship data (group memberships, session data, ACLs, trust paths) and visualises attack paths from any user to Domain Admin. It's used by both red teams (finding paths to exploit) and blue teams (identifying and closing those paths before attackers find them).

BloodHound architecture:

Data collection (SharpHound):
  SharpHound.exe or SharpHound.ps1 runs in the domain context
  Collects via LDAP and Windows APIs:
    - Group memberships (who is in what group)
    - Active sessions (who is logged into which computer)
    - ACLs (who has what rights over which AD objects)
    - SPNs (service accounts for Kerberoasting)
    - Delegation settings

Analysis (BloodHound GUI):
  Neo4j graph database backend
  Visualises trust relationships as a directed graph
  Pre-built queries for common attack paths

Critical BloodHound queries:
  "Find all Domain Admins"
  "Find shortest path to Domain Admin from [username]"
  "Find all paths from [compromised host] to Domain Admin"
  "Find computers where Domain Admins have sessions"
  "Find users with Kerberoastable accounts"
  "Find AS-REP roastable users"
  "Find principals with DCSync rights"
  "Find unconstrained delegation computers"
  "Find dangerous ACLs" (WriteDACL, GenericAll, WriteOwner on privileged groups)

Defender use case:
  Run BloodHound quarterly as an AD security assessment
  Sort findings by impact: paths to Domain Admin are highest priority
  Close paths by:
    - Removing unnecessary group memberships
    - Fixing over-permissive ACLs
    - Disabling delegation on workstations
    - Tiering admin accounts

Common BloodHound attack paths explained:

Path: jsmith (low-priv user)
  → MemberOf → IT-Helpdesk (group)
  → HasSession → DESKTOP-42 (computer)
  → AdminTo → IT-ADMIN-01 (admin computer)
  → HasSession → DA-admin (Domain Admin has active session)
  → Domain Admin compromise

Reading this:
  jsmith is in IT-Helpdesk group
  IT-Helpdesk has local admin on DESKTOP-42
  DESKTOP-42 → IT-ADMIN-01 (DA has session, somehow)
  Compromise DESKTOP-42 → wait for/steal DA's session → DA hash

GenericAll edge:
  IT-Support-Group has GenericAll rights on Domain Admins group
  jsmith is in IT-Support-Group
  Attack: jsmith can add any user to Domain Admins
  → Add jsmith to Domain Admins
  → Instant Domain Admin without compromising any admin account

WriteDACL edge:
  jsmith has WriteDACL on Domain Admins
  jsmith can modify the ACL of Domain Admins group
  → Grant jsmith GenericAll on Domain Admins
  → Add jsmith to Domain Admins

These ACL-based attacks:
  - Leave no obvious traces (no failed logins)
  - Don't require credential theft
  - Often missed by traditional monitoring
  - Detected by BloodHound analysis

Windows Defender and Modern Windows Security Controls

Modern Windows (10/11 Enterprise) ships with a substantial set of built-in security controls that significantly raise the bar for attackers. Many are disabled by default or require specific hardware. Understanding what these controls do and how to enable them is core Windows security knowledge.

Windows security controls overview:

Windows Defender Antivirus:
  Real-time protection (signature + cloud-delivered signatures)
  Controlled Folder Access: Prevents ransomware from modifying Documents, Pictures, Desktop
  Network Protection: Blocks connections to known-malicious domains/IPs
  Tamper Protection: Prevents malware from disabling Defender settings

Microsoft Defender for Endpoint (MDE):
  Enterprise EDR: Behavioural detection, threat hunting, automated investigation
  Attack Surface Reduction (ASR) rules:
    Block Office macros calling Win32 APIs
    Block executable content from email client
    Block credential stealing from LSASS process
    Block process injections from Office apps
    Block execution of potentially obfuscated scripts
  Enable via: Intune, SCCM, or GPO

Credential Guard:
  Uses Hyper-V isolated VM (VSM) to store LSASS credentials
  NT hashes no longer in accessible LSASS memory
  Mimikatz sekurlsa::logonpasswords returns (null)
  Requires: UEFI, Secure Boot, 64-bit processor with virtualisation

Secure Boot:
  UEFI firmware validates bootloader signature before executing
  Prevents bootkits and UEFI-level rootkits from persisting
  Requires: UEFI firmware + Secure Boot key enrollment

BitLocker:
  Full disk encryption (AES-256 or AES-128 with XTS mode)
  TPM binding: key released only when boot measurements match
  Protects against offline attacks (stolen laptop, cold boot)
  Network Unlock: Servers can auto-unlock in data centres

Windows Firewall:
  Host-based stateful firewall
  Separate profiles: Domain, Private, Public
  Deploy rules via GPO across domain machines

AppLocker / WDAC (Windows Defender Application Control):
  Application allowlisting — only approved software can execute
  WDAC: Policy enforced by kernel (harder to bypass than AppLocker)
  Blocks: Unsigned executables, scripts, DLLs not in allowlist
  Highly effective against malware — most malware isn't allowlisted

Enabling key security controls via PowerShell / GPO:

# Enable Credential Guard (requires UEFI + Secure Boot):
# GPO: Computer Configuration → Administrative Templates
#      → System → Device Guard → Turn on Virtualization Based Security
# Or via PowerShell (Windows 10 2004+):
Set-VMSecurity -VMName "..." -VirtualizationBasedSecurityOptOut $false

# Enable ASR rules (requires Defender for Endpoint):
Set-MpPreference -AttackSurfaceReductionRules_Ids @(
    "75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84"  # Block Office from creating child processes
    "D4F940AB-401B-4EFC-AADC-AD5F3C50688A"  # Block Office from creating executable content
    "3B576869-A4EC-4529-8536-B80A7769E899"  # Block Office from injecting into other processes
    "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550"  # Block executable content from email
    "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B0"  # Block credential stealing from LSASS
    "D3E037E1-3EB8-44C8-A917-57927947596D"  # Block JavaScript and VBScript from launching processes
) -AttackSurfaceReductionRules_Actions @(
    "Enabled", "Enabled", "Enabled", "Enabled", "Enabled", "Enabled"
)

# Enable Windows Defender Tamper Protection (prevent disabling Defender):
Set-MpPreference -TamperProtection 5  # On (requires SYSTEM or Intune to change)

# Enable Controlled Folder Access (anti-ransomware):
Set-MpPreference -EnableControlledFolderAccess Enabled

Windows Event Logging for Security

Windows Event Logs are the primary data source for detecting attacks in Windows environments. The Security event log records authentication, privilege use, and object access. But default logging is insufficient — many critical events require explicit configuration.

Critical Security Event IDs for detection:

Authentication:
  4624 - Successful logon (with Logon Type: 3=network, 10=remote interactive)
  4625 - Failed logon (brute force detection)
  4648 - Logon using explicit credentials (runas, PtH patterns)
  4768 - Kerberos TGT request (authentication)
  4769 - Kerberos service ticket request (Kerberoasting: many = suspicious)
  4771 - Kerberos pre-authentication failed (wrong password)

Privilege Use:
  4672 - Special privileges assigned (admin equivalent rights)
  4698 - Scheduled task created (persistence mechanism)
  4702 - Scheduled task updated
  4720 - User account created
  4728 - User added to security group (especially Domain Admins)
  4732 - User added to local group
  4756 - User added to universal group

Process:
  4688 - New process created (requires Process Tracking audit + command line logging)
  4689 - Process exited

Credential Access:
  4776 - NTLM authentication (domain or local)
  4104 - PowerShell script block logged (requires PowerShell logging GPO)
  4103 - PowerShell module logging

Object Access:
  4663 - Object access (file, registry) — requires SACL on object
  4670 - Object permissions changed

SIEM alerts to configure from these events:
  4625 (>5 in 5 min, same source) → brute force
  4769 (>20 in 5 min, same user) → Kerberoasting
  4720 or 4728 after hours → suspicious account creation
  4688 where ParentProcessName=winword.exe, NewProcessName=cmd.exe → macro exploit
  4688 CommandLine contains: mimikatz, sekurlsa, vssadmin delete shadows → immediate alert

Interview Questions

Error Library — Common Mistakes

In Module 18, you learn cloud security from first principles: the shared responsibility model and exactly where cloud provider responsibility ends and yours begins, how IAM works across AWS/Azure/GCP, the most dangerous cloud misconfigurations (public S3 buckets, over-permissive IAM roles, exposed metadata services), and how cloud-native security tools detect threats in cloud environments.