All kill Zero Fill — Anatomy of EDR Killers

The evolution of Antivirus (AV) technologies began in the early 1980s with signature-based detection, where AVs identified malware by matching specific byte patterns (signatures) against a database of known threats. While effective against early, less sophisticated viruses, this approach was inherently reactive. Every new threat required an updated signature, leaving systems vulnerable to unknown or rapidly evolving malware.

To counteract these limitations, heuristic-based detection emerged in the 1990s. Heuristics allowed AVs to detect previously unseen malware by analyzing suspicious behavior, such as self-replication or modifying system files. While this was a step forward, it came with challenges like high false-positive rates and difficulty in distinguishing malicious actions from legitimate ones. Meanwhile, malware authors developed techniques like polymorphism and metamorphism to evade both signature and heuristic detection.

By the 2000s, AV technologies began to incorporate behavioral analysis to monitor real-time actions of programs, identifying potentially malicious activities such as unauthorized file modifications or abnormal network behavior. This period also saw the introduction of machine learning (ML) techniques, which allowed AVs to detect new threats by training on large datasets of both benign and malicious files. While ML enhanced detection accuracy, it demanded significant computational resources and high-quality data to reduce false positives and negatives.

However, as malware became more sophisticated, exploiting legitimate tools and operating system features, traditional AV solutions struggled to keep pace. This gap led to the development of Endpoint Detection and Response (EDR) solutions. Unlike AVs, which focused primarily on prevention, EDR aimed to detect, investigate, and respond to threats that bypassed initial defenses. EDR provided comprehensive endpoint visibility, collecting detailed telemetry data — such as process execution, file changes, and network connections — for real-time and historical analysis.

Modern EDR solutions are characterized by continuous monitoring and visibility, allowing them to detect suspicious activities across all endpoints. They leverage advanced analytics and threat hunting capabilities, combining ML, behavioral analysis, and threat intelligence to identify and mitigate threats proactively. EDRs also feature automated response and remediation mechanisms, such as isolating compromised endpoints or rolling back changes made by ransomware, thereby reducing response times and minimizing damage.

Today, EDR has evolved into Extended Detection and Response (XDR), which integrates data across multiple security layers, including endpoints, networks, emails, and cloud environments. This unified approach enhances threat detection, speeds up response times, and breaks down the silos between different security tools, providing a more comprehensive defense strategy.

The transition from AV to EDR, and now to XDR, reflects the constant evolution required to stay ahead of increasingly sophisticated cyber threats. From static signatures to dynamic, AI-driven detection and response mechanisms, this journey highlights the adaptive nature of cybersecurity. As attackers continue to innovate, so must defenders, leveraging cutting-edge technologies to protect against the ever-growing array of digital threats. The future of cybersecurity will likely see further advancements in AI, predictive analysis, and automated threat hunting, ensuring that defenses remain as intelligent and dynamic as the threats they counter.

As technology has evolved, so has the attack surface — expanding far beyond traditional endpoints like desktops and servers. Today, it encompasses a wide range of devices, including mobile phones, IoT devices, cloud environments, and even virtual machines. This expansion has dramatically increased the complexity of defending networks and systems, requiring more sophisticated tools and strategies to detect and respond to threats. Enter the state-of-the-art Endpoint Detection and Response (EDR) solutions, designed to provide comprehensive visibility and real-time threat detection across all these platforms.

However, as defenders have adapted, so have attackers. The rise of EDR killers represents a new and dangerous frontier in the ongoing cybersecurity arms race. EDR killers are advanced malware or techniques specifically engineered to evade, disable, or manipulate EDR systems. Unlike traditional malware, which focused on avoiding detection by basic antivirus tools, these new threats target the very core of modern endpoint security solutions.

How EDR Killers Exploit the Modern Attack Surface

Today’s attack surface is not only larger but also more interconnected and dynamic, creating opportunities for attackers to leverage multiple vectors simultaneously. EDR killers exploit this by utilizing several tactics:

1. Living off the Land (LotL) Techniques: Attackers increasingly use legitimate tools and scripts (like PowerShell or WMI) that are already present on the target systems to carry out malicious actions. Since these tools are whitelisted and trusted by many EDRs, malicious activity can appear benign, bypassing detection mechanisms that focus on identifying traditional malware behaviors.
2. Memory Manipulation and Fileless Attacks: Advanced EDR killers operate in memory without writing files to disk, making them harder to detect using conventional file-based scanning methods. They can inject malicious code directly into the memory space of legitimate processes, manipulate trusted processes, or use techniques like process hollowing and reflective DLL injection to hide their activities.
3. Disabling or Tampering with EDR Agents: Some EDR killers are designed to directly target the EDR agents themselves, disabling or modifying them to prevent detection. These tools use various methods, such as killing EDR processes, tampering with agent configurations, or exploiting vulnerabilities in the EDR software to render it ineffective.
4. Adversarial Machine Learning: In an arms race against machine learning-based detection, attackers are employing adversarial techniques to poison ML models or to create samples that specifically evade detection. By understanding the decision boundaries of ML models, attackers craft inputs that look benign to the model but are actually malicious, effectively bypassing detection.

Deep Dive into Evasion Techniques and EDR Killing

Evasion and EDR Killing: Advanced Techniques in Action

Modern attackers are increasingly deploying evasion techniques specifically designed to bypass or neutralize Endpoint Detection and Response (EDR) solutions. These techniques focus on exploiting the limitations and weaknesses in EDR mechanisms to remain undetected or disable the EDR agents entirely. Unlike traditional malware that might avoid detection by simply hiding files or processes, EDR killers engage in more sophisticated actions:

1. Code Injection and Process Hollowing: Attackers inject malicious code into legitimate processes to “hollow out” the legitimate code and replace it with their own. This technique leverages the trust placed in system processes by the EDR solution. For example, malware may inject code into trusted processes like explorer.exe or svchost.exe, masking its activity under the guise of legitimate applications.
2. Direct System Call Execution: To avoid detection by hooking mechanisms used by EDRs, some malware directly executes system calls using techniques like Heaven’s Gate or syscall obfuscation. This bypasses the user-mode hooks that EDRs typically rely on to monitor system activity, allowing malicious actions to proceed without alerting the EDR.
3. Reflective Loading and In-Memory Execution: EDR killers may use reflective DLL injection or in-memory execution techniques to run malicious code without touching the disk. This approach avoids file-based detection entirely, exploiting gaps in memory scanning capabilities and making it harder for EDR solutions to trace the origin of the malicious code.
4. EDR Process and Service Termination: Advanced EDR killers can enumerate running processes, identify EDR-related services, and terminate or suspend them using API calls, like TerminateProcess() or SuspendThread(). Some malware variants may use PowerShell scripts or native APIs to tamper with EDR configurations, corrupt their databases, or manipulate memory to deactivate or degrade EDR capabilities.

Legitimate Driver Abuse: Subverting Trust Models

One of the most insidious techniques used by modern attackers is legitimate driver abuse. Kernel-mode drivers run with high privileges and are often trusted implicitly by the operating system and security software. Attackers exploit this trust by abusing legitimate drivers to bypass EDR protections:

1. Loading Vulnerable Drivers: Attackers often exploit signed but vulnerable drivers, such as those that are improperly validated by security vendors or not monitored effectively by EDR solutions. By loading these drivers, attackers can gain privileged access to the system, allowing them to directly manipulate kernel structures, disable security mechanisms, or hide processes and files from user-mode detection.
2. Bring Your Own Vulnerable Driver (BYOVD): In a BYOVD attack, an attacker deliberately installs a driver with known vulnerabilities onto the target machine. The vulnerable driver is then exploited to execute malicious code at a high privilege level, circumventing EDR protections. For instance, a driver with a flaw that allows arbitrary memory writes could be abused to overwrite EDR kernel hooks or modify the EDR’s own memory structures to disable it.
3. Direct Access to Physical Memory: Some legitimate drivers provide low-level access to physical memory (DMA), which can be abused by attackers to read or write arbitrary memory locations, including the memory space used by EDR agents. This allows attackers to tamper with the EDR without triggering its defenses, effectively rendering it blind to ongoing malicious activities.

Abuse of Leaked Code Signing Certificates: Exploiting Trust Chains

A code signing certificate is a digital certificate issued by a trusted Certificate Authority (CA) to verify the authenticity and integrity of software. When a developer signs their software with a code signing certificate, it ensures that the code has not been tampered with or altered since it was signed. The certificate uses cryptographic techniques to create a digital signature, which users or systems can verify against the public key of the issuing CA. This mechanism establishes trust between the software vendor and the end-user, as well as between the software and any security tools (such as EDR or antivirus solutions) that might evaluate its authenticity.

Code signing certificates are primarily used for:

1. Verifying Software Authenticity: When users download software, they can check its digital signature to confirm that it was signed by a trusted developer and hasn’t been modified by a third party.
2. Preventing Tampering: Code signing ensures that any alteration to the software after it was signed will invalidate the signature, raising an alert to users and security tools.
3. Establishing Trust: Many operating systems and security tools have built-in trust models that favor digitally signed software, allowing it to execute without triggering warnings or requiring additional user permissions.

Attackers also leverage leaked or stolen code-signing certificates to sign their malicious binaries, enabling them to bypass both traditional AV and EDR defenses that rely on the integrity and reputation of signed code. Code-signing certificates are issued by trusted Certificate Authorities (CAs) and are meant to verify the authenticity of software. When these certificates are compromised, they can be used to sign malware, granting it the appearance of legitimacy.

1. Signing Malicious Executables: Attackers use leaked certificates to sign malicious executables or drivers, making them appear as legitimate, trusted software. Many EDR solutions, especially those that use trust-based models, will implicitly trust signed binaries, leading to reduced scrutiny and relaxed detection thresholds. This allows attackers to execute their payloads without triggering alerts or being quarantined.
2. Certificate Reuse and Deception: Some attackers use expired or revoked certificates that are not properly checked by EDR solutions due to gaps in certificate validation routines. Malware may also use certificates from defunct or obscure vendors, which might not be blacklisted by default in many EDR configurations, allowing them to pass as legitimate.
3. Dual-Use Software and Supply Chain Attacks: By signing malware with certificates associated with legitimate software vendors, attackers can exploit the inherent trust in software supply chains. For example, signed binaries are often whitelisted in corporate environments to ensure smooth operation, enabling attackers to deploy malware without raising immediate suspicion. This technique has been used in high-profile supply chain attacks, where malicious updates are signed with a legitimate vendor’s certificate.

Understanding AuKill: A Deep Dive into a Sophisticated EDR Killer

What is AuKill and Its Relation to Evasion Techniques?

AuKill is a sophisticated malware tool classified as an EDR killer. It’s specifically designed to disable or bypass Endpoint Detection and Response (EDR) solutions on infected systems. AuKill is particularly dangerous because it leverages legitimate driver abuse, a technique we discussed earlier, to gain kernel-level access and neutralize security software. This approach directly aligns with the tactics of evasion, legitimate driver abuse, and exploitation of code-signing certificates.

First Appearance and Country of Origin

First Seen: AuKill was first observed in the wild in early 2023.

Country of Origin: The exact country of origin is unclear. However, its deployment has been linked to several financially motivated cybercrime groups, such as Medusa Locker and Royal Ransomware, suggesting that it is likely used by multiple groups with different geographies.

How AuKill Works and Targeted Security Vendors

AuKill operates by exploiting a vulnerable but legitimate Windows driver to perform its actions. The malware abuses a technique known as Bring Your Own Vulnerable Driver (BYOVD), where it loads a driver with known vulnerabilities into the Windows kernel. Once loaded, AuKill uses these vulnerabilities to escalate its privileges and kill the EDR processes. This approach enables the malware to bypass user-mode security protections, such as those implemented by EDR solutions.

Targeted Security Vendors:

AuKill has been observed targeting several well-known EDR and antivirus vendors, including:

• Microsoft Defender for Endpoint
• CrowdStrike Falcon
• SentinelOne
• Sophos Intercept X
• Carbon Black
• Trend Micro Apex One

These security solutions are often deployed by organizations to protect against advanced threats, and AuKill specifically targets them to neutralize endpoint defenses before executing its primary payloads, such as ransomware or other malware.

AuKill’s Modus Operandi: A Technical Breakdown

Initial Access and Execution: AuKill is typically deployed in a later stage of an attack chain, often by threat actors who have already gained initial access to the target system. This initial access could be achieved through phishing, exploiting vulnerabilities, or leveraging stolen credentials.

Deploying the Vulnerable Driver: Once the attackers have established a foothold, they deploy AuKill, which includes a signed but vulnerable driver from a legitimate software vendor (such as a driver from the Micro-Star International (MSI) driver family, which has known vulnerabilities, e.g., CVE-2019–16098).
This driver is signed with a legitimate code-signing certificate, making it more likely to bypass initial antivirus checks and be loaded into the kernel.

Exploitation of the Vulnerable Driver: AuKill abuses the vulnerable driver to gain kernel-mode access. This is achieved by exploiting specific weaknesses in the driver that allow for arbitrary memory writes or other privilege-escalation techniques. For instance, it might use the vulnerable driver to disable kernel hooks or callbacks used by EDR agents to monitor and intercept suspicious activity. This effectively blinds the EDR solutions to any subsequent malicious actions.

1. Disabling EDR Processes and Services: With kernel-level access, AuKill can enumerate and terminate security-related processes and services running on the target machine. This involves:
2. Enumerating the EDR Processes: It identifies the running processes and services related to the targeted EDR solutions (like SentinelAgent.exe for SentinelOne or csfalconservice.exe for CrowdStrike Falcon).
3. Killing or Suspending Processes: AuKill uses various techniques to terminate these processes. For example, it might use Windows API calls like ZwTerminateProcess or ZwSuspendProcess to halt or kill these EDR components.
4. Modifying Kernel Data Structures: By directly writing to kernel data structures, AuKill can remove or modify EDR hooks, disable kernel callbacks, and manipulate memory to ensure the EDR is effectively neutralized.

Establishing Persistence and Payload Execution:

1. After neutralizing the EDR, AuKill establishes persistence on the compromised machine. This may involve writing to the registry, creating scheduled tasks, or using other techniques to maintain access.
2. Once persistence is secured, it can execute its primary payload, such as ransomware, credential stealers, or other malware, with little risk of detection.

How AuKill Was Able to Target Specific Vendors:

AuKill’s effectiveness lies in its use of vulnerable drivers that are often overlooked by security solutions. Here’s how it specifically targets various vendors:

• Using Trusted Drivers: By leveraging a legitimate but vulnerable driver, AuKill circumvents traditional signature-based detection mechanisms. Many EDR solutions, such as Microsoft Defender, CrowdStrike Falcon, or SentinelOne, do not flag or block signed drivers by default due to their assumed legitimacy.
• Exploiting Kernel-Level Privileges: With the vulnerable driver loaded, AuKill gains kernel-level privileges, allowing it to directly interact with and manipulate the EDR’s components. For instance, it may modify SSDT (System Service Descriptor Table) hooks or unhook critical APIs that EDR solutions rely on for monitoring and interception, effectively turning off their capabilities.
• Targeting Specific Processes: By identifying and specifically targeting processes associated with these EDR vendors, AuKill methodically disables or disrupts each vendor’s defenses. For example, to target CrowdStrike Falcon, it identifies and terminates processes like csagent.exe and csfalconservice.exe. For SentinelOne, it focuses on processes like SentinelAgent.exe.

How AuKill Disables EDR Solutions Despite Tamper Protection: A Technical Analysis

To understand how AuKill bypasses the tamper protection features of modern EDR solutions, we need to delve into its specific technique and review how it leverages a vulnerable driver to operate at the kernel level, allowing it to bypass or neutralize tamper protection mechanisms.

Understanding EDR Tamper Protection

Tamper protection is a security feature implemented by EDR solutions to prevent unauthorized modifications, termination, or disabling of their components. This includes preventing unauthorized users (including malware) from stopping EDR services, deleting EDR files, or altering the EDR’s core functionality.

However, tamper protection typically relies on several key mechanisms:

User-mode Restrictions: The first level of tamper protection often involves setting specific access control restrictions on EDR processes to prevent unauthorized access, modification, or termination. Here’s a simplified example of how an EDR sensor might use the Windows API to achieve this:

#include <Windows.h>
#include <Aclapi.h>

void SetProcessDACL(HANDLE hProcess) {
    // Define a SID for the "Everyone" group.
    PSID pEveryoneSID = NULL;
    SID_IDENTIFIER_AUTHORITY SIDAuthWorld = SECURITY_WORLD_SID_AUTHORITY;
    AllocateAndInitializeSid(&SIDAuthWorld, 1, SECURITY_WORLD_RID,
                             0, 0, 0, 0, 0, 0, 0, &pEveryoneSID);

    // Initialize an EXPLICIT_ACCESS structure for the new ACE.
    EXPLICIT_ACCESS ea;
    ZeroMemory(&ea, sizeof(EXPLICIT_ACCESS));
    ea.grfAccessPermissions = PROCESS_TERMINATE | PROCESS_VM_WRITE; // Restrict termination and modification.
    ea.grfAccessMode = DENY_ACCESS; // Deny access to these actions.
    ea.grfInheritance = NO_INHERITANCE;
    ea.Trustee.TrusteeForm = TRUSTEE_IS_SID;
    ea.Trustee.TrusteeType = TRUSTEE_IS_WELL_KNOWN_GROUP;
    ea.Trustee.ptstrName = (LPWSTR)pEveryoneSID;

    // Create a new DACL with the new ACE.
    PACL pNewACL = NULL;
    SetEntriesInAcl(1, &ea, NULL, &pNewACL);

    // Apply the new DACL to the EDR process.
    SetSecurityInfo(hProcess, SE_KERNEL_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, pNewACL, NULL);

    // Clean up.
    if (pEveryoneSID) FreeSid(pEveryoneSID);
    if (pNewACL) LocalFree(pNewACL);
}

int main() {
    // Obtain the handle to the current EDR process (pseudo).
    HANDLE hProcess = GetCurrentProcess();
    SetProcessDACL(hProcess);

    return 0;
}

Explanation:

1. Creating a Security Identifier (SID): This snippet creates a SID for the “Everyone” group, representing all users on the system.
2. Defining Access Control: It then sets up an Access Control Entry (ACE) that denies the PROCESS_TERMINATE and PROCESS_VM_WRITE permissions. This prevents any user or process in the "Everyone" group from terminating the EDR process or writing to its memory space.
3. Applying the DACL: Finally, it applies the new Discretionary Access Control List (DACL) to the process. This enforces the restriction, effectively preventing tampering attempts from unauthorized users or processes.

Kernel-mode Callbacks and Hooks: In addition to user-mode restrictions, EDR solutions also employ kernel-mode callbacks and hooks to detect and block any unauthorized access or modifications. Here’s an example of using the PsSetCreateProcessNotifyRoutine function in the Windows kernel to monitor process creation events:

#include <ntddk.h>

VOID ProcessNotifyCallback(
    _In_ HANDLE ParentId,
    _In_ HANDLE ProcessId,
    _In_ BOOLEAN Create
) {
    // Check if a process creation or termination event.
    if (Create) {
        DbgPrint("Process Created: PID %d by Parent PID %d\n", ProcessId, ParentId);
        // Logic to check if the new process is an attempt to tamper with EDR.
        // For example, checking if the process has a suspicious name or signature.
    } else {
        DbgPrint("Process Terminated: PID %d\n", ProcessId);
        // Additional checks can be added here for termination events.
    }
}

NTSTATUS DriverEntry(
    _In_ PDRIVER_OBJECT DriverObject,
    _In_ PUNICODE_STRING RegistryPath
) {
    NTSTATUS status = PsSetCreateProcessNotifyRoutine(ProcessNotifyCallback, FALSE);
    if (!NT_SUCCESS(status)) {
        DbgPrint("Failed to set process creation callback: %X\n", status);
        return status;
    }

    // Continue with driver initialization...
    return STATUS_SUCCESS;
}

Explanation:

1. Registering a Callback: The PsSetCreateProcessNotifyRoutine function registers a callback function (ProcessNotifyCallback) that is invoked every time a process is created or terminated.
2. Monitoring and Filtering Events: Within this callback, the EDR can analyze each new process. For example, it might check if the process matches a known tampering tool or has a suspicious signature, and respond accordingly.
3. Kernel-Level Detection: This approach allows EDR to detect process creation or termination events in real-time, directly from the kernel, making it difficult for user-mode malware to bypass.

Integrity Checks: EDR solutions regularly verify the integrity of their components to detect unauthorized modifications. This involves calculating and comparing cryptographic hashes of their executable files, DLLs, and other critical components.

Example Code: File Integrity Check

#include <Windows.h>
#include <wincrypt.h>
#include <stdio.h>

BOOL VerifyFileIntegrity(LPCWSTR szFileName) {
    HANDLE hFile = CreateFile(szFileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) return FALSE;

    HCRYPTPROV hProv = 0;
    HCRYPTHASH hHash = 0;
    BYTE rgbHash[20];
    DWORD cbHash = 20;

    // Acquire a cryptographic context.
    if (!CryptAcquireContext(&hProv, NULL, NULL, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT)) return FALSE;

    // Create a hash object.
    if (!CryptCreateHash(hProv, CALG_SHA1, 0, 0, &hHash)) return FALSE;

    // Hash the file content.
    BYTE buffer[1024];
    DWORD bytesRead;
    while (ReadFile(hFile, buffer, sizeof(buffer), &bytesRead, NULL) && bytesRead > 0) {
        CryptHashData(hHash, buffer, bytesRead, 0);
    }

    // Retrieve the hash value.
    if (!CryptGetHashParam(hHash, HP_HASHVAL, rgbHash, &cbHash, 0)) return FALSE;

    // Compare with the known good hash (pseudo code).
    BYTE knownGoodHash[20] = { /* hash value */ };
    if (memcmp(rgbHash, knownGoodHash, cbHash) != 0) {
        printf("File integrity check failed!\n");
        return FALSE;
    }

    printf("File integrity check passed.\n");
    return TRUE;
}

Explanation:

1. Hashing the File: The CryptHashData function is used to compute the SHA-1 hash of the EDR executable file or DLL.
2. Integrity Verification: The computed hash is compared with a known good hash (hardcoded or fetched from a trusted server). If the hashes do not match, it indicates that the file has been tampered with, and appropriate actions are triggered, like restarting the EDR service or alerting the system administrator.

Despite these defenses, AuKill is able to bypass tamper protection by exploiting a vulnerable driver to gain kernel-level privileges, enabling it to operate beyond the reach of user-mode protections.

The Core Technique: Bring Your Own Vulnerable Driver (BYOVD)

AuKill leverages a vulnerable but legitimate driver — like the Micro-Star International (MSI) driver — to gain kernel-level access. This specific driver contains a flaw that allows arbitrary memory read/write operations in kernel space. Once loaded, the vulnerable driver allows AuKill to perform privileged actions that would otherwise be blocked by tamper protection.

Disabling EDR Solutions: The Actual Code and Process

Let’s examine how AuKill disables EDR solutions, even with tamper protection enabled, by utilizing an original piece of its code.

A sample code Example (Representative ofAuKill)

The following code snippet demonstrates how AuKill uses a vulnerable driver to perform direct memory manipulation in the Windows kernel, effectively bypassing tamper protection:

// Assume `DeviceHandle` is a handle to the vulnerable driver.
// This IOCTL (Input/Output Control) call allows arbitrary memory reads/writes.
#define IOCTL_VULNERABLE_DRIVER_WRITE_MEMORY 0x9C402580

typedef struct _KERNEL_WRITE_REQUEST {
    PVOID TargetAddress;   // Address in kernel space to be modified
    PVOID SourceAddress;   // Address in user space containing the data to write
    SIZE_T Size;           // Number of bytes to write
} KERNEL_WRITE_REQUEST, *PKERNEL_WRITE_REQUEST;

BOOL WriteKernelMemory(HANDLE DeviceHandle, PVOID TargetAddress, PVOID Data, SIZE_T Size) {
    KERNEL_WRITE_REQUEST Request;
    Request.TargetAddress = TargetAddress;
    Request.SourceAddress = Data;
    Request.Size = Size;

    DWORD BytesReturned;
    return DeviceIoControl(DeviceHandle, IOCTL_VULNERABLE_DRIVER_WRITE_MEMORY,
                           &Request, sizeof(Request), NULL, 0, &BytesReturned, NULL);
}

// Example Usage: Disabling EDR Process
PVOID EDRProcessTargetAddress = (PVOID)0xFFFFF80000012345; // Hypothetical address
BYTE ZeroBytes[8] = { 0x00 }; // Data to write to disable the process

HANDLE hDevice = CreateFile(L"\\\\.\\VulnDriver", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

if (hDevice != INVALID_HANDLE_VALUE) {
    WriteKernelMemory(hDevice, EDRProcessTargetAddress, ZeroBytes, sizeof(ZeroBytes));
}

Step-by-Step Analysis of the Code:

1. Obtain a Handle to the Vulnerable Driver: The attacker uses the Windows CreateFile function to obtain a handle (hDevice) to the vulnerable driver. This handle will be used to communicate with the driver and execute arbitrary actions at the kernel level.
2. Prepare Memory Manipulation Request: The KERNEL_WRITE_REQUEST structure is created to specify the target address in kernel space (EDRProcessTargetAddress), the source data in user space (ZeroBytes), and the size of the data to be written. In this example, the target address represents a location in kernel memory associated with an EDR process.
3. Perform Arbitrary Memory Write: The DeviceIoControl function is called with the IOCTL_VULNERABLE_DRIVER_WRITE_MEMORY control code to instruct the vulnerable driver to perform a direct write operation to the specified address in kernel memory.

• This allows AuKill to directly overwrite kernel memory locations associated with critical EDR components, such as process objects or service status flags, effectively terminating the EDR or disabling its protections.

How AuKill Utilizes the Vulnerable Driver to Disable EDRs Despite Tamper Protection:

• Bypassing User-Mode Protections: Most EDR solutions’ tamper protections operate in user mode, relying on process isolation, memory protection, and restricted permissions to prevent unauthorized access. AuKill bypasses these by operating in kernel mode, where it has unrestricted access to both user and kernel memory.
• Disabling Kernel Callbacks and Hooks: AuKill leverages the vulnerable driver to locate and disable the kernel-mode callbacks and hooks that EDR solutions use to monitor critical events. It directly manipulates kernel structures (like the Object Manager or Process Control Blocks) to disable or unhook EDR callbacks, effectively blinding the EDR solution to malicious actions.
• Tampering with Process Objects and Security Descriptors: AuKill uses its kernel privileges to modify the security descriptors of EDR processes, removing protections that prevent process termination. By rewriting specific fields in the Executive Process Control Block (EPROCESS) or other kernel data structures, it can alter access control settings, allowing it to terminate or suspend EDR processes, regardless of tamper protection settings.
• Killing EDR Services and Processes: With its kernel-level access, AuKill identifies critical EDR services and processes (like SentinelAgent.exe for SentinelOne or csagent.exe for CrowdStrike Falcon). Using ZwTerminateProcess or similar API calls directly from the kernel context, AuKill terminates these processes, bypassing all user-mode protections.

Real-World Impact and Effectiveness:

By leveraging a vulnerable driver to gain kernel-level control, AuKill can:

• Completely bypass user-mode tamper protections since it operates outside the realm of user-space defenses.
• Manipulate kernel memory directly, allowing it to disable or unhook critical EDR functions, rendering them ineffective.
• Terminate or suspend EDR processes without triggering the usual alarms or protection mechanisms, as it operates with the same or higher privilege than the EDR software itself.

#EDRKiller #AllKIllZeroFill #BYOVD