social-engineering

Social engineering in the research: why people remain the gap, and what actually works

A summary of social engineering research: the psychological principles behind it, phishing and USB drop experiments, large-scale phishing training studies, real cases from Twitter to the Arup deepfake, and technical defenses that don't depend on human vigilance.

9 min read

  • social-engineering
  • phishing
  • security
  • research

Social engineering is an attack on people rather than systems: persuading someone to hand over a password, approve a transfer, plug in a device, or reset MFA on someone else's behalf. There's no memory corruption exploit or parser bug; what gets exploited is trust, haste, and the habit of being helpful.

The Verizon Data Breach Investigations Report (DBIR) 2024 found that roughly 68% of breaches involved a non-malicious human element, such as falling for phishing or making a configuration mistake. The FBI's IC3 recorded about US$2.9 billion in losses from business email compromise (BEC), fake emails asking for a transfer or a change of bank details, in 2023 alone. This post summarizes what research has found about these attacks, then what it means for developers who build and run systems. It complements OSINT for developers: OSINT is the research stage, social engineering is the exploitation stage.

The attack cycle

Kevin Mitnick, in The Art of Deception (2002), described social engineering as a repeating cycle:

StageWhat the attacker doesExample
Researchgathers names, roles, org structure, internal jargonLinkedIn profiles, the "Our Team" page, CT logs
Build a pretextcrafts a plausible role"I'm from IT, there's a problem with your VPN account"
Exploit trustasks for something small, then something biggeran OTP code, a password reset, access to an internal tool
Use the resultuses the access for the next stepgets into a system, then attacks others from inside

The first stage almost always relies on open sources. The more internal detail the attacker knows (a manager's name, the ticketing system's name, shift change times), the more convincing the pretext.

Why it works: the psychology

Robert Cialdini, in Influence (1984), summarized six principles that make people comply with requests. All of them show up again and again in real attacks:

PrincipleHow it appears in attacks
Authorityan email "from the CEO", a call "from the security team"
Scarcity and urgency"your account will be disabled within 24 hours"
Social proof"everyone else has already updated their details"
Likingthe attacker is friendly, familiar, uses nicknames
Reciprocitya small favor or gift before the request
Commitment and consistencya small request first, then gradually bigger ones

Frank Stajano and Paul Wilson, in Understanding Scam Victims: Seven Principles for Systems Security (Communications of the ACM, 2011), studied street scams together with the people who run them and arrived at a similar list: distraction, social compliance, herd behavior, the victim's own dishonesty, kindness, need and greed, and time pressure. Their most important conclusion for system designers: these weaknesses aren't victim stupidity but normal human traits. A system that relies on users "never being fooled" is wrong by design.

What the experiments show

Phishing from a "friend"

Jagatic and colleagues at Indiana University (Social Phishing, Communications of the ACM, 2007) sent simulated phishing emails to students. The control group got email from an unknown sender; the experimental group got email that appeared to come from one of their friends, with relationships taken from public social network data. The result: 16% of the control group entered their credentials, compared with 72% of the "from a friend" group. Open social data makes phishing far more effective, which is why the research stage matters so much to attackers.

USB drives in the parking lot

Tischer and colleagues (Users Really Do Plug in USB Drives They Find, IEEE Symposium on Security and Privacy, 2016) dropped 297 flash drives around the University of Illinois campus. At least 45% of them (135 drives) were plugged into a computer and had files opened, and the researchers estimate the true figure could be as high as 98%. The files only phoned home to the researchers, but they could just as well have been malware. When asked, most people said they plugged the drive in with good intentions: to find the owner.

Does phishing training work?

Two large studies give an uncomfortable answer:

  • Lain, Kostiainen, and Čapkun (Phishing in Organizations: Findings from a Large-Scale and Long-Term Study, IEEE S&P 2022) followed 14,773 employees for 15 months. Training shown right after an employee clicked a simulated email (embedded training) didn't make them more resilient, and could even have side effects that made some employees more susceptible. The positive finding: employee reports were very useful. When many people press the "report phishing" button, a campaign can be detected quickly, and the reporting habit lasts.
  • Ho and colleagues (Understanding the Efficacy of Phishing Training in Practice, IEEE S&P 2025) ran an eight-month randomized controlled experiment, with ten simulated phishing campaigns, on more than 19,500 employees of UC San Diego Health. There was no significant relationship between whether someone had recently completed annual training and how likely they were to be fooled, and embedded training lowered the average failure rate by only about 2%. Most users spent very little time on the training material.

That doesn't mean education is useless, but it can't be the main line of defense. One click out of thousands of employees is enough for an attacker.

Real cases

  • Twitter (2020). Attackers phoned several employees posing as internal IT and steered them to a fake page imitating the internal login. With access to an internal admin tool, they targeted 130 accounts, including high-profile ones, for a Bitcoin scam.
  • Uber (2022). An attacker who already had a contractor's password flooded their phone with MFA prompts, then contacted them on WhatsApp posing as IT and asked them to approve one. The technique is known as MFA fatigue.
  • MGM Resorts (2023). The group known as Scattered Spider called the help desk impersonating an employee and asked for a password and MFA reset. According to the attackers' own claim, they found that employee on LinkedIn. The resulting operational disruption lasted days.
  • Arup (2024). An employee in Hong Kong transferred HK$200 million (about US$25 million) in 15 transactions after joining a video call in which every other participant, including the "CFO", was a deepfake. Seeing and hearing a familiar face is no longer proof of identity.

The pattern is the same: the attackers didn't break any cryptography. They found a process that let one person, under pressure, grant access without a second check.

Defenses that don't depend on vigilance

Since the research shows people will occasionally be fooled, the best defense is to make being fooled not enough to cause damage.

Phishing-resistant authentication

An SMS or authenticator-app OTP can be typed into a fake page, and a push notification can be approved out of fatigue. WebAuthn (passkeys or FIDO2 security keys) is different: the credential is bound to the origin. The browser will only sign a challenge for the domain that registered it, so a page at login-your-domain.com.attacker.example gets nothing even if the user has already been fooled.

Passkey registration: rpId binds the credential to the domain
const credential = await navigator.credentials.create({
  publicKey: {
    challenge, // random bytes from the server, single use
    rp: { id: "your-domain.com", name: "Your Domain" },
    user: { id: userIdBytes, name: "name@your-domain.com", displayName: "Name" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }], // ES256
    authenticatorSelection: { residentKey: "required", userVerification: "required" },
  },
});

If push notifications stay in use, turn on number matching (the user types the number shown on the login screen) and limit repeated requests.

Processes that force a second check

  • Account and MFA resets at the help desk shouldn't rely only on information that can be found through OSINT (date of birth, manager's name, ID number). Verify through an already registered channel, or require approval from the person's manager.
  • Fund transfers and changes of bank details must be confirmed through a separate channel: a call to the number already on file, not the number in the requesting email.
  • Risky actions in internal tools (changing a user's account email, disabling MFA, exporting data) should require a second person's approval and always land in an audit log.

Starve the attacker of raw material

Spoofed email in your domain's name can be made much harder with SPF, DKIM, and DMARC with a p=reject policy:

A DMARC record that rejects spoofed email
_dmarc.your-domain.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@your-domain.com"

Beyond that, reduce exposed internal detail: org structure, system names, and employee email formats. How to close leaks like these is covered in OPSEC for developers.

Make reporting easy

Lain et al.'s findings show that employee reports are an effective sensor. Put a "report phishing" button in the email client, respond to every report quickly, and never punish someone who reports after they already clicked. Organizations that punish mistakes lose the reports, not the mistakes.

Conclusion

Two decades of research show a consistent pattern: the psychological principles social engineering exploits are a normal part of how people cooperate, training alone doesn't bring the victim rate down enough, and the most damaging attacks succeed because one person could grant access without a second check. For developers the lesson is practical: use origin-bound authentication, design sensitive processes to need more than one person or one channel, and make reporting easy.

References