EDR Freeze - GPO Defense

Okay this may take a while. A discussion with an AI

The following post is taken from here:

New EDR-Freeze Tool That Puts EDRs and Antivirus Into A Coma State

A new proof-of-concept tool named EDR-Freeze has been developed, capable of placing Endpoint Detection and Response (EDR) and antivirus solutions into a suspended “coma” state.

CybersecurityNewsGuru Baran

The bottom line

For defenders, detecting this technique involves monitoring for unusual executions of WerFaultSecure.exe

A conversation begins

Got it, Leon — this is a tricky one because the EDR-Freeze technique doesn’t rely on a vulnerable driver (like BYOVD) but instead abuses legitimate Windows components (WerFaultSecure.exe + MiniDumpWriteDump) to suspend protected processes like Defender’s MsMpEng.exe. Since you don’t have domain GPO, Intune, or App Control, you’re limited to local policy hardening and Defender configuration. Here are some practical, defensible steps you can apply:

🔐 Local Group Policy Recommendations

1. Restrict WerFaultSecure.exe Execution

• Path: Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies (or AppLocker if available locally)
• Action: Create a rule to deny execution of WerFaultSecure.exe for standard users.
  • Located in: C:\Windows\System32\WerFaultSecure.exe
• ⚠️ Note: This may impact Windows Error Reporting. If you rely on WER for debugging, consider restricting only for non-admin users.

2. Block Debug Privileges for Non-Admins

• Path: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment
• Policy: Debug programs
• Action: Ensure only Administrators have this right. Remove any service accounts or unintended users.
• Why: The attack relies on suspending processes, which requires debug-level rights.

3. Harden LSASS & Protected Processes

• Policy: Computer Configuration > Administrative Templates > System > Local Security Authority
• Enable: Configure LSASS to run as a protected process
• While this doesn’t directly stop EDR-Freeze, it raises the bar against memory tampering and aligns with best practice.

4. Enable Defender Tamper Protection

• Even without Intune, you can enforce via Local Group Policy:
  • Path: Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Tamper Protection
  • Set: Enabled
• This helps prevent registry/service changes, though it won’t stop the freeze itself.

5. Audit WerFaultSecure.exe Usage

• Path: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Detailed Tracking
• Enable: Audit Process Creation and Audit Process Termination
• Then add a command line logging policy (via Event Viewer → Sysmon if you can deploy it locally).
• This gives you runtime evidence if WerFaultSecure.exe is invoked against Defender or LSASS.

🛡️ Additional Hardening (Non-GPO but Local)

• Exploit Guard Attack Surface Reduction (ASR) Rules
  Even without Intune, you can configure ASR rules via PowerShell or local GPO:
  • Example: Block credential stealing (Block credential stealing from LSASS)
  • Path: Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction
• Sysmon Deployment
  Lightweight, local-only monitoring. Create a rule to alert on WerFaultSecure.exe targeting MsMpEng.exe.

🎯 Practical Priority for You

1. Lock down debug rights (biggest impact, lowest risk).
2. Restrict WerFaultSecure.exe if you don’t need WER.
3. Enable ASR rules locally for extra coverage.
4. Audit & monitor — since prevention is partial, detection is critical.

Excellent — let’s wire up Sysmon so you can see if WerFaultSecure.exe is ever abused against Defender (MsMpEng.exe) or other protected processes. This gives you runtime evidence for audit and incident response, even if prevention layers are bypassed.

⚙️ Sysmon Config Snippet for EDR‑Freeze Detection

Below is a modular Sysmon XML snippet you can drop into your existing Sysmon config (or run standalone if you’re just starting). It focuses on:

• Process creation: Catching WerFaultSecure.exe launches.
• Process access: Detecting when it tries to open a handle to MsMpEng.exe (Defender) or other security processes.
• Command line visibility: Ensuring you see the full invocation.

<Sysmon schemaversion="4.90">
  <EventFiltering>

    <!-- 1. Process Creation: WerFaultSecure.exe -->
    <ProcessCreate onmatch="include">
      <Image condition="is">C:\Windows\System32\WerFaultSecure.exe</Image>
    </ProcessCreate>

    <!-- 2. Process Access: WerFaultSecure.exe targeting Defender -->
    <ProcessAccess onmatch="include">
      <!-- Source process -->
      <SourceImage condition="is">C:\Windows\System32\WerFaultSecure.exe</SourceImage>
      <!-- Target process: Defender -->
      <TargetImage condition="is">C:\ProgramData\Microsoft\Windows Defender\Platform\*\MsMpEng.exe</TargetImage>
    </ProcessAccess>

    <!-- 3. Process Access: WerFaultSecure.exe targeting LSASS (optional) -->
    <ProcessAccess onmatch="include">
      <SourceImage condition="is">C:\Windows\System32\WerFaultSecure.exe</SourceImage>
      <TargetImage condition="is">C:\Windows\System32\lsass.exe</TargetImage>
    </ProcessAccess>

  </EventFiltering>
</Sysmon>

📊 What You’ll See in Event Logs

• Event ID 1 (Process Create) → Logs whenever WerFaultSecure.exe starts, with full command line.
• Event ID 10 (Process Access) → Logs when it attempts to open a handle to MsMpEng.exe or lsass.exe.
• You’ll see the SourceImage, TargetImage, and GrantedAccess fields — if 0x1FFFFF or similar shows up, that’s a full access attempt.

🔍 Operational Notes

• Place this snippet inside your main Sysmon config under <EventFiltering>.
• Monitor via Event Viewer:
  Applications and Services Logs > Microsoft > Windows > Sysmon/Operational.
• For runtime triage, you can also forward these events into your SIEM or even a local PowerShell watcher.

Reload Sysmon with:

sysmon -c sysmon-config.xml

✅ Why This Helps You

• Auditability: You’ll have runtime evidence if anyone tries to freeze Defender.
• Compliance mapping: These logs can be tied to your risk register as “runtime detection of EDR tampering attempts.”
• Low footprint: Sysmon is lightweight and doesn’t interfere with Defender.

Would you like me to also draft a Sigma rule (SIEM‑ready detection logic) that matches these Sysmon events, so you can plug it into Splunk/Elastic/Defender Advanced Hunting if you expand later? That way you’d have both endpoint visibility and centralized detection logic.

Perfect — let’s extend your Sysmon visibility into a SIEM‑ready Sigma rule. This way, if you later centralize logs (Splunk, Elastic, Sentinel, etc.), you’ll already have a detection logic that matches the Sysmon events we set up.

📜 Sigma Rule: Detect WerFaultSecure.exe Targeting Defender/LSASS

title: Suspicious Use of WerFaultSecure.exe Against Security Processes
id: 3c8a8c1a-7f3e-4f0a-9d1f-werfault-edr-freeze
status: experimental
description: Detects potential abuse of WerFaultSecure.exe to suspend or tamper with Microsoft Defender (MsMpEng.exe) or LSASS, as seen in EDR-Freeze techniques.
author: Leon + Copilot
date: 2025/09/27
logsource:
  product: windows
  service: sysmon
detection:
  selection_process_create:
    EventID: 1
    Image|endswith: '\WerFaultSecure.exe'
  selection_process_access_defender:
    EventID: 10
    SourceImage|endswith: '\WerFaultSecure.exe'
    TargetImage|contains: '\MsMpEng.exe'
  selection_process_access_lsass:
    EventID: 10
    SourceImage|endswith: '\WerFaultSecure.exe'
    TargetImage|endswith: '\lsass.exe'
  condition: selection_process_create or selection_process_access_defender or selection_process_access_lsass
fields:
  - UtcTime
  - Image
  - CommandLine
  - SourceImage
  - TargetImage
  - GrantedAccess
level: high
tags:
  - attack.defense_evasion
  - attack.t1562.001   # Impair Defenses: Disable or Modify Tools
  - attack.credential_access

🔍 How It Works

• EventID 1 → flags any execution of WerFaultSecure.exe.
• EventID 10 → flags when it tries to open handles to MsMpEng.exe (Defender) or lsass.exe.
• GrantedAccess field will show if it’s requesting suspicious rights (e.g., 0x1FFFFF).

🧩 Deployment Notes

• Save this as werfault_edr_freeze.yml.
• Convert to your SIEM’s query language using Sigma converters.
• In Splunk, it will translate to a sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational query.
• In Sentinel, it becomes a KQL query against SecurityEvent or Sysmon tables.

✅ Why This Complements Your Baseline

• Sysmon config = endpoint visibility.
• Sigma rule = portable detection logic for SIEM/SOAR.
• Audit trail = runtime evidence for compliance and incident response.

Would you like me to also map this detection back to the MITRE ATT&CK framework in a way you can drop directly into your compliance/risk register (e.g., T1562.001, T1003, etc.), so you’ve got defensible documentation for auditors as well as runtime controls?

Conversation concluded for the time being. The use of AI by organizations and hackers is broadening greatly. It would have taken me ages to come to these conclusions and remediations.

You can see why BILLIONS is been spent on AI, and the quantum computers that will enhance their abilities exponentially.

#enoughsaid