Billing Clerk Phishing: Containment, Ransom and Recovery Decisions
On Monday at 10:40 a.m., a billing clerk at a stationery distributor received an email that looked as if it came from the transport contractor: 'Invoice copy shared - View Document'. The link opened a page resembling the company's webmail login, and she typed her email address and password. By 11:15 a.m. more than 40 customers had received mail from her account giving revised bank account details for payments. At 11:30 a.m. files in the server's shared folder began to change: payroll.xlsx became payroll.xlsx.lock, and a text file demanded payment in Bitcoin. The office has 12 PCs, one server, an always-on broadband router, and an external backup disk that is connected to the server permanently. The proprietor's son, a first-year IT student, wants to switch off and format the server immediately, then pay the ransom because 'the data is worth more'.
1. Set out the response steps for the first two hours in the order you would take them, justifying the sequence and stating what you would deliberately not do.
Read the worked answer
Order matters: stop the spread, stop the fraud, preserve evidence, then recover.
- Isolate, do not destroy. Unplug the network cable and disable Wi-Fi on the clerk's PC; disconnect the server's LAN cable but leave it powered on, because pulling the plug destroys volatile evidence (running processes, encryption keys, network connections). Turn off the router's Wi-Fi or unplug its WAN link to stop further fraudulent mail leaving.
- Stop the money loss. Telephone the bank to flag the altered account details and ask for a recall/hold on any transfers; email and phone the 40 customers from a clean device and a known number telling them to ignore the revised bank details. This is time-critical and outranks forensics, because payments in transit can still be stopped.
- Secure the mailbox. From a clean device change the password, revoke all active sessions, enable two-factor authentication, and check for attacker-created forwarding rules, auto-replies, delegation and mailbox rules - these are what let the attacker keep reading invoices after a password reset.
- Preserve, then clean. Photograph error screens, export mail and server event logs, note the ransom file name and address. Only then remove infected machines from the network and rebuild them.
- Report. File a complaint at cybercrime.gov.in or call 1930, inform the local police/CERT-In, and record the incident.
Deliberately not done: no immediate format (it destroys evidence and the option of recovery), no payment, and no attempt to 'clean' the server by deleting the .lock files.
2. Evaluate the son's two proposals: format the server at once, and pay the ransom. Include what the permanently attached backup disk means for recovery.
Read the worked answer
Format at once: reject. It destroys the logs and artefacts needed for the police complaint, the insurance claim and the root-cause analysis, and it destroys any chance of recovering data without paying. Formatting is the last step, after evidence is captured and a clean backup is verified.
Pay the ransom: reject. There is no guarantee of a working key; ransomware families are routinely badly coded, and payment often triggers a second demand (double extortion: data copied out before encryption and threatened with publication). Paying funds criminal groups and marks the firm as a payer likely to be attacked again. It may also raise legal and insurance problems.
The backup is the real problem. The external disk is permanently connected to the server, so encrypted network shares and mapped drives are usually encrypted too - the backup may already be encrypted. Check it on the disconnected machine before relying on it, and never reconnect it to an infected server.
Recovery path. Rebuild the server from known-clean media, restore only from a backup verified as clean, and accept loss of anything after the last good backup. If no clean backup exists, reconstruct from invoices, bank statements and paper records, and only then consider the ransom as a business decision taken with police advice - not as a reflex.
3. Identify the security failures that allowed this incident, then choose the first three fixes for a small budget and justify the priority order.
Read the worked answer
Failures in the chain.
- Phishing-susceptible staff with no recent training and a look-alike login page that was accepted at face value.
- No two-factor authentication on email, so one password gave full mailbox access.
- No mail authentication/ filtering discipline, letting a spoofed sender reach the inbox.
- A flat network: the billing clerk could reach payroll, so the infection reached files unrelated to billing.
- Always-connected backup disk, which converts one infection into total loss.
- A single account with broad rights (also the cause of the earlier deletion problem).
First three fixes, in priority order.
- Two-factor authentication on email and remote access - free or nearly free; it directly defeats the stolen password that started everything, and the loss per rupee is the best in the list.
- Offline/off-site backup on the 3-2-1 rule (3 copies, 2 media, 1 offline or off-site, with versioning and a quarterly test restore). Without this, no other control can save the business; with it, ransomware becomes an inconvenience instead of an extinction event.
- Least privilege and network separation - billing staff lose write access to payroll, and finance files sit on a separate share; this limits blast radius even after a mistake.
Training, mail authentication (SPF/DKIM/DMARC) and endpoint protection follow next; they are valuable but they reduce probability, whereas 2FA and a disconnected backup reduce the impact of the mistake that will still happen.