How this lab works
This is your hands-on practice space for the whole CSC2203 syllabus — all ten weeks of the official course outline, from Week 1 foundations through Week 10 risk & review. Weeks 1–4 rebuild what you've already been taught as something you do instead of read: classify a real-feeling incident, run a flood attack against a capacity meter, break a weak cipher, watch a hash avalanche, run RSA by hand. Weeks 5–10 are a structured first look ahead — built from the course textbooks — at authentication & access control, Kerberos & PKI, secure protocols, email/app-layer security & firewalls, intrusion detection, and risk & vulnerability assessment, so you arrive at each of those lectures already having met the core ideas once.
Each module has two parts. The regular cards are Practice — sandboxes and tools with instant feedback, ungraded, as many tries as you like. Near the end of each module is a gold-bordered Assessed Challenge — personalised to you, worth 10 of your 100 final marks. Answer every question, then click "Check my score" — nothing is marked right or wrong while you're still answering. Your score appears along with which ones you got right and wrong, and you can try again with a freshly reshuffled set of questions as many times as you like; your best attempt is what counts toward your final mark. Use the practice tools first to work out the mechanics, then apply what you learned in the assessed challenge.
What each module covers
| Module | Week | You will | Assessed marks |
|---|---|---|---|
| 1 · Foundations | Wk 1 | Classify CIA violations, the threat chain, and authentication vs. authorization | 10 |
| 2 · Network Attacks | Wk 2 | Identify malware, run a DoS-vs-DDoS simulator, spot spoofing/recon, scan a mock host, trace NAT | 10 |
| 3 · Symmetric Crypto | Wk 3 | Calculate key spaces; run an XOR cipher; break a reused key | 10 |
| 4 · Hashing & Public-Key | Wk 4 | Trigger the avalanche effect; watch ECB vs. CBC; run RSA by hand | 10 |
| 5 · Authentication & Access Control | Wk 5 | Compute password entropy; tell MAC from DAC and RBAC from ABAC | 10 |
| 6 · Kerberos & PKI | Wk 6 | Step through an AS/TGS ticket exchange; trace a certificate chain of trust | 10 |
| 7 · Secure Protocols | Wk 7 | Step through a TLS handshake; compare IPsec AH vs ESP | 10 |
| 8 · Email, App Security & Firewalls | Wk 8 | Test firewall rules against simulated packets; match OWASP Top 10 categories | 10 |
| 9 · Intrusion Detection & Monitoring | Wk 9 | Triage a mock alert stream; tell signature- from anomaly-based detection | 10 |
| 10 · Risk, Assessment & Review | Wk 10 | Score a risk matrix; diagnose an incident that ties the whole course together | 10 |
| Total | 100 | ||
Weeks 5–10 are enrichment/preview material built from the course textbooks ahead of those lectures — if something you meet here differs from how your lecturer later presents it in class, the lecture takes precedence.
Module 1 — CIA, threats, and the Asset→Control chain
For each incident below, work out (a) which CIA objective was hit hardest, (b) whether it's a passive or active attack, and (c) where the vulnerability actually sits. Submit means recording your reasoning in the worksheet — use these as practice first.
Authentication vs. authorization — the most confused pair in the course
Authentication proves who you are. Authorization decides what you're allowed to do once you're recognised. Both can succeed, both can fail, or one can succeed while the other fails — that last case is the one people mix up.
Your personalised incidents
New incidents, different from the practice ones above. Answer all of them, then check your score — you'll see what's right and wrong and can try again with a fresh set.
Written task (for your worksheet)
Pick one of the five incidents above and walk it through the full Asset → Threat → Vulnerability → Attack → Risk → Control chain from Week 1, in your own words. Draft it here — this text stays in your browser only, so copy it into your worksheet when you're happy with it.
Module 2 — Malware, DoS/DDoS, spoofing, reconnaissance & NAT
Everything here is simulated against a fake, harmless target — no real scanning, flooding or spoofing tool is used or should ever be pointed at a system you don't own. The goal is to see the shape of each attack clearly enough that you'd recognise it in a log file.
Malware taxonomy — name that nasty
Different malware families are grouped by how they spread and what they do, not by how dangerous they sound.
DoS vs. DDoS — simulated botnet takedown
A botmaster commands a botnet — a network of previously-compromised devices, often recruited through phishing or an unpatched vulnerability — to flood a target at once. Watch what an undefended target looks like below, then switch to the defender's seat and see what mitigation actually does. Every "bot" and "target" here is a fictional icon on this page; nothing controls a real device.
Spoofing & reconnaissance
Two attacker moves that usually happen before the main attack: forging where traffic appears to come from, and quietly mapping what's reachable.
Reconnaissance in practice — scan a mock host
This is a fabricated host that exists only on this page. Click a port to "probe" it the way a reconnaissance scan would, one port at a time.
NAT — watch the translation table fill in
A NAT box maps ⟨internal IP, internal port⟩ to ⟨external IP, external port⟩ so many private-network machines can share a small number of public addresses. Add a few simulated connections and watch the table build.
| Internal host | Internal ⟨IP:port⟩ | NAT-assigned external ⟨IP:port⟩ | Destination |
|---|
Notice every row leaves through the same external IP, distinguished only by port — this is exactly why a single public IP address can serve an entire office or campus.
Malware, attack reasoning & your personal NAT calculation
The NAT question uses numbers assigned to you — work it out the same way you just did in the demo above.
Module 3 — Key spaces, XOR, and why key reuse breaks everything
Feel the difference between a 56-bit key and a 128-bit key, then reuse an XOR key badly on purpose so you can see exactly what an attacker gets for free when you do.
Brute-force key-space calculator
Computational difficulty is the whole point of a key-length choice. Compare DES's 56-bit key against AES-128 and AES-256.
Watch a weak key actually get brute-forced
The calculator above tells you how long a brute force would take. Here's one actually happening: an 8-bit XOR key (just 256 possibilities) being tried one at a time against a captured ciphertext, using a known-plaintext assumption — exactly how many real key-recovery attacks work.
XOR cipher — encrypt, decrypt, then break your own reused key
First confirm XOR is symmetric (the same operation encrypts and decrypts). Then reuse the same key on two different messages — a genuine "two-time pad" mistake — and see what leaks with no key-cracking at all.
Your personalised key space & XOR ciphertext
The XOR field below is pre-filled into the practice tool above with your assigned plaintext and key — click "Encrypt & decrypt" up there, then copy the ciphertext hex down here.
Module 4 — Avalanche effect, ECB vs CBC, RSA, and signatures
Four exercises, each rebuilding a slide from Week 4 as something you operate yourself instead of watch.
SHA-256 avalanche sandbox
Hash a string, flip one character, hash it again. A secure hash should change roughly half its output bits — with no visible relationship to what changed.
Plain hash vs. HMAC — which one can an attacker forge?
A message ships with an integrity value. An attacker who can read the wire tampers with the message. Can they still produce a value that looks valid — without knowing the secret key?
ECB vs. CBC — watch the pattern leak
Both use the same simplified teaching cipher (an XOR-based substitution — not real AES, so the arithmetic stays checkable by hand). The plaintext below is deliberately repetitive, like a bitmap image or a form with fixed fields. Encrypt it block-by-block under ECB, then under CBC, and compare.
Plaintext (identical shapes repeat on purpose)
ECB ciphertext — every identical plaintext block still looks identical
CBC ciphertext — each block is XORed with the previous ciphertext block first
RSA sandbox — generate keys, encrypt, decrypt, sign, verify
Real RSA uses primes hundreds of digits long; we use tiny primes here so every step is checkable by hand, exactly like the worked example from lecture.
Your personalised RSA keys, plus HMAC & ECB/CBC reasoning
The RSA sandbox above has been pre-set to your assigned prime pair, message M and hash-value H. Generate the keypair, run encrypt/decrypt and sign/verify up there, then transcribe n, C and S down here.
Module 5 — Proving who you are, and deciding what you can do
Two separate problems: authentication (proving identity — something you know/have/are) and access control (once identity is established, what you're permitted to do). This module previews both ahead of lecture.
Password entropy calculator
Entropy in bits ≈ length × log₂(character-set size). A larger, more varied character set and more characters both push an attacker's expected guessing time up exponentially — this is the same "computational difficulty" idea from Week 3's key-space calculator, applied to passwords instead of keys.
Access control models — quick check
Four models, four very different rulebooks for "who can do what."
Your personalised entropy calculation & access-control scenario
The entropy question uses a length and character set assigned to you — work it out the same way as the practice tool above.
Module 6 — Trusted third parties: tickets and certificates
Two ways a network lets strangers trust each other without sharing a secret in advance: a ticket-granting service (Kerberos) and a chain of digital signatures (PKI) — reusing the public-key mechanics from Week 4.
Kerberos — step through the ticket exchange
Click through each step of a simplified Kerberos login. Every message after the first is encrypted with a key the attacker never sees in the clear.
PKI & chain of trust — quick check
A certificate is a public key, signed by someone you already trust — chained back to a root CA you trust by default.
Kerberos & PKI check
Module 7 — Wrapping traffic: IPsec, TLS, SSH
Same underlying crypto toolkit from Weeks 3–4, wired into real network protocols at different layers.
TLS handshake — step through it
Click through the stages a browser and server go through before the padlock appears.
Watch a man-in-the-middle attack — then watch TLS stop it
Alice needs to send Bob a funds-transfer instruction. Mallory has positioned herself on the path between them — a rogue Wi-Fi access point, or ARP/DNS spoofing on the local network — so every packet passes through her first. Step through what happens on a plaintext channel, then switch to an encrypted + signed channel (what TLS actually gives you) and watch the same attack fail.
IPsec AH vs ESP, and SSH — quick check
Secure protocols check
Module 8 — Securing the edge: email, applications, and the perimeter
PGP reuses Week 4's signatures and encryption directly; firewalls decide what's even allowed to reach your application in the first place.
Firewall rule tester
A simple ordered ACL. Rules are checked top to bottom; the first match wins. Try a few source/destination/port combinations.
| # | Action | Source | Dest port |
|---|
Phishing — see it happen, then take it apart
You're a student checking your inbox. One of these messages is a phishing attempt built to look like it's from IT Support. Open it, follow it through the way a busy, trusting user would, and watch what an attacker sees the moment credentials are typed — then pull the email apart and find every red flag. Simulation only — nothing typed here is sent anywhere.
PGP, OWASP Top 10 & DMZ — quick check
Email/app security & firewalls check
Module 9 — Watching the network: IDS, IPS & SIEM
Detection is a different discipline from prevention — and knowing which detection method is watching changes what it will, and won't, catch.
Alert triage — signature or anomaly?
For each log line, decide whether a signature-based IDS (matches known attack patterns) or an anomaly-based IDS (flags deviation from a learned baseline) is the one that would catch it — or both, or neither.
NIDS vs HIDS, IDS vs IPS, SIEM — quick check
Detection & monitoring check
Module 10 — Risk, assessment, and the whole course at once
Risk management ties everything together: every control you've met since Week 1 exists to push risk down. This closing module scores a risk matrix, then finishes with the course-wide capstone scenario your written report is built on.
Risk-matrix calculator
Risk is commonly scored as Likelihood × Impact on a simple 1–5 scale each. This is exactly the kind of prioritisation a vulnerability assessment report hands to management.
Vulnerability assessment vs. penetration testing — quick check
Course-wide capstone: Incident at Mutare TechBank
This is the scenario your written report (see the assignment brief) is built on. Read it once straight through, then use the four prompts below to draft your analysis — one prompt per early-semester week's toolkit.
Mutare TechBank runs an online banking portal for retail customers. On a Tuesday morning, the SOC receives three unrelated-looking alerts within twenty minutes: (1) a spike in failed logins from a narrow range of IP addresses, followed by a handful of successful logins from those same addresses using previously unused, oddly consistent passwords; (2) a customer complaint that a funds-transfer confirmation email they never requested arrived, referencing a transfer they didn't make, for an amount their statement doesn't yet show; (3) a junior developer notices that the bank's mobile app is still encrypting locally-cached transaction receipts one fixed-size block at a time with the same key and no chaining — and when they view the encrypted cache file as an image, they can still make out the shape of the receipt template underneath the "encryption."
Risk scoring & capstone diagnostic check
Your written report (submitted separately, per the assignment brief) is graded by your lecturer — this automatic check covers precise diagnosis only.
Results & certificate
Your full-syllabus progress, and — once every module is submitted — your certificate of completion.
Complete and submit all ten assessed challenges to unlock your certificate. Progress: 0/10 submitted.
Verify a certificate
Enter the Student ID and Certificate ID exactly as they appear on a certificate. This looks the record up on the server that issued it — the same check anyone can run from the public verify page linked on the certificate itself, without needing to open this lab.