Exploit Vulnerabilities

Overview

This room moves from identifying vulnerabilities to actually researching and exploiting them. It compares automated and manual vulnerability research, introduces practical exploit sources, and walks through a simple remote code execution workflow using a public exploit.

1) Automated vs Manual Vulnerability Research

Automated scanners are useful for speed and coverage, but they are not a replacement for manual testing.

• Advantages: repeatable, quick, team-friendly reporting, and broad coverage.
• Disadvantages: noisy traffic, operator over-reliance, incomplete findings, and limited usefulness in basic open-source editions.

Manual research is slower but gives the tester better control, better context, and better judgment about what is actually exploitable.

2) Common Vulnerability Types

The room highlights several categories you should expect to encounter during assessments:

• Security misconfigurations: unsafe settings or exposed internals.
• Broken access control: reaching functionality or data you should not have.
• Insecure deserialization: unsafe processing of attacker-controlled serialized data.
• Injection: malicious input being interpreted as commands or queries.

3) Finding Manual Exploits

After identifying a likely vulnerability, the next step is exploit research. The room focuses on three useful sources:

• Rapid7: vulnerability intelligence plus Metasploit-oriented exploit guidance at rapid7.com/db.
• GitHub: strong for fresh PoCs and niche exploits, but quality varies and verification is limited.
• Searchsploit: local offline access to Exploit-DB entries from Kali or AttackBox.

4) Searchsploit

searchsploit is often the fastest way to check whether a known application or version already has public exploit material.

• Works offline because it mirrors Exploit-DB locally.
• Search by product name, version, or vulnerability type.
• Useful when you already identified software during reconnaissance.

5) Example Manual Exploitation Workflow

The practical goal in the room is to use a public exploit to achieve remote code execution and gain a foothold.

1. Identify a vulnerable service from earlier research.
2. Locate a public exploit for that specific issue.
3. Read the exploit instead of assuming it will work as-is.
4. Modify any required variables such as local IP, port, or target URL.
5. Run a harmless command first, such as whoami, to verify code execution.
6. Use the exploit to retrieve useful files or continue post-exploitation.

6) Adapting Public Exploits

A public exploit usually needs changes before it works in your environment.

• Update attacker IPs and ports.
• Confirm the required command-line arguments.
• Check whether the exploit expects a specific target path or software version.
• Read the code enough to understand what it uploads, executes, or triggers.

The room demonstrates editing variables like mymachine before running the exploit.

7) Verifying RCE Safely

When testing remote code execution, start with low-risk commands that prove execution without changing much on the target.

• whoami confirms the execution context.
• cat flag.txt demonstrates file-read capability in the room scenario.
• Only move to more advanced payloads once you have validated the exploit path.

Exam Notes (PT1)

• Automated scanners are useful, but they are noisy and incomplete.
• Manual exploit research commonly uses Rapid7, GitHub, Exploit-DB, and searchsploit.
• Public exploits often require edits before use, especially IPs, ports, and target-specific values.
• Read the exploit usage instructions and source before running it.
• Validate RCE with a harmless command first, then pivot to higher-value actions like reading files or gaining a foothold.