What is attacker engineering?
Attacker engineering is building defensive systems, frameworks, and architecture backward from how attackers actually operate.
Not forward from a control checklist — so detection, fraud, identity, and platform defense share one adversary-informed vocabulary.
Vincent Passaro, Head of Attacker Engineering & Intelligence Partnerships at Stripe. Personal site, personal view. Speaker bio: RBLN (opens in a new tab).
What problem attacker engineering solves
Controls and frameworks written without attacker realism drift into checkbox security. A control can be documented, assigned, and still miss the path an attacker takes. The checklist records what the program intended to prevent. It does not record what the attacker did.
Fraud, identity, and platform teams need a shared way to describe adversary behavior before they automate detection, testing, or response. If each team names the same behavior differently, the systems built on those names do not meet. Automation then scales the mismatch.
Job posts use “attacker” for three different jobs: demonstrating an intrusion, building automated attack modules, or building the defense from those paths. Attacker engineering is the third.
What attacker engineering does
A way of building, not an org chart. 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
Detection, testing, architecture, and a shared language are the point. A briefing that never changes a system is research, not this practice.
Work across surfaces
The practice crosses security, payments, identity, fraud, and platform surfaces. A path that starts in one of those places usually continues in another, and a description that stops at the team boundary is incomplete.
Produce reusable artifacts
Frameworks, mappings, and tooling should outlast the exercise that motivated them. FT3 (Fraud Tools, Tactics, and Techniques) is the public example: the practice applied to fraud. It is an output, not a synonym.
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. | Feeds the practice tradecraft to turn 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 the adversary truth the practice supplies. |
| 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
Attacker engineering 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. Attacker engineering asks what defensive system should exist because attackers work that way.
What the practice supplies
Detection engineering
Detection pipelines encode adversary truth: which behaviors matter, how they chain, and what a miss looks like. The practice supplies it.
Purple team
Purple team is a way of working: an offense–defense loop. Attacker engineering builds the systems that loop is trying to improve.
Fraud operations
Working a fraud queue with a shared language is operations. Building the language is attacker engineering.
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 — not forward from a control checklist — so detection, fraud, identity, and platform defense share one adversary-informed vocabulary.
- What does an attacker engineer do?
- Four moves: model adversary behavior at technique and path level, turn that model into systems, work across surfaces, and produce reusable artifacts.
- 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. It is his view, not an official Stripe statement, product page, or channel.
- How is attacker engineering different from threat-informed defense?
- Attacker engineering works inside threat-informed defense, not beside it. 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 is the program-level approach. Attacker engineering is the engineering practice that builds the systems and the shared language that approach depends on.
- How is attacker engineering different from red team work?
- Red team and offensive security demonstrate attack paths and achieve objectives. Attacker engineering owns the lasting defensive systems built from those paths: detection, architecture, and shared language.
- How is attacker engineering different from adversary emulation?
- Adversary 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), explains. Attacker engineering uses emulation as an input; it designs the defensive systems that emulation tests.
- 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
- RBLN West“When Both Sides Have Agents: Attacker Engineering at Machine Speed”Upcoming
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 careerLineage. The seat where complex events are already underway.
- AcheronResearch engine supporting FT3: candidate techniques and coverage.
- Resume of impactCareer record across security, payments, identity, fraud, and platform.
- ContactGet in touch.