Detection Engineering at Scale
Production-ready SPL, KQL, and Sigma detection rules for every threat we track. Written by analysts, mapped to MITRE ATT&CK, and ready to deploy to your SIEM.
The discipline behind finding threats in your environment
Detection engineering is the practice of designing, building, testing, and maintaining detection logic that identifies adversary behaviors in security telemetry. Unlike signature-based antivirus or simple IOC matching, detection engineering focuses on behavioral patterns — the specific sequences of process executions, registry modifications, network connections, and API calls that distinguish malicious activity from normal operations. It requires deep knowledge of both attacker tradecraft and the data sources that your security stack generates.
Threadlinqs approaches detection engineering as a continuous process tied directly to threat intelligence. Every threat published on our platform ships with detection rules authored across three formats, each mapped to specific MITRE ATT&CK techniques and tested against representative log data. This closes the gap between learning about a threat and being able to detect it — reducing mean-time-to-detect from weeks to the moment you deploy the rule.
Three formats. Every major SIEM.
Each threat on Threadlinqs includes detection rules in SPL, KQL, and Sigma. This ensures coverage whether your SOC runs Splunk, Microsoft Sentinel, or any platform that supports the open Sigma standard. Rules are written with production constraints in mind — accounting for field normalization, index performance, and false-positive tuning.
Splunk
Search Processing Language queries optimized for Splunk Enterprise and Splunk Cloud. Written against CIM-normalized data models with index and sourcetype scoping.
Microsoft Sentinel
Kusto Query Language rules for Microsoft Sentinel, Defender for Endpoint, and Azure Monitor. Designed for analytics rules with proper entity mapping.
Universal YAML
Sigma rules in the open standard YAML format. Convert to any backend — QRadar, Elastic, Chronicle, Palo Alto XSIAM — using SigmaHQ converters or pySigma.
A detection library built for real workflows
The detection library is not a static list. It is a filterable, searchable interface designed for analysts who need to find the right rule and deploy it quickly. Every rule carries metadata — severity, confidence, MITRE mapping, detection type, and the source threat — so you can make informed decisions about what to deploy and where.
Multi-Select Filtering
Filter by detection type, severity, confidence, MITRE tactic, index, sourcetype, table, author, or threat actor. Combine filters with AND/OR logic to narrow from 3,553 rules to exactly the set your environment needs.
Severity & Confidence Badges
Every rule is tagged with a severity level (critical, high, medium, low) and a confidence score. High-confidence, high-severity rules are your priority deploys. Low-confidence rules may need tuning for your environment.
MITRE Mapping Per Rule
Each detection rule links to one or more MITRE ATT&CK techniques with tactic context. This lets you measure coverage gaps — see which techniques across initial access, execution, persistence, and lateral movement have active detections.
One-Click Copy
Copy any rule to your clipboard with a single click. No account required for browsing; authenticated users can save rules to a personal library and export detection packages grouped by threat or MITRE technique.
Detection Type Tabs
Toggle between SPL, KQL, and Sigma views instantly. The library remembers your preferred format so you see relevant rules first. Each tab shows a syntax-highlighted code block with the full query.
Linked Threat Context
Every detection links back to its parent threat with full context — attack timeline, IOCs, MITRE techniques, and actor attribution. Understand why the rule exists, not just what it searches for.
From threat to detection in one workflow
Threadlinqs integrates threat intelligence and detection engineering into a single pipeline. When a new threat is published, detection rules are authored against the documented TTPs and IOCs, mapped to ATT&CK, and made available in the library within the same publish cycle.
Threat Published
A new threat is researched and published with full TTP analysis, timeline, IOCs, MITRE mappings, and actor attribution. The threat becomes the source of truth for detection authoring.
->Detections Generated
SPL, KQL, and Sigma rules are authored for each behavioral TTP. Rules target specific log sources — process creation, network connections, registry, DNS — and are tested for accuracy and noise.
->Deploy to SIEM
Copy rules directly from the library into Splunk saved searches, Sentinel analytics rules, or your Sigma pipeline. Each rule includes the metadata needed for triage: severity, confidence, and technique context.
503 MITRE ATT&CK techniques with active detections
Detection rules across the Threadlinqs library map to 503 individual MITRE ATT&CK techniques spanning all 14 tactics — from Reconnaissance and Resource Development through Impact. This is not theoretical mapping. Each technique linkage means at least one production-ready detection rule exists that targets the specific behavior described by that technique.
The coverage is weighted toward the tactics that matter most in post-compromise detection: Execution (T1059 variants), Persistence (scheduled tasks, registry run keys, DLL side-loading), Defense Evasion (process injection, timestomping, indicator removal), and Command and Control (DNS tunneling, encrypted channels, protocol abuse). These are the stages where detection has the highest signal-to-noise ratio and where SOC analysts make the most impactful interventions.
Detections connected to the full intelligence picture
Detection rules do not exist in isolation. On Threadlinqs, every detection is linked to the threat intelligence, MITRE coverage analysis, and actor attribution that produced it. This means your detection deployment decisions are informed by the full context of who is using a technique, how prevalent it is, and what other indicators surround it.
Threat Intelligence
Each detection links to a fully documented threat with attack timelines, IOC lists, and TTP breakdowns. When you deploy a rule, you understand the adversary behavior it targets and the campaign context behind it.
MITRE Coverage Map
View your detection coverage across the full ATT&CK matrix. Identify gaps in specific tactics, prioritize techniques used by threat actors targeting your industry, and track coverage growth over time.
Actor Attribution
Detections are linked to the threat actors who use each technique. Filter rules by actor group — APT28, Lazarus, TeamPCP — and build detection packages tailored to the adversaries most relevant to your organization.
Common questions
What SIEM platforms do these detections support?
SPL rules are written for Splunk Enterprise and Splunk Cloud. KQL rules target Microsoft Sentinel and Defender for Endpoint. Sigma rules can be converted to any backend including Elastic, QRadar, Chronicle, Palo Alto XSIAM, and Sumo Logic using the SigmaHQ converter toolchain or pySigma.
How often are new detections published?
New detections are published with every new threat on the platform. As of April 2026, the library contains 3,553 rules across 344 threats. New threats and their associated detections are published multiple times per week.
Do I need a paid plan to access detections?
The detection library is browsable on the free Blue Analyst tier. Full detection rule content, copy functionality, and library save features are available starting at the Red Professional tier. Sigma rules and advanced filtering require Purple SME or higher.
Are detections tested before publishing?
Yes. Each rule is validated against representative log data for syntactic correctness and logical accuracy. Severity and confidence ratings reflect the expected false-positive rate and detection fidelity. Rules targeting high-noise data sources like DNS or process creation include tuning guidance.
3,553 detection rules across SPL, KQL, and Sigma — ready for your SIEM.
[ explore_detections ]