GUÍA DE SEGURIDAD OFENSIVA PARA TÚNELES SSH Y PROXIES

Esta publicación pretende ser una ventanilla única para todas las cosas que un analista de seguridad ofensiva desearía saber sobre el uso de túneles Secure Shell (SSH) y proxies SOCKS. La información proporcionada aquí no es nueva, pero pretende ser un documento de referencia que se pueda utilizar durante las operaciones.

Traducido de: SPECTEROPS

Conceptos básicos de Secure Shell (SSH)

SSH es un protocolo que permite a un usuario conectarse de forma remota a un host y, por lo general, proporciona un shell interactivo o símbolo del sistema que se puede aprovechar para ejecutar comandos. La mayoría de los servidores basados ​​en Linux tienen un servidor SSH instalado y tanto Windows como Linux tienen un cliente SSH incorporado. El cliente / servidor SSH más común es la implementación de OpenSSH y es la aplicación utilizada para todas las referencias en esta publicación.

Cortafuegos

Debido a que SSH facilita el control remoto de un host, el servidor SSH siempre debe configurarse con reglas de firewall que incluyan la conexión de un host específico en la lista blanca. Esto es especialmente cierto si se puede acceder desde Internet al servidor SSH. Sería un fracaso significativo si la infraestructura de operaciones ofensivas se comprometiera o incluso fuera accesible para los adversarios.

Autenticación

Las conexiones SSH se pueden establecer con solo un nombre de usuario y contraseña para la autenticación. Además, SSH permite a los usuarios crear un par de claves pública y privada que posteriormente se pueden utilizar en lugar de una contraseña. Estas claves ofrecen un cifrado asimétrico configurable fuerte. Los usuarios deben asegurar el acceso a su clave privada generada como si fuera un secreto. La clave pública generada se agrega al archivo de claves autorizadas SSH del host de destino.

Al igual que una contraseña, si un atacante recupera una clave privada, puede utilizarse para acceder al servidor. Debido a esto, las claves SSH deben estar encriptadas con una contraseña que actúa como un segundo factor. La utilidad ssh-keygen se puede utilizar para crear un par de claves RSA de 4096 bits con la sentencia:

ssh-keygen -t rsa -b 4096

De forma predeterminada, esto generará una clave privada denominada id_rsa y un archivo de clave pública denominado id_rsa.pub. Asegúrese de ingresar una contraseña cuando se le solicite que cifre la clave. Los permisos del archivo de clave privada deben restringirse para que solo el usuario, y nadie más, pueda leer el archivo. Si los permisos del archivo permiten que otros usuarios lo lean, el cliente SSH ignorará el archivo de identidad y mostrará un error. En un host Linux, los permisos deben ser "600" para que el usuario pueda leer y escribir el archivo, pero no se permite el acceso al grupo ni a otros usuarios.

Cada sección principal de esta publicación se basará en la sección anterior y también dividirá los comandos en partes numeradas en un intento de aumentar la comprensión. Se presentará una imagen visual después de cada conjunto de comandos para ilustrar la conectividad de la red y para identificar en qué hosts se deben ejecutar los comandos. Para empezar, LINUX1 representa la estación de trabajo Linux de un analista y REDIR1 representa un host accesible a Internet que forma parte de la infraestructura de la operación ofensiva.

La siguiente imagen ilustra el uso de una clave privada SSH para conectarse a un servidor SSH en el host REDIR1 como el usuario rastley del LINUX1:

1. Utilice el cliente SSH en LINUX1
2. Utilice el archivo de identidad, la clave privada del usuario en /root/priv.key
3. Establezca una conexión SSH a REDIR1 e inicie sesión como rastley

Esta imagen ilustra el establecimiento de una conexión SSH de LINUX1 a REDIR1

Túnel de reenvío de puerto remoto

OBJETIVO: Conectarse a un puerto en un host comprometido en la red del cliente desde un redirector.

Supongamos que durante una evaluación, un analista compromete un host, llamado PWNED1, que está ejecutando un servidor SSH. El analista ahora quiere conectarse vía SSH en el host comprometido directamente desde Internet. Una opción es crear un túnel SSH directo de puerto remoto, también conocido como túnel inverso, desde PWNED1 hasta el servidor del analista accesible a Internet, REDIR1. Una vez que el túnel está configurado, el analista obtiene conexión SSH directamente en el host comprometido desde el redirector.

Desde el host comprometido, use la bandera -R para construir un túnel SSH de reenvío de puerto remoto. Esta bandera toma un argumento de [bind_address:]port:host:hostport. El bind_address es la interfaz de la dirección IP de ese túnel, debe unirse a, o escuchar sobre, por el host remoto. El bind_address no se debe confundir con la dirección del servidor SSH que conecta el cliente SSH para la autentificación. El valor predeterminado de OpenSSH es utilizar la dirección IP del adaptador de bucle invertido del host, 127.0.0.1. Si desea utilizar una IP de interfaz diferente, la opción GatewayPorts debe estar habilitada en el archivo /etc/ssh/sshd_config del servidor SSH. Cuando esta opción está habilitada y bind_address está vacío (0.0.0.0 o *), entonces se vinculará a TODAS las interfaces. Esto presenta un problema porque ahora cualquier persona en Internet podría conectarse al túnel porque estaría escuchando en una interfaz con una dirección IP pública y, posteriormente, llegaría al host interno comprometido. Si las opciones de GatewayPorts NO están habilitadas y bind_address está en blanco, el túnel solo se vinculará al adaptador de bucle invertido. Por esta razón, se recomienda que los analistas siempre especifiquen explícitamente bind_address en lugar de asumir la configuración del servidor SSH.

El nombre "localhost" normalmente se refiere al adaptador de bucle invertido del host; sin embargo, también podría hacer referencia a cualquier dirección IP arbitraria modificando el archivo /etc/hosts. Por esta razón, se recomienda que los analistas siempre usen explícitamente la dirección IP de la interfaz 127.0.0.1, en lugar de un nombre DNS que se supone que se resuelve en el adaptador de bucle invertido.

El argumento port especifica el puerto por el cual el túnel se conectará a la bind_address en la interfaz del servidor remoto. Este puerto debe estar libre y la cuenta de usuario debe tener los permisos adecuados para conectarse a un puerto privilegiado, cualquiera que sea menor que 1024.

El argumento host es la interfaz a la que se enlazará el túnel en el host de origen donde se ejecuta el comando y desde donde se inicia la conexión. Se aplican las mismas reglas que antes, lo mejor es especificar explícitamente el adaptador de bucle invertido con 127.0.0.1.

El último argumento, hostport, es el puerto en el host de origen al que el túnel enviará tráfico. El puerto de host debe hacer referencia a un servicio en el host de origen al que un analista desea conectarse a través del túnel. Debido a que queremos llegar al servidor SSH en el host de origen, se debe usar el puerto 22.

Este comando construirá un túnel de reenvío de puertos SSH que envía tráfico desde el host remoto al host de origen. La bandera -R del cliente SSH determina la dirección en la que fluye el tráfico a través del túnel en relación con el lugar donde se ejecutó el comando. El comando se ejecutará en el host de origen, PWNED1, por lo que el tráfico fluirá desde el host remoto REDIR1 al host de origen PWNED1.

1. Utilice el cliente SSH en PWNED1
2. Cree un túnel de reenvío de puertos desde el host remoto, REDIR1, al host de origen, PWNED1
3. En el host remoto, REDIR1, escuche en bind_address, 127.0.0.1, en el puerto 2222
4. Reenvíe la conexión desde el host remoto, REDIR1, al servicio SSH que ya se está escuchando en el host de origen, PWNED1, adaptador host loopback 127.0.0.1 en hostport 22
5. El cliente SSH debe conectarse a REDIR1 e iniciar sesión como rastley

Una vez que se ha establecido un túnel SSH entre el host comprometido y el host de Internet, un analista ahora puede usarlo para conectarse al servidor SSH en el host de origen, PWNED1. Desde REDIR1, para enlazar el puerto 2222, el tráfico se enviará a través del túnel al hostport en el servidor host. El analista debe proporcionar un nombre de usuario y una contraseña válidos para el host comprometido, PWNED1.

1. Utilice el cliente SSH en REDIR1
2. Establezca una conexión SSH al puerto 2222
3. El cliente SSH debe conectarse al adaptador loopback (127.0.0.1), que se reenvía a través del túnel SSH creado previamente a PWNED1, e iniciar sesión como el usuario hpotter, una cuenta de usuario válida en PWNED1.

Esta imagen visualiza el establecimiento de un túnel SSH de reenvío de puerto remoto entre REDIR1 y PWNED1, y luego el inicio de una nueva sesión SSH a través del túnel de REDIR1 a PWNED1.

Aplicaciones web

OBJETIVO: conectarse a una aplicación web en el host comprometido en la red del cliente desde un redirector.

Los túneles de reenvío de puertos remotos se pueden usar para conectarse a cualquier servicio que escuche en el host de origen. Un ejemplo podría ser conectarse a una escucha de aplicaciones web en PWNED1 por el puerto 8443. Esto podría ser algo así como un escáner de vulnerabilidad o controlador de la máquina virtual. Este comando crea un túnel de reenvío de puertos para acceder a una aplicación web que escucha en PWNED1.

1. Utilice el cliente SSH en PWNED1
2. Cree un túnel de reenvío de puertos desde el host remoto, REDIR1, al host de origen, PWNED1
3. En el host remoto, REDIR1, escuche en bind_address, 127.0.0.1, en el puerto 443
4. Reenvíe la conexión desde el host remoto al servidor web que ya está a la escucha de la fuente, PWNED1, adaptador host loopback 127.0.0.1 hostport 8443
5. El cliente SSH debe conectarse a REDIR1 e iniciar sesión como rastley

Para usar el túnel, abra un navegador web en REDIR1 y navegue hasta https://127.0.0.1:443. El tráfico se reenviará a través del túnel a la aplicación web que escucha en PWNED1 en el puerto 8443.

Argumentos opcionales del cliente SSH

Hay algunos argumentos opcionales del cliente SSH que son útiles al crear túneles. Cuando el comando de túnel de reenvío de puerto remoto de la sección anterior se ejecutó en PWNED1, dejó un indicador de terminal SSH interactivo en REDIR1. Cualquiera con acceso a PWNED1 ahora podría emitir comandos a REDIR1, dependiendo del contexto de ejecución del comando. La bandera -N elimina la capacidad de ejecutar comandos en el host remoto. Cuando la bandera -N se usa, se establece una conexión SSH pero el analista no tendrá un mensaje para ingresar o ejecutar comandos. La bandera -T evita que se asigne una pseudo-terminal para la conexión; sin embargo, los comandos aún podrían emitirse si solo se usara la bandera -T. La mejor forma de evitar la ejecución remota de comandos es utilizar juntas las banderas -N y -T.

En la mayoría de los casos, un analista no necesita interactuar con un túnel una vez que está configurado. Para evitar que el túnel bloquee el uso continuo de la terminal actual, use la bandera -f. Esta bandera bifurca el proceso del cliente SSH en segundo plano justo después de la autenticación.

1. Utilice el cliente SSH en PWNED1
2. Utilice los siguientes argumentos SSH
• f => Bifurque este proceso de cliente SSH en segundo plano después de la autenticación
• N => Sin ejecución de comandos en el host remoto
• T => No asigne una pseudo-Terminal en el host remoto
• R => Cree un túnel de reenvío de puerto remoto desde el host remoto al host de origen
3. En el host remoto, REDIR1, escuche en bind_address, 127.0.0.1, en el puerto 443
4. Reenvíe la conexión desde el host remoto al servidor web que ya está a la escucha de la fuente, PWNED1, adaptador host loopback  127.0.0.1, hostport 8443
5. El cliente SSH debe conectarse a REDIR1 e iniciar sesión como rastley

Proxy de SOCKS

OBJETIVO: Herramientas y tráfico proxy desde un host Linux a la red del cliente.

Acceder a un solo servicio que escucha en un objetivo comprometido es bueno, pero sería mejor si los operadores pudieran llegar a cualquier host en toda la red interna del cliente. SSH convenientemente tiene incorporado un modo de actuar como un servidor SOCKS a través de su función “Dynamic” de reenvío de puerto a nivel de aplicación. SOCKS versión 5 es un protocolo que actúa como una puerta de enlace y transmite de forma transparente el tráfico de red hacia y desde su puerto de escucha. Esto se usa comúnmente para eludir las restricciones de la red. El tráfico parece provenir del host donde está escuchando el servidor SOCKS y no muestra la dirección IP del host que inició la solicitud. Para crear un servidor proxy SOCKS de escucha, use el argumento del puerto SSH -D [bind_address:].

1. Utilice el cliente SSH en PWNED1
2. Crea un puerto Dynamic, un servidor SOCKS
3. El servidor SOCKS escuchará en el bind_address 127.0.0.1 puerto 9052
4. El cliente SSH debe conectarse a sí mismo (PWNED1) , a través del adaptador loopback, e iniciar sesión como hpotter

Una vez que el servidor SOCKS está escuchando, debe ser accesible por un analista para que sus herramientas puedan usarse para llegar a las redes de destino internas. Cree un túnel de reenvío de puerto remoto SSH para que el servidor SOCKS en PWNED1 esté disponible a través de REDIR1.

1. Utilice el cliente SSH en PWNED1
2. Cree un túnel de reenvío de puertos desde el host remoto, REDIR1, al host de origen, PWNED1
3. En el host remoto, REDIR1, escuche en bind_address, 127.0.0.1, en el puerto 9051
4. Reenvíe la conexión desde el host remoto al servicio SOCKS que ya se está escuchando en la fuente, PWNED1, adaptador host loopback 127.0.0.1 hostport 9052
5. El cliente SSH debe conectarse a REDIR1 e iniciar sesión como rastley

Un programa, aplicación o herramienta de seguridad ofensiva debe tener soporte explícito para que un proxy lo utilice de forma nativa. Algunas herramientas como Firefox y Burp Suite tienen una opción para configurar un proxy. Sin embargo, hay muchas herramientas que no tienen soporte de proxy explícito.

Proxychains-ng es una herramienta que se puede utilizar para enviar tráfico TCP desde cualquier programa arbitrario a un proxy SOCKS. No es compatible con ICMP o UDP. Una vez que se haya instalado proxychains, edite el archivo /etc/proxychains4.conf para que la última línea del archivo de configuración apunte a la interfaz y al puerto donde está escuchando el servidor SOCKS. En nuestro ejemplo, la última línea sería el siguiente:

socks4 127.0.0.1 9051.

Con las cadenas de proxy configuradas, un analista podría ejecutar un programa arbitrario y enviar su tráfico TCP a la red interna del cliente. Si un analista quisiera usar Nmap y hacer un escaneo de puerto TCP para el puerto 445, prefijaría su comando normal con "proxychains". Específicamente para Nmap, la configuración proxy_dns de proxychains debe estar deshabilitada. Debido a que proxychains no admite UDP o ICMP, se deben utilizar los tipos de exploración Nmap TCP SYN y connect. Un comando de ejemplo de Nmap que usa cadenas de proxy se ve así:

proxychains nmap -sT -p 445 192.168.1.10

Reenvío dinámico inverso de puerto

OBJETIVO: Herramientas y tráfico proxy desde un host Linux a la red del cliente en un solo comando ssh.

OpenSSH versión 7.6 introdujo una nueva característica denominada "reenvío dinámico inverso" que aprovecha la sintaxis extendida para el argumento -R. Esta función permite a un operador crear un servicio de escucha SOCKS5 en un host remoto con un solo comando. El ejemplo anterior en la sección Reenvío de puerto remoto requería dos comandos SSH; uno con el argumento -D para crear el servicio SOCKS5 y un segundo comando con el argumento -R para conectarlo con un túnel. Esta función está habilitada en el lado del cliente y, por lo tanto, no es necesario configurarla en el servidor. La documentación de SSH dice:

Si no se especificó un destino explícito, ssh actuará como un proxy SOCKS 4/5 y reenviará las conexiones a los destinos solicitados por el cliente SOCKS remoto.

La sintaxis de extensión para el argumento SSH -R es [bind_address:] port.

1. Utilice el cliente SSH en PWNED1
2. Cree un túnel de reenvío de puertos dinámico desde el host remoto, REDIR1, al host de origen, PWNED1
3. En el host remoto, REDIR1, cree un servicio SOCKS que esté escuchando en bind_address, 127.0.0.1, en el puerto 9051
4. El cliente SSH debe conectarse a REDIR1 e iniciar sesión como rastley

DNS

OBJETIVO: Configurar la estación de trabajo privada de un analista para resolver nombres de host mientras se usa un proxy

De forma predeterminada, ni las cadenas de proxy ni el protocolo SOCKS4 admiten solicitudes de DNS. Una solución alternativa es agregar una entrada para el nombre de host de destino en el archivo /etc/hosts donde se usa proxychains. Esto permitirá que el sistema operativo busque la dirección IP del host de destino localmente, antes de que se envíe a través del túnel. Sin embargo, los protocolos SOCKS4a y SOCKS5 son capaces de manejar solicitudes de DNS y no requieren una entrada en el archivo /etc/hosts. Para habilitar el soporte de DNS para las cadenas de proxy, edite el archivo de configuración, /etc/proxychains4.conf, y des-comente la línea "proxy_dns":

# Proxy DNS requests — no leak for DNS data

proxy_dns

Para habilitar el soporte de DNS transparente para algunas herramientas de Linux, se debe identificar un servidor DNS en la red de destino interna para enviar las solicitudes de DNS. Exporte la variable de entorno "PROXYRESOLV_DNS" con un valor del servidor DNS interno como:

export PROXYRESOLVE_DNS=192.168.1.1

Túnel de reenvío del puerto local

OBJETIVO: Reenviar el tráfico desde la estación de trabajo privada de un analista a un servidor proxy SOCKS.

Es posible que un analista no desee ejecutar herramientas desde un host accesible a Internet como REDIR1. Un escenario más probable es utilizar una máquina virtual (VM), LINUX1, de la propia red interna del analista. Para hacer esto, use la misma configuración de antes para crear un proxy SSH SOCKS y un túnel de reenvío de puerto remoto. Es necesario crear un túnel adicional desde la VM del analista, LINUX1 hasta el redirector, REDIR1.

Utilice SSH -L [bind_address:] port: host: hostport para configurar un túnel y reenviar el tráfico desde la VM local del analista, LINUX1, al redirector, REDIR1. Esto crea un túnel de reenvío de puerto local desde LINUX1 a REDIR1. Este comando es como usar la bandera -R, pero la principal diferencia es la dirección en la que fluye el tráfico a través del túnel. La bandera -L envía tráfico desde el host de origen al host remoto, donde la bandera -R envía tráfico desde el host remoto al host de origen. La fuente se determina en función de dónde se ejecuta el comando SSH.

1. Utilice el cliente SSH en LINUX1
2. Cree un túnel de reenvío de puerto local desde el host de origen, LINUX1, al host remoto, REDIR1
3. En el host local, LINUX1, escuche en bind_address, 127.0.0.1, en el puerto 9050
4. Reenviar la conexión desde el host local al puerto que ya está escuchando en el host remoto, REDIR1, adaptador host loopback 127.0.0.1 hostport 9051
5. El cliente SSH debe conectarse a REDIR1 e iniciar sesión como rastley

Una vez que el túnel se ha configurado desde LINUX1, el analista puede volver a usar cadenas de proxy en su VM para ejecutar herramientas. Actualice el archivo de configuración de proxychains en /etc/proxychains4.conf  para usar el túnel SOCKS5 accesible en el puerto 9050 (por ejemplo, socks5 127.0.0.1 9050). El tráfico de esas herramientas se enrutará de LINUX1 a REDIR1, y luego de REDIR1 a PWNED1 y, finalmente, de PWNED1 al host de destino en la red interna del cliente.

Navegador web

OBJETIVO: Configurar el navegador web de un analista para usar un proxy SOCKS.

Los analistas también pueden utilizar otros programas que tienen soporte de proxy SOCKS integrado, como Firefox, para acceder a aplicaciones web en la red de un cliente. El host que ejecuta el navegador web debe estar configurado con un túnel de escucha a un proxy SOCKS como se documenta en la sección anterior. Para configurar Firefox para usar el proxy SOCKS en LINUX1, abra el menú Configuración de conexión de red y configúrelo para usar el puerto de escucha en 9050. Una vez configurado Firefox, todo el tráfico se enviará a los hosts de la red interna. No olvide que el DNS no funcionará a través de un túnel SOCKS4. Los analistas pueden comunicarse con un host por su dirección IP interna o crear una entrada en el archivo /etc/hosts.

Suite Burp

OBJETIVO: Configurar Burp Suite para usar cadenas de proxy y un proxy SOCKS.

A veces, un analista puede querer duplicar y usar un proxy HTTP, como Burp Suite, en su VM junto con un proxy SOCKS. Burp suite ha incorporado soporte para un servidor SOCKS; sin embargo, la experiencia ha demostrado que no funciona bien cuando se usa con servidores SOCKS de herramientas como Cobalt Strike. El mejor enfoque es iniciar Burp Suite con cadenas de proxy en lugar de configurar explícitamente Burp Suite para usar un servidor SOCKS. Siga los pasos de las secciones anteriores para configurar un túnel en la VM que se conecta al puerto SOCKS.

Estructuras de comando y control (C2)

OBJETIVO: Herramientas y tráfico proxy desde la estación de trabajo privada de un analista a la red del cliente a través de un marco C2.

Algunos marcos de C2 utilizan un agente que tiene incorporado un servidor SOCKS como Mythic‘s, Poseidón y Cobalt Strike’s Beacon. El uso de las capacidades integradas de SOCKS de un agente elimina la necesidad de configurar múltiples túneles SSH.

Desde el símbolo del sistema de Cobalt Strike Beacon, ejecute el comando socks 9051. Esto creará un puerto de servidor SOCKS de escucha en Cobalt Strike Team Server (REDIR1), no en el host donde se ejecuta el agente (PWNED1) ni en el host donde se ejecuta el cliente de interfaz de usuario Cobalt Strike (LINUX1). Todo el tráfico enviado al puerto SOCKS de escucha en el Team Server se enviará posteriormente al host comprometido donde se está ejecutando Beacon.

Una vez que el puerto del servidor SOCKS esté escuchando en el Team Server, configure un puerto local de reenvío desde la VM del operador (LINUX1) al Team Server (REDIR1). Una vez que se ha configurado el túnel, se pueden utilizar herramientas como las cadenas de proxy y Firefox para enviar tráfico a la red interna del cliente.

Protocolo de escritorio remoto (RDP)

OBJETIVO: utilizar RDP a través de un proxy SOCKS desde la estación de trabajo privada de Linux de un analista.

Los administradores suelen utilizar RDP para acceder de forma remota a un host de Windows y aprovechar la GUI de Windows para realizar tareas. Por esta misma razón, los analistas a menudo también querrán utilizar RDP para acceder a un sistema de información de destino. Los túneles SSH y los proxies SOCKS se pueden utilizar para transportar un cliente RDP desde el host de un analista a un entorno de destino y controlar de forma remota un host. El cliente xfreerdp de Linux es un programa de uso común para acceder de forma remota a un host Linux. Con un servidor SOCKS y túneles ya en funcionamiento, use proxychains para conectarse al entorno de destino con xfreerdp.

1. Utilice el cliente proxychains en LINUX1
2. Proxy en el cliente xfreerdp
3. Conéctese al hostname del servidor remoto 192.168.1.10
4. Conéctese al servicio RDP en el puerto remoto 3389
5. Inicie sesión con el usuario administrador
6. Inicie sesión con la contraseña Passw0rd1

Otras banderas útiles incluyen: /clipboard para compartir datos de los comandos de copiar y pegar entre su host y el sistema remoto. Además, la bandera /drive:MyDrive,/tmp crea un recurso compartido de archivos llamado MyDrive en el host de Windows que se puede usar para transferir archivos hacia y desde el directorio /tmp en el host de origen, LINUX1.

Windows

OBJETIVO: Herramientas y tráfico proxy desde la estación de trabajo privada de Windows de un analista a la red del cliente.

Windows 10 tiene un cliente OpenSSH integrado que se puede usar para crear un túnel de reenvío de puerto local SSH para el tráfico de proxy en la red de destino. Sin embargo, proxychains no es compatible con Windows. Una alternativa es utilizar Proxifier. El host que ejecuta Proxifier debe configurarse con un túnel SSH a un puerto proxy SOCKS de escucha como se documenta en las secciones anteriores. Una vez que el túnel esté configurado, abra Proxifier y vaya al menú Perfil. Agregue un servidor proxy que apunte al túnel SSH de reenvío del puerto local que se configuró en el host de Windows.

El proxy se puede configurar para enrutar todo el tráfico desde su máquina virtual de Windows a través del proxy SOCKS hacia la red de destino. Alternativamente, Proxifier ofrece una opción más segura de OPSEC para crear reglas que restrinjan el tráfico a través del proxy SOCKS para programas específicos. Para agregar una regla, vaya al menú Perfil y seleccione Reglas de proximidad y agregue aplicaciones que deberían poder usar el proxy. Esta imagen muestra una regla que solo transferirá el tráfico de cmd.exe, rubeus.exe, mstsc.exe y powershell.exe.

Advertencias de Proxifier

Si bien Proxifier puede permitir que un analista utilice herramientas de Windows y envíe tráfico a la red de un cliente, hay varios "errores" que se deben tener en cuenta. El primero es considerar las credenciales asociadas con la sesión de inicio de sesión que está ejecutando la herramienta. La cuenta de usuario local del host de Windows de un analista no se autenticará correctamente en los recursos de red de un cliente. Se recomienda utilizar el programa runas.exe con la bandera /netonly para crear una nueva sesión con credenciales para un usuario válido en el dominio del cliente. Otras alternativas incluyen parchear LSASS con un hash NTLM o importar un TGT de Kerberos en la sesión de inicio de sesión actual con una herramienta como Rubeus.

Las aplicaciones que utilizan implícitamente otros servicios de Windows o el kernel de Windows NT para conectarse a un host remoto no podrán comunicarse a través del proxy. Algunos programas utilizan de forma transparente los otros servicios del sistema operativo (por ejemplo, RPC, DCOM o WMI) o el kernel de Windows (por ejemplo, SMB) bajo el capó. Un ejemplo de esto es cuando se usa el Explorador de Windows para explorar un recurso compartido de archivos SMB. El proceso del sistema que representa el kernel de Windows, intentará conectar el recurso compartido SMB, pero la conexión se agotará porque la conexión de red del kernel no pasa por el proxy. De manera similar, cuando hay un intento de autenticarse en un controlador de dominio usando Kerberos, lsass.exe realiza la conexión con los controladores de dominio, no con la aplicación de origen que inició la solicitud. Esta actividad también se puede ver al intentar usar el comando net view o los cmdlets Get-Net* de PowerView porque usan conexiones de red RPC que se originan principalmente en el Kernel o el servicio RPCSS.

Además, algunas herramientas como BloodHound o Rubeus dependen de determinadas variables de entorno de Windows para identificar el dominio de Active Directory y los servidores de inicio de sesión. Debido a que la estación de trabajo privada de Windows de un analista no está unida a un dominio, esas variables de entorno no existirán. Una solución alternativa es especificar siempre el dominio, el controlador de dominio y las credenciales explícitas según la herramienta y los argumentos disponibles (por ejemplo, el cmdlet Get-DomainUser de Powerview).

Túnel HTTP

OBJETIVO: Crear un túnel utilizando el protocolo HTTP.

Los operadores pueden utilizar el protocolo HTTP para crear un túnel. Esto es útil cuando el protocolo SSH no puede salir de la red de destino en los puertos 22, 80 o 443. Casi todas las organizaciones permiten que el protocolo HTTP salga de la red, ya que se utiliza para las actividades diarias y las operaciones comerciales. gTunnel es una "solución de tunelización HTTP/2 multiplataforma que tiene como objetivo proporcionar túneles de red rápidos y sencillos que son eficientes y sigilosos". La herramienta es compatible con túneles de reenvío y reversos, así como con el protocolo proxy SOCKS5. El analista deberá colocar el cliente gTunnel en el host comprometido, PWNED1, para crear una conexión. Visite la documentación de gTunnel para obtener detalles sobre los pasos para comenzar.

Conclusión

Los túneles SSH y los proxies SOCKS son invaluables durante las operaciones de seguridad ofensivas, pero también pueden ser un poco confusos de configurar. Es de esperar que la información detallada para cada parte de un comando, seguida de un gráfico visual, facilite la comprensión de las cosas. Aprovechar los túneles de reenvío de puertos remotos y locales del cliente SSH permite al analista eludir las restricciones de seguridad de la red. Los analistas pueden combinar túneles SSH con un proxy SOCKS para ejecutar sus herramientas en un host donde no hay aplicaciones de monitoreo de puntos finales. Esto se puede utilizar para evitar las detecciones y permite un uso flexible de programas que pueden ejecutarse en diferentes sistemas operativos. Con suerte, esta publicación se utiliza como punto de referencia para desmitificar la complejidad de configurar túneles SSH y proporciona ejemplos detallados como punto de referencia para operaciones futuras.

Traducido de: SPECTEROPS