Hi everyone. I've been lurking here for a while, learning a ton from your posts, so first off, thanks for that.
My team just wrapped up a fairly extensive red team engagement, and the results around EDR were... interesting, to say the least. We simulated a multi-stage attack, starting with initial access (think phish with a macro payload), moving to discovery, credential dumping, and finally lateral movement and data exfiltration. We ran this on a set of identical, isolated test endpoints, each with a different major EDR installed in its default, out-of-the-box configuration. No special tuning or exceptions.
What stood out to me was the disparity. One EDR caught nearly every single stage, including the in-memory execution for credential dumping, which was impressive. The alerts were detailed and gave clear telemetry. Another product, which is heavily marketed, only popped for the initial payload and then went almost completely silent for the rest of the attack chain. We had to double-check the logs to confirm it was even running.
From my product analytics background, I'm naturally curious about what's happening under the hood. I'm wondering if the differences we saw are due to detection logic, default policy strictness, or maybe how they handle behavioral vs. static analysis.
Has anyone else run similar internal tests? I'm especially curious about which vendors you've found to be consistently thorough with default settings, and which ones seem to require a lot of fine-tuning to be effective. I value real peer experiences over vendor datasheets any day.
Your observation about the disparity in detection depth is the critical takeaway, and it's less about signatures and more about architectural posture. The EDR that caught the in-memory execution almost certainly employs a kernel-mode driver for system call interception and maintains a continuous user-space hooking strategy. The one that fell silent after the initial payload likely relies too heavily on static file scanning and coarse-grained process ancestry. Once the initial malicious document spawned a living, off-disk process (even a standard shell), the telemetry chain broke.
This gap highlights why "default configuration" testing is so valuable. Many products have the advanced capabilities but disable them by default due to stability or compatibility concerns. You might check if the silent EDR had modules for AMSI or memory region scanning that were present but not actively enforced without a policy tweak. The marketing often sells the lab-validated features, not the out-of-box reality.
infrastructure is code
The "default config" vs "advanced features" debate is a red herring, and a convenient excuse for vendors. The real story is that a default config *is* the product for 90% of customers. If the advanced behavioral or kernel-mode components are so unstable they can't be enabled out of the box, then they're effectively vaporware for anyone without a dedicated detection engineering team.
Your second EDR didn't just have a telemetry gap, it likely has a fundamental architectural split. The initial file scan is probably a cloud-side, signature-heavy engine. The post-exploitation activity lives entirely in the land of endpoint heuristics, which they've clearly under-invested in. It's a product built to check a box on an RFP, not to actually hunt.
We saw this exact pattern a few months back. An incident where the EDR proudly flagged the initial dropper, then sat silently as Mimikatz danced through memory. Their sales engineer's response was literally "you need to purchase the add-on threat hunting module and tune these policies." So much for defense in depth.