KQL - LolDrivers

Objective

The objective of this exercise is to create a custom detection rule that identifies the execution or loading of known vulnerable or malicious drivers, commonly referred to as LOLDrivers (Living Off the Land Drivers). By leveraging publicly available LOLDrivers intelligence, the detection rule enables security teams to identify potential attempts to exploit legitimate signed drivers for privilege escalation, defense evasion, or arbitrary kernel-level code execution.

The completed detection rule should:

• Detect the loading or execution of drivers listed in the LOLDrivers project.
• Generate high-fidelity alerts when a known vulnerable driver is observed.
• Reduce the time required to identify bring-your-own-vulnerable-driver (BYOVD) attacks.
• Support proactive threat hunting and incident response activities.

---

Skills Learned

• Threat Understanding - Understanding of Living Off the Land Drivers (LOLDrivers) and BYOVD attack techniques.
• Detection Engineering - Creating custom detection logic using endpoint or SIEM telemetry.
• Validation and Testing - Assessing rule performance by testing against confirmed indicators of compromise (IOCs).

---

Steps

Part 1: Research and Prepartion

Begin by researching publicly available LOLDrivers intelligence to identify drivers that have been associated with malicious activity or are known to be vulnerable. This intelligence is sourced from the public repository:

Source URL: https://www.loldrivers.io/

Collect relevant information such as driver names, file hashes, publishers, associated CVEs, and documented attack techniques.

Next, review available telemetry within the environment to determine where driver load events can be observed. Common data sources include endpoint detection and response (EDR) telemetry, Sysmon, Windows Event Logs, and SIEM platforms. Ensure the available data includes key attributes such as driver filename, file path, SHA256 hash, and SHA1 hash, as well as the process responsible for loading the driver.

Part 2: Detection Rule Development

Using the collected threat intelligence, develop a custom detection rule that identifies the loading of known LOLDrivers. The detection logic correlates endpoint driver load events with the LOLDrivers dataset by matching known SHA256 and SHA1 hashes.

The following Kusto Query Language (KQL) query can be used as the detection logic within Microsoft Sentinel or Microsoft Defender XDR:

 let LOLDrivers = externaldata (Category:string, KnownVulnerableSamples:dynamic, Verified:string ) [h@"https://www.loldrivers.io/api/drivers.json"]
     with (
       format=multijson,
       ingestionMapping=@'
[
  {"Column":"Category","Properties":{"Path":"$.Category"}},
  {"Column":"KnownVulnerableSamples","Properties":{"Path":"$.KnownVulnerableSamples"}},
  {"Column":"Verified","Properties":{"Path":"$.Verified"}}
]'
     )
| mv-expand KnownVulnerableSamples
| extend SHA1 = tostring(KnownVulnerableSamples.SHA1), SHA256 = tostring(KnownVulnerableSamples.SHA256)
;
// you can filter the drivers further based on category or verified status
DeviceEvents
| where ActionType == "DriverLoad"
| join kind=inner (LOLDrivers | where isnotempty(SHA256)) on SHA256
| union (
  DeviceEvents
  | where ActionType == "DriverLoad"
  | join kind=inner (LOLDrivers | where isnotempty(SHA1)) on SHA1
)

Once implemented, validate the rule in a controlled environment. Confirm that known LOLDrivers generate alerts while legitimate driver activity does not result in excessive false positives. Ensure that alerts include sufficient context for investigation, such as driver hash, device name, and timestamp.

Part 3: Deployment and Continuous Improvemen

After successful testing, deploy the detection rule into the production environment and configure alert severity and MITRE ATT&CK mappings. Document the detection logic, including the data source, query behavior, and expected outcomes.

Finally, establish a maintenance process to periodically update the detection logic as new entries are published in the LOLDrivers project. This ensures continued coverage against emerging Bring Your Own Vulnerable Driver (BYOVD) techniques and reduces detection blind spots over time.

---

Notes

• Some legitimate IT tools or hardware vendors may use drivers that appear in the LOLDrivers dataset, so context is important before escalating an alert.
• This detection should be used as part of a larger security strategy and not relied on by itself. Other logs and signals should also be checked during investigations.
• Driver loading activity can be normal on most endpoints, especially during software installs, updates, or hardware driver updates. Because of this, some alerts may be false positives.