ADV-101 Instructor Guide

For instructors running ADV-101. The course is the academy's CVE-to-tool capstone; this guide adds pacing context, common stumbling blocks, the authorization-document process, and the capstone defense logistics.

Course shape at a glance

Cohort pacing recommendations

• Self-paced (one student): 13 calendar weeks is tight. Plan for 14-15 weeks in practice; capstone polish slips for most students.
• Classroom (5-12 students): 13 weeks. The capstone defense block needs a 3-hour cohort session at end of Week 13; schedule a 4-hour block for safety (defenses run long).
• Bootcamp (full-time, ~3.5 weeks): 125 hours fits in 18 working days at 7 hours/day. Aggressive but doable for OSCP-prep cohorts. The midterm and capstone defense need fixed dates; do not let bootcamp time pressure compress them.
• Night class (working-adult cadence): 2 evenings + Saturday lab. 13 calendar weeks. The capstone defense is a single Saturday session; schedule early.

The authorization process (lecturer's responsibility)

The cyber-use authorization document is the central instructor responsibility for ADV-101. Process:

1. Week 1, day 1. Distribute the authorization document text (a one-page agreement covering lab target, scope, negative scope, duration, personal conduct boundaries). Walk through it in lecture. Students who refuse to sign are dropped from the cohort; this is a hard line.

2. Week 3. Lab 3 is the isolated lab network build-out. The lab requires the signed authorization on file before the student touches the SB6141 management interface. Students sign at the start of Lab 3; instructor counter-signs after verifying the isolated-network setup.

3. Per-session authorization line. Every lab session (Week 4 onward) starts with the student writing a single line in their lab notebook: "Authorized session: {date}, target SB6141 unit {serial}, scope per signed cohort authorization." Instructor spot-checks during lab.

4. End of Week 13. Authorization closes at capstone defense. The document is filed with the cohort records.

The discipline is the discipline. A student who has not signed cannot proceed past Week 3. A student whose lab notebook lacks per-session authorization lines cannot earn full credit on the affected lab.

Per-week pacing notes and common stumbling blocks

Week 1: Foundations

Pacing: Lecture is dense (authorization framing + CVE record reading + adversarial posture). Lab is light (annotate a CVE record on paper).

Common blocks:

• Students who completed RE-101 are eager to start "doing offensive stuff." Reframe: Week 1 is the foundation that prevents Week 2's lab from becoming a felony. Authorization is the dividing line.
• The Longenecker CVE record itself is short; some students treat the annotation lab as filler. It is not; the annotation surfaces what the CVE record OMITS, which becomes the pattern for reading every CVE record going forward.

What to watch: students who skip the authorization framing usually struggle in Lab 3 (network isolation) because they have not internalized "the rules exist for technical reasons, not bureaucratic ones."

Week 2: HTTP at the wire level; CSRF mechanics

Pacing: This is the first lab where students touch the SB6141. Plan 3 hours for Lab 2; many students need 4.

Common blocks:

• Burp's CA certificate needs to be installed in the Burp-bundled browser for HTTPS interception. The SB6141 admin interface is HTTP (not HTTPS), so this does not block ADV-101 Lab 2, but the muscle memory matters for capstone work.
• Students who never used curl -v before are surprised by the verbosity. Walk through one full request/response in lecture; the rest is repetition.
• The CSRF mechanic is "browser auto-attaches cookies to same-origin requests; an attacker rides this for cross-origin form posts." Some students confuse it with session-hijacking or XSS. The Stuttard + Pinto chapter is the answer; assign it as required reading before Week 2's lecture.

What to watch: the Lab 2 transcript should show the student manually reproducing the CSRF with curl, not with a one-line python -c '...' shortcut. The manual reproduction is the point.

Week 3: Isolated lab networks; authorization basis

Pacing: Lab 3 is two sessions. Session 1: build the isolated network and verify isolation. Session 2: document authorization (network diagram + per-session log template + scope-limit document).

Common blocks:

• Students with Wi-Fi-only laptops sometimes try to skip the wired isolation. Do not allow it; the Lab 3 deliverable requires a verified-isolated network.
• The "scope-limit document" feels like paperwork; some students treat it as filler. Reframe: this is the document the academy points to in any post-incident review. It is the student's professional defense.

Week 4: Python requests, argparse, logging, exit codes (Tool v0.1)

Pacing: First tool-engineering lab. Plan 4 hours for students without FND-102 muscle memory; 2.5 for students who shipped FND-102 recently.

Common blocks:

• Tool v0.1's job is to FINGERPRINT the target (HTTP probe to 192.168.100.1/; expect-specific-string in response) and REFUSE to act if the response does not match. Some students skip the refuse-to-act path because it is "obvious." The refusal IS the safety property; the tool must demonstrate it.
• argparse returns strings; students forget to type-convert (int(), float()) and chase type bugs. Coach: argparse type= parameter does the conversion at parse time.
• Exit codes (0 success, 1 error, 2 usage error) are convention; students who skip them lose points in the rubric.

Week 5: Tool safety engineering I (Tool v0.2, authz + dry-run)

Pacing: The lecture is the heart of the course. Walk through --authorized-by and --dry-run as design patterns, with the lecture's worked example mirroring Lab 5 exactly.

Common blocks:

• "Why a --dry-run flag? Won't users just skip it?" The dry-run prints what the tool WOULD do without actually doing it; it lets the operator verify the target and the action before commitment. The verification step IS the safety property. Students who treat dry-run as optional or off-by-default miss the point.
• --authorized-by as a REQUIRED flag (not optional): the argparse pattern is parser.add_argument('--authorized-by', required=True, help='name of authorizing party'). Without it, the tool refuses to start. This safety control is non-optional.

What to watch: Lab 5's submission should fail gracefully when run without --authorized-by; if it succeeds (silent default or hidden override), the safety property is violated.

Week 6: Midterm

Pacing: 3-hour proctored practical. Different CVE, different target (academy-controlled VM or container). Students reproduce the CVE manually within the 3-hour window.

Sample midterm specs (rotate per cohort; the actual exam is one of these or a close variant):

• Apache Tomcat 8.0.x default-credentials exposure. The student receives an academy-provided VM running Tomcat with default Tomcat Manager credentials; reproduces unauthorized administrative access via curl; documents the exact request.
• Joomla 1.5 SQLi. Academy-provided container with vulnerable Joomla install; reproduces SQLi via curl; documents the injection point.
• DVWA file-upload bypass. Academy-provided container; reproduces the upload bypass; documents the bypass technique.

Grading: Correctness (60%) + reproduction transcript clarity (20%) + authorization line in the exam notebook (20%). Students who skip the authorization line lose 20% even on perfect reproduction.

Time budget within the exam: ~30 min spec read + scoping + ~90 min reproduction + ~60 min documentation.

Week 7: Tool safety engineering II (Tool v0.3, logs + idempotency)

Pacing: The most code-intensive lab. Plan 4-5 hours.

Common blocks:

• "Idempotent semantics" is jargon students stumble on. Operational definition: running the tool twice has the same effect as running it once. For a CSRF exploit, idempotency means re-running the tool on an already-exploited target detects the existing state and reports "already done" rather than crashing or double-applying.
• Structured logs: JSON output to one file; human-readable summary to stderr. Students who emit only one format lose flexibility downstream (CI consumers want JSON; humans want the summary).
• Rollback: for a state-changing tool, the rollback is "undo what we did." For an SB6141 CSRF, rollback is "restore the configuration we changed." Some CVEs do not have a meaningful rollback; in those cases, the tool documents the irreversibility explicitly in its run-log.

Week 8: CVSS v3.1 + impact scoring

Pacing: Lecture-heavy week. Walk through the CVSS calculator at https://www.first.org/cvss/calculator/3.1 live; show the student a vector string they can copy into the calculator and verify.

Common blocks:

• "Scope Changed" is the metric students misread most often. Walk through the canonical example (a guest-VM escape to host-VM is "scope changed"; in-guest privilege escalation is not).
• Students score the SB6141 CSRF and want to inflate the score. Reality check: the CSRF requires the victim to be logged in, the attacker to host a cross-origin page, and the victim to visit it within the session window. The honest score is in the 6-7 range, not 9+.

Week 9: Coordinated vulnerability disclosure

Pacing: Lecture covers the CERT/CC + ISO/IEC 29147 framework. Lab 9 is the disclosure-report draft.

Common blocks:

• "Why disclose if the vendor is end-of-life?" The honest answer: defensive guidance for affected users matters even when the vendor is gone. The SB6141 is end-of-life; the disclosure still helps cable operators decide to remove the device from their pools.
• The negative-scope section is the section students skip first. It is the section that protects the researcher; it MUST be present.

Week 10: Professional ethics; CFAA; DMCA §1201

Pacing: Lecture is dense with case law. Spend time on three or four concrete cases (Aaron Swartz; Marcus Hutchins; Citizen Lab v. NSO; a recent state-law variation).

Common blocks:

• Students underestimate how broadly CFAA can apply. The "exceeds authorized access" clause is the trap; walk through the Van Buren ruling (2021) to show the Supreme Court's narrowing but also the residual ambiguity.
• DMCA §1201 (anti-circumvention) is the section that makes RE work itself potentially actionable. The triennial DMCA exemptions for security research (granted 2015 onward) are the safety valve; students should know they exist and how to claim them.

Week 11: Capstone workshop

Pacing: Lab is 1-on-1 scope-check meetings. 30 minutes per student.

Common blocks:

• Students bring v0.3 tools that are not yet v1.0 packages. The workshop's job is to identify the gap (missing pyproject.toml, missing LICENSE, missing CHANGELOG, missing tests) and let the student close it in week 12.
• The disclosure report draft is usually weak on the negative-scope and remediation sections; instructors should flag these specifically.

Weeks 12-13: Capstone build + defense

Pacing: No lecture. The student is on their own with instructor office hours.

The defense panel. Three reviewers: the ADV-101 instructor; one academy alumnus (RE-101 or ADV-101 graduate, ideally currently in vuln-research role); one external practitioner (sponsor, industry contact, or guest reviewer). Defense is 20 minutes per student: 8 min student presentation + 12 min Q&A.

Common defense stumbles:

• "What if the SB6141 wasn't end-of-life?" The student should answer with the CVD timeline they would have followed.
• "Could your tool be misused?" The honest answer: yes, but the safety controls (authz, dry-run, fingerprinting) make misuse require deliberate effort. The discipline lives in the code AND in the documentation.
• "What would you do if a vendor refused to acknowledge your disclosure?" The student should know the academy's published-after-180-days fallback per Lab 9.

Grading framework

Lab grading (1-5, 7-11):

• Correctness (50%): the lab artifact does what the spec says
• Safety hygiene (25%): authorization line in lab notebook; argparse --authorized-by present where required; --dry-run works where required
• Documentation (15%): lab notebook entries are sentences, not telegrams; key decisions explained
• Reflection (10%): the lab's reflection prompts answered substantively

Midterm (Week 6):

• Correctness (60%)
• Reproduction transcript clarity (20%)
• Authorization line (20%; binary; missing = lose 20%)

Capstone:

A capstone where the tool runs but the report is weak fails. A capstone where the report is strong but the tool lacks --authorized-by fails. Both legs must be solid.

Forward-pointer cross-references

When teaching, note these connections to downstream paths:

• OSCP preparation. ADV-101 + PEN-101 is the explicit OSCP-prep sequence. Students intending to sit the OSCP should plan ~3-6 months of OffSec PEN-200 self-study after ADV-101 ships.
• Industry vulnerability-research roles. The capstone deliverable shape IS the practitioner deliverable shape. Resume language: "shipped CERT/CC-grade disclosure report and tool for SB6141 CSRF" reads well in vuln-research job applications.
• ADV-102 (LLM-CVE variant; roadmap). Same shape applied to a different attack surface. Yaworski's Real-World Bug Hunting is the bridge reading.
• Bug bounty work. ADV-101 graduates are typically ready to begin disclosed-disclosure bug-bounty programs (HackerOne, Bugcrowd) on authorized programs only.

What to do if a student is stuck

The course's hardest weeks for most students are Week 5 (tool safety I; design discipline) and Week 9 (CVD drafting; new register of writing). Three rescue tactics:

1. Worked example. Walk through the instructor's reference Tool v0.2 line by line, showing how --authorized-by integrates and what the dry-run output looks like. Most students unblock from seeing a working example.
2. Pair-review. Sit next to the student during the lab. Read the student's lab notebook out loud; the student catches half their own errors that way.
3. Read the source. For the CVD draft (Lab 9), open the CERT/CC website and read one published advisory. Students see the shape and write to it.

A student who reaches Week 7 without an authorization signature on file should not proceed; back-fill Week 1's framing before continuing.

Pilot-cohort notes (to be appended after first run)

Empty in v0.1; populate after the first cohort completes the course.

Instructor guide v0.1.