Disable or Modify Windows Defender

Back


Id	20d52a04-b5d8-402d-88e2-7929d12cbdcd
Rulename	Disable or Modify Windows Defender
Description	This detection watches the commandline logs for known commands that are used to disable the Defender AV. This is based on research performed by @olafhartong on a large sample of malware for varying purposes. Note that this detection is imperfect and is only meant to serve as basis for building a more resilient detection rule. Make the detection more resilient, currently the order of parameters matters. You don’t want that for a production rule. See blogpost (https://medium.com/falconforce/falconfriday-av-manipulation-0xff0e-67ed4387f9ab?source=friends_link&sk=3c7c499797bbb4d74879e102ef3ecf8f) for more resilience considerations. The current approach can easily be bypassed by not using the powershell.exe executable. Consider adding more ways to detect this behavior.
Severity	Medium
Tactics	DefenseEvasion
Techniques	T1562.001
Required data connectors	MicrosoftThreatProtection
Kind	Scheduled
Query frequency	1h
Query period	1h
Trigger threshold	0
Trigger operator	gt
Source Uri	https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/FalconFriday/Analytic Rules/DisableOrModifyWindowsDefender.yaml
Version	1.0.1
Arm template	20d52a04-b5d8-402d-88e2-7929d12cbdcd.json

KQL

let defendertampering=dynamic(["Set-MpPreference -DisableRealtimeMonitoring $true","sc stop WinDefend","sc delete WinDefend","Set-MpPreference -DisableBehaviorMonitoring $true","Set-MpPreference -ExclusionProcess", "Set-MpPreference -ExclusionExtension dll","net stop security center"]);
DeviceProcessEvents
| where ProcessCommandLine has_any (defendertampering)
// If you have a lot of false positives coming from JetBrains, you can use the line below. 
//| where InitiatingProcessFolderPath !startswith @"c:\program files\jetbrains\" and InitiatingProcessVersionInfoProductName !~ ("Android Studio")

YAML

entityMappings:
- entityType: Host
  fieldMappings:
  - identifier: FullName
    columnName: DeviceName
- entityType: Account
  fieldMappings:
  - identifier: Sid
    columnName: AccountSid
  - identifier: Name
    columnName: AccountName
  - identifier: NTDomain
    columnName: AccountDomain
- entityType: Process
  fieldMappings:
  - identifier: CommandLine
    columnName: ProcessCommandLine
name: Disable or Modify Windows Defender
tactics:
- DefenseEvasion
severity: Medium
triggerThreshold: 0
relevantTechniques:
- T1562.001
id: 20d52a04-b5d8-402d-88e2-7929d12cbdcd
version: 1.0.1
OriginalUri: https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/FalconFriday/Analytic Rules/DisableOrModifyWindowsDefender.yaml
queryFrequency: 1h
triggerOperator: gt
query: |
  let defendertampering=dynamic(["Set-MpPreference -DisableRealtimeMonitoring $true","sc stop WinDefend","sc delete WinDefend","Set-MpPreference -DisableBehaviorMonitoring $true","Set-MpPreference -ExclusionProcess", "Set-MpPreference -ExclusionExtension dll","net stop security center"]);
  DeviceProcessEvents
  | where ProcessCommandLine has_any (defendertampering)
  // If you have a lot of false positives coming from JetBrains, you can use the line below. 
  //| where InitiatingProcessFolderPath !startswith @"c:\program files\jetbrains\" and InitiatingProcessVersionInfoProductName !~ ("Android Studio")  
description: |
  This detection watches the commandline logs for known commands that are used to disable the Defender AV. This is based on research performed by @olafhartong on a large sample of malware for varying purposes. 
  Note that this detection is imperfect and is only meant to serve as basis for building a more resilient detection rule. Make the detection more resilient, currently the order of parameters matters. You don't want that for a production rule. 
  See blogpost (https://medium.com/falconforce/falconfriday-av-manipulation-0xff0e-67ed4387f9ab?source=friends_link&sk=3c7c499797bbb4d74879e102ef3ecf8f) for more resilience considerations. The current approach can easily be bypassed by not using the powershell.exe executable. 
  Consider adding more ways to detect this behavior.  
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - DeviceProcessEvents
status: Available
queryPeriod: 1h
kind: Scheduled

ARM

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspace": {
      "type": "String"
    }
  },
  "resources": [
    {
      "apiVersion": "2024-01-01-preview",
      "id": "[concat(resourceId('Microsoft.OperationalInsights/workspaces/providers', parameters('workspace'), 'Microsoft.SecurityInsights'),'/alertRules/20d52a04-b5d8-402d-88e2-7929d12cbdcd')]",
      "kind": "Scheduled",
      "name": "[concat(parameters('workspace'),'/Microsoft.SecurityInsights/20d52a04-b5d8-402d-88e2-7929d12cbdcd')]",
      "properties": {
        "alertRuleTemplateName": "20d52a04-b5d8-402d-88e2-7929d12cbdcd",
        "customDetails": null,
        "description": "This detection watches the commandline logs for known commands that are used to disable the Defender AV. This is based on research performed by @olafhartong on a large sample of malware for varying purposes. \nNote that this detection is imperfect and is only meant to serve as basis for building a more resilient detection rule. Make the detection more resilient, currently the order of parameters matters. You don't want that for a production rule. \nSee blogpost (https://medium.com/falconforce/falconfriday-av-manipulation-0xff0e-67ed4387f9ab?source=friends_link&sk=3c7c499797bbb4d74879e102ef3ecf8f) for more resilience considerations. The current approach can easily be bypassed by not using the powershell.exe executable. \nConsider adding more ways to detect this behavior.\n",
        "displayName": "Disable or Modify Windows Defender",
        "enabled": true,
        "entityMappings": [
          {
            "entityType": "Host",
            "fieldMappings": [
              {
                "columnName": "DeviceName",
                "identifier": "FullName"
              }
            ]
          },
          {
            "entityType": "Account",
            "fieldMappings": [
              {
                "columnName": "AccountSid",
                "identifier": "Sid"
              },
              {
                "columnName": "AccountName",
                "identifier": "Name"
              },
              {
                "columnName": "AccountDomain",
                "identifier": "NTDomain"
              }
            ]
          },
          {
            "entityType": "Process",
            "fieldMappings": [
              {
                "columnName": "ProcessCommandLine",
                "identifier": "CommandLine"
              }
            ]
          }
        ],
        "OriginalUri": "https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/FalconFriday/Analytic Rules/DisableOrModifyWindowsDefender.yaml",
        "query": "let defendertampering=dynamic([\"Set-MpPreference -DisableRealtimeMonitoring $true\",\"sc stop WinDefend\",\"sc delete WinDefend\",\"Set-MpPreference -DisableBehaviorMonitoring $true\",\"Set-MpPreference -ExclusionProcess\", \"Set-MpPreference -ExclusionExtension dll\",\"net stop security center\"]);\nDeviceProcessEvents\n| where ProcessCommandLine has_any (defendertampering)\n// If you have a lot of false positives coming from JetBrains, you can use the line below. \n//| where InitiatingProcessFolderPath !startswith @\"c:\\program files\\jetbrains\\\" and InitiatingProcessVersionInfoProductName !~ (\"Android Studio\")\n",
        "queryFrequency": "PT1H",
        "queryPeriod": "PT1H",
        "severity": "Medium",
        "status": "Available",
        "subTechniques": [
          "T1562.001"
        ],
        "suppressionDuration": "PT1H",
        "suppressionEnabled": false,
        "tactics": [
          "DefenseEvasion"
        ],
        "techniques": [
          "T1562"
        ],
        "templateVersion": "1.0.1",
        "triggerOperator": "GreaterThan",
        "triggerThreshold": 0
      },
      "type": "Microsoft.OperationalInsights/workspaces/providers/alertRules"
    }
  ]
}