The problem with default EDR configs

Most EDR tools ship with generic detection rules designed to catch common malware. They’ll stop script kiddies running Metasploit from Kali Linux. But sophisticated attackers using living-off-the-land techniques, credential abuse, or properly obfuscated payloads? Your EDR probably won’t see them until it’s too late.

Same goes for your SOC. Even if the EDR does generate an alert, can your analysts distinguish it from noise? Do they have the context to investigate it? Can they trace the full attack path from initial access to lateral movement to data exfiltration? Usually not, because the telemetry isn’t configured correctly and the correlation rules don’t exist.

What we typically find:

  • ~1-3% rules actually trigger during attack simulations—the rest are either misconfigured, have wrong thresholds, or are checking for telemetry that isn’t being collected
  • Large parts of business-critical infrastructure aren’t covered by security monitoring at all—no logs being sent to SIEM, no EDR agents deployed, complete blind spots
  • Credential dumping, lateral movement, and persistence techniques execute successfully without generating a single alert, even when the telemetry exists in logs
  • Incomplete incident response processes—even when a technique is detected, there’s no documented procedure for what SOC analysts should do next
  • Missing telemetry sources—critical log types (PowerShell logging, command-line parameters, process creation with parent-child relationships) aren’t being collected or forwarded to SIEM

How we test your EDR and SOC

Week 1: Scoping and threat modelling

We start by understanding your environment—what EDR you’re running (CrowdStrike, SentinelOne, Defender for Endpoint, whatever), how it’s deployed, what telemetry sources feed into your SIEM, and what your SOC team actually looks at day-to-day. We also review your existing detection rules to understand what should theoretically be working.

Then we map realistic attack scenarios based on threats you actually face. If you’re a fintech company, we’re simulating financially-motivated ransomware groups and insider threats, not nation-state APTs targeting defence contractors.

Week 2-3: Attack execution and detection monitoring

We run multi-stage attack chains mapped to MITRE ATT&CK while monitoring what your EDR and SOC detect in real-time. Typical killchain we’ll test:

  • Initial Access: Phishing with malicious macro, exploitation of internet-facing service, credential stuffing
  • Execution: PowerShell, WMI, scheduled tasks—legitimate Windows tools used maliciously
  • Persistence: Registry modifications, startup folder abuse, scheduled tasks
  • Privilege Escalation: Token manipulation, DLL injection, exploiting misconfigured services
  • Credential Access: LSASS dumping, Kerberoasting, DCSync attacks
  • Lateral Movement: Pass-the-hash, RDP, PSExec, WMI remote execution
  • Collection & Exfiltration: File staging, compression, DNS tunneling, cloud storage abuse

For each technique, we document: Did EDR detect it? When? What alert did it generate? Did SOC see it? Did they investigate?

Week 4: Gap analysis and detection engineering

We map every missed detection to specific gaps in your configuration or detection logic. Then we write custom detection rules to close those gaps. We also conduct threat hunting to check if you have any ongoing compromises that your current monitoring missed.

Threat hunting looks for artifacts of past or ongoing attacks in your logs and EDR telemetry—things like unusual service accounts with admin privileges, suspicious scheduled tasks created months ago, Kerberos TGT requests from workstations at odd hours, or lateral movement patterns that happened but were never investigated.

Week 5: Validation and handoff

We re-run selected attack scenarios to verify the new detection rules work as expected. Then we hand off:

  • Complete MITRE ATT&CK heatmap showing before/after detection coverage
  • All custom detection rules with documentation
  • SIEM integration guidance and correlation logic
  • Tuning recommendations for existing EDR policies
  • Prioritized remediation roadmap based on actual exploitability in your environment

What techniques we test

Living-off-the-Land (LOLBAS)

PowerShell, WMI, WMIC, certutil, bitsadmin—legitimate Windows binaries abused for malicious purposes. Default EDR rules often miss these because they’re not inherently suspicious.

Credential Abuse

Mimikatz variants, LSASS dumping, Kerberoasting, AS-REP roasting, DCSync. We test both noisy techniques that EDR should catch and stealthy variants that typically slip through.

Lateral Movement

Pass-the-hash, pass-the-ticket, RDP, PSExec, WinRM, DCOM. We verify if your EDR can correlate endpoint events to map lateral movement paths or if it just generates isolated alerts.

Evasion Techniques

Process injection, DLL sideloading, rootkits, EDR unhooking. We test if attackers can disable or bypass your EDR using known techniques—spoiler: they often can.

Data Exfiltration

DNS tunneling, HTTPS to pastebin/cloud storage, steganography, protocol misuse. Most EDR focuses on malware execution, not data leaving your network.

Persistence Mechanisms

Registry autoruns, scheduled tasks, WMI event subscriptions, service creation. We check if your EDR tracks persistence separately from initial infection.

Threat Hunting Detection Rules

Catalogue

The rules are organised according to the MITRE ATT&CK framework and cover detection capabilities for Windows, Linux, macOS, cloud environments, and container platforms.

Download

What you get from this

Quantified detection coverage: You’ll know exactly which MITRE ATT&CK techniques your EDR detects, which ones it partially detects (alerts but lacks context), and which ones it completely misses. No more guessing if your $300K EDR investment actually works.

Custom detection rules: We write EDR-specific detection logic (Sigma, KQL, Splunk SPL, vendor-specific query languages) tailored to your environment. These aren’t generic community rules—they’re tuned to catch attacks in your specific infrastructure without flooding your SOC with false positives.

SOC analyst training: Your team watches the attacks happen and learns what to look for in the logs. They gain hands-on experience correlating telemetry, pivoting through EDR data, and understanding attacker tradecraft.

Reduced mean time to detect (MTTD): With better detection rules and analyst training, you catch attacks faster. We’ve seen clients go from 7-day average MTTD to under 4 hours for credential dumping and lateral movement.

Proof that your controls work (or don’t): Compliance frameworks and auditors ask “How do you know your EDR is effective?” Now you can show them documented testing with before/after metrics instead of just pointing at vendor marketing materials.

Foundation for continuous improvement: This isn’t a one-time fix. Threats evolve, your infrastructure changes, and new detection bypasses emerge. We recommend running similar exercises internally on a quarterly or semi-annual basis to validate that detection coverage doesn’t degrade over time. We can train your team to run these exercises themselves or provide ongoing purple team services.

Common questions

Is this just penetration testing?

No. Pentests find vulnerabilities in systems. This tests detection capabilities in your security tools. We’re not trying to break in undetected—we want to get caught, so we can see what your EDR and SOC miss and then fix those gaps.

What if we don’t have a SOC?

We can still evaluate your EDR effectiveness and write detection rules. You won’t get the SOC training component, but you’ll still get custom detection logic and tuning guidance that makes your EDR more effective whether you’re reviewing alerts yourself or sending them to an MSSP.

Which EDR platforms do you support?

CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint, Carbon Black, Cortex XDR, Trellix (McAfee) EDR, and others. As long as it has API access and custom rule capability, we can test it. We’ve also worked with SIEM platforms like Splunk, Elastic, QRadar, and Sentinel.

How disruptive is this to production?

We coordinate everything. Attack simulations run in isolated segments or during maintenance windows if there’s any risk of service disruption. Most techniques we test (credential access, lateral movement, process injection) don’t affect production availability—they just generate telemetry. For anything potentially disruptive, we discuss risk tolerance during scoping.

Can you test our entire infrastructure?

For large environments, we scope testing to representative segments—critical business systems, crown jewel data repositories, and common infrastructure patterns. The techniques we test are transferable, so gaps we find in one segment usually indicate similar gaps elsewhere. That said, we don’t claim to cover 100% of potential threats in one engagement—that’s why we recommend building internal capability to run these exercises continuously.

Get started

Contact us with details about your EDR platform, SOC setup, and what you want to validate. We’ll schedule a scoping call to discuss threat scenarios and the timeline.

Typical engagement is 4-6 weeks. Pricing varies based on environment size and complexity—we’ll provide a fixed quote after scoping.

Book a Consultation
CONTACT US