Building Your First SOC Detection Library with MITRE ATT&CK

Every SOC eventually faces the same question: “how do we know what we can catch?” The honest answer is usually “we don’t, and that’s why we keep getting surprised.”

A SOC detection library is the cure for that surprise. It’s a curated, versioned, mapped-to-MITRE-ATT&CK set of rules that tells you — concretely — which adversary behaviors you can see, which you can’t, and what work is in flight. If you don’t have one yet, this guide walks you through building the first version in a way that will actually survive contact with production.

Step 1: Get Your Logs in Order Before You Write a Single Rule

Detection engineering without telemetry is a creative writing exercise. Before you start drafting a detection library, audit what you’re actually collecting. A minimum viable log stack looks like this:

• Windows Security events — especially 4624, 4625, 4648, 4672, 4688 (with command-line auditing enabled), 4697, 4698, 4720, 4732. Without 4688 command lines, half of the ATT&CK execution tactic is invisible.
• Sysmon or EDR process telemetry — Sysmon Event IDs 1 (ProcessCreate), 3 (NetworkConnect), 7 (ImageLoad), 10 (ProcessAccess), 11 (FileCreate), 13 (RegistryValueSet). EDR equivalents (Defender DeviceProcessEvents, CrowdStrike ProcessRollup2) give you the same signal with better normalisation.
• Firewall + DNS logs — egress firewall and recursive DNS resolver logs. These carry lateral movement, C2 beaconing, and data exfiltration signal that endpoints will miss.
• Cloud audit logs — Azure AD sign-in logs, Microsoft 365 Unified Audit Log, AWS CloudTrail, GCP Audit Logs. The identity plane is where modern intrusions pivot.
• Identity telemetry — Active Directory event logs (domain controllers), Kerberos ticket events (4768, 4769, 4771), and if you have it, Microsoft Defender for Identity or equivalent.

If any of these are missing, fix that first. A detection library built on incomplete telemetry is a library full of detections that silently fail.

Step 2: Prioritise — Don’t Start with All 704 Techniques

MITRE ATT&CK currently has over 700 techniques and sub-techniques. You cannot write quality detections for all of them in week one, and if you try, you’ll produce noise. Prioritisation is the single most important skill in detection engineering.

Three inputs should drive your first pass:

1. Prevalence in real intrusions. Certain techniques show up in almost every incident report: PowerShell execution, LSASS dumping, scheduled task persistence, spearphishing attachments, RDP lateral movement. Start here.
2. Threat intel relevant to your sector. If you’re in finance, APT38 and FIN groups matter. If you’re in healthcare, ransomware affiliates matter. If you’re a UK MSP, NCSC and CISA advisories for the last 12 months matter. Map the techniques those actors use.
3. Your telemetry reality. You can only detect what you can see. Filter the above two lists against your current log coverage.

The intersection is your week-one backlog.

Step 3: The Top 30 to Cover First

If you want a concrete starting point, these are the sub-techniques that earn their spot in a week-one SOC detection library. They are high-prevalence, high-impact, and almost always detectable with the minimum telemetry stack above.

Execution

• T1059.001 — PowerShell
• T1059.003 — Windows Command Shell
• T1059.005 — Visual Basic
• T1047 — Windows Management Instrumentation
• T1204.002 — Malicious File

Persistence

• T1053.005 — Scheduled Task
• T1547.001 — Registry Run Keys / Startup Folder
• T1543.003 — Windows Service
• T1136.001 — Local Account Creation

Privilege Escalation / Defense Evasion

• T1055 — Process Injection
• T1218.005 — Mshta
• T1218.011 — Rundll32
• T1070.001 — Clear Windows Event Logs
• T1562.001 — Disable or Modify Tools

Credential Access

• T1003.001 — LSASS Memory
• T1110.003 — Password Spraying
• T1558.003 — Kerberoasting
• T1555 — Credentials from Password Stores

Discovery

• T1087.002 — Domain Account Discovery
• T1018 — Remote System Discovery
• T1482 — Domain Trust Discovery

Lateral Movement

• T1021.001 — Remote Desktop Protocol
• T1021.002 — SMB/Windows Admin Shares
• T1021.006 — Windows Remote Management

Command & Control / Exfiltration / Impact

• T1105 — Ingress Tool Transfer
• T1071.001 — Web Protocols (HTTP/S C2)
• T1572 — Protocol Tunneling
• T1048 — Exfiltration Over Alternative Protocol

Initial Access

• T1566.001 — Spearphishing Attachment
• T1566.002 — Spearphishing Link
• T1078 — Valid Accounts

That’s about 30 techniques. If you cover those well, you will catch the behaviour driving the majority of real-world intrusions. The long tail of ATT&CK is worth covering eventually — not in week one.

Step 4: The Detection Development Loop

Once you have a prioritised list, every detection in your library should go through the same five-stage loop:

Research → Query → Test → Tune → Promote.

Research. Read the MITRE page for the technique. Read recent incident reports that reference it. Look at the Atomic Red Team tests. Understand why an attacker uses the technique and what the byproducts on the endpoint are. If you can’t describe the attacker’s objective in one sentence, stop and read more.

Query. Draft the detection in your SIEM’s native language. Use verbatim field names (not pseudocode), name the required tables, and include a 24h lookback at most during development. For example, here is the starter KQL for T1059.001 — PowerShell from the df00tech library:

let SuspiciousPatterns = dynamic([
  "-EncodedCommand", "-enc ", "-e ", "-ec ",
  "Invoke-WebRequest", "IWR ", "Invoke-RestMethod",
  "Net.WebClient", "DownloadString", "DownloadFile", "DownloadData",
  "Start-BitsTransfer",
  "AmsiUtils", "amsiInitFailed", "SetProtectionLevel",
  "Invoke-Expression", "IEX(", "IEX ",
  "-ExecutionPolicy Bypass", "-ep bypass", "-ep unrestricted",
  "-WindowStyle Hidden", "-w hidden", "-windowstyle h",
  "[Convert]::FromBase64String", "[System.Convert]::FromBase64String",
  "Invoke-Mimikatz", "Invoke-Shellcode",
  "New-Object IO.MemoryStream", "IO.Compression",
  "bitsadmin", "certutil -urlcache"
]);
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "powershell.exe" or FileName =~ "pwsh.exe"
| where ProcessCommandLine has_any (SuspiciousPatterns)
| extend EncodedCmd = ProcessCommandLine has_any ("-EncodedCommand", "-enc ", "-e ", "-ec ")
| extend DownloadCradle = ProcessCommandLine has_any ("Invoke-WebRequest", "Net.WebClient", "DownloadString", "DownloadFile", "IWR ", "Start-BitsTransfer")
| extend AmsiBypass = ProcessCommandLine has_any ("AmsiUtils", "amsiInitFailed", "SetProtectionLevel")
| extend PolicyBypass = ProcessCommandLine has_any ("-ExecutionPolicy Bypass", "-ep bypass")
| extend HiddenWindow = ProcessCommandLine has_any ("-WindowStyle Hidden", "-w hidden")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine,
         EncodedCmd, DownloadCradle, AmsiBypass, PolicyBypass, HiddenWindow
| sort by Timestamp desc

Notice what this query does well: it flags specific, meaningful patterns rather than “all PowerShell,” and it extends multiple boolean columns so an analyst can see at a glance which indicators fired. That’s production-quality output.

For credential dumping, here’s the T1003.001 — LSASS Memory detection, written in KQL against Microsoft Defender for Endpoint:

let LsassAccessTools = dynamic([
  "procdump", "procdump64", "mimikatz", "mimilib", "wce", "gsecdump",
  "lsass.exe", "sqldumper", "werfault", "taskmgr"
]);
let SuspiciousLsassAccess = DeviceEvents
| where Timestamp > ago(24h)
| where ActionType == "ProcessAccessed"
| where FileName =~ "lsass.exe"
| where InitiatingProcessFileName !in~ (
    "MsMpEng.exe", "csrss.exe", "services.exe", "lsm.exe",
    "svchost.exe", "winlogon.exe", "wmiprvse.exe", "wininit.exe",
    "SecurityHealthService.exe", "SenseIR.exe"
  )
| where InitiatingProcessGrantedAccessMask in (
    "0x1fffff", "0x1f3fff", "0x143a", "0x1410", "0x1010", "0x40"
  )
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          InitiatingProcessAccountName, InitiatingProcessGrantedAccessMask;
let ComsvcsMinidump = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "rundll32.exe"
| where ProcessCommandLine has_all ("comsvcs.dll", "MiniDump")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine;
let ProcDumpLsass = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("procdump.exe", "procdump64.exe")
| where ProcessCommandLine has "lsass"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine;
union SuspiciousLsassAccess, ComsvcsMinidump, ProcDumpLsass
| sort by Timestamp desc

This one is worth studying: a single detection fans out across three distinct attacker TTPs (Mimikatz-style direct access, comsvcs.dll MiniDump LOLBin, and ProcDump abuse) and unions the results. One rule, three paths to detection. That’s the shape good detections take.

Test. Run the query against 7–30 days of historical data. You are looking for two things: true positives (did anything real fire?) and volume (how many alerts per day would this generate?). A detection that would have produced 400 alerts a day in retrospect is not production-ready.

Tune. Add exclusions — but only for specific, documented processes and accounts, never for patterns. Document every exclusion inline with a comment explaining why. Set severity based on actual business risk, not theoretical worst case.

Promote. Move the rule from dev to production with a unique ID, an ATT&CK mapping, a list of known false positives, and a link to a triage playbook. If any of those are missing, it’s not ready.

Step 5: Track Coverage with MITRE ATT&CK Navigator Layers

Once you have detections in production, you need a way to see your coverage at a glance. The standard tool is the MITRE ATT&CK Navigator, which lets you overlay a JSON layer onto the matrix with per-technique scores.

A practical workflow:

1. Tag every detection in your SIEM with its ATT&CK technique ID.
2. Export a weekly roll-up: technique ID → number of rules → average confidence.
3. Convert to a Navigator layer JSON (the format is trivial — techniqueID, score, color).
4. Import into Navigator and render the matrix.

You can also browse the df00tech ATT&CK matrix to see what a fully-populated coverage view looks like. Empty cells make gaps concrete in a way that a spreadsheet never will, and they make the business case for detection engineering investment much easier to present.

Step 6: Validate with Atomic Red Team

A detection that has never fired in testing is a detection that doesn’t work. Atomic Red Team is the community-standard way to prove your rules actually work. The workflow:

1. Pick a detection from your library.
2. Find the matching Atomic Red Team test (they’re indexed by ATT&CK technique ID).
3. Run the atomic on a test endpoint with your full telemetry stack.
4. Confirm the alert fires within your expected SLA (under 15 minutes for critical, under an hour for high).
5. Confirm the alert contains enough context — user, host, command line, parent process — for triage without pivoting.

If any step fails, go back to the loop: fix the telemetry, the query, or the tuning. Repeat quarterly. Detection drift is real — OS updates, EDR agent changes, and schema modifications silently break things.

Step 7: Where Tools Stop and Engineering Starts

Most SOCs believe they are buying detection when they buy a SIEM, an EDR, or a threat intel feed. They aren’t. They’re buying a platform on which detection is possible. The engineering — the mapping of technique to telemetry to query to alert to response — is the work that makes the platform useful. Vendors give you starter rules; those rules are not your detection library. They are a baseline, and often a noisy one.

Your detection library is your SOC’s institutional memory. It encodes every lesson you’ve learned about your environment, every false positive you’ve suppressed with care, every technique you’ve seen in a real incident. No vendor will ever have that context. You build it, you own it, you version-control it, and you measure it.

Start Here

Browse the full df00tech detection library — 700+ KQL and SPL queries mapped to MITRE ATT&CK, free forever. Fork them, tune them, use them. Pair them with the ATT&CK matrix view to see coverage at a glance, and use specific detections like T1059.001 — PowerShell, T1003.001 — LSASS Memory, T1053.005 — Scheduled Task, T1566.001 — Spearphishing Attachment, and T1021.001 — Remote Desktop Protocol as the seed for your week-one backlog.

A SOC detection library is not built in a sprint. It’s built deliberately, technique by technique, tuned rule by tuned rule. Start with the top 30. Ship them through the full loop. Measure coverage. Then expand.

Related Posts

• Top 20 Most Important MITRE ATT&CK Techniques for SOC Analysts
• Splunk SPL vs Microsoft KQL: Detection Rule Syntax Comparison
• How to Detect PowerShell Execution Attacks