A Worked Case: Analysing a Real Attack

Question 1: which levers?

• The routine, and this is the principal one. Paying a supplier's invoice is the clerk's job, and a notification of changed bank details is a thing suppliers genuinely send. Nothing about the request was unusual, so nothing triggered scrutiny.
• Authority, mildly: the supplier's accounts department is entitled to state its own bank details.
• Familiarity: a real supplier, a real invoice number, an established relationship.
• Notably not urgency. The absence is instructive: the attacker did not need pressure because the request was already normal, and urgency might have prompted a check.

Question 2: what reconnaissance? The attacker knew the supplier relationship existed, the invoice number, and the clerk's address. The most likely source is a compromised mailbox at either company, giving access to genuine correspondence, which also explains the accurate invoice number and matching tone. Alternatively, public tender or contract records plus the email format.

Question 3: which control failed? Precisely: there was no requirement to verify a change of banking details through an independently obtained channel. The company treated an emailed instruction as sufficient authority to change where money is sent. Secondarily, there was no out-of-band confirmation to the supplier that details had changed, and no alerting on a payment to newly changed details.

Question 4: the single control. A mandatory callback to a telephone number already held on file (not one supplied in the message) before any change to payment details takes effect. This defeats the attack completely and regardless of how convincing the email was, because the attacker does not control the number on file.

Question 5: what would have limited the damage? Detecting it sooner. An alert when a payment is made to bank details changed within the last thirty days would have surfaced it in days rather than three weeks, and funds recalled quickly are sometimes recoverable.

The lesson. The most costly social engineering is often the least dramatic. There was no malware, no link, no urgency and nothing for a filter to detect. A control that depends on someone feeling suspicious would not have worked, because there was nothing to feel suspicious about.

Case two: the help desk and the second factor

The narrative. An attacker has obtained an employee's password from an unrelated breach where the employee reused it. The corporate account requires a second factor, a code from an application on the employee's phone, so the password alone fails.

The attacker telephones the company's IT help desk, gives the employee's name and employee number, and says they have a new phone and cannot generate codes, and that they have a customer presentation in twenty minutes. The help desk agent, following a procedure that asks for name, employee number and date of birth, all of which the attacker has from public and breach sources, resets the second-factor enrolment. The attacker registers their own device and signs in.

Question 1: which levers?

• Urgency: the presentation in twenty minutes, compressing the agent's decision and making a thorough check feel obstructive.
• The routine: "I have a new phone" is among the commonest genuine help-desk requests.
• Authority, weakly, and liking: a colleague in difficulty, and the help desk exists to help.

Question 2: what reconnaissance? The employee's name and role (professional networking site), the employee-number format (possibly a photograph of a badge, or a document's metadata), the date of birth (social media), and the password (a third-party breach, exploited through reuse). Note how little of this came from the company's own systems.

Question 3: which control failed? Two, and both should be named. First, the help desk's identity verification relied on information that is not secret: name, employee number and date of birth are all discoverable, so the procedure verified knowledge of public facts rather than identity. Second, the second factor could be reset by a telephone call, which means the strength of the second factor was reduced to the strength of the help-desk procedure. A third, upstream: password reuse was possible because there was no check against known-breached credentials.

Question 4: the single control. A stronger identity-verification procedure for second-factor resets: verification through the employee's manager, a video call with an identity document, or a code sent to a pre-registered alternative channel. Most simply, the reset should not be completable in one telephone call by someone who knows only public facts.

Question 5: what would have limited the damage? Alerting on second-factor re-enrolment followed by a sign-in from a new device and an unfamiliar location, and requiring re-authentication for sensitive actions so that a session obtained this way could not immediately do the most damaging things.

The lesson, and it is the most transferable in this chapter: a control is only as strong as its recovery path. An organisation that deploys multi-factor authentication and leaves a telephone call as the reset route has moved the attack, not prevented it. Attackers always look for the recovery path, because it exists precisely to let someone in who cannot authenticate normally.

A worked example: the analysis as a reproducible table

For the examination, this is the shape to produce for any scenario given:

What beginners get wrong

• Ending the analysis at "the employee was careless". It is hindsight, it produces no fix, and in both cases above the employee was doing their job correctly under the procedures they had.
• Naming the technique and stopping. "This was phishing" is a classification, not an analysis. The four questions are the analysis.
• Recommending "more training" as the single control. Training lowers the rate and cannot be the answer where, as in case one, there was nothing to notice. Name a process gate or a technical control.
• Missing the recovery path. Case two is the standard shape: the control was sound and its reset route was not.
• Listing twenty recommendations equally. Ranking is the professional contribution. Name the one that would have stopped it.
• Forgetting the damage-limiting question. Prevention fails eventually; detection speed determines the loss.

Quick revision

• The method, four questions: which lever, what reconnaissance, which control failed, what single control would have stopped it; plus a fifth, what would have limited the damage.
• Case one, supplier payment fraud: the routine and familiarity, no urgency needed; likely a compromised mailbox supplied the invoice detail; no independent verification of banking changes; callback to a number already on file defeats it; alerting on recently changed payment details limits it.
• Case two, help-desk second-factor reset: urgency and the routine; public facts plus a reused breached password; verification by non-secret facts and a resettable second factor; stronger reset verification defeats it; alerting on re-enrolment plus new-device sign-in limits it.
• Two transferable lessons: the costliest attacks are often the least dramatic, and a control is only as strong as its recovery path.
• An analysis that ends in blame has not finished; it must end in a control.

Test yourself

1. State the four questions that constitute an analysis of a social-engineering incident.

Which psychological lever or levers were pulled; what reconnaissance made the approach plausible and where it came from; which control failed or was absent, stated precisely; and what single control would most likely have prevented it. A fifth question, what would have limited the damage, completes it.

1. In the supplier-payment case, why would awareness training have been an inadequate recommendation?

Because there was nothing for the clerk to notice: the request was routine, unhurried, referenced a genuine invoice number and came from a real supplier relationship, so no amount of alertness reliably distinguishes it. The effective control is procedural, a mandatory callback to a number already on file before payment details can change.

1. What general lesson does the help-desk case teach about multi-factor authentication?

That a control is only as strong as its recovery path. Deploying a second factor while permitting it to be reset on a single telephone call, verified against facts that are publicly discoverable, reduces the strength of the second factor to the strength of the help-desk procedure and relocates the attack rather than preventing it.

1. Why did the attacker in the supplier case deliberately not use urgency?

Because the request was already routine and therefore unlikely to be questioned, whereas urgency is itself a recognised warning sign and might have prompted the clerk to check. The absence of pressure made the message more, not less, convincing.

1. Why must an analysis end in a control rather than in a judgement about the person deceived?

Because the individual was performing their normal duties under the procedures provided, so attributing the failure to them yields no improvement and discourages reporting. Identifying the missing process gate or technical control produces a change that prevents recurrence regardless of who is at the desk.