brencronin

2 days ago10 min read

EDR Evaluation - EDR System Operations (SysOps)

EDR/XDR platforms often lack transparency in their detection logic. This is intentional, designed both to prevent threat actors from bypassing detections and to safeguard the product’s intellectual property from being copied by competitors.

A noteworthy initiative addressing this challenge is the EDR Telemetry Project: https://www.edr-telemetry.com/index.html This project aims to map telemetry data from leading EDR vendors, helping users better understand the data being collected and enabling them to build custom detection rules tailored to their specific environments and security needs.

For Windows-based systems, the categories of EDR telemetry covered by the project include:

Process Activity
File Manipulation
User Account Activity
Network Activity
Hash Algorithms
Registry Activity
Scheduled Task Activity
Service Activity
Drive/Module Activity
Device Operations
Other Relevant Events
Named Pipe Activity
EDR System Operations (SysOps)
WMI Activity
BITS Jobs Activity
PowerShell Activity

This resource provides organizations with valuable insights into EDR telemetry, enabling them to refine detection strategies and strengthen their overall security posture. This article will specifically highlight the importance of EDR System Operations (SysOps) for cyber defenders and explore additional investigative techniques within the Microsoft Defender EDR environment that defenders can leverage.

Understanding EDR System Operations (SysOps)

Ensuring the EDR is operational and fully functional is critical, as it serves as one of your primary detection mechanisms. Consequently, the EDR must include safeguards and alerting capabilities to detect and respond to scenarios where it is stopped, uninstalled, disconnected, or experiences errors.

The EDR Telemetry Project categorizes the following telemetry types under EDR System Operations (SysOps) related to the EDR agent on the host:

Agent Start
Agent Stop
Agent Install
Agent Uninstall
Agent Keep-Alive
Agent Errors

These telemetry events are essential for maintaining the functionality and reliability of the EDR solution, ensuring continuous protection and visibility.

How attackers try to bypass EDR Detections?

First Step, EDR Enumeration

One of the first actions threat actors take upon compromising a system is to enumerate the EDR tools and configurations in place. This helps them understand how they can evade detection and avoid being blocked. For instance, the Seatbelt project ( https://github.com/GhostPack/Seatbelt ) provides a set of security-oriented host-survey "safety checks" for red team operators or attackers. Among its modules, one specifically allows for checking Windows Defender settings, highlighting potential weaknesses that could be exploited.

Therefore, the detection of EDR enumeration can serve as a good threat hunting or detection for defenders. For example, for Windows Defender there is a powershell module Get-MpPreference https://learn.microsoft.com/en-us/powershell/module/defender/get-mppreference?view=windowsserver2022-ps which gets preferences for the Windows Defender scans and updates.

//Overall MP protection status
PS C:\> Get-MpComputerStatus
AMEngineVersion                 : 1.1.9700.0
AMProductVersion                : 4.3.9463.0
AMServiceEnabled                : True
...
...
//MP exclusions
Get-MpPreference | Select-Object -Property ExclusionPath -ExpandProperty ExclusionPath

KQL query to search for this type of activity.

let ProcessBased = DeviceProcessEvents
| where ProcessCommandLine has "Get-MpPreference"
| extend Table = "DeviceProcessEvents"
| project-reorder Table, Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessFileName;
let EventBased = DeviceEvents
| extend Command = parse_json(AdditionalFields).Command
| where  Command == "Get-MpPreference"
| extend ScriptLocation = extract(@"literalPath '(.*?)'", 0, InitiatingProcessCommandLine)
| extend Table = "DeviceEvents"
| project-reorder Table, Timestamp, DeviceName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, ScriptLocation;
union ProcessBased, EventBased

https://www.kqlsearch.com/query/Defenderdiscoveryactivities&clp06744s0151mc0ogrrxq51o

Defender settings can also be obtained via Windows Mangement instrumentation (WMI).

Get-CimInstance -ComputerName MyRemoteServer -Query 'Select * from MSFT_MPComputerStatus' -Namespace 'root\Microsoft\Windows\Defender' | Select RealTimeProtectionEnabled,PSComputerName

Defender also has a DOS based command line tool called MpCmdRun.exe https://learn.microsoft.com/en-us/defender-endpoint/command-line-arguments-microsoft-defender-antivirus?branch=v-anbic-wdav-new-mpcmdrun-options it is also notable that this tool is listed in the Living off the Land LOL binaries project: https://lolbas-project.github.io/lolbas/Binaries/MpCmdRun/

%ProgramFiles%\Windows Defender\MpCmdRun.exe
//or
C:\ProgramData\Microsoft\Windows Defender\Platform\<antimalware platform version>

MpCmdRun.exe -CheckExclusion -path <path>

Defender SysOps Telemetry and Tampering

Overview of Defender SysOps Telemetry

The diagram below illustrates common techniques attackers use to bypass Defender EDR, including:

PowerShell Cmdlets: Using Set-MpPreference and Add-MpPreference to modify Defender settings.
WMI: Leveraging Windows Management Instrumentation for manipulation.
MpCmdRun.exe: Executing commands via Defender’s command-line utility.
Registry Modifications: Directly altering registry settings related to Defender.

Each of these methods requires administrator privileges, emphasizing the critical need to restrict and tightly manage administrative access on systems.

The diagram also highlights key telemetry sources for detecting these manipulation techniques:

Defender Logs: Essential for detecting changes or issues (Applications and Services Logs > Microsoft > Windows > Windows Defender)
PowerShell Logs: Crucial for tracking script-based activity.
Registry Activity: Monitors changes to Defender-related settings.
Tamper Protection Alerts: Triggered if Defender’s tamper protection is enabled.

These insights highlight the critical need to instrument both Defender and PowerShell to ensure comprehensive log collection and correlation for effective alerting. Equally important is monitoring these telemetry sources for tampering, such as attempts to disable PowerShell logging, to maintain the integrity of detection mechanisms. They also emphasize the need to actively monitor and alert on any interference with this telemetry to ensure early detection of potential bypass attempts.

Overview of Defender Tampering

Windows Defender's tamper protection is a crucial feature designed to safeguard key security settings from unauthorized changes. This includes blocking attempts to disable critical Defender functionalities such as:

Virus and threat protection
Real-time protection
Behavior monitoring
Antivirus protection, including IOAV (IOfficeAntivirus)
Cloud protection
Automatic threat action management
Security intelligence updates
Scanning of archive files
Notifications to the Windows Security app
Managing Defender Tamper Protection

Defender tamper protection can be configured through:

The Microsoft Defender portal
Intune Admin Center or Configuration Manager
Configuration Manager with tenant attach
The Windows Security app

Tamper protection also restricts the addition or modification of exclusions, provided these conditions are met:

Devices use a minimum version of the Defender platform.
DisableLocalAdminMerge is enabled, preventing local device settings from overriding organizational policies.
Devices are managed exclusively via Intune or Configuration Manager with Sense enabled.
Antivirus exclusions are centrally managed via Intune or Configuration Manager.

While tamper protection significantly enhances EDR security, it requires specific configurations to function optimally. Many organizations still lack the necessary settings or disable tamper protection as a workaround, leaving their systems exposed. If defender tamper protection is enabled the 'RealTimeProtectionEnabled' field will be true.

//Overall MP protection status
PS C:\> Get-MpComputerStatus
...
RealTimeProtectionEnabled       : True
...

Detecting Attempts to Modify Tamper-Protected Settings

If tamper protection is enabled, any attempt to modify protected settings is blocked, generating Event ID 5013 in the logs. This event identifies the setting that was targeted. The following KQL query can be used to detect such attempts:

//If Tamper protection is enabled then any attempt to change any of Defender's settings is blocked. Event ID 5013 is generated and states which setting change was blocked.//
Event
| where TimeGenerated >= ago(1d)
| where EventLog == "Microsoft-Windows-Windows Defender/Operational"
| where EventID == 5013
| parse EventData with * 'Value">'RegistryKey'</Data>' *
| extend RenderedDescription = tostring(split(RenderedDescription, "Value")[0])
| project TimeGenerated, Description = RenderedDescription, Computer, RegistryKey

Defender tamper protection adds an essential layer of defense against EDR tampering. However, organizations must ensure proper configurations are in place for it to work effectively. A failure to do so can leave systems vulnerable to attacks that exploit gaps in EDR settings.

For more details about tamper protection and its implementation, refer to the [Microsoft documentation](https://learn.microsoft.com/en-us/defender-endpoint/prevent-changes-to-security-settings-with-tamper-protection?view=o365-worldwide#what-happ

Bypassing EDR through Exclusions

Once threat actors now the current EDR landscape they can make decisions on evading the EDR. One of the simplest techniques is to add exclusions for their tools into the EDR. Adding EDR exclusions is much less invasive then fully disabling the EDR, and can often blend in with normal exclusions added by necessity. Often legitimate 3rd part software needs to be added to EDR exclusions because either it is blocked by the EDR or there is a performance impact to the system because the software constantly opens and closes many files, and the real-time protection features of EDR are constantly performing analysis when files are opened and closed. The main types of exclusions are:

Exclusions based on file name, extension and folder location
Exclusions for files opened by processes

Exclusions can be managed locally in the following ways.

Creation of a local policy
Using the Windows Security GUI
Powershell with the Cmdlet Add-MpPreference

Example using the Add-MpPreferece PowerShell Cmdlet to add an exclusion. these exclusions will Defender event ID 5007.

//Folder Exclusions
Add-MpPreference -ExclusionPath "C:\Windows\Temp"
//or
Set-MpPreference -ExclusionPath "C:\Windows\Temp"
//Exclusion based on file extension
Add-MpPreference -ExclusionExtension ".bat"
//process exclusoins
Add-MpPreference -ExclusionProcess "C:\Windows\System32\cmd.exe"

Using WMI to add exclusions.

Invoke-CimMethod -Namespace root/Microsoft/Windows/Defender -ClassName MSFT_MpPreference -MethodName Add -Arguments @{ExclusionPath=@("C:\Temp"); ThreatIDDefaultAction_Ids=@([Int64]1,[Int64]2,[Int64]3,[Int64]10); ThreatIDDefaultAction_Actions=@([Byte]1, [Byte]2, [Byte]3, [Byte]10); Force=$true}

using MpCmdRun.exe to add exclusions.

MpCmdRun.exe -AddExclusion -path "C:\Users\user\Documents\important_file.doc"

Checking for exclusions added via MpCmdRun.exe

kql
let arguments = dynamic(['ScanType 3 -File',"-CheckExclusion"]);
DeviceProcessEvents
| where FileName == "MpCmdRun.exe"
| where ProcessCommandLine has_any (arguments)
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine
| summarize Count = count(), Commands = make_set(ProcessCommandLine) by bin(TimeGenerated,1m), DeviceName
// exclude threshold or tune as per your needs
// | where Count > 1

https://www.kqlsearch.com/query/Mde-defenderexclusionsenumerations&cm22pmls201psmc0piekrkolz

Checking exclusions if you have Defender operational logs (exclusions on folder paths).

Event
| where TimeGenerated >= ago(timeframe)
| where EventLog == "Microsoft-Windows-Windows Defender/Operational"
| parse EventData with * 'New Value">'RegistryKey'</Data>' *
| where RegistryKey startswith "HKLM\\SOFTWARE\\Microsoft\\Windows Defender\\Exclusions\\Paths"
| extend ExcludedFolder = tostring(split(RegistryKey, "Paths\\")[1])
| extend ExcludedFolder = tostring(split(ExcludedFolder, "=")[0])
| project TimeGenerated, Computer, ExcludedFolder, RegistryKey

Checking exclusions if you have Defender operational logs (exclusion extensions).

Event
| where TimeGenerated >= ago(timeframe)
| where EventLog == "Microsoft-Windows-Windows Defender/Operational"
| parse EventData with * 'New Value">'RegistryKey'</Data>' *
| where RegistryKey startswith "HKLM\\SOFTWARE\\Microsoft\\Windows Defender\\Exclusions\\Extensions"
| extend ExcludedExtension = tostring(split(RegistryKey, "Extensions\\")[1])
| extend ExcludedExtension = tostring(split(ExcludedExtension, "=")[0])
| where ExcludedExtension endswith ".ps1"
  or ExcludedExtension endswith ".vbs"
  or ExcludedExtension endswith ".bat"
| project TimeGenerated, Computer, ExcludedExtension, RegistryKey

Detecting exclusions through registry events.

DeviceRegistryEvents

| where ((ActionType == "RegistryValueSet") and (RegistryKey startswith @"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows Defender\\Exclusions\\Paths"

or RegistryKey startswith @"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions\Extensions"

or RegistryKey startswith @"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions\Processes"))

https://github.com/rod-trent/SentinelKQL/blob/master/DefenderExclusions.txt

Custom Indicators - Allow actions

A unique method threat actors could exploit to bypass Defender involves abusing its built-in Indicator of Compromise (IOC) feature. This feature allows administrators to create custom IOCs in Defender, specifying actions for files, IPs, or URLs as block, alert, or allow. While this is an excellent defensive tool, a threat actor with administrative access to the Defender console could potentially exploit it by adding their malicious file, IP, or URL as an IOC and assigning it an allow action.

However, for an attacker to successfully execute this tactic, they would first need administrative access to the Defender console, underscoring the critical importance of protecting admin accounts and maintaining strict access controls.

Disabling Defender EDR Features

The following examples of disabling of Defender EDR features are taken from the article, 'Why are Windows Defender AV logs so important and how to monitor them with Azure Sentinel?': https://m365internals.com/2021/07/05/why-are-windows-defender-av-logs-so-important-and-how-to-monitor-them-with-azure-sentinel/

Removing definitions from signature engine

"C:\Program Files\Windows Defender\MpCmdRun.exe" -RemoveDefinitions -All

Disabling script scanning

Set-MpPreference -DisableScriptScanning $true

Disabling controlled folder access

Set-MpPreference -EnableControlledFolderAccess Disabled

Changing networkprotection to audit mode:

Set-MpPreference -EnableNetworkProtection AuditMode

Disable active protective services

Set-MpPreference -Force -MAPSReporting Disabled

Stopping samples from being submitted.

Set-MpPreference -SubmitSamplesConsent NeverSend

Example rule 'Windows Defender Submit Sample Feature Disabled' from detection.fyi: https://detection.fyi/sigmahq/sigma/windows/builtin/windefend/win_defender_config_change_sample_submission_consent/

Disable real-time protection

Set-MpPreference -DisableRealtimeMonitoring $true

Disable IOV scanning files and attachments

Set-MpPreference -DisableIOAVProtection $true

Changing Defender Modes

Microsoft Defender operates in several distinct modes, each serving specific purposes:

AV Active Mode: The default mode where Microsoft Defender Antivirus actively protects against threats by scanning files, detecting malicious activity, and remediating threats.
AV Disabled Mode: Microsoft Defender Antivirus is disabled, typically when another antivirus solution is in place or when it is intentionally turned off.
Passive Mode: In this mode, Microsoft Defender Antivirus scans files and reports threats but does not remediate them. This is commonly used when Microsoft Defender is not the primary antivirus or endpoint detection and response (EDR) solution.
Audit Mode: Audit mode is designed to evaluate the impact of Defender Antivirus without actually enforcing policies or blocking actions.
AV Troubleshooting Mode: Allows administrators to temporarily disable tamper protection to troubleshoot Defender Antivirus features, even if devices are managed by organizational policies. This mode is particularly useful for making changes that would otherwise be blocked. More details about troubleshooting mode can be found here.
EDR Block Mode: Even if Microsoft Defender Antivirus is not the primary antivirus solution, this mode ensures that detected threats are blocked and remediated, leveraging Defender’s endpoint detection and response capabilities.

Defender Modes Special Considerations

Troubleshooting Mode: Critical for diagnosing and resolving issues with Defender features. It provides temporary flexibility for admins to adjust settings that are otherwise restricted by tamper protection. More information about troubleshooting mode can be found here: https://jeffreyappel.nl/microsoft-defender-for-endpoint-troubleshooting-mode-how-to-use-it/

KQL query to find devices where Defender is in troubleshooting mode.

search in (DeviceEvents)  
ActionType == "AntivirusTroubleshootModeEvent"  
| extend _tsmodeproperties = parse_json(AdditionalFields)  
| where Timestamp > ago(3h)    |where _tsmodeproperties.TroubleshootingStateChangeReason == "Troubleshooting mode started" |summarize (Timestamp, ReportId)=arg_max(Timestamp, ReportId), count() by DeviceId

EDR Killers/Silencers

Using the Windows firewall to disable EDR

A notable technique involves leveraging the Windows Host Firewall to block EDR agents from transmitting telemetry or functioning effectively. This method is exemplified by tools like EDR Silencer: https://github.com/netero1010/EDRSilencer and further detailed in a Huntress blog post https://www.huntress.com/blog/silencing-the-edr-silencers?utm_source=substack&utm_medium=email. This approach highlights how threat actors can manipulate native system features to neutralize endpoint detection capabilities, emphasizing the importance of monitoring firewall configurations and ensuring proper safeguards are in place.

Disabling Event Tracing

Endpoint Detection and Response (EDR) products often leverage Event Tracing for Windows (ETW) as a critical detection mechanism because ETW provides a high-performance, low-overhead way to capture and analyze detailed system events. ETW provides real-time, granular telemetry about system behavior, including:

Process creation and termination
Thread activity
Registry access
File I/O operations
Network activity

EDR products use these event streams to monitor system activities continuously and detect potentially malicious behaviors and sophisticated attack techniques like:

Process injection
File tampering
Anomalous registry modifications.
Living-off-the-land (LotL) attacks: Monitoring benign tools like PowerShell or WMI when used maliciously.
Memory-only malware: Tracking malicious activity that doesn't leave a disk footprint by observing ETW events related to memory operations.
Credential dumping: Detecting suspicious access to LSASS.exe or SAM registry hives.

As a result, ETW evasion has become a popular tactic among advanced attackers aiming to bypass EDRs. By disabling ETW providers or tampering with ETW data, attackers can effectively evade detection.

One such method leverages a built-in Windows tool called logman.exe, which can be used to disable ETW providers. This technique is also documented in the Living Off the Land (LOTL) project: https://lofl-project.github.io/. For more details on how attackers exploit ETW evasion and its impact on detection and response, refer to this SOC Investigation article: https://www.socinvestigation.com/the-flow-of-event-telemetry-blocking-detection-response/

Detecting usage of in Sentinel Logman.exe to manipulate ETW logging.

SecurityEvent 
| where EventID == 4688 
| where (((NewProcessName endswith @'\logman.exe') and (CommandLine contains 'query' or CommandLine contains 'update' or CommandLine contains 'EventLog')) or (NewProcessName endswith @'\powershell.exe' and (CommandLine contains 'Remove-EtwTraceProvider' or CommandLine contains 'AutologgerName' or CommandLine contains 'EventLog' or CommandLine contains 'Set-EtwTraceProvider' or CommandLine contains 'Property')) or NewProcessName endswith @'\wpr.exe')

Disabling event Tracing registry change

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Windows Defender/Operational" /v Enabled /t Reg_DWORD /d 0 /f

EDRKillShifter

The tool employs an EDR bypass technique known as "Bring Your Own Vulnerable Driver" (BYOVD). This approach uses a loader executable to deliver a legitimate but vulnerable driver, which can then be exploited to bypass security mechanisms.

EDR Kill Shifter Detection

let DriverwithLowPrevalence = DeviceFileEvents
| where ActionType == "FileCreated"
| where FileName endswith ".sys"
| invoke FileProfile(SHA1,10000)
| where GlobalPrevalence <= 150
| invoke FileProfile(SHA1,1000)
| where GlobalPrevalence <= 150 or isempty(GlobalPrevalence)
| join kind=leftouter DeviceFileCertificateInfo on SHA1
| project FileName;
let DevicewithLPDriverActivated = DeviceEvents
// Event ID 3004 — Kernel-mode Driver Validation
| where ReportId == "3004"
| where ActionType == @"DriverLoad"
| where FileName has_any(DriverwithLowPrevalence)
| distinct DeviceName;
DeviceEvents
//| where ReportId == "5013"
| where ActionType == @"TamperingAttempt"
| where DeviceName has_any(DevicewithLPDriverActivated)

https://www.kqlsearch.com/query/Detecting%20Edr-killing%20Tool&cm0hwgr8v00okmc0p4ahlvq8f

Loading of other suspicious drivers - EDRSandblast

DeviceEvents
| where ActionType == "DriverLoad"
| where FileName has_any("WN_64.sys", "wnbios.sys")

https://www.kqlsearch.com/query/Edrsandblast&cm335iavb02d1mc0pn0n1t9wo

Overall Defender health

An interesting data table in Microsoft Defender that helps determine the status of Defender is DeviceTvmInfoGathering, which stands for Table Vulnerability Management. This table contains vulnerability information about devices related to attack surface reduction rules and, by extension, the status of EDR. More information about querying the DeviceTvmInfoGathering table to assess Defender's EDR status and operation can be found here: