Kill Chain Phase 1 — Event Enablement Runbook

Purpose

This runbook is the complete implementation guide for Phase 1 of kill chain detection enablement at Cirius Group. Phase 1 goal: get all required Windows security events flowing reliably to the SecurityEvent table in cirius-logging-law-central so the Phase 2 detection agents have the data they need.

HIPAA §164.312(b) (Audit Controls) requires that audit activity be recorded and reviewed. The events in this runbook constitute the audit record for execution, persistence, credential use, lateral movement, and defense evasion.

This runbook supersedes the configuration notes in kill-chain-audit-policy.md, which covered only 4688 and PowerShell logging. This document covers all Phase 1 events end to end, with verification.

Scope and Delivery Method

Device Type	Delivery Method	Target
Home computers, non-domain-joined Windows 10/11	Intune Settings Catalog + OMA-URI	All enrolled devices
AD-joined servers (on-prem, Azure VMs)	Group Policy Object (GPO)	All server OUs
Domain controllers specifically	GPO (separate, higher-privilege GPO)	Domain Controllers OU

Data path:

Windows endpoint → Windows Event Log → AMA (Azure Monitor Agent) → DCR → LAW
cirius-logging-law-central (5d76d1f2, rg-logging-logs) → SecurityEvent table

Event Coverage Matrix

EventID	Source	Kill Chain Stage	Requires Audit Policy	Requires Registry/GPO Extra
4688	Security	Execution, Credential Dump	Process Creation → Success	ProcessCreationIncludeCmdLine
4698	Security	Persistence	Audit Other Object Access Events → Success	None
4702	Security	Persistence	Audit Other Object Access Events → Success	None
7045	System	Persistence	Audit Security System Extension → Success	None
4624	Security	Lateral Movement	Audit Logon → Success	None
4625	Security	Initial Access	Audit Logon → Failure	None
4648	Security	Lateral Movement	Audit Other Logon/Logoff Events → Success	None
1102	Security	Defense Evasion	Audit Security State Change → Success	None
5140	Security	Lateral Movement	Audit File Share → Success	None
4103	PowerShell/Operational	Execution	N/A	Module Logging registry
4104	PowerShell/Operational	Execution	N/A	Script Block Logging registry

Important distinction on 7045: EventID 7045 is in the System log, not the Security log. The AMA DCR for Windows must include the System log in addition to Security log. Confirm the DCR configuration covers both logs before deploying (see Part 3).

Important distinction on 4698/4702: These events are generated under the Object Access audit category but the specific subcategory is "Audit Other Object Access Events" (also listed as "Other Object Access Events"). This is not the same as the general Object Access policy. Enable the subcategory specifically.

Part 1 — Intune (Home Computers, Non-Domain-Joined Windows 10/11)

Prerequisites

Intune Administrator role (or Global Administrator)
Target device group created — all enrolled Windows 10/11 home computers
AMA is already deployed to these devices (confirm before deploying audit policy — audit policy without log forwarding is useless)

1.1 — Create the Settings Catalog Policy

Portal path:Intune admin center → Devices → Windows → Configuration → Create → New Policy

Platform: Windows 10 and later
Profile type: Settings Catalog
Name: CiriusKC-Phase1-AuditPolicy-HomeDevices
Description: Kill chain Phase 1 audit policy — all required SecurityEvent IDs

1.2 — Audit Subcategories via Settings Catalog

In the Settings Catalog editor, search for and configure each setting below. The Settings Catalog exposes audit subcategories under "Microsoft Defender → Security Center" and "Administrative Templates" paths. For audit subcategories, search the exact setting name in the catalog search bar.

Process Creation → EventID 4688

Setting Name	Category Path in Catalog	Value
Audit Process Creation	`Auditing → Advanced Audit Policy Configuration → Detailed Tracking`	Success

Search term: Audit Process Creation

The catalog path in Intune Settings Catalog: Device Configuration → Administrative Templates → Windows Components → ...

If "Audit Process Creation" does not appear in Settings Catalog, use the OMA-URI method in section 1.3 instead.

Logon Events → EventID 4624 and 4625

Setting Name	Value
Audit Logon	Success and Failure

Search term: Audit Logon Enables: 4624 (Success) and 4625 (Failure)

Explicit Credential Logon → EventID 4648

Setting Name	Value
Audit Other Logon/Logoff Events	Success

Search term: Audit Other Logon Enables: 4648

New Service Installed → EventID 7045

Setting Name	Value
Audit Security System Extension	Success

Search term: Audit Security System Extension Enables: 7045

Setting Name	Value
Audit File Share	Success

Search term: Audit File Share Enables: 5140

Note: "Audit Object Access" is the parent category. The specific subcategory needed is "Audit File Share" — not "Audit Detailed File Share" (which generates 5145 and is higher volume). Enable "Audit File Share" only.

Security Audit Log Cleared → EventID 1102

Setting Name	Value
Audit Security State Change	Success

Search term: Audit Security State Change Enables: 1102

Scheduled Task Created/Modified → EventID 4698 and 4702

Setting Name	Value
Audit Other Object Access Events	Success

Search term: Audit Other Object Access Events Enables: 4698, 4702, and other object access events.

1.3 — Settings Not in Settings Catalog: OMA-URI Policies

Some settings are not exposed in the Intune Settings Catalog and require OMA-URI custom profiles.

Portal path for OMA-URI:Intune admin center → Devices → Windows → Configuration → Create → New Policy

Platform: Windows 10 and later
Profile type: Templates → Custom
Name: CiriusKC-Phase1-RegistryKeys-HomeDevices

OMA-URI 1 — ProcessCreationIncludeCmdLine (required for 4688 CommandLine field)

Without this, EventID 4688 is generated but the CommandLine field is blank, making the event nearly useless for detection.

Field	Value
Name	ProcessCreationIncludeCmdLine
Description	Enables command line logging in EventID 4688
OMA-URI	`./Device/Vendor/MSFT/Policy/Config/MSSecurityGuide/EnableStructuredExceptionHandlingOverwriteProtection`

Wait — use the correct OMA-URI for this setting:

Field	Value
OMA-URI	`./Device/Vendor/MSFT/Policy/Config/ADMX_AuditSettings/IncludeCmdLine`
Data type	String
Value	`<enabled/>`

If the ADMX-backed OMA-URI is not recognized by the device (older ADMX catalog), fall back to the direct registry path via a PowerShell script (see 1.4).

Equivalent registry key (what this deploys):

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit
  Value: ProcessCreationIncludeCmdLine_Enabled
  Type:  DWORD
  Data:  1

OMA-URI 2 — PowerShell Module Logging (EventID 4103)

Field	Value
Name	PowerShell-ModuleLogging-Enable
OMA-URI	`./Device/Vendor/MSFT/Policy/Config/WindowsPowerShell/TurnOnModuleLogging`
Data type	String
Value	`<enabled/><data id="ModuleNames" value="*"/>`

This enables module logging for all modules (*). Generates EventID 4103.

Equivalent registry keys:

HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging
  Value: EnableModuleLogging
  Type:  DWORD
  Data:  1

HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames
  Value: *
  Type:  REG_SZ
  Data:  *

OMA-URI 3 — PowerShell Script Block Logging (EventID 4104)

Field	Value
Name	PowerShell-ScriptBlockLogging-Enable
OMA-URI	`./Device/Vendor/MSFT/Policy/Config/WindowsPowerShell/TurnOnPowerShellScriptBlockLogging`
Data type	String
Value	`<enabled/>`

Generates EventID 4104. This is the highest-value PowerShell log — it captures the deobfuscated script content, meaning even base64-encoded payloads are logged in cleartext after decoding.

Equivalent registry key:

HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
  Value: EnableScriptBlockLogging
  Type:  DWORD
  Data:  1

OMA-URI 4 — PowerShell Transcription (Recommended)

Transcription writes all PowerShell session input/output to text files on disk. Not required for LAW ingestion but valuable for forensics.

Field	Value
Name	PowerShell-Transcription-Enable
OMA-URI	`./Device/Vendor/MSFT/Policy/Config/WindowsPowerShell/TurnOnPowerShellTranscription`
Data type	String
Value	`<enabled/><data id="OutputDirectory" value="C:\PSTranscripts"/>`

Equivalent registry keys:

HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription
  Value: EnableTranscripting
  Type:  DWORD
  Data:  1

  Value: OutputDirectory
  Type:  REG_SZ
  Data:  C:\PSTranscripts

1.4 — PowerShell Script Deployment (Fallback / Verification)

If OMA-URI policies do not apply cleanly, use an Intune PowerShell script as fallback. This script sets all required registry keys directly and is idempotent.

Deploy via: Intune → Devices → Scripts and remediations → Platform scripts

Script name: CiriusKC-Phase1-RegistryDeploy
Run as: System
Run in 64-bit PowerShell host: Yes (required for registry paths)

powershell

# Kill Chain Phase 1 — Registry Key Deployment
# Idempotent. Run as SYSTEM in 64-bit host.
# Last updated: 2026-05

$ErrorActionPreference = 'Stop'

function Set-RegistryValue {
    param($Path, $Name, $Value, $Type = 'DWORD')
    if (-not (Test-Path $Path)) {
        New-Item -Path $Path -Force | Out-Null
    }
    Set-ItemProperty -Path $Path -Name $Name -Value $Value -Type $Type
}

# 1. Process Creation Command Line (4688 CommandLine field)
Set-RegistryValue `
    -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit' `
    -Name 'ProcessCreationIncludeCmdLine_Enabled' `
    -Value 1

# 2. PowerShell Module Logging (4103)
Set-RegistryValue `
    -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging' `
    -Name 'EnableModuleLogging' `
    -Value 1

$moduleNamesPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames'
if (-not (Test-Path $moduleNamesPath)) {
    New-Item -Path $moduleNamesPath -Force | Out-Null
}
Set-ItemProperty -Path $moduleNamesPath -Name '*' -Value '*' -Type String

# 3. PowerShell Script Block Logging (4104)
Set-RegistryValue `
    -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' `
    -Name 'EnableScriptBlockLogging' `
    -Value 1

# 4. PowerShell Transcription (optional but recommended)
Set-RegistryValue `
    -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription' `
    -Name 'EnableTranscripting' `
    -Value 1

Set-RegistryValue `
    -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription' `
    -Name 'OutputDirectory' `
    -Value 'C:\PSTranscripts' `
    -Type String

Write-Output 'Kill Chain Phase 1 registry keys applied successfully.'

1.5 — Assignment

Assign both the Settings Catalog policy and the OMA-URI custom profile to the same target device group.

Assignment path:Policy → Properties → Assignments → Add groups → select home device group → Save

Deployment typically reaches devices within 15–30 minutes. Devices must be online and Intune-reachable. Use the sync button on individual devices to force immediate pull.

1.6 — Verifying Intune Deployment

Check policy deployment status:Intune → Devices → Configuration → CiriusKC-Phase1-AuditPolicy-HomeDevices → Device and user check-in status

Each device shows: Succeeded / Failed / Pending / Not applicable

Check on device (run PowerShell as administrator on an enrolled device):

powershell

# Verify audit subcategory state
auditpol /get /category:* | Select-String -Pattern "Process Creation|Logon|Object Access|Security System|Security State"

# Verify CommandLine registry key
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit' -Name ProcessCreationIncludeCmdLine_Enabled -ErrorAction SilentlyContinue

# Verify PowerShell logging registry
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' -ErrorAction SilentlyContinue
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging' -ErrorAction SilentlyContinue

Expected auditpol output (partial):

Detailed Tracking
  Process Creation                        Success
Logon/Logoff
  Logon                                   Success and Failure
  Other Logon/Logoff Events               Success
Object Access
  File Share                              Success
  Other Object Access Events              Success
System
  Security State Change                   Success
  Security System Extension               Success

Part 2 — Group Policy (AD-Joined Servers)

Prerequisites

Domain Admin or delegated GPO editor rights
Group Policy Management Console (GPMC) on a management workstation or BIZADSAZP01 / CGIADSAZP01
Target OUs: all OUs containing production servers
Separate GPO for Domain Controllers (DC OU has unique GPO precedence requirements)

2.1 — GPO Structure

Create two separate GPOs to keep server and DC configuration distinct:

GPO Name	Linked To	Purpose
`Cirius-KillChain-Phase1-Servers`	All server OUs (except DC OU)	Production server audit policy
`Cirius-KillChain-Phase1-DomainControllers`	Domain Controllers OU	DC-specific audit policy (superset)

Link priority: If existing security baseline GPOs exist on these OUs, set kill chain GPO link order to a lower number (higher precedence) to ensure settings are not overridden by legacy policies.

2.2 — Audit Policy Configuration (All Server GPO)

GPO Path:Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies

Configure each subcategory as follows:

Detailed Tracking

Subcategory	Value	Enables EventID
Audit Process Creation	Success	4688

Navigation: Advanced Audit Policy Configuration → System Audit Policies → Detailed Tracking → Audit Process Creation

Check: Configure the following audit events
Check: Success
Leave Failure unchecked (4688 only fires on Success)

Logon/Logoff

Subcategory	Value	Enables EventID
Audit Logon	Success and Failure	4624, 4625
Audit Other Logon/Logoff Events	Success	4648

Navigation: ... → Logon/Logoff

Audit Logon: Check Configure → Success + Failure
Audit Other Logon/Logoff Events: Check Configure → Success only

Object Access

Subcategory	Value	Enables EventID
Audit File Share	Success	5140
Audit Other Object Access Events	Success	4698, 4702

Navigation: ... → Object Access

Audit File Share: Check Configure → Success only
Audit Other Object Access Events: Check Configure → Success only

Do not enable "Audit Detailed File Share" (EventID 5145) unless specifically required — it generates one event per file access and will be extremely high volume on file servers.

System

Subcategory	Value	Enables EventID
Audit Security State Change	Success	1102
Audit Security System Extension	Success	7045

Navigation: ... → System

Audit Security State Change: Check Configure → Success
Audit Security System Extension: Check Configure → Success

2.3 — Process Command Line in 4688 (GPO Administrative Template)

This is a separate GPO setting from the audit subcategory above. Both must be enabled for CommandLine-populated 4688 events.

GPO Path:Computer Configuration → Administrative Templates → System → Audit Process Creation

Setting: Include command line in process creation events Value: Enabled

If "Audit Process Creation" does not appear under Administrative Templates → System, the ADMX template may not be loaded in the Central Store. Fall back to registry:

Registry alternative (deployable via GPO Preferences → Registry):

Key:   HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit
Value: ProcessCreationIncludeCmdLine_Enabled
Type:  DWORD
Data:  1

GPO Preferences path for registry deployment: Computer Configuration → Preferences → Windows Settings → Registry → New → Registry Item

2.4 — PowerShell Logging via GPO

GPO Path:Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell

Module Logging (EventID 4103)

Setting: Turn on Module Logging Value: Enabled

When enabled, a sub-option appears: "Module Names." Set this to * to log all modules. If the UI does not expose the module names field, edit the GPO registry preference:

Key:   HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging
Value: EnableModuleLogging
Type:  DWORD
Data:  1

Key:   HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames
Value: *
Type:  REG_SZ
Data:  *

Script Block Logging (EventID 4104)

Setting: Turn on PowerShell Script Block Logging Value: Enabled

Sub-option: Log script block invocation start/stop events → Enabled

Registry equivalent:

Key:   HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
Value: EnableScriptBlockLogging
Type:  DWORD
Data:  1

Transcription (Recommended)

Setting: Turn on PowerShell Transcription Value: Enabled

Set output directory to: C:\PSTranscripts

2.5 — Domain Controllers: Additional Audit Policy

Domain Controllers handle Kerberos authentication and directory replication. They generate additional event types relevant to credential attacks and DCSync.

Apply the Cirius-KillChain-Phase1-DomainControllers GPO to the Domain Controllers OU with all settings from 2.2–2.4, plus these additional subcategories:

GPO Path:Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies

Account Logon (DC-specific)

Subcategory	Value	Enables EventID	Notes
Audit Kerberos Service Ticket Operations	Success and Failure	4769	Kerberos TGS requests — required for Kerberoasting detection
Audit Kerberos Authentication Service	Success and Failure	4768	TGT requests — required for AS-REP roasting and brute force
Audit Credential Validation	Success and Failure	4776	NTLM credential validation

Navigation: ... → Account Logon

Audit Kerberos Service Ticket Operations: Success + Failure
Audit Kerberos Authentication Service: Success + Failure
Audit Credential Validation: Success + Failure

Directory Service Access (DC-specific)

Subcategory	Value	Enables EventID	Notes
Audit Directory Service Access	Success	4662	Directory object access — DCSync detection requires this
Audit Directory Service Changes	Success	4720, 4728, 4732	Group/account modifications

Navigation: ... → DS Access

Audit Directory Service Access: Success
Audit Directory Service Changes: Success

Note on DCSync detection: DCSync (mimikatz dcsync) does not generate a single unique EventID. Detection requires correlating 4662 (DS access with replication rights)

source account that is not a DC machine account. This is handled in the Phase 2 credential dumping agent.

2.6 — GPO Application

Apply to servers:

powershell

# Run on a target server or push remotely
gpupdate /force

Apply to domain controllers:

powershell

# Run on each DC, or use a domain-wide gpupdate
Invoke-GPUpdate -Computer <DC-hostname> -Force

Verify GPO is applied on a server:

powershell

# Shows which GPOs applied to Computer policy
gpresult /r /scope computer

# Show specific audit subcategory state
auditpol /get /category:*

Expected output for Phase 1 coverage:

System audit policy
Category/Subcategory                      Setting
System
  Security State Change                   Success
  Security System Extension               Success
Logon/Logoff
  Logon                                   Success and Failure
  Other Logon/Logoff Events               Success
Object Access
  File Share                              Success
  Other Object Access Events              Success
Detailed Tracking
  Process Creation                        Success

For DCs, additionally expect:

Account Logon
  Kerberos Service Ticket Operations      Success and Failure
  Kerberos Authentication Service         Success and Failure
  Credential Validation                   Success and Failure
DS Access
  Directory Service Access                Success
  Directory Service Changes               Success

Verify CommandLine registry key on server:

powershell

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit' `
    -Name ProcessCreationIncludeCmdLine_Enabled -ErrorAction SilentlyContinue

Expected: ProcessCreationIncludeCmdLine_Enabled : 1

Verify PowerShell logging registry on server:

powershell

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging'

Expected: EnableScriptBlockLogging : 1 and EnableModuleLogging : 1

Force specific subcategory — emergency override (not preferred):

If GPO is slow to propagate and a specific server needs settings immediately:

powershell

# Enable process creation auditing directly (overrides pending until next GPO refresh)
auditpol /set /subcategory:"Process Creation" /success:enable

# Enable logon auditing
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Other Logon/Logoff Events" /success:enable

# Enable file share
auditpol /set /subcategory:"File Share" /success:enable

# Enable security system extension
auditpol /set /subcategory:"Security System Extension" /success:enable

# Enable security state change
auditpol /set /subcategory:"Security State Change" /success:enable

# Enable scheduled task auditing
auditpol /set /subcategory:"Other Object Access Events" /success:enable

Warning: auditpol /set directly can be overridden at next GPO refresh. Prefer GPO as the authoritative source. Use direct auditpol only for immediate verification or as a stopgap while GPO propagates.

2.7 — DCR Verification: System Log Inclusion

EventID 7045 lives in the System log, not the Security log. Confirm the DCR that forwards events to LAW includes the System log.

Check current DCR configuration:

In Azure portal: Monitor → Data Collection Rules → [DCR name targeting servers] → Data Sources → Windows Event Logs

Confirm the Data Source includes both:

Security (for 4624, 4625, 4648, 4688, 1102, 5140, 4698, 4702, 4776)
System (for 7045)

If System log is missing, add it via the Azure portal or Terraform. In the DCR, add:

json

{
  "name": "system-log",
  "streams": ["Microsoft-Event"],
  "eventLogs": [
    {
      "name": "System",
      "xPathQueries": ["System!*[System[(EventID=7045)]]"]
    }
  ]
}

Or, if using the Microsoft-SecurityEvent stream (preferred for structured columns), note that 7045 from the System log lands in the SecurityEvent table only when the workspace has Microsoft Sentinel enabled — which cirius-logging-law-central does (confirmed). Verify 7045 appears in SecurityEvent vs Event table with the KQL in Part 3.

Important gotcha from CLAUDE.md: The Microsoft-SecurityEvent DCR stream requires a Sentinel-enabled workspace. cirius-logging-law-central is Sentinel-enabled, so this is supported. Do not move the DCR to a non-Sentinel LAW or it will return 400 InvalidPayload.

Part 3 — Verification

3.1 — KQL Coverage Queries

Run all queries against workspace cirius-logging-law-central (ID: 5d76d1f2).

Allow 15–30 minutes after policy deployment before expecting events. AMA agent heartbeat is typically every 5 minutes; event forwarding lag is usually under 5 minutes for high-frequency events.

Overall Coverage Check

kql

// All Phase 1 EventIDs — which are flowing, which are silent
let phase1Events = dynamic([1102, 4103, 4104, 4624, 4625, 4648, 4688, 4698, 4702, 5140, 7045]);
SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID in (phase1Events)
| summarize EventCount = count() by EventID
| join kind=rightouter (
    datatable(EventID:int, EventName:string, KillChainStage:string)
    [
        4688, "Process Creation",             "Execution",
        4698, "Scheduled Task Created",       "Persistence",
        4702, "Scheduled Task Modified",      "Persistence",
        7045, "New Service Installed",        "Persistence",
        4624, "Logon Success",                "Lateral Movement",
        4625, "Logon Failure",                "Initial Access",
        4648, "Explicit Credential Logon",    "Lateral Movement",
        1102, "Audit Log Cleared",            "Defense Evasion",
        5140, "Network Share Accessed",       "Lateral Movement",
        4103, "PowerShell Module Logging",    "Execution",
        4104, "PowerShell Script Block",      "Execution"
    ]
) on EventID
| project EventID, EventName, KillChainStage, EventCount = coalesce(EventCount, 0)
| order by EventID asc

Expected: All EventIDs show EventCount > 0. EventIDs with count = 0 indicate a gap. Exceptions: 1102 (log cleared) may legitimately be 0 if no log clearing has occurred — verify with a test log clear; 4698/4702 may be 0 if no scheduled tasks were created during the window.

EventID 4688 — Process Creation with CommandLine

kql

// Confirm 4688 is flowing AND CommandLine is populated
SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4688
| summarize
    TotalEvents = count(),
    WithCommandLine = countif(isnotempty(CommandLine)),
    WithoutCommandLine = countif(isempty(CommandLine))
    by Computer
| extend CommandLinePct = round(100.0 * WithCommandLine / TotalEvents, 1)
| order by TotalEvents desc

Expected: WithoutCommandLine should be 0 or near 0. If CommandLinePct is 0%, the ProcessCreationIncludeCmdLine registry key is not applied on that device.

EventID 4688 — Device Coverage

kql

// Which devices are reporting 4688 vs silent
let reportingDevices =
    SecurityEvent
    | where TimeGenerated > ago(4h)
    | where EventID == 4688
    | summarize LastSeen = max(TimeGenerated) by Computer;
reportingDevices
| order by Computer asc

Cross-reference this list against the expected inventory. Devices not in this list have not generated any process creation events in 4 hours — either the audit policy is not applied or AMA is not forwarding.

EventID 4624/4625 — Logon Events

kql

SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID in (4624, 4625)
| summarize Count = count() by EventID, Computer
| order by Computer asc, EventID asc

Expected: 4624 should be consistently high on active machines. 4625 volume depends on authentication failures in the environment.

EventID 4648 — Explicit Credential Logon

kql

SecurityEvent
| where TimeGenerated > ago(4h)
| where EventID == 4648
| project TimeGenerated, Computer, Account, TargetUserName, TargetServerName, ProcessName
| order by TimeGenerated desc
| take 50

4648 volume is medium — fires when credentials are passed explicitly (RunAs, WMI remote, PsExec, etc.). If completely absent over 4 hours, audit policy for "Other Logon/Logoff Events" is not applied.

EventID 7045 — New Service (System Log)

kql

// 7045 may be in SecurityEvent or Event table depending on DCR configuration
// Check both:
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 7045
| project TimeGenerated, Computer, ServiceName, ServiceFileName = CommandLine
| order by TimeGenerated desc

// If 0 results above, check Event table (System log forwarded via Microsoft-Event stream):
Event
| where TimeGenerated > ago(24h)
| where EventID == 7045
| project TimeGenerated, Computer, RenderedDescription
| order by TimeGenerated desc

If 7045 appears in Event but not SecurityEvent, the DCR is using the Microsoft-Event stream for the System log instead of routing through Sentinel's SecurityEvent normalization. For structured column access (ServiceName field), 7045 needs to reach SecurityEvent. Update the DCR to include System log events through the Sentinel-enabled data collection path.

If 7045 shows 0 results in both tables: System log is not included in any DCR, or Audit Security System Extension is not enabled on those devices.

Generate a test 7045 event:

powershell

# Install and immediately remove a dummy service to trigger 7045
sc.exe create TestKillChainSvc binPath= "C:\Windows\System32\calc.exe"
sc.exe delete TestKillChainSvc

Wait 5 minutes then re-run the KQL.

EventID 4698/4702 — Scheduled Task Created/Modified

kql

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID in (4698, 4702)
| project TimeGenerated, Computer, EventID, Account, TaskName, TaskContent = CommandLine
| order by TimeGenerated desc

Generate a test 4698 event:

powershell

Register-ScheduledTask -TaskName "TestKillChainTask" `
    -Action (New-ScheduledTaskAction -Execute "calc.exe") `
    -Trigger (New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(5))
Unregister-ScheduledTask -TaskName "TestKillChainTask" -Confirm:$false

kql

SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 5140
| summarize Count = count() by Computer, ShareName, AccountName = SubjectUserName
| order by Count desc

5140 fires on every share access (UNC path open). On file servers this will be extremely high volume. If share access is not occurring during the test window, trigger it manually:

powershell

# Access a share on a server that has the audit policy applied
net use \\<servername>\<sharename> /user:<domain>\<user>

EventID 1102 — Audit Log Cleared

kql

// 1102 fires rarely — query 7 days
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 1102
| project TimeGenerated, Computer, Account = SubjectUserName, Activity

Generate a test 1102 event (use a non-production machine, this clears the Security log):

powershell

# WARNING: This clears the Security event log on the local machine. Test only.
wevtutil cl Security

Then query LAW within 5 minutes. If 1102 does not appear, Audit Security State Change is not enabled.

PowerShell 4103/4104 — Script Block and Module Logging

kql

SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID in (4103, 4104)
| summarize Count = count() by EventID, Computer
| order by Computer asc, EventID asc

Generate test events — run PowerShell on a target machine:

powershell

# This triggers 4103 (module logging) and 4104 (script block logging)
Invoke-Command -ScriptBlock { Write-Output "Kill chain Phase 1 test"; Get-Process }

Wait 2 minutes, rerun KQL. If 4103/4104 do not appear, the PowerShell logging registry keys are not applied.

Verify script block captures obfuscated content:

powershell

# Encoded command — 4104 should log the decoded content
$encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes("Write-Output 'test obfuscated'"))
powershell -EncodedCommand $encoded

In LAW, EventID 4104 should show the decoded content: Write-Output 'test obfuscated'

3.2 — Device Coverage Check

Identify devices that should be reporting but are silent.

kql

// Devices seen in Heartbeat (AMA alive) but absent from SecurityEvent in last 4h
let amaDevices = Heartbeat
    | where TimeGenerated > ago(1h)
    | where OSType == "Windows"
    | summarize by Computer;
let reportingDevices = SecurityEvent
    | where TimeGenerated > ago(4h)
    | where EventID == 4688
    | summarize by Computer;
amaDevices
| join kind=leftanti reportingDevices on Computer
| project Computer
| sort by Computer asc

This returns Windows devices where AMA is running (they are online and connected to LAW) but no 4688 events have been received. These devices have AMA working but audit policy is not applied. Investigate:

For Intune devices: check policy deployment status in Intune portal for that device
For GPO devices: run gpresult /r on the device and check for policy application errors or WMI filter exclusions

3.3 — Expected Volume (Sanity Check)

Use these ranges to confirm events are flowing at realistic rates. Significant deviation in either direction warrants investigation.

EventID	Expected Volume	Notes
4624	50–500/hour per active server	Higher on domain controllers, terminal servers
4625	1–50/hour per server	Spikes indicate brute force
4648	5–100/hour per server	Higher on servers with service accounts
4688	200–2000/hour per active server	Very high on servers with many processes
4698	0–10/day	Only fires when scheduled tasks are created
4702	0–20/day	Task modifications — may spike after patch cycle
7045	0–5/day	Only fires when new services install
1102	0–1/week	Near-zero in normal operation; any instance = alert
5140	10–500/hour on file servers	0 on servers with no share access
4103	50–500/hour per server	All PowerShell module loads
4104	20–200/hour per server	Script block level — lower than 4103

High-volume warning: 4688 at >5,000/hour per server is not unusual on busy application servers. Monitor LAW ingestion cost after rollout. If ingestion cost becomes a concern, scope 4688 via XPath to specific high-value processes at the DCR level rather than filtering at the collection policy level.

3.4 — Troubleshooting: Events in Event Viewer but Not in LAW

If a device shows the correct events in Windows Event Viewer (eventvwr.msc) but the events are not appearing in LAW, the problem is in the AMA → DCR pipeline, not the audit policy.

Diagnostic steps:

Step 1 — Confirm AMA is running:

powershell

Get-Service -Name AzureMonitorAgent
# Expected: Status = Running

Step 2 — Check AMA logs for errors:

Event Viewer → Applications and Services Logs → Microsoft → Azure Monitor Agent → Operations

Look for errors indicating DCR download failures, network connectivity issues, or workspace authentication errors.

Step 3 — Verify DCR association:

In Azure portal: Monitor → Data Collection Rules → [DCR name] → Resources

Confirm the server or VM is listed as an associated resource. If it is not listed, add the machine: Data Collection Rules → [DCR] → Resources → Add

Or via Azure CLI:

bash

az monitor data-collection-rule association create \
    --name "dcr-assoc-<servername>" \
    --rule-id "/subscriptions/<sub>/resourceGroups/rg-logging-logs/providers/Microsoft.Insights/dataCollectionRules/<dcr-name>" \
    --resource "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm-name>"

Step 4 — Verify DCR data source includes Security log:

Monitor → Data Collection Rules → [DCR] → Data Sources → Windows Event Logs

Confirm the XPath query includes Security log:

Security!*[System[(Level=1 or Level=2 or Level=3 or Level=4 or Level=0)]]

For scoped collection (preferred — reduces volume):

Security!*[System[(EventID=4624 or EventID=4625 or EventID=4648 or EventID=4688 or EventID=4698 or EventID=4702 or EventID=1102 or EventID=5140)]]
System!*[System[(EventID=7045)]]

Step 5 — Check workspace ID in DCR:

The DCR destination must point to workspace ID 5d76d1f2. Verify: Monitor → Data Collection Rules → [DCR] → Destinations

If the workspace listed is not cirius-logging-law-central, update the destination.

Step 6 — Force AMA resync:

powershell

# Restart AMA to force DCR re-download
Restart-Service -Name AzureMonitorAgent -Force

# On Azure VMs, you can also reset the extension via Azure CLI:
# az vm extension delete --vm-name <name> --resource-group <rg> --name AzureMonitorAgent
# az vm extension set --vm-name <name> --resource-group <rg> --name AzureMonitorAgent --publisher Microsoft.Azure.Monitor --version 1.0 --enable-auto-upgrade true

Wait 5 minutes after restart, then check LAW for new events.

Step 7 — Verify PowerShell events specifically:

PowerShell 4103/4104 events log to Microsoft-Windows-PowerShell/Operational, not the Security log. The DCR must explicitly include this log channel if using XPath-scoped collection:

Microsoft-Windows-PowerShell/Operational!*[System[(EventID=4103 or EventID=4104)]]

If the DCR only collects from Security!*, PowerShell events will never appear in LAW regardless of whether script block logging is enabled.

Compliance Mapping

Requirement	Control	Events	Status After Phase 1
HIPAA §164.312(b) — Audit Controls	Record user activity	4624, 4625, 4648, 4688	Covered
HIPAA §164.312(b) — Audit Controls	Record system events	7045, 4698, 1102	Covered
HIPAA §164.308(a)(5)(ii)(C) — Log-in Monitoring	Monitor access	4624, 4625	Covered
HIPAA §164.312(c)(1) — Integrity	Detect unauthorized modification	4698, 7045, 1102	Covered
HITRUST 09.ab — Monitoring System Use	Monitor privileged activity	4688 + CommandLine	Covered
SOC2 CC7.2 — Monitoring	Threat detection capability	All Phase 1 events	Covered

Kill Chain Audit Policy — earlier narrower doc, superseded by this runbook for new deployments
Kill Chain Incident Response
Alerting Runbook
Log Retention Verification

Document History

Date	Change	Author
2026-05-25	Initial — full Phase 1 coverage: all EventIDs, both deployment methods, verification KQL, volume estimates, DCR troubleshooting	Rory / Kobe

Kill Chain Phase 1 — Event Enablement Runbook ​

Purpose ​

Scope and Delivery Method ​

Event Coverage Matrix ​

Part 1 — Intune (Home Computers, Non-Domain-Joined Windows 10/11) ​

Prerequisites ​

1.1 — Create the Settings Catalog Policy ​

1.2 — Audit Subcategories via Settings Catalog ​

Process Creation → EventID 4688 ​

Logon Events → EventID 4624 and 4625 ​

Explicit Credential Logon → EventID 4648 ​

New Service Installed → EventID 7045 ​

Network Share Access → EventID 5140 ​

Security Audit Log Cleared → EventID 1102 ​

Scheduled Task Created/Modified → EventID 4698 and 4702 ​

1.3 — Settings Not in Settings Catalog: OMA-URI Policies ​

OMA-URI 1 — ProcessCreationIncludeCmdLine (required for 4688 CommandLine field) ​

OMA-URI 2 — PowerShell Module Logging (EventID 4103) ​

OMA-URI 3 — PowerShell Script Block Logging (EventID 4104) ​

OMA-URI 4 — PowerShell Transcription (Recommended) ​

1.4 — PowerShell Script Deployment (Fallback / Verification) ​

1.5 — Assignment ​

1.6 — Verifying Intune Deployment ​

Part 2 — Group Policy (AD-Joined Servers) ​

Prerequisites ​

2.1 — GPO Structure ​

2.2 — Audit Policy Configuration (All Server GPO) ​

Detailed Tracking ​

Logon/Logoff ​

Object Access ​

System ​

2.3 — Process Command Line in 4688 (GPO Administrative Template) ​

2.4 — PowerShell Logging via GPO ​

Module Logging (EventID 4103) ​

Script Block Logging (EventID 4104) ​

Transcription (Recommended) ​

2.5 — Domain Controllers: Additional Audit Policy ​

Account Logon (DC-specific) ​

Directory Service Access (DC-specific) ​

2.6 — GPO Application ​

2.7 — DCR Verification: System Log Inclusion ​

Part 3 — Verification ​

3.1 — KQL Coverage Queries ​

Overall Coverage Check ​

EventID 4688 — Process Creation with CommandLine ​

EventID 4688 — Device Coverage ​

EventID 4624/4625 — Logon Events ​

EventID 4648 — Explicit Credential Logon ​

EventID 7045 — New Service (System Log) ​

EventID 4698/4702 — Scheduled Task Created/Modified ​

EventID 5140 — Network Share Access ​

EventID 1102 — Audit Log Cleared ​

PowerShell 4103/4104 — Script Block and Module Logging ​

3.2 — Device Coverage Check ​

3.3 — Expected Volume (Sanity Check) ​

3.4 — Troubleshooting: Events in Event Viewer but Not in LAW ​

Compliance Mapping ​

Related Documentation ​

Document History ​

Kill Chain Phase 1 — Event Enablement Runbook

Purpose

Scope and Delivery Method

Event Coverage Matrix

Part 1 — Intune (Home Computers, Non-Domain-Joined Windows 10/11)

Prerequisites

1.1 — Create the Settings Catalog Policy

1.2 — Audit Subcategories via Settings Catalog

Process Creation → EventID 4688

Logon Events → EventID 4624 and 4625

Explicit Credential Logon → EventID 4648

New Service Installed → EventID 7045

Network Share Access → EventID 5140

Security Audit Log Cleared → EventID 1102

Scheduled Task Created/Modified → EventID 4698 and 4702

1.3 — Settings Not in Settings Catalog: OMA-URI Policies

OMA-URI 1 — ProcessCreationIncludeCmdLine (required for 4688 CommandLine field)

OMA-URI 2 — PowerShell Module Logging (EventID 4103)

OMA-URI 3 — PowerShell Script Block Logging (EventID 4104)

OMA-URI 4 — PowerShell Transcription (Recommended)

1.4 — PowerShell Script Deployment (Fallback / Verification)

1.5 — Assignment

1.6 — Verifying Intune Deployment

Part 2 — Group Policy (AD-Joined Servers)

Prerequisites

2.1 — GPO Structure

2.2 — Audit Policy Configuration (All Server GPO)

Detailed Tracking

Logon/Logoff

Object Access

System

2.3 — Process Command Line in 4688 (GPO Administrative Template)

2.4 — PowerShell Logging via GPO

Module Logging (EventID 4103)

Script Block Logging (EventID 4104)

Transcription (Recommended)

2.5 — Domain Controllers: Additional Audit Policy

Account Logon (DC-specific)

Directory Service Access (DC-specific)

2.6 — GPO Application

2.7 — DCR Verification: System Log Inclusion

Part 3 — Verification

3.1 — KQL Coverage Queries

Overall Coverage Check

EventID 4688 — Process Creation with CommandLine

EventID 4688 — Device Coverage

EventID 4624/4625 — Logon Events

EventID 4648 — Explicit Credential Logon

EventID 7045 — New Service (System Log)

EventID 4698/4702 — Scheduled Task Created/Modified

EventID 5140 — Network Share Access

EventID 1102 — Audit Log Cleared

PowerShell 4103/4104 — Script Block and Module Logging

3.2 — Device Coverage Check

3.3 — Expected Volume (Sanity Check)

3.4 — Troubleshooting: Events in Event Viewer but Not in LAW

Compliance Mapping

Related Documentation

Document History