top of page
Search

MITRE ATT&CK Coverage Gaps (And How to Actually Fill Them)

  • 4 days ago
  • 7 min read

If you've looked at Microsoft's MITRE ATT&CK coverage dashboards in Defender XDR or Sentinel, you've probably seen a lot of green. Microsoft will tell you they cover hundreds of techniques across the kill chain, and technically, that's true. But here's the uncomfortable reality: coverage doesn't mean detection.


Just because Microsoft has a detection rule for a technique doesn't mean it's tuned for your environment, enabled by default, or actually firing when an attacker uses that TTP. I've done tabletop exercises where organizations thought they had solid coverage for credential dumping or lateral movement, only to discover during a purple team engagement that half their detections never triggered.


In this post, I'll walk through how to identify your actual coverage gaps — not what the dashboard says, but what you're genuinely detecting — and how to fill the most critical ones with custom analytics rules, telemetry tuning, and validation testing.


Prerequisites

Before you start assessing coverage, you need:

  • Microsoft Defender XDR or Microsoft Sentinel deployed

  • Defender for Endpoint agents on endpoints

  • Microsoft Defender for Identity (if you're covering identity-based techniques)

  • Security Reader role minimum (Security Administrator for making changes)

  • MITRE ATT&CK Navigator (free tool from MITRE: https://mitre-attack.github.io/attack-navigator/)

  • Atomic Red Team or similar testing framework (https://github.com/redcanaryco/atomic-red-team)

  • At least 30 days of telemetry to validate detection logic


Step 1 – Export Your Current Coverage

Start by understanding what Microsoft claims you're detecting.

In Defender XDR

Go to Reports > General > Security report and scroll to the MITRE ATT&CK section. You'll see a heatmap showing techniques covered by Defender alerts.

This is useful, but it's optimistic. It shows techniques that could trigger alerts, not techniques you've actually detected.


In Sentinel

If you're using Sentinel, deploy the MITRE ATT&CK coverage workbook:

  1. Go to Sentinel > Workbooks > Templates

  2. Search for "MITRE ATT&CK"

  3. Deploy the MITRE ATT&CK Coverage workbook

This shows which analytics rules map to which techniques. Export the data to CSV or JSON.

Build Your Coverage Layer

Take the exported data and import it into MITRE ATT&CK Navigator:

  1. Go to https://mitre-attack.github.io/attack-navigator/

  2. Click Create New Layer > Enterprise ATT&CK

  3. Upload your exported coverage data (or manually color techniques you're covering)

Now you have a visual representation. But this is still theoretical coverage. Let's validate it.


Step 2 – Test Detection Coverage with Atomic Red Team

The only way to know if you're actually detecting something is to simulate the attack and see if alerts fire.

Atomic Red Team provides pre-built tests for hundreds of MITRE techniques. Here's how to use it safely:

Install Atomic Red Team

On a non-production test VM (isolated network, monitored by Defender for Endpoint):


# Install Invoke-AtomicRedTeam module
Install-Module -Name invoke-atomicredteam -Scope CurrentUser -Force

# Import the module
Import-Module invoke-atomicredteam

# Download atomic test definitions
Invoke-Expression (Invoke-WebRequest 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing).Content
Install-AtomicRedTeam -getAtomics

Run a Test for a Specific Technique

Let's test T1003.001 (LSASS Memory Dump) — a common credential dumping technique:

Invoke-AtomicTest T1003.001 -TestNumbers 1 -ShowDetailsBrief

This simulates an attacker dumping LSASS memory. Now check:

  1. Did Defender for Endpoint fire an alert?

  2. Did a Sentinel analytics rule trigger?

  3. How long did it take to alert?

Go to Defender XDR > Incidents & alerts and filter by the test device. If you see an alert for "Credential dumping" or "Suspicious process accessed LSASS" — you have coverage. If nothing fired, you have a gap.


Document Results

Create a spreadsheet tracking:

  • Technique ID (e.g., T1003.001)

  • Test executed (Yes/No)

  • Alert fired (Yes/No)

  • Alert name (what it was called)

  • Time to alert (seconds/minutes)

  • Detection source (Defender for Endpoint, Sentinel rule, etc.)

Run this for your top 20–30 high-risk techniques. Focus on:

  • Initial Access (T1566 Phishing, T1190 Exploit Public-Facing Application)

  • Credential Access (T1003 OS Credential Dumping, T1558 Kerberos attacks)

  • Lateral Movement (T1021 Remote Services, T1570 Lateral Tool Transfer)

  • Defense Evasion (T1562 Impair Defenses, T1070 Indicator Removal)

  • Exfiltration (T1041 Exfiltration Over C2, T1567 Exfiltration to Cloud)


Step 3 – Identify Common Coverage Gaps

Based on testing dozens of environments, here are the techniques most often missed even with full Microsoft security stack deployed:


T1059.001 – PowerShell Obfuscation

Gap: Defender detects some malicious PowerShell, but obfuscated or encoded commands often slip through.

Fix: Create a custom Sentinel analytics rule for suspicious PowerShell patterns:

DeviceEvents
| where ActionType == "PowerShellCommand"
| extend CommandLine = tostring(AdditionalFields.Command)
| where CommandLine contains "bypass" 
    or CommandLine contains "-enc" 
    or CommandLine contains "IEX" 
    or CommandLine contains "downloadstring"
    or CommandLine matches regex @"[A-Za-z0-9+/]{100,}={0,2}"  // Base64
| project Timestamp, DeviceName, AccountName, CommandLine

T1087.002 – Domain Account Enumeration

Gap: MDI detects some enumeration (BloodHound, SharpHound), but misses native tools like net user /domain or PowerView with custom parameters.

Fix: Hunt for repeated net.exe or LDAP queries from non-admin accounts:

DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName =~ "net.exe" or FileName =~ "net1.exe"
| where ProcessCommandLine has_any ("user", "group", "localgroup")
| summarize Count=count(), CommandLines=make_set(ProcessCommandLine) by DeviceName, AccountName, bin(Timestamp, 5m)
| where Count > 5

T1048.003 – Exfiltration Over Unencrypted Protocol

Gap: Most detections focus on known cloud services (OneDrive, Dropbox). Raw FTP, HTTP POST, or DNS exfiltration often isn't flagged.

Fix: Create a network traffic baseline, then alert on outliers:

DeviceNetworkEvents
| where RemotePort in (21, 69)  // FTP, TFTP
| where InitiatingProcessAccountName != "SYSTEM"
| summarize UploadBytes=sum(BytesSent) by DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName
| where UploadBytes > 10485760  // 10MB threshold

T1136.001 – Create Local Account

Gap: Defender detects new local admin accounts, but misses standard user accounts created for persistence.

Fix: Alert on any local account creation outside of imaging/provisioning windows:

DeviceEvents
| where ActionType == "UserAccountCreated"
| where AccountDomain == DeviceName  // Local account
| project Timestamp, DeviceName, AccountName, InitiatingProcessAccountName, InitiatingProcessCommandLine

T1027 – Obfuscated Files or Information

Gap: Defender flags known packers (UPX, etc.), but custom obfuscation or heavily padded files aren't detected.

Fix: Hunt for files with high entropy or unusual extensions:

DeviceFileEvents
| where Timestamp > ago(24h)
| where ActionType == "FileCreated"
| where FileName endswith ".dat" or FileName endswith ".tmp" or FileName endswith ".bin"
| where FolderPath has "AppData" or FolderPath has "ProgramData"
| where FileSize > 1048576  // > 1MB
| summarize Count=count() by DeviceName, FileName, SHA256
| where Count == 1  // Unique, not commonly seen

Step 4 – Fill Gaps with Custom Analytics Rules

For each validated gap, create a custom analytics rule in Sentinel:

  1. Go to Sentinel > Analytics > Create > Scheduled query rule

  2. Name it clearly: "Custom - T1059.001 - PowerShell Obfuscation Detection"

  3. Map it to the MITRE technique in Tactics and techniques

  4. Set severity based on risk (High for credential access, Medium for discovery)

  5. Set the query frequency (5–15 minutes for high-value techniques)

Critical: Test each rule in a dev/test workspace first. Run it over 7–14 days of historical data to baseline false positive rates before deploying to production.


Step 5 – Enable Missing Telemetry

Sometimes the gap isn't detection logic — it's missing telemetry. Common culprits:

Windows Event Logs

Defender for Endpoint collects some events, but not all. Enable Advanced Audit Policies via GPO:

  • Account Logon > Credential Validation

  • Logon/Logoff > Logon, Logoff, Account Lockout

  • Object Access > File Share, Registry

  • Policy Change > Audit Policy Change

Forward these to Sentinel using Windows Security Events connector or Azure Monitor

Agent.


Sysmon

Deploy Sysmon with SwiftOnSecurity's config for deeper process, network, and file telemetry:

# Download Sysmon
Invoke-WebRequest -Uri https://download.sysinternals.com/files/Sysmon.zip -OutFile C:\Temp\Sysmon.zip
Expand-Archive C:\Temp\Sysmon.zip -DestinationPath C:\Temp\Sysmon

# Download SwiftOnSecurity config
Invoke-WebRequest -Uri https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml -OutFile C:\Temp\sysmonconfig.xml

# Install Sysmon
C:\Temp\Sysmon\Sysmon64.exe -accepteula -i C:\Temp\sysmonconfig.xml

Ingest Sysmon logs into Sentinel via Windows Event Forwarding or Azure Monitor Agent (Event ID 1–26).


Azure AD / Entra ID Sign-In Logs

If you're not ingesting Azure AD Sign-In Logs and Audit Logs, you're blind to:

  • T1078 (Valid Accounts abuse)

  • T1110 (Brute Force)

  • T1556 (Modify Authentication Process)

Enable the Azure Active Directory connector in Sentinel and ingest both logs.


Troubleshooting

Problem: Atomic Red Team tests are blocked before execution.

  • Cause: Defender for Endpoint's real-time protection is blocking the test.

  • Fix: Add the test VM to an exclusion group temporarily, or use evaluation mode in Defender.

Problem: I created a custom rule, but it's firing too many false positives.

  • Cause: The query isn't scoped properly (missing baselines, thresholds, or exclusions).

  • Fix: Add exclusion logic for known service accounts, scheduled tasks, or application-specific behavior.

Problem: I don't know which techniques are highest priority.

  • Cause: MITRE lists 200+ techniques; prioritization is hard.

  • Fix: Use MITRE ATT&CK Prioritized Technique List (https://top-attack-techniques.mitre-engenuity.org/) or focus on techniques seen in recent ransomware/BEC campaigns.


Hardening Considerations

Filling detection gaps is half the battle. The other half is reducing attack surface:

  • Disable LLMNR and NetBIOS to prevent name poisoning attacks (T1557)

  • Enable LSA Protection and Credential Guard to harden against credential dumping (T1003)

  • Restrict PowerShell to Constrained Language Mode for standard users (T1059.001)

  • Enable ASR rules in Defender for Endpoint (e.g., block credential stealing, Office macros, script-based attacks)

  • Deploy application allowlisting (AppLocker, WDAC) to prevent unsigned binaries (T1204, T1218)

Use Microsoft Secure Score and Exposure Management to identify quick hardening wins that also shrink your MITRE coverage gaps.


Final Thoughts

Here's the hard truth: no tool gives you 100% MITRE ATT&CK coverage out of the box. Not Defender. Not Sentinel. Not CrowdStrike, Palo Alto, or anyone else. Coverage is something you build by understanding your gaps, testing detection logic, and continuously tuning based on how real attacks behave in your environment.


I see too many teams treat MITRE coverage like a checkbox — "We have XDR, so we're good." Then they get hit with a ransomware attack that used lateral movement techniques they thought were covered, but the alerts never fired because the telemetry wasn't there or the rule wasn't tuned properly.


Start with the techniques that matter most for your threat model. If you're worried about ransomware, focus on credential access and lateral movement. If you're a target for espionage, prioritize persistence and exfiltration. Use Atomic Red Team to validate what's actually working, and don't trust the dashboard until you've tested it yourself.


And don't try to fill every gap at once. Pick your top 10 high-risk techniques, validate coverage, build custom detections where needed, and move on to the next batch. This is iterative work — your threat landscape changes, MITRE updates techniques, and Microsoft releases new detections. Treat coverage as an ongoing program, not a one-time project.

In a future post, I'll cover advanced purple team exercises for validating Sentinel and Defender XDR detections at scale — because once you've filled your gaps, you need a process to keep validating them as your environment evolves.

Comments

Subscribe

Thanks for submitting!

bottom of page