Social Engineering Attack Database

S.E.A.db

Open Reference Framework

A structured taxonomy of social engineering mechanisms — principles, emotions, techniques, and contexts — with canonical IDs, MITRE ATT&CK mappings, and cross-references. The human layer of attack, documented.

15 Principles 07 Emotions 56 Techniques 04 Contexts
SEA-P · Principles SEA-E · Emotions SEA-T · Techniques SEA-C · Contexts

Get informed on how social engineering shows up in the headlines, see why this classification matters, and learn how to apply it day to day.

SEA-P — Principle

PRINCIPLES

Universal psychological triggers exploited in social engineering. Present across all attack vectors and delivery mechanisms.

SEA-E — Emotion

EMOTIONS

Affective states activated in the target during the attack. Each emotion produces a distinct behavioral profile across the click→collect funnel.

SEA-T · · — Technique

TECHNIQUES

Attack execution methods organized by vector. Each technique maps to MITRE ATT&CK where applicable and includes detection signals and forensic indicators.

Vector:
SEA-C — Context

CONTEXTS

Situational conditions that amplify or attenuate an attack. A new entity type with no equivalent in existing frameworks — documents the environmental layer of social engineering.

About the Project

WHY S.E.A.db EXISTS

Social engineering has been extensively documented on the technical, MITRE ATT&CK covers the how. What has never been structured is the human layer: why people comply, what emotional state was activated, which cognitive system was bypassed.

After 9 years running phishing simulations, vishing campaigns, and physical intrusion tests, most of it invisible work, inside client environments, away from any public stage, I noticed that the mechanisms repeat. The same principles appear in a tax reform email and in a parking lot tailgate. The same emotional state drives a click on a prize offer and compliance with a fake executive directive.

S.E.A.db is my attempt to make that pattern visible. Not a benchmark, not a threat feed, a structured vocabulary for the human side of attacks. Every ID is a mechanism I have documented across hundreds of real simulations. Every cross-reference is a relationship I have observed in the data.

This database is public and free. If it helps a practitioner build a better simulation, a trainer explain why people fall for it, or a researcher find language for what they already know — it has done its job.

The Author
Luiz C Chieregato
Social Engineering Practitioner

9 years designing and analyzing social engineering simulations. Creator of S.E.A.map — a proprietary methodology for phishing campaign analysis covering HFACS, Bow-Tie, and MITRE ATT&CK.

oes.seg.br ↗ LinkedIn ↗ Email
Want the data behind the mechanisms?

S.E.A.db documents the what and the why. S.E.A.map takes it further — it is a structured analysis tool that maps a real phishing simulation across behavioral, organizational, and technical dimensions. HFACS, Bow-Tie, MITRE ATT&CK, emotional funnel, and campaign benchmarks drawn from over 800 simulations across 9 years — all in a single interactive report.

Learn more about S.E.A.map →
Field Guide

HOW TO USE

From classifying a pretext, to reading a campaign with precision, to planning the next one with consistency — how the SEA.db taxonomy turns a click rate into a decision.

The premise
Click rate is not intelligence.

A click rate answers one question — how much happened — and treats that answer as the result. "34 of 363 clicked" describes without explaining, and without explanation no defense can be aimed. The SEA.db doesn't replace the click rate with a better number. It adds the layers that say why the attack worked, where the defense failed, and what to do next. That is the difference between a data point (it happened) and intelligence (what to do about it).

01 — Before the campaign

CLASSIFY THE MODEL

Before you fire a simulation, classify the pretext you are about to use. The SEA.db breaks any social engineering attack into four independent axes. A complete diagnosis uses all four — and classifying up front is what later makes the result comparable and the countermeasure addressable.

SEA-P
How
The principle — the psychological lever the attacker pulls. Authority, scarcity, reciprocity, familiarity. This is the engineering of the pretext.
SEA-E
What
The emotion — the internal state the pretext activates in the target. Fear, benefit, curiosity, belonging. This is the effect on the human.
SEA-T
With what
The technique — how the pretext was materialized. Brand spoofing, hyperlink masking, an expanded form, a suppressor screen. Organized by vector.
SEA-C
In what setting
The context — the circumstance the pretext anchors to. A real external event, internal knowledge, a seasonal window, or administrative routine.

A principle is what the attacker does; an emotion is what the victim feels. A good pretext chains principles to produce an emotion that suppresses rational analysis. Worked example: a fake "Black Friday corporate benefits program" email leans on Greed (SEA-P-006) and Affinity (SEA-P-012), fires the emotion Happiness/Benefit (SEA-E-002), is materialized through email techniques, and is anchored in a Seasonal Window (SEA-C-003). Once classified, every axis points somewhere: the name of the mechanism is the address of the countermeasure.

02 — After the campaign

ANALYZE WITH PRECISION

A well-built attack rarely fires one mechanism in isolation — it runs in sequence, and each phase has its own window of failure and its own countermeasure. Knowing which phase the attack won, and which barrier the organization failed at, is what gives the next training an address.

01
Activation — the pretext gets attention
The email itself. The dominant principle hits something the employee already carries — a desire, a worry, a bond, an information gap. Countermeasure: not "spot the suspicious email" but the habit of pausing the moment an email evokes an immediate emotion.
02
Legitimation — the source looks credible
Familiarity, authority, context validation, social proof — usually via brand spoofing. Countermeasure: verify the real sending domain, not the display name; visual familiarity is not proof of origin.
03
Compromise — the first click
Where most generic training focuses, and stops. If they got here, the email did not look suspicious. Countermeasure: deliberate friction at the click — check the URL in the bar, character by character if needed.
04
Conversion — the data is handed over
The last point where defense can still work, and the one that gets the least training. Countermeasure: the most counterintuitive — teach that stopping mid-process is correct. Typing the password is always the final, irreversible step.

This is where the three proprietary indices read the result. What matters is the question each one answers — the question the click rate can't:

ERI
Emotional Risk Index — the emotional manipulation potential of the pretext.
CEF
Cognitive Escape Factor — how much people resisted after the first click. A higher value means a stronger second barrier. It is not conversion efficiency.
PPI
Phishing Persistance Index — average interactions per unique victim (≥1.0×). Above 1.0× flags the profiles a real attacker would re-contact.
03 — The trap to avoid

DON'T BE FOOLED BY METRICS THAT MOVED

Your click rate dropped. Did you improve — or did you just change the attack?
A click rate falls between two campaigns and the report reads it as progress. But if the two campaigns ran different emotional mechanisms, the comparison is a false signal. A 9% click on a Greed pretext with a Black Friday context is a completely different phenomenon from 9% on an Authority pretext from IT. The emotion — not the sector, not the calendar — calibrates the real expectation. Comparing campaigns with different mechanisms produces noise that looks like a trend.

And the click rate is structurally blind to the second barrier. Picture a campaign with a 14% click rate — below any sector average, a number an organization would happily file away. But the CEF is low: nearly half of the people who reached the collection screen handed over their credentials. The first barrier (don't click) held for most; the second barrier (don't submit, even after clicking) collapsed. The problem isn't the email — it's the next screen. Two campaigns with the same 14% click can demand opposite trainings: one where the click is the problem, one where the conversion is. The click rate alone cannot tell them apart. That is exactly what it is built to miss.

The rule that follows: compare only equivalent mechanisms. Same emotion, same context. Otherwise you are measuring the change in attack, not the change in your people.

04 — Before the next campaign

PLAN THE NEXT ONE

The diagnosis is only worth what the next decision does with it. Once you know which phase the attack won and which barrier failed, the next campaign stops being a random draw and becomes a deliberate choice: which emotion, which principle, which context to test next — and which mechanism to repeat in order to measure whether your people actually changed.

That is what turns the loop simulation → analysis → training → new simulation into something that evolves instead of something that repeats. Hold the mechanism constant when you want to measure improvement; vary it deliberately when you want to map exposure. The classification you did in step 01 is what makes both moves legitimate — because you know what you are holding and what you are changing.

05 — Make it yours

USE IT IN YOUR OWN TOOLING

The SEA.db is open under CC BY 4.0 and the IDs are stable. You don't need permission, an account, or our infrastructure to build on it. Three ways to put it to work:

  1. Reference. Cite the canonical IDs (SEA-P-007, SEA-E-005, …) in your internal reports, playbooks, and post-campaign reviews so everyone names the same mechanism the same way.
  2. Integrate. Pull the taxonomy structure into your own dashboard or analysis tool and classify your campaigns along the same four axes — principle, emotion, technique, context.
  3. Contribute or fork. The repository is public. Extend it, adapt it, or build something entirely your own on top of it.

We built a report that runs on this taxonomy — SEA.map. It came out of the SEA.db, not the other way around. You can build your own on the same foundation.

↗ Open the repository on GitHub
Licensed under CC BY 4.0 · citable via Zenodo DOI 10.5281/zenodo.20791723
⌕
Press ESC to close · Enter or click to navigate