# Attack Tree Analysis: [Attacker goal against system name]

> Attack tree analysis following the method popularised by Bruce Schneier
> ("Attack Trees", Dr. Dobb's Journal, December 1999): one attacker goal
> as the root, sub-goals refined through AND and OR nodes down to concrete
> leaf attacks, attributes on each leaf (cost, skill, likelihood),
> analysis of the cheapest and most likely paths, and countermeasures
> mapped to the nodes they cut. Replace every `[bracketed]` value and
> every row marked *Example*. The worked example targets the
> administrator account of a fictional SaaS billing console.

<!--
Guidance: How to use this template
- One tree per attacker goal. If you find yourself writing two roots,
  split the document.
- Build the tree top-down in the nested list first; draw the diagram only
  when the structure is stable.
- Rate leaves only. Parent values are computed from children: OR takes the
  easiest child, AND combines all children.
- Re-run the path analysis after each countermeasure; the cheapest path
  usually moves somewhere else rather than disappearing.
-->

| Field | Value |
|---|---|
| Document ID | [AT-BILLING-001] |
| System | [Billing console, release 3.2] |
| Attacker goal | [Take over a billing administrator account] |
| Attacker profile | [External, financially motivated, moderate skill, budget up to USD 10,000] |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Owner | [@security-engineer] |
| Reviewers | [@tech-lead], [@identity-team] |
| Related threat model | [TM-BILLING-002] |
| Last updated | YYYY-MM-DD |

## 1. Goal and scope

<!-- Guidance: State the root goal as the attacker would, in one sentence, and fix the assumptions. A vague goal ("hack the system") yields an unbounded tree. -->

**Root goal:** *Example:* Obtain an authenticated session with billing
administrator rights in the production billing console.

| Item | Value |
|---|---|
| Asset at stake | *Example:* Ability to issue refunds and change payout bank accounts |
| Impact if achieved | *Example:* Direct financial loss up to USD 250,000 per incident before detection |
| In scope | Web console, identity provider integration, support desk processes, administrator endpoints |
| Out of scope | Physical attacks on data centres; compromise of the cloud provider |
| Assumptions | MFA is enforced for administrators; console reachable from the internet |

## 2. Attacker profile

<!-- Guidance: The same tree yields different answers for different attackers. Record the profile used for the ratings, and repeat the analysis for a second profile if it matters. -->

| Attribute | Value used in ratings |
|---|---|
| Type | *Example:* External criminal group |
| Skill | Moderate: uses public tools and phishing kits; no novel exploits |
| Budget | Up to USD 10,000 per target |
| Time | Weeks |
| Access | No insider access at the start |
| Risk tolerance | Avoids actions likely to be detected before payout |

## 3. Attack tree

<!-- Guidance: Number nodes hierarchically (1, 1.1, 1.1.1). Mark each parent [OR] (any child suffices) or [AND] (all children needed). Leaves are concrete actions an analyst could estimate. -->

The tree below refines the root goal; `[OR]` means any child achieves
the parent and `[AND]` means all children are needed.

### 3.1 Tree as a nested list

- **0 Take over a billing administrator account** [OR]
  - **1 Steal credentials and bypass MFA** [AND]
    - 1.1 Obtain password [OR]
      - 1.1.1 Phish the administrator with a fake login page (leaf)
      - 1.1.2 Reuse a password from a third-party breach (leaf)
    - 1.2 Defeat MFA [OR]
      - 1.2.1 Adversary-in-the-middle proxy relays the one-time code (leaf)
      - 1.2.2 MFA fatigue: send repeated push prompts until approved (leaf)
  - **2 Abuse account recovery** [AND]
    - 2.1 Gather personal details of the administrator from social media (leaf)
    - 2.2 Persuade the support desk to reset MFA (leaf)
  - **3 Hijack an existing session** [OR]
    - 3.1 Steal a session cookie with malware on the administrator's laptop (leaf)
    - 3.2 Exploit stored XSS in the console to exfiltrate the session (leaf)
  - **4 Escalate from a low-privilege account** [AND]
    - 4.1 Obtain any customer-support account (leaf)
    - 4.2 Exploit a broken authorization check to assign the admin role (leaf)

### 3.2 Tree as a diagram

The diagram shows the same structure; AND gates are drawn as hexagons and
OR gates as rounded boxes.

```mermaid
flowchart TD
  G["0 Take over billing admin (OR)"]
  A1{{"1 Credentials + MFA bypass (AND)"}}
  A2{{"2 Abuse account recovery (AND)"}}
  O3("3 Hijack session (OR)")
  A4{{"4 Escalate from low privilege (AND)"}}
  O11("1.1 Obtain password (OR)")
  O12("1.2 Defeat MFA (OR)")
  L111["1.1.1 Phishing page"]
  L112["1.1.2 Breached password reuse"]
  L121["1.2.1 AitM proxy"]
  L122["1.2.2 MFA fatigue"]
  L21["2.1 OSINT on admin"]
  L22["2.2 Social-engineer support desk"]
  L31["3.1 Cookie-stealing malware"]
  L32["3.2 Stored XSS"]
  L41["4.1 Obtain support account"]
  L42["4.2 Broken authorization"]
  G --> A1
  G --> A2
  G --> O3
  G --> A4
  A1 --> O11
  A1 --> O12
  O11 --> L111
  O11 --> L112
  O12 --> L121
  O12 --> L122
  A2 --> L21
  A2 --> L22
  O3 --> L31
  O3 --> L32
  A4 --> L41
  A4 --> L42
```

## 4. Leaf attributes

<!-- Guidance: Rate every leaf for the attacker profile in section 2. Use real figures where you have them (prices of phishing kits, bug bounty data, incident history) and say where they came from. -->

Each leaf is rated for cost to the attacker (USD), skill (1 low to 5
expert), likelihood of success per attempt (0 to 1) and detectability
(Low, Medium, High) with current controls.

| Node | Leaf attack | Cost (USD) | Skill (1-5) | Likelihood | Detectability | Source of estimate |
|---|---|---|---|---|---|---|
| 1.1.1 | Phishing page | *Example:* 500 | 2 | 0.30 | Medium | Internal phishing simulation: 30% click rate |
| 1.1.2 | Breached password reuse | 100 | 1 | 0.05 | Low | Password screening already blocks known breached passwords |
| 1.2.1 | AitM proxy relays code | 1,500 | 3 | 0.60 | Low | Public phishing kits; TOTP is relayable |
| 1.2.2 | MFA fatigue | 0 | 1 | 0.10 | High | Number matching enabled in 2025 |
| 2.1 | OSINT on admin | 200 | 1 | 0.90 | Low | Public profiles |
| 2.2 | Social-engineer support desk | 1,000 | 3 | 0.15 | Medium | Two of 20 red-team calls succeeded |
| 3.1 | Cookie-stealing malware | 3,000 | 3 | 0.10 | Medium | EDR on managed laptops |
| 3.2 | Stored XSS | 5,000 | 4 | 0.05 | Medium | CSP in place; last pentest found none |
| 4.1 | Obtain support account | 800 | 2 | 0.25 | Medium | Support staff not on phishing-resistant MFA |
| 4.2 | Broken authorization | 4,000 | 4 | 0.10 | Low | Role endpoint lacks server-side check (finding SR-014) |
| [n.n] | [Leaf] | [Cost] | [1-5] | [0-1] | [L/M/H] | [Source] |

## 5. Path analysis

<!-- Guidance: Compute parent values from leaves. OR: take the minimum cost (or maximum likelihood) child. AND: sum the costs, take the maximum skill and multiply the likelihoods (assuming independence; say so if not). -->

Values propagate upwards with these rules:

$$
\text{OR: } C = \min_i C_i,\quad P = \max_i P_i \qquad
\text{AND: } C = \sum_i C_i,\quad P = \prod_i P_i,\quad S = \max_i S_i
$$

where $C$ is cost, $P$ likelihood and $S$ required skill.

### 5.1 Computed node values

| Node | Gate | Cost (USD) | Skill | Likelihood | Cheapest child |
|---|---|---|---|---|---|
| 1.1 | OR | 100 | 1 by cost, 2 by likelihood | 0.30 | *Example:* 1.1.2 by cost, 1.1.1 by likelihood |
| 1.2 | OR | 0 | 1 by cost, 3 by likelihood | 0.60 | 1.2.2 by cost, 1.2.1 by likelihood |
| 1 | AND | 2,000 (1.1.1 + 1.2.1) | 3 | 0.18 | Most likely combination |
| 2 | AND | 1,200 | 3 | 0.135 | |
| 3 | OR | 3,000 | 3 | 0.10 | 3.1 |
| 4 | AND | 4,800 | 4 | 0.025 | |
| 0 | OR | 1,200 by cost; path 1 by likelihood | 3 | 0.18 | Path 1 |

### 5.2 Critical paths

| Rank | Path | Cost | Likelihood | Why it matters |
|---|---|---|---|---|
| 1 | *Example:* 1.1.1 phishing AND 1.2.1 AitM proxy | 2,000 | 0.18 | Highest likelihood; low detectability of the proxy |
| 2 | 2.1 OSINT AND 2.2 support-desk reset | 1,200 | 0.135 | Cheapest path; bypasses MFA entirely |
| 3 | 3.1 session theft by malware | 3,000 | 0.10 | Independent of authentication controls |
| [n] | [Path] | [Cost] | [P] | [Reason] |

Expected loss for the top path, using the impact in section 1:
$0.18 \times 250{,}000 = \text{USD } 45{,}000$ per targeted campaign.

## 6. Countermeasures

<!-- Guidance: For each countermeasure, name the nodes it cuts and re-rate them. A countermeasure on an AND node's child cuts the whole branch; on an OR node it only removes one option. -->

| ID | Countermeasure | Nodes affected | New rating | Cost to defender | Owner | Status |
|---|---|---|---|---|---|---|
| CM-01 | *Example:* Phishing-resistant MFA (FIDO2 security keys) for all administrators | 1.2.1, 1.2.2 | 1.2.1 likelihood 0.60 to 0.01 | USD 3,000 keys + 5 days | [@identity-team] | [Planned] |
| CM-02 | Support desk may not reset administrator MFA; reset requires in-person or manager-verified video check | 2.2 | Likelihood 0.15 to 0.02 | Process change | [@support-lead] | [Planned] |
| CM-03 | Bind admin sessions to device (token binding or short-lived cookies with re-authentication for payouts) | 3.1, 3.2 | Impact reduced: payouts need fresh key touch | 10 days | [@platform] | [Open] |
| CM-04 | Fix server-side role assignment check (SR-014) | 4.2 | Likelihood 0.10 to 0.01 | 2 days | [@billing-team] | [In progress] |
| CM-05 | Alert on new device login plus payout account change within 24 hours | All paths | Detectability raised to High | 3 days | [@secops] | [Open] |
| [CM-nn] | [Countermeasure] | [Nodes] | [Rating change] | [Cost] | [@name] | [Status] |

### 6.1 Re-analysis after countermeasures

| Path | Likelihood before | Likelihood after | Cost before | Cost after |
|---|---|---|---|---|
| 1 Credentials + MFA bypass | 0.18 | *Example:* 0.003 | 2,000 | 2,000 |
| 2 Account recovery | 0.135 | 0.018 | 1,200 | 1,200 |
| 3 Session hijack | 0.10 | 0.10 (impact reduced by CM-03) | 3,000 | 3,000 |
| 4 Privilege escalation | 0.025 | 0.0025 | 4,800 | 4,800 |

*Example:* After CM-01 to CM-04, session hijack (path 3) becomes the
most likely path; CM-03 and CM-05 limit what it can achieve.

## 7. Conclusions and actions

<!-- Guidance: Summarise in three or four sentences what the tree shows and what will be done, so a reader who skips the tables still gets the decision. -->

*Example:* The cheapest and most likely routes to administrator takeover
go around MFA rather than through it: relayable one-time codes and
support-desk resets. Phishing-resistant keys and a strict reset process
remove both. Session theft then becomes the leading path and is
addressed by device binding and step-up authentication for payouts.

| Action | Owner | Due |
|---|---|---|
| Implement CM-01 and CM-02 before next quarterly access review | [@name] | YYYY-MM-DD |
| Re-run this analysis after CM-03 is deployed | [@name] | YYYY-MM-DD |
| [Action] | [@name] | YYYY-MM-DD |

## 8. References

<!-- Guidance: Cite the method and the evidence used for ratings. -->

| Reference | Use |
|---|---|
| Schneier, B. "Attack Trees", Dr. Dobb's Journal, December 1999 | Method: goal decomposition with AND/OR nodes and leaf attributes |
| [Internal phishing simulation report] | Likelihood of 1.1.1 |
| [Red-team report] | Likelihood of 2.2 |
| [Threat model TM-BILLING-002] | Source threats |

## Standard and licence note

Based on the attack tree method described by Bruce Schneier ("Attack
Trees", Dr. Dobb's Journal, 1999) and common security engineering
practice for AND/OR decomposition and attribute propagation. This
template is original text written for this collection and reproduces no
text from that article. Template licence: MIT.