detection-engineering-reference

Documents Windows event IDs, detection rule semantics, and MITRE mappings for TinySocs.

Updated Oct 12, 2025
One-click install
npx skills add https://github.com/lukefitzg/tinysocs --skill detection-engineering-reference-lukefitzg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: detection-engineering-reference
Source: https://github.com/lukefitzg/tinysocs/tree/main/.claude/skills/detection-engineering-reference
Command: npx skills add https://github.com/lukefitzg/tinysocs --skill detection-engineering-reference-lukefitzg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Detection engineers working on TinySocs need to know which Windows/Sysmon/FIM event IDs actually fire, what audit policies enable them, how the C# detection engine matches events, and why specific thresholds were chosen — without re-reading thousands of lines of source code and config files. ## Core Features & Use Cases - Event-ID dictionary: Maps every Windows, Sysmon, and FIM event ID used by rules to its channel, audit-policy prerequisite, consuming rules, and whether the source is live or dead under the shipped configuration. - Matching semantics reference: Explains the exact threshold_by_key evaluation logic in DetectionEngine.cs, including field_match contains/exact modes, group_by fallback behavior, sliding windows, cooldowns, and deterministic alert IDs. - MITRE coverage and false-positive theory: Documents the 16 techniques covered by the 19 enabled rules, why mitre_coverage.py's headline number is inflated, and the FP rationale behind each threshold and disable decision. - Use Case: Before tuning a brute-force rule, an engineer checks why TS-001 uses 15 failures in 5 minutes and learns the threshold sits above stale-credential retry cadence but below anything a human would type. ## Quick Start Ask what Windows event ID 4625 means, what audit policy enables it, and which TinySocs detection rules consume it.

Frequently Asked Questions about detection-engineering-reference

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What does Windows event ID 4625 mean and which rules use it?

Event ID 4625 is a failed logon from the Security channel, enabled by the Logon failure audit subcategory. In TinySocs it feeds enabled rules TS-001 (grouped by user), TS-002 (grouped by IP), and TS-071 (RDP logons with LogonType exactly 10).

How does field_match work in TinySocs detection rules?

field_match checks whether a dot-path field on the event contains (default, case-insensitive substring) or exactly equals one of the listed values. If the field is missing entirely, the match fails and the event is dropped for that rule.

Why do some TinySocs Sysmon rules never fire?

Some event sources are dead in the shipped sysmon-config.xml — for example ProcessAccess (Sysmon 10) uses onmatch include with zero rules, so TS-060 can never fire. Others like TS-091 and TS-092 are disabled purely for false-positive tuning, not dead sources.

How many MITRE ATT&CK techniques does TinySocs actually cover?

The 19 enabled C#-engine rules cover 16 unique techniques across 8 tactics. The 32-technique figure in detection-coverage.md is inflated because mitre_coverage.py counts disabled rules and the non-running Python KQL catalogue.

Why is the brute-force threshold 15 failures in 5 minutes?

The threshold sits above the natural retry cadence of the most common benign cause — a service or mapped drive with a stale saved password — and below anything a human would hand-type. Fifteen failures in five minutes against one account indicates automation.

When should I not use this detection reference skill?

Do not use it for adding new rules or writing Atomic Red Team tests (that is the detection-validation toolkit), deciding whether to promote a candidate rule (research methodology), or understanding the dual-engine architecture and signed-pack trust path (architecture contract).