An evening looking at files that no longer open
Sometimes, a file listing is enough to make me worry.
The supplied image is an inventory I am reviewing. Obscured folder names, virtual disk files and .babyk extensions appear together. To an outsider, it may look like a technical screen. At a data recovery desk, each entry raises questions: which service is inside, whose work is waiting, and what options remain for making the data usable?
That is why I wanted to write these notes on the evening of 4 November 2026. The more encrypted data I encounter, the more seriously I believe businesses should take preparation before an incident.
BabyK and the risk to virtual infrastructure
BabyK/Babuk makes me cautious when receiving data associated with virtual infrastructure. Where many services share a cluster, an incident affecting storage or the hypervisor can leave many VMs unavailable. The actual impact depends on the environment, affected data and surviving recovery options.
SentinelLABS documented multiple ransomware families reusing Babuk source code for ESXi lockers. Reuse also complicates attribution: a .babyk extension warrants investigation but does not identify the operator behind an incident. [1]
At intake, I want to understand which data matters, the scope of impact and which sources can still be assessed safely. Those questions connect directly to a business resuming work.
What stayed with me from a Qilin response
I previously participated in a response that was identified during the engagement as involving Qilin. I was told the attackers had been present in the business for more than two weeks before encryption. A Singapore-based investigation company had been appointed by the parent company to support the response in Vietnam.
“More than two weeks” is information shared with me about that particular incident. What stayed with me was the gap between an attacker’s arrival and the moment people discover encrypted data. During that gap, a system can still appear to be operating normally.
By the time files stop opening, the story may already have been unfolding for a long time.
Recovery planning therefore includes assessment of both the environment and the data used for restoration. Bringing a VM online is a milestone; confirming safe, usable service is the work that must follow through.
The drives I keep at 2A Phan Chu Trinh
Data recovery is fascinating work. Recovery of encrypted data can sound so unlikely when retold that people become skeptical.
At my workplace at 2A Phan Chu Trinh, I keep dozens of encrypted drives that customers let me retain as mementos after response work. When someone visits to talk about the profession, those drives bring back particular stories.
I also have tens of terabytes of encrypted data to study as part of that ongoing interest. Understanding an inaccessible file takes patience: examining structure, readable regions and the limits of possible approaches.
The satisfaction comes from understanding the problem. For a business waiting on its data, however, the pressure is real. I value these stories while hoping more businesses can prepare well enough to avoid needing one.
Name the data at the heart of your business
In intake work I encounter NAS, servers, VMware, Linux and other environments. The platforms vary, but the concern is familiar: applications stop running, records stop opening and people cannot continue their work.
For one company, the “heart” may be its accounting database. For another, production data, designs, project records or a management application. Without naming that dependency, it is possible to back up a large volume while missing what is most urgently needed.
Business owners and IT should sit down together and ask:
- Which service causes serious disruption if it is unavailable for half a day?
- What data and dependencies are needed to run it again?
- Where is the latest usable copy, who can retrieve it and how far has recovery been tested?
Start with the critical service, then extend the scope. Clear priorities make backup work better suited to the resources of each business.
AI adds pressure; preparation still starts with specific work
I worry about AI assisting people who want to attack systems. In its assessment published on 3 November 2026, NCSC judged that criminal AI adoption would likely increase the scale and efficiency of ransomware, social engineering and vulnerability exploitation. [3]
That is context for preparation; I have no evidence attributing AI use to the incidents discussed here. My concern is the pace of change and the gap between protection a business believes it has and protection that has actually been tested.
Reviewing administrator access, patching systems, protecting backup storage and rehearsing restoration are practical places to begin, starting with the most important service.
Prove offline and immutable backups through recovery
I want businesses to have offline copies they can actually use. If production data and administrator accounts are compromised together, an appropriately isolated copy may preserve an important recovery route.
CISA recommends offline, encrypted copies and regular tests of their availability and integrity during recovery. Its guidance also recognizes immutable storage while noting configuration and cost considerations. [2]
Immutability is valuable when protection, retention and administrative controls are designed correctly. Offline copies have risks too: age, failed media, lost decryption keys and untested restores. Reconnection also needs a controlled procedure.
I want evidence that a copy can be retrieved during a production outage, the responsible person knows how to obtain it, the data has been tested appropriately and the application can perform the required work. Technology labels need that operational evidence.
To get started, select a service, review its backup source and rehearse a restore. Our business backup plan for NAS, servers and SQL provides a scope matrix and an acceptance record.
Backups designed and operated for the needs of each business are an important foundation for recovery from ransomware.
Backups belong alongside prevention and intrusion detection. For now, my message is simple: sit down together, name the heart of the system and begin by testing its protection.
Wishing everyone good luck 🍀
TUNGTEK Tùng.
Notes written at 22:00 on 4 November 2026, Vietnam time.
Feeling worried, from the TUNGTEK data recovery desk.
Technical references and editorial note
- SentinelLABS — Babuk-derived ESXi lockers and attribution limits
- CISA / NSA / FBI / MS-ISAC — #StopRansomware Guide
- NCSC — Annual Review 2026: The impact of AI on cyber threat
Personal field notes supplied by Tùng Nguyễn, edited for the Blog. The Qilin timeline and Singapore response detail are the author’s account of information shared during that engagement. Public sources support only the linked technical context; they do not independently verify the private incident or a recovery outcome.
