The lookalike-domain payment request and the parking-lot pen drive

Red flags, and why each matters.

• Lookalike domain. .co against .com is a deliberate near-match; the display name is trivially forged and proves nothing.
• Urgency plus audit framing. 'Before audit' creates time pressure precisely to discourage verification.
• A PDF that must be 'enabled for editing'. That prompt usually means embedded scripts or a macro chain; a genuine invoice does not need editing rights to be read.
• A new payment destination and an unusual amount (₹4,80,000) with no purchase order reference.
• The timing. Friday after 4:40 p.m. is chosen so the manager is unreachable and the payment can clear before Monday.
• The phone call twenty minutes later. A coordinated second channel - the 'bank' asking for an OTP is the classic final step to complete a transfer or take over an account. No bank asks for an OTP.

Actions, in order.

1. Do not reply, do not open the attachment, do not forward it to colleagues to 'check'.
2. Preserve it: note sender address, full headers, time, and the caller's number and time of call. Screenshot before anything is deleted.
3. Verify through a channel you chose, not one the email supplied: call the finance director on the number in the internal directory or the staff app. Do not use any number given in the email.
4. Tell the receptionist and the front desk immediately that no call about OTPs or payments is to be transferred, and brief whoever is on the desk.
5. Escalate. If the manager is unreachable, the alternate approver or the IT/security contact must be in the firm's incident list; document the attempts with timestamps. A firm of 40 seats that has no after-hours escalation path has a control gap to fix on Monday.
6. Report the email to IT so the sender is blocked and the mail gateway is searched for other recipients - finance and HR are usually targeted in the same wave.
7. If Rohit already entered credentials on any page, or shared a code, he must call the bank's published number, ask for the account and card to be frozen, and change his password from a different device.

Handle it as a security incident, not a curiosity.

1. Treat the front-desk PC as potentially compromised the moment the drive was inserted. Unplug the network cable and disable Wi-Fi on that machine - isolation stops any payload from reaching the file share or the claims system.
2. Do not simply run a quick scan and declare it clean. Malicious drives can act as a keyboard (firmware-level attacks), can exploit autorun or shortcut files, and can plant a dropper that a single scan misses. The safe path for a small firm is to image or reinstall the machine from a known-good build, and to scan the drive only on an isolated machine that is not on the network.
3. Log the incident: who found it, where, when, who plugged it in, which machine, what was opened. Preserve the drive for the IT contact rather than returning it to the owner.
4. Brief the front desk and the trainee without blaming: found media is handed to IT and never inserted, full stop. The trainee's mistake is exactly what an untrained person does, which is the point.

What it reveals.

• There is no removable-media rule, and no technical control either: USB mass storage should be disabled by policy on front-desk and accounts machines, or at least blocked for standard users.
• There is no after-hours escalation path, shown by the manager being unreachable during an active social-engineering attempt.
• Staff are untrained in two basics that would have stopped both incidents: verify payment changes by callback, and never insert found media. The trainee and the email target failed on the same missing skill - the assumption that something which looks routine is safe.
• Physical security at the parking area lets an attacker place a device on site; a labelled drop box and a one-line notice at reception cost nothing.

Recommend fixing the technical controls (mail authentication and external-sender banner, USB blocking, endpoint protection) and the human ones together; either alone leaves the same gap open.

Keep the register to one line per incident and six columns, filled in during the incident, not after it:

• Date and time detected
• What happened, in one sentence
• Channel (email, phone, removable media, web)
• Who reported it and to whom it was escalated
• Immediate action taken (blocked sender, machine isolated, account frozen)
• Outcome and the one control changed as a result

Why this stays useful.

1. It is closed only when a control changes. An incident line with no control change stays open and visible. That converts the register from a diary into a work queue. An entry such as 'lookalike domain, sender blocked' stays open until the mail gateway has SPF, DKIM and DMARC checked and an external-sender banner enabled.
2. It is reviewed monthly for patterns, not for blame. Four entries on the same channel in a quarter is a signal about a control, not about individuals. Counts by channel are the only metrics worth reporting to management.
3. It is short enough to complete during the event. If a line takes more than three minutes, people fill it in from memory a week later and the detail is worthless.
4. It has a named owner and a review date. Without an owner the register becomes a list of stories; with one, the review becomes a ten-minute standing agenda item.
5. It is linked to the training calendar. Every closed incident becomes a two-line item in the next awareness briefing, using the firm's own example rather than a generic poster.

For a 40-seat firm this should be a shared sheet with restricted edit rights, not a formal system; the value is in the discipline of closing the loop, not in the tool.