OSC: Vulnerability Discovery and Analysis

This domain tests whether you can move from raw enumeration output to a specific, validated weakness, and explain why it is exploitable here. The exam cares less about naming a CVE and more about proving the precondition exists on this host, at this version, with these permissions.

Core rules

• Verify, do not assume. A banner reading Apache/2.4.49 is a hypothesis; request /.%2e/.%2e/.%2e/.%2e/etc/passwd and confirm the contents before writing path traversal as confirmed.
• Map each discovered service to its attack surface: web (LFI/RFI, upload, SSTI, SQLi, deserialization, default credentials), SMB (signing, null sessions, MS17-010), FTP (anonymous and write access), SNMP, LDAP, MSSQL xp_cmdshell, NFS.
• Read PoC code before running it. Identify what it writes, where it connects, and which version strings it checks.
• Expect to adapt: hardcoded paths, Python 2 syntax, missing dependencies, a different install directory, or an offset that must be recalculated.
• Prefer the least destructive proof. id beats a reverse shell; reading one file beats a full dump.

Worked example

Enumeration shows a web app at /app/, version 2.3, and a changelog mentioning fixed file-upload validation in 2.4. You test the upload endpoint: shell.php is rejected, but shell.php.jpg is accepted and later executed as PHP. Reasoning: the check validates only the final extension while the web server maps by the first extension; the version diff plus the behavioral test confirms the weakness. That yields a low-privilege web shell.

Traps that cost marks

Trusting version-to-CVE matching without a test; running an unread exploit that drops a service or reboots the box; missing that an exploit needs credentials you already hold; ignoring 32-bit versus 64-bit architecture; and reporting a CVE with no evidence line behind it.