EDRSandblast v1.1 releases: bypass EDR detections and LSASS protections
EDRSandBlast
EDRSandBlast is a tool written in C that weaponizes a vulnerable signed driver to bypass EDR detections (Kernel callbacks and ETW TI provider) and LSASS protections. Multiple userland unhooking techniques are also implemented to evade userland monitoring.
As of release, a combination of userland (–usermode) and Kernel-land (–kernelmode) techniques were used to dump LSASS memory under EDR scrutiny, without being blocked nor generating “OS Credential Dumping”-related events in the product (cloud) console. The tests were performed on 3 distinct EDR products and were successful in each case.
EDR bypass through Kernel callbacks removal
EDR products use Kernel callbacks on Windows to be notified by the kernel of system activity, such as process and thread creation and loading of images (exe / DLL).
The Kernel callbacks are defined from user-land using a number of documented APIs (nt!PsSetCreateProcessNotifyRoutine, nt!PsSetCreateThreadNotifyRoutine, etc.). The user-land APIs add driver-supplied callback routines to undocumented arrays of routines in Kernel-space:
- PspCreateProcessNotifyRoutine for process creation
- PspCreateThreadNotifyRoutine for thread creation
- PspLoadImageNotifyRoutine for image loading
EDRSandBlast enumerates the routines defined in those arrays and remove any callback routine linked to a predefined list of EDR drivers (more than 1000 thousands drivers of security products from the allocated filter altitudes). The enumeration and removal are made possible through the exploitation of an arbitrary Kernel memory read / write vulnerability of the Micro-Star MSI Afterburner driver (CVE-2019-16098). The enumeration and removal code is largely inspired from br-sn’s CheekyBlinder project.
The offsets of the aforementioned arrays are hardcoded in the NtoskrnlOffsets.csv file for more than 350 versions of the Windows Kernel ntoskrnl.exe. The choice of going with hardcoded offsets instead of pattern searches is justified by the fact that the undocumented APIs responsible for Kernel callbacks addition / removal are subject to change and that any attempt to write Kernel memory at the wrong address may (and often will) result in a Bug Check (Blue Screen of Death). For more information on how the offsets were gathered, refer to Offsets section.
EDR bypass through deactivation of the ETW Microsoft-Windows-Threat-Intelligence provider
The ETW Microsoft-Windows-Threat-Intelligence provider log data about the usages of some Windows API commonly used maliciously. This includes the nt!MiReadWriteVirtualMemory API, called by nt!NtReadVirtualMemory (which is used to dump LSASS memory) and monitored by the nt!EtwTiLogReadWriteVm function.
EDR products can consume the logs produced by the ETW TI provider through services or processes running as, respectively, SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT or PS_PROTECTED_ANTIMALWARE_LIGHT, and associated with an Early Launch Anti Malware (ELAM) driver.
As published by slaeryan in a CNO Development Labs blog post, the ETW TI provider can be disabled altogether by patching, in kernel memory, its ProviderEnableInfo attribute to 0x0. Refer to the great aforementioned blog post for more information on the technique.
Similar to the Kernel callbacks removal, the necessary ntoskrnl.exe offsets (nt!EtwThreatIntProvRegHandleOffset, _ETW_REG_ENTRY’s GuidEntry, and _ETW_GUID_ENTRY’s ProviderEnableInfo) are hardcoded in the NtoskrnlOffsets.csv file a number of the Windows Kernel versions.
