detection-review: weekly Sigma corpus review

[github-actions]

detection-review: weekly Sigma corpus review — 2026-07-15

I have everything I need. Verified: T1557.001 is now titled "Name Resolution Poisoning and SMB Relay" (NTLM relay), T1187 is Forced Authentication (coercion/PetitPotam), T1555 covers DPAPI — all valid. Here's the review.

---

Detection review — detections/sigma/ (whole corpus, 2026-07-15)

Scope reviewed: all 65 rules / 68 documents. Sibling ../dotfiles-Kali is present, so the red↔blue mirror dimension is in scope and drives the top findings. CI-proven facts (parse, compile, tag/coverage drift) are trusted and not re-litigated.

Headline: The mechanical and judgment quality of the rules that exist is high — the AD invariant rules detect the right thing (Kerberoast RC4 downgrade, DCSync replication right, LSASS via Sysmon-10, potato's dual User/SubjectUserName handling, wmiexec's parent+redirect pairing), the value_count correlation pattern is used correctly, and logsource↔field coherence is clean (every *_4688 rule correctly declares category: process_creation rather than keying Sysmon fields off a Security-log source — the classic dead-field trap is absent). The problem is coverage shape, not rule craft: the corpus has grown a large SaaS/CI-CD wing while the red mirror and this repo's own methodology stay on-prem/AD-centric — and the unanswered red entries cluster in exactly the two methodology rows the corpus is thinnest on.

---

1. Lateral Movement has no 4624 detection at all — the methodology's named invariant is unimplemented ⟵ strongest finding

• Gap: DEFENSE-METHODOLOGY.md names "4624 type 3, Zeek SMB" as the primary data source for Lateral Movement. grep confirms zero rules reference 4624 / LogonType anywhere in the corpus. All three lateral_movement/ rules are 4688 process-exec derivatives (rdp-hijack, psexec-7045, wmiexec). Kali's companion-generated lateral-4624-fanout (one source → many hosts, type-3 network logon — the pass-the-hash / credential-reuse invariant) has no blue answer.
• Why it matters: This is the most central lateral-movement invariant in the threat model, it's a first-class companion-generated red entry (not a hand-note), and the auth succeeds — so none of the 4688 rules can ever see it. It's a structural hole, not a tuning gap.
• Proposed change: Author a value_count correlation exactly like password_spray_4625 / sharphound_ldap_sweep_4662: base rule on EventID:4624 LogonType:3 (filter -/::1/machine loopback), group-by source address, dc(host) > N over a short window. The repo already owns this pattern; this is a copy-and-retarget.
• ATT&CK: T1021 (Remote Services) / T1550.002 (Pass the Hash). Confidence: high.

2. Coercion / relay (5145 pipes) is half-covered — two companion-gen attacks unanswered

• Gap: Methodology row "Coercion / Relay / AD CS | 5145 pipes, 4886 SAN" only has the 4886 half (adcs_esc1_san_mismatch_4886). The only 5145 detection in the whole corpus is gpp_cpassword_sysvol_5145. Missing, both companion-generated in PURPLE-TEAM.md:
  • coercion-5145 — named-pipe access (spoolss/efsrpc/lsarpc/netlogon/lsass) over IPC$. Sigma-expressible (same shape as the gpp rule). → T1187 Forced Authentication (verified — PetitPotam/EfsRpc).
  • dpapi-backupkey-5145 — RelativeTargetName: protected_storage over IPC$ on a DC; near-zero-FP. Sigma-expressible. → T1555 Credentials from Password Stores (verified).
• Note (don't over-scope): the third relay entry, ntlm-relay-4624 (workstation↔source mismatch, T1557.001 — verified, MITRE recently retitled it "Name Resolution Poisoning and SMB Relay"), is a field-to-field comparison Sigma can't express — same limitation adcs_esc1 documents. Leave it as a documented backend/correlation task, not a Sigma rule.
• Proposed change: Author coercion-5145 and dpapi-backupkey-5145 as single-selection rules under credential_access/ (mirrors the gpp rule). Confidence: high for both being real, actionable gaps.

3. vault/vault_bulk_secret_read.yml — noise by construction; title ≠ detection

• The rule: titled "bulk secret read," but the detection is type:request, request.operation:read, request.path|startswith 'secret/' with a bare condition: selection — i.e. it fires on every single secret read, with no count, threshold, or correlation. Secret reads are among the highest-volume events in any Vault deployment.
• Why it matters: This violates the repo's own philosophy ("a muted rule is a blind spot"). Shipped as-is it fires on 100% of normal application traffic → instantly muted → the T1555 "bulk exfil" intent is silently lost. The level: low half-acknowledges this, but a low-severity rule that matches all traffic is pure fatigue, not signal.
• Proposed change: Convert to a value_count correlation (the pattern already in password_spray/sharphound): base on the single read, group-by principal/token, alert on dc(path) > N distinct secrets in a window. That actually detects bulk read and matches the title. Confidence: high.

4. Two more SaaS rules are over-broad → alert fatigue

• snowflake/snowflake_data_unload.yml — query_type: 'UNLOAD' alone. UNLOAD/COPY INTO <stage> is routine nightly ETL in most Snowflake shops; with no filter for known stages/service accounts or volume threshold, this is benign-heavy. Proposed: filter known unload stages/roles, or make it a volume/first-seen correlation.
• cloud/entra_illicit_consent_grant.yml — OperationName: 'Consent to application' fires on all user consent, not just illicit/high-privilege grants. Proposed: scope to admin-consent operations or high-risk scopes, or exclude first-party/known app IDs. (Check gws_illicit_oauth_grant for the same shape.)
• Confidence: medium — depends on each environment's baseline, but both are muting risks worth a human look.

5. No rogue-account-creation (4720/4722) rule — basic persistence gap

• Gap: grep confirms no 4720/4722 rule. Kali documents rogue account creation (hand-authored, 4720 paired with 4722); it's persistence 101 (T1136 Create Account) and trivially Sigma-expressible. Its absence next to the sophisticated AD rules (DCShadow, RBCD, shadow-creds) is conspicuous.
• Proposed change: Add a persistence/ rule on EventID:4720 (optionally correlated with 4722). Confidence: high it's a real gap; medium on priority (noisier than the invariant-based rules above).

6. Two AD rules ship live placeholder filters — CI can't catch these

• privilege_escalation/rbcd_allowedtoact_5136.yml → filter_delegation_admins: SubjectUserName: ['svc_delegation'] (# replace with your…).
• defense_evasion/dcshadow_rogue_dc_4742.yml → filter_real_dcs: TargetUserName: ['DC1$','DC2$'] (# replace with…).
• Why it matters: structurally valid, so sigma.yml passes them — but as shipped the allowlists match nothing real. dcshadow is low-risk (GC-SPN selection is rare enough to carry it). rbcd is the concern: without the real delegation-admin list, every legitimate delegation write alerts; the description's intent ("a write from a normal user is the anomaly") isn't actually encoded — the rule can't distinguish admin from user, it just excludes one fake name.
• Proposed change: Document these as deploy-time-required substitutions (a comment isn't enforcement) or add a lint note; for rbcd, consider pairing with the 4741 computer-account-create burst the description already mentions to regain fidelity without the allowlist. Confidence: needs-a-human-look — intended deployment convention matters here.

---

Lower-priority / noted, not recommended this cycle

• Golden/Silver ticket, unconstrained-delegation (companion-gen in the mirror) are absence-based or field-comparison detections the red doc itself marks soft — poor Sigma fits; leave as backend correlations.
• adcs_esc1_san_mismatch_4886 is deliberately a broad triage surface (can't do the SAN↔Requester comparison in Sigma) — transparently self-documented, so not a finding.
• LOLBAS / obfuscated-command-line (hand-authored red) are intentionally noisy hunts — low value as Sigma alerts.

Bottom line

Rule craft is solid and matches the methodology's "detect the invariant" philosophy; CI's mechanical gate plus this corpus's scoping discipline are in good shape. The material gaps are all coverage breadth on the on-prem side — the corpus invested heavily in SaaS/CI-CD while leaving the two AD rows its own methodology prioritizes (Lateral Movement 4624, Coercion/Relay 5145) partly or wholly unanswered, despite first-class companion-generated red entries existing for them. Findings 1 and 2 are the highest-value work: central techniques, documented attacks with no blue answer, and both authorable with patterns the repo already owns.

No edits made (report-first). If any finding is adopted, the new/edited rule goes under detections/sigma/ and the author regenerates the drift-gated artifacts (gen-navigator.sh, gen-coverage.sh, gen-siem.sh) so sigma.yml gates the result — keeping the red↔blue split intact.

Sources: T1557.001 · T1187 · T1555

Filed by the claude-routines workflow. Report-first: review and act — nothing was changed.