Authenticate your profile to see activity

Blinded by Silence

Blinded by Silence: How Attackers Disable EDR

Overview

Endpoint Detection and Response systems (EDRs) are an essential part of modern cybersecurity strategies. EDR solutions gather and analyze data from endpoints to identify suspicious activities and provide real-time threat visibility. This allows security teams to respond quickly to incidents, investigate threats thoroughly, and mitigate the impact of potential breaches.

When attackers manage to disable or block EDR systems using tools like EDRSilencer or NimBlackout, it poses serious challenges to defenders. One major consequence is the loss of visibility into endpoint activities, which compromises the ability of cybersecurity teams to detect and respond to threats effectively. This diminished visibility can result in delayed detection of breaches, giving attackers more time to exfiltrate data or cause damage. Moreover, without the continuous monitoring and real-time alerts that EDRs provide, defenders are left with a reactive approach, often discovering incidents only after significant harm has been done. The ability of EDRs to facilitate immediate responses, such as isolating affected systems and stopping malicious processes, is also neutralized when these tools are blocked, leaving organizations more vulnerable to ongoing attacks. In such scenarios, the risk of prolonged, undetected breaches increases, complicating the efforts of defenders and escalating the potential damage to the organization’s security posture.

This blog isn’t going to cover every EDR based tool in an attackers arsenal, but there are some common ones that have been observed recently. Attackers and Defenders are in a constant game of cat and mouse when it comes to tools and techniques. Fortunately, with these techniques there are some common indicators that can still be detected irregardless of the tool used.

Tools

Here are the tools we will be taking a look at. Many of these have been observed in use in the wild.

EDRSilencer — Inspired by the closed source FireBlock tool FireBlock from MdSec NightHawk, this tool was created with the aim of blocking the outbound traffic of running EDR processes using Windows Filtering Platform (WFP) APIs.

EDRSandBlast — Written in C. It weaponizes a vulnerable signed driver to bypass EDR detections (Notify Routine callbacks, Object Callbacks and ETW TI provider) and LSASS protections. Multiple userland unhooking techniques are also implemented to evade userland monitoring.

NimBlackout — An adaptation of the @Blackout project which consists of removing AV/EDRs using the gmer (BYOVD) driver.

AuKill — The AuKill tool abuses an outdated version of the driver used by version 16.32 of the Microsoft utility, Process Explorer, to disable EDR processes before deploying either a backdoor or ransomware on the target system.

EDRSilencer

The main features of this tool is searching for running EDR processes and applying Windows Filtering Platform (WFP) filters to block outbound traffic, adding filters for specific processes, and removing filters either individually or globally. The tool includes a custom implementation to avoid file handle access issues with EDR processes by bypassing the CreateFileW API. It supports a wide range of EDRs, including Microsoft Defender, Carbon Black, SentinelOne, and more.

By creating custom WFP filters, attackers can selectively intercept and drop network packets sent by EDR processes, effectively preventing them from communicating with their management servers or security dashboards. This disruption stops the EDR from sending telemetry data, alerts, or incident logs, thereby silencing its ability to notify defenders of suspicious or malicious activities occurring on the endpoints. Such interference can be stealthy, as it can be crafted to target only specific processes or traffic patterns associated with the EDR, ensuring other legitimate network operations remain unaffected. By exploiting WFP in this manner, attackers can maintain prolonged access to a compromised system without detection, allowing them to escalate their attacks, exfiltrate data, or cause further damage without triggering the EDR’s defensive mechanisms.

Fortunately, there are a few pieces of telemetry that sneak through before the EDR is silenced. One such piece is Windows Event 5447 which identifies when a WFP filter has been changed. In the case of EDRSilencer there is a very specific filter that is added.

Action: %%16389
ActivityID: "9F3364FE-E417-0002-2065-339F17E4DA01"
CalloutKey: 00000000-0000-0000-0000-000000000000
CalloutName: -
ChangeType: %%16384
Channel: Security
Conditions: Condition ID: {d78e1e87-8644-4ea5-9437-d809ecefc971}
Match value: Equal to
Condition value:
00000000 5c 00 64 00 65 00 76 00-69 00 63 00 65 00 5c 00 \.d.e.v.i.c.e.\.
00000010 68 00 61 00 72 00 64 00-64 00 69 00 73 00 6b 00 h.a.r.d.d.i.s.k.
00000020 76 00 6f 00 6c 00 75 00-6d 00 65 00 31 00 5c 00 v.o.l.u.m.e.1.\.
00000030 70 00 72 00 6f 00 67 00-72 00 61 00 6d 00 64 00 p.r.o.g.r.a.m.d.
00000040 61 00 74 00 61 00 5c 00-6d 00 69 00 63 00 72 00 a.t.a.\.m.i.c.r.
00000050 6f 00 73 00 6f 00 66 00-74 00 5c 00 77 00 69 00 o.s.o.f.t.\.w.i.
00000060 6e 00 64 00 6f 00 77 00-73 00 20 00 64 00 65 00 n.d.o.w.s. .d.e.
00000070 66 00 65 00 6e 00 64 00-65 00 72 00 5c 00 70 00 f.e.n.d.e.r.\.p.
00000080 6c 00 61 00 74 00 66 00-6f 00 72 00 6d 00 5c 00 l.a.t.f.o.r.m.\.
00000090 34 00 2e 00 31 00 38 00-2e 00 32 00 34 00 30 00 4...1.8...2.4.0.
000000a0 36 00 30 00 2e 00 37 00-2d 00 30 00 5c 00 6d 00 6.0...7.-.0.\.m.
000000b0 73 00 6d 00 70 00 65 00-6e 00 67 00 2e 00 65 00 s.m.p.e.n.g...e.
000000c0 78 00 65 00 00 00 x.e...
Error_Code: -
EventID: 5447
EventRecordID: 763263
FilterId: 67700
FilterKey: 795B7AA5-86D4-4383-BD45-FA5FE4AA7509
FilterName: Custom Outbound Filter
FilterType: %%16387
Keywords: 0x8020000000000000
LayerId: 48
LayerKey: C38D57D1-05A7-4C33-904F-7FBCEEE60E82
LayerName: ALE Connect v4 Layer
Level: 0
...

EDRSilencer by default will create its filters with the FilterName of “Custom Outbound Filter”. You can also see the process being filtered in the Condition Value, in this case msmpeng.exe (Defender).

Another detection opportunity is the command line arguments and process information from when the tool is launched. It is pretty unusual for a benign process to have a argument called blockedr.

...
Caller_Domain: WIN10-21H1
Caller_User_Name: localuser
Channel: Security
CommandLine: EDRSilencer.exe blockedr
EventID: 4688
NewProcessName: C:\Users\localuser\Desktop\EDRSilencer.exe
Opcode: 0
ParentProcessName: C:\Windows\System32\cmd.exe
ProcessID: "4"
ProcessId: 10416
Process_Command_Line: EDRSilencer.exe blockedr
TokenElevationType: %%1936
...

For more logs, details, and detections, we have captured this activity in our platform here.

EDRSandBlast

This tool can also use WFP to block communication of EDRs. It will enumerate EDRs and create filters for every service and process of the EDR.

This will create very similar logs as EDRSilencer in Windows Event 5447 but on a larger scale since it will do it for every subprocess of the EDR. However, since it is enumerating the EDR services it will access the EDR process in a way that is logged. In Sysmon this will be EventCode 10.

CallTrace: C:\Windows\SYSTEM32\ntdll.dll+9d234|C:\Windows\System32\KERNELBASE.dll+2c0fe|C:\Users\localuser\EDRSandblast.exe+5eb1f|C:\Users\localuser\EDRSandblast.exe+5fb11|C:\Users\localuser\EDRSandblast.exe+5b106|C:\Users\localuser\EDRSandblast.exe+74c68|C:\Windows\System32\KERNEL32.DLL+17034|C:\Windows\SYSTEM32\ntdll.dll+52651
Channel: Microsoft-Windows-Sysmon/Operational
EventCode: 10
EventDescription: ProcessAccess
EventID: 10
EventRecordID: 1589884
GrantedAccess: 0x1000
ProcessID: "3452"
ProcessId: 1424
ProcessName: EDRSandblast.exe
ProcessPath: C:\Users\localuser\
SourceImage: C:\Users\localuser\EDRSandblast.exe
SourceProcessGUID: F51F9151-1307-6729-E915-000000000D00
SourceProcessId: 1424
SourceThreadId: 2064
SourceUser: WIN10-21H1\localuser
SystemTime: '2024-11-04T18:31:36.252633Z'
TargetImage: C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24090.11-0\MsMpEng.exe
TargetProcessGUID: F51F9151-10B7-6729-0303-000000000D00
TargetProcessId: 6424
TargetUser: NT AUTHORITY\SYSTEM
...

In addition to the methods of detection mentioned, you can also identify these WFP Filters through the registry. They will create an entry under HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules\{GUID} as seen here.

Channel: Microsoft-Windows-Sysmon/Operational
Details: v2.30|Action=Block|Active=TRUE|Dir=In|App=C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24090.11-0\MsMpEng.exe|Name=wYLqwn43kCmugxYqisuL|Desc=wYLqwn43kCmugxYqisuL|
EventCode: 13
EventDescription: RegistryEvent (Value Set)
EventType: SetValue
Image: C:\Windows\system32\svchost.exe
ProcessGuid: F51F9151-1EDC-6733-2300-000000000F00
SystemTime: '2024-11-12T14:50:37.718504Z'
TargetObject: HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules\{19876A6F-6871-4C48-A9EB-B1FFF949759C}
...

For more logs, details, and detections, we have captured this activity in our platform here.

EDRSandBlast also has a technique to perform LSASS dumping without triggering Credential Dumping activity alerts. EDRSandBlast enumerates the Kernel “Notify Routines” callbacks and remove any callback routine linked to a predefined list of EDR drivers (more than 1000 drivers of security products supported, see the EDR driver detection section. The enumeration and removal are made possible through the exploitation of an arbitrary Kernel memory read / write primitive provided by the exploitation of a vulnerable driver (see Vulnerable drivers section).

Here we can see the tool creating the malicious service and loading the vulnerable driver.

Afterwards it uses this driver to remove those callback routines and make the process safe. Then lsass.exe is access and dumped to the current directory. Once done the service and driver are removed.

These activities will still create some logs despite the efforts of the tool to hide activity. The first we can look at is the service creation for the kernel driver (Windows Event 7045)

Channel: System
EventCode: 7045
EventRecordID: 6244
EventSourceName: "Service Control Manager"
ImagePath: C:\Users\localuser\gdrv.sys
Keywords: 0x8080000000000000
Level: 4
Name: "Service Control Manager"
Opcode: 0
ProcessID: "720"
ProcessId: 720
Qualifiers: "16384"
RecordNumber: 6244
ServiceName: bx92yOn6
ServiceType: kernel mode driver
SigmaEventCode: 7045
StartType: auto start
SystemTime: '2024-11-04T18:27:21.800918Z'
Task: 0
ThreadID: "4852"
UserID: "S-1-5-21-1538153195-943065003-848949206-1000"
Version: 0
dest: WIN10-21H1.snapattack.labs
...

Here we can see the driver being loaded from an unusual location (C:\Users\localuser\gdrv.sys) as a kernel mode driver with a start type of auto start. The combination of auto start with kernel mode should be investigated but adding in a known vulnerable driver really makes this stand out. This technique is commonly referred to as a "bring your own vulnerable driver" (BYOVD) attack. The LOLDrivers project contains a massive list of information about these known drivers including names and hashes.

For more logs, details, and detections, we have captured this activity in our platform here.

Blackout/NimBlackout

These tools leverage a different driver, gmer, to effectively disable or kill EDRs and Antiviruses. It uses a very similar approach to EDRSandBlast by loading a kernel mode driver and then exploiting the vulnerable driver to accomplish something it normally wouldn’t have permission to. In the particular case of this tool, it will repeatedly terminate the specified process over and over. Likely targets for this are EDR and AntiVirus products.

If you have telemetry for registry activity you can actually see the service creation keys as well with EventCode 13. These tools will both use the Blackout.sys driver as the ImagePath.

Channel: Microsoft-Windows-Sysmon/Operational
Details: \??\C:\Users\Public\Blackout.sys
EventCode: 13
EventDescription: RegistryEvent (Value Set)
EventRecordID: 26269
EventType: SetValue
Image: C:\Windows\system32\services.exe
Keywords: 0x8000000000000000
ProcessName: services.exe
ProcessPath: C:\Windows\system32\
SystemTime: '2023-07-11T17:46:23.006634Z'
TargetObject: HKLM\System\CurrentControlSet\Services\NimBlackout\ImagePath
User: NT AUTHORITY\SYSTEM
UserID: "S-1-5-18"
action: modified
user: SYSTEM
user_id: "S-1-5-18"
vendor_product: Microsoft Sysmon
...

If you have telemetry for Windows Events you can monitor for termination of your EDR Processes. This is Event Id 4689, and here we can see the Defender process from our execution being killed.

EventCode: 4689
Logon_ID: 0x3e7
Name: "Microsoft-Windows-Security-Auditing"
ProcessID: "4"
ProcessId: 8624
ProcessName: C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.23050.5-0\MsMpEng.exe
Status: 0x0
SubjectDomainName: SNAPATTACK
SubjectLogonId: 0x3e7
SubjectUserName: QUADRA$
SubjectUserSid: S-1-5-18
SystemTime: '2023-07-11T17:46:24.779760Z'
Task: 13313
ThreadID: "9060"
name: A process has exited
status: success
subject: A process has exited
...

For more logs, details, and detections, we have captured this activity in our platform here.

Threat Actor Tools — AuKill

While all the tools covered so far have been open source tools, or educational experiments, these techniques are being actively used by threat actors. One such example is a tool dubbed AuKill by Sophos discussed here. However, this tool uses many of the techniques covered in this blog and includes many of the same detection opportunities.

The AuKill tool abuses an outdated version of the driver used by version 16.32 of the Microsoft utility, Process Explorer, to disable EDR processes before deploying either a backdoor or ransomware on the target system.

The method of abusing the Process Explorer driver to bypass EDR systems isn’t new; it was implemented in many open-source tools. AuKill possibly uses multiple code snippets from, and built their malware around, the core technique introduced by Backstab. AuKill drops a driver named PROCEXP.SYS (from the release version 16.32 of process Explorer) into the C:\Windows\System32\drivers path. The legitimate Process Explorer driver is named PROCEXP152.sys, and normally is found in the same location. Both drivers can be present on a machine that has a copy of Process Explorer running. The AuKill installer also drops an executable copy of itself to either the System32 or the TEMP directory, which it runs as a service as seen below.

EventCode: 4697
ProcessId: 660
ServiceAccount: LocalSystem
ServiceFileName: C:\Windows\system32\auSophos.exe
ServiceName: auSophos
ServiceStartType: 2
ServiceType: 0x10
SubjectDomainName: SNAPATTACK
SubjectLogonId: 0x3e7
SubjectUserName: MSEDGEWIN10$
SubjectUserSid: S-1-5-18
SystemTime: '2023-04-26 15:25:24.920066 UTC'
action: success
name: A service was installed in the system
product: Windows
service: auSophos
service_name: auSophos
sigma_product: windows
sigma_service: security
start_mode: auto
status: started

Another interesting thing that this tool does that we hadn’t seen in many of the open source tools was disabling the Windows Update Service. This can be seen in a registry key change.

Details: DWORD (0x00000004)
EventCode: 13
EventDescription: RegistryEvent (Value Set)
EventType: SetValue
Image: C:\Windows\system32\services.exe
ProcessId: 636
ProcessName: services.exe
ProcessPath: C:\Windows\system32\
SystemTime: '2023-04-26 15:25:43.001866 UTC'
TargetObject: HKLM\System\CurrentControlSet\Services\wuauserv\Start
Task: 13
User: NT AUTHORITY\SYSTEM
UserID: "S-1-5-18"
action: modified
...

This value change disables the automatic starting of the update service. This can prevent future security updates that might mess with an attacker’s access.

For more logs, details, and detections, we have captured this activity in our platform here.

MITRE

T1562.001: Impair Defenses: Disable or Modify Tools
Adversaries may modify and/or disable security tools to avoid possible detection of their malware/tools and activities

T1562.004: Impair Defenses: Disable or Modify System Network Configurations
Adversaries may disable or modify system firewalls in order to bypass controls limiting network usage.

T1569: System Services
Adversaries may abuse system services or daemons to execute commands or programs.

T1112: Modify Registry
Adversaries may interact with the Windows Registry to hide configuration information within Registry keys, remove information as part of cleaning up, or as part of other techniques to aid in persistence and execution.

Conclusion

The tools and techniques used by attackers to bypass or disable EDRs underscore the continuous and evolving struggle between cybersecurity defenses and adversarial tactics. By exploiting legitimate system features, such as the Windows Filtering Platform, attackers can effectively neutralize critical EDR functions, creating blind spots. However, defenders are not without recourse. While these tools aim to obscure their activities, certain logs and registry modifications still offer valuable indicators of compromise. Monitoring for these signals — like specific WFP filters, unusual process behaviors, or suspicious service creations — can help defenders detect these evasive tactics. Having a strong detection workflow is paramount to catch these sorts of attacks, especially when they are attacking the EDRs themselves.

SnapAttack is the threat hunting, detection engineering, and detection validation platform for proactive threat-informed defense. Register for a FREE community account to access the tons of content included in this blog post, as well as thousands of other detections. Subscribers also get advanced features like a no-code detection builder, one-click deployments to leading SIEMs and EDRs like Chronicle, Sentinel, Splunk, CrowdStrike and SentinelOne, advanced threat profiles to prioritize relevant threats, and customized reports that track MITRE ATT&CK coverage and more!

Resources

Blinded by Silence was originally published in SnapAttack on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Blinded by Silence appeared first on Security Boulevard.

14 November 2024

>>More