What is attacker engineering?
Attacker engineering is building defensive systems, frameworks, and architecture backward from how attackers actually operate.
It starts from attacker techniques and paths instead of a control checklist, so detection, fraud, identity, and platform teams use the same names for the same attacker behavior.
Vincent Passaro is Head of Attacker Engineering & Intelligence Partnerships at Stripe. These are his own views. Speaker bio: RBLN (opens in a new tab).
What problem attacker engineering solves
Controls written without a real attacker in mind turn into checkbox security. A control can be documented and owned and never touch the path an attacker takes. The checklist still marks it covered.
Fraud, identity, and platform teams often watch the same attacker from different sides. When each team names the behavior its own way, the detections and tests they build don’t connect, and automating them copies the gap into every system downstream.
Job posts use “attacker” for three different jobs: showing that an intrusion works, building automated attack tools, and building defenses from the paths attackers take. Attacker engineering is the third.
What attacker engineering does
The practice doesn’t depend on a team carrying the name. It comes down to four moves.
Model adversary behavior at technique and path level
Name what the attacker does, in what order, and against which surface. A path is a sequence a defender can point at, not a list of controls with the word “attacker” added.
Turn that model into systems
The model has to end up in a detection, a test, an architecture decision, or the names teams use for an attack. A briefing that changes no system is useful research, but it is a different job.
Work across surfaces
Attacks rarely stay inside one team’s surface. A path that starts in identity often ends in payments or fraud, and a model that stops at a team boundary leaves out the part someone else has to clean up.
Produce reusable artifacts
Frameworks, mappings, and tools should keep working after the project that produced them ends. FT3 (Fraud Tools, Tactics, and Techniques) is the public example, one thing this practice has produced when applied to fraud.
One path, turned into a rule and a test
Security, platform, and billing support all use one name for it: exposed-key compute abuse.
How attacker engineering differs from nearby roles
No standards body defines attacker engineering alongside red team, purple team, or adversary emulation. The comparisons below are Passaro’s own.
| Practice | What it does | Relation to attacker engineering |
|---|---|---|
| Red team and offensive security | Demonstrates attack paths and achieves objectives against a target. | Feeds the practice with demonstrated attack paths. |
| Threat intelligence and CTI | Collects and analyzes adversary tradecraft, actors, and campaigns. | Supplies the tradecraft the practice turns into systems. |
| Adversary emulation | Replays a named actor’s techniques to test whether defenses catch them. | Informs the practice; validates defenses rather than designing them. |
| Detection engineering | Builds and operates detection content and pipelines. | Encodes what the practice learns about attacker behavior. |
| Purple team | Runs a collaborative offense–defense loop to improve detection. | Improves the systems and language the practice builds. |
| Fraud operations | Works fraud cases and runs controls day to day. | Uses the operating language the practice builds, such as FT3. |
| Attack Engineer jobs | Builds offensive products: automated attack modules and the platforms running them. | Outside the practice: same words, different object. |
What feeds the practice
Red team and offensive security
The practice takes the paths a red team demonstrates and owns the defensive systems built from them.
Threat intelligence and CTI
The practice converts tradecraft into something a team can build: a model, a control, a framework, a test.
Adversary emulation
Emulation asks whether a known behavior would be caught. The practice asks what defensive system should exist because attackers work that way.
What the practice supplies
Detection engineering
A detection pipeline needs to know which behaviors matter, how they chain together, and what a miss looks like. Attacker engineering supplies that knowledge.
Purple team
Purple teaming is a working loop between offense and defense. Attacker engineering builds the systems that loop is trying to improve.
Fraud operations
Fraud analysts use those names to work the queue every day. Attacker engineering builds and maintains them.
Questions about attacker engineering
- What is attacker engineering?
- Attacker engineering, as defined by Vincent Passaro, is building defensive systems, frameworks, and architecture backward from how attackers actually operate. It starts from attacker techniques and paths instead of a control checklist, so detection, fraud, identity, and platform teams use the same names for the same attacker behavior.
- What does an attacker engineer do?
- An attacker engineer models adversary behavior at the technique and path level, turns that model into detections, tests, and architecture, works across team boundaries, and builds frameworks and tools other teams reuse.
- Who defines attacker engineering here, and is this a Stripe page?
- Vincent Passaro, Head of Attacker Engineering & Intelligence Partnerships at Stripe, defines it here on his personal site, vincentpassaro.com. This is a personal site, and nothing on it is an official Stripe statement.
- How is attacker engineering different from threat-informed defense?
- Attacker engineering sits inside threat-informed defense. MITRE’s Center for Threat-Informed Defense (opens in a new tab) says threat-informed defense “aligns defensive measures to real-world observations of adversary tradecraft.” That sets the direction for a whole program, and attacker engineering builds the systems and the common names that program relies on.
- How is attacker engineering different from red team work?
- A red team shows that an attack path works and reaches its objective. Attacker engineering takes those paths and owns the defenses built from them, from detection rules to architecture changes.
- How is attacker engineering different from adversary emulation?
- Attacker engineering uses adversary emulation as an input and designs the defenses emulation then tests. Emulation replays a named actor’s tactics, techniques, and procedures to see whether defenses catch them, as Blake Robertson’s 2023 essay for MITRE’s Center for Threat-Informed Defense, “Adversary Emulation: Why We Do It” (opens in a new tab), describes.
- Is an Attack Engineer job the same thing?
- No. Attacker engineering is a defensive practice. Attack Engineer and Attack Engineering postings, including Horizon3’s Attack Engineer posting (opens in a new tab), hire for offensive product engineering: automated attack modules.
- Is attacker engineering the same as social engineering?
- No. Social engineering is an attack technique that manipulates people into giving up access, money, or information; attacker engineering is a defensive practice that models it as one attacker behavior among many.
- Is FT3 the same as MITRE F3?
- No. FT3 (Fraud Tools, Tactics, and Techniques) is a framework Vincent Passaro created; its hub is vincentpassaro.com/ft3. MITRE F3 is the Fight Fraud Framework (opens in a new tab), a separate effort.
Where the term appears
Where to go next
- FT3, the framework hubFraud Tools, Tactics, and Techniques.
- Building adversary language systemsHow a shared vocabulary for attacker behavior gets made.
- FT3 2.0, a dimensional fraud taxonomyWhat changed when the fraud taxonomy stopped being a flat matrix.
- Inside a Tier-3 incident response careerThe tier-3 incident response work this practice grew out of.
- AcheronResearch engine supporting FT3: candidate techniques and coverage.
- Resume of impactThe full career record, role by role.
- ContactGet in touch.