Allow-List Patterns — Writing Exclusions That Don't Open Blind Spots

Adding an exclusion is easy. Adding one that doesn’t create a worse problem than the noise it suppresses — that’s the engineering discipline. Every exclusion is a documented blind spot. This lesson covers the patterns for writing exclusions that are narrow enough to suppress only the legitimate use case without giving attackers a free path.

The Exclusion Safety Hierarchy

From most specific (safest) to least specific (most dangerous):

Most specific (safest)
  ↑
  1. Process tree (binary path + specific parent path + specific user)
  2. Full binary path + parent path
  3. Full binary path only
  4. Binary filename only (NO PATH)
  5. User or group only
  6. IP range or subnet only
  7. Keyword match only ("if CommandLine contains 'admin'")
  ↓
Least specific (most dangerous — creates largest blind spot)

Always use the most specific exclusion that correctly suppresses the FP. Never use a less specific exclusion when a more specific one works.

Exclusion Pattern 1: Full Binary Path

# WRONG — filename only:
filter_defender:
  SourceImage|endswith: '\MsMpEng.exe'

# RIGHT — full path:
filter_defender:
  SourceImage: 'C:\Program Files\Windows Defender\MsMpEng.exe'

Why the filename-only is wrong: An attacker running C:\Users\Public\MsMpEng.exe would be excluded. The path includes the user’s writable directory — no admin rights needed to place a file there.

Why the full path is better: C:\Program Files\Windows Defender\ is protected by Windows Defender’s self-protection (tamper protection). Placing a file there without defeating Defender is non-trivial. The exclusion’s blast radius is limited to processes that legitimately run from that path.

Exclusion Pattern 2: Process Tree (Binary + Parent)

For LOLBin exclusions, binary path alone is often insufficient — the same legitimate binary is also an attacker tool. The distinguishing factor is who launched it.

# Exclude certutil only when launched by SCCM:
filter_sccm_certutil:
  Image: 'C:\Windows\System32\certutil.exe'
  ParentImage: 'C:\Windows\CCM\CcmExec.exe'

# Exclude PowerShell only when launched by a specific orchestration tool:
filter_ansible:
  Image|endswith: '\powershell.exe'
  ParentImage: 'C:\Program Files\Ansible\ansible-runner.exe'
  User|endswith: 'svc-ansible'

The process tree exclusion only suppresses the legitimate workflow. An attacker using certutil for download (T1105) from a compromised shell gets a different ParentImage (cmd.exe, powershell.exe, explorer.exe) → alert fires.

Exclusion Pattern 3: Time-Based Exclusion

For planned maintenance windows where expected behavior would be noisy:

# In Splunk (post-conversion):
| where not (
    SourceImage = "C:\\Windows\\System32\\vssadmin.exe"
    AND date_hour >= 2 AND date_hour <= 4  # 2-4am maintenance window
    AND date_wday = 0  # Sunday only
)

Risk: If maintenance runs outside the window (unplanned restart, emergency patching), the alert fires — which is correct. Time-based exclusions are appropriate for scheduled automated operations, not for ad-hoc legitimate use.

Caution: This pattern can’t be expressed in Sigma YAML directly — it requires SIEM-side logic. Sigma handles logic at the event level, not time-window level.

Exclusion Pattern 4: User + Context Combination

For user-based exclusions, never exclude by user alone. Combine user with the specific expected action:

# DANGEROUS — excludes all activity from service account:
filter_svc:
  User: 'CORP\svc-backup'

# SAFER — excludes only the expected backup activity:
filter_svc:
  User: 'CORP\svc-backup'
  Image: 'C:\Program Files\BackupAgent\agent.exe'
  CommandLine|contains: 'shadowcopy delete'

An attacker who steals the svc-backup credential and uses it for lateral movement would not match the specific Image + CommandLine pattern → alert fires. The broad exclusion gives a stolen credential complete invisibility.

The Exclusion Maintenance Problem

Exclusions accumulate. Without maintenance, after 18 months you have:

Exclusions for software that was uninstalled
Exclusions for hosts that were decommissioned
Exclusions for service accounts that were renamed
Exclusions for IP ranges that were reassigned
Exclusions for paths that no longer exist on any system

Each stale exclusion is a documented blind spot for a path that is now available to attackers.

Mitigation strategies:

1. Document every exclusion in the ADS

## False Positives

| Exclusion | Why | Added | Verified Last | Expiry Review |
|-----------|-----|-------|--------------|---------------|
| MsMpEng.exe | Windows Defender memory scan | 2025-03-01 | 2026-01-15 | 2026-07-01 |
| CcmExec.exe certutil | SCCM certificate operations | 2025-06-15 | 2026-01-15 | 2026-07-01 |
| svc-backup agent.exe | Backup agent shadow copy cleanup | 2025-09-01 | 2026-01-15 | 2026-03-01 |

2. Quarterly exclusion review

For each exclusion:

Does the excluded binary still exist on your endpoints? (find /i "binary.exe" across asset inventory)
Did the service account change? Check AD
Did the software version change? Check deployment records

If the excluded process no longer exists in your environment, remove the exclusion.

3. Alert on exclusion non-firing

If an exclusion fires regularly (protecting a legitimate use case), its absence in a given time window is noteworthy. A backup service that always runs nightly and always fires the exclusion — if it goes silent for 3 days, something changed (service failure or software update). Build a scheduled search that alerts if an expected exclusion pattern hasn’t been seen in 72 hours.

Worked Example

Adding a scoped exclusion for a monitoring agent

Situation: A rule detecting net.exe user operations fires 5 times per day for an IT monitoring agent that checks domain user status with: net.exe user /domain. The agent runs as CORP\svc-monitoring from C:\Program Files\Monitor\agent.exe.

Step 1: Write the exclusion (most specific):

filter_monitoring_agent:
  Image: 'C:\Windows\System32\net.exe'
  ParentImage: 'C:\Program Files\Monitor\agent.exe'
  User: 'CORP\svc-monitoring'
  CommandLine|contains: '/domain'

Step 2: Test the exclusion doesn’t suppress attacks:

Attacker runs: net.exe user attacker /add (using a different CommandLine)
→ CommandLine doesn't contain '/domain' → exclusion doesn't match → ALERT FIRES ✓

Attacker uses svc-monitoring credential from shell:
ParentImage = cmd.exe → exclusion doesn't match → ALERT FIRES ✓

Attacker places malware at C:\Program Files\Monitor\evil.exe:
Image = evil.exe, not net.exe → exclusion doesn't match → ALERT FIRES ✓

Step 3: Document in ADS:

Exclusion: net.exe /domain from svc-monitoring via Monitor agent
Why: IT monitoring agent checks domain user counts hourly
Path: C:\Program Files\Monitor\agent.exe (Monitor v4.2.1)
Service account: CORP\svc-monitoring
Expiry review: 2026-11-01 (when Monitor v5.0 deployment planned)

Retrieval Practice

You're adding an exclusion for Windows Defender (MsMpEng.exe) accessing LSASS in an LSASS-dump detection rule. You write: `filter_defender: SourceImage|endswith: '\\MsMpEng.exe'`. What is the problem, and how do you fix it?

Reveal answer

The exclusion uses filename-only matching. Any process named MsMpEng.exe — regardless of path — is excluded. An attacker who places malware at C:\Users\Public\MsMpEng.exe or C:\Temp\MsMpEng.exe would be excluded from LSASS-dump detection while running credential dumping. Fix: use the full path: `filter_defender: SourceImage: 'C:\\Program Files\\Windows Defender\\MsMpEng.exe'`. This restricts the exclusion to the actual Defender installation directory, which is protected. Optionally add OriginalFileName verification if your Sysmon version captures it for this event type.

Retrieval Practice

You inherit a LSASS-dump detection rule with 47 exclusions, some dating back 3 years. The rule is at 70% precision (30% FP rate). What is your first diagnostic step, and what would a healthy precision target be after cleanup?

Reveal answer

First step: audit the exclusion list against the current environment. For each exclusion: (1) Does the excluded binary still exist on any endpoint? Run an asset inventory query. (2) Is the excluded service account still active in AD? (3) Is the excluded software still deployed? Any exclusion whose binary no longer exists in the environment is a stale free pass. After removing stale exclusions, run the rule against 30 days of historical data and reclassify the remaining alerts. Target precision: 85%+ for a critical-severity rule like LSASS dump detection (where every TP matters and FP budget is low). If precision is below 85% after cleanup, sample the remaining FPs and write targeted exclusions for the dominant remaining sources.