Lynx encrypts a leasing company's Oracle ledger and threatens to leak contracts

The client is a mid-sized leasing company whose core accounting, contract ledger and regulatory reporting system share one Oracle database on Linux. The database ran in ARCHIVELOG mode with archived logs written to the local fast recovery area, while RMAN full backups were pushed each night to a backup appliance holding its own independent credentials.

To support cross-border leasing business, staff at an overseas subsidiary and several outsourced developers reached the head office domain through the same VPN, and a group of long-unused contractor accounts there had no multi-factor authentication.

Late on a Friday the duty engineer found the Oracle instance would not open, with ORA-01110 datafile errors in the alert log. The .dbf datafiles, control files and the archived logs in the fast recovery area all carried an appended .LYNX extension, and README.txt had appeared in the affected directories. Printers at several branch sites had begun printing an English ransom note on their own, and office desktop wallpapers had been replaced with a ransom message.

The note supplied no email address, only several Tor mirror addresses and victim-specific login credentials. The next day the attacker claimed through the negotiation portal to hold customer contracts and lessee records, threatening staged publication on its leak site. The month's regulatory reporting deadline was nine calendar days away, and the client had made no attempt to open the database before calling us.

Containment went out on the first call: keep the database host powered but off the network, no startup, no recover, no resetlogs, pause backup and replication jobs, and take the appliance off the network without powering it down or using domain credentials on it.

• Evidence and imaging. Read-only images of the database host disks and appliance volumes, with alert and trace logs, listener logs, VPN and domain authentication records, crontab and authorized_keys; all later work ran on copies.
• Family confirmation and recoverability. The .LYNX extension, the Base64 body of README.txt and encrypted-file trailer fingerprints confirmed Lynx and separated it from the code-related INC Ransom. With no public decryptor, measured coverage landed around the 15% level, leaving long untouched stretches in the large files.
• Recovery execution. The previous night's full backup was retrieved under the appliance's own credentials and restored on an isolated recovery host. Usable redo records were extracted from the partially encrypted archived logs against Oracle block structures and rolled forward sequence by sequence to roughly forty minutes before encryption began; the reporting database was rebuilt the same way.
• Hardening in parallel. Dormant and contractor VPN accounts removed and multi-factor authentication enforced, listener addresses tightened, unauthorised remote tools such as AnyDesk and their persistence cleared, database and domain passwords reset, immutable and offline backup copies added.
• Deliverables. Kill-chain reconstruction, coverage measurement report, recovery scope and gap list, exfiltration impact assessment, remediation sign-off checklist.