ATT&CK techniques and exploited CVEs.
7 SIEM platforms. Updated daily.

Production-ready detection rules for MITRE ATT&CK

df00tech is a library of 949 detection rules, each one mapped to a specific MITRE ATT&CK technique or sub-technique. Every rule is written to be deployed, not just read: you copy the query into your SIEM, point it at the right data source, and you have working coverage for a specific adversary behaviour. The detections span all 14 ATT&CK tactics — from initial access and execution through credential access, lateral movement and exfiltration — so you can close gaps by ATT&CK techniques rather than guessing at what your existing rules miss.

Detection engineering is the work of turning an attacker behaviour into a reliable, low-noise query. It is repetitive, version-specific, and easy to get subtly wrong. Most teams rebuild the same Kerberoasting, LSASS-dumping and malicious-PowerShell rules from scratch at every new job. df00tech exists so you don't have to: the detection rules here are free to use, kept current, and framed around the ATT&CK techniques your threat model already references. Browse the full coverage on the ATT&CK matrix, or jump straight to high-value detections like Kerberoasting (T1558.003), LSASS Memory (T1003.001), PowerShell (T1059.001) and Remote Access Tools (T1219).

One detection, seven SIEM platforms

Detection content is usually written for one query language and then stranded there. df00tech publishes each detection as ready-to-run queries for seven SIEM and EDR platforms: Microsoft Sentinel (KQL), Splunk (SPL), Elastic (EQL), QRadar (AQL), Sumo Logic, Chronicle (YARA-L) and LogScale (CQL). The same ATT&CK technique, expressed in the language your stack actually speaks, so a Splunk shop and a Sentinel shop get the same coverage without translating detection logic by hand. Rules also export to Sigma for pipelines that compile their own backend queries. Every detection ships with the data sources and log tables it needs, confidence and severity ratings to drive triage, and explicit false-positive guidance — all free to use.

Detections for exploited CVEs, updated daily

Adversaries don't only run techniques — they exploit specific vulnerabilities, and the gap between a CVE landing on CISA's Known Exploited Vulnerabilities (KEV) catalog and an attacker using it against you is short. Alongside the ATT&CK library, df00tech publishes 234 CVE detections, each one mapped to a known-exploited or actively weaponised vulnerability and shipped with the same seven SIEM queries, data-source requirements and false-positive guidance as the rest of the library. An automated research pipeline watches KEV, exploit disclosures and threat-intel reporting, and turns newly exploited CVEs into deployable detections — so the corpus grows with the threat landscape, daily, rather than going stale between releases. Browse them on the vulnerabilities page, filterable by exploit status, CVSS band, vendor and product.

How our detections are built

Each detection starts from a documented adversary behaviour, not a vendor signature. We read the relevant ATT&CK technique page, the public threat-intel reporting behind it, and the red-team tooling that exercises it, then write a query against the telemetry that behaviour actually produces — the specific Windows event ID, EDR process event, or cloud audit log, rather than a generic keyword match. The rule is mapped to its ATT&CK technique ID so coverage is auditable against the matrix, given an honest confidence and severity rating, and paired with the benign scenarios that will trigger it. We translate that logic into all seven query languages and re-validate the syntax before publishing. Detections are versioned and refreshed as ATT&CK and the underlying log schemas change.

Worked example — tuning Kerberoasting (T1558.003). A naive Kerberoasting rule alerts on every Kerberos service-ticket request that uses RC4 encryption (Windows Event 4769 with ticket encryption type 0x17). That fires constantly in real environments: legacy applications pinned to RC4 for pre-2008 compatibility, and enterprise software like Oracle and SAP that ship RC4-only Kerberos configurations, both produce a steady stream of exactly these events. The tuning is not to suppress RC4 — that blinds you to the real attack — but to baseline it: RC4 requests from legacy app servers come from a small set of fixed, known source IPs at low, consistent volume, whereas a Kerberoasting attack is one principal requesting tickets for many distinct SPNs in a short window. So we tune on the spike-and-spread, allow-list the validated legacy source IPs, and correlate 4769 volume against scheduled vulnerability-scan windows (Nessus and Qualys enumerate SPNs as part of AD health checks). The full breakdown, with the query for each platform, is on the Kerberoasting detection page.

Built for detection engineers

df00tech is built and maintained by a security engineer who got tired of rewriting the same detection rules at every new job. The goal is enterprise-grade ATT&CK coverage that a one-person SOC can deploy as easily as a large team — no proprietary taxonomy, no vendor lock-in, no six-figure tooling budget required. Read more on the about page, follow new detections and write-ups on the blog, or get in touch at [email protected].