Chapter 2 — Authorized offensive security and red team: advanced seminar
Lesson map
Lesson 02 published. Map, example, EX008.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Seminar practice"]
N2["2.2 ATT&CK vocabulary"]
N3["2.3 Findings without payloads"]
N4["2.4 Threat-led vs checklist"]
N5["2.5 Feedback craft"]
N6["2.5b Comparing frameworks in one slide"]
N7["2.5c Reading a framework critically"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX008"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Seminar practice"]
N2["2.2 ATT&CK vocabulary"]
N3["2.3 Findings without payloads"]
N4["2.4 Threat-led vs checklist"]
N5["2.5 Feedback craft"]
N6["2.5b Comparing frameworks in one slide"]
N7["2.5c Reading a framework critically"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX008"]
[Learning outcomes]
|
v
[2.1 Seminar practice]
|
v
[2.2 ATT&CK vocabulary]
|
v
[2.3 Findings without payloads]
|
v
[2.4 Threat-led vs checklist]
|
v
[2.5 Feedback craft]
|
v
[2.5b Comparing frameworks in one slide]
|
v
[2.5c Reading a framework critically]
|
v
[Worked example] --> [Exercise EX008]
Learning outcomes
You will (1) present and critique methodology papers and frameworks; (2) use ATT&CK as a shared vocabulary; (3) prioritise synthetic findings without exploit detail; (4) debate threat-led vs checklist testing; and (5) give structured peer feedback.
2.1 Seminar practice
Each week one student presents a framework or paper: claim, evidence, what a master's study could reuse. Peers file written feedback: major issue, minor issue, question.
Written feedback keeps the discussion on the work rather than on the presenter. When Noah presents ATT&CK tagging as a reporting intervention, the major issue his peers raise is that tagging quality may vary. That comment later becomes his tag audit. Keep each week's feedback in the research log, with the action you took in response.
2.2 ATT&CK vocabulary
Label planned and observed techniques. Coverage is communication, not proof of safety.
ATT&CK technique IDs give testers and defenders shared names for behaviour, such as T1046 Network Service Discovery or T1078 Valid Accounts. In the coverage lab, five of seven planned techniques were observed, or 71%. That figure says what the assessment exercised, not what risk remains. Planned techniques that were not seen go on the next authorized plan rather than being tested freelance. Use one pinned ATT&CK version for all labels, so tags stay comparable throughout the study.
2.3 Findings without payloads
Practice writing findings as title, affected asset, evidence reference, impact, likelihood, recommendation — never as exploit recipes.
The findings lab scores each synthetic finding as impact times four, plus exploitability times two, plus exposure. SYN-001, a default admin password on the staging web UI, scores 20 and is critical; SYN-002, missing headers on the public site, scores 9 and is medium. Neither entry says how to exploit anything. A remediator needs the asset, evidence reference and fix, not the attack. SYN-005, a lab service account with domain admin rights, scores 17 and is also critical.
2.4 Threat-led vs checklist
TIBER-EU and CBEST emphasise intelligence-led scenarios for critical financial services. PTES and WSTG support structured technical coverage. A dissertation should say which logic it uses.
Noah's study uses the structured logic: synthetic findings from training assessments on CBM segments, recorded in tickets. It borrows no threat-intelligence phase, so its results say nothing about intelligence-led tests of live financial services. Stating this early stops readers from assuming the comparison applies to TIBER-EU or CBEST engagements, and it shapes the limitations chapter.
2.5 Feedback craft
Major issues change conclusions; minor issues polish. Cite evidence when you disagree.
"""ATT&CK-style coverage matrix over synthetic authorized techniques (names only)."""
# Synthetic engagement log: technique_id -> observed (True/False)
PLAN = ["T1046", "T1595", "T1082", "T1083", "T1059", "T1078", "T1021"]
OBSERVED = {"T1046", "T1595", "T1082", "T1083", "T1078"}
LABELS = {
"T1046": "Network Service Discovery",
"T1595": "Active Scanning",
"T1082": "System Information Discovery",
"T1083": "File and Directory Discovery",
"T1059": "Command and Scripting Interpreter",
"T1078": "Valid Accounts",
"T1021": "Remote Services",
}
covered = 0
for tid in PLAN:
hit = tid in OBSERVED
covered += hit
print(f"{tid} {LABELS[tid]:34} {'COVERED' if hit else 'PLANNED-NOT-SEEN'}")
print(f"coverage={covered}/{len(PLAN)} ({100*covered/len(PLAN):.0f}%)")
Expected output:
T1046 Network Service Discovery COVERED
T1595 Active Scanning COVERED
T1082 System Information Discovery COVERED
T1083 File and Directory Discovery COVERED
T1059 Command and Scripting Interpreter PLANNED-NOT-SEEN
T1078 Valid Accounts COVERED
T1021 Remote Services PLANNED-NOT-SEEN
coverage=5/7 (71%)
"""Score synthetic findings for report priority (no exploit details)."""
# impact 0-3, exploitability 0-3, exposure 0-3 -> priority
findings = [
("SYN-001", "default admin password on staging web UI", 3, 3, 2),
("SYN-002", "missing security headers on public site", 1, 1, 3),
("SYN-003", "outdated TLS on internal admin port", 2, 2, 1),
("SYN-004", "verbose error messages disclose paths", 1, 2, 2),
("SYN-005", "service account with domain admin in lab AD", 3, 2, 1),
]
def priority(impact, exploitability, exposure):
score = impact*4 + exploitability*2 + exposure
if score >= 16: return "critical", score
if score >= 11: return "high", score
if score >= 7: return "medium", score
return "low", score
for fid, title, i, e, x in findings:
p, s = priority(i, e, x)
print(f"{fid} priority={p:8} score={s:2} impact={i} exploitability={e} exposure={x} :: {title}")
Expected output:
SYN-001 priority=critical score=20 impact=3 exploitability=3 exposure=2 :: default admin password on staging web UI
SYN-002 priority=medium score= 9 impact=1 exploitability=1 exposure=3 :: missing security headers on public site
SYN-003 priority=high score=13 impact=2 exploitability=2 exposure=1 :: outdated TLS on internal admin port
SYN-004 priority=medium score=10 impact=1 exploitability=2 exposure=2 :: verbose error messages disclose paths
SYN-005 priority=critical score=17 impact=3 exploitability=2 exposure=1 :: service account with domain admin in lab AD
A useful major comment on Noah's idea is that tag quality is unmeasured; a useful minor comment is that the ATT&CK version should be named. Both are specific and actionable. Feedback that only praises gives the presenter nothing to fix. When you disagree, point to the source, the data or the lab output that supports your view. Separate major from minor clearly, so the presenter knows which comments must be answered before the design is fixed.
2.5b Comparing frameworks in one slide
A useful seminar slide has three columns: question the framework answers, artefact it expects (ROE, scenario, test case), and a failure mode (checkbox theatre, intel theatre, coverage theatre). Students leave knowing when not to force-fit a framework.
For example, ATT&CK answers what an adversary might do, expects technique-level observations, and fails when coverage percentages are read as safety. Keep each column to one line. Draw the same three columns for PTES, WSTG, TIBER-EU and CBEST. Noah's slide shows that his study fits PTES and WSTG logic best, and says plainly where ATT&CK cannot name a process flaw.
2.5c Reading a framework critically
Each framework embeds an assumption you should test before citing it in a dissertation. PTES assumes a client who can state business impact before testing starts; at Cedar Bridge Mutual the claims team could not, so Noah's scoping meeting produced a list of crown-jewel processes (claim intake, payout approval) rather than hosts. ATT&CK assumes behaviour can be named at technique granularity; a finding about a missing approval step in payouts has no technique, and forcing one (T1078, Valid Accounts) would hide the process flaw. TIBER-EU assumes a regulator-led threat-intelligence phase; a mid-sized insurer outside that regime borrows its structure but must say so. Write each assumption as one sentence in your methods chapter and state whether it held in your setting.
2.6 Worked example (synthetic CBM case)
Noah presents ATT&CK tagging as a reporting intervention. Peers note that tagging quality may vary. The coverage lab shows 71% of a planned set observed; the findings lab ranks SYN-001 critical without describing an exploit path.
The peer comment about tag quality changes the design: Noah plans a tag audit against ATT&CK definitions. The coverage figure of 71% is reported as what the assessment exercised. SYN-001 is ranked critical with a score of 20, and the report entry gives its asset, evidence reference and fix, with no exploit path.
2.7 Errors and limits
- Seminars that demo attacks.
- Feedback that only praises.
- Treating coverage % as residual risk.
Each error damages the seminar. Attack demonstrations spread dual-use detail and break the course boundary. Feedback that only praises leaves weak designs unchallenged until examiners find the problems. Reading coverage as residual risk turns a description of what was exercised into a false claim of safety, the error the coverage lab warns about. Check your seminar plan and feedback for all three. A reviewer outside the seminar can spot them quickly.
Exercises
- EX008 — Present — Outline a 10-minute seminar on PTES. Rubric: 3 = claim, phases, limits, reuse; 2 = three; 1 = one; 0 = none.
- EX009 — Coverage — Interpret planned-not-seen rows ethically. Rubric: 3 = next authorized work, not freelancing; 2 = partial; 1 = attack now; 0 = none.
- EX010 — Finding — Rewrite SYN-005 as a report entry (no exploit steps). Rubric: 3 = asset, impact, evidence ref, recommendation; 2 = three; 1 = steps; 0 = none.
- EX011 — Threat-led — When is CBEST-style testing more appropriate than a checklist web test? Rubric: 3 = critical services, intel-led, oversight; 2 = two; 1 = one; 0 = none.
- EX012 — Feedback — Write one major and one minor comment on Noah's idea. Rubric: 3 = both specific; 2 = one; 1 = vague; 0 = none.
- EX013 — WSTG — What does WSTG add that ATT&CK does not? Rubric: 3 = web test cases/procedures for authorized web apps; 2 = partial; 1 = vague; 0 = wrong.
- EX014 — Dual-use — Why ban exploit demos in seminar? Rubric: 3 = dual-use, ethics, course boundary; 2 = two; 1 = one; 0 = none.
Synthesis
Seminar and literature habits turn red-team practice into researchable questions with ethical boundaries.
Continue studying — chapter 02 of 08
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →