WIP - not final! For comments only.
Description
The midterm challenges are the practical counterpart of the theoretical test. You are given a set of vulnerable machines and applications running on a dedicated platform, and a fixed amount of supervised class time in which to break them. Afterwards you write up what you did.
The session is individual. Unlike the other assignments in this course, this one is an assessment of what you can do on your own, with your own hands on the keyboard. The flags you obtain are your evidence of work; the writeup is your evidence of understanding, and it is the part that carries most of the detail of the grade.
The challenges cover the topics lectured up to that point: reconnaissance and information leakage, vulnerability assessment and enumeration, injection (SQL and command), broken authentication and session handling, and cross-site scripting. They are not CTF trivia and none of them depends on a trick you have to guess: each one yields to methodical enumeration, an understanding of how the flaw works, and enough patience to follow the trail. Tooling is expected, including automated tools, but a tool that you cannot explain will not earn you much in the writeup.
Learning outcomes
After completing this assignment you should be able to:
- Enumerate a target methodically and decide where to look next, rather than running tools blindly and reading whatever comes out.
- Recognise the class of a vulnerability from its symptoms, and confirm it with a minimal test instead of a lucky payload.
- Use the standard tooling of the field, including its configuration, and explain what a given tool actually did on your behalf.
- Document an attack so that a third party can repeat it from your notes alone, and state what the underlying flaw is and how it should be fixed.
Format
| Item | Value |
|---|---|
| Modality | Individual, supervised, in class |
| Platform | CTF environment provided by staff, one isolated instance per student |
| Session | One 3 hour session, in the class slot |
| Challenges | Around ten, across five categories, of increasing difficulty |
| Scoring | Flags obtained in the session, plus the writeup delivered afterwards |
The instance assigned to you is yours alone for the duration. Flags are generated per student, so a flag copied from a colleague will not validate on your instance.
What you must do
1. During the session
Solve as much as you can within the time available. Work systematically: enumerate, record what you tried, and keep notes as you go, because the writeup is built from them and memory is not reliable after three hours.
Notes taken during the session may be carried into the writeup, but they must be your own work, made during the session. Anything brought in from outside falls under the rules below.
2. The writeup
Deliver a writeup covering every challenge you attempted, solved or not. For each one:
- The category and the vulnerability class you believe you were dealing with, named by CWE where applicable.
- How you got there: the enumeration that found the entry point, the tests that confirmed the flaw, and the reasoning that connected them. A list of tool invocations with no reasoning is the weakest thing you can hand in.
- The exploitation path, with the exact requests or commands that mattered, and enough evidence (responses, output, screenshots) that the claim is not merely asserted.
- The impact you actually reached on that instance.
- The fix: what change to the application would remove the flaw, and why. Where you could see the vulnerable behaviour but not the code, argue the fix from behaviour.
- What you would do next, for the challenges you did not finish.
3. The one you did not solve
Write up at least one challenge that you did not solve. Say what you observed, what you ruled out, what you would have tried with more time, and where you got stuck. This is graded on its own merit: an honest, well-argued analysis of a failure is worth meaningfully more than a solved challenge that you cannot explain.
Deliverables
| Deliverable | Format | Notes |
|---|---|---|
| Flags | Submitted through the platform | During the session only |
| Writeup | PDF, one PDF per student | Due after the session, see the timeline |
Suggested structure for the writeup: a short introduction stating your score and how long you spent on each category, then one section per challenge in the order you attempted them, then a closing section on what you would do with another three hours.
Rules
Individual work
This assignment is individual. Discussion, sharing of flags, hints, notes or tool output with other students, before or after the session and before the writeup deadline, is prohibited. Helping someone else through a challenge is a violation on the same footing as giving away a flag.
Tools and external material
Tools are allowed and expected: browsers, proxies such as Burp or ZAP, nmap, curl, Python, database clients, and dedicated exploit helpers. Automated tools such as sqlmap are allowed; you must state which ones you used and what they did, because the writeup is graded on your understanding, not on the tool’s output.
The following are not allowed: generative AI assistants and LLM-based tooling of any kind, solution walkthroughs or writeups of the same challenges found online, remote help from another person, and any material brought into the session other than your own notes and the course notes.
Rules of engagement
Attack only your own instance. Probing, scanning or interfering with other students' instances, the platform hosting them, or the network they sit on is a serious offence and will be handled as such. No denial of service attempts, no brute forcing of the platform itself, and no attempts to read other students’ flags.
Verification
The platform keeps logs of every instance. Staff read them, and they are compared with what you claim in the writeup. Claims that do not match the logs are treated as fabrication. Two writeups that are substantially similar are treated jointly, and so is a writeup that describes a solution far better than the session activity supports.
Grading
| Criterion | Weight | Excellent | Insufficient |
|---|---|---|---|
| Challenges solved in the session | 45% | A good spread across categories, including at least one of the harder ones | Only the easiest category, or points obtained with no idea why they worked |
| Writeup: reasoning and evidence | 30% | Third party can reproduce it from the writeup alone; flaw class named and argued; evidence attached | Tool invocations with no reasoning, no evidence, or reconstructed guesswork |
| Impact, fix and defensive view | 15% | Impact stated precisely, fix plausible and specific to the flaw | No fix, or a generic “validate your inputs” paragraph |
| Analysis of an unsolved challenge | 10% | Clear account of what was ruled out and what would come next | Absent, or hand-waving |
The challenges are deliberately over-supplied relative to the time available: you are not expected to solve everything. Marks for the solved-challenges criterion saturate before everyone finishes, so spending twenty minutes stuck on one challenge while an easy one sits unsolved is a poor trade. Partial progress on a challenge pays off if it is documented: a documented half-solution is worth more than an unsolved one, and less than a solved one.
Timeline
| Milestone | Date | Notes |
|---|---|---|
| Practice environment opens | November 6th | Sample challenges from previous editions, for training only, not graded |
| Supervised session | November 20th | 3 hours, in class, individual |
| Writeup due | November 27th | PDF, individual |
If you miss the session for a justified reason, tell staff before it takes place: an alternative slot may be arranged. Without notice, the session is failed.
Common pitfalls
- Running every tool you know at the target and reading the output as if it were understanding. Enumerate with a question in mind.
- Brute forcing where a few minutes of reading the responses would have given the answer, and then having nothing to write about.
- A writeup that says “I ran sqlmap and it dumped the database”. Say what the injection point was, why it was injectable, and how the data came out.
- No evidence. Unannotated screenshots of a tool’s output prove nothing; keep the specific requests and the specific responses that mattered.
- Leaving the fix section to the end and filling it with generic advice.
- Underestimating how much of the grade sits in the writeup. A strong session with a thin writeup is a mediocre grade, and a moderate session with an excellent writeup is a good one.
- Spending the last hour on the hardest challenge because it is the one still open.
FAQ
Is this a group assignment? No. It is individual, and the other assignments in this course are group work. Do not plan to collaborate on this one.
Can I use sqlmap, Burp or nmap? Yes, including fully automated tools. Name them in the writeup and explain what they did. Automating a step you cannot explain earns less than doing it by hand and being able to say why.
Can I use an AI assistant? No. This is an individual test and AI use is not permitted in it. The course allows AI in other assignments; this one does not.
What if I solve very little? Write the writeup well. Reasoned partial progress and an honest account of a challenge you could not finish are graded, and they carry real weight. Silence does not.
Are the challenges new? They are written for this course and cover the topics lectured so far. The practice environment uses challenges from previous editions, which are fair game to train on.
Will there be binary exploitation challenges? Not in the midterm session. The session covers the material lectured up to that date. Memory corruption appears later in the semester and is examined in the theoretical tests.