Pretexting Guide: Invented Scenarios, Impersonation and Verification Controls

Pretexting is a social engineering technique in which an attacker invents a believable scenario, the pretext, and plays a role inside it to persuade someone to hand over information, access or money. The pretext supplies the reason the request seems normal: a new IT engineer fixing an account, an executive travelling without a laptop, a supplier with new bank details, an auditor who needs a list of administrators. Pretexting is the engine behind most help desk password and MFA reset attacks, which have led to some of the most costly incidents of recent years. This guide explains what pretexting is, how it works, why it matters, which misconceptions weaken defences, and which verification controls and staff scripts stop it. It is written for service desk leads, finance and HR managers, identity teams and awareness owners. It is defensive throughout and contains no material usable to run an attack.

Key takeaways

• A pretext is a story plus a role. The attacker researches the organisation, then plays a character with a plausible reason to ask for something a real colleague might ask for.
• The help desk is the prime target. A password or MFA reset granted to an impostor turns a phone call into valid credentials, as the MGM Resorts, Co-op and Marks and Spencer incidents show.
• Knowledge questions do not verify identity. Names, employee numbers, managers and office locations are often public or leaked, so verification must rely on something an impostor cannot know or hold.
• Scripts protect staff. A fixed verification procedure with explicit permission to refuse and call back removes the social pressure that pretexting depends on.
• Some pretexting is illegal in its own right. In the US, the Gramm-Leach-Bliley Act prohibits obtaining customer information of a financial institution by false pretences.

What it is

MITRE CAPEC catalogues pretexting as CAPEC-407, a child of CAPEC-416 Manipulate Human Behavior, and closely related to CAPEC-410 Information Elicitation. Unlike a mass phishing email, a pretext is usually targeted and interactive: the attacker adapts in real time to the target's answers, often over the phone or chat. Pretexting can be the whole attack (extracting customer records) or one stage of a larger intrusion (getting an MFA reset, then using the account).

Pretexting is distinct from, but feeds into, other forms of social engineering. Vishing is pretexting over voice; business email compromise is often pretexting by email; a deepfake is a pretext with synthetic voice or video. See the Social Engineering Guide for the wider map.

Typical pretexts

How it works

A pretexting operation typically moves through five stages. Understanding them tells defenders where to interrupt.

1. Reconnaissance. The attacker gathers names, roles, reporting lines, suppliers, tools and jargon from professional networking sites, company websites, breach data and earlier calls (ATT&CK T1589 Gather Victim Identity Information, T1591 Gather Victim Org Information). In the MGM Resorts case, the attackers said they found an employee on LinkedIn before calling the help desk.
2. Preparation. Accounts, phone numbers or lookalike domains are set up so the role looks real (T1585 Establish Accounts). Caller ID can be spoofed, so a familiar number proves nothing.
3. Approach. The attacker opens with the pretext and builds rapport, often using internal terminology to sound like an insider. Information-gathering calls (T1598 Phishing for Information, including T1598.004 Spearphishing Voice) may come first, collecting small details that make the later call convincing.
4. The ask. The attacker requests the action: reset, code, payment, data. Pressure levers such as urgency, authority and sympathy are applied here.
5. Exploitation. Whatever was obtained is used immediately, often within minutes: signing in with reset credentials (T1078 Valid Accounts), registering a new MFA device (T1098.005 Device Registration), or moving money.

Help desk password and MFA reset abuse

CISA's advisory AA23-320A on Scattered Spider describes actors using social engineering to convince help desk staff to reset passwords and MFA tokens, posing as IT staff to obtain one-time codes from employees, and persuading carriers to move phone numbers to attacker-controlled SIM cards. The pattern repeated in UK retail in 2025.

• MGM Resorts, September 2023: according to the attackers' own account, an employee identified on LinkedIn was impersonated in a call to the IT help desk. The intrusion disrupted casinos, room keys and reservations for about ten days, and MGM estimated about $100 million of impact. See the MGM Resorts breach.
• Co-op, April 2025: attackers reportedly posed as staff to get an employee's password reset through the help desk, then targeted Active Directory credentials; data on 6.5 million members was taken. See the Co-op cyber attack.
• Marks and Spencer, April 2025: M&S said attackers impersonated a third-party user, and reporting links the route to an outsourced help desk; M&S estimated a £300 million profit impact. See the Marks and Spencer cyberattack.

Why it matters

Pretexting bypasses technical controls by recruiting an authorised person to act on the attacker's behalf. When the target is a help desk agent with reset rights, one successful call can be worth more than any exploit. Three trends make it more dangerous:

• AI-generated voice: in alert I-051525-PSA (May 2025), the FBI warned of a campaign since April 2025 impersonating senior US officials with texts and AI-generated voice messages, and advised verifying by independently finding the person's number and calling back. See the Deepfake and AI Impersonation Guide.
• Weak recovery factors: NIST SP 800-63B-4 states that passwords, one-time passwords and out-of-band methods are not phishing-resistant, and treats changing a registered phone number as binding a new authenticator. A reset process that issues one of these to a caller hands over a working credential.
• Financial loss at scale: the FBI IC3 2024 report recorded 21,442 business email compromise complaints with $2,770,151,146 in reported losses, and 36,002 tech support complaints with $1,464,755,976 in losses, both categories driven largely by impersonation.

Verification controls

Decision guidance: use self-service phishing-resistant recovery as the default route, a callback plus manager confirmation for standard users who have lost every factor, and video or in-person proofing plus a second approver for administrators, executives and anyone with identity provider rights. Smaller organisations without video tooling can rely on callback plus manager confirmation and simply refuse remote resets for administrators. Outsourced desks must apply the same tiers. See the Account Recovery and Help Desk Security Guide and the Deepfake-Resistant Identity Verification Guide.

Scripts for staff

Short, fixed wording gives staff a reason to refuse that does not depend on suspecting the caller. These are defensive scripts for people receiving requests.

• Help desk, any reset: "For your security I can't reset this on an inbound call. I'll end the call now and ring you back on the number in the directory, and I'll need your manager to confirm in the ticket."
• Help desk, privileged account: "Administrator resets need a video or in-person check and a second approver. I'll raise the request and the identity team will contact you."
• Any employee, unsolicited IT call: "I don't share codes or approve prompts I didn't start. I'll raise a ticket through the portal if there's a problem."
• Finance, bank detail change: "We only change payment details after calling the number we already hold for you. Until then, payments go to the existing account."
• Anyone, executive request outside process: "I'll confirm with you on your usual number before I act. If it's urgent, that's the quickest way."

Pair the scripts with a rule that no one is criticised for following them, even when the caller turns out to be a real executive.

Implementing the controls

1. Inventory reset and change paths: list every way a password, MFA method, phone number, payment detail or access grant can be changed, including outsourced desks and chat channels.
2. Define verification tiers by account risk, as in the table above, and write them as a one-page procedure.
3. Pilot with one desk team for two to four weeks, measuring handling time and failed verifications. Keep an exception route, approved by a security manager and logged, so legitimate users are not stranded; if the pilot shows unacceptable lockouts, roll back to the previous procedure for that user group while you fix the gap.
4. Configure the identity platform so reset events, MFA method changes and new device registrations raise alerts, and so administrators cannot be reset by first-line agents.
5. Train and test with role-play scenarios and authorised vishing tests of the desk, including outsourced providers. See the Social Engineering and Physical Penetration Testing Guide.

Detection and measurement

• Signals: reset followed within minutes by sign-in from a new device or country; MFA method changes on privileged accounts; repeated calls about the same user; callers who fail verification; supplier bank detail changes.
• Metrics: percentage of resets that passed the full tiered procedure (audited sample, target 100% for privileged); number of failed or abandoned verifications reported to security; time from suspicious call to SOC triage; share of users enrolled in self-service phishing-resistant recovery; payment changes verified by callback (target 100%).

Common misconceptions

• "Our staff would spot a fake." Pretexters use real names, internal jargon and genuine-sounding problems. The MGM, Co-op and Marks and Spencer callers were convincing enough for trained desks.
• "Caller ID or a familiar voice proves identity." Numbers can be spoofed and voices cloned; the FBI's 2025 alert specifically names AI-generated voice.
• "Knowing the employee number is verification." It is a fact, not proof of identity, and often available to attackers.
• "MFA solves it." Phishable MFA can be reset or talked out of a user; only phishing-resistant factors combined with strong recovery remove the path.
• "It is an awareness problem." Training helps, but the decisive control is a procedure that does not rely on the agent judging the caller's honesty.
• "Suppliers are their own risk." An outsourced desk that resets your accounts is part of your control set and must be held to it.

Related concepts

Framework mapping

Practitioner checklist

• Map every reset and change path, including outsourced desks and chat.
• Remove knowledge questions as a sole verification method.
• Adopt tiered verification, with video or in-person proofing and a second approver for privileged accounts.
• Make self-service recovery with a phishing-resistant authenticator the default.
• Issue staff fixed refusal and callback scripts, and back anyone who uses them.
• Alert on resets and MFA changes followed by new-device or privileged activity.
• Require callbacks to held numbers for supplier bank detail changes.
• Test the desk and suppliers with authorised pretexting exercises at least annually.

Standards and references

• MITRE CAPEC: Pretexting
• CISA: Scattered Spider (AA23-320A)
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• FTC: Gramm-Leach-Bliley Act
• FBI IC3: Public Service Announcement I-051525-PSA on impersonation of senior US officials
• FBI IC3: Internet Crime Report 2024
• NCSC: Phishing attacks, defending your organisation
• MITRE ATT&CK: Phishing for Information, Spearphishing Voice

Related NHI Mgmt Group resources: Social Engineering Guide · Account Recovery and Help Desk Security Guide · Phishing-Resistant MFA Guide · Scattered Spider Threat Actor Profile