BlackNevas Ransomware: Trigona Lineage, Partial Encryption, and Evidence-First Recovery
Why encrypting a fraction of a file can still interrupt an entire business, and what defenders should preserve before attempting recovery.
A ransomware incident often creates a misleading picture: the files are still on disk, their sizes may look normal, and only a fraction of their bytes may have been encrypted. Yet the associated database, virtual machine, or archive can be unusable. BlackNevas provides an important technical case study in why encrypted bytes and recoverable business data are not interchangeable metrics.
This article reviews publicly documented malware characteristics, marks the limits of available evidence, and proposes a defensible approach to recovery. It does not claim to reconstruct the intrusion path of any specific victim.
A closer look at BlackNevas / Trial Recovery
SentinelOne and AhnLab describe BlackNevas, also known as Trial Recovery, as a ransomware family observed around November 2024 with strong technical lineage to Trigona. The family has publicly described variants for Windows and Linux, as well as implementations targeting NAS and VMware ESXi environments. Observed encrypted file names may end in .-encrypted or .ENCRYPTED, while ransom notes are commonly called how_to_decrypt.txt. None of these indicators alone is sufficient for definitive attribution. [1][2]
Some encrypted files use a trial-recovery prefix, which helps explain the alternative name. According to AhnLab, different original file types can receive distinct renaming treatment. This seemingly cosmetic behavior can support classification, although it must be corroborated by binary-level examination and other evidence. [1]
Partial encryption: three modes, one major misconception
AhnLab’s September 2025 technical examination documents three modes in its analyzed sample:
/fast— Encrypts approximately 1% of file size — The unmodified portion may still depend on damaged metadata- Default — Encrypts roughly the first 10% — Structural damage can make the entire file unusable
/full— Encrypts the entire file — Restoration generally requires a valid key or an independent clean source
Those percentages are properties of a particular analyzed implementation and execution mode, not observed recovery rates. They should not be generalized to every BlackNevas build or incident. [1]
Forensic implications depend heavily on file format. Relational databases may require valid headers, allocation structures, transaction logs, and internal page relationships. A virtual disk may have critical metadata or guest file-system structures inside the damaged region. Compressed archives can rely on indexing and compression state that makes otherwise intact byte ranges difficult to use. The actual task is not to count surviving bytes, but to determine whether meaningful, internally consistent application data can be extracted.
Cryptographic design and the limits of decryption
The AhnLab report describes AES-based file encryption combined with RSA protection of the AES key material. It also documents additional structures associated with the encrypted file and checks used to identify encryption state. Without appropriate private-key material, those artifacts do not ordinarily expose a straightforward plaintext decryption key. [1]
This distinction matters in incident communications:
Decryption reverses encryption through an authorized, working key or a demonstrated cryptographic weakness. Data extraction attempts to recover usable information from remaining readable regions or alternative sources. Backup restoration restores an independent copy. They may overlap operationally, but they are not the same technical outcome.
Neither an encrypted file extension nor a ransomware note establishes how much of a specific database can be restored. Recovery assessments require direct examination of samples under controlled conditions.
Double extortion: claims are not evidence
The BlackNevas ransom note documented by AhnLab includes threats around a seven-day deadline, possible disclosure, and sale or publication of allegedly stolen data. This should be treated as attacker messaging, not proof that a particular victim’s data was successfully exfiltrated or that the criminals will reliably erase keys at the stated deadline. Independent validation calls for egress evidence, account activity, logs, confirmed disclosures, and a properly scoped investigation. [1]
Public leak trackers continue to collect BlackNevas-linked posts in 2026. Their counts differ across services because of aggregation methods, duplicates, claimed victim entities, and timing. For example, VULONE has reported dozens of claimed victim entries. These are claims, not verified incidents and not a defensible basis for calculating a real-world compromise rate. [4][5]
Get TUNGTEK Tùng 0963509115’s stories in your inbox
Join Medium for free to get updates from this writer.
Early profiles characterized the operation as a closed group with alleged partnerships for leak publication, rather than a broadly advertised affiliate-based RaaS program. Such arrangements are difficult to independently validate, and any actor relationship should be presented with the source’s own confidence level. [2][3]
An evidence-first response workflow
1. Contain without unnecessarily destroying evidence
Isolate affected systems and administrative paths. Coordinate containment across identity infrastructure, hypervisors, and shared storage. Preserve volatile artifacts when feasible and proportionate; if immediate network isolation is impossible and destructive activity continues, shutdown may be necessary despite the loss of memory-resident evidence. CISA provides a practical response framework. [6]
2. Acquire before modifying
Preserve notes, representative encrypted files, available samples, process history, identity events, remote access logs, NAS and hypervisor logs, and relevant snapshots. Acquire forensic images where appropriate, compute cryptographic hashes, and maintain evidence provenance. Perform testing against copies, not the originals.
3. Establish a variant-specific assessment
Correlate file extensions and ransom notes with the encrypted file structure, host artifacts, and available detections. Do not assume that an execution mode documented in a public sample matches the binary deployed in a new incident. Do not assume an MSP or VPN compromise without supporting logs.
4. Explore recovery paths in an ordered manner
First validate clean, offline, or immutable backups. Then assess application snapshots, previous versions, unaffected replicas, logs, or other independent copies. When technically justified, examine whether the untouched areas of affected files permit reconstruction or partial extraction. Document uncertainty and perform all such work within a controlled environment.
5. Validate application integrity
A recovered object is not necessarily a trustworthy business artifact. Validate content, database consistency, dependency relationships, transaction history where applicable, and usability with the original application stack. Rebuild the affected environment from trusted components before reconnecting restored workloads.
Is a public BlackNevas decryptor available?
At the editorial cutoff, this review did not verify a reputable, general-purpose free decryptor dedicated to BlackNevas among the public resources consulted. This is not a claim of permanent impossibility: security research and key disclosures can change the landscape. Monitor reputable decryption repositories and use candidate tools only on preserved working copies. [7]
Three lessons for defenders
First, measure recoverability by application validity, not by the percentage of bytes thought to be unaffected. Second, preserve evidence before engaging in repair or experimentation. Third, treat extortion claims, leak-site listings, and group narratives as leads that require independent corroboration.
For organizations operating NAS, SQL Server, or virtualized production environments, recovery and incident response must be handled as a single coordinated effort: one team may focus on forensic scope and containment while another tests data integrity and business restoration.
About TUNGTEK Research
Ransomware.VN by TUNGTEK publishes threat research and practical incident-response guidance. TRecovery by TUNGTEK provides ransomware triage, Ransomware Fast Check (RFC), recovery assessment, and professional data-extraction services where technically feasible. Outcomes are case-dependent and cannot be guaranteed before examination.
Original in-depth report (Vietnamese): https://link.tungtek.com/207 (TEKLink207).
For technical inquiries: https://cuudulieumahoa.com · 0963 509 115.
Data incident? Contact TUNGTEK.
References
- AhnLab ASEC, September 10, 2025: https://asec.ahnlab.com/en/90080/
- SentinelOne, BlackNevas Anthology: https://www.sentinelone.com/anthology/blacknevas/
- Halcyon, BlackNevas Profile (updated July 27, 2026): https://www.halcyon.ai/threat-group/blacknevas
- VULONE ransomware tracker (dynamic): https://vulone.com/ransomware/blacknevas
- Darkfield ransomware tracker: https://darkfield.orizon.one/groups/blacknevas
- CISA, #StopRansomware Guide: https://www.cisa.gov/stopransomware/ransomware-guide
- Emsisoft, Free Ransomware Decryption Tools: https://www.emsisoft.com/en/ransomware-decryption/
Editorial disclosure: No private victim identifiers, negotiation details, or unverified customer recovery outcomes are included. This article is a technical educational article and not incident-specific forensic evidence.
