Chapter 9 — Tools and methods | Technical Authorized offensive security and red team

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 9 — Tools and methods

Lesson map

Lesson 09 published. Map, example, EX033.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 Method cards"]
  N2["9.3 WSTG selection"]
  N3["9.4 Interpretation"]
  N4["9.5 Version pin"]
  N5["9.6 Forbidden methods"]
  N6["9.7 Card library"]
  N7["9.8 Noise budget"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX033"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 Method cards"]
  N2["9.3 WSTG selection"]
  N3["9.4 Interpretation"]
  N4["9.5 Version pin"]
  N5["9.6 Forbidden methods"]
  N6["9.7 Card library"]
  N7["9.8 Noise budget"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX033"]

[Learning outcomes]
    |
    v
[9.1 Method cards]
    |
    v
[9.3 WSTG selection]
    |
    v
[9.4 Interpretation]
    |
    v
[9.5 Version pin]
    |
    v
[9.6 Forbidden methods]
    |
    v
[9.7 Card library]
    |
    v
[9.8 Noise budget]
    |
    v
[Worked example] --> [Exercise EX033]

Learning outcomes

You will (1) choose methods from WSTG themes; (2) configure tools with rate limits; (3) interpret results with the system model; (4) keep a method card per check.

9.1 Method cards

Each card: purpose, ROE reference, tool/settings, stop conditions, evidence expected.

On top of those fields, every card must name the check, the rate limit, the harm mode and the evidence expected. Those four entries are the minimum for ENG-512: a card that lacks any of them is rejected at peer review and stays out of Sam's Saturday stack. The rule keeps improvised checks off the engagement, because a technician cannot run a method whose rate and harm were never written down and agreed.

9.2 Rate limits

Scanners get explicit rate limits below what staging can take. Faster is not better.

On the staging login checks this means a hard cap on attempts per minute, set so the 401 loop pattern cannot recur and the noise budget stays intact. When the cap trips, the job fails closed and ends; it does not quietly slow down and keep retrying. Journey-planner auth cards follow the same rule, so a peer reading any auth card can see the agreed rate and know exactly what happens when it is reached.

9.3 WSTG selection

Sam picks auth, session, access control and input handling for the journey planner API, not every WSTG item in one window. WSTG selection for NMT staging focuses on the session, auth and input checks that match rider-facing risk, with session and auth on the journey planner first. Cards that need fare backends are not selected for ordinary ENG-512 and stay off the selection list. A narrow selection done well also gives the report an honest coverage statement: the themes left out are named as not tested in this window rather than implied to be clean.

9.4 Interpretation

Map each tool alert to a model element before promoting it to a finding.

A tool hit becomes a finding only after a human has traced a path to impact. An outdated banner reported at low confidence stays in discovery until Sam shows exposure and impact with evidence that a peer can reproduce on staging. This keeps banner-only noise out of the report, and it means every finding the owner receives already explains which part of the system model is affected and why it matters.

9.5 Version pin

Record tool versions on the method card.

Scanner and script versions are pinned in the notebook beside ENG-512 before the window opens. Without pins, a retest can turn into an argument about setup: the owner says FIXED, the tester sees STILL OPEN, and nobody can tell whether the tool changed in between. With the versions written down, the second run uses the same tools as the first, so any difference in the result points at the fix rather than at the tooling.

9.6 Forbidden methods

Password spraying and DoS remain forbidden at NMT.

The forbidden list also covers fare-network probes and anything that is not on an approved method card. Sam's card library prints that list on its cover, and the cover is read aloud at kickoff so every peer hears the same limits before the first check runs. A method that is missing from the library is not a grey area to be argued in the window; it is out of scope until a new card is reviewed and agreed.

9.7 Card library

Method cards live in a team library with owners. Copying a card without reading its stop conditions is a common newcomer mistake Sam watches for. The library lives in the runbook repository with an owner and a review date on every card. A card without a review in twelve months is retired to the archive before it can enter ENG-512, and Sam will not run stale cards on ENG-512 hosts. A retired card returns only after its owner re-checks the tool version, rate and stop conditions against the current ROE.

9.8 Noise budget

If a method would generate more alerts than the SOC agreed to handle, Sam reduces the rate or reschedules; detection partners are not punching bags. The noise budget agreed with the SOC caps how many auth failures ENG-512 may generate, and it is written as a number on the kickoff sheet. Crossing it is a stop condition, treated as discipline rather than weakness, not a badge of thoroughness. When the budget is tight, Sam spreads the auth cards across two windows instead of compressing them into one.

9.9 Field discipline

Method cards are useless if they disagree with the ROE. Sam's review step is to highlight the ROE clause each card relies on; if he cannot highlight a clause, the card is rewritten or dropped. This habit also educates newcomers: they see that "we always run tool X" is not a reason, while "ROE clause 4.2 allows authenticated GET/POST to staging API at ≤1 rps" is a reason. Field discipline for methods is cards, rates, pins, the forbidden list and the noise budget, and Sam will not add a clever check mid-window without a written card and notice to the SOC.

Worked example (synthetic NMT)

Sam's card for IDOR on saved journeys: WSTG-AUTHZ, curl with two test users, rate 1 req/s, stop if HTTP 5xx rate >1%, evidence = request ids + responses redacted.

Synthetic case — Northline Municipal Transit (NMT). The transit agency, Sam Park and all figures are invented for teaching.

Errors and limits

Live transit systems and fare equipment are never tested without a separate, specialised authorization. This book uses synthetic data only and grants no authority to test real systems.

Exercises

EX033 — Card fields. List five method-card fields. Rubric: 3 = five from chapter; 2 = three; 1 = one; 0 = none.
EX034 — Rate limit reason. Why set rate limits on staging? Rubric: 3 = avoid crash/lockout/log storm; 2 = partial; 1 = go faster; 0 = none.
EX035 — Selectivity. Why not run every WSTG check in one window? Rubric: 3 = time/quality; focus on high-risk themes; 2 = partial; 1 = always all; 0 = none.
EX036 — Forbidden. Name two forbidden methods at NMT. Rubric: 3 = password spraying and DoS; 2 = one; 1 = vague; 0 = none.

Synthesis

Method cards bind purpose, ROE, rate limits and evidence — and keep forbidden methods out.

Continue studying — chapter 09 of 18

← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →