AuKill and the BYOVD Tactic: A Tale of Attack and Defense

Introduction

In the evolving cat-and-mouse game between attackers and defenders in cybersecurity, the utilization of Bring Your Own Vulnerable Driver (BYOVD) tactics has significantly changed the playing field. One of the most potent manifestations of this method is a tool known as AuKill. This blog post explores AuKill from both an attacker and a defender perspective, offering deep insight into its functionality, purpose, and how enterprises can protect themselves.

The Attacker’s Perspective: Weaponizing the Kernel

Understanding the Objective

As an attacker, the goal is simple yet sophisticated: bypass or neutralize endpoint detection and response (EDR) systems to execute malicious payloads—often ransomware or information stealers—without interruption. Modern EDR tools operate with high privileges and leverage kernel-level monitoring, making them difficult to disable using user-mode techniques.

This is where BYOVD becomes attractive. Drivers operate at kernel level, and if a legitimate, signed driver has a known vulnerability, it can be abused to achieve privilege escalation or code execution at ring 0. AuKill automates this entire process.

The Setup: Dropping the Payload

An attacker who has gained administrative access to a target system—often through phishing, exploit kits, or stolen credentials—begins by deploying AuKill. The tool includes:

A known vulnerable driver (e.g., from Process Explorer or other legitimate software).
Custom code to exploit the vulnerability.
A payload, often ransomware or malware designed to evade user-mode detection.

Execution: The Kill Chain in Motion

Driver Installation: Using administrator privileges, AuKill installs the vulnerable driver. Since the driver is signed, Windows does not block it outright unless kernel driver blocklists are enforced.
Privilege Escalation: Once the driver is loaded, AuKill communicates with it to execute code in kernel mode.
Disabling EDR: Kernel access allows the attacker to forcibly terminate processes or disable callbacks used by EDR systems—essentially blinding them.
Malware Execution: With defenses down, the ransomware or data stealer is executed, encrypting or exfiltrating data with minimal resistance.

Post-Execution Benefits

From an attacker’s viewpoint, AuKill delivers significant advantages:

No need to exploit zero-day vulnerabilities in the EDR itself.
Legitimate signed drivers make attribution harder.
Disabling EDR increases dwell time and success rate.

The Defender’s Perspective: Closing the Gate

Recognizing the Threat

For defenders, the use of tools like AuKill poses a complex challenge. These tools do not rely on typical malware behaviors; instead, they exploit trusted components of the Windows OS. Traditional antivirus methods—signature-based detection and behavior-based heuristics—may not flag the driver or its activity immediately.

Defensive Failures Observed

Driver Signing Abuse: Windows trusts signed drivers by default. Without WDAC or equivalent policies, vulnerable drivers are fair game.
Insufficient Privilege Controls: Once attackers achieve admin access, they can load drivers freely.
Lack of Telemetry: Many organizations lack deep telemetry into driver loads or kernel-level operations.

Response Strategies: Hardening and Detection

Driver Blocklists
- Microsoft maintains a list of vulnerable drivers that can be blocked using Windows Defender Application Control (WDAC).
- Organizations should ensure this blocklist is applied across all endpoints.
Least Privilege Enforcement
- Admin access should be tightly controlled.
- LAPS, privileged access management (PAM), and session auditing should be mandatory.
Monitoring Driver Installation Events
- Use Sysmon (event ID 6) or EDR platforms to monitor for unexpected driver installs.
- Alert on loading of known vulnerable drivers.
Process Termination Alerts
- Monitor for termination of critical security processes.
- Unexpected shutdowns of EDR components should generate immediate alerts.
EDR Tamper Protection
- Many modern EDR solutions have self-protection mechanisms. Ensure these are enabled.

Case Study: LockBit Ransomware with AuKill

In a well-documented incident, LockBit affiliates used AuKill to disable EDR on high-value targets. The attack involved:

Dropping AuKill along with a vulnerable driver.
Using the tool to kill the EDR process.
Deploying LockBit ransomware within minutes.

The organization lacked driver monitoring and had no tamper protection enabled, allowing attackers to execute with impunity.

Bridging the Gap: Red and Blue Team Insights

Red Team Simulation Goals

From an adversary simulation standpoint, AuKill represents a real-world tactic to test EDR resilience. Red teams might:

Simulate the BYOVD attack path.
Measure EDR response or failure.
Test detection of unusual kernel-mode activity.

Blue Team Countermeasures

Blue teams, in response, should:

Use Sigma rules and YARA to identify AuKill behavior patterns.
Test EDR reactions by simulating vulnerable driver loads in controlled environments.
Patch detection gaps revealed during red team engagements.

Conclusion

AuKill is a prime example of how attackers continuously evolve to subvert even advanced security controls. By leveraging BYOVD techniques, they exploit the inherent trust placed in signed drivers to disable EDR systems silently. For defenders, this reinforces the need for a zero-trust mindset—even for signed binaries—and a layered security model that includes strict access control, vigilant monitoring, and proactive threat hunting.

The game continues to evolve, but with the right awareness and defenses, the advantage can shift back to the defenders.