Listen to this Post
Introduction:
The cybersecurity landscape is witnessing a sophisticated shift in attacker tradecraft, moving beyond traditional malware to the weaponization of signed, legitimate software components. The recent addition of `atillk64.sys` to the Living-Off-the-Land Drivers (LOLDrivers) repository underscores a critical threat: adversaries are exploiting trusted, signed drivers to gain unfettered kernel-level access, effectively dismantling security controls and compromising entire systems.
Learning Objectives:
- Understand the concept of LOLDrivers and how they pose a fundamental threat to endpoint security.
- Analyze the specific case of `atillk64.sys` and its associated CVE-2020-12138 vulnerability.
- Implement detection and mitigation strategies to identify and block the abuse of legitimate drivers.
You Should Know:
- Decoding the LOLDrivers Project and Its Critical Role
The LOLDrivers project is a curated, open-source repository dedicated to cataloging legitimate drivers that have been maliciously exploited in the wild. Similar to the “Living-off-the-Land” (LOL) techniques that use built-in OS tools like `powershell.exe` or bitsadmin.exe, LOLDrivers represent a higher-echelon threat by operating at the kernel level. When a malicious actor loads a vulnerable but signed driver, they bypass signature enforcement policies (like Microsoft’s Driver Signature Enforcement) and gain the ability to read/write kernel memory, terminate security processes, and disable endpoint detection and response (EDR) agents. The project provides rich metadata, including digital certificate details and file hashes, empowering defenders to build automated detection rules.
- A Deep Dive into the atillk64.sys Driver and CVE-2020-12138
`atillk64.sys` is a legitimate 64-bit kernel driver originally associated with AMD graphics cards. The driver contains a vulnerability, cataloged as CVE-2020-12138, which is an arbitrary read/write primitive. This flaw exists because the driver’s IOCTL (Input/Output Control) handler lacks proper access control and validation. An attacker with low-privileged access on a compromised machine can craft specific IOCTL requests to interact with this driver. Once loaded, the driver, trusting the requests because it runs in kernel mode, allows the attacker to read from or write to any arbitrary kernel memory address. This capability is the key to full system compromise, enabling privilege escalation from a standard user to
NT AUTHORITY\SYSTEM.
3. Step-by-Step: How an Attacker Exploits This Driver
An exploitation chain typically follows these steps:
Step 1: Initial Compromise. An attacker gains initial access and user-level execution on a target system through a phishing email, exploited application, or other means.
Step 2: Driver Acquisition. The attacker uploads the legitimate `atillk64.sys` driver file to the compromised system. Since the driver is signed, it is not flagged by antivirus as inherently malicious.
Step 3: Driver Loading. The attacker uses a user-mode program to load the driver into the kernel. This can be achieved with native Windows tools or custom loaders.
Windows Command (using built-in tools):
sc create AtiLoader binPath= C:\temp\atillk64.sys type= kernel sc start AtiLoader
Step 4: Exploitation. The attacker executes a payload or exploit code that communicates with the loaded driver via its vulnerable IOCTL interface. This code sends the crafted requests to perform malicious kernel memory operations, such as disabling a security product or stealing credentials directly from memory.
Step 5: Privilege Escalation. By tampering with kernel structures, the exploit grants the attacker’s process the highest level of system privileges.
- Proactive Hunting: Detecting Malicious Driver Loads with EDR and SIEM
Defenders must look beyond file hashes and focus on behavior and telemetry. Endpoint Detection and Response (EDR) tools and SIEMs are critical for this.
Step 1: Configure EDR/Sysmon Logging. Ensure your EDR solution is configured to log kernel driver loads. Sysmon (System Monitor) is a free tool from Microsoft that provides this capability.
Sysmon Configuration (Event ID 6):
<!-- Logs when a driver is loaded --> <DriverLoad onmatch="include"> <Image condition="end with">.sys</Image> </DriverLoad>
Step 2: Craft Detection Rules. Create alerts for the loading of known LOLDrivers. This can be done using the hashes and file names provided by the LOLDrivers project.
Example Sigma Rule (YAML) logic:
title: Loading of Known Vulnerable Driver atillk64.sys logsource: product: windows service: sysmon detection: selection: EventID: 6 ImageLoaded|endswith: '\atillk64.sys' condition: selection
Step 3: Hunt for Anomalies. Search for driver loads from unusual paths (e.g., `C:\Users\Public\` or C:\temp\) or by non-administrative users, which is highly suspicious for kernel-mode components.
5. Hardening Your Defenses: Mitigation and Prevention Strategies
Preventing the abuse of drivers requires a multi-layered approach.
Step 1: Implement Application Control. Use policies like Windows Defender Application Control (WDAC) or AppLocker to create a deny-list or, more effectively, an allow-list of approved drivers and applications. A WDAC policy can block drivers based on their publisher or specific hash.
Example WDAC PowerShell command to refresh a policy:
RefreshPolicy.exe /Machine
Step 2: Leverage Attack Surface Reduction (ASR) Rules. Enable the “Block abuse of exploited vulnerable signed drivers” ASR rule in Microsoft Defender. This is specifically designed to counter attacks like the one using atillk64.sys.
Step 3: Patch and Inventory. While this specific CVE may not have a patch from the vendor, maintaining a robust asset inventory helps you identify and remove vulnerable software components. For other drivers, apply vendor patches promptly.
Step 4: Principle of Least Privilege. Strictly enforce least privilege. Most users do not need the ability to load kernel drivers. Restrict this capability to administrative accounts only.
- Automating Discovery with the LOLDrivers Project and YARA
The LOLDrivers website (https://www.loldrivers.io/) is a primary resource. You can integrate its data into your security operations.
Step 1: Access the Repository. Navigate to the site and use the API or downloadable data sets to get the latest list of known malicious drivers.
Step 2: Create YARA Rules. Use the provided file hashes and metadata to write YARA rules for scanning your environment.
Example YARA Rule Skeleton:
rule LOLDriver_atillk64_sys {
meta:
description = "Detects atillk64.sys LOLDriver"
reference = "https://www.loldrivers.io/drivers/1234-abcd/"
strings:
$file_hash_sha1 = "a1b2c3d4e5f6..." // Replace with actual hash from the site
condition:
filesize < 100KB and hash.sha1(0, filesize) == $file_hash_sha1
}
Step 3: Deploy and Scan. Use tools like Thor Lite or your EDR’s built-in scanning capability to run these YARA rules across your endpoints proactively.
What Undercode Say:
- The Trust Model is Broken. The core takeaway is that the foundational security model of “trust based on a digital signature” is critically flawed. Attackers have realized that it is easier to find and exploit a flaw in a legitimately signed driver than to steal a certificate or break the signing algorithm itself.
- Visibility is the New Prevention. In this new era, preventing every initial intrusion is a losing battle. The focus must shift to deep visibility and rapid detection. Knowing what is running on your systems at the kernel level, and being able to identify anomalous behavior from seemingly legitimate components, is no longer optional; it is essential for survival.
This incident is not an anomaly but a signpost for the future of cyber attacks. The barrier to entry for kernel-level exploitation is lowering, enabling a broader range of threat actors to employ techniques once reserved for advanced persistent threats (APTs). Defenders must preemptively adapt their tools, processes, and mindset to assume that any signed component, no matter how obscure, could be the next vector for a total system takeover.
Prediction:
The weaponization of legitimate drivers will accelerate, moving from a niche technique to a mainstream attack vector. We will see the emergence of “driver-as-a-service” offerings in the cybercrime underground, where low-skilled attackers can rent access to exploit kits built around these signed drivers. This will force a fundamental change in the software industry, pressuring hardware and software vendors to adopt more rigorous secure development lifecycles for their drivers. Furthermore, operating system vendors like Microsoft will be compelled to implement even stricter kernel access controls, potentially moving towards a model where only a curated list of Microsoft-verified drivers can be loaded, fundamentally altering the Windows security paradigm.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Magicswordio Loldrivers – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
