Skip to content

Windows telemetry integrity and policy recovery

Treat collection health as evidence. A logging-policy change, provider reconfiguration, cleared channel, forwarding gap, or later Group Policy repair can materially change what an investigation is able to prove.

High-value evidence

Evidence What it establishes Dependency
Sysmon 4 Sysmon service state changed Sysmon installed and collected
Sysmon 12–14 Monitored registry object/value changed Matching Sysmon registry rules
Sysmon 16 Sysmon configuration changed Sysmon Operational log collected
Sysmon 255 Sysmon reported an internal error Sysmon Operational log collected
Security 4657 Registry value modified Audit Registry plus a matching system access control list
Security 4719 System audit policy changed Security auditing and collection
Security 1102 Security audit log cleared Security log collection
System 104 An event log was cleared Relevant System log collection
PowerShell 4103 Module logging content Module Logging enabled
PowerShell 4104 Script block content Script Block Logging enabled
GroupPolicy 4016 / 5016 Client-side extension processing started/completed Group Policy Operational log collected
Defender 5007 Microsoft Defender Antivirus configuration changed Defender Operational log collected
Defender 5013 Tamper protection blocked a protected Defender change Supported protected setting and Defender Operational log

No single event proves every telemetry-tampering scenario. Correlate configuration state, process activity, policy source and forwarding health.

Defender events

Microsoft Defender tamper protection and PowerShell logging policy protect different control planes.

  • 5013 is the clearest local evidence that tamper protection blocked a change to a supported Microsoft Defender Antivirus setting.
  • 5007 records a Defender Antivirus configuration change. It does not, by itself, prove tamper protection triggered.
  • Absence of 5013 does not prove no tampering occurred. Check Defender version, onboarding, policy source, tamper-protection state, collection and whether the target setting is protected.

Collect the setting, attempted old/new values, timestamp, actor or process evidence, nearby endpoint activity and resulting policy state.

PowerShell policy changes

Machine-wide PowerShell policy values normally reside below:

HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell

An elevated local administrator can normally change machine-wide PowerShell logging values on that endpoint. Local administrative rights do not grant authority to edit the domain Group Policy Object.

High-value values include:

ScriptBlockLogging\EnableScriptBlockLogging
ModuleLogging\EnableModuleLogging
Transcription\EnableTranscripting

Monitor with narrowly scoped Sysmon registry rules and, where justified, Security 4657 auditing. Also collect the responsible process, user/session, command line and preceding elevation or remote-administration activity.

Group Policy restoration

Do not assume that a local value will be repaired at an exact time.

Ordinary clients and member servers normally refresh Group Policy every 90 minutes plus a random offset of up to 30 minutes; domain controllers check computer policy more frequently. Connectivity, policy scope, slow links and client-side-extension behavior can delay or prevent restoration.

By default, an unchanged applicable Group Policy Object might not cause registry settings to be rewritten. Environments that require drift correction can configure registry policy processing to process even when Group Policy Objects have not changed.

Correlate:

unexpected privileged process changes logging policy
→ activity occurs during reduced visibility
→ GroupPolicy 4016 begins Registry extension processing
→ Sysmon 13 and/or Security 4657 records the desired value restored
→ GroupPolicy 5016 completes processing

That sequence is suspicious but not conclusive. Test approved troubleshooting, deployment activity, configuration-management conflicts, operating-system servicing and administrator error.

Central Group Policy changes

Endpoint registry events show local effect; they do not identify who edited the central policy.

For domain Group Policy changes, correlate:

  • Active Directory event 5136 when Directory Service Changes auditing and suitable object auditing are enabled;
  • System Volume file auditing where justified;
  • Group Policy delegation and change-control records;
  • privileged identity and administrative workstation telemetry;
  • before/after Group Policy reports, replication and endpoint processing.

Group Policy editing can be delegated. Domain Admin membership is not the only authority that can modify a specific Group Policy Object.

Investigation sequence

  1. Establish the last known healthy event and provider heartbeat.
  2. Find policy, registry, service, channel, collector or sensor changes.
  3. Resolve the actor, token, process lineage and management source.
  4. Bound the reduced-visibility interval.
  5. Hunt other providers for activity during that interval.
  6. Determine whether the control was blocked, changed, reverted or never applied.
  7. Verify collection recovery at the endpoint and destination.
  8. Preserve configuration snapshots, event records and policy provenance.

Sources