.png)
It was a Saturday when a friend called. His company had been hit, a ransom demanded, could I help. I walked into an incident that looked already over: every VM disk locked, no realistic way back except negotiating and paying. It didn't end that way. One IT admin who had never been trained to do this grabbed a memory dump of the encryption process before anyone touched it. I know enough cryptography to ask the right questions about what was inside that dump. A fifth-generation AI model did the actual math. My logic, its math, and most of the company's data came back. It worked because of a window that almost never opens, and no security program should want to depend on that window opening.
In professional terms, that's getting pulled into an incident in its last phase. I've spent my whole career building the kind of layered defense meant to keep that call from ever reaching me. If I'm honest, I always assumed an incident like this is close to a knockout blow for a business, that once every disk is locked there's nothing left to do but negotiate and pay. That would have been an unremarkable story even a year ago. What changed is AI, though not quite in the way most of the market is currently selling it.
Look at what's actually shipping right now, AI-powered like everything else, and it mostly comes down to two categories.
The first is AI SOC. It exists to speed up how incidents get handled: triage the alert flood, correlate it, hand back a verdict. Nobody has to spend hours manually rebuilding the picture of what happened, or at least not as many hours.
The second is AI pentest. It exists to speed up finding vulnerabilities in your own environment, generally so you find them before someone outside your company does.
Underneath the speed pitch, both are selling the same thing: budget. Fewer analyst hours, fewer pentester hours, similar or better coverage.
Everyone's a little rattled by now, by what Mythos can apparently do, by stories like Hugging Face, by the rest of the pile. But from where I sit, 99.99 percent of that is really about speed and scale on pretty ordinary misconfigurations and forgotten, unpatched, internet-facing assets. I haven't seen a public, jaw-dropping story about a real 0-day in a major closed-source product, the kind with no source code to hand the model in the first place. Somewhere there's probably that 0.01 percent that never becomes public, precisely because it would actually be alarming. Those would be about quality, not quantity.
This story belongs to that quality side. Except the team doing the finding is blue, not red.
Back to that Saturday, and to what AI actually did for me.
The short version: the entire virtualization layer was encrypted, every VM disk. There was either no backup, or the attacker had reached that too.
What I had on hand: a couple of the encryptor's own binaries, a ransom note with instructions for making contact, and, unexpectedly, a memory dump of the encryption process pulled from one of the hypervisors. I still don't know exactly what made the on-site IT admin capture that dump, or why it happened on that one hypervisor and not the others. Call it luck. This time luck actually broke the right way. Anyone who's run a mature incident response function knows that capturing memory before you touch anything, before you reboot, is close to rule one on a live ransomware case. It's not something IT admins are generally trained to do, and there was no security team on site yet to tell them otherwise.
A year ago, not being a professional malware analyst or forensic reverse engineer myself, I'd have told this company the case was closed except for the negotiation. This year, with enough theoretical grounding in the cryptography and a fifth-generation frontier model to do the heavy lifting, it got a lot more interesting.
It didn't cooperate right away. The first couple of prompts got flatly refused, guardrails treating a ransomware binary like something I had no business examining. Then it seemed to work out that I was the one trying to get files back, not the one who'd encrypted them in the first place, and after that it just helped.
Reverse engineering the binary showed it fully encrypts small files but only partially touches large ones: roughly ten percent of each, spread across the file so the format still parses afterward. Every VM disk falls into that second bucket by definition, they're all hundreds of gigabytes. Memory analysis didn't give me the attacker's private key, and it didn't need to. The session key the process actually uses to encrypt files sits in its own memory for as long as it's alive, and that's what I pulled out. The model helped turn that into a working decryptor. Every disk on that one hypervisor came back, including the one the company cared about most.
And because roughly ninety percent of every disk had never been touched by the encryptor to begin with, I pulled a lot of files straight off the untouched regions on the other hypervisors without needing a key at all. There's genuine damage from this incident, I'm not going to pretend otherwise. But most of the data came back, and that's the actual difference between having a choice and being forced into a negotiation.
That recovered visibility also let me partially rebuild the logs on those machines and reconstruct what the attacker had actually done inside the environment. They'd been in the network for more than three weeks before pulling the trigger. Entry point, as usual, was an unpatched service exposed to the internet.
One more detail worth keeping. Because the disks are so large, several of the encryption runs on them never finished, they got partway through a disk and stopped. I doubt the attacker could reconstruct what they lost there either, not without the same memory dump I happened to have.
Here's what keeps me from calling this a repeatable process. The attacker hadn't run the encryptor once. There were several separate runs across the environment, each generating its own independent session key. The one memory dump I had covered exactly one of them. Everything that run touched, I got back. Everything the other runs touched, several hundred megabytes of it, is gone for good, because those keys never existed anywhere my single dump could reach.
So no, this isn't a story about disciplined incident response. It's a story about one admin, on one host, catching one process out of several running that night. I got lucky exactly once. The other chances closed on their own, unwatched, because nobody happened to be looking at the right process list on the right machine at the right minute.
Bottom line, I think the outcome here comes down to the same thing these AI security products are ultimately selling everywhere else: budget. Whatever this saved in recovery costs against an actual ransom payment.
But two things matter more to me than the money.
Which is why I think AI SOC needs to be paired with agents that can actually act, not just recommend. Not 'sudo rm -rf /' on a hunch, obviously. A narrow, pre-approved set of moves: block an IP, block a DNS name, capture a memory dump the moment a process starts behaving like ransomware. Something that's already there, watching, with permission to move before anyone has time to convene a call about it.
That's the exact gap StreamForce, Stream.Security's agentic response layer, is built to close. It runs a narrow, pre-approved set of actions (capture memory, isolate a host, block an indicator) directly on the infrastructure Stream.Security is already watching, so the outcome doesn't come down to which admin happened to be at their desk when it mattered. CloudTwin gives it the runtime and identity context to tell an actual ransomware run from a false alarm, and StreamMate AI lets your team direct or review that response in plain language instead of a runbook nobody has time to read at 2am. You shouldn't need to get lucky twice.
Stream is the AI-native platform built to fight AI-enabled attacks. It autonomously prevents, detects, hunts, and remediates exposures and threats across production at machine speed - driving risk toward zero. It replaces the fragmented stack of scanners, runtime agents, exposure tools and playbooks with one live model of production.Defending Production needs a new approach: Stream is the only Autonomous Production Defense Platform that works across your entire production estate. It runs on a patented CloudTwin®, a high-fidelity security data harmonization layer that models Cloud, SaaS, identity, runtime, AI, network, perimeter, on-prem, security controls, and the behavior running on top of them into one live model of production: real-time, fully correlated, continuously updating. Not a snapshot. And it does not stop at boundaries - the boundaries that fragment every other tool are the same boundaries an attacker moves across. Inside CloudTwin they are one system.
