SocksOverRDP Pivoting (double hop over RDP)

Cuando el pivote solo nos deja llegar al siguiente segmento por RDP (por ejemplo, una red Windows sin SSH), podemos tunelizar tráfico arbitrario dentro de la propia sesión de Escritorio remoto. SocksOverRDP usa los Dynamic Virtual Channels (DVC) de RDP, el mismo mecanismo que transporta el portapapeles o el audio, para abrir un proxy SOCKS sobre el canal cifrado de RDP. Así encadenamos saltos (nuestro host, un primer servidor, y desde este un tercero) sin subir un túnel propio ni abrir puertos nuevos: todo viaja como si fuera RDP legítimo.

Mecanismo

En el primer host (al que llegamos por RDP) se registra el plugin del cliente con regsvr32.exe. A partir de ahí, cada nueva sesión RDP saliente ofrecerá un listener SOCKS local en 127.0.0.1:1080:

regsvr32.exe SocksOverRDP-Plugin.dll

Desde ese primer host abrimos una sesión RDP con mstsc.exe hacia el segundo host y, ya dentro, ejecutamos el servidor con privilegios de administrador para levantar el canal:

SocksOverRDP-Server.exe

De vuelta en el primer host, confirmamos que el listener SOCKS ya escucha:

netstat -antb | findstr 1080

TCP    127.0.0.1:1080         0.0.0.0:0              LISTENING

Para que nuestras herramientas usen ese SOCKS, se enruta el tráfico a 127.0.0.1:1080 con Proxifier (proxy SOCKS para clientes gráficos de Windows como mstsc.exe) o, si operamos desde Linux con el puerto reexpuesto, con proxychains apuntando al SOCKS del pivote:

# /etc/proxychains.conf en el atacante (SOCKS del primer pivote)
socks5 <pivot-ip> 1080

Un truco habitual es reexponer el 1080 local del pivote con netsh para alcanzarlo desde fuera:

netsh interface portproxy add v4tov4 listenport=1080 listenaddress=0.0.0.0 connectport=1080 connectaddress=127.0.0.1

Requisitos

Acceso RDP válido al primer host, permiso para registrar la DLL (regsvr32 no exige administrador para HKCU, pero el SocksOverRDP-Server.exe en el destino sí se ejecuta como administrador) y que el Escritorio remoto esté disponible en la cadena. Al tratarse de binarios de terceros, conviene subirlos con las herramientas del propio sistema y contar con que un EDR pueda detectarlos.

Cómo detectarlo. El patrón delata: la carga de una DLL desconocida con regsvr32.exe seguida de un proceso SocksOverRDP-Server o Proxifier, y sobre todo sesiones RDP encadenadas de servidor a servidor (un servidor que inicia RDP saliente hacia otro es anómalo). En red, RDP legítimo no debería transportar volúmenes de tráfico propios de un proxy. Vigilar además reglas nuevas de netsh interface portproxy y listeners locales en 1080.

Defensa. Restringir RDP con el cortafuegos y con Restricted Admin; limitar los DVC que no se necesiten por directiva; no permitir RDP servidor a servidor salvo salto administrativo controlado; y monitorizar regsvr32 cargando DLL fuera de rutas del sistema. Es primo del pivoting con Chisel, del reenvío nativo con netsh y del pivoting con Ligolo-ng, y se apoya en el acceso por RDP del primer salto.