We have three endpoint enhancements, all contributing to better endpoint prevention:

1. To be even more proactive about Bring Your Own Vulnerable Driver (BYOVD) attacks, we’re continuously monitoring public vulnerable driver disclosures and automatically generating endpoint protections
2. To improve your endpoint management efficiency, Automatic Troubleshooting is now available as a skill via Elastic Agent Builder
3. To expand our coverage surface, Elastic Defend is now available for Windows on ARM

Let’s dig into each one.

What is a BYOVD attack and how does it bypass endpoint protection?

BYOVD is a technique attackers use to gain kernel-level access on Windows machines by abusing legitimately signed drivers, letting them bypass defenses meant to block unauthorized code. Windows requires low-level software drivers that run in the kernel to be digitally signed, so rather than trying to sneak in something unsigned, attackers bring a driver that's already signed and trusted, but that has a known security flaw. That flaw is enough to disable security software or tamper with memory, and once an attacker has that level of access, security tools can no longer reliably protect the host.

This combination is why BYOVD has become so appealing to ransomware operators. The technique started as tradecraft mostly reserved for advanced state actors and red teams. Elastic Security Labs has tracked its shift into a routine step ransomware crews now use to tamper with or shut down endpoint security software before deploying their payload, as detailed in Stopping Vulnerable Driver Attacks.

Now, why does timing matter here? BYOVD attacks have depended on one thing for years: the delay between a vulnerable driver's public disclosure and a vendor shipping coverage for it. The moment a vulnerable driver becomes public knowledge, attackers already know about it. When it takes a vendor an entire product release to ship a protection, that gap is exactly what the technique depends on.

To close this gap, Elastic Security Labs Threat Command, Elastic's security research team now continuously monitors public vulnerable driver disclosure sources, including VirusTotal, the LOLDrivers catalog, and Microsoft's Vulnerable Driver Block List, and automatically generates and instantly deploys detection rules. Because we know any delay could be the difference between an exposed endpoint and a secured one, we’ve decoupled this coverage from any release cycle and publish the protections in the open.

How Elastic automatically generates vulnerable driver YARA rules

Elastic Security Labs has published detection coverage for vulnerable drivers for years. That coverage now runs through an always-on process that adds new drivers to the protections library as they're disclosed. An always- on process means coverage ships continuously, not whenever the next major release happens to land, and it doesn’t require an update or setting change. A driver flagged today becomes a driver Elastic Defend recognizes.

Elastic Security Labs Threat Command monitors three public sources for newly disclosed vulnerable and malicious drivers:

• VirusTotal
• The community-run LOLDrivers catalog
• Microsoft's Vulnerable Driver Block List

No single source catches everything, so the system checks all three, filters out drivers Elastic already covers, and builds new detection rules from the driver's digital signature and file characteristics.

One example: Avast's signed anti-rootkit driver (aswArPot.sys), which was abused to terminate protected processes from the kernel and has been leveraged in Cuba ransomware intrusions as well as GHOSTENGINE campaigns. Elastic generates detection coverage for weaponized drivers like these automatically as soon as they surface in the wild.

Every rule this process generates is public. Coverage lands in Elastic's open protections-artifacts repository alongside the rest of Elastic's detection content, so a security team can verify it directly before applying it to their systems. The sources are named and the rules themselves are published in the open, unlike a vendor's private threat feed. You can see which driver triggered a rule, which source flagged it, and inspect the detection logic itself.

This process has taken coverage from an initial 65 rules in 2023 to more than 800 known vulnerable drivers today, and the number keeps growing. These protections ship through Elastic Security's malware protection, so make sure it's enabled and set to Prevent to get the full benefit.

Signature coverage is also just one layer though. This automated coverage sits alongside protections Elastic Defend has carried for years: validating drivers against a blocklist before they're allowed to load and flagging drivers the moment they're seen for the first time in an environment. A newly disclosed driver doesn't have to wait on a signature alone to be caught doing something suspicious, and a driver built to slip past one layer still has to get past the others built to detect it.

Automatic endpoint troubleshooting in Elastic Agent Builder, now available as a skill

The automatic troubleshooting skill in Elastic Agent Builder flags policy and performance issues, bringing automation and natural language chat to endpoint diagnosis. Just like the existing Automatic Troubleshooting feature scans for and surfaces known endpoint issues, this skill also lets you ask questions, get a diagnosis, and receive specific remediation guidance. It handles the failures that consume the most investigation time: third-party antivirus conflicts, policy application failures, and the errors that typically send analysts into logs for hours.

The skill runs continuously to identify issues’ root causes, tell you what to fix, what commands to run, and what data to collect, all available the second you’re aware of an issue. The existing automatic troubleshooting feature remains available; this skill sits alongside it as a faster path to resolution, specifically tailored for teams that want to work through issues conversationally.

Windows on ARM: Elastic Defend coverage for Snapdragon and Copilot+ PCs

With the increased popularity of ARM processors, Snapdragon laptops, Copilot+ PCs, ARM workstations are more commonly showing up in enterprises’ fleets. If your endpoint protection doesn't cover them, they're unmonitored, and an unmonitored endpoint is a gap an attacker can use. That’s why Elastic Defend has now expanded to cover Windows on ARM. ARM workstations, Snapdragon laptops, and Copilot+ PCs can enroll under your existing policy with the same detection rules and telemetry as x64 endpoints. As you add ARM devices to your fleet, they can enroll automatically to your existing policies.

Get started with Elastic Security today

Elastic Security has significant enhancements to endpoint protections, efficiencies for diagnosing and resolving performance issues, and expanding coverage to new systems, all aimed at shifting defenses earlier, to prevention at the endpoint.

Elastic Security Labs Threat Command now continuously monitors public vulnerable driver disclosure sources and automatically generates and instantly deploys protection rules, decoupled from any release cycle and published in the open. That speed matters when AI-driven attacks can move from one machine to the next in under a minute, faster than any response workflow can react.

Browse the rules directly in the elastic/protections-artifacts repo, alongside the rest of Elastic's open detection content and test out the automatic troubleshooting skill through Elastic Agent Builder.

How threat intelligence works in Elastic Security

In modern security operations, threat intelligence must work across detection, investigation, and response, not sit in a reference table.

Elastic Security supports this in two ways. Ingested intelligence via integrations drives continuous detection and historical hunting. Agentic workflows, built on Elastic Workflows and Agent Builder, provide on-demand enrichment and investigative reasoning during an active investigation. This post focuses on how Elastic's Google Threat Intelligence (GTI) integration powers ingestion-based detection and hunting, and how it fits into a broader, more dynamic SOC model where AI-driven workflows use that intelligence at alert time.

What Google Threat Intelligence provides

The Google Threat Intelligence integration brings curated threat intelligence directly into Elastic Security, making it actionable across detection and investigation. GTI combines intelligence from Google's global security visibility with VirusTotal data to deliver enriched context on indicators of compromise, with coverage across malware, ransomware, phishing, infostealers, malicious infrastructure, threat actors, and other adversary activity.

Each indicator is returned with: a verdict (Malicious, Suspicious, or Undetected), a severity, and a composite threat score from 0–100. Because that score is derived from multiple signals, security teams can prioritize indicators based on confidence rather than their presence alone.

How the Google Threat Intelligence integration works in Elastic Security

Setup takes only a few minutes. You provide your GTI API key in the Elastic integration, and ingestion begins on a scheduled polling interval, with no additional infrastructure or collectors required. The integration ingests two primary data streams.

| Purpose | Threat List | IOC Stream | |--------|-------------|------------| | Purpose | High-confidence detection | Threat hunting + early visibility | | Volume | Curated, lower volume | Broader, higher volume | | Best for | Precision-critical alerting | Emerging and exploratory activity |

As data is ingested, indicators are standardized using the Elastic Common Schema (ECS), along with GTI context, such as verdict, severity, score, malware families, threat actor associations, and campaign metadata (where available). This enables GTI to be searched and correlated consistently alongside other ECS-compliant intelligence sources (including TAXII feeds), custom intelligence, and the broader security telemetry already present in Elastic Security. Elastic also manages indicator lifecycle automatically, including expiration and revocation, which reduces matches against stale intelligence. Once ingested, GTI indicators become part of the same searchable dataset as logs, endpoint, and cloud telemetry, enabling unified correlation across the environment.

Using Google Threat Intelligence for indicator match detections

Elastic's indicator match rules use GTI data to detect when known malicious IPs, domains, URLs, or file hashes appear in security telemetry, continuously correlating intelligence against observed activity and surfacing matches for investigation. Because GTI provides structured fields such as score, verdict, and severity, teams can tune detections by confidence: high-confidence indicators can trigger immediate escalation, while lower-confidence indicators can be routed for review or further validation.

Threat hunting with GTI indicators in Elastic Security

With GTI metadata, analysts can pivot from a single IOC to all associated infrastructure and search historical telemetry; not just check if an indicator appeared, but understand what campaign it belongs to.

GTI enriches indicators with metadata such as threat actor associations and malware family context, allowing analysts to move beyond single-IOC searches. Hunters can pivot from an adversary or campaign to all associated indicators (IPs, domains, and file hashes) and search across historical telemetry using ES|QL. This makes it straightforward to determine whether known malicious infrastructure has ever interacted with the environment.

Monitoring threat intelligence activity with GTI dashboards

The integration includes prebuilt dashboards that provide visibility into threat intelligence activity and the detections GTI drives. Using saved searches and aggregated metrics, these dashboards summarize observed threats across malware families, campaigns, threat actors, toolkits, and vulnerabilities, helping SOC teams understand which threat types are most active in their environment and how intelligence is being operationalized.

Google Threat Intelligence feed categories and coverage

GTI includes 14 categorized feed categories, so organizations can tailor coverage to their needs and subscription level. Supported categories include:

• Cryptominers
• Trending threats
• Initial access and delivery vectors
• Infostealers
• IoT threats
• Linux malware
• Malicious infrastructure
• General malware
• Mobile threats
• macOS threats
• Phishing
• Ransomware
• Threat actors
• Vulnerability exploitation and weaponization

Availability depends on your Google Threat Intelligence subscription tier, and additional feeds can be enabled without changes to the Elastic configuration.

Agentic enrichment and real-time triage with Elastic Workflows

For ambiguous or emerging indicators not yet in an indexed feed, Elastic Security supports AI-driven investigation through Agent Builder and Elastic Workflows, which complement intelligence ingestion by enabling real-time enrichment and reasoning during an investigation.

With workflows, an analyst is no longer limited to the intelligence already in the index. During alert triage, a workflow can query external intelligence and reputation services such as VirusTotal in real time, enrich an alert with fresh context about the IPs, domains, or file hashes involved, correlate that live intelligence against Elastic telemetry, and summarize the findings into a structured investigation context that the analyst can act on. Agent Builder extends this further: teams can compose reusable, task-specific capabilities, such as agent skills for alert triage, enrichment, or case handling, so the assistant executes multi-step investigative tasks with the consistency of traditional automation, through a natural-language interface.


This introduces a complementary model. Ingested intelligence (GTI, TAXII, and custom feeds) provides continuous detection and historical hunting against indicators you already hold. Agentic workflows provide on-demand enrichment and investigative reasoning at alert time, reaching out to live sources and assembling context on the fly. Together, they enable teams to detect known threats at scale and provide context to investigations.

Getting started with Google Threat Intelligence in Elastic Security

To use the Google Threat Intelligence integration in Elastic Security, you need an active GTI license and API key.

1. Install: open Integrations catalog in Kibana → search "Google Threat Intelligence" → add integration → enter your API key
2. Configure the data streams: enable Threat List (high-confidence detections) and IOC Stream (hunting coverage) → set polling frequency to match API limits and operational needs
3. Tune: prebuilt indicator match rules activate automatically; if alert volume is high, start by filtering on confidence threshold

All indicators are stored in Elasticsearch and accessible through the GTI threat intelligence data view, enabling search, correlation, and custom detection logic. Full configuration details and troubleshooting guidance are available in the official documentation.

Tying it all together

Threat intelligence only matters if a team can act on it. By bringing Google Threat Intelligence into Elastic Security, SOC teams get ingestion-based detection running continuously across their telemetry and agent-driven investigation reasoning over that intelligence in real time. The combination lets threat intelligence operate continuously and contextually, helping analysts move from indicators to confident decisions faster.