The Vendor Bank-Change Email
A 42-employee ITeS firm in Guwahati pays overseas vendors by bank transfer. The accounts executive, M, receives an email from [email protected] asking to change the beneficiary account for an upcoming invoice of USD 18,400. The firm's real vendor uses vendorindia.co. The email has a PDF invoice and an .html attachment labelled 'payment_portal.html'. M replies with a scanned copy of the invoice, which shows the firm's GSTIN and bank details, and forwards it to finance. The finance manager notices the domain mismatch the next morning; no transfer has been made. Separately, the shared drive has a folder 'KYC_Scans' with three customers' passports and bank statements, readable by all 42 employees. The firm has no written incident-response plan. The CEO asks whether they should just delete the emails and warn staff.
1. List the first actions in the next two hours, in priority order, and explain why deleting the email is a bad first move.
Read the worked answer
Order: contain, preserve, verify, notify. First, isolate M's mailbox and endpoint from the network if there is any sign the .html was opened; reset M's password, revoke active sessions, and check for forwarding rules, mailbox delegation and sent items. Second, preserve evidence: export the message as .eml with full headers, save the attachment without opening it on a production machine, and record hashes and timestamps. Third, block the lookalike domain at the mail gateway and search for other recipients. Fourth, call the real vendor on a previously known number, not a number in the suspicious email, to verify the bank details; alert the bank if any transfer instruction was sent. Fifth, notify management and legal. Deleting the email destroys headers, the attachment and the audit trail needed to determine scope and to report the incident. It also does not undo the reply that already disclosed the invoice and bank details.
2. Draft the key points of a notification to the vendor and to affected customers, distinguishing confirmed facts from unknowns.
Read the worked answer
To the vendor: state that an email from a lookalike domain requested a bank change; confirm that M replied with an invoice containing the firm's GSTIN and bank details; state that no payment has been made; ask the vendor to verify its beneficiary details through a known contact and confirm whether its own account was compromised. Label unknowns clearly: we do not yet know whether the attachment was opened or whether other mailboxes were targeted. To affected customers, if KYC exposure is confirmed: state what data was in the folder (passport and bank statement), the period, the containment steps, and a single contact point; say what is not yet known rather than guessing. Do not name the employee or speculate about fault. Keep a written log of who was notified and when, and follow contractual and legal notification timelines.
3. Recommend controls for bank-detail changes and for the KYC_Scans folder. Prioritise by risk.
Read the worked answer
Prioritise the KYC folder first because passports and bank statements are high-harm identity documents. Remove the 'everyone' permission, apply least privilege by client team, encrypt the folder, enable auditing, set retention and deletion rules, and log access. Then fix bank-detail changes: a callback to a known number, dual approval, a vendor master change log, email authentication (SPF, DKIM, DMARC), and a payment hold on first-time beneficiary changes. The USD 18,400 invoice is a near miss, not the only risk; the same trick could target any vendor. Staff awareness is useful but insufficient alone. Test the controls with a simulated bank-change request, and review mailbox forwarding rules monthly. The ordering reflects harm and likelihood: identity data is already exposed to 42 people, while the payment fraud was stopped before funds moved.