Malware News Technical analysis of ByteToCrypt, the custom Linux ransomware deployed by the ByteToBreach threat actor.

[Khushal]

Content source

https://tlpblack.net/blog/20260728-a-deep-dive-into-bytetobreach-s-bytetocrypt-ransomware

Executive Summary​

This blog focuses on technical analysis of the custom ransomware strain utilized by the ByteToBreach threat actor, dubbed "bytetocrypt". There are multiple quirky aspects of this bytetocrypt and the known actor's TTPs, suggesting that this ransomware was developed by a capable software developer, but less experienced at ransomware.

• the encryption implementation is fragile and error-prone but not cryptographically breakable
• this code is not an ESXi-aware platform but has been deployed to ESXi environments
• the ransomware is not runtime interactive for its operator
• following encryption and ransom tasks, it autoexecutes a set of anti-forensics capabilities

This immaturity invites extra attention to bytetocrypt's encryption capabilities. But when it comes to its implementation, all-in-all the technology presented is brittle but effective. Our assessment of the ransomware is based on several factors:

• it ignores randomness, cryptographic, I/O (deletion and rename), and anti-forensics failures
• mistakes read errors for end-of-file
• truncates paths to fixed buffers
• loses metadata
• can announce success after partial or failed work

A straightforward brute-force defeat is not possible. The ransomware's defects can spare some files or create corrupted output, but they do not disclose correctly generated keys. The practical recovery paths include the RSA private key, a per-file AES key captured from live memory, immutable/offline backups, still-open plaintext file descriptors, or storage-level recovery.

Additionally for the ransomware itself, contrary to common assumptions regarding ESXi-related incidents, this binary is not an ESXi-aware platform. It operates as a generic, directory-based encryptor with no inherent hypervisor awareness. It compromises virtual-machine data solely because operators can execute it from datastores or other accessible directory structures. Based on our experience from other 2026 TLPBLACK Incident Response engagements, we've seen this same behaviour used by other ransomware operators as well: obtain root access and then execute a cryptor from accessible datastores.

Notable previous reporting includes some detail on targeting, infrastructure, and TTPs. In addition to other regions, BytetoBreach was and is active in Europe for at least a year. ANCPI, the Romanian National Agency for Cadastre and Land Registration, was attacked, affecting systems central to property registration and related public services. In July 2026 this cyberattack on ANCPI produced a prolonged, widely reported outage of its public-facing services. Romanian public broadcasting reported on 18 July 2026 that authorities were investigating the incident. Those authorities assessed that the related “ByteToBreach” actor had been active since 1 June 2025, and their motivation was financial.

Recently an individual presented himself as a part of ByteToBreach and described the operation. In an July 17 interview recorded in a main-stream Romanian news article, this person claiming to be a ByteToBreach actor said there were no zero-days involved and described the operation as opportunistic. They claimed the principal databases were exfiltrated rather than encrypted, denied a political motive, described himself as independent, and framed decryption help as negotiable for payment. Of course, these are adversary statements and should not be treated as reliable, trustworthy information.

A Deep Dive into ByteToBreach's ByteToCrypt ransomware

Technical analysis of ByteToCrypt, the custom Linux ransomware deployed by the ByteToBreach threat actor: encryption internals, anti-forensics behavior, decryption prospects, and IOCs.

tlpblack.net

 

[Bot]

Key Takeaways

The excerpt describes a ransomware family whose implementation is unreliable, but not necessarily cryptographically weak. Bugs such as path truncation, incomplete processing, ignored I/O errors, and metadata loss may leave some files untouched or damaged, but they do not automatically provide a method to derive the encryption keys.

The most realistic recovery opportunities are therefore:

• Obtaining the attackers’ RSA private key
• Recovering per-file AES keys from live memory or active processes
• Using verified offline or immutable backups
• Checking for still-open plaintext file handles on affected systems
• Attempting storage-level recovery where appropriate

The ESXi point is also important: a generic Linux encryptor can affect virtual-machine files without being hypervisor-aware. Execution privileges and datastore access may be sufficient; ESXi-specific functionality is not required.

Any claims about the actor’s identity, motives, intrusion path, or exfiltration activity should be treated as unverified unless supported by independent forensic evidence. Likewise, the encryption conclusions should be confirmed against samples, logs, memory captures, and unaffected systems rather than inferred from the ransom note alone.

For an active incident, preserve affected systems and volatile evidence before cleanup, isolate them from the network, and involve qualified incident-response personnel. Do not rely on decryptors or recovery claims until they have been validated against copies of the encrypted data.