VCA-ADV-101 — Adversarial Techniques: CVE-to-Tool
The direct follow-on to VCA-RE-101. Students take a published CVE for the course’s primary target (the Motorola/ARRIS SURFboard SB6141), reproduce the vulnerability manually, then convert their manual reproduction into a responsible, authorization-gated testing tool that a professional analyst could legitimately hand to a client engagement. The course is not “how to hack modems.” It is “how a security researcher, acting under authorization, turns a disclosed weakness into an auditable proof artifact.”
Why This Vulnerability
Primary teaching CVE — unauthenticated CSRF on the SB6141 admin interface. The device exposes an administrative web interface requiring no authentication from the cable-side LAN. A crafted HTTP request — even one originating from the victim’s own browser visiting an attacker-controlled page — can trigger administrative actions including reboot and factory reset. David Longenecker disclosed this in 2016; ARRIS acknowledged; ISPs eventually pushed a firmware update. Lab-owned units still run pre-patch firmware, making them suitable authorized teaching targets.
Chosen because: pedagogical simplicity (reproducible with curl in one lab session),
real-world register (named researcher, disclosure timeline, vendor response), ethical clarity
(lab-owned isolated target), tool-engineering surface (authorization gating, logging, rollback,
safe-defaults all matter), and continuity with the RE-101 target device.
Learning Outcomes
- Read a CVE record end-to-end and identify what a reproducing researcher would need.
- Establish an isolated, authorized test network for vulnerability validation on a lab-owned target.
- Manually reproduce a disclosed vulnerability and articulate preconditions and effects.
- Convert a manual reproduction into a reusable Python tool that requires explicit authorization input, logs every action, fails safe, and produces an auditable run artifact.
- Engineer the tool with appropriate safety engineering — authorization gates, scope limits, dry-run mode, idempotent operation, user-visible logging, and destructive-action confirmation.
- Produce a coordinated-disclosure-ready report under CERT/CC CVD practice (ISO/IEC 29147).
- Identify the legal and ethical boundaries of adversarial testing under U.S. law (CFAA, DMCA §1201, state computer-crime statutes).
- Defend the tool orally in a simulated client-briefing setting.
Weekly Schedule
| Week | Topic | Laboratory |
|---|---|---|
| 1 | Foundations — adversarial posture, authorization as the dividing line, CVE records as professional literature | Read and annotate the SB6141 Longenecker CVE; reproduce nothing yet |
| 2 | HTTP at the wire level; CSRF mechanics | Reproduce the CSRF manually with curl on the lab SB6141 |
| 3 | Isolated lab networks; authorization basis for this target | Build the isolated lab network; document authorization |
| 4 | Python requests, argparse, logging, exit codes | Tool v0.1 — fingerprint only (is this an SB6141?) |
| 5 | Tool safety engineering I — authorization gates, dry-run, destructive-action confirmations | Tool v0.2 — adds --authorized-by flag and dry-run |
| 6 | Midterm practical — reproduce a different CVE manually on a different authorized target | Proctored 3-hour exam |
| 7 | Tool safety engineering II — logging, auditable artifacts, rollback, idempotency | Tool v0.3 — adds run-log output and validation |
| 8 | CVSS and impact scoring | Score the chosen CVE and justify the score |
| 9 | Coordinated vulnerability disclosure — CERT/CC, ISO/IEC 29147 | Draft the disclosure report for a hypothetical novel finding |
| 10 | Professional ethics; CFAA; DMCA §1201; state law variation; SDVOSB engagement rules | Write a 2-page personal ethics statement |
| 11 | Capstone defense preparation; report and tool review | Submission and peer review |
Capstone — Tool + Disclosure-Ready Report
The tool must:
- Fingerprint the target and refuse to run if the target isn’t what it expects
- Require an explicit
--authorized-byargument naming a lawful authorization source - Support
--dry-runmode that demonstrates intent without taking effect - Produce a structured log artifact (JSON + human-readable) of every action
- Require explicit user confirmation before any destructive or persistence-altering action
- Pass an instructor-provided test suite on the lab target
- Ship as a proper Python package with README, LICENSE, and CHANGELOG
The report must:
- Describe the vulnerability at the level of a CERT/CC disclosure document
- Document reproduction steps sufficient for an independent engineer to repeat
- Score the impact via CVSS v3.1 with per-metric justification
- Recommend remediation and, separately, mitigation
- Include an explicit negative-scope “what this tool does not do” section
Ethics Framework (Embedded Throughout)
The course operates under an explicit discipline: the tool exists to test lab-owned targets under written authorization, and only such targets. Codified in three artifacts each student signs:
- Course AUP — scope restrictions, signed Week 1.
- Per-session authorization log — each lab begins with a one-line written authorization statement.
- The tool’s own code — the
--authorized-byflag is not decorative. A tool that can run without it fails the capstone.
Required Hardware & Software
- Same as VCA-RE-101 — student’s own SB6141 (lab-owned), laptop or lab Pi, and an isolated network switch or dedicated VLAN. No new purchases.
- The same
fwlabcontainer as RE-101, augmented withrequests,pytest, andscapy. - Burp Suite Community Edition for Week 2 HTTP inspection.
Certification Alignment
OSCP Prep
Long-term preparation for OffSec OSCP (available post-18). Graduates who pursue OSCP after the course are generally ready for the OffSec PEN-200 self-study path within 3–6 months.
Interested in VCA-ADV-101?
Email academy@virtuscybersecurity.com with your register and why.