Scenario solution
Oracle Database Encrypted by Ransomware
- Oracle Database
- Oracle RAC
- ASM
- Data Guard
- RMAN
- 医院 HIS
- Oracle EBS
- Red Hat Enterprise Linux
When Oracle datafiles (.dbf), control files and archived redo logs are encrypted, hospital HIS, large ERP and group finance systems typically go down as a whole. This page covers triage order, the role of control files and archived logs, and when block-level repair or RMAN restore applies.
Typical symptoms
- Datafiles (.dbf), control files (control01.ctl) and online redo logs (redo01.log) are renamed or carry an appended extension
- Instance startup raises datafile corruption or header-read errors such as ORA-01110, ORA-01122 or ORA-27047
- The database stops at nomount or mount and will not open; the alert log reports block checksum failures
- Front-end applications such as HIS, EMR and EBS report database connection failures en masse, forcing outpatient and inpatient workflows onto paper
- RMAN backup directories, expdp .dmp exports and the archived log destination are encrypted or wiped as well
- Unknown SSH public keys and unexpected crontab entries appear on the Linux host, with the oracle user's shell history cleared
Business risk & common mistakes
Oracle usually carries an organisation's most critical, least loss-tolerant workloads: hospital HIS and electronic medical records, group finance and production systems, the back end of large ERP deployments. These environments have very strict recovery point objectives — losing a few hours of data in clinical or financial contexts can be a material incident, not an inconvenience.
Oracle's recovery logic differs markedly from SQL Server, and the sequence cannot simply be copied across:
- The control file is the map for recovery. It records the datafile inventory, checkpoints and log sequences. If all control files are lost, even intact datafiles require a backup control file or a recreated control file before the database will open.
- Archived redo logs define the recovery point. In ARCHIVELOG mode, a usable datafile backup plus a continuous archived log stream allows point-in-time recovery; once archived logs are encrypted or deleted, the recovery point snaps back to the last usable backup.
- ASM and raw-device deployments are harder. Data does not sit on a normal filesystem, so encryptors often reach only the ASM disk headers or the whole block device. Recovery is nothing like file-level repair, so the storage layout must be established first.
Common mistakes, most damaging first:
- Repeated startup / recover attempts on the live database, or operations such as alter database datafile offline drop and resetlogs. These rewrite the control file and file headers and can sever the remaining recovery path outright.
- Trying to mount or rebalance an ASM disk group while disk headers are damaged, risking overwrite.
- Recovering data onto the original disk, or writing exports back to the same storage.
- Restoring an encrypted .dmp or RMAN backup set over the existing files.
- Rebooting the host. On Linux this discards open file handles and process artefacts still in memory, and may trigger automatic mounts and writes.
We do not recommend paying, and we do not negotiate on your behalf.
Our response plan
Isolate, preserve, and establish the storage layout
Isolate the database host and do not reboot or attempt to open the database. First establish the storage layout: filesystem, ASM, raw device or SAN LUN, and whether RAC or a Data Guard standby exists. Choose evidence handling accordingly — read-only images for filesystems, block-level images or storage snapshots for ASM and LUNs. Preserve alert logs, trace files, listener logs, /var/log/secure, crontab, authorized_keys and a process snapshot.
Identify the family and inventory recovery material
Identify the family and encryption mode (full-file, intermittent or header-only) while inventorying material item by item: datafiles, control files, online redo logs, archived logs, RMAN backup sets, expdp exports, the Data Guard standby, storage snapshots. Entropy-check each one separately — in many cases the archived log destination was only partly encrypted, or the standby survived intact behind network isolation, and such details decide the achievable recovery point.
Assess recoverability: RMAN restore, block repair, or rebuild
Assess three paths in priority order. RMAN or standby restore: where a usable backup set or standby exists, point-in-time recovery with archived logs gives the best and most native result. Block-level repair and extraction: where datafiles are header-only or intermittently encrypted, undamaged regions can be parsed against Oracle block structures, segment and extent maps reconstructed, and table data extracted directly; a missing control file can be worked around by recreating it. Rebuild: where core data is genuinely unusable, backfill from the standby, downstream systems, interface logs and paper records. The assessment states the achievable recovery point and the gaps.
Execute recovery in an isolated environment
Stand up a clean recovery host with the same Oracle version and patch level as production, and operate exclusively on the image. On the RMAN path, run restore database, then recover database until time or SCN. On the repair path, load extracted table data into a freshly created database and hand it to the application team for validation. In clinical and financial settings, restore the critical databases and tables first — patient master index, current admissions, general ledger — so operations can resume, then bring non-critical history back in batches.
Harden, rebuild backups, and sign off
Close the entry point: keep 1521 off the public internet, tighten listener addresses and ACLs, apply Oracle and OS patches, remove rogue SSH keys and crontab entries, and reset the oracle / grid and all database credentials. Rebuild backups as RMAN full backups plus archived log backups with one offline or immutable copy, ensuring the standby and backup storage do not share credentials. Business owners sign off against key metrics — patient counts, current admissions, ledger balances, document continuity — accompanied by an incident report and remediation checklist.
Recovery paths
Recovery prospects for Oracle hinge on two things: whether a usable backup chain exists, and how far encryption reached into the datafiles.
Path 1: RMAN restore or Data Guard failover. The first choice, provided the backup sets or standby were untouched and archived logs are continuous. Physical standbys often sit on a different network segment and do not share Windows domain credentials, and have survived intact in numerous incidents — an underrated recovery resource. Verify first whether the standby has already applied the damage; a standby that was disconnected before the attack is safer still.
Path 2: block-level datafile repair and table extraction. Applies where .dbf files were header-only or intermittently encrypted. Oracle also organises data in blocks with block-header checksums, so untouched blocks remain parseable, segment maps can be reconstructed and table data exported into a new database. Missing control files and redo logs do not block this path, but the output is readable data: some rows, indexes, LOB segments and partition metadata may be lost, and PL/SQL objects and privilege configuration usually need rebuilding from source control or documentation.
Path 3: logical export remnants and external copies. Look for historical expdp / exp .dmp files, data pump directories, reporting staging tables, ETL landing files, downstream warehouses and interface logs. In clinical and financial environments, downstream systems often retain enough to rebuild key business views.
Path 4: storage- and hypervisor-layer snapshots. With ASM or raw devices, where file-level techniques do not apply, array snapshots, VM snapshots and replicated volumes are frequently the only viable rollback point.
Path 5: public decryptor. Only where the family and version clearly match a published tool, validated against a copy.
Stated plainly: when ARCHIVELOG mode was off, backups had gone long unverified, and control files sat on the same volume as datafiles and were encrypted together, the recoverable scope narrows sharply. We avoid "100%" and "guaranteed recovery"; assessment produces a conclusion before implementation begins. We do not pay ransoms and we do not negotiate.
Common ransomware families
- No public decryptor
TellYouThePass
TellYouThePass is the archetypal vulnerability-driven ransomware family in China, mass-deployed against internet-facing ERP, OA, finance and middleware systems. It appends .locked and hits both Windows and Linux servers. No public decryptor exists.
- Some versions decryptable
GlobeImposter
GlobeImposter has been active since 2017 and is highly prevalent in China through its Chinese-zodiac variants (such as .Dragon4444) and Olympian-gods variants (such as .Ares666). It spreads by brute-forcing RDP/SMB and moving laterally, and caused widespread hospital infections in China in 2018. Mainstream variants have no decryptor.
- No public decryptor
BeijingCrypt
BeijingCrypt takes its name from the .beijing extension used by early builds. It is a persistently prevalent family in China, deployed by hand after brute-forcing remote desktop or database credentials, and has cycled through .beijing, .360, .520, .halo and .bixi variants. No public decryptor exists.
- Free decryptor available
Phobos
Phobos is a RaaS family that relies mainly on brute-forced RDP and has spawned a long list of variants (.eking, .faust, .elbie, .devos and more). It has been a persistent presence in Chinese server-ransomware cases, and in July 2025 Japan's National Police Agency released a free decryptor covering part of the lineage.
- Some versions decryptable
LockBit
LockBit is one of the largest ransomware-as-a-service operations in the world. Despite the 2024 law-enforcement takedown it returned as LockBit 5.0, with working Windows, Linux and VMware ESXi payloads, and it remains one of the most frequently seen families in China.
Hardening recommendations
- Enable and verify ARCHIVELOG mode. Without archived logs there is no point-in-time recovery. Give the archive destination its own space and its own backup rather than leaving it only on the database host.
- Send RMAN backups somewhere independent. Do not mount the backup target on the production host or reuse production credentials; write at least one copy to immutable storage or offline media, and run restore validate regularly to prove the backup sets are usable.
- Make real use of a physical standby. A Data Guard standby on a different network segment with its own OS accounts and passwords is a fast failover point during a ransomware incident — provided it does not share administrative credentials with the primary.
- Keep 1521 off the internet and tighten the listener. Use TCP.VALIDNODE_CHECKING or firewall whitelisting to restrict sources, and close unnecessary XDB and HTTP service ports.
- Track Oracle and OS patches quarterly. Follow Oracle quarterly security patches (CPU / RU) and Linux kernel privilege-escalation issues; database hosts must not sit on old versions indefinitely.
- Reduce the Linux administration surface. Disable password logons in favour of keys, forbid direct remote root logon, audit changes to authorized_keys and crontab, and avoid reusing passwords across oracle and grid accounts.
- Cover Linux database servers with EDR or host security, monitoring anomalous SSH logons and mass file rewriting or encryption behaviour — not just the Windows estate.
- Drill recovery, not backup reporting. Every six months, run a full RMAN recovery in an isolated environment and time it, to obtain genuine RTO/RPO figures.
Emergency response
Data already encrypted? Stop and let an engineer look first
We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.
Related industries
Healthcare Ransomware Response and Recovery
When a hospital is hit, registration, consultation, orders, billing, laboratory and imaging fail at the same moment and care falls back to paper. This page covers the healthcare threat picture, a recovery priority built around clinical continuity, and the handling of patient data and compliance obligations.
Manufacturing Ransomware Response and Recovery
Ransomware in manufacturing hits information systems and production cadence at the same time: with ERP down there are no orders, with MES down there is no schedule, and an encrypted drawing library takes the process documentation for an entire product line with it. This page covers the asset profile, recovery priorities and targeted defences.
Financial Services Ransomware Response and Recovery
Financial and quasi-financial institutions face far stricter requirements on data integrity, transaction continuity and regulatory reporting than most sectors, so one ransomware event hits availability, customer trust and compliance simultaneously. This page covers the threat profile, a recovery approach centred on transactional consistency, and hardening priorities.
Government and Public Sector Ransomware Response
Public sector ransomware incidents run on three lines at once: service interruption, data security and mandatory reporting. When document circulation, archives and integrated service platforms stop, both public services and internal operations are affected. This page covers the handling sequence, reporting duties and hardening priorities.
Related services
Data Recovery
Recovery beyond decryption: backup repair, database repair and remnant extraction.
Ransomware Decryption
Identify the family first, then commit to a recoverable scope — without paying a ransom.
Incident Response
Round-the-clock intake: contain first, preserve evidence second, recover third.
Security Hardening
Close the handful of paths attackers actually use: exposure, weak credentials, patches, privilege, backups.
FAQ
Frequently asked questions
Our Oracle .dbf files are encrypted — can they be recovered?
Three things decide it. First, whether a usable RMAN backup set or Data Guard standby exists — if so, the native recovery path gives the best result. Second, how far encryption reached into the datafiles: large .dbf files are often header-only encrypted, and the intact Oracle block structures behind that can still be parsed and their table data extracted. Third, the continuity of archived redo logs, which determines how close the recovery point can get. When none of the three is available the recoverable scope narrows considerably, and only an assessment can give a real answer.
The control files were encrypted too — is the whole database lost?
No. Control files record the datafile inventory, checkpoints and log sequences — a map, not the data itself. There are three usual approaches: restore the control file from an RMAN backup, recover it from autobackup, or recreate it (create controlfile) where the datafiles are usable and then run recovery. If none of that is available, the block-extraction path does not depend on the control file at all — parsing datafile block structures and exporting table data works regardless. What matters is not repeatedly attempting resetlogs-style operations on the original files, which genuinely does destroy remaining options.
We use ASM — how should an encrypted environment be handled?
With ASM the data does not live on a normal filesystem; encryptors typically damage only the ASM disk headers or write across the block device, so handling differs entirely from file-level cases. The first rule is do not try to mount the disk group and do not rebalance — take LUN-level block images or array snapshots at the storage layer first. Then assess damage from the image: header damage may be repairable, while broad overwriting of metadata areas pushes you toward backups, the standby or storage snapshots. These cases depend heavily on early, correct on-site decisions, so engaging sooner preserves more options.
With hospital HIS down, can part of it be restored so outpatient services can run?
Yes, and it is usually the right approach. Clinical recovery should be sequenced by business continuity rather than by database order: restore the patient master index, current admissions and outpatient encounters, orders and billing tables first so registration, consultation, payment and dispensing can resume; bring laboratory history, imaging archives and research or statistical data back in later batches. We set the priority list together with the IT department and clinical units, and keep a plan for back-entering the data captured on paper during the outage.
Could the Data Guard standby have been encrypted as well?
It is possible, but a standby survives more often than the primary. Three factors decide it: whether it sits on a separate network segment, whether it shares administrative credentials (especially domain accounts), and whether log apply was running at the time of the attack. In several incidents the standby survived intact thanks to network isolation and independent accounts, becoming the fastest available recovery point. The correct sequence is to isolate the standby first and resist starting sync or failing over, verify its datafiles and archived logs, and only then plan the switchover.
Updated