Kernel integrity weakened

Windows recorded a boot configuration that weakens kernel code integrity. Event 4826 is written at boot with the settings in force, and three of them matter here:

* TestSigning enabled — the kernel will load drivers signed by ANY certificate, including one the attacker generated. * KernelDebug enabled — a kernel debugger may attach, which permits arbitrary kernel memory modification and defeats PatchGuard. * DisableIntegrityChecks — driver signature enforcement off entirely.

Any of these is the prerequisite for loading an unsigned or attacker-signed driver, which is how endpoint protection gets disabled from below (the "bring your own vulnerable driver" pattern). Because the setting survives reboot, this is a persistent weakening of the platform, not a momentary action.

• T1553.006Subvert Trust Controls: Code Signing Policy Modification· Defense Evasion
• T1562.001Impair Defenses: Disable or Modify Tools· Defense Evasion

Genuine on driver-development and QA machines, and on hardware-vendor test rigs — these settings exist for that purpose. Establish once whether the host has any business running unsigned drivers; if it is an ordinary workstation or server, it does not.

Note the %%1842 / %%1843 codes are Windows' own Enabled / Disabled values, so a record showing %%1843 is the safe state and does not match.

To confirm: this event marks the boot AFTER the change, so look for what set it — bcdedit.exe with testsigning, nointegritychecks or debug, and the reboot that followed. Then enumerate drivers loaded since, and check for any whose signature would not have been accepted under normal enforcement.

Declarative YAML read by the detection engine — data, never executed. Confidence 80%. Source: rules/windows/kernel_integrity_weakened.yaml, licensed under the Apache License 2.0.

id: windows.defense_evasion.kernel_integrity_weakened
version: 1.0.0
status: stable
severity: high
confidence: 0.8
platforms: [windows]
mitre_techniques: [T1553.006, T1562.001]
description: |
  Windows recorded a boot configuration that weakens kernel code integrity. Event
  4826 is written at boot with the settings in force, and three of them matter here:

    * `TestSigning` enabled  — the kernel will load drivers signed by ANY
      certificate, including one the attacker generated.
    * `KernelDebug` enabled  — a kernel debugger may attach, which permits arbitrary
      kernel memory modification and defeats PatchGuard.
    * `DisableIntegrityChecks` — driver signature enforcement off entirely.

  Any of these is the prerequisite for loading an unsigned or attacker-signed driver,
  which is how endpoint protection gets disabled from below (the "bring your own
  vulnerable driver" pattern). Because the setting survives reboot, this is a
  persistent weakening of the platform, not a momentary action.
match:
  native_event_id: '4826'
  raw_message_contains_any:
    - 'TestSigning=%%1842'
    - 'KernelDebug=%%1842'
    - 'DisableIntegrityChecks=%%1842'
correlation_keys: [hostname]
false_positive_guidance: |
  Genuine on driver-development and QA machines, and on hardware-vendor test rigs —
  these settings exist for that purpose. Establish once whether the host has any
  business running unsigned drivers; if it is an ordinary workstation or server, it
  does not.

  Note the `%%1842` / `%%1843` codes are Windows' own Enabled / Disabled values, so a
  record showing `%%1843` is the safe state and does not match.

  To confirm: this event marks the boot AFTER the change, so look for what set it —
  `bcdedit.exe` with `testsigning`, `nointegritychecks` or `debug`, and the reboot
  that followed. Then enumerate drivers loaded since, and check for any whose
  signature would not have been accepted under normal enforcement.

• Security logging registry tamperingSeverity high
• AWS security service disabledSeverity high
• Microsoft 365 Purview policy tamperingSeverity high
• Audit daemon stoppedSeverity high
• Security service stoppedSeverity high
• Defender Exclusion Added via PowerShellSeverity high