25. 06. 2026 Daniel Degasperi Blue Team, Log-SIEM, SEC4U, Threat Intelligence

LOLDrivers Is More Than a Simple List: A New Approach to BYOVD Detection

1. Introduction

The abuse of vulnerable drivers has become an increasingly common technique adopted by attackers to bypass modern security controls.

This attack pattern, commonly referred to as Bring Your Own Vulnerable Driver (BYOVD), consists of loading legitimately signed but vulnerable drivers into the operating system in order to gain kernel-level privileges, disable security products, or bypass Endpoint Detection and Response (EDR) protections.

Unlike traditional malware, attackers do not necessarily need to develop custom malicious drivers. Instead, they can leverage existing vulnerable drivers that are publicly available and often legitimately distributed by hardware and software vendors.

Over the past few years, BYOVD has been extensively adopted by ransomware operators and advanced threat actors as an effective method to tamper with security solutions.¹

Tracking these drivers and keeping detection content up to date has therefore become an important challenge for Security Operations teams.

Projects such as LOLDrivers.io provide an invaluable resource by continuously maintaining a curated repository of vulnerable and malicious drivers known to be abused by attackers.

However, simply having access to this information is not enough. The real challenge is how to operationalize this intelligence in a scalable and maintainable way.

2. The limitations of a static list

Detections for malicious or vulnerable evidences have often relied on static detection rules (using list or array), where indicators such as SHA256 hashes or driver filenames are directly embedded into the detection logic.

While this approach is straightforward to implement, it presents several operational limitations.

Every time LOLDrivers (in this case study) publishes new entries, existing rules must be manually updated and redeployed.

As the number of indicators grows, maintaining large hardcoded lists quickly becomes complex.

Some of the main drawbacks include:

Indicators could become outdated quickly.
Detection rules require continuous maintenance.
New entries are not automatically covered.
Rule complexity increases over time.
Operational overhead grows significantly.

The problem is not the detection logic itself, but rather the fact that it is tightly integrated with threat intelligence data.

Detection rules should not be responsible for storing intelligence information.

Instead, they should simply use it.

3. From static detection to dynamic intelligence

To better understand the benefits of this approach, let’s compare two different implementations that aim to detect the exact same activity: the loading of a driver listed by LOLDrivers.

Initial approach: static rule

Initially, the rule we had developed and deployed in production was based on a Sigma rule in which the LOLDrivers indicators are embedded directly in the rule’s query.

A simplified Sigma detection may look similar to the following:

title: Vulnerable Driver Load
description: Detects the load of known vulnerable drivers via the file name of the drivers.
logsource:
    product: windows
    category: driver_load
detection:
    selection:
        ImageLoaded|endswith:
            - '\panmonfltx64.sys'
            - ...

condition: selection

The detection logic is simple: if the loaded driver’s name matches one of the hardcoded values, generate an alert (the same for the rule abouts the hashes).

While simple, this implementation introduces several operational challenges.

Every time LOLDrivers publishes new entries:

The rule must be manually updated.
The IOC list must be regenerated.
The rule must be tested.
The rule must be redeployed.

As the number of indicators grows, the rule itself gradually becomes an IOC repository rather than a detection rule.

This creates a strong dependency between threat intelligence and detection engineering.

A more scalable approach consists of decoupling threat intelligence from the detection logic.

New approach: Elastic Indicator Match

With Elastic, the same detection can be implemented differently. The rule no longer stores any indicators.

Instead, it simply correlates endpoint telemetry against a dedicated LOLDrivers intelligence index populated by the Custom API integration.

Conceptually, the rule becomes:

Source Event: 
host teletry (dll.name, dll.hash.sha256, file.hash.sha256, file.name) 

Indicator Source: 
threat.indicator.file.name, threat.indicator.file.hash.sha256 

Match: 
file.hash.sha256 == threat.indicator.file.hash.sha256

The detection logic remains permanently unchanged.

Regardless of whether LOLDrivers contains 100, 500 or 5000 entries the rule itself never needs to be modified 🙂 .

Only the intelligence data is updated.

Why this matters

The difference may appear subtle at first glance, but it fundamentally changes the operational model.

Using any static detection, threat intelligence is embedded inside the rule. With the new dynamic approach (in this particular case Indicator Match), threat intelligence becomes external data consumed by the rule.

Instead of asking:

“Which new file names or hashes should I add to my detection?”

The question becomes:

“Is my intelligence source being continuously updated?”

This approach allows SOC teams to focus on building robust detections instead of maintaining IOC lists.

4. Ingesting LOLDrivers using Elastic Custom API Integration

Elastic provides a native mechanism to retrieve data from external APIs through the Custom API integration.

Instead of relying on external scripts, scheduled tasks, or third-party collectors, the integration can periodically query LOLDrivers and ingest its data directly into Elastic.

The ingestion workflow becomes very simple

Using a native Elastic integration offers several advantages:

No additional infrastructure is required.
Centralized management through Elastic.
Easier long-term maintenance.
Native compatibility with Elastic Security.

Once collected, these values should be normalized into ECS fields under the threat.indicator.* fields :

data_stream.dataset: "loldrivers.log"
threat.indicator.file.hash.sha256
threat.indicator.file.name
driver.Commands.Description
driver.MitreID
driver.Category: "malicious" (or "vulnerable driver")

Additional metadata could also be added to facilitate future investigations.

For example:

tags:
- loldrivers
- byovd
- vulnerable-driver

At this stage, LOLDrivers is no longer a static reference list but a continuously updated threat intelligence feed.

In the screenshot, we can see that the data related to the drivers is fetched every hour (for testing purposes), and indexed in the desired index.

The frequency of the data pull can obviously vary, and it’s not absolutely necessary to do it every hour; for a use case like this, every 24 hours would be perfectly fine, so that the list is at least updated daily.

Furthermore, the ingested data does not need to be retained for an excessively long time, since all of it is retrieved every time the data is pulled.

5. Detecting malicious drivers using Indicator Match Rules

Once the intelligence feed is available, Elastic Indicator Match rules can be used to correlate endpoint telemetry against LOLDrivers indicators.

The principle is straightforward.

On one side, we have endpoint telemetry generated by systems such as:

Elastic Defend
Sysmon Event ID 6
Windows Driver Load events

On the other side, we have the LOLDrivers intelligence index.

The correlation logic becomes extremely simple, for example:

file.hash.sha256 MATCHES threat.indicator.file.hash.sha256

Whenever a loaded driver matches an entry maintained by LOLDrivers, Elastic automatically generates an alert.

As mentioned earlier, the biggest advantages of this approach is that the detection rule never changes… only the underlying intelligence data is updated; this significantly reduces maintenance efforts while simultaneously increasing detection coverage.

This is the rule regarding malicious drivers (the rule that identifies vulnerable drivers is essentially the same).

6. Operational impact and key considerations

The benefits of this approach extend beyond detection accuracy.

By decoupling threat intelligence from detection logic, organizations can significantly simplify their detection engineering workflows while improving long-term maintainability.

The operational differences between the traditional and the proposed approach become immediately evident.

Static List Rules	Indexed Events
Hardcoded IOC lists	Dynamic intelligence feed
Manual updates	Automatic updates
Frequent rule modifications	Stable detection rules
Limited scalability	Highly scalable
High maintenance effort	Low maintenance effort

However, a few operational aspects should still be considered when implementing this solution.

Indicator lifecycle management

Threat intelligence should not be treated as immutable data.

The ingestion process should properly manage:

Deduplication
Updates
Retention policies
Expiration policies

Without proper lifecycle management, stale indicators may continue generating unnecessary alerts over time.

For this reason, and to avoid large amounts of duplicate and possibly obsolete data, it is important to set an appropriate retention policy.

Choosing the correct severity & reducing false positives

The LOLDrivers database contains both malicious and vulnerable drivers. It is therefore clear that these two scenarios have very different impacts and levels of severity.

While evidence of a malicious driver being loaded or used must be investigated immediately and is potentially of high severity, not every vulnerable driver execution is necessarily malicious.

Some enterprise environments may legitimately use software that loads vulnerable drivers.

For this reason, it was decided to use the same index but to define two different detection rules for malicious and vulnerable drivers, with high and low severity levels, respectively.

Additional filtering mechanisms could therefore be introduced, such as:

Trusted publishers
Approved software
Known installation paths
Asset criticality

These filters help reduce noise while preserving detection accuracy.

7. Conclusion

Perhaps the biggest benefit of this approach is not technical but operational.

Detection engineers no longer need to maintain growing lists of indicators inside their rules. Instead, they can focus on improving detection logic while threat intelligence is maintained and updated independently.

The objective is not to create more detection rules, but to build smarter and easier-to-maintain detections.

By leveraging Elastic Custom API integration and Indicator Match rules, LOLDrivers can be transformed from a static online repository into a continuously updated threat intelligence feed. This allows organizations to move away from static IOC-based detections and adopt a dynamic intelligence-driven workflow.

The result is a more scalable, maintainable, and operationally efficient solution that significantly improves BYOVD detection coverage while reducing the effort required to keep detections up to date.

Ultimately, LOLDrivers should not be considered a list to copy into a detection rule, but rather a threat intelligence source to continuously consume.