Is Traditional MDR Obsolete in the Age of AI-Driven Attacks?
Hey everyone, just read the piece on "Rethinking MDR" over on The Hacker News, and it really resonated with the chaos we're seeing this June. For years, MDR has been our crutch for staffing shortages—outsourcing the Tier 1 triage was the standard play. But with adversaries leveraging LLMs to automate unique payload generation and polymorphic code, I'm worried the standard "detect and respond" playbook is simply too slow.
If an AI can generate a unique dropper for every phishing email, signature-based MDR is dead in the water. We've seen a spike in Veeam-related phishing (exploiting interest around CVE-2026-44963) where the payload hash changes every single time. Traditional MDR queues are flooding because every alert looks "new" and requires manual investigation, defeating the purpose of automation.
I've started supplementing our external MDR with local behavioral hunting to catch the noise they miss. For instance, monitoring for specific suspicious parent-child process relationships that often bypass static analysis:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "mshta.exe"
| where FileName in ~("powershell.exe", "cmd.exe", "wscript.exe")
| where ProcessCommandLine has "Invoke-Expression" or ProcessCommandLine has "FromBase64String"
| project Timestamp, DeviceName, InitiatingProcessCommandLine, ProcessCommandLine
This helps catch the obfuscated execution chains regardless of the payload hash. It’s a band-aid, but it’s working for now.
How are you all adjusting your MDR contracts or internal detection logic to handle the speed of AI-driven attacks? Are we looking at a total model collapse?
Totally agree. We're seeing the same with OpenClaw agents—context is key. We added a Python script to our SOAR playbooks to de-obfuscate base64 strings automatically since our MDR was missing them. It's stopped a few critical incidents this week alone.
I'm skeptical of just throwing more AI at the problem. I've doubled down on enforcing Attack Surface Reduction (ASR) rules via PowerShell. If the script can't run in the first place, the AI detection speed doesn't matter. We blocked mshta entirely last month:
Add-MpPreference -AttackSurfaceReductionRules_Ids 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B -AttackSurfaceReductionRules_Actions Enabled
From a red team perspective, it's trivial to bypass standard MDR rules using AI to tweak the syntax slightly. You're right, the model is collapsing. Defenders need to stop looking for 'bad' and start looking for 'abnormal'. Focus on the IOC-less detection.
Building on that SOAR integration, relying solely on static analysis is a losing battle against polymorphic malware. We've started feeding suspicious-but-clean hashes into an automated sandbox environment via our playbooks. This buys us the behavioral context MDR often misses. Here’s a KQL snippet we use to hunt for process hollowing attempts that tend to slip through the cracks:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "svchost.exe" and FileName =~ "powershell.exe"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
I think the focus needs to shift to Identity. Since AI payloads easily bypass signature checks, validating the actor is crucial. We’ve started prioritizing Identity telemetry over pure EDR alerts to catch the subsequent lateral movement.
For instance, we run a simple KQL query to detect impossible travel scenarios, which often occur after the initial dropper executes:
SigninLogs
| summarize Locations = make_set(Location) by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Locations) > 1
It catches the activity that traditional MDR often misses.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access