When Packers Kill EDR: Use AI to Catch Ransomware

Most organizations still treat endpoint detection and response (EDR) as the “last line” that will always be there when things go wrong. Shanya is a blunt reminder that attackers are planning for a world where your EDR isn’t just bypassed—it’s terminated, deleted, and blinded before the real payload lands.

A recent wave of activity around Shanya, a packer-as-a-service, shows how ransomware crews are buying “wrappers” that hide malicious code and ship with EDR-killer capabilities. The uncomfortable takeaway: if your detection strategy depends on your endpoint agent being alive at the moment the ransomware executes, you’re betting the company on a single point of failure.

This post is part of our AI in Cybersecurity series, and the angle is simple: AI-driven detection matters most when traditional controls are intentionally suppressed. Shanya is exactly the sort of threat that makes behavior-based, cross-telemetry analytics (and not just endpoint signatures) non-negotiable.

Shanya and the rise of packer-as-a-service

Answer first: Packer-as-a-service turns advanced evasion into a purchasable feature, letting more ransomware actors ship malware that’s harder to scan, triage, and block.

If ransomware-as-a-service lowered the barrier to launching an extortion campaign, packer-as-a-service lowers the barrier to getting the ransomware to run in the first place.

A “packer” is essentially a protective shell around malware. It can compress, encrypt, and reshape the payload so static scanners don’t recognize it and analysts can’t easily reverse it. What’s changed is the business model: rather than each gang maintaining its own custom obfuscation and loader pipeline, they can outsource it to a service that specializes in:

• Obfuscation and runtime unpacking (making the payload look benign until it executes)
• Anti-analysis features (sandbox checks, debugger detection, timing tricks)
• Delivery flexibility (wrapping different ransomware families with similar evasion techniques)

Shanya is being discussed in the same breath as other packing operations that have become part of the ransomware ecosystem. Security researchers have observed it used broadly through 2025, indicating it’s not a niche tool or a short-lived experiment.

Here’s what I find most important: packer-as-a-service creates standardization for criminals. Standardization means reuse. Reuse means volume. Volume means your defenders see the same “shape” of attack across different ransomware brands.

That’s also where AI-based detection can win—if you model the behavior of the wrapper and the staging, you’re less dependent on knowing which ransomware family comes next.

The real threat: Shanya as an EDR killer

Answer first: Shanya’s most dangerous feature isn’t just hiding ransomware—it’s clearing the runway by disabling security tools at the kernel/process level.

Shanya is described primarily as an EDR killer that prepares the environment for whatever comes after it. The pattern that matters to defenders is the sequence of actions—because it’s measurable.

How EDR killers typically work (and why it’s effective)

EDR products live on endpoints and need privileged access to observe and block activity. Attackers have responded by targeting the EDR’s ability to observe.

Shanya’s observed approach includes:

1. Dropping a legitimate (clean) driver associated with a real program to reduce suspicion.
2. Dropping a malicious unsigned kernel driver.
3. Loading the clean driver, then abusing it to gain the kind of write access needed for tampering.
4. Terminating and deleting processes/services tied to security products.

If that sequence succeeds, two things happen immediately:

• Your endpoint tool might stop reporting (visibility loss).
• Your endpoint tool might stop enforcing prevention policies (control loss).

In plain language: the attacker is trying to ensure that when ransomware executes, your best sensor is already blind.

Why this isn’t a “one gang” issue

One of the most frustrating aspects of this trend is reuse across crews. Researchers have observed similar EDR-killer functionality used by multiple ransomware gangs (including Akira, Medusa, Qilin, and Crytox) and in other delivery chains.

That variety matters because it kills a common defensive habit: “We don’t get hit by that ransomware.” Packers and EDR killers don’t care about the brand name. They’re infrastructure.

Why static detection fails against packed ransomware

Answer first: Packed payloads and fast-changing wrappers break signatures; defenders need detection anchored in behavior, relationships, and timing.

Most traditional anti-malware logic still leans on one or more of these:

• Known file hashes
• Known byte patterns
• Known strings and imports
• Reputation and prevalence scoring

Packers are built to scramble those signals. When the malware is packed, the file on disk may not contain the same recognizable content as the unpacked payload in memory. Even worse, packers can mutate each build so the hash and byte structure change constantly.

That’s why organizations sometimes experience the classic “it looked fine until it ran” problem:

• The packed file is delivered.
• Static scanning says it’s unknown or benign.
• Runtime unpacking happens quickly.
• Security tooling is disabled.
• Only then does ransomware execute.

If you’re relying heavily on pre-execution file scanning, Shanya-style tooling can turn your defenses into a speed bump.

Where AI-driven threat detection fits (and where it doesn’t)

Answer first: AI helps most when it detects the “setup” behaviors—driver abuse, security tooling tampering, and unusual execution chains—before ransomware detonates.

AI in cybersecurity is often marketed like magic. It isn’t. It’s a set of techniques that can be extremely practical when you point them at the right problem.

For packers and EDR killers, the right problem isn’t “identify this exact ransomware sample.” The right problem is “spot the abnormal chain of events that makes ransomware possible.”

The behaviors AI can reliably learn and flag

Good AI-based threat detection systems (especially those trained on large fleets and diverse telemetry) can identify patterns such as:

• Rare driver load events (especially unsigned drivers or unusual driver ancestry)
• Known abused driver families and “living-off-the-driver” behavior
• Process termination waves targeting security services
• Unexpected privilege escalation and kernel interactions
• DLL side-loading patterns and suspicious parent/child process chains
• “Quiet period then burst” execution typical of staged attacks

The key is correlation. A single event might be explainable. A sequence is harder to dismiss.

A snippet-worthy way to say it:

Attackers can hide code, but they can’t hide physics—processes start, drivers load, services die, and networks light up.

Why AI needs the right telemetry to be useful

AI can’t see what you don’t collect. If the only truth you trust is the endpoint agent (and that agent can be killed), you need additional signals to avoid a total blackout.

At minimum, most teams should aim to correlate:

• Endpoint telemetry (yes, still important)
• Identity signals (unusual logons, token abuse, privilege changes)
• Network and DNS activity (beaconing, lateral movement patterns)
• Server/workload logs (SMB spikes, remote execution tools)
• Backup and storage events (deletion attempts, snapshot tampering)

When an endpoint goes dark, AI-driven analytics can still detect the blast radius forming elsewhere.

A practical defense plan for Shanya-style threats

Answer first: Treat EDR as critical infrastructure: harden it, monitor for tampering, and build “EDR-down” detection paths using AI and layered controls.

The source reporting emphasizes a familiar truth: hygiene still matters. I agree—but “hygiene” needs to be specific enough that teams can implement it next week, not next quarter.

1) Protect the protector (EDR hardening)

Start by assuming attackers will try to remove your agent.

• Enable EDR tamper protection and password/role gatekeeping for uninstall actions.
• Restrict local admin rights; many EDR-kill chains get easier with admin.
• Monitor for EDR service stop attempts and unexpected agent health drops.
• Maintain an allow/deny strategy for driver loading where feasible.

If your EDR product supports “self-defense” settings, treat them like you treat MFA: mandatory.

2) Block known abused drivers (and watch for the pattern)

Driver abuse is a repeat offender in modern ransomware operations. Even when you can’t block every possibility, you can:

• Maintain a deny list of known abused kernel drivers.
• Alert on new/rare driver installs by non-IT processes.
• Alert when a clean driver is loaded and quickly followed by suspicious write activity and process killing.

This is an area where AI models help because “rare + high-impact” patterns are exactly what anomaly detection does well.

3) Detect the staging chain, not just the payload

If you’re only hunting for encryption activity, you’re late.

Shift detection earlier:

• Suspicious parent/child chains (script host → installer → driver loader)
• Remote tooling patterns (PsExec-like behavior, WMI remote execution, scheduled task bursts)
• Security control suppression attempts (service deletion, registry tampering)

AI-based behavioral detection is strongest here because packers change the payload; they don’t change the need to stage.

4) Build an “EDR is down” playbook

This is the part most companies skip until an incident forces it.

Define what happens when:

• A critical mass of endpoints stops reporting within 5–15 minutes
• A high-value host’s EDR agent reports tamper events
• Security services are stopped across multiple machines

Your playbook should include:

1. Automatic isolation actions (network segmentation, conditional access tightening)
2. Identity containment (disable risky sessions, force re-auth)
3. Rapid triage queries in your SIEM/data lake
4. Backup protection checks (immutability, snapshot integrity)

5) Train for social engineering that feeds ransomware

Shanya has been observed in broader attack chains that include social engineering delivery. Don’t treat user training as “check the box.” Focus it on what actually shows up in real inboxes and real clicks.

Teams get better results when training is paired with technical friction:

• Block risky file types from email where possible
• Run attachments through detonation/sandboxing
• Limit script execution policies

What to ask vendors (and your internal team) right now

Answer first: Your evaluation question isn’t “does it stop ransomware?” It’s “what happens when attackers try to kill the sensors?”

If you’re assessing AI in cybersecurity tools, or re-assessing your EDR posture after seeing threats like Shanya, here are questions that cut through marketing:

• Can you detect EDR tampering attempts independently of the endpoint agent?
• What telemetry supports driver-level detection (and where is it processed)?
• Do your models flag sequence-based attacks (driver load → service kill → lateral movement)?
• How do you reduce false positives on “rare” admin actions without ignoring them?
• What automated containment actions can trigger from high-confidence behavior?

The best answers will be specific: event types, timing windows, and response options—not vague assurances.

What this means for the AI in Cybersecurity roadmap

Shanya is a clean example of why “more signatures” isn’t the next step. Attackers are productizing evasion and selling it as a service layer, which means defenders need detection that survives:

• obfuscation,
• rapid mutation,
• and deliberate sensor suppression.

AI-driven threat detection earns its budget when it finds the setup—the weird driver behavior, the sudden security service termination, the abnormal chain of execution—before encryption starts and before your endpoint tools get silenced.

If you had to assume that a portion of endpoints will lose EDR visibility during a real attack, would your organization still spot ransomware staging in time to contain it? That’s the question worth answering before the next packed payload shows up.