The Locked Lab Before the Board Practical

1. Do not boot the two powered-off PCs. They may hold the only unencrypted copy of the dropper and the startup mechanism that launched it. Booting can trigger encryption or overwrite volatile evidence. Label them and leave them off.
2. Isolate the 22 infected PCs, but do not shut them down. Pull the Ethernet cables and disable the lab switch uplink. Shutting down loses RAM-resident keys and process lists, while leaving them networked lets encryption continue reaching the S: drive and other hosts. Isolation is the compromise.
3. Disconnect the attendance server and pause the backup job. A backup taken after infection may be encrypted or may contain the malware. Verify the nine-day-old copy by restoring it to a scratch disk and scanning it before trusting it.
4. Preserve evidence. Photograph each screen and READ_ME.txt, record system times, export any router or switch logs, and start a written timeline. Do not delete the ransom notes.
5. Notify the principal in writing and report the incident. In India, report to CERT-In and, where personal data of students is involved, consider the breach-notification duties under the DPDP Act, 2023.
6. Disable the shared labadmin account only after isolation; changing a password on a compromised host is not containment.

The ordering matters because spread is active, evidence is perishable, and a bad restore repeats the incident.

Risk 1: the initial vector is destroyed. The shared labadmin password and the likely use of a USB device or mapped drive mean the same entry point may survive. Wiping every machine removes the two offline PCs and any logs that could show how the malware arrived, so the rebuilt lab can be reinfected.

Risk 2: the backup is not trusted. The backup lives on the same server that was reachable from infected PCs. It may contain the malware or be partly encrypted, and restoring it blindly could re-trigger encryption. Nine days of attendance data would also be lost if the copy is unusable.

72-hour plan:

• Hour 0–4: keep all machines isolated; image or preserve the two offline PCs for later analysis; restore the backup to a separate scratch disk and scan it.
• Hour 4–24: rebuild 20 exam PCs from a known-good offline image, patch them, give each a unique local administrator password, disable SMBv1 and autorun, and test one machine before cloning.
• Hour 24–48: restore only verified student files from the scanned backup; keep the attendance server isolated; change all domain and lab credentials; enable logging.
• Hour 48–72: run the practical on the rebuilt subset, keep the remaining machines offline, and rebuild them after the exam.

This preserves evidence, avoids reinfection, and still meets the exam deadline.

Do not pay. Payment does not guarantee decryption, funds criminal activity, and may create further extortion. A verified nine-day-old backup exists, and the data loss is limited and recoverable. Paying also sets a precedent that invites repeat attacks on a school with weak controls.

Who to tell:

• The principal and management, in writing, with a factual timeline.
• Staff and students whose attendance data was affected, once the facts are confirmed; avoid naming suspected students.
• The school board or education department, according to its incident rules.
• CERT-In, and the Data Protection Board of India if the incident amounts to a personal data breach under the DPDP Act, 2023.
• The police cybercrime portal if there is extortion or if the school wants a formal investigation.

The reasoning is harm minimisation plus legal duty: affected people need to know so they can watch for misuse, and regulators need timely notice. Notification should be accurate and should not speculate about who caused the infection.