Social Engineering Guide: How Manipulation Attacks Work and How to Resist Them

Social engineering is the manipulation of people into doing something that helps an attacker, such as revealing a password, approving a payment, resetting an MFA device or holding a door open. It exploits trust, habit and process gaps rather than software flaws, which is why it sits at the start of so many ransomware, fraud and data theft incidents. This guide is the umbrella page for the NHI Mgmt Group social engineering series: it explains the principles of influence attackers rely on, summarises each main form and links the deeper guide for it, and sets out the organisational controls and awareness work that reduce the risk. It is written for security leaders, identity teams, service desk managers and awareness owners who need one map of the whole field.

Key takeaways

• The target is a decision, not a device. Every form of social engineering aims to get a person to take one action: click, share, approve, reset, pay or let someone in. Controls work best when they are attached to those actions.
• Process beats vigilance. Verification procedures, out-of-band callbacks and dual approval stop attacks that convincing pretexts, AI voices and deepfakes get past a well-trained person.
• The help desk is now a primary attack surface. MGM Resorts, Co-op and Marks and Spencer all show that a password or MFA reset granted over the phone can lead to tenant-wide compromise.
• Phishing-resistant MFA removes whole attack classes. FIDO2/WebAuthn and PKI authenticators stop credential and one-time code theft, MFA fatigue and most adversary-in-the-middle phishing, though not payment fraud or physical intrusion.
• Measure reporting, not only clicks. A culture where people report quickly and without blame shortens dwell time more than a falling simulation click rate does.

How social engineering works: the principles of influence

Attackers rarely invent new psychology. They reuse a small set of persuasion levers, usually combined, to push a target into fast, automatic decisions instead of careful ones. The well-known set of influence principles from persuasion research maps neatly onto attack patterns.

Most attacks follow the same lifecycle: reconnaissance on people and processes (ATT&CK T1589 Gather Victim Identity Information and T1591 Gather Victim Org Information, often from LinkedIn and company websites), preparation of accounts, domains or numbers (T1585 Establish Accounts), the approach and pretext, the ask, and then exploitation of whatever was obtained. Disrupting any stage helps, but the ask is where organisational controls are cheapest to apply.

The main forms of social engineering

The forms differ by channel and by what the attacker wants, and each has its own deeper guide in this series. The table summarises them; the notes below say where each guide goes further.

• Phishing: still the largest volume form. The FBI IC3 2024 report recorded 193,407 phishing and spoofing complaints. See the Phishing Guide, the AiTM Phishing Guide, the Device Code Phishing Guide, the Consent Phishing and Illicit OAuth Grants Guide and the Top 10 Phishing Techniques.
• Vishing and smishing: voice and text attacks that often combine, a text to set up a call or a call to "confirm" a code. In May 2025 the FBI warned (alert I-051525-PSA) of a campaign since April 2025 impersonating senior US officials with texts and AI-generated voice messages. See the Vishing and Smishing Guide.
• Quishing: QR codes move the victim from a protected laptop to a personal phone where URL filtering and browser protections may be absent. See the QR Code Phishing (Quishing) Guide.
• Callback phishing: a fake invoice or subscription notice contains no link, only a phone number; the "agent" talks the victim into installing remote support software. See the Callback Phishing (TOAD) Guide.
• Pretexting: the invented scenario that underpins most of the other forms, such as the IT engineer, the executive, the supplier or the auditor. See the Pretexting Guide.
• Help desk social engineering: the caller impersonates an employee to get a password reset, MFA re-enrolment or new device registered. See the Account Recovery and Help Desk Security Guide.
• Business email compromise: the IC3 2024 report recorded 21,442 BEC complaints with reported losses of $2,770,151,146. See the Email Identity and BEC Guide and the Business Email Compromise Response Playbook.
• Deepfakes: synthetic voice and video remove the "I recognised their voice" safeguard. See the Deepfake and AI Impersonation Guide, the Executive Deepfake and CEO Fraud Guide and the Deepfake-Resistant Identity Verification Guide.
• Baiting and USB drops: curiosity or greed lures, from "free" downloads to infected media left in car parks. See the Baiting Attacks Guide and the USB Drop Attacks Guide.
• Tailgating: following an authorised person through a controlled door, often helped by politeness or a carried box. See the Tailgating and Piggybacking Guide.

Why the help desk and identity layer matter most

The highest-impact social engineering of recent years has targeted identity processes rather than individual inboxes. CISA's advisory AA23-320A on Scattered Spider describes actors posing as IT or help desk staff to obtain credentials, convincing help desks to reset passwords and MFA tokens, persuading employees to share one-time codes or install remote access tools, sending repeated MFA prompts, and SIM swapping phone numbers. See the Scattered Spider Threat Actor Profile.

• Reset equals authentication: a password or MFA reset is the moment an identity is re-bound to new credentials. NIST SP 800-63B-4 treats changing a registered phone number as binding a new authenticator, so it deserves the same assurance as the original enrolment.
• Weak factors fail under pressure: NIST SP 800-63B-4 states that passwords, look-up secrets, out-of-band methods and one-time passwords are not phishing-resistant. Anything a person can read out can be talked out of them.
• Admin accounts multiply the damage: a reset on an identity provider administrator turns one phone call into control of every connected application. See the MFA Fatigue and Bypass Guide.
• Machine identities are the next hop: once inside, attackers look for tokens, API keys and service accounts that do not need a human at all, which is why post-incident clean-up must cover non-human identities as well as people.

Organisational controls

The controls below are ordered by how much risk they remove per unit of effort in most organisations. They are deliberately procedural: they hold even when the pretext is perfect.

Decision guidance

• Small organisations: start with phishing-resistant MFA on email and the identity provider, a written callback rule for payments and resets, and a simple reporting address. Outsourced IT support must follow the same verification rules; put it in the contract.
• Large organisations: tier help desk verification by risk (standard user, privileged user, executive), monitor resets centrally, and test outsourced service desks as rigorously as internal ones. The Marks and Spencer incident shows why supplier help desks are in scope.
• Self-service versus agent-assisted recovery: self-service recovery bound to a phishing-resistant authenticator removes the human from the attack path; agent-assisted recovery is still needed for lost devices, so make it slower and stronger, not faster.
• Code words versus callbacks: shared code words help for small executive groups and families, as the FBI suggests, but leak over time. Callbacks to directory numbers scale better and should be the default.

Awareness programmes that change behaviour

Training is one layer, not the whole defence. The UK NCSC phishing guidance makes the point directly: make verification of sensitive requests simple, make reporting easy, give feedback, and avoid blame, because punishing people discourages reporting. CISA's public guidance now notes that good grammar no longer proves a message is genuine, since AI can produce flawless text, so awareness content has to move from spotting typos to checking the request itself.

• Teach the action, not the lure: "never read out a code", "always call back on the directory number", "no exceptions for urgency" are durable rules that work across channels.
• Role-based content: finance, help desk, executive assistants, HR and receptionists face different pretexts and need scenario training for their own processes.
• Simulations with care: phishing and vishing simulations are useful for measuring reporting and for practising procedures, not for catching people out. See the Phishing Simulation Programme Guide.
• Programme structure: see the Security Awareness and Human Risk Management Guide, the Security Awareness Maturity Model and the Security Awareness Plan Template.
• Authorised testing: controlled social engineering and physical tests check whether procedures hold in practice. See the Social Engineering and Physical Penetration Testing Guide.

Implementing a social engineering defence programme

1. Map the sensitive actions. List every action a person can take that an attacker would want: credential and MFA resets, device registration, payment and bank detail changes, access grants, data exports, door access. Name the owner of each.
2. Write the verification rule for each action. Decide what proof is required and which channel confirms it. Keep rules short enough to fit on one card at the help desk or in finance.
3. Close the easiest paths first. Enforce phishing-resistant MFA for administrators and the identity provider, block unapproved remote access tools, and require callbacks for payment changes.
4. Pilot with one team. Run the new help desk verification flow with a pilot group for two to four weeks, track call handling time and failed verifications, and adjust before rolling out. Keep the previous process documented so you can roll back for a specific user group if the new flow blocks legitimate recovery, with a security manager approving each exception.
5. Instrument and alert. Send reset, MFA change and new device events from the identity provider to the SIEM and alert on risky combinations (see below).
6. Train against the new rules. Update awareness content and role-based scenarios so people practise the procedure, then test it with authorised simulations.
7. Extend to suppliers. Add verification requirements to outsourced help desk and finance contracts and test them.

Detection and measurement

• Identity events: password resets, MFA method changes and new device registrations (ATT&CK T1098.005), especially when followed within minutes by sign-in from a new location or privileged activity.
• MFA anomalies: bursts of push requests (T1621 Multi-Factor Authentication Request Generation) and changes to MFA policy (T1556.006).
• Help desk records: calls requesting resets for privileged accounts, repeated calls about the same user, callers who cannot pass verification.
• Endpoint signals: execution of remote access tools not on the allowlist, often the first sign of callback phishing.
• Finance signals: supplier bank detail changes and first-time payees above threshold.

Common failure patterns

• Verification that public data can satisfy: name, employee number and manager's name are often found on LinkedIn or in leaked data. In the MGM Resorts breach, the attackers said they found an employee on LinkedIn and then called the IT help desk; MGM estimated about $100 million of impact.
• Outsourced help desks outside the control set: the Marks and Spencer cyberattack began with impersonation of a third-party user, with reporting linking the route to an outsourced help desk.
• Resets without alerting: in the Co-op cyber attack, attackers reportedly obtained a password reset by posing as staff, then went after Active Directory credentials.
• Phishable MFA left as a fallback: organisations deploy passkeys but keep SMS or push as a recovery option, so attackers simply ask for the weaker one. In the Uber breach repeated push prompts wore down a contractor, and in the Cisco breach voice phishing and repeated pushes got an employee to approve VPN access.
• Trusting the voice or face: the Arup deepfake fraud shows a video call is not proof of identity for a payment: a finance worker made 15 transfers totalling HK$200 million after a call with deepfaked colleagues.
• Blame-driven awareness: naming and shaming simulation clickers teaches people to stay quiet after a mistake, which is the opposite of what the SOC needs.

Framework mapping

Practitioner checklist

• List every sensitive action (resets, device registration, payment changes, access grants) and write a one-card verification rule for each.
• Require phishing-resistant MFA for all administrators and identity provider roles, and remove phishable fallbacks.
• Make help desk verification independent of public data, with a stricter tier for privileged users and executives.
• Require callbacks to directory or supplier master numbers for payment and credential changes, never numbers in the request.
• Block unapproved remote access tools with application control.
• Alert on resets and MFA changes followed by new-device or privileged activity.
• Give staff a fast, blame-free reporting route for email, phone and SMS attempts, and send feedback.
• Run role-based training and authorised simulations that practise the procedure, and measure report rates.
• Put the same verification requirements and testing rights into outsourced help desk and finance contracts.

Standards and references

• CISA: Scattered Spider (AA23-320A)
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NCSC: Phishing attacks, defending your organisation
• CISA: Recognize and Report Phishing
• FBI IC3: Public Service Announcement I-051525-PSA on impersonation of senior US officials
• FBI IC3: Internet Crime Report 2024
• MITRE CAPEC: Manipulate Human Behavior
• MITRE ATT&CK: Phishing

Related NHI Mgmt Group resources: Pretexting Guide · Account Recovery and Help Desk Security Guide · Phishing-Resistant MFA Guide · Security Awareness and Human Risk Management Guide