Threat Intel Campaign

Threat Intelligence Campaign Authoring — Instructions

Purpose

This skill converts published threat-intelligence reporting into tested, tuned, publish-ready threat-hunting campaigns that land in queries/threat-intelligence/YYYY-MM/. It exists to be driven either:

• Interactively — a human gives one article URL ("read this article and write/test/tune hunts"), or
• Unattended — a scheduled automation passes a feed URL and the skill triages everything published in a recent window.

It does the authoring (parse → triage → relevance gate → write → test → tune → publish files → regenerate manifest/TOCs). It deliberately does NOT create branches, commits, or pull requests. That orchestration — and the per-article PR isolation — belongs to the calling workflow. This keeps the skill reusable and free of git side effects when a human runs it.

What this skill produces:

📑 TABLE OF CONTENTS

1. Critical Workflow Rules
2. Prerequisites
3. Inputs / Parameters
4. Invocation Modes
5. Execution Workflow — Phase 0–6
6. The Relevance Gate (Huntability Rubric)
7. Writing / Testing / Tuning Queries
8. Campaign File Format
9. Structured Output Contract
10. In-Chat Hunt Findings Summary
11. Known Pitfalls
12. Quality Checklist

⚠️ CRITICAL WORKFLOW RULES - READ FIRST ⚠️

1. No git side effects. This skill NEVER runs git commit, git push, gh pr create, or any branch operation. It writes files and regenerates the manifest/TOCs only. Publishing (branch + commit + PR per article) is the calling automation's job. If a human is running this interactively, leave the files in the working tree for them to review.

2. feed_url is a parameter — nothing vendor-specific is hardcoded. The skill handles any RSS 2.0 or Atom feed. The Microsoft Threat Intelligence feed is just one value a caller may pass; do not assume it.

3. Advanced Hunting (≤30d) is the primary test/tune engine. Write and validate every query against RunAdvancedHuntingQuery within a 30-day window. Fall back to the Sentinel Data Lake (query_lake, >30d) only when you need additional supporting evidence that AH's 30-day cap cannot provide (e.g., confirming a rare IOC's longer-term absence/presence). Follow the Tool Selection Rule and timestamp-adaptation guidance in copilot-instructions.md.

4. ⛔ Evidence-based "tested" claims only. A query may be described as tested in the campaign file only if it was actually executed. If a query could not be run (table absent, AH safety filter, telemetry gap), say so explicitly and mark cd_ready: false with honest adaptation_notes. Never imply validation that did not happen. Follow the Evidence-Based Analysis rule in copilot-instructions.md.

5. ⛔ Committed output is PII-free — but published IOCs are NOT PII. Test/tune runs against the live tenant, but campaign files are version-controlled. NEVER paste real tenant entities (your UPNs, hostnames, IPs, workspace/tenant GUIDs, app names) into a campaign file. The article's published IOCs (hashes, domains, URLs, certs, filenames) are the opposite — they are public, shareable, and MUST be included verbatim in the IOC Reference table and the IOC-sweep queries (this is how the committed companion files do it). Do not placeholder or omit a published IOC. Concrete tenant findings from test runs belong in the In-Chat Hunt Findings Summary, not the file. Perform a PII sanity-check before finalizing each file.

6. ⛔ Every IOC must trace to the article. Never invent one. Copy IOCs from the article's "Indicators of compromise" table (and any inline-cited indicators) exactly. Before finalizing, re-open the article's IOC section and confirm each hash/domain/URL/filename in your file appears there character-for-character. Hallucinated or mis-transcribed IOCs are a critical evidence-integrity failure — they produce false detections and erode trust. If an indicator only appears in narrative prose (not the IOC table), label it as such.

7. Reference, don't reinvent. Use the kql-query-authoring skill's discipline for query construction (schema validation via kql-search MCP, table pitfalls, TimeGenerated vs Timestamp), and the detection-authoring skill's CD Metadata Contract for the <!-- cd-metadata --> block on every query. Read those SKILL.md files when authoring.

8. Workspace selection. Follow the SENTINEL WORKSPACE SELECTION rule in copilot-instructions.md. In unattended runs the caller will specify the workspace; if exactly one exists, auto-select and state it.

9. Read config.json for workspace ID, tenant, and Azure MCP parameters before querying.

10. Quiet runs are a success, not a failure. If nothing in the window qualifies, that is a valid, expected outcome. Emit an empty/"skipped"-only result set and stop — do not lower the bar to manufacture a campaign.

Prerequisites

Feed parsing uses Python stdlib (xml.etree.ElementTree) so it works unattended without pip install. feedparser may be used if already installed, but never assume it.

Inputs / Parameters

Invocation Modes

A. Single-article mode — caller passes article_url (the classic "read this article and write hunts" prompt). → Skip Phase 1 (feed) and the time filter. Still run Phase 2 (dedup) and Phase 3 (relevance gate) unless the human explicitly says "build it regardless". Then Phases 4–6 for that one article.

B. Feed mode — caller passes feed_url (+ optional lookback_hours). → Full Phase 0–6 across all qualifying entries in the window, capped at max_campaigns.

Execution Workflow

Phase 0 — Setup

1. Read config.json (workspace ID, tenant, subscription, Azure MCP params).
2. Resolve workspace per the selection rule. State which workspace is in use.
3. Confirm kql-search + Triage MCP are available (needed for testing).

Phase 1 — Fetch & parse the feed (feed mode only)

Fetch feed_url and parse entries with Python stdlib so it works for both RSS and Atom:

import sys, urllib.request, datetime as dt
import xml.etree.ElementTree as ET
from email.utils import parsedate_to_datetime

feed_url = sys.argv[1]
lookback_hours = int(sys.argv[2]) if len(sys.argv) > 2 else 24
cutoff = dt.datetime.now(dt.timezone.utc) - dt.timedelta(hours=lookback_hours)

raw = urllib.request.urlopen(urllib.request.Request(feed_url, headers={"User-Agent": "ti-campaign/1.0"}), timeout=30).read()
root = ET.fromstring(raw)
ATOM = "{http://www.w3.org/2005/Atom}"

def text(el, *tags):
    for t in tags:
        for tag in (t, ATOM + t):
            f = el.find(tag)
            if f is not None and f.text:
                return f.text.strip()
    return None

def parse_date(s):
    if not s: return None
    try: return parsedate_to_datetime(s)              # RSS pubDate
    except Exception:
        try: return dt.datetime.fromisoformat(s.replace("Z", "+00:00"))  # Atom ISO
        except Exception: return None

entries = list(root.iter("item")) or list(root.iter(ATOM + "entry"))  # RSS first, else Atom
for e in entries:
    title = text(e, "title")
    link = text(e, "link")
    if not link:
        a = e.find(ATOM + "link")
        link = a.get("href") if a is not None else None
    pub = parse_date(text(e, "pubDate", "published", "updated"))
    if pub and pub >= cutoff:
        print(f"{pub.isoformat()}\t{title}\t{link}")

Run it with the powershell tool (python script.py <feed_url> <lookback_hours>). Collect (published, title, link) for entries inside the window. If the feed only exposes summaries, you'll fetch full bodies in Phase 3.

Phase 2 — Dedup against existing campaigns

For each candidate URL, check whether it's already been turned into a campaign:

• grep for the article URL (and a normalized form without trailing slash / query string) across queries/threat-intelligence/**.
• Also grep the proposed slug. If a match exists → mark decision: "skipped", reason: "already published", and drop it from the work list.

Phase 3 — Relevance gate

For each remaining candidate, fetch the full article body (web_fetch) and apply the Huntability Rubric. Produce a decision (campaign / skipped) with a one-line reason. Rank campaign candidates by huntability confidence and keep the top max_campaigns.

Phase 4 — Write / test / tune (per qualifying article)

See Writing / Testing / Tuning Queries. Output: a set of validated queries, each with an honest cd-metadata block and tuning notes.

Phase 5 — Publish the campaign file

Write queries/threat-intelligence/YYYY-MM/<slug>.md in the exact Campaign File Format. YYYY-MM = the article's publication month. <slug> = short, kebab/underscore, descriptive (e.g., soho_router_dns_hijacking). Do NOT hand-write the Quick Reference TOC — generate_tocs.py creates it.

Phase 6 — Regenerate artifacts + emit results

1. python .github/manifests/build_manifest.py (regenerate + validate; fix any error-level warnings on your new file).
2. python scripts/generate_tocs.py (insert the Quick Reference TOC).
3. Emit the Structured Output Contract JSON + a human summary.
4. Emit the In-Chat Hunt Findings Summary — the per-article report of what the test runs actually found (hits, false positives to tune, follow-up actions). Chat/run output only; never write it to a tracked file.
5. Stop. No git.

The Relevance Gate — Huntability Rubric

This is the judgment step: does this article warrant a hunting campaign? Decide with explicit gates, not vibes. Cite the evidence from the article for each gate.

Hard gates (BOTH must PASS to build)

Confidence signals (raise/lower priority among passing candidates)

Auto-skip categories (do not build)

• Product/feature announcements, GA/preview notices, roadmap posts
• Analyst-recognition / "named a Leader" / awards
• Strategy, opinion, policy, or business-update posts
• Event/webinar recaps and partner marketing
• Pure data-breach news with no attacker TTPs/IOCs

Decision rule

BUILD if G1 PASS and G2 PASS and (concrete IOCs present OR ≥2 distinct mappable TTPs). Otherwise SKIP with a specific reason (which gate failed / which auto-skip category).

Record the rubric outcome in the structured result reason field (e.g., "BUILD: 4 IOCs + 6 mappable TTPs (endpoint, identity)" or "SKIP: product announcement, G1 fail").