Ransomware Evolution: Autonomous Adaptation in the Wild

Author: Lyrie Threat Intelligence Team

Date: 2026-05-13

Reading time: 9 min

TL;DR

In Q1 2026, Lyrie's threat intelligence team observed a new ransomware family — internally tracked as MORPHIC — across four customer environments. Unlike traditional ransomware whose behavior is fixed at compile time and whose evasion tricks are pre-scripted, MORPHIC carries an embedded reasoning loop that modifies its own runtime behavior in response to defender activity it observes on the host.

Specifically, in the four incidents we analyzed, MORPHIC:

• Slowed its encryption rate from ~2GB/sec to <50MB/sec when it detected EDR-style API queries against the encrypting process.
• Paused all file operations and slept for periods of 4-11 minutes when it detected attachment of memory-forensic tools (procdump, winpmem, equivalents).
• Switched from AES-CTR encryption to a custom XChaCha20-derived stream when an embedded check against a known-decryptor signature triggered, defeating two third-party decryptor releases mid-incident.
• Rewrote portions of its own code segment in memory in response to inferred analyst behavior, including swapping function pointers and reordering branch targets to defeat behavioral-pattern matching.

This is qualitatively new. Traditional polymorphic ransomware varies its static signature. MORPHIC varies its runtime behavior pattern — including pausing, slowing, and structurally rewriting itself — based on real-time observation of the defender stack. Honeypots designed around expected behavioral patterns are now actively counter-productive: MORPHIC detects honeypot environments and avoids them, leaving them clean while encrypting production.

This article documents what we observed, the dynamic-threat-modeling approach Lyrie used to detect and contain MORPHIC, and why the next generation of honeypots must be rebuilt around adversarial-reasoning principles.

What MORPHIC Looks Like

MORPHIC arrives like most ransomware — phishing, edge-appliance exploitation, or RDP credential reuse — and lands an initial dropper on a beachhead host. The dropper is unremarkable: ~340KB, packed, calls home to a C2 to retrieve a second-stage payload. AV catches the dropper at well-resourced organizations; at less-resourced ones, it slips through.

The second stage is where it gets interesting. The runtime payload includes:

• A traditional encryption engine (AES-CTR with a per-file key, master key wrapped under ECC P-384).
• A traditional propagation module (SMB, WinRM, scheduled tasks).
• A runtime observation module that watches for specific defender signals — EDR API hooks, memory-forensic tool attachment, process-inspection patterns, debugger attach.
• A runtime decision module that adjusts encryption rate, propagation pace, and encryption mode based on the observation module's input.

The decision module is not, as best we can tell from static analysis, an LLM. It is a relatively small decision-tree-with-thresholds implementation, but it is designed and tuned in a way that suggests an adversarial-ML upstream — the decision boundaries align with what an LLM-driven red-team agent would tune them to.

This matters because it means we are seeing the output of AI-assisted malware development, not yet AI-driven malware execution. The execution-time intelligence is conventional. The development-time intelligence — which behaviors to model, which thresholds to choose, how to compose them — looks like an attacker who has been running their adversarial loop against modern EDR products in a private lab for months.

How Traditional Honeypots Failed

At one of the four affected customers, an enterprise honeypot — a popular commercial product — was deployed at the network edge of the file-server subnet. The honeypot is designed to attract ransomware traffic by exposing decoy SMB shares with attractive filenames and structurally-plausible-but-fake content.

MORPHIC ignored it. The forensic record on the honeypot showed two probes — both surface-level SMB enumerations — followed by no further activity. Meanwhile MORPHIC was encrypting the production file servers two subnets over.

We traced the avoidance to two MORPHIC behaviors:

1. Honeypot environments are detectable. The honeypot's decoy shares had filenames sampled from a published "realistic enterprise filename" generator, and the file size distribution had a long-tail signature that did not match real file systems. MORPHIC's observation module appears to have learned this distribution and avoided shares matching it.

2. Process-environment introspection. The honeypot host ran the commercial honeypot product's instrumentation as a kernel driver. MORPHIC enumerated kernel drivers as part of its standard recon and treated the presence of a known honeypot driver as a hard avoid signal.

Neither of these is sophisticated. Both are observable in MORPHIC's static binary if you know to look. The point is that static honeypots — those whose decoy patterns are baked in at deployment time — are now adversarially modeled. A defender deploying a 2023-era honeypot in 2026 is deploying a clearly-marked "do not encrypt here" sign.

Lyrie's Dynamic Threat Modeling Approach

Lyrie's ransomware containment runs on dynamic threat modeling — a continuously-updated, per-environment model of normal file-system, process, and network behavior, against which deviations are scored in real time. The detection chain on MORPHIC at the four customers:

Detection signal 1: anomalous file-write rate distribution. Normal application file writes follow a recognizable bursty pattern with characteristic file-size and inter-arrival distributions. MORPHIC's encryption pattern, even at its throttled-when-observed rate, was distinguishable at p > 0.999. The detection latency was 4-14 seconds from first encrypted file to alert, depending on customer environment.

Detection signal 2: rate-correlation with defender activity. This is the signal that made MORPHIC particularly visible to us. We log every EDR-style API query made by our own runtime, and we correlate them with observed file-system activity on the same host. MORPHIC's slowdown-when-queried behavior produces a negative correlation between query rate and write rate — an extremely unusual pattern that does not exist for any normal application. This correlation signal was the strongest single feature in our MORPHIC detector and is the feature we are least worried about MORPHIC's authors training around (because doing so requires giving up the throttling defense that helps MORPHIC against EDR more generally).

Detection signal 3: code-segment integrity drift. Our runtime hashes the code segment of high-suspicion processes at regular intervals. MORPHIC's runtime self-rewrites produce hash drift even when the binary's outward behavior is unchanged. Combined with the file-write anomaly, this signal lifts MORPHIC to certainty.

Response: at all four customers, the runtime quarantined the affected host within 18-44 seconds of first detection. Total files encrypted across the four incidents: 7,113, 412, 88, and 0 — the zero is the customer where MORPHIC was caught at the SMB enumeration stage before it touched a file. The 7,113 case is the customer where we were deployed at the network layer but not at the endpoint; the encryption ran for ~9 seconds before quarantine.

In no case did MORPHIC complete its intended encryption of the customer environment.

Rebuilding Honeypots for the Adversarial Era

Lyrie's working hypothesis for the next generation of honeypot design has three principles.

1. Honeypots must be statistically indistinguishable from real environments at the surface that the adversary observes. This means filename distributions, file-size distributions, file-content compressibility, MAC-time distributions, share-permission patterns, and (this is the hard one) traffic patterns on the network adjacent to the decoy. A honeypot that gets these wrong is a billboard.

2. Honeypots must be adversarially evaluated, regularly. A red-team exercise where the red-team's tooling is a current-generation ransomware family, run quarterly, against the honeypot deployment. The honeypot should fool the red team's tooling, not the red team's humans. If the tooling avoids the honeypot, the honeypot has failed.

3. Honeypots should integrate with the runtime, not stand alone. A honeypot that exists as a separate appliance is a separate attack surface and a separate avoidance target. A honeypot whose decoys are dynamically generated from the customer's real environment, deployed alongside real workloads on real hosts (with appropriate isolation), is much harder to avoid because the adversary cannot distinguish decoy from real without escalating recon to a level that itself triggers detection.

Lyrie has prototyped principle 3 and we expect to release reference designs in Q4 2026. We have not solved principles 1 and 2 for arbitrary environments; we have solved them well enough for specific industry verticals (financial services, healthcare). Both remain open research.

What Enterprises Should Do This Quarter

1. Audit your honeypot deployments. If you have one, run a current-generation ransomware family against it in a lab and see whether the ransomware engages. If it doesn't, your honeypot is decoration.

2. Deploy detection signals that don't depend on static signatures. File-write-rate anomalies, code-segment integrity drift, EDR-query-vs-write-rate correlation. These are the signals that survive an adversarial family like MORPHIC.

3. Run a containment drill. Once a quarter, simulate a ransomware detonation in a controlled subnet and measure your time-to-quarantine. Sub-60-seconds is the target. Many enterprises measure this in minutes-to-tens-of-minutes; that is the difference between losing a host and losing a department.

What's Next

• Public MORPHIC IoC release (this week). Full hash set, network indicators, behavioral fingerprints. ATP-signed.
• Q3 2026: Open-source release of our code-segment integrity monitor, MIT licensed.
• Q4 2026: Reference design for adversarially-grounded honeypots, including the synthesis pipeline for environment-matched decoys.

Reach the team: [email protected].

---

_Published by Lyrie.ai · lyrie.ai/research · Guy Sheetrit, CEO_