BlackNevas Ransomware: Trigona links, selective encryption and double-extortion risk

Executive summary

BlackNevas, also called Trial Recovery, is a ransomware family identified by researchers from late 2024, with a clear code and technical relationship to Trigona. Its notable features include operation across multiple platforms, partial or full encryption modes, AES/RSA key management, and pressure involving data allegedly stolen. These characteristics were observed in research samples; they are not a default configuration that can be inferred for every attack. [S1][S2][S3]

Tracking services recorded BlackNevas responsibility claims in 2026. VULONE lists 47 claims in the source checked for this article; other platforms can differ because of organization naming, duplicate records and collection dates. A claim is not an independently investigated and confirmed incident. [S4][S5]

1. Identification and the Trigona relationship

SentinelOne and AhnLab date BlackNevas emergence to around November 2024, while leak trackers commonly date observed victim-list activity to 2025. These dates need not conflict: one describes malware emergence, the other observation of claims in tracking infrastructure. [S1][S2][S4]

The name Trial Recovery comes from encrypted filenames with the trial-recovery prefix in observed samples. AhnLab records random.random.-encrypted and trial-recovery.random.random.-encrypted, with the latter found for some document and image types. This is not a unique identification signal; a similar filename alone does not establish BlackNevas across a system. [S1]

Some analysis describes a closed operation rather than publicly recruiting affiliates through RaaS. Relationships with data-publication groups described by SentinelOne and Halcyon rest on observations and claims; they should not be presented as proof of formal organizational relationships. [S2][S3]

2. Affected platforms and the attack surface

Published variants can target Windows, Linux, NAS and VMware ESXi. Storage and virtualization systems can spread business disruption across many services. SentinelOne discusses phishing, existing vulnerabilities and SMB access in some campaigns. The entry path for a specific organization must be established from logs and artifacts rather than inferred from a ransomware family name. [S2]

For environments using outside IT service providers, some independent reporting hypothesizes that contemporaneous claims relate to a shared MSP. This is an investigative lead, not a verified supply-chain campaign without evidence of compromise of the management infrastructure. [S8]

3. Encryption: AES handles data, RSA protects keys

According to AhnLab, after selecting a target file, the malware encrypts data with AES and protects the AES key with an RSA public key, storing related material in the encrypted file. The sample also keeps state markers to avoid repeat processing. The corresponding private key is not available as plaintext in the file, so a ransom note and ordinary encrypted files are insufficient to derive a decryption key. [S1]

In the sample AhnLab analyzed: /fast encrypts about 1% of total file size, leaving many bytes unchanged but potentially damaging critical headers or metadata. The default encrypts about the first 10%; this does not mean 90% of data is recoverable. /full encrypts the whole file, ordinarily requiring a valid key or an alternative data source.

The 1% and 10% figures describe the amount encrypted by that malware sample in those modes, never recovery success rates. SQL, VMDK, ZIP, image and document files may depend on affected structures even if most bytes remain. Versions and parameters in other incidents may differ. [S1]

The analyzed sample excludes some system files and extensions such as .sys, .dll, .exe and .log, as well as some virtual-machine state files. These exclusions describe technical behavior and do not guarantee that these file types are always safe. [S1]

4. Ransom notes and seven-day pressure

AhnLab records the note name how_to_decrypt.txt and threats concerning decryption keys, information leaks, publication and auctioning of data. The seven-day ultimatum is attacker pressure, not proof that keys will actually be deleted on day seven. Claims of data theft require corroboration through network traffic, access logs, destination systems, publication evidence and related artifacts. [S1]

Note names, contact addresses and file formats can vary between campaigns. Victim server identifiers and negotiation content from a case not authorized for disclosure should not be published.

5. Investigative indicators and their limits

Initial classification signals include how_to_decrypt.txt, .-encrypted or .ENCRYPTED extensions in some samples, names containing trial-recovery, abnormal file changes and artifacts of encryptor execution. These support triage but do not individually establish the malware family. [S1][S2]

AhnLab publishes MD5 hashes for particular research samples. A match applies to the actual file with that hash; this is not a comprehensive variant list: 2374998cffb71f3714da2075461a884b; 4a1864a95643b0211fa7ad81b676fe2e; 9f877949b8cbbb3adfe07fd4411b9f26; f2547a80dd64dcd5cba164fe4558c2b6.

Incident verification needs hashes, notes, byte structures, process timelines, EDR, Windows Event Logs, RDP/VPN, SMB, AD, hypervisor and NAS logs together. Do not attribute an IP, CVE or entry mode to a specific case merely because a family report mentions it.

7. Is there a public BlackNevas decryptor?

At editorial time, the checked public decryptor sources did not establish a reliable free specialized tool capable of universal BlackNevas decryption. This is a time-limited search result, not a claim that no tool can ever exist. Continue checking Emsisoft, No More Ransom and security-vendor announcements, and test only on preserved copies. [S7]