The Payroll Email, the Shared Login and the Plugged-In Backup
The office of a school in Ludhiana has 40 staff sharing six computers. All six sign in with one account, office, whose password is school@123 and has not changed in three years. Backups of the result files run every Friday to an external hard disk that stays plugged into the office computer all week, and the office computer keeps a mapped network drive to the server that holds the examination records.
On Monday a clerk receives an email appearing to come from the principal's real address, [email protected], with the subject "Salary revision - open before 5 p.m." and an attachment named salary_revision.xlsm. The clerk opens it and clicks "Enable Content" when Excel asks. Nothing visible happens. On Tuesday morning every document on the office computer has a .locked extension, a file named READ_ME.txt demands payment in Bitcoin within 72 hours, and the mapped drive on the server shows the same names.
The principal wants to pay immediately to recover the results before the board deadline. The Friday backup is still sitting on the external disk.
1. Identify the attack chain and list the immediate actions the school should take, in order, with the reason for each. State clearly where you stand on paying the demand.
Read the worked answer
Chain. A spear-phishing email (plausible sender, urgency, salary hook) delivered a malicious macro in an .xlsm workbook. "Enable Content" allowed the macro to run, it downloaded or unpacked a payload, and that payload encrypted files locally, then on the mapped drive, and very likely on the attached external disk. Displaying a READ_ME.txt with a Bitcoin demand is the signature of ransomware.
Immediate actions, in order.
- Isolate, do not shut down blindly: disconnect the machine from the network (cable and Wi-Fi) and disconnect the mapped drive so encryption cannot spread further. Keeping the machine powered preserves volatile evidence such as the running process, though a school should follow its incident plan and any advice from a responder.
- Unplug the external backup disk immediately and treat it as possibly encrypted - do not open more files from it.
- Do not pay. Payment funds criminal activity, does not guarantee a working decryptor, and there is no assurance the stolen data is deleted. Report to the principal, the district education office and the police cyber cell, and file a complaint at cybercrime.gov.in with the email headers, the file name and the note.
- Photograph the ransom note and preserve the email and logs before cleaning anything; find out exactly when the infection started so the scope of encryption is known.
- Rebuild from a known-good source: reinstall the affected machine rather than trusting a cleaned one, restore data from a backup made before Monday, and change every password from a clean device, including the shared office password.
- Notify anyone whose data was on the server, and check the server itself for encrypted files and unauthorised logins.
The results can be reconstructed faster from registers, teacher mark sheets and the server's remaining copies than the 72-hour deadline suggests - paying should not be on the table.
2. Evaluate the account and password practice. Explain why one shared login defeats accountability even if the password were strong, and why "the sender address was the principal's real address" is not evidence that the principal sent the mail.
Read the worked answer
The shared account. Six people, one credential, unchanged for three years. school@123 is short, predictable, built from the school's own name, and would appear in any dictionary or pattern-based attack; reuse elsewhere would also leak it. But the deeper defect is not strength, it is identity. Every log entry - file access, logins, mailbox activity, the moment the attachment was opened - records office, not a person. After this incident the school cannot say who opened the file, cannot prove who did not, and cannot revoke access for one leaver without locking out five colleagues. That is why shared accounts are prohibited in any system holding personal data: accountability, least privilege and revocation all depend on one account per person.
Why the address proves nothing. The From header is trivially forged, and even a genuine sender address can be reached by spoofing the display name, by a lookalike domain (school-edu.in versus school.edu.in), or by the principal's own mailbox being compromised. The channel is not authenticated to the reader. Two further signals were available and ignored: an unexpected .xlsm attachment, which is a document type that carries macros, and an urgency-and-secrecy instruction ("before 5 p.m.", salary) designed to prevent verification. The correct response is to verify out of band - phone the principal, or start a fresh message to the known address rather than replying - and never to click Enable Content on an unsolicited document.
Measures. Individual accounts, a long unique passphrase, multi-factor authentication on email and on the server, macro execution disabled by policy and blocked at the mail gateway, and short awareness sessions with staff that include reporting, not just spotting.
3. Judge the backup arrangement: weekly, on an external disk that stays plugged into the computer being backed up. Explain what this design has probably cost the school, and describe the arrangement you would put in place, including how you would know it works.
Read the worked answer
A backup that is permanently mounted on the machine it protects is not a backup, it is a second copy of the same failure. Ransomware enumerates mounted drives and network shares before it encrypts, so the external disk and the mapped server drive were almost certainly encrypted along with the local files. The school most likely holds three encrypted copies and no clean one, and its only remaining independent data may be the Friday copy if and only if it was physically disconnected before Monday.
Design: 3-2-1. Three copies of the result data, on two different media, with one copy off-site and offline. Practically: keep the server as the working copy, run scheduled backups to a network location the office account cannot write to (so the malware cannot reach it with the same credentials), and rotate two external disks that are plugged in only for the backup window and stored locked away otherwise. If affordable, add an immutable or cloud versioned copy, since versioning survives encryption of the live data. Reduce the interval from weekly to daily for result files - the deadline damage comes from losing a week, not from the encryption alone.
Access control. The backup job should run under a dedicated account with write-only access to the backup target; the office user must not be able to delete backups. That single change blunts most ransomware.
Proving it works. Perform a real restore into a scratch folder every term and open the files; a backup that has never been restored is a hope, not a control. Record the restore date, the file count and the size, and keep a printed restore procedure so the process does not depend on any one person. After this incident, inspect the Friday disk on an isolated machine before trusting it: check file dates and extensions, and restore only what predates Monday.