Ransomware at a district cooperative bank branch: first hour, backups, and reporting
A district cooperative bank runs its core banking application from a central data centre, but each of its 25 branches keeps a Windows Server file server for scanned KYC documents and a small payroll share. On Monday at 09:20 one branch reports that its files now carry a .locked extension and a ransom note demands payment in cryptocurrency. Mapped drives on 14 branch PCs are affected. The NAS used for nightly backups is domain-joined, permanently mounted on the file server, and holds 30 days of backups. The same local administrator password is used on all branch servers, and the domain administrator account is used to run backups. Staff routinely use personal USB drives for printing. The branch has unplugged the server's network cable, but the PCs remain connected to the LAN and to the WAN link to the data centre. The bank opens at 10:00 and the CISO cannot be reached for two hours.
1. Set out your first-hour actions in priority order with the reason for each, including what you would deliberately not do.
Read the worked answer
Order: stop spread, preserve evidence, keep the bank trading through the unaffected core system.
- Isolate properly. Unplugging one cable is not isolation - 14 PCs are still on the LAN and can keep encrypting shares. Disable the branch's switch ports or the branch WAN interface at the router. Keep the file server powered on if a memory image can be taken; if there is no forensic capability, image the disk and then shut it down cleanly, recording the time.
- Cut the blast radius toward the data centre. Block SMB (445/139) and RDP from the branch to the data centre, and confirm the core banking application shows no anomalous access.
- Reset the shared credentials. Identical local administrator passwords mean one credential opens 25 branches; the domain admin account used for backups is worse. Reset branch local admin passwords and the backup service account after checking for persistence, and disable the account until the new secret is in the vault.
- Sweep the other 24 branches for the same extension, for services or scheduled tasks created in the last 72 hours, and for unusual outbound traffic.
- Preserve evidence: ransom note, wallet address, sample encrypted files, Windows event logs, NAS logs, and the USBSTOR registry keys showing which USB devices were used.
- Communicate and keep trading: brief the CISO, board and branch manager; confirm the core application is healthy, then let deposits and withdrawals continue. KYC scans move to paper and a scanner-to-email workaround that does not touch the server.
Deliberately not: pay; reimage before imaging; reconnect the NAS to 'just restore'; delete encrypted files to tidy up.
2. Can the existing backups be trusted for recovery? Redesign the backup scheme and state the RPO/RTO you would commit to.
Read the worked answer
Trust assessment - treat the backups as compromised. The NAS is domain-joined, permanently mapped on the file server, and was online during the attack, so the same credentials that encrypted the server could reach and delete or encrypt the backups. A backup the production server can write to is not a backup. A single device in the same room also breaks the offsite rule, and there is no evidence of a tested restore.
Recovery: image the NAS, then look for an immutable snapshot or an earlier backup that predates initial access (check the first suspicious logon or USB insertion, not the first encrypted file). Verify integrity by hashing sample documents against known-good copies before restoring.
Redesign (3-2-1-1): three copies, two media types, one offsite, one offline or immutable (object-lock repository or rotating removable media). The backup repository must not be domain-joined, must use separate credentials with MFA on the console, and the backup service account must be barred from interactive logon. Segment backups onto their own VLAN and alert on deletion of restore points.
RPO/RTO: for scanned KYC documents an RPO of 24 hours and an RTO of 8 hours per branch is defensible; payroll may tolerate 7 days. Publish those numbers, then run a quarterly restore drill into an isolated VLAN and record the actual time achieved - an untested RTO is a wish.
3. State the reporting and legal obligations and the evidence you would preserve, and explain why paying is not a technical solution.
Read the worked answer
Reporting: under the CERT-In Directions of April 2022, specified incidents - ransomware included - must be reported to CERT-In within 6 hours of noticing, in the prescribed format, with relevant logs; logs must be retained for 180 days within India. As a bank it also falls under RBI's cyber security framework, which requires prompt reporting to RBI (currently within hours, depending on incident type) and to the board or its audit committee. If customer data was taken, the IT Act's Section 43A compensation duty for failure to protect sensitive personal data and the SPDI Rules' security and breach-notification obligations apply, along with police complaint where demanded. Verify the current circular before quoting deadlines externally.
Evidence: chain-of-custody log, hashed disk and memory images, the ransom note and wallet address, firewall and proxy logs, NAS access logs, VPN and RDP logon history, USB device history, and email headers. Keep a timeline with who did what and when.
Why not pay: decryption tools are unreliable, payment funds criminal groups and may breach sanctions, and paying marks the bank as a repeat customer. The recovery that actually works is a verified immutable backup plus removal of the initial access route - most likely the personal USB drives or an exposed remote-access service. Paying while the entry point remains open simply restarts the clock.