Why We Built MagicSword And Why We Almost Didn't
After years building threat detection, the same techniques kept showing up in every breach and nobody was stopping them. This is the story of why MagicSword exists, what the detection industry gets wrong, and why prevention isn't a feature. It's the whole point.

We spent years detecting attacks for a living. And we were good at it.
At Splunk, we built the Threat Research team from the ground up. We analyzed malware families, wrote detections, published research, and helped enterprises understand what was hitting them. It felt like meaningful work. It was meaningful work.
But something started bothering us that we couldn't shake.
Every ransomware case we analyzed, every incident report we reviewed, the same techniques kept showing up. PowerShell abuse. WMI. Living-off-the-land binaries. Legitimate remote management tools being hijacked. These weren't sophisticated zero-days. They were the same primitives, over and over again, across different threat actors, different victims, different years.
We kept detecting them. Nobody was stopping them.
The moment it really clicked was when we published the LOLDrivers project. We'd noticed attackers were increasingly using vulnerable legitimate drivers to bypass security controls. We documented it, published it, and it went viral in the security community. Thousands of people shared it. It was everywhere.
And the first question we kept getting was:
"Okay, but how do we actually stop this?"
That question haunted us. We had built one of the best detection research teams in the industry, and the community's response to our best work was essentially: detection isn't enough. What do we do?
We saw the same pattern emerge with remote monitoring and management tools through the LOLRMM project, and with living-off-the-land binaries through LOLBAS. Across every project, the same gap. We could document exactly how attackers were abusing legitimate tools. We couldn't stop them from running.
Now layer AI on top of that problem and it gets worse fast.
In 2024, 79% of all threat detections were malware-free. No custom payloads, no sketchy executables. Just stolen credentials and your own IT tools turned against you. AI-generated phishing emails now achieve a 54% click-through rate compared to 12% for traditional attempts. The grammatical errors that trained employees to spot fakes? Gone. FunkSec emerged in December 2024 with a developer who openly admitted he couldn't code, used AI to fill the gaps, and claimed more victims in a single month than any other ransomware group.
Getting in has never been easier. And once they're in, they're using your own tools.
Here's the uncomfortable truth the industry doesn't want to say out loud: AI is now being applied heavily to detection too. Better models, faster analysis, smarter anomaly detection. Vendors are racing to slap "AI-powered" on everything. And it's still not solving the core problem. You can have the most sophisticated AI-driven detection engine on the planet, and if PowerShell is allowed to run unrestricted in your environment, you're still playing catch-up against attackers moving at machine speed.
Akira went from defense evasion to full encryption in twenty minutes. Using your tools. CrowdStrike documented a breakout time of 51 seconds from initial access to lateral movement. The DFIR Report has documented case after case where ransomware groups achieve full domain compromise in under 45 minutes. You cannot staff a SOC to respond faster than that. No AI detection layer changes that math.
So we looked at prevention. And we found another problem.
Application control as an industry has been thinking about this completely backwards. The existing approach is rooted in old IT security models, controlling which applications employees are allowed to run, built around compliance requirements and productivity policies. Preventing someone from installing Spotify on a work laptop. That's not security. That's IT governance dressed up as protection.
Nobody was asking the real question: which applications are actually being used to compromise organizations? The tools showing up in every breach aren't random software employees sneak onto their machines. They're PowerShell. WMI. PsExec. AnyDesk. Tools that are supposed to be there. Sophos documented a 51% increase in living-off-the-land binary abuse year-over-year, identifying 187 unique Microsoft LOLbins being weaponized. Black Basta hit over 500 organizations, including 12 of 16 critical U.S. infrastructure sectors, with a toolkit that reads like an IT administrator's workstation: AnyDesk, Quick Assist, PsExec, PowerShell, WMIC.
The threat isn't the application. It's the context in which it runs and what it's allowed to do.
That's where we saw the real opportunity. Not to build another application control tool that tells you what software is approved. But to leverage application control as a mechanism to actually prevent breaches — by understanding the threat landscape and using it to stop the specific techniques attackers rely on, not just manage a list of approved executables.
The security industry isn't optimizing for stopping attacks. It's optimizing for describing them. We built faster dashboards to watch ourselves lose in real time. Red Canary's 2024 Threat Detection Report shows the same techniques dominating year after year: Windows Command Shell, PowerShell, WMI, Mshta. The same primitives, the same incident reports, year after year.
What frustrates us most isn't the technology. It's the culture. Security teams are measured on detection coverage, MTTD, MTTR. Metrics that all assume the attacker is already inside.
We think it's time the industry started talking about a different metric entirely: MTTP. Mean Time to Prevent. Because the goal shouldn't be how fast you respond to something that already ran. It should be ensuring it never ran in the first place.
The defender we're trying to help is the one we used to be. The one who knows the alert means they're already too late. The one who writes the same incident report for the fourth quarter in a row. The one who goes home wondering why we're so good at explaining breaches and so bad at preventing them.
If MagicSword succeeds, organizations stop accepting preventable attacks as the cost of doing business.
If it fails, the same families hit the same techniques, the same SOC teams get the same alerts, and someone writes the same incident report again next year.
We built MagicSword because we believe prevention isn't a feature. It's the whole point. And it's time the industry started acting like it.
Read the official announcement here.
If any of this sounds familiar, the same alerts, the same techniques, the same incident reports, you're the defender we built this for. → Book a demo and see what prevention-first actually looks like in practice.
References
- CrowdStrike 2026 Global Threat Report
- LOLDrivers — Vulnerable Driver Project
- LOLRMM — Living Off the Land RMM Tools
- LOLBAS — Living Off the Land Binaries and Scripts
- Sophos Active Adversary Report, December 2024
- Check Point Research — FunkSec Ransomware Analysis
- CISA Advisory — Black Basta Ransomware
- Picus Security — Akira Ransomware 2024 Analysis
- Hoxhunt — AI Phishing Click-Through Rates
- The DFIR Report
- Red Canary 2024 Threat Detection Report
- Microsoft — Volt Typhoon LOTL Activity

Written by
Jose Hernandez
Threat Researcher
Jose Enrique Hernandez formed and served as the Director of Threat Research at Splunk. Jose is known for creating several security-related projects, including: Splunk Attack Range, Splunk Security Content, Git-Wild-Hunt, Melting-Cobalt, lolrmm.io and loldrivers.io. He also works as a maintainer to security industry critical repositories such as Atomic Red Team and lolbas-project.github.io.


