Loading

PowerShell Script with Windows Defender Tampering Capabilities

Detects PowerShell scripts that uses Set-MpPreference with parameters that disable or weaken Defender. Attackers tamper with antivirus settings to reduce detection and enable follow-on payload execution.

Rule type: query
Rule indices:

  • winlogbeat-*
  • logs-windows.powershell*

Rule Severity: medium
Risk Score: 47
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • Data Source: PowerShell Logs
  • Resources: Investigation Guide

Version: 107
Rule authors:

  • Elastic

Rule license: Elastic License v2

PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). Setup instructions: https://ela.st/powershell-logging-setup

Disclaimer: This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.

This alert highlights PowerShell script block activity that attempts to change Windows Defender preferences in ways that can reduce host protections. These changes are frequently used to create a window for follow-on execution (for example, staging payloads, running tools, or maintaining access with reduced scanning and response).

Triage should focus on (1) what protections were targeted and how, (2) who initiated the change and on which host(s), (3) whether the change took effect and persisted, and (4) whether there is surrounding activity that suggests initial access or follow-on malicious actions.

  • user.name, user.domain, user.id: Account execution context for correlation, prioritization, and scoping.
  • host.name, host.id: Host execution context for correlation, prioritization, and scoping.
  • powershell.file.script_block_text: Script block content that matched the detection logic.
  • powershell.file.script_block_id, powershell.sequence, powershell.total: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.
  • file.path, file.directory, file.name: File-origin context when the script block is sourced from an on-disk file.
  • powershell.file.script_block_length: Script block length (size) context.

  • Review the script block content and determine the intended Defender impact:

    • Inspect powershell.file.script_block_text and enumerate each Set-MpPreference parameter present.
    • Capture whether the script is disabling protections (for example, real-time monitoring, script scanning, network file scanning) or changing default threat actions (low/moderate/high) to more permissive outcomes.
    • Note whether the script changes multiple settings in one execution, repeats the changes, or includes additional logic that suggests deliberate defense impairment rather than a single configuration adjustment.

  • Reconstruct full script content when it is split across multiple events:

    • If powershell.total is greater than 1, pivot on powershell.file.script_block_id and order fragments by powershell.sequence to rebuild the full script.
    • Ensure you capture all fragments for the same powershell.file.script_block_id on the same host.id and user.id near the alert time; missing fragments can hide follow-on behavior embedded in later chunks.

  • Establish scope across hosts and accounts:

    • Use @timestamp, host.name / host.id, and user.name / user.domain / user.id to determine whether the activity is isolated or distributed.
    • Look for the same user context making similar changes across multiple hosts in a short time window (suggesting automation or compromised credentials).
    • Look for multiple distinct user contexts making similar changes on the same host (suggesting lateral movement or multiple access paths).

  • Determine the execution and origin context:

    • If file.path or file.name is populated, treat the activity as file-backed scripting and capture the location for scoping (where else this script exists, who can write to it, and when it was last introduced).
    • If the file fields are not populated, treat the activity as potentially interactive or dynamically generated content and expand the search for adjacent script blocks from the same user.id on the same host.id around @timestamp to identify staging, execution flow, or repeated attempts.

  • Validate whether Defender settings were actually changed and whether the change persisted:

    • Using available endpoint security telemetry and configuration auditing, validate whether the targeted preferences were applied on the affected host(s) and whether they remained in the weakened state after the alert time.
    • Compare against your approved baseline for Defender settings and identify deviations that would materially reduce protection coverage.

  • Correlate with adjacent activity to identify initial access and follow-on execution:

    • Correlate by host.id and time to nearby process activity to identify the PowerShell host process and its launching context (interactive use vs scheduled/automated execution vs another process initiating PowerShell).
    • Review file and network telemetry around the same time for indicators of payload staging or execution (new files written, unusual outbound connections, or repeated attempts after the change).
    • Check for repeated Defender preference modifications over time on the same host (suggesting persistent tampering) and for other suspicious activity tied to the same user.id.

Legitimate activity can modify Defender preferences, but it should be explainable, consistent, and controlled.

  • Common benign drivers:

    • Approved endpoint management or administrative maintenance that adjusts scanning behavior for performance or operational compatibility.
    • Controlled troubleshooting where settings are temporarily changed and later restored.

  • Validation questions to reduce uncertainty:

    • Does user.id map to an expected administrative or management identity for this host population?
    • Is the activity aligned with known maintenance windows, change records, and documented procedures?
    • Is file.path (when present) consistent with a known, maintained script location, and does the script content align with an approved baseline?

If the activity is benign, document the owner, expected scope (hosts/users), expected recurrence, and the intended steady-state protection posture.

If the activity is unauthorized or suspicious, treat it as a defense evasion attempt with potential follow-on actions.

  • Contain and preserve evidence:

    • Prioritize affected endpoints identified by host.id / host.name and preserve relevant evidence, including the full reconstructed script from powershell.file.script_block_id and powershell.file.script_block_text.
    • Capture the initiating identity context (user.name, user.domain, user.id) for incident scoping and credential review.

  • Restore protections and eliminate the change source:

    • Restore Windows Defender preferences to the approved baseline using authorized operational processes and verify protections are active.
    • If file.path is present, identify the responsible script and remove or disable unauthorized automation that applies the changes.
    • If the activity appears user-driven or interactive, investigate how the user obtained execution capability on the host and address the root cause.

  • Address potential account compromise and lateral movement:

    • Review recent activity associated with the initiating account and affected hosts for signs of credential misuse, unexpected access patterns, or follow-on execution.
    • Apply appropriate credential remediation for impacted identities and review privileged access assignments relevant to the affected endpoints.

  • Scope and monitor:

    • Hunt for the same Defender-tampering parameters within powershell.file.script_block_text across other hosts and users to identify additional impacted systems.
    • Continue monitoring for recurrence of similar preference changes tied to the same user.id, as repeated tampering may indicate persistence or an active intrusion.
event.category: "process" and host.os.type:windows and
(
  powershell.file.script_block_text: "Set-MpPreference" and
  powershell.file.script_block_text: (
    DisableArchiveScanning or DisableBehaviorMonitoring or
    DisableIntrusionPreventionSystem or DisableIOAVProtection or
    DisableRemovableDriveScanning or DisableBlockAtFirstSeen or
    DisableScanningMappedNetworkDrivesForFullScan or
    DisableScanningNetworkFiles or DisableScriptScanning or
    DisableRealtimeMonitoring or LowThreatDefaultAction or
    ModerateThreatDefaultAction or HighThreatDefaultAction
  )
) and
not powershell.file.script_block_text : (
  ("cmdletization" and "cdxml-Help.xml") or
  ("function Set-MpPreference" and "Microsoft.PowerShell.Cmdletization.GeneratedTypes.MpPreference.SubmitSamplesConsentType")
) and
not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\SenseCM" and
not user.id : "S-1-5-18"

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK