Listen to this Post
Introduction:
The cybersecurity industry faces a persistent challenge: detection engineers and threat hunters are inundated with thousands of rules across various SIEM platforms like Sigma, Splunk, and Elastic. The Security Detections MCP (Model Context Protocol) server emerges as a groundbreaking solution, leveraging AI to provide a unified, searchable database of over 6,500 detection rules, complete with MITRE ATT&CK mappings and CVE tracking[reference:0]. This innovation allows defenders to query across these disparate sources using natural language, dramatically accelerating threat research and coverage analysis.
Learning Objectives:
- Understand the architecture and core functionality of the Security Detections MCP server.
- Learn how to query a unified database of Sigma, Splunk, and Elastic detection rules using natural language.
- Explore how to automate detection engineering workflows, from CTI report ingestion to draft rule generation.
- Discover mitigation strategies for Living Off the Land Drivers (LOLDrivers) and how to integrate them into your defenses.
You Should Know:
- Introducing the Security Detections MCP: A Unified Query Engine
The Security Detections MCP, created by Michael Haag (co-host of Atomics on a Friday and maintainer of LOLDrivers & Atomic Red Team), is a server that acts as a bridge between an AI assistant (like or Cursor) and a massive repository of security rules[reference:1]. It aggregates detection logic from Sigma (~3,000+ rules), Splunk ESCU (~2,000+ rules), Elastic (~1,500+ rules), and Analytic Stories (~330) into a single, normalized SQLite database[reference:2][reference:3].
Step-by-Step Guide: Installation and Basic Querying
This guide will walk you through setting up the MCP server and using it for basic detection queries.
Step 1: Prerequisites
- Node.js (version 20 or later): Required to run the MCP server. Verify with
node --version. - An MCP Client: An AI application that supports the Model Context Protocol, such as the Cursor IDE, Desktop, or any custom MCP client.
- Git: For cloning the detection rule repositories (optional but recommended).
Step 2: Installation and Configuration
The server can be run directly using `npx` without a full installation, or installed globally.
1. NPX (No Install – Recommended for Testing):
npx -y security-detections-mcp
2. Global Install:
npm install -g security-detections-mcp
3. Configuration: Add the server to your MCP client’s configuration file (e.g., `~/.cursor/mcp.json` or ~/.config//mcp.json). The `env` section allows you to specify local paths to your cloned rule repositories for enhanced search.
{
"mcpServers": {
"security-detections": {
"command": "npx",
"args": ["-y", "security-detections-mcp"],
"env": {
"SIGMA_PATHS": "/path/to/sigma/rules",
"SPLUNK_PATHS": "/path/to/security_content/detections",
"ELASTIC_PATHS": "/path/to/detection-rules/rules"
}
}
}
}
Note: You can clone the necessary detection repositories from their official GitHub sources or leave these paths empty to use the built-in database.[reference:4]
Step 3: Performing Your First Queries
Once configured, you can interact with the MCP server via your AI client using natural language prompts. The MCP tools will translate your requests into queries against the unified database.
Example 1: Finding Sigma Detections for a Specific Technique
“Find me Sigma detections for LSASS credential dumping (T1003.001).”
The MCP server will parse this request, query its database, and return relevant Sigma rule names, their logic, and MITRE mappings. You can see a similar example on the project’s site: “Find PowerShell detections for credential dumping”[reference:5].
Example 2: Checking CVE Coverage
“Do we have Splunk detections covering PrintNightmare (CVE-2021-34527)?”
The server will search for rules that reference the specific CVE ID, allowing you to quickly identify any gaps in your coverage[reference:6].
Example 3: Process-Based Searches
“Show me all Elastic rules that monitor the execution of powershell.exe.”
This will filter the Elastic rule set to return only those that list “powershell.exe” as a monitored process[reference:7].
- Autonomous Detection Engineering: From Threat Intel to Draft Rules
Version 3.0 of the Security Detections MCP transforms the server from a simple query engine into a fully autonomous detection engineering platform[reference:8]. This advanced feature enables the AI to act as a virtual security analyst, automating the entire workflow from threat intelligence ingestion to the creation of new, validated detection rules.
Step-by-Step Guide: Automating Detection Creation
This guide outlines how to use the autonomous pipeline to generate a detection rule for a new technique.
Step 1: Prerequisites for Autonomous Mode
- All prerequisites from Section 1.
- Anthropic API Key: The pipeline uses an LLM for analysis and rule generation. Add this key to your `.env` file.
- SIEM Configuration: You must set the `SIEM_PLATFORM` variable in your `.env` file to
splunk,sentinel,elastic, orsigma[reference:9]. This dictates the output format of the generated detection rules.
Step 2: Understanding the Pipeline
The autonomous workflow is a structured pipeline that performs the following actions[reference:10]:
1. CTI Analyst: Extracts TTPs (Tactics, Techniques, and Procedures) from a threat report, CISA alert, or manual input.
2. Coverage Analyzer: Compares the extracted TTPs against the existing unified detection database to identify coverage gaps.
3. Detection Engineer: For gaps that are found, this stage generates a new detection rule in your target SIEM’s native language (SPL, KQL, EQL, or Sigma)[reference:11].
4. Validator: Optionally runs the detection against a test environment (like Splunk Attack Range) to ensure it fires as expected.
5. PR Stager: Creates a draft Pull Request with the new rule in your detection repository, ready for human review.
Step 3: Running the Pipeline
You can trigger the pipeline for various inputs.
To analyze a specific MITRE technique and create a missing detection:
npm run orchestrate -- --type technique --input "T1566.004 Spearphishing Voice"
The tool will identify that this technique has no existing coverage and create a new detection for it[reference:12].
To analyze a new CISA alert:
npm run orchestrate -- --type cisa_alert --url https://www.cisa.gov/news-events/alerts/...
To analyze a threat report file:
npm run orchestrate -- --type threat_report --file ./report.md
Step 4: Testing the Generated Detections
The platform can be integrated with Atomic Red Team to run tests against a lab environment, validating that the newly generated detection rules actually fire as intended[reference:13]. This creates a closed-loop system for continuous detection validation.
3. Understanding and Mitigating the LOLDrivers Threat
“Living Off the Land Drivers” (LOLDrivers) are a critical threat where attackers weaponize legitimate, signed kernel drivers to bypass security controls[reference:14]. These drivers can be exploited to read/write arbitrary kernel memory, disable EDR hooks, and bypass even advanced protections like Hypervisor-protected Code Integrity (HVCI)[reference:15]. The LOLDrivers project provides a centralized, community-curated repository of these vulnerable and malicious drivers, complete with hashes and behavioral metadata[reference:16].
Step-by-Step Guide: Proactive Driver Mitigation with WDAC and Sigma
This guide demonstrates how to use the LOLDrivers data to proactively defend your Windows endpoints.
Step 1: Accessing the LOLDrivers Data
The primary resource is the official website loldrivers.io[reference:17]. For automation, the project’s GitHub repository contains YAML files for each driver, as well as pre-built detection rules.
Step 2: Implementing Windows Defender Application Control (WDAC) Policies
One of the most effective mitigations is to block known vulnerable drivers using a WDAC policy. The LOLDrivers project provides a WDAC policy that can be directly applied to your systems[reference:18].
Locate the WDAC Policy: The policy is available in the `detections/wdac` directory of the LOLDrivers GitHub repo.
Deploy the Policy:
- Convert the policy binary (if necessary): The raw `.xml` WDAC policy needs to be converted to a binary `.bin` file for deployment.
Using the ConvertFrom-CIPolicy cmdlet ConvertFrom-CIPolicy -XmlFilePath ".\LOLDrivers_Blocklist.xml" -BinaryFilePath ".\LOLDrivers_Blocklist.bin"
- Deploy to Local Machine: Copy the `.bin` and `.xml` files to `%windir%\System32\CodeIntegrity\CiPolicies\Active\` and restart the system.
- Audit Mode First: It is highly recommended to first deploy the policy in Audit Mode to verify it does not block legitimate drivers. Set the policy’s rule to `Audit Mode` before full enforcement.
Step 3: Detecting LOLDrivers with Sigma Rules
The project includes a comprehensive set of Sigma rules to detect the loading or exploitation of known vulnerable drivers[reference:19]. These rules can be integrated into your SIEM.
Access Sigma Rules: The rules are located in the `detections/sigma` directory of the repository.
Implementing in Your SIEM (e.g., Splunk, Sentinel): Convert the Sigma rule to your SIEM’s query language (e.g., SPL or KQL). A common detection involves monitoring the `DeviceImageLoadEvent` (Event ID 6) for driver file hashes or names that match the LOLDrivers blocklist[reference:20].
Example Sigma Rule Logic (Simplified):
title: Detection of LOLDriver Load status: experimental logsource: product: windows service: sysmon detection: selection: EventID: 6 ImageLoaded: - '\capcom.sys' - '\gdrv.sys' condition: selection
This rule would trigger an alert if Sysmon logs an image load for any of the listed known vulnerable driver names.
Step 4: Active Hunting with PowerShell
You can also proactively scan your systems for the presence of known LOLDrivers using a simple script.
Check Loaded Drivers against LOLDrivers list: The following PowerShell script, based on community efforts, compares the drivers currently loaded in the system’s memory against a local copy of the LOLDrivers hash list[reference:21].
A simple script to check loaded drivers against a loldrivers.io list (CSV format)
$lolDriverHashes = Import-Csv -Path "C:\path\to\loldrivers_hashes.csv"
$loadedDrivers = Get-WindowsDriver -Online | Select-Object -ExpandProperty Driver
foreach ($driver in $loadedDrivers) {
if ($lolDriverHashes.Hash -contains $driver.Hash) {
Write-Warning "Vulnerable LOLDriver found: $($driver.Name)"
}
}
Note: A more comprehensive script would involve downloading and parsing the YAML files directly from the LOLDrivers GitHub repository.
What Undercode Say:
- Key Takeaway 1: The Security Detections MCP is a force multiplier for blue teams, turning weeks of manual rule correlation into seconds of AI-driven queries.
- Key Takeaway 2: Autonomous detection engineering represents the future of security operations, where AI not only identifies coverage gaps but also drafts and validates mitigations.
The Security Detections MCP server is more than a tool; it’s a paradigm shift for detection engineering. By leveraging the Model Context Protocol, it empowers defenders to query a vast, unified repository of threat intelligence using natural language, breaking down the silos between different SIEM platforms. The autonomous 3.0 pipeline takes this a step further, automating the entire detection lifecycle from threat report to validated rule. When combined with proactive defense strategies like the LOLDrivers blocklist for WDAC, security teams can move from a reactive stance to a predictive and automated posture. The future of cybersecurity is not just about collecting more data, but about enabling AI to understand, correlate, and act on that data intelligently.
Prediction:
As AI agents become ubiquitous, the attack surface will shift dramatically towards the interfaces that connect them, like MCP. Tools like the Security Detections MCP are the vanguard of this new frontier, but the arms race will intensify. Expect to see an explosion of malicious MCP servers designed for tool poisoning and data exfiltration, countered by a new class of security products focused on MCP governance, inline policy enforcement, and runtime anomaly detection. The role of the security analyst will evolve from a manual rule-writer to an AI workflow orchestrator, responsible for validating and tuning autonomously generated defenses. Organizations that fail to adopt these AI-driven detection and response frameworks will find themselves hopelessly outmatched.
▶️ Related Video (90% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Michaelahaag Im – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
