Shanya-style packers can kill EDR before ransomware runs. Learn how AI-driven behavioral detection and response can stop visibility-denial attacks.

AI vs EDR Killers: Stopping Shanya-Style Packers
Ransomware crews aren’t just buying ransomware anymore—they’re buying evasion. The rise of packer-as-a-service (PaaS) makes that painfully clear: attackers can wrap whatever malware they already have in a commercial-grade “shell” designed to slip past defenses and, in Shanya’s case, take your EDR down first.
This matters because a lot of security programs still treat endpoint detection and response as the last line of defense—and sometimes the only line that consistently gets budget. Shanya flips that assumption on its head. If the first successful action in an intrusion is disabling your visibility, you’re not dealing with “ransomware” as a single event. You’re dealing with a visibility-denial phase that must be prevented, detected, and contained—often with more than traditional endpoint controls.
This post is part of our AI in Cybersecurity series, and Shanya is a clean example of why modern detection has to be behavioral, cross-layer, and fast. AI isn’t a magic shield, but when it’s applied to telemetry fusion, anomaly detection, and automated triage, it’s one of the most practical ways to stay ahead of services built specifically to blind you.
What Shanya changes: evasion is now a subscription
Answer first: Shanya turns advanced obfuscation and EDR disruption into a repeatable service, which lowers attacker skill requirements and increases the volume of “EDR-resistant” ransomware attempts.
Security research published by Sophos in early December 2025 described Shanya as a packer-as-a-service family used to help ransomware operators avoid anti-malware controls. It follows the path established by prior packer operations (such as HeartCrypt) and appears to be used broadly across regions.
Here’s the key shift: packers used to feel like an “extra” used by higher-end actors. PaaS makes packers feel like table stakes—a paid add-on that comes bundled with updates, customer support (yes), and iterations when defenders catch up.
For defenders, that creates two problems:
- Commoditization: More crews can run more advanced evasion with less expertise.
- Acceleration: Once a packer technique works, it propagates quickly across multiple ransomware groups.
If you’re seeing more incidents where payloads look different every time, but outcomes and behaviors are similar, PaaS economics are often why.
Why “signature resistance” isn’t the scary part
Packers don’t just change file hashes. Many also:
- Alter control flow to confuse static analysis
- Delay execution or gate it behind conditions (time, locale, user action)
- Use side-loading techniques to blend into legitimate software activity
Hash-based and static signature detection will always lag here. The fix isn’t “more signatures.” The fix is detection that’s harder to spoof than a file wrapper.
Shanya as an EDR killer: the visibility-denial pattern
Answer first: Shanya’s standout trait is that it targets your endpoint tooling—using drivers to terminate and delete security processes—so the ransomware stage runs in the dark.
Sophos describes Shanya primarily as an EDR killer that prepares the environment for follow-on malware. The observed approach is consistent with a pattern defenders keep running into in 2024–2025: attackers don’t race to encrypt first. They race to remove the brakes first.
At a high level, Shanya’s technique (as described in the research) includes:
- Dropping a legitimate (clean) driver associated with real software
- Dropping a malicious unsigned kernel driver
- Loading the clean driver to avoid immediate suspicion
- Abusing the clean driver for privileged access (for example, write access)
- Using that capability to terminate and delete processes/services tied to security products
Sophos observed this behavior used by multiple ransomware gangs, including Akira, Medusa, Qilin, and Crytox, and also noted usage in other campaigns that relied on DLL side-loading.
Why kernel-level abuse is such a force multiplier
A lot of endpoint security assumes it can observe, intercept, and remediate what happens on the host. But kernel-level manipulation can undermine those assumptions.
When attackers can:
- Tamper with protected processes
- Kill user-mode agents
- Remove services and drivers tied to telemetry collection
…your EDR doesn’t just miss an alert. It can miss the entire intrusion narrative.
That’s why I think “EDR vs ransomware” is the wrong mental model. The real fight is visibility vs visibility denial.
Where traditional EDR programs get this wrong
Answer first: Many organizations rely on EDR as a single control rather than an ecosystem of controls that keep EDR trustworthy—especially against driver abuse and tamper techniques.
Plenty of teams have strong EDR deployments and still get hit. The common failure mode isn’t “they didn’t buy the right tool.” It’s one of these:
1) EDR is deployed, but not hardened
EDR often needs its own protection plan:
- Strict control over driver installation
- Policies to prevent use of known abused kernel drivers
- Locked-down local admin rights (and monitored privilege escalation)
- Tamper protection that’s actually tested (not just enabled)
2) Telemetry is siloed on the endpoint
If the endpoint becomes untrusted, you need other sources that can still tell the story:
- Identity logs (SSO, conditional access, MFA prompts)
- Network flows (east-west movement, unusual SMB/RDP patterns)
- Server audit logs and Windows Event Forwarding
- Backup/admin plane logs (the place attackers love to disable first)
3) Response depends on the same agent that gets killed
If your playbook assumes “EDR will isolate the host,” and the host is already blinded, you need a second isolation path:
- Network access control or switch port actions
- Firewall policy pushes based on host tags
- Identity-based containment (disable sessions, revoke tokens)
This is exactly where AI-driven operations can help—because the decision to contain shouldn’t require a human to manually correlate five consoles while ransomware is staging.
How AI-driven detection outsmarts packer-as-a-service
Answer first: AI helps most when it correlates behavior across layers (endpoint, identity, network) and spots anomalies that persist even when the payload is obfuscated.
Attackers can change packers fast. They can’t easily change the physics of an intrusion. That’s the defender advantage AI can amplify.
Behavioral analytics: focus on what packers can’t hide
Even if Shanya obfuscates the payload, the intrusion still has behavioral footprints:
- Unusual driver load events and service creation
- Attempts to access or modify protected processes
- Spikes in process termination targeting security tooling
- DLL side-loading patterns (legit signed binary + suspicious adjacent DLL)
- Privilege escalation followed by rapid defense changes
Well-tuned anomaly detection can flag these sequences as “rare and high-risk,” even if the file itself looks new.
A practical stance I’ve found works: treat security-tool tampering as a top-tier incident category, not as a sub-alert under “malware.” If something tries to remove your alarms, that’s the emergency.
Telemetry fusion: keep signal when endpoints go quiet
When EDR is degraded, AI systems that can reason over multiple streams still have leverage:
- Identity anomalies: token abuse, impossible travel, admin role changes
- Network anomalies: new lateral movement routes, odd DNS patterns
- Backup anomalies: deletion attempts, retention changes, vault access
Correlation is the win. A single alert might be noisy; a chain is usually decisive.
Faster triage: reduce the human bottleneck
December is peak “thin staffing” season in many orgs. End-of-year change freezes, holidays, and fewer on-call resources create perfect conditions for ransomware operators.
AI-assisted triage can:
- Group related alerts into one incident
- Summarize host, user, and network context
- Recommend containment steps based on playbooks
- Reduce time-to-decision when minutes matter
If your mean time to respond is measured in hours, PaaS-driven ransomware will keep exploiting that gap.
A defensive playbook for Shanya-style EDR killers
Answer first: You need to prevent driver abuse, add independent telemetry sources, and automate containment triggers—because once EDR is killed, your options shrink.
Below is a pragmatic checklist you can put into a 30–60 day hardening sprint.
1) Block driver abuse pathways
- Enforce strict driver installation policy (limit who can install, monitor every install)
- Maintain a denylist for known abused drivers (and audit exceptions)
- Use OS-native controls where applicable (memory integrity / HVCI where supported)
- Alert on unsigned driver load attempts and unusual driver load chains
2) Treat EDR tampering as “stop-the-line” severity
- Create a dedicated detection category: Defense Evasion / Security Tool Impairment
- Require immediate containment when confirmed (even before malware confirmation)
- Measure it: track “time from tamper attempt to containment” as a KPI
3) Add a second containment mechanism
If your EDR gets killed, you still need an off-host response path:
- Network isolation capabilities at the switch/firewall layer
- Identity-driven containment (disable accounts, revoke tokens, force re-auth)
- Controlled shutdown of high-risk admin shares and remote tools
4) Build ransomware blast-radius controls
These don’t stop Shanya directly, but they limit outcomes:
- Separate backup credentials from domain admin
- Immutable or object-locked backups where possible
- Tested restores (quarterly at minimum; monthly is better for critical systems)
- Segmentation for file servers and admin tools
5) Put AI where it actually helps
AI is most valuable when it’s attached to decisions:
- Behavioral detection tuned to rare sequences (driver load → security process kills)
- Automated incident grouping and summarization
- Policy-based containment recommendations with human approval
- Post-incident learning loops (feed confirmed TTPs back into detections)
If AI only generates “more alerts,” it’s not helping. It should reduce work and speed containment.
The question security leaders should ask after reading about Shanya
Answer first: The right question isn’t “Can our EDR detect this packer?” It’s “What happens to our detection and response when an attacker tries to disable the EDR?”
Shanya is a reminder that modern ransomware operations include a deliberate pre-encryption phase focused on blinding and weakening defenses. Packer-as-a-service makes that phase cheaper, faster, and more accessible to more threat actors.
If you’re mapping out your 2026 security plan, I’d make one bet: incidents that start with EDR disruption will become more common, not less. That pushes organizations toward AI-driven threat detection that’s behavioral, correlated across layers, and paired with automated response.
If you want a practical next step, run a tabletop exercise with one twist: assume the endpoint agent is partially or fully disabled 10 minutes into the attack. Can your team still detect lateral movement? Can you still isolate systems? Can you still protect backups and identity?
That answer tells you where to invest next—and whether your security program is built for the world Shanya represents.