8.4 Connecting Windows Hosts to Sentinel

Connecting Windows Hosts to Sentinel

Introduction

Windows Security Events are the foundational host-level telemetry for on-premises and hybrid environments. Process creation, logon events, privilege escalation, account management, and object access — all recorded in the Windows Security Event Log and ingested into Sentinel through the Azure Monitor Agent (AMA) and Data Collection Rules (DCRs).

If your environment has Defender for Endpoint, you may already have endpoint telemetry through the DeviceProcessEvents and DeviceLogonEvents tables (via the Defender XDR connector). Windows Security Events provide a different and complementary data set — they include events that MDE does not capture (detailed Windows audit events, service installation, security policy changes) and serve as a second source for environments where MDE coverage is incomplete.

Azure Monitor Agent (AMA) deployment

AMA is the agent that collects data from Windows (and Linux) hosts and sends it to the workspace. It replaces the deprecated Log Analytics Agent (MMA).

Deployment methods:

Azure Policy (recommended for scale) — create a policy that auto-deploys AMA to all Azure VMs and Arc-connected servers. The policy ensures new servers get AMA automatically. Navigate to Azure portal → Policy → Assign policy → search “Configure Windows machines to run Azure Monitor Agent” → assign to the relevant scope (subscription or resource group).

Azure Arc (for on-premises servers) — install the Azure Arc agent on on-premises Windows servers. This registers them as Azure resources, enabling AMA deployment through the same Azure Policy mechanism used for Azure VMs.

Manual installation — for individual servers or pilot deployments. Download the AMA installer from the Azure portal or install via PowerShell:

1
2
3

// PowerShell — install AMA on a Windows server (run as administrator)
// Invoke-WebRequest -Uri "https://aka.ms/AMAWindows" -OutFile "AMAInstaller.msi"
// Start-Process msiexec.exe -Wait -ArgumentList '/i AMAInstaller.msi /quiet'

AMA system identity: AMA uses a system-assigned managed identity on each machine to authenticate to Azure. For Azure VMs, this identity is created automatically. For Arc-connected on-premises servers, the Arc agent creates the managed identity during registration.

Data Collection Rules for Windows Security Events

After deploying AMA, you must create a Data Collection Rule (DCR) that tells the agent what to collect. Without a DCR, AMA collects nothing — it waits for instructions.

Creating a DCR for Windows Security Events:

Navigate to Azure portal → Monitor → Data Collection Rules → Create.

Rule name: dcr-windows-security-events-prod Platform type: Windows Resources: select the VMs/servers to collect from Data source: Windows Event Logs → Security Destination: your Sentinel Log Analytics workspace

Collection levels: The DCR defines which security events to collect. Microsoft provides predefined sets:

All Events — every Windows Security Event. Comprehensive but very high volume (5-20 GB/day per busy server). Includes verbose audit success events (every file access, every token manipulation) that rarely contribute to security investigation. Use only when compliance requires complete audit records.

Common — the security-relevant subset. Includes: successful and failed logons (Event IDs 4624, 4625), account management (4720, 4722, 4726, 4728, 4732, 4756), privilege use (4672, 4673), process creation (4688), service installation (4697), and security policy changes (4719). Excludes: routine audit success events, token manipulation details, and verbose object access events. This is the recommended level for most environments — it provides the events needed for investigation while reducing volume by 50-70% compared to “All Events.”

Minimal — only the most critical events. Logon failures, account lockouts, security log cleared, audit policy changed. Suitable only for very low-cost deployments where any data is better than no data.

Custom XPath queries — for granular control, define custom XPath expressions that select exactly which Event IDs to collect. This is the most precise approach: collect the specific events your analytics rules need and nothing else.

1
2
3
4
5

// Custom XPath example: collect only specific Event IDs
// Security!*[System[(EventID=4624 or EventID=4625 or EventID=4648
//   or EventID=4672 or EventID=4688 or EventID=4720 or EventID=4726
//   or EventID=4728 or EventID=4732 or EventID=4756 or EventID=4697
//   or EventID=1102)]]

The SecurityEvent table

Windows Security Events land in the SecurityEvent table in the workspace.

Key columns: TimeGenerated, EventID (the Windows event ID — 4624 for logon, 4625 for failed logon, 4688 for process creation, etc.), Computer (hostname), Account (user who triggered the event), Activity (human-readable event description), LogonType (for logon events: 2=Interactive, 3=Network, 10=Remote, etc.), IpAddress, Process (for process creation events), CommandLine (if command-line auditing is enabled).

Critical Event IDs for security investigation

Not all Windows Event IDs are equally valuable. These are the events that SOC analysts query most frequently.

Authentication events:

Event ID 4624 (Successful logon) — every successful authentication. The LogonType field distinguishes interactive (2), network (3), service (5), remote desktop (10), and cached credentials (11). Lateral movement detection relies on finding LogonType 3 and 10 from unexpected source IPs.

Event ID 4625 (Failed logon) — every failed authentication attempt. Brute-force detection relies on counting these per source IP per time window. The SubStatus code reveals why the logon failed: 0xC0000064 (username does not exist), 0xC000006A (bad password), 0xC0000234 (account locked).

Event ID 4648 (Explicit credential logon) — a process authenticated using explicitly provided credentials (RunAs, net use with credentials). Attackers use this for lateral movement with stolen credentials.

Account management:

Event ID 4720 (User account created) — new local or domain account creation. Persistence indicator: attackers create backdoor accounts.

Event ID 4726 (User account deleted) — account deletion. May indicate evidence destruction.

Event ID 4728/4732/4756 (Member added to security group) — privilege escalation. Attackers add compromised accounts to administrative groups.

Process and service events:

Event ID 4688 (Process creation) — every process launch. The CommandLine field (when auditing is enabled) reveals exactly what was executed. This is the Windows equivalent of DeviceProcessEvents from MDE.

Event ID 4697 (Service installed) — new service installation. Persistence indicator: attackers install malicious services.

Event ID 1102 (Audit log cleared) — the Security Event Log was cleared. Almost always indicates an attacker covering their tracks. High-severity alert for any analytics rule.

Investigation queries using these Event IDs:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Detect lateral movement: network logons from unusual source IPs
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4624
| where LogonType == 3 or LogonType == 10
| where IpAddress != "" and IpAddress != "-" and IpAddress != "127.0.0.1"
| summarize UniqueComputers = dcount(Computer),
    Computers = make_set(Computer, 10)
    by Account, IpAddress
| where UniqueComputers > 3
| order by UniqueComputers desc

1
2
3
4
5

// Detect potential evidence destruction: security log cleared
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 1102
| project TimeGenerated, Computer, Account, Activity

Enabling advanced audit policies via GPO

The default Windows audit configuration misses critical events. For comprehensive security visibility, enable these advanced audit policies via Group Policy.

Critical: Enable command-line auditing. Without this, Event ID 4688 shows that powershell.exe was launched but not what it executed. Enable via GPO: Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events.

Enable PowerShell Script Block Logging. Records the full content of PowerShell scripts executed on the host. Essential for detecting encoded and obfuscated PowerShell attacks. Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Block Logging.

Enable Module Logging. Records PowerShell module usage. Enable via GPO alongside Script Block Logging for complete PowerShell visibility.

These three GPO settings transform Windows Security Events from “a process ran” to “a process ran this specific command with these specific parameters” — the difference between knowing something happened and knowing exactly what happened.

Sysmon integration for enhanced endpoint visibility

Windows Security Events provide authentication, process creation, and account management data. For deeper endpoint visibility — specifically network connections per process, DNS queries, file creation with hashes, registry modifications, and WMI events — deploy Sysmon (System Monitor) alongside AMA.

Sysmon is a free Microsoft Sysinternals tool that generates detailed event logs for security-relevant system activity. Sysmon events are written to a dedicated Windows Event Log (Microsoft-Windows-Sysmon/Operational) that AMA can collect via a DCR.

Key Sysmon event types for security operations:

Event ID 1 (Process creation) — similar to SecurityEvent 4688 but includes the process hash (SHA256), parent process hash, and the full command line without requiring the GPO setting. Event ID 3 (Network connection) — records every TCP/UDP connection with the process that initiated it. Essential for C2 detection at the process level. Event ID 7 (Image loaded) — DLL loading events. Detects DLL sideloading and injection. Event ID 11 (File created) — file creation with the target filename and the creating process. Detects malware drops and data staging. Event ID 13 (Registry value set) — registry modifications. Detects persistence mechanisms (Run keys, services, scheduled tasks). Event ID 22 (DNS query) — DNS queries with the querying process. Detects C2 domain lookups at the process level.

Sysmon configuration: Sysmon requires an XML configuration file that defines which events to collect and which to exclude. Use a community-maintained configuration (SwiftOnSecurity’s sysmon-config or olafhartong’s sysmon-modular) as a starting point and customise for your environment. Deploy Sysmon via GPO, SCCM, or Intune.

Sysmon + MDE overlap: If you have Defender for Endpoint, MDE already collects similar telemetry (DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents). Sysmon is most valuable for: servers not onboarded to MDE, environments without MDE licences, and supplementary visibility (Sysmon captures some events MDE does not, such as DNS queries per process via Event ID 22).

Windows Event Forwarding (WEF) for centralised collection

In large environments, deploying AMA to every Windows host may not be immediately practical. Windows Event Forwarding (WEF) provides an alternative: forward security events from source hosts to a central Windows Event Collector (WEC) server, then deploy AMA only on the WEC server.

Architecture: Source hosts → WEF subscription → WEC server → AMA on WEC → Sentinel workspace.

Advantages: Reduces AMA deployment scope (one agent on the WEC instead of one per host). Uses built-in Windows functionality (no third-party tools). Supports granular event selection via WEF subscriptions (similar to XPath queries).

Disadvantages: Adds an intermediate hop (increased latency). The WEC server is a single point of failure (deploy in HA pair). WEF subscriptions require GPO configuration on all source hosts.

When to use WEF: As a transitional step during AMA migration (forward events to WEC while gradually deploying AMA to individual hosts), or for hosts that cannot run AMA (embedded Windows systems, legacy Windows versions).

Critical: Enable command-line auditing. By default, Windows does not include the full command line in Event ID 4688 (process creation). Without command-line auditing, you see that powershell.exe was launched but not what it executed. Enable via GPO: Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events.

1
2
3
4
5
6
7
8

// Find suspicious process creation on Windows hosts
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4688
| where Process has_any ("powershell", "cmd", "wscript", "cscript",
    "mshta", "regsvr32", "rundll32", "certutil")
| project TimeGenerated, Computer, Account, Process, CommandLine
| order by TimeGenerated desc

Scaling AMA deployment with Azure Policy

For environments with hundreds of servers, manual AMA deployment is impractical. Azure Policy automates both deployment and DCR association.

Policy 1: Deploy AMA. Assign the built-in policy “Configure Windows machines to run Azure Monitor Agent” to your subscription. This auto-installs AMA on all Windows VMs (Azure) and Arc-connected servers (on-premises).

Policy 2: Associate DCR. Assign the built-in policy “Configure Windows machines to be associated with a Data Collection Rule” and specify your DCR. This ensures every server with AMA is configured to collect the security events defined in your DCR.

Policy 3: Remediation. For existing servers that pre-date the policy assignment, run a remediation task that applies the policy retroactively. New servers created after the policy assignment are covered automatically.

The combination of these three policies ensures: every Windows server has AMA deployed, every AMA instance is configured with the correct DCR, and new servers are automatically covered. No manual intervention per server.

Knowledge check