Social engineering has left the inbox

Voice phishing is the workhorse. The caller claims to be IT support, a vendor, a bank or an executive, and caller ID backs the story because it is trivially spoofed and carries no authentication at all. The modern version is rehearsed and well researched: names, role titles and current systems come from LinkedIn, company pages and old breach data, and voice cloning tools have made 'it sounded exactly like him' a weak defence. The ask is usually small. One credential, one approval or one reset is enough to start.

SMS lures work because the message lands on a device your controls do not manage. A text about a missed parcel, a payroll update or a suspicious sign-in carries a link that opens in a mobile browser, where the address bar is cramped and a lookalike domain reads fine at a glance. There is no gateway in the path, no link rewriting, and usually no visibility that the contact ever happened.

MFA fatigue attacks the approval instead of the credential. An attacker who already holds a password fires push prompts at the user's phone until one gets approved out of exhaustion or confusion, and the stronger version pairs the prompts with a call from 'IT' explaining that approving the prompt will make them stop. QR codes run the same off-channel trick from a different angle: a code on a poster, an invoice or an email rendered as an image moves the victim onto a personal phone, off your network and past every URL filter you own.

Helpdesk impersonation runs the con in the other direction. Instead of calling staff and pretending to be IT, the attacker calls IT and pretends to be staff. A plausible story, a few personal details harvested from public sources, some manufactured urgency, and the request lands: reset my password, re-enrol my MFA, I am locked out and my flight boards in twenty minutes. A service desk measured on speed and friendliness is being graded on exactly the qualities the attacker exploits.

The common thread is that every one of these paths avoids the inspected channel. Your mail security stack sits between the internet and the inbox, and a phone call, a text to a personal number, a scanned QR code and an inbound call to the service desk all route around it. Device management does not help when the lure completes on an unmanaged personal phone. Awareness training does not transfer automatically either, because staff trained to scrutinise email still extend a telephone caller a level of trust no written message would get. The phone feels synchronous and human, and urgency lands harder when a voice supplies it.

There is also an evidence gap. Email leaves an artefact that can be searched, blocked and reported on, while a phone call leaves no record unless the helpdesk logs it. Unless identity checks are written down and MFA method changes raise alerts that someone actually reads, the first evidence of a voice-based intrusion is often the intrusion itself.

The counter is mostly procedural, and it rests on one rule: identity gets verified through a channel the organisation controls. The channel a request arrived on proves nothing about who sent it. If a caller claims to be a staff member, the helpdesk ends the call and rings back on the number in the directory. If a text claims to be from the bank, the user opens the bank's app. If an executive emails or calls about an urgent transfer, payment details change only after confirmation through details already on file.

Culture is what makes the procedure survive pressure. Staff need explicit written permission from leadership to slow down or refuse a request from anyone, including an executive, until verification completes, and executives have to submit to the process visibly when it inconveniences them. The single most useful artefact most organisations can publish internally is a short statement of how IT will and will not contact staff: IT will never ask for your password, never request an MFA code, never ask you to approve a prompt on its behalf. Once that contract is published, any contact that breaches it is hostile by definition, and reporting it becomes a simple decision instead of a judgement call.

Password and MFA resets are the crown-jewel workflow, because a successful reset makes the attacker the legitimate user from that point on. These are the controls we most often find missing when we test the path:

An assessment built for the current threat goes well past a simulated email campaign. It tests whether an outsider armed with public information can talk their way to a password reset, whether staff approve an unexpected push prompt when a caller asks them to, whether a QR code in the right place gets scanned, and whether an SMS lure that names a real internal system gets a click. Just as importantly, it tests what happens next: whether anyone reports the contact, whether the report reaches the right team quickly, and whether the logs let a responder reconstruct the approach afterwards.

The findings worth paying for are about process. A test that ends with a list of who fell for the pretext has measured the wrong thing, because a well-built pretext lands on almost anyone eventually. The useful output identifies which verification step was missing or got skipped under pressure, which script the helpdesk needed and did not have, and which alert never fired. Designing pretexts that are realistic, ethical and safe, agreeing rules of engagement with legal and HR before anyone picks up a phone, and running each channel lawfully takes genuine care, and that design work is where an assessment stops being a checklist. We run these engagements as part of our offensive practice, across every channel described above.

Testing pays off once the basic contract exists, so build it first. Publish the statement of how IT contacts staff. Write the call-back rule into the helpdesk procedure and brief the team on it, including the right of refusal. Turn on number matching for push approvals and alerting for MFA method changes in your identity platform. None of this needs new products, and all of it changes what a caller can achieve this week.

Once those controls are in place, a test tells you whether they hold against a determined, well-researched pretext. Run it before that and it will only confirm what you already know.