Detection Engineering & Threat Intelligence

20 min · S3

Module Objective

Detection engineering is where SOC analysts create lasting value — building the rules that catch tomorrow's attacks, not just triaging today's alerts. But the pipeline from threat report to deployed detection rule is slow: read the report, extract the techniques, map to MITRE ATT&CK, identify the data sources, write the KQL logic, test, document, and deploy. Claude accelerates every phase — compressing hours of manual work into a systematic, repeatable workflow.

Deliverable: The complete Claude-assisted detection engineering pipeline — from threat report to deployed, documented detection rule. Including MITRE ATT&CK mapping, KQL rule generation, threat briefing creation, and rule documentation using Skills for team-wide consistency.

⏱ Estimated completion: 20 minutes

Phase 1: MITRE ATT&CK mapping

Claude knows the MITRE ATT&CK framework well — it saw the entire matrix extensively during training. When you describe a detection scenario, Claude maps it to the most specific technique and sub-technique, identifies the tactic, and provides the related techniques in the attack chain (what typically precedes and follows the technique).

The mapping prompt should describe the behavior you are detecting, not just a keyword. “Map inbox rules to MITRE” produces a generic mapping. “Map the detection of inbox rules containing financial keywords created from non-corporate IPs during a suspected BEC compromise” produces T1114.003 (Email Forwarding Rule) under Collection, with T1078.004 (Valid Accounts: Cloud) preceding it and T1534 (Internal Spearphishing) following it. The specificity of the mapping matches the specificity of the prompt.

Batch mapping is where Claude saves the most time. When you have a set of detection rules that need MITRE mappings, provide them all in a single prompt. Claude maps the entire set at once — ten rules mapped in two minutes instead of thirty minutes of manual framework searching.

Phase 2: KQL detection rule generation

After mapping the technique, the next phase is writing the detection logic. The KQL generation workflow from S1 applies here, with additional constraints specific to detection rules: the query must be idempotent (safe to run repeatedly), include entity mapping for Sentinel incident creation, specify the recommended schedule and lookback window, and handle known false positive scenarios.

Worked artifact — detection rule generation prompt:

<task>
Write a Sentinel analytics rule (Scheduled type) that detects
inbox rules containing financial keywords created from
non-corporate IP addresses.
</task>

<detection_requirements>
- MITRE: T1114.003 Email Forwarding Rule (Collection)
- Table: OfficeActivity
- Operation: New-InboxRule
- Financial keywords in rule parameters: invoice, payment,
  wire, bank, transfer, remittance, account details
- Exclude IPs in CorporateExternalIPs watchlist
- Schedule: every 15 minutes, lookback 20 minutes
- Severity: High
- Entity mapping: Account (UserId), IP (ClientIP)
- Expected false positives: IT admins creating rules during
  troubleshooting, users who legitimately filter financial
  emails (rare — investigate anyway)
</detection_requirements>

<output_format>
KQL query with header comment block containing: rule name,
MITRE technique, severity, schedule, entity mapping, false
positive guidance. Inline comments on each operator.
</output_format>

Verify the generated query against your OfficeActivity table schema. Test against 30 days of historical data. Tune the keyword list and false positive exclusions for your environment before enabling in production.

Phase 3: Threat briefing creation

When a new threat report arrives (vendor advisory, CISA alert, CERT bulletin), the SOC lead often needs to brief management on the relevance to the organization. Claude converts the technical threat report into a management-ready briefing.

Upload the threat report (PDF or paste the relevant text) and ask Claude to produce a briefing that covers what the threat is (in business terms), whether it affects your organization (based on the environment context in your Project system prompt), what detection coverage you currently have, and what actions are recommended.

The briefing format should match your organization’s standard. If you brief management weekly, create a Skill for the briefing format so every briefing is consistent.

Phase 4: Detection rule documentation

Using the detection rule documentation Skill from F3, Claude produces the complete rule card — MITRE mapping, severity, data source, trigger condition, expected false positives, tuning guidance, entity mapping, the KQL query, and investigation steps. The Skill ensures every rule your team produces is documented to the same standard, regardless of which analyst writes it.

For teams managing a rule library, this documentation discipline is the difference between a collection of undocumented queries and a professional detection library that a new team member can understand and maintain.

IOC enrichment

When you receive IOCs from a threat intelligence feed (IP addresses, domains, file hashes, email addresses), Claude assists with enrichment — providing context about what the IOC is associated with, what MITRE techniques it relates to, and how to detect activity involving the IOC in your environment.

Use web search (enabled in Claude.ai) for current IOC context. Claude can search threat intelligence sources for reputation data, campaign associations, and historical activity. Combine this with a KQL generation prompt to produce a hunt query that checks your environment for the specific IOCs.

Verify all IOC enrichment. Claude’s web search retrieves publicly available information, which may be incomplete or outdated. Cross-reference Claude’s enrichment against your organization’s threat intelligence platform (if available) and primary sources (VirusTotal, AbuseIPDB, AlienVault OTX) before acting on it.

Compliance Myth

"AI-generated detection rules are less reliable than manually written rules."

Production reality: The reliability of a detection rule depends on three things: whether the logic correctly identifies the target behavior, whether the false positive rate is acceptable, and whether the rule is maintained over time. Claude-generated rules are subject to the same verification process as manually written rules — test against historical data, tune thresholds, document false positives, and review periodically. A Claude-generated rule that has been verified, tested, and documented is exactly as reliable as a manually written rule that went through the same process. The risk is not in the generation method — it is in skipping the verification step, regardless of whether the rule was written by a human or by Claude.

Try it: Run the full detection pipeline

Choose a threat report relevant to your environment (a recent CISA advisory, a vendor threat brief, or a Microsoft Security blog post). Upload it to your Security Operations project. Ask Claude to: (1) extract the key TTPs and map them to MITRE ATT&CK, (2) generate a KQL detection rule for the highest-priority technique, (3) document the rule using your standard format, and (4) produce a one-paragraph management briefing on the threat's relevance to your organization. This exercises the complete pipeline: threat report → mapping → rule → documentation → briefing. Verify the KQL against your Sentinel schema before deploying.

Knowledge checks

Check your understanding

1. A vendor threat report describes an attacker who creates inbox rules to forward emails containing financial keywords to an external address. What MITRE ATT&CK technique does this map to?

T1114.003 — Email Forwarding Rule, under the Collection tactic. The attacker is collecting emails containing financial information by creating a forwarding rule. Related techniques in the attack chain: T1078.004 (Valid Accounts: Cloud) typically precedes it (the attacker needs mailbox access first), and T1534 (Internal Spearphishing) may follow (using the compromised mailbox to phish other employees).

T1566.001 — Spearphishing Attachment

T1098 — Account Manipulation

T1114.003 Email Forwarding Rule (Collection). The technique is about collecting email data through forwarding rules, not about the initial access method that enabled mailbox access.

2. You need to produce consistent detection rule documentation across a team of five analysts. What is the most effective approach?

Give each analyst a documentation template document

Create a custom Skill that defines the documentation format and distribute it to the team. The Skill applies automatically whenever any analyst asks Claude to document a detection rule — producing consistent output across the team without each person remembering the format. On Team and Enterprise plans, admins can push Skills to all team members, ensuring uniform documentation quality.

Review each analyst's documentation manually

A distributed Skill ensures consistent documentation automatically. It scales across the team without manual enforcement and applies to every rule documentation request.

3. Claude generates a detection rule with a specific MITRE ATT&CK mapping. Should you trust the mapping?

Claude maps ATT&CK techniques well because the framework was extensively represented in its training data. However, verify the mapping against the ATT&CK matrix — especially for sub-techniques and for techniques with similar descriptions (e.g., T1114.003 Email Forwarding Rule vs T1114.002 Remote Email Collection). Claude occasionally selects a closely related technique instead of the most precise one.

Yes — Claude's MITRE mappings are always accurate

No — never trust AI for framework mapping

Trust but verify. Claude maps ATT&CK techniques well but occasionally selects a related technique instead of the most precise one. A quick check against the ATT&CK matrix confirms or corrects the mapping.

Key takeaways

The detection pipeline has five phases. Threat report → MITRE mapping → KQL rule generation → documentation → deployment. Claude accelerates all five.

Batch MITRE mapping saves the most time. Map ten rules at once instead of one at a time.

Verification applies to every phase. The KQL logic, the MITRE mapping, and the documentation all require verification before deployment.

Skills ensure team consistency. A detection rule documentation Skill distributed to the team produces uniform rule cards from every analyst.

← Compliance & Policy Generation Incident Response Documentation with Claude →