Muy buenas a todos!
Esta semana os traigo un post totalmente diferente a los que suelo publicar normalmente. En esta ocasión, no voy a presentar ninguna herramienta nueva, ni voy a explicar cómo funciona la última hacking tool de moda. Desde ahora y durante los próximos meses, he decidido centrarme en arreglar y mejorar mis proyectos, que mucha falta les hacen.
Evidentemente, esto no significa que no vaya a publicar nuevas herramientas, ni que vaya a dejar de hablar de otras tools que me parezcan interesantes. Simplemente, hay muchas cosas que arreglar y mejorar en mis creaciones, que pueden solucionarse rápidamente.
Por eso, he decidido crear este pequeño post, explicando brevemente las cosas que he solucionado. Aprovechando la ocasión, también os quiero contar las próximas novedades que podréis encontrar en mis herramientas y algunas funciones nuevas que ya están disponibles.
Para hacerlo todo más sencillo, dividiré este artículo en tres secciones: Problemas solucionados, Nuevas características y Próximas actualizaciones.
En cada una de ellas, os explicaré de forma sencilla y detallada todos los cambios realizados (o por realizar) en cada una de las herramientas que podéis encontrar en mi GitHub.
Adicionalmente, también dividiré esta entrada en tres partes, ya que algunos cambios todavía se encuentran en una fase preliminar y podrían no llevarse a cabo o sufrir cambios durante su planteamiento.
Ahora que ya sabéis de qué va la temática del post, vamos a por ello 😋
Problemas solucionados
Cloudtopolis ha sido uno de los proyectos que más dolores de cabeza me ha dado últimamente. Debido a todos los cambios que ha realizado Google en sus productos, me he visto obligado a modificar el funcionamiento de la herramienta más veces de las que me gustaría.
En las primeras versiones, se utilizaba SSH para conectar Google Colab con Cloud Shell, pero a Google no le gustaba la idea. Básicamente, este comportamiento modificaba la contraseña del usuario «root» en la máquina virtual y por motivos de seguridad, decidieron cortar por lo sano.
Posteriormente, lo resolví utilizando la autenticación OAuth nativa de Google para llevar a cabo este propósito. De esta forma, ha estado funcionando sin problemas.. hasta ahora. Por motivos de seguridad (una vez más), ahora todos los proyectos de Cloud Shell vienen con la API de ejecución de comandos deshabilitada por defecto.
Ya que, seguramente, me encontraría con más problemas si consiguiera automatizar la forma de habilitar este proceso, he decidido utilizar de forma temporal un servicio externo. No es algo que me guste, ya que no debería ser necesario un tercero para conectar dos servicios propios de Google.
En cualquier caso, por ahora funciona correctamente y podemos seguir utilizando Cloudtopolis sin problemas e incluso algo más rápido que antes, ya que ahora son menos pasos.
Resumiéndolo mucho, ahora Cloud shell se conectará mediante SSH al servicio de localhost.run tal y como puede verse en el siguiente fragmento de código:
De esta forma, al ejecutar ahora el script en Cloud Shell, nos encontraremos con un nuevo elemento llamado link. Este enlace, siempre será una dirección aleatoria terminada en «.lhrtunnel.link» desde la que podremos acceder a Cloudtopolis, tal y como se muestra a continuación:
Por último, solo tendremos que acceder como de costumbre, crear el Voucher y pegarlo junto al link en los datos de Google Colab:
Utilizando este nuevo método, tendremos algunas ventajas e inconvenientes:
• Al no utilizar OAuth, no es necesario verificar nuestra identidad, por lo que la conexión se realiza mucho más rápido y no es necesario validar las cuentas al compartir la ejecución con otros amigos y/o compañeros.
• Los nombres de dominio tienen un tiempo de vida corto y al cambiarse será necesario volver a ejecutar el script principal junto a los agentes de Colab. Al hacerlo, se asignará un dominio nuevo durante otro breve período de tiempo.
Como conclusión final, este nuevo sistema funciona de forma estable y segura, es mucho más rápido que el anterior y nos permite ejecuciones lo suficientemente largas para tareas básicas o de corta duración.
Si necesitas tiempos de ejecución más largos y más potencia de cómputo, es recomendable utilizar la combinación de VPS + Colab Pro.
En el caso de PyShell, todo ha resultado mucho más fácil. Básicamente, se trataban de pequeños errores que podían dar problemas en situaciones muy concretas.
En primer lugar, un bug en la definición de las rutas dinámicas, impedía llegar a la ruta raíz («/») si nos escapábamos el directorio muchas veces con el comando cd.
Cuando esto sucedía, la ruta desaparecía por completo y no podíamos continuar listando directorios:
Por otra parte, cuando utilizamos las shells incorporadas en PyShell todo funciona perfectamente (ya que han sido diseñadas específicamente para este fin). Pero, qué sucede cuando encontramos una vulnerabilidad y podemos ejecutar código en una web ya existente?
Normalmente, cuando nos encontramos ante esta casuística, el output de nuestros comandos se mostrarán dentro de un «<pre>» junto al resto de la página. Conociendo esta información, es muy fácil filtrar todo el contenido dentro de esa etiqueta y descartar el resto.
Más o menos, esto era lo que sucedía en esa situación:
Ahora, una vez resueltos los fallos comentados anteriormente, todo funciona de la forma esperada:
Aunque todavía quedan cosas por pulir, PyShell nos ofrece una webshell totalmente funcional, con una interfaz limpia y sencilla, incluso cuando no utilizamos sus propias shells incorporadas.
Por último, el bug más fácil de arreglar de todos. Literalmente, el cambio se trata de una pequeña modificación dentro de un «if» en el código de Invoke-DNSteal.
Por pequeño que parezca el cambio, se trata de algo bastante significativo:
Uno de los problemas al utilizar la herramienta, es que la misma, debe saber diferenciar cuando enviamos un string o cuando estamos leyendo de un fichero. Aunque resulta algo muy trivial, existen muchas formas de hacerlo.
En mi caso, he decidido utilizar la siguiente cadena («:\») como filtro para determinarlo. Es decir, si la ruta del fichero contiene esa combinación (en Windows ningún fichero puede contener esos símbolos), se trata de un fichero. De lo contrario, se trata de un texto.
De esta forma, no solo se resuelve ese problema, sino que también ahora es posible exfiltrar todo un directorio completo utilizando «.fullname» antes (o dentro) de un foreach, tal y como puede verse a continuación:
Pronto habrá nuevas mejoras en Invoke-DNSteal, que os mostraré en el próximo artículo de esta serie.
Nuevas características
Resueltos los problemas, pasemos a las nuevas funcionalidades. En este caso, es el turno de PSRansom, la última herramienta que os presenté en el blog.
En la última actualización, se ha añadido un nuevo parámetro («-demo»), que nos permite recrear el comportamiento de algunas familias de ransomware, mostrando una alerta en pantalla y cambiando el fondo del escritorio:
Pronto también habrá algunas mejoras en PSRansom, pero habrá que esperar al próximo artículo para saber de qué se trata.
Próximas actualizaciones
Hacía mucho tiempo que no hablaba de AutoRDPwn, la primera herramienta propia que os presenté hace ya unos añitos en este blog. No por eso quiere decir que la tenga olvidada, ni mucho menos.
En primer lugar, es muy probable que elimine el bypass de AMSI, ya que es algo que Microsoft está persiguiendo de forma bastante activa y no aporta nada actualmente.
Otro de los cambios previstos, es eliminar todas aquellas herramientas de terceros que dependen de ficheros de tipo «.exe» para su ejecución, centrándome en que cualquier funcionalidad del framework siempre se ejecutará en memoria desde PowerShell, independientemente de lo que sea.
Por último, gracias a la llegada de PowerRemoteDesktop, se abren muchas puertas a solucionar algunos problemas que existían en equipos legacy, así como el uso de RDPWrap en aquellos que no disponen de escritorio remoto por defecto.
También se actualizarán todos los scripts de terceros, se revisará el código por completo y puede que lleguen algunas cosas nuevas.
Para terminar el artículo, veamos que nuevas funciones nos traerá Invoke-Stealth, probablemente una de las herramientas con menos popularidad de mi GitHub.
En primer lugar, se reemplazará Chimera por Chameleon, ya que este último utiliza Python en lugar de bash. Y no es que no me guste bash, ni mucho menos 😜
El problema, por así decirlo, es que al igual que otras de mis herramientas escritas en PowerShell, prefiero que funcionen tanto en Windows como en Linux. Por tanto, me resulta mucho más sencillo utilizar un «Python portable» que utilizar bash en los sistemas de Microsoft.
Gracias a esto, también se solucionaría el problema con PyFuscation y la herramienta funcionaría en su totalidad en ambos sistemas sin requerir demasiadas dependencias.
Para terminar, también he pensado en reemplazar la función de «ReverseB64» y utilizar la misma que utiliza PSRansom, ya que es mucho mejor que la primera. De esta forma, sería más difícil para los AV/EDR entender el código de forma estática.
Tampoco descarto la idea de reemplazar PSObfuscation por una nueva funcionalidad de compresión escrita por mí mismo, para reducir el tamaño de los payloads y mejorar aún más la evasión estática usando valores de compresión aleatorios.
Antes de despedirme, recordad que muchas de mis herramientas se encuentran en fase «beta» y es probable que se produzcan fallos en algunos escenarios. Si encuentras alguno, no dudes en hacérmelo saber 🙂
Espero que os haya gustado y os resulte útil en vuestras próximas auditorías.
Nos vemos en la próxima!