Social engineering, and the attacks that go around every control you set

Why this matters

Every control in this domain assumes the attacker has to defeat a machine. Social engineering does not bother: it asks a person to open the door, and the person does, because the request looked ordinary.

This is the largest single category of successful attack, and the exam gives it real weight. It also puts a support technician in an unusual position, because you are both a target — you have elevated access and a culture of being helpful — and the person users come to afterwards. Being able to recognise the techniques, and being able to handle the conversation after someone has fallen for one, are both part of the job.

The lesson

Phishing, spear phishing, vishing and smishing, told apart by their channel

The techniques are the same; the channel changes, and so does the name.

• Phishing — by email, sent broadly. Generic, high volume, and still effective because the volume is enormous.
• Spear phishing — targeted at a specific person or small group, using details about them. The details come from social media, company websites, and previous breaches. A spear phishing message is often indistinguishable from legitimate correspondence because it references real projects and real colleagues.
• Whaling — spear phishing aimed at senior people, usually attempting a payment or a credential.
• Vishing — by voice call. The technical support scam, the bank fraud department, the tax office. Voice adds pressure and removes the time to think that email allows.
• Smishing — by text message. Delivery notifications, bank alerts, one-time-code requests. Short messages carry fewer of the signals people use to judge email.

Two more worth naming: business email compromise, where a real mailbox has been taken over and the message genuinely comes from a colleague, which defeats almost every "check the sender" heuristic; and quishing, where the payload is a QR code, which hides the destination entirely and is increasingly used on printed material in public places.

For the exam, the discriminator between these is nearly always the channel and the targeting. For real life, the discriminator that matters is whether the message is asking you to do something.

Pretexting, tailgating, shoulder surfing and dumpster diving in a real office

In-person techniques are older, simpler, and still work.

Pretexting is the invented reason that makes the request ordinary. "I'm from the lift maintenance company", "I'm the new starter in finance and IT hasn't set me up yet", "I'm calling from your supplier about an invoice". The pretext is the whole attack; everything else follows naturally from it.

Tailgating is following someone through a controlled door. It works because challenging a stranger is socially expensive and because carrying a large box makes people hold doors open.

Shoulder surfing is reading a screen or a keyboard over someone's shoulder — at a desk, on a train, at a cash machine. Privacy filters and screen position are the controls, and awareness is most of it.

Dumpster diving is going through the rubbish. Organisations discard printouts, notes, old hardware, and whole filing cabinets, and there is no technical control between any of it and the street. Shredding, secure disposal bins, and treating disposal as a security process are the answers, and they belong to the operational procedures domain.

The pattern connecting all four: none of them attacks technology, so none of them is stopped by technology. The controls are physical, procedural and cultural — which is why an organisation's willingness to let staff challenge a stranger is a security control in the literal sense.

The signals that give a message away, and the ones that no longer do

The advice people were given ten years ago has aged badly, and repeating it makes users worse at this rather than better.

Signals that no longer work:

• Spelling and grammar. Messages are well written now. Poor English was never a reliable signal and is a positively misleading one today.
• "Look for the padlock." Almost every site has a certificate, including hostile ones. The padlock means the connection is encrypted, not that the site is honest.
• The display name. Trivially set to anything.
• "It came from someone I know." With a compromised mailbox, it did.

Signals that still work:

• The request itself. Does this message want a credential, a payment, a code, or software installed? Those four cover the overwhelming majority.
• A link whose destination does not match its text. Hover and read the actual address, paying attention to the domain immediately before the first single slash — that is the real site, and everything before it can be made to say anything.
• Unexpected urgency, especially with a consequence attached.
• A change of payment details, which is business email compromise in one line and should always be verified by a separate channel.
• Being asked to bypass a normal process, which is the point of the pretext.
• An authentication prompt you did not trigger. A code arriving unasked, or a push notification you did not initiate, means someone already has your password.

The reframe worth teaching users: stop trying to spot the fake, and start noticing what is being asked of you.

Why urgency and authority are the two levers, and how to answer both

Almost every one of these attacks runs on two levers, and naming them gives a user something to hold on to.

Urgency removes deliberation. "Your account will be closed today." "The payment must go out before the bank closes." "We are on a call with the client right now." The point is to prevent the pause in which someone would check.

Authority removes challenge. A message from the chief executive, a caller from IT, a badge and a clipboard, a letter from a regulator. The point is to make checking feel insubordinate.

The answer to both is the same, and it is one sentence: verify through a channel you chose. Not the phone number in the email; the number on the company's own website or on the back of the card. Not a reply to the message; a new message to a known address. Not the link; the site you type yourself.

That single habit defeats the entire category, and it is worth teaching as a habit rather than as a rule, because rules do not survive pressure.

The organisational half matters too, and a technician can advocate for it: a culture where it is acceptable to slow down and check is the actual control. If checking a payment change with the finance director is career- limiting, nobody will check, and every policy above it is decoration. The same applies to challenging a stranger in a corridor. Users do not fail at this because they are careless; they fail because the environment made compliance the expensive option.

What to tell a user who has already clicked, in the order it helps

Somebody will click. The response to that conversation decides how much damage follows, and it starts with not making the person feel stupid — because if they feel stupid, the next one will not tell you at all, and the delay is the thing that costs money.

The order that helps:

1. "Thank you for telling me." Say it first and mean it. Speed of reporting is the single most valuable factor in the outcome.
2. What exactly did you do? Did you enter credentials? On which site? Did you approve a prompt? Did you run or install anything? Did you pay something? The answers determine everything after.
3. If credentials were entered: change that password now, from a different device, and change it anywhere it was reused. Then sign out all sessions, then check the second factor enrolments, recovery addresses, and mail forwarding rules. Those survive a password change, which is why they come next rather than later.
4. If something was run or installed: disconnect the machine from the network and stop using it. The removal procedure in this domain takes over.
5. If money moved: contact the bank immediately, because the window for recall is measured in hours.
6. Report it internally, by whatever route exists. This is not a formality: a message that reached one person reached others.
7. Then, and only then, talk about how to recognise it next time.

The thing not to do is any version of "you should have known". It is untrue — these attacks are good — and it trains the user to hide the next one.