How to Perform an EDR Coverage Gap Analysis with Red Team Testing

Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most organizations deploy an EDR and assume it provides comprehensive detection coverage: but EDR platforms ship with default policies that balance detection against alert volume. Many high-value detection opportunities require explicit configuration: enabling telemetry for specific event types, creating custom detection rules, and tuning policies for the environment.
A coverage gap analysis answers the specific question: 'Which attacker techniques could execute on our endpoints right now without generating an alert?' The answer drives rule development and policy tuning efforts on the techniques that matter most for your threat landscape.
Environment Setup and Scope Definition
Setup requirements:
- Isolated test environment (separate from production) with representative endpoint configuration
- Domain-joined Windows 10/11 workstation with production GPOs applied
- Same EDR policy as production endpoints
- Same AV exclusions as production
- Internet access (for realistic C2 simulation, or use redirectors)
- ATT&CK framework scope: select relevant technique subsets:
Option A: Test all techniques in the matrix (~800+ in ATT&CK v15)
Option B: Test techniques used by specific threat groups that target your industry
Example for financial sector: FIN7, Lazarus Group, Scattered Spider
MITRE ATT&CK Groups page lists techniques per group
Option C: Test your most-feared techniques first:
- Credential access (T1003 OS Credential Dumping)
- Lateral movement (T1021 Remote Services)
- Defense evasion (T1562 Impair Defenses)
- Persistence (T1053 Scheduled Task, T1543 Create or Modify System Process)
# Install Invoke-AtomicRedTeam (the Atomic Red Team PowerShell framework):
# Run on the test machine (isolated environment):
# Install from PowerShell Gallery:
Install-Module -Name invoke-atomicredteam -Scope CurrentUser -Force
Install-Module -Name powershell-yaml -Scope CurrentUser -Force
# Clone the Atomic Red Team test library:
$atomicPath = 'C:\AtomicRedTeam'
Invoke-Expression (Invoke-WebRequest 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
Install-AtomicRedTeam -getAtomics -Force
# Downloads ~500MB of test cases and payloads
# Verify installation:
Get-Help Invoke-AtomicTest -Full
Running Atomic Red Team Tests
# Run a specific ATT&CK technique test:
# T1003.001 = OS Credential Dumping: LSASS Memory
Invoke-AtomicTest T1003.001
# Run with verbose output to see what the test does:
Invoke-AtomicTest T1003.001 -ShowDetailsBrief
# Show test details before running (recommended for new tests):
Invoke-AtomicTest T1003.001 -ShowDetails
# Run prerequisite checks first:
Invoke-AtomicTest T1003.001 -CheckPrereqs
# Run and log results:
Invoke-AtomicTest T1003.001 -LogPath C:\AtomicResults\ -TimeoutSeconds 120
# Cleanup after test:
Invoke-AtomicTest T1003.001 -Cleanup
Run a batch of techniques for a specific threat group:
# Run all Lazarus Group techniques (mapped in ATT&CK):
$LazarusTechniques = @(
'T1059.001', # PowerShell
'T1059.003', # Windows Command Shell
'T1003.001', # LSASS Credential Dumping
'T1021.002', # SMB/Windows Admin Shares
'T1055', # Process Injection
'T1562.001', # Disable/Modify Tools
'T1070.001', # Clear Windows Event Logs
'T1105', # Ingress Tool Transfer
'T1486' # Data Encrypted for Impact
)
$results = @()
foreach ($technique in $LazarusTechniques) {
Write-Host "Testing: $technique"
try {
$result = Invoke-AtomicTest $technique -ReturnOutput -TimeoutSeconds 60
$results += [PSCustomObject]@{
Technique = $technique
Status = 'Executed'
Output = $result
}
} catch {
$results += [PSCustomObject]@{
Technique = $technique
Status = "Error: $($_.Exception.Message)"
Output = ''
}
}
Start-Sleep -Seconds 30 # Gap between tests for alert correlation
Invoke-AtomicTest $technique -Cleanup 2>$null
}
$results | Export-Csv -Path C:\AtomicResults\LazarusGroup-$(Get-Date -Format yyyyMMdd).csv -NoTypeInformation
Critical tests to run for any enterprise EDR:
# These are the techniques most commonly missed or misconfigured:
# Credential Access:
Invoke-AtomicTest T1003.001 # LSASS memory dump (mimikatz-style)
Invoke-AtomicTest T1003.003 # NTDS.dit dump
Invoke-AtomicTest T1552.001 # Credentials in files
# Defense Evasion:
Invoke-AtomicTest T1562.001 # Disable security tools
Invoke-AtomicTest T1070.001 # Clear event logs
Invoke-AtomicTest T1027.002 # Software packing (obfuscated code)
Invoke-AtomicTest T1218.010 # regsvr32 Squiblydoo
# Persistence:
Invoke-AtomicTest T1053.005 # Scheduled task
Invoke-AtomicTest T1543.003 # Windows service
Invoke-AtomicTest T1547.001 # Registry run keys
# Discovery:
Invoke-AtomicTest T1087.001 # Local account enumeration
Invoke-AtomicTest T1082 # System information discovery
Invoke-AtomicTest T1016 # Network discovery
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Correlating Results Against EDR Alerts
After running each test, check the EDR console to determine detection status:
For each technique tested, classify the result into one of four categories:
1. ALERTED: EDR generated an alert with the correct technique/tactic attribution
- Color: Green in ATT&CK Navigator
- Action: No immediate action needed; verify alert quality and response playbook
2. TELEMETRY ONLY: EDR logged the event but did not generate an alert
- Color: Yellow in ATT&CK Navigator
- Action: Create a detection rule using the available telemetry
- This is the highest-priority gap: the data exists, just no detection rule
3. NO DETECTION: EDR has no log or alert for the technique
- Color: Red in ATT&CK Navigator
- Action: Check EDR policy (telemetry collection setting), check if the technique
requires specific EDR module (e.g., memory scanning, script inspection)
4. FALSE NEGATIVE: Test confirmed malicious behavior, EDR had the telemetry,
but did not alert: indicating a detection rule gap
Query CrowdStrike Falcon for test artifacts:
# In Falcon Event Search (FES): Humio query language:
# Find process creation events for the test machine during test window:
ComputerName="TEST-WORKSTATION01"
| EventType="ProcessRollup2"
| where timestamp > startOf1HoursAgo
| select timestamp, FileName, CommandLine, ParentBaseFileName
| sort timestamp
# Find if LSASS access was detected:
ComputerName="TEST-WORKSTATION01"
| EventType="ProcessRollup2" OR EventType="SyntheticProcessRollup2"
| FileName = "mimikatz.exe" OR CommandLine = "*sekurlsa*"
Query Microsoft Defender for Endpoint:
// Check MDE for technique artifacts from test machine:
DeviceProcessEvents
| where DeviceName == "test-workstation01"
| where Timestamp > ago(2h)
| project Timestamp, FileName, ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc
// Check if LSASS access was detected:
DeviceEvents
| where DeviceName == "test-workstation01"
| where ActionType == "LsassProcessAccess"
| where Timestamp > ago(2h)
ATT&CK Navigator Heatmap and Remediation
Build your coverage heatmap in ATT&CK Navigator:
1. Go to https://mitre-attack.github.io/attack-navigator/
2. Create new layer > Select ATT&CK version matching your testing
3. For each tested technique:
- ALERTED → color: green (#00ff00), score: 3
- TELEMETRY ONLY → color: yellow (#ffff00), score: 2
- NO DETECTION → color: red (#ff0000), score: 1
- NOT TESTED → no color (leave blank)
4. Export the layer as JSON for documentation
5. Generate the heatmap image for reporting
The resulting heatmap shows:
- Your current detection coverage across the ATT&CK matrix
- Techniques requiring new detection rules (yellow)
- Techniques requiring telemetry/policy changes (red)
- Gaps in high-priority tactic areas (credential access, lateral movement)
Build detection rules for telemetry-only gaps:
// Example: LSASS access was logged but not alerted
// Build a Sentinel detection rule from MDE telemetry:
DeviceEvents
| where ActionType == "LsassProcessAccess"
// Exclude legitimate processes that access LSASS:
| where InitiatingProcessFileName !in~ (
"MsMpEng.exe", // Windows Defender
"csrss.exe", // Windows system process
"wininit.exe", // Windows initialization
"SecurityHealthService.exe"
)
| where InitiatingProcessFolderPath !startswith @"C:\Windows\System32\\"
// Alert on:
| project Timestamp, DeviceName, InitiatingProcessFileName,
InitiatingProcessCommandLine, InitiatingProcessFolderPath
| order by Timestamp desc
Track coverage improvement over time:
After each gap remediation sprint:
1. Re-run the failed tests from the previous round
2. Update the ATT&CK Navigator layer
3. Calculate coverage score:
Coverage % = (Alerted + Telemetry) / Total Tested × 100
Target: >80% alert coverage for high-priority techniques
4. Track by tactic:
- Credential Access coverage: X%
- Lateral Movement coverage: Y%
- Defense Evasion coverage: Z% ← Usually the lowest; DET techniques are hardest
The bottom line
An EDR coverage gap analysis uses Atomic Red Team (Install-Module invoke-atomicredteam; Invoke-AtomicTest [technique-id]) to execute standardized ATT&CK technique tests on a production-mirrored test endpoint, then checks the EDR console for alerts vs. telemetry-only vs. no detection. Classify results in ATT&CK Navigator as green/yellow/red. Yellow (telemetry, no alert) is the highest-priority gap: the data exists, just no detection rule. Build KQL or EDR custom rules from the available telemetry events. Focus first on techniques used by threat groups targeting your industry: use ATT&CK Groups to identify the relevant technique list. Retest after each detection rule improvement sprint to track coverage percentage by tactic.
Frequently asked questions
What is Atomic Red Team and how is it used for EDR gap analysis?
Atomic Red Team is an open-source library of 1,000+ standardized adversary simulation tests mapped to MITRE ATT&CK techniques, maintained by Red Canary. Each test executes a specific technique implementation (LSASS memory dump, registry run key persistence, certutil download) on a controlled endpoint. The PowerShell framework (invoke-atomicredteam, installed via Install-Module) allows running individual tests (Invoke-AtomicTest T1003.001) or batches. After running each test, analysts check the EDR console for alerts, telemetry, or no detection: producing a technique-by-technique coverage assessment.
How do you prioritize which EDR detection gaps to fix first?
Prioritize gaps by technique impact and attacker usage frequency: (1) credential access techniques (LSASS dumping, NTDS.dit extraction, credential file access): these are prerequisites for privilege escalation and domain compromise; (2) defense evasion techniques (disable security tools, clear event logs): if attackers can blind your EDR, all other detections fail; (3) lateral movement techniques (SMB/RDP/WMI): containment depends on detecting pivoting; (4) techniques used by threat groups that actively target your industry, identified via MITRE ATT&CK Groups page.
What is MITRE ATT&CK and how does it map to EDR coverage analysis?
MITRE ATT&CK is a framework that catalogs adversary tactics, techniques, and sub-techniques (T1003.001 = LSASS memory dump, T1059.001 = PowerShell execution, etc.) based on real-world attack observations. For EDR coverage analysis: run Atomic Red Team tests mapped to specific ATT&CK technique IDs, then use the ATT&CK Navigator (a free web tool at attack.mitre.org/resources/attack-navigator/) to create a heatmap showing which techniques your EDR detected (green), partially detected (yellow), or missed (red). This produces a visual coverage gap map that can be shared with leadership and used to prioritize detection engineering work.
How do I run Atomic Red Team tests safely without affecting production?
Atomic Red Team tests should be run on isolated lab endpoints or virtual machines that mirror production OS versions and EDR configurations. Never run tests involving data destruction (T1485 - Data Destruction) or denial of service in production. For credential access tests: use non-privileged test accounts (not real admin credentials). For persistence tests: document which registry keys, scheduled tasks, or services the test creates so they can be cleaned up afterward. The invoke-atomicredteam module includes cleanup commands (Invoke-AtomicTest T1003.001 -Cleanup) that remove test artifacts. Before running any test: verify you have written authorization from the system owner and coordinate with the SOC to avoid triggering actual incident response.
What is the difference between EDR telemetry and EDR detections?
EDR telemetry is the raw event data the agent collects and sends to the cloud console: process creation events, network connections, file writes, registry modifications, and API calls. Detections are alerts generated when EDR analytics rules (vendor-supplied or custom) match patterns in that telemetry. Telemetry without detection rules is still valuable: during threat hunting, analysts query raw telemetry to find attacker behavior that never triggered an alert. Coverage gap analysis should assess both: can the EDR collect the telemetry needed to detect a technique (data source coverage), and does a detection rule exist that would alert on that telemetry (rule coverage)?
How do you build a detection rule from Atomic Red Team telemetry-only results?
When an Atomic Red Team test produces telemetry but no alert, query the EDR's raw event store for the specific events generated during the test window. In CrowdStrike Falcon, use Event Search (Humio) filtered to the test machine and technique timeframe: look for process creation, registry writes, or API calls that uniquely identify the technique. Extract the most specific field combination (parent process, command-line pattern, target object) that distinguishes the attacker behavior from legitimate activity. Write a custom detection rule using those fields: in Sentinel, build a KQL scheduled alert; in CrowdStrike, create a Custom IOA rule in the Falcon console. After deploying the rule, rerun the Atomic Red Team test to confirm the rule now alerts. Document the rule with the ATT&CK technique ID, the test case used for validation, and the false-positive exclusion logic applied.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.

Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.
