The attacker's mindset is systems thinking

Security people love the phrase “think like an attacker,” but rarely unpack it. Here’s my working definition: an attacker is someone who reads a system as it is, not as it was intended.

Designers think in features. Attackers think in interactions between features. Almost every interesting vulnerability lives in the seam between two components that are each individually correct:

• The parser is fine. The renderer is fine. The parser’s output fed to the renderer is the bug.
• The IAM policy is fine. The default service role is fine. Together they’re a privilege escalation. See cloud-iam-blast-radius.
• The model follows instructions. The document contains instructions. Now the document is the operator. See prompt-injection-is-untrusted-input.

This is just Donella Meadows with a hoodie on. Systems thinking says behavior emerges from structure, not from the intentions of the parts. Offense is the empirical branch of that claim.

The practical loop

1. Build the designer’s mental model of the system.
2. Build a second model from the actual artifacts: code, configs, network behavior.
3. Attack the difference between the two models.

CTFs are a gym for step 3 (ctf-field-notes-web), because puzzle authors deliberately hide a gap between appearance and structure.

Two ways I actually work this loop: fuzzing automates step 3, mutating inputs until the gap between the two models reveals itself, and threat modeling runs the loop in reverse, mapping a system’s seams on purpose before someone else does.

The kindest thing about this mindset: it transfers. Markets, incentives, organizations: anything with rules has seams. That’s half of why I keep poking at quant ideas.