The ADS Framework — Writing a Detection Strategy Document

A detection rule without context is a liability. Six months after you write it, no one knows why a specific threshold was chosen, what it was tested against, or what the response should be when it fires. The ADS (Alerting and Detection Strategy) framework solves this by standardizing the documentation every detection should have.

ADS Document Structure

1. Goal

Template: “Detect [adversary behavior] which enables [impact]. This behavior is associated with [ATT&CK technique(s)].“

## Goal
Detect credential dumping from LSASS process memory (T1003.001), which enables attackers 
to extract plaintext credentials and NTLM hashes from memory — allowing pass-the-hash and 
pass-the-ticket lateral movement across the domain.

2. Categorization

technique: T1003.001
tactic: Credential Access
severity: Critical
data_sources:
  - Sysmon Event 10 (Process Access)
  - Windows Security Event 4656 (Handle to LSASS)
pyramid_level: L3  # behavioral, not tool-specific
summiting_score: L3

3. Strategy Abstract

A 2–4 paragraph description of the detection approach in plain English. Non-technical leadership should be able to read this and understand what the alert covers.

## Strategy Abstract

This detection monitors for any process that opens a handle to lsass.exe with 
PROCESS_VM_READ (0x10) or PROCESS_ALL_ACCESS (0x1F0FFF) rights. These access rights 
are required to read the memory of another process — the core operation of credential 
dumping tools.

The detection uses Sysmon Event ID 10 (Process Access), which records when one process 
opens a handle to another. The TargetImage field identifies lsass.exe as the target, and 
GrantedAccess contains the rights requested.

This approach is tool-agnostic: it fires regardless of whether the attacker uses Mimikatz, 
ProcDump, comsvcs.dll, or a custom tool. The only evasion path is kernel-mode access, 
which requires a kernel exploit.

4. Technical Context

The full technical details: field names, Sigma rule, test commands.

## Technical Context

**Data source:** Sysmon Event ID 10 (Process Access)
**Key fields:**
- TargetImage: must end with `\lsass.exe`
- GrantedAccess: must include PROCESS_VM_READ (0x10) or higher

**Sigma rule:**
[link to rule file in detection-as-code repo]

**Test command (Atomic Red Team T1003.001):**
`procdump64.exe -accepteula -ma lsass.exe lsass.dmp`

**Known-good processes that access LSASS (excluded):**
- C:\Program Files\Windows Defender\MsMpEng.exe
- C:\Windows\System32\WerFault.exe
- C:\Windows\System32\taskmgr.exe (Windows 11 only)

5. Blind Spots

## Blind Spots

- Kernel-mode LSASS dumping via a signed kernel driver (bypasses Sysmon user-mode interception)
- LSASS dumping via Windows Error Reporting API (WerFault.exe creates minidumps — excluded from rule)
- SAM database dumping (T1003.002) — separate technique, separate rule needed
- DPAPI credential decryption (T1555) — doesn't access LSASS at all
- Living-off-the-land: `comsvcs.dll MiniDump` via rundll32 — this IS caught by the rule 
  (the rundll32.exe process still needs PROCESS_VM_READ on LSASS)

6. False Positives

## False Positives

Expected false positive sources and suppression approach:

| Source | Suppression | Verified? |
|--------|------------|----------|
| MsMpEng.exe (Windows Defender) | Exclude by full path | Yes — confirmed in test env |
| WerFault.exe (Error Reporting) | Exclude by full path + parent = werfault | Yes |
| CrashPlan agent (backup) | Exclude by full path | Yes — verified with vendor |

**FP rate estimate:** < 1 per week in standard corporate environment
**FP rate if exclusions fail:** ~5 per day (high — monitor exclusion rule health)

7. Validation

## Validation

**True positive test (run monthly or after config changes):**
1. Deploy a test Windows VM with Sysmon installed
2. Run: `.\procdump64.exe -accepteula -ma lsass.exe lsass.dmp`
3. Expected: Alert fires within 60 seconds, SourceImage=procdump64.exe
4. Expected: Alert includes GrantedAccess value starting with 0x10

**False positive test:**
1. Open Windows Task Manager → Details tab → right-click lsass.exe → Create dump file
2. Expected: WerFault.exe creates the dump → NO alert fires (exclusion applies)
3. Expected: Only the custom exclusion suppresses, not a broad TargetImage exclusion

**Regression test:** Run weekly via CI against sample EVTX file

8. Priority and Response

## Priority
**Severity:** Critical (credential dumping enables domain compromise)
**SLA:** Analyst response within 15 minutes of alert
**Auto-enrichment:** Prepend asset criticality of SourceImage host, user risk score

## Response Actions
1. Isolate the host from the network if SourceImage is not an excluded tool
2. Capture memory image of the host (forensic preservation)
3. Rotate all credentials that may have been cached on the host (domain accounts)
4. Check lateral movement logs (4624 Type 3) from the host's IP over the past 4 hours
5. Escalate to Incident Response if lateral movement evidence found

ADS at Scale: The Detection Repository

In a mature detection program, every rule in the SIEM has a corresponding ADS document in the detection repository:

detection-rules/
├── T1003.001-lsass-memory-dump/
│   ├── rule.yml          ← Sigma rule
│   ├── ADS.md            ← ADS document
│   ├── tests/
│   │   ├── true-positive.evtx   ← sample that should alert
│   │   └── false-positive.evtx  ← sample that should not alert
│   └── CHANGELOG.md      ← tuning history