La historia de la investigación y el desarrollo en 3 partes. Parte 1 - investigación.
Hay muchas hayas, incluso más beneficios.
Declaración del problema.
Durante la realización de pentests y campañas de RedTeam, no siempre es posible utilizar los medios habituales de los clientes, como VPN, RDP, Citrix, etc. como una solución para ingresar a la red interna. En algún lugar, una VPN normal funciona de acuerdo con MFA y se usa un token de hierro como segundo factor, en algún lugar se supervisa severamente y nuestra entrada de VPN se hace visible de inmediato, como dicen, con todas las consecuencias, pero en algún lugar simplemente no hay tales medios.
En tales casos, constantemente tenemos que hacer los llamados "túneles inversos": conexiones desde la red interna a un recurso externo o al servidor que controlamos. Dentro de dicho túnel, ya podemos trabajar con los recursos internos de los clientes.
Hay varias variedades de tales túneles inversos. El más famoso de ellos, por supuesto, es Meterpreter. Los túneles SSH con reenvío de puerto inverso también tienen una gran demanda entre las masas de hackers. Hay muchas herramientas de túnel inverso y muchas de ellas están bien estudiadas y descritas.
Por supuesto, por su parte, los desarrolladores de soluciones de protección no se quedan atrás y detectan activamente tales acciones.
Por ejemplo, las sesiones de MSF son detectadas exitosamente por IPS moderno de Cisco o Positive Tech, y el túnel SSH inverso puede ser detectado por casi cualquier pequeño firewall normal.
Por lo tanto, para pasar desapercibido en una buena campaña de RedTeam, necesitamos construir un túnel inverso con medios no estándar y adaptarnos lo más posible al modo real de la red.
Intentemos encontrar o inventar algo similar.
Antes de inventar algo, debe comprender qué resultado queremos lograr, qué funciones debe realizar nuestro desarrollo. ¿Cuáles serán los requisitos para el túnel para que podamos trabajar en modo de sigilo máximo?
Está claro que para cada caso, tales requisitos pueden diferir enormemente, pero por experiencia podemos distinguir los principales:
- funciona en el sistema operativo Windows-7-10. Como la mayoría de las redes corporativas usan Windows;
- el cliente se conecta al servidor a través de SSL para evitar escuchar estúpidamente usando ips;
- al conectarse, el cliente debe admitir la operación a través de un servidor proxy con autorización, como Muchas compañías acceden a Internet a través de un proxy. De hecho, es posible que la máquina cliente ni siquiera sepa nada al respecto, y el proxy se usa en modo transparente. Pero debemos poner tal funcionalidad;
- la parte del cliente debe ser concisa y portátil;
Está claro que para trabajar dentro de la red del Cliente en la máquina del cliente, puede instalar OpenVPN y elevar un túnel completo a su servidor (ya que los clientes openvpn pueden trabajar a través de servidores proxy). Pero, en primer lugar, esto no siempre funciona, ya que es posible que no seamos administradores locales allí, y en segundo lugar, hará tanto ruido que un SIEM o HIPS decentes inmediatamente nos “golpearán”. Idealmente, nuestro cliente debería ser un llamado comando en línea, como muchos shells de bash, por ejemplo, y ejecutarse a través de la línea de comando, por ejemplo, al ejecutar comandos desde una macro de palabra. - nuestro túnel debe ser multiproceso y admitir muchas conexiones al mismo tiempo;
- La conexión cliente-servidor debe tener algún tipo de autorización para que el túnel se establezca solo para nuestro cliente, y no para todos los que vienen a nuestro servidor en la dirección y puerto especificados. Idealmente, para "usuarios de terceros", se debe abrir una página de destino con sellos o temas profesionales relacionados con el dominio de origen.
Por ejemplo, si el Cliente es una organización médica, para el administrador de seguridad de la información que decidió verificar el recurso que utilizó el empleado de la clínica, se abrirá una página con productos farmacéuticos, una wikipedia con una descripción del diagnóstico o un blog del Dr. Komarovsky, etc.
Análisis de herramientas existentes.
Antes de inventar su bicicleta, debe analizar las bicicletas existentes y comprender si realmente la necesitamos y, probablemente, no solo pensamos en la necesidad de una bicicleta tan funcional.
Buscar en Internet (parece que estamos de acuerdo con Google), así como buscar en el github las palabras clave "calcetines inversos", no dio muchos resultados. Básicamente, todo se reduce a construir túneles ssh con reenvío de puerto inverso y todo lo relacionado con él. Además de los túneles SSH, se pueden distinguir varias soluciones:
github.com/klsecservices/rpivotUna implementación de larga data del túnel inverso de los chicos de Kaspersky Lab. Por el nombre, está claro para qué es este script. Implementado en Python 2.7, el túnel se ejecuta en modo de texto claro (como está de moda decir ahora, hola a ILV)
github.com/tonyseek/rsocksOtra implementación de Python también está en texto claro, pero hay más opciones. Está escrito como un módulo y hay una API para integrar la solución en sus proyectos.
github.com/llkat/rsockstungithub.com/mis-team/rsockstunEl primer enlace es la versión inicial de la implementación de Sox inverso en Golang (no compatible con el desarrollador).
El segundo enlace ya es nuestra revisión con chips adicionales, también en el golang. En nuestra versión, implementamos SSL, trabajamos a través de un proxy con autorización NTLM, autorización del cliente, una página de aterrizaje con una contraseña incorrecta (o más bien una redirección a una página de aterrizaje), modo multiproceso (es decir, varias personas pueden trabajar con el túnel al mismo tiempo) , un sistema de ping del cliente para saber si está vivo o no.
github.com/jun7th/tsocksImplementación inversa de Sox de nuestros "amigos chinos" en python. Allí para los perezosos e "inmortales" se encuentra el binar (exe) listo para usar, ensamblado por los chinos y listo para usar. Aquí, solo el dios chino sabe que puede haber más que la funcionalidad principal en este binario, así que úselo bajo su propio riesgo y riesgo.
github.com/securesocketfunneling/ssfUn proyecto bastante interesante de C ++ para implementar calcetines inversos y más. Además del túnel inverso, puede hacer reenvío de puertos, crear un shell de comandos, etc.
Medidor de MsfAquí, como dicen, sin comentarios. Todos los piratas informáticos más o menos educados están muy familiarizados con esta cosa y entienden con qué facilidad se puede detectar con un equipo de protección.
Todas las herramientas anteriores funcionan en una tecnología similar: en una máquina dentro de la red, se lanza un módulo binario ejecutable preparado previamente, que establece una conexión a un servidor externo. El servidor inicia el servidor SOCKS4 / 5, que acepta conexiones y las traduce al cliente.
La desventaja de todas las herramientas anteriores es que se requiere Python o Golang en la máquina del cliente (¿vio a menudo Python instalado en las máquinas, por ejemplo, los directores de la empresa o los trabajadores de oficina?), O necesita arrastrar un binario premontado a esta máquina (en realidad, Python y el script en una botella) y ejecute este binario que ya está allí. Y descargar exe con su posterior lanzamiento también es la firma de un antivirus local o HIPS.
En general, la conclusión se sugiere a sí misma: necesitamos una solución en powershell. Ahora los tomates volarán hacia nosotros, dicen PowerShell, todo está golpeado, está siendo monitoreado, bloqueado, etc. etc. De hecho, no en todas partes. Declaramos responsablemente. Por cierto, hay muchas maneras de evitar los bloqueos (aquí nuevamente la frase de moda sobre hola al ILV :)), comenzando por el estúpido cambio de nombre de powershell.exe -> cmdd.exe y terminando con powerdll, etc.
Empieza a inventar
Está claro que primero buscaremos en Google y ... no encontraremos nada sobre este tema (si alguien lo ha encontrado, agregue enlaces a los comentarios). Solo hay una
implementación de Socks5 en powershell, pero este es el Sox "directo" habitual, que tiene varios de sus inconvenientes (hablaremos de ellos más adelante). Por supuesto, puede convertirlo en un reverso con un movimiento de muñeca, pero solo será un Sox de un solo hilo, que no es exactamente lo que necesitamos para nosotros.
Entonces, no encontramos nada listo, así que todavía tenemos que inventar nuestra bicicleta. Como base de nuestra bicicleta, tomamos
nuestro desarrollo de calcetines inversos en el golang e implementamos el cliente para él en powershell.
RSocksTunEntonces, ¿cómo funciona rsockstun?
En el corazón del trabajo de RsocksTun (en lo sucesivo, rs) hay dos componentes de software: el servidor Yamux y el servidor Socks5. El servidor Socks5 es un local local regular, se ejecuta en el cliente. Y las conexiones de multiplexación a él (¿recuerdas sobre subprocesamiento múltiple?) Se proporcionan usando yamux (
otro multiplexor más ). Este esquema le permite ejecutar varios servidores de calcetines de cliente5 y distribuir conexiones externas a ellos, reenviándolos a través de una sola conexión TCP (casi como en meterpreter) desde el cliente al servidor, realizando así el modo multihilo, sin el cual simplemente no podemos trabajar completamente en el interno red
La esencia de yamux es que introduce un nivel de red adicional de flujos, dándose cuenta como un encabezado de 12 bytes para cada paquete. (Aquí usamos intencionalmente la palabra "transmisión", no una transmisión, para no confundir al lector con el hilo del programa "hilo" - este concepto también lo usaremos en este artículo). Dentro del encabezado yamux contiene el número de transmisión, las banderas para configurar / finalizar la transmisión, el número de bytes transferidos, el tamaño de la ventana de transferencia.
Además de instalar / completar la transmisión, yamux implementa un mecanismo keepalive que le permite monitorear el estado del canal de comunicación instalado. El mecanismo de mensajes keeplive se configura al crear una sesión de Yamux. En realidad, desde la configuración solo hay dos parámetros: activar / desactivar y la frecuencia de envío de paquetes en segundos. El servidor yamux puede enviar mensajes keepalive, por lo que el cliente yamux puede. Al recibir un mensaje keepalive, la parte remota está obligada a responder enviando exactamente el mismo identificador de mensaje (en realidad un número) que ha recibido. En general, keepalive es el mismo ping, solo para yamux.
Toda la técnica de operación del multiplexor se detalla: tipos de paquetes, indicadores de instalación y terminación, el mecanismo de transferencia de datos se describe en
la especificación de yamux.
Conclusión de la primera parte.
Entonces, en la primera parte del artículo nos familiarizamos con algunas herramientas para organizar túneles inversos, analizamos sus ventajas y desventajas, estudiamos el mecanismo de operación del multiplexor Yamux y describimos los requisitos básicos para el módulo PowerShell recién creado. En la siguiente parte, desarrollaremos el módulo en sí, prácticamente desde cero. Continuará No cambies :)