category hub
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 leads Attacker Engineering at Stripe. This page is his personal definition of the practice. It is not an official Stripe statement, product page, or channel. A public speaker bio at RBLN (opens in a new tab) puts the same idea in one line: defensive systems built backward from how attackers actually operate, not forward from controls.
The output is work that stays. Frameworks, adversary-informed architecture, and detection research. Not a penetration test that ends when the report is delivered. FT3 (Fraud Tools, Tactics, and Techniques) is the public example of that output in fraud. FT3 is not the name of the practice, and it is not MITRE’s Fight Fraud Framework (F3).
Attack paths run forward in steel. Amber squares assemble back along them.
01
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.
The title is also hard to hire for and hard to explain. Red team, detection engineering, threat intelligence, and fraud operations share words with this practice and not its object. A requisition that says “attacker” can mean someone who demonstrates an intrusion, someone who builds automated attack modules, or someone who builds the defense from those paths. Those are different jobs. This page names the third one.
02
The practice is a way of building, not an org chart and not a catalog of exercises. Four moves are enough to inspect it.
Four lanes. Packets travel forward. Squares lock in behind them.
01
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.
02
Detection, testing, architecture, and a shared language are the point. A briefing that never changes a system is research, not this practice.
03
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.
04
Frameworks, mappings, and tooling should outlast the exercise that motivated them. FT3 is the flagship public example: attacker engineering applied to fraud, published as its own framework. The practice produced it. The framework is not a synonym for the practice. Read the framework at its own hub. This page will not pretend to be the catalog.
03
No standards body names attacker engineering as a peer of red team, purple team, or adversary emulation. Those neighbors have public definitions. This practice does not, outside Passaro’s own writing and talks. The comparisons below are his. They cite the neighbor. They do not borrow the neighbor’s name.
One field flies apart. The other pulls inward.
The defensive practice defined on this page. Prefer the full phrase. Building defense from how attackers operate.
A job-market title. Public postings, including Horizon3’s NodeZero-class Attack Engineer role, describe offensive product engineering: automated attack modules. Same word cluster. Different object. This site does not claim those jobs.
Fraud Tools, Tactics, and Techniques. An output of the practice. The citation target is /ft3. Not a synonym for attacker engineering.
MITRE’s Fight Fraud Framework (F3) (opens in a new tab). A different framework. FT3 ≠ F3.
vincentpassaro.com is a personal site. Vincent Passaro is employed by Stripe. It is not an official Stripe channel.
Red team and offensive security demonstrate paths and achieve objectives. Attacker engineering takes those paths and owns the defensive systems built from them. A test that ends when the report is sent is not this practice.
Adversary emulation replays a named actor’s tactics, techniques, and procedures, drawn from threat intelligence, to see whether defenses catch them. MITRE’s Center for Threat-Informed Defense describes that purpose in Blake Robertson’s 2023 essay Adversary Emulation: Why We Do It (opens in a new tab). Emulation informs attacker engineering. It is not attacker engineering. Emulation asks whether a known behavior would be caught. Attacker engineering asks what defensive system should exist because attackers work that way.
Purple team is a collaborative offense–defense loop run to improve detection. It is a way of working. Attacker engineering builds the systems that loop is trying to improve, and the language those systems share.
Detection engineering crafts and operates detection content and pipelines. Attacker engineering supplies the adversary truth those pipelines encode: which behaviors matter, how they chain, and what a miss looks like.
Threat intelligence collects and analyzes. Attacker engineering converts tradecraft into something a team can build: a model, a control, a framework, a test. A report that never becomes a system has not become the practice.
Fraud operations is casework and the day-to-day running of controls. Attacker engineering builds the operating language and the systems those teams use. FT3 is one such language for fraud. Working a queue with that language is operations. Building the language is the practice.
Public “Attack Engineer” and “Attack Engineering” postings, including Horizon3’s Attack Engineer role (opens in a new tab), hire for offensive product engineering: automated attack modules and the product that runs them. The words overlap. The object does not. Prefer the full phrase attacker engineering for the defensive practice on this site. Do not treat those job descriptions as a definition of this page.
04
FT3 is the public example of attacker-engineering output in fraud. It gives teams a consistent way to describe attacker behavior. The framework hub is /ft3. Use that page for the framework. Use this page for the practice. MITRE F3, the Fight Fraud Framework, is a separate effort. Do not swap the names.
Other pages are inputs or adjacent work, not a second definition. Adversary language is how a shared vocabulary gets built. The FT3 2.0 essay is how the fraud taxonomy gained dimensions. Tier-3 incident response is lineage: what it looks like to sit where complex events are already in progress. Acheron is a research engine aimed at fraud technique discovery in support of FT3. /impact is role proof — offensive-informed systems, frameworks, and architecture across security, payments, identity, fraud, and platform — not the definition.
Separate paths end on one square, FT3.
05
01
Hiring managers who see the title and need a plain definition before they write a requisition or read a résumé that uses a similar phrase.
02
Practitioners comparing the work to red team, detection engineering, threat intelligence, or fraud operations, and who need the differences to stay sharp.
03
Teams building agentic, fraud, or payment defense who need the category named correctly before they staff it, buy a tool, or adopt a job title that only looks the same.
06
This page routes outward. Each link below is a specific piece of work, not a restatement of the definition.
07
01
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. The output is lasting defensive work, including frameworks such as FT3, not a penetration test that ends when the report is delivered.
02
Vincent Passaro, Head of Attacker Engineering at Stripe. This is his personal definition hub on vincentpassaro.com. It is not an official Stripe channel. A public RBLN speaker bio describes the same direction: defensive systems built backward from how attackers actually operate, not forward from controls (https://www.rbln.com/speakers/vincent-passaro).
03
Red team and offensive security demonstrate paths and achieve objectives. Attacker engineering owns the lasting defensive systems built from those paths: detection, architecture, and shared language. Running a pen test and leaving is not this practice.
04
Adversary emulation is CTI-driven replay of a named actor’s tactics, techniques, and procedures, used to validate defenses. MITRE’s Center for Threat-Informed Defense describes that purpose in Blake Robertson’s 2023 essay “Adversary Emulation: Why We Do It” (https://medium.com/mitre-engenuity/adversary-emulation-why-we-do-it-629c7e27e566). Emulation informs attacker engineering. It is not attacker engineering.
05
No. Job-market Attack Engineer and Attack Engineering roles, including Horizon3’s NodeZero-class Attack Engineer posting (https://jobs.ashbyhq.com/horizon3ai/94efbe91-1cdb-4875-99ec-a5680628d895), hire for offensive product engineering: automated attack modules. Attacker engineering on this site is the defensive practice. Same words. Different object.
06
No. FT3 is Fraud Tools, Tactics, and Techniques, a framework Vincent Passaro created and an output of attacker engineering. Its hub is https://www.vincentpassaro.com/ft3. MITRE F3 is the Fight Fraud Framework (https://ctid.mitre.org/fightfraud). FT3 is not MITRE F3.
07
No. Vincent Passaro is employed by Stripe. vincentpassaro.com is his personal site. It is not an official Stripe statement, product page, or channel.