Lynx Ransomware Decryption & Data Recovery

Lynx appeared in July 2024 and began recruiting affiliates on the RAMP forum in August under the handle "silencer", quickly building a scaled ransomware-as-a-service operation. Unit 42's binary comparison established roughly 48% overall function overlap with INC Ransom, rising to 70.8% among shared functions and higher still in the Linux/ESXi variant. Combined with the public sale of INC's source code in 2024, the consensus view is that Lynx is a repackaging of purchased or reused INC code.

The operation is notably productised. Group-IB's analysis of the affiliate panel describes modules for News, Companies, Chats, Stuffers and Leaks, supporting victim profile management, custom sample generation, negotiation chat and scheduled leak publication, with pre-built binaries covering Windows, Linux across x86, ARM, MIPS and PPC, and ESXi. The affiliate split is 80/20 in the affiliate's favour. That level of industrialisation lets crews without development capability attack virtualisation estates efficiently.

Victims were initially concentrated among US and UK retail, real estate, architecture, financial and environmental services firms. From early 2026 Lynx began posting in large single-day batches - 20 organisations on 5 January alone - passing 400 claimed victims in total, placing it in the upper-middle tier of active families.

One point matters specifically for Chinese organisations: Lynx's recruitment posts explicitly state that it does not operate in the CIS, Ukraine, China, Iran or North Korea, and does not target healthcare, government institutions, churches or children's charities. Such statements are not a security guarantee - affiliates do not always comply, and overseas entities and cross-border systems of Chinese groups fall outside that self-declared restriction - but there is currently no public report of a Lynx campaign targeting mainland China organisations.

Extension. .LYNX is appended to encrypted files (lowercase .lynx in some builds), with the original filename preserved.

Ransom note. A README.txt appears in affected directories; its body is stored Base64-encoded in the sample and decoded at runtime. The English text states that files are encrypted and data stolen, and supplies several Tor mirror addresses plus victim-specific login credentials.

Distinctive behaviour.

• Desktop wallpaper replaced with a ransom message.
• The note printed in bulk to reachable network printers; some early samples attempted to print a report through Microsoft OneNote.
• In ESXi environments, virtual machines force-stopped and snapshots deleted.

Telling Lynx from INC. The encryption flow is similar, but the extension (.LYNX versus .INC), note filename (README.txt versus INC-README.txt/html), leak site and key systems all differ. Because the code is shared, behaviour alone is easy to confuse, so accurate attribution requires comparing encrypted-file trailer structures and binary fingerprints.

Other indicators. Anomalous RDP logins before the attack, installation of remote control tools such as AnyDesk, credential dumping utilities, and archiving or cloud upload tools appearing on non-administrative hosts.

Lynx operates as RaaS, so specific tradecraft varies by affiliate, but public cases repeatedly show:

• Valid credentials plus remote access. Purchased credentials, infostealer logs or password attacks used to log into RDP, VPN and remote maintenance entry points - the dominant starting position.
• Phishing. Loader delivery to establish a foothold before pulling down further tooling.
• Edge and application exploitation. Unpatched internet-facing services used for entry.
• Lateral movement. RDP, PsExec, WMI and remote control tools such as AnyDesk combined with stolen domain accounts.
• Escalation and defence evasion. Credential dumping for domain admin rights, disabling or uninstalling endpoint protection, clearing logs.
• Hypervisor takeover. Once vCenter or ESXi credentials are obtained, the Linux/ESXi encryptor is deployed at host level, taking down every VM at once.
• Exfiltration completed before encryption as leak leverage.

Because the affiliate panel ships binaries for many architectures, Lynx affiliates have a wider blast radius in mixed estates - Windows domains plus Linux servers plus ESXi clusters plus assorted embedded devices - than most families. That is particularly unfavourable for the ageing-Linux-servers-and-virtualisation-cluster combination common in Chinese manufacturing.

Algorithms. The Windows encryptor performs Curve25519 Donna key agreement and encrypts content with AES-128-CTR using a per-file key; the Linux/ESXi variant uses the same cryptographic design.

Encryption modes. Four configurable levels are offered: fast (about 5%), medium (about 15%), slow (about 25%) and entire (100%). This matters enormously for recovery assessment. If an affiliate chose fast or medium, 75% to 95% of the blocks in large files - databases, virtual disks, backup containers - are completely untouched and structural repair has substantial room. If entire was chosen, there is effectively none. The encrypted proportion must therefore be measured before a recovery path is chosen; no general rule applies.

Command-line control. Target directories, single files, exclusion paths and hidden execution are all selectable, letting affiliates tune behaviour to the environment.

Virtualisation handling. The Linux/ESXi build force-terminates running virtual machines and deletes VM snapshots before encrypting files under /vmfs/volumes, ensuring complete encryption and making rollback difficult.

Recovery inhibition. The Windows build deletes volume shadow copies through DeviceIoControl calls and attempts to damage backup partition drives.

Double extortion. Data is exfiltrated before encryption and published in stages if unpaid, with wallpaper and printed notes adding pressure channels.