Serverless & Bullet-Proof Web Sites (1 de 2)

En este artículo me gustaría contaros una pequeña PoC que hicimos en el equipo de Ideas Locas que teníamos guardada para algún evento de Web3, pero que como tengo ganas de contárosla, he decidido hacerlo desde hoy. No es un estudio completo, ni mucho menos, porque el escenario es enorme, pero se basa en un idea muy sencilla, que es hacer Serverless & Bullet-Proof WebSites, capaces de soportar el intento de bloqueo o censura de cualquier entidad.

Figura 1: Serverless & Bullet-Proof Web Sites (1 de 2)

Esto no es algo nuevo, y la Serverless Web lleva tiempo estudiándose, y trabajándose con diferentes arquitecturas, todas ellas totalmente distribuidas.

Dust-RSS

Uno de esos ejemplos fue un proyecto personal del equipo de Ideas Locas, en aquel entonces en Informática 64, en aquel entonces del año 2010, y que presentamos en la RootedCON de 2011 y se llamó Dust-RSS.

Figura 2: Dust-RSS en su presentación en RootedCON 2011

La idea era muy sencilla, evitar la censura de los servidores RSS de los blogs para permitir que cualquiera que tuviera algo que comunicar lo pudiera hacer siempre, y para eso diseñamos una arquitectura muy sencilla, basado en claves PGP y una red P2P para hacer la distribución. Esto hacía que no hubiera un único punto de fallo en el servidor web, ni en el DNS, y que con tener la clave pública PGP del publicador se pudiera buscar por redes P2P las publicaciones. 

Figura 3: Demo de Dust RSS funcionando

De esta forma, el publicador lo único que debía conservar era su clave PGP privada para poder poner en la red P2P una nueva publicación. La arquitectura funcionaba, pero se quedó en una PoC que presentamos en DefCON 2012, y que se quedó como un bonito experimento.

OSIRIS SPS

Uno de las arquitecturas que buscaba solucionar estos problemas de censura de servidores Web se trataba de OSIRIS SPS (Serverless Portal System) y su Gateway ISIS, para poder publicar servidores Web que no dependieran de un único punto de fallo. Para ello, la solución era similar a tener a páginas web cacheadas y compartidas por una red P2P.

Figura 4: Foro de Anime publicado en Osiris SPS visible vía Isis Gateway

Las páginas web de los portales que se ven a través de esas URLs realmente no están en ningún servidor web concreto, sino distribuidos por toda la red P2P de Osiris SPS, lo que impediría un bloqueo o censura del sistema. Es perfecto para crear foros y portales de denuncia social que no puedan ser quitados de Internet si no quieren sus usuarios.

DeepWeb: TOR, I2P, FeeNet, Hyperboria, CJDNS

Todas estas soluciones no accesibles a través de los navegadores de "superficie", son consideradas redes de la DeepWeb, no solo porque no son accesibles con las herramientas más comunes de Internet, sino porque además cuentan con herramientas y protecciones contra el control, ya sea cifrados especiales o como hemos visto, para evitar el bloqueo de sus contenidos, como en el caso de OSIRIS SPS o el sistema DUST RSS que utiliza mecanismos P2P para ello.  q

Figura 5: Libro de Deep Web: TOR, FeeNEt & I2P.  Privacidad y Anonimato 
de Daniel Echevarry a.k.a. "adastra" en 0xWord.

Por supuesto, muchas de las funciones de seguridad que se buscan en estas redes, están en las más conocidas de la DeepWeb como son  TOR, FreeNET e I2P, donde el cifrado de las comunicaciones es una de las claves en todas ellas.

Figura 6: Arquitectura de conexión CJDNS para la red Hyperboria

Pero la búsqueda de arquitecturas distribuidas y seguras ea algo que se ha estudiado mucho, como el caso de CJDNS y su red Hyperboria con conexiones cifradas y certificadas sobre IPv6, GNUNet, Lantern, YaCy para conseguir que no puedan ser accesibles los contenidos por nadie.

Malware en BlockChain

Por supuesto, pensar en arquitecturas Serverless y Distribuidas, es hablar del core de las cadenas de bloques de BlockChain, y utilizar las capacidades que tiene para poder almacenar datos de forma permanente y protegida con la distribución por diseño que tiene esta tecnología.

Figura 7: PoC de C&C con OP_Code en cadena de BitCoin

propuesta por Yaiza Rubio y Felix Brezo en EuskalHack 2017

En la EuskalHack del 2017, Felix Brezo y Yaiza Rubio hacían una demostración de cómo se podrían almacenar comandos de un C&C de una Botnet de malware en el campo OP_CODE la cadena de bloques de BitCoin.

Figura 8: Libro de "Bitcoin: La tecnología Blockchain y su investigación"
de Yaiza Rubio y Félix Brezo en 0xWord

Esto, al precio que está hoy el BitCoin parece un poco caro, pero esta idea de usar la cadena de OP_CODE para hacer servicios no es nueva, y algunos proyectos lo han utilizado en el pasado, aunque co la proliferación de cadenas de bloques a precios mucho más más económicos, hace que ya no sea necesario centrarse en ese campo.

Figura 9: Análisis del malware de Etherhiding

Y como muestra de esto lo hemos tenido con el caso del malware de Etherhiding, donde el binario del malware se han escondido dentro de la cadena de Binance Smart Chain, y ha utilizado SmartContracts para actualizarse.

Redes Sociales Descentralizadas

Por supuesto, la explosión de las cadenas de Blockchain, y otras arquitecturas distribuidas, hayan ido apareciendo en todos los verticales tecnológicos nuevos servicios que pretenden ser más resistentes contra los ataques a servicios descentralizados, como son las Redes Sociales.

Figura 10: Yo tengo mi curenta en Mastodon

Ahí, propuestas como Mastodom, Diaspora, Matrix, Block Square, que son sólo una pequeña muestra, han ido apareciendo por todos los rincones de Internet, y se han convertido en parte de la transformación y disrupción que se está viviendo en este mundo de las redes sociales.

Figura 11: Red social Diaspora 

Pero la descentralización de todos los servicios digitales que se están construyendo hoy en día. Algunos que se han hecho piezas fundamentales en las arquitecturas Web3, como el almacenamiento IPFS (Inter Planetary File System) del que ya hablamos.

Y esto nos lleva a nuestra PoC, que es cómo aplicar todas las arquitecturas al servicio fundamental de la web, y que como veremos es rápido y sencillo, pero será en la segunda parte de este artículo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Aplicaciones prácticas de Docker en ciberseguridad: Tu servidor Proxy para navegar por la red TOR #DeepWeb #Anonimato #Docker

Este posiblemente sea el primer artículo de una serie que vamos a ir publicando llamada “Aplicaciones prácticas de Docker en ciberseguridad”, donde iremos mostraremos recursos, herramientas y soluciones siempre utilizando Docker como elemento principal. La versatilidad y sencillez de esta tecnología nos permite disponer de nuestra propia caja de herramientas, segura, en cualquier momento y en cualquier lugar.

Figura 1: Docker en ciberseguridad: Tu servidor Proxy para navegar por TOR

Esto para alguien que se dedica a la ciberseguridad o incluso para cualquier usuario que quiera probar o utilizar alguna aplicación, es una opción que debemos de tener en cuenta. Y recuerda, si necesitas ayuda para comenzar esta aventura con Docker, en nuestro libro “Docker: SecDevOps” tienes un buen punto de partida para comenzar en este fantástico mundo de los contenedores Docker.

Figura 2: Libro de Docker:SecDevOps

Utilizar un contenedor Docker nos permite encapsular toda la instalación (componentes, dependencias, etc) y aislarlo de nuestro host (por defecto). De esta manera, podemos, por ejemplo, crear un proxy para navegar a través de la red Tor de una manera segura y rápida. Y esto es justo lo que vamos a contarte hoy paso a paso, así que manos al a obra.

Cómo configurar un Proxy Tor

Para ello vamos a crear una imagen con dos herramientas que seguro ya conocéis: anonsurf y tiny proxy. Con anonsurf navegaremos a través de Tor y tiny proxy, actuará pues como su nombre indica: como un Proxy.  Todo ello para que puedas navegar con anonimato a través de la Deep Web o poder hacer labores de Ciberinvestigación.

Figura 3: Deep Web: Privacidad y Anonimato

Lo primero que haremos es crearnos una imagen Docker con dichas herramientas. Para facilitar este proceso, vamos a utilizar una aplicación llamada doig o Docker Image Generator, una aplicación Open Source en lenguaje Go, creada por Tuxotron ;) que tenéis disponible en este enlace.

Figura 4: Doig en GitHub

Esta aplicación permite crear imágenes Docker o ficheros Dockerfile personalizados, simplemente eligiendo las herramientas que necesites. Además de facilitar la tarea de crear la imagen, también es muy instructiva, ya que una vez creada la imagen nos permite exportar el fichero Dockerfile el cual podemos utilizar directamente con el comando docker build o simplemente para ver su funcionamiento. Para instalar doig:

git clone https://github.com/tuxotron/docker-image-generator
cd docker-image-generator
go build

Para crear nuestra imagen para navegar por la red Tor, ejecutamos:

./doig -i myproxy -t anonsurf tinyproxy
…
Successfully built 49e1529560fe
Successfully tagged myproxy:latest

Tools added to the image:
  [-] tinyproxy: When you run Tiny Proxy, by defautl listens on port 8888,
        so you will need to map that port to a local port. Ex: -p 8888:8888
  [-] anonsurf: You need to run the container in privileged mode

Con la opción -i especificamos el nombre de la imagen y con -t listamos las herramientas que queremos incluir en la misma. Una vez terminado el proceso de construcción de la imagen, vemos que al final nos aparecen dos mensajes:

[-] tinyproxy: When you run Tiny Proxy, by defautl listens on port 8888,
       so you will need to map that port to a local port. Ex: -p 8888:8888

Este nos avisa que tiny proxy por defecto escucha por el puerto 8888, y que para usarlo necesitaremos mapear dicho puerto al de nuestro host. Si tuvieras cualquier otra aplicación escuchando por ese puerto, mapéalo a cualquier otro. En Docker se pueden mapear puertos del contenedor al host con la opción -p (--publish) host-interface:puerto-host:puerto-contenedor. Por ejemplo:

docker run -p 127.0.0.1:80:8080

Esto mapearía el puerto 80 de la interfaz 127.0.0.1 al puerto 8080 del contenedor. Si se omite la interfaz, se usaría 0.0.0.0:

docker run -p 80:8080

También se pueden especificar rangos de puertos. Por ejemplo:

docker run -p 80-82:8080-8082

Esto mapearía el puerto 80 del host al puerto 8080, 81 al 8081 y el 82 al 8082.

Existe una segunda forma de mapear los puertos con la opción -P (--publish-all). Esta opción no requiere ningún valor, ya que lo que hace es mapear los puertos que expone el contenedor a puertos aleatorios (por encima del 30000) del host. La forma en que Docker identifica los puertos que expone un contenedor viene por el comando EXPOSE de la imagen.

El segundo mensaje:

[-] anonsurf: You need to run the container in privileged mode

Nos dice que anonsurf requiere permisos elevados, ya que éste necesita hacer cambios en las iptables del contenedor. Aquí podemos darle permisos usando las capacidades o bien ejecutar el contenedor en modo privilegiado. Cuando se ejecuta un contenedor en modo privilegiado, tenemos que asegurarnos bien de las funciones que ejecuta, ya que podría comprometer tu sistema.

Si todo ha marchado bien, siguiendo nuestro ejemplo, deberíamos tener una imagen Docker llamada myproxy. Ahora, para ejecutar nuestro contenedor, lo haremos de la siguiente forma:

docker run -it --rm --privileged -p 8888:8888 myproxy
root@9ca7a81698d3:/opt#

Eso nos sitúa en una shell dentro del contenedor. Ahora todo lo que tenemos que hacer es arrancar anonsurf y tiny proxy:

anonsurf start
 * killing dangerous applications
 * cleaning some dangerous cache elements
[ i ] Stopping IPv6 services:


[ i ] Starting anonymous mode:

 * Tor is not running!  starting it  for you

 * Starting tor daemon...                                                                              [ OK ]
 * Saved iptables rules

 * Modified resolv.conf to use Tor and Private Internet Access DNS
 * All traffic was redirected through Tor

[ i ] You are under AnonSurf tunnel


root@9ca7a81698d3:/opt# tinyproxy
root@9ca7a81698d3:/opt#

Si el indicas a tu navegador que use nuestro Proxy (localhost:8888), estarás navegando a través de Tor, como puede verse en ese vídeo.


Figura 5: Configurar un Proxy TOR en Docker Parte 1
De esta forma, cada vez que queramos arrancar nuestro Proxy Tor tenemos que arrancar el contenedor y levantar ambos servicios. Si queremos automatizar un poco el proceso y ahorrarnos los pasos de levantar dichos servicios de forma manual, podemos usar la opción -d de doig. Esta opción nos dará el fichero Dockerfile que nos permite construir nuestra imagen. Todo lo que tenemos que hacer es añadir al final de dicho fichero la instrucción CMD para que arranque nuestros servicios. Veamos un ejemplo:

./doig -d -t anonsurf tinyproxy > Dockerfile

cat Dockerfile

FROM ubuntu:18.04

RUN apt update && \
    apt install -y software-properties-common git curl p7zip-full wget
                   whois locales python3 python3-pip upx psmisc && \
    add-apt-repository -y ppa:longsleep/golang-backports && \
    apt update && \
    localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias en_US.UTF-8
WORKDIR /opt
ENV LANG en_US.utf8
ARG DEBIAN_FRONTEND=noninteractive

RUN   apt install -y tinyproxy && sed -i -e '/^Allow /s/^/#/' 
           -e '/^ConnectPort /s/^/#/'
           -e '/^#DisableViaHeader /s/^#//' /etc/tinyproxy/tinyproxy.conf && \
      apt install -y iptables &&
           git clone https://github.com/Und3rf10w/kali-anonsurf.git
           && cd kali-anonsurf && ./installer.sh && \
           rm -rf /var/lib/apt/lists/*

Lo que haremos es añadir al final del fichero Dockerfile es el comando:

CMD anonsurf start; tinyproxy -d

Aquí que le decimos a Docker es que ejecute ese comando cuando arranquemos el contenedor. Fíjate que a tiny proxy le pasamos el parámetro -d para que se ejecute en el foreground. Si no Docker terminaría el contenedor. Una vez hecho esto, ahora sólo nos queda construir la imagen:

docker build -t myproxy

Y arrancar el contenedor:

docker run -d -p 8888:8888 --privileged myproxy

Aquí tenemos que prestar un poco de atención, ya que ya no hemos arrancado el contenedor en modo interactivo (-it) si no en modo no interactivo con la opción -d (detach). De esta forma el contenedor corre en el background. También se podría ejecutar en modo interactivo, pero se nos quedaría la shell “enganchada” al contenedor. Aún así, en ambos casos debería de funcionar.


Figura 6: Configurar un Proxy TOR en Docker Parte 2
Recuerda que esta imagen está sólo disponible en tu sistema. Si queremos compartir esta imagen con alguien o simplemente quisieras usarla en otros entornos, sin tener que construir la imagen en cada uno de ellos, puedes subir ésta a un registro de imágenes. Un registro de imágenes es un repositorio donde se pueden almacenar, imágenes.

Dichas imágenes pueden ser públicas o privadas. A las públicas cualquiera puede acceder y a las privadas, pues cómo puedes imaginar, sólo son accesible por aquellos que tengan las credenciales necesarias. En Docker el registro de imágenes por defecto es https://hub.docker.com. Aquí cualquiera se puede crear una cuenta gratuita. Dicha cuenta te permite crear repositorios y subir imágenes a estos. Con la cuenta gratuita, sólo puedes crear un repositorio privado. El resto deben ser públicos.

Para descargar imágenes del https://hub.docker.com, no necesitas ni tener cuenta ni estar autenticado, siempre y cuanto la descarga de las imágenes que hagas sean públicas, pero si necesitas descargar imágenes privados y/o subir imágenes (ya sean privadas o públicas), sí que tienes que tener cuenta y estar autenticado. Con docker login puedes registrar tu cuenta en Docker y una vez hecho eso, ya podrías acceder a tus imágenes privadas y subir imágenes. Para subir una imagen tienes el comando docker push.

docker push usuario/imagen:tag

Es muy importante que crees una imagen, si la vas a subir al registro, que la nombres con tu usuario/nombre-imagen. Esta es la forma en que Docker identifica a quién pertenece la imagen. Por ejemplo, si tu nombre de usuario es usuario1, siguiendo el ejemplo anterior, cuando crees la imagen:

./doig -i usuario1/myproxy -t anonsurf tinyproxy

O si tomas el camino de crear la imagen por tu cuenta, sin doig:

docker build -t usuario1/myproxy

Si por algún motivo se nos olvida ponerle el nombre correcto, tampoco es necesario recrear la imagen, sólo tenemos que dar una etiqueta con el nombre correcto con el comando docker tag:

docker tag myproxy tuxotron/myproxy

Una vez hecho eso ya puedes subir la imagen a nuestro repositorio:

docker push tuxotron/myproxy
The push refers to repository [docker.io/tuxotron/myproxy]
83366880db76: Pushed
3ca184e4825e: Pushed
16542a8fc3be: Mounted from library/ubuntu
6597da2e2e52: Mounted from library/ubuntu
977183d4e999: Mounted from library/ubuntu
c8be1b8f4d60: Mounted from library/ubuntu
latest: digest:
  sha256:9fbd8e4c508738ca5ef70211988a3f39734c46ce022d4ed82581139132a9fbc4
  size: 1572

Ahora desde cualquier otra máquina (con Docker) sería posible ejecutar el contenedor como hemos visto antes.

Conclusiones

Aunque doig te facilite la vida a la hora crear imágenes, saber cómo funciona y cómo usar Docker te permitirá comprender mejor el funcionamiento interno del proceso de creación de imágenes, posiblemente una de sus partes más importantes. Si creéis que este post ha resultado útil, continuaremos con nuestra serie para ir implementando más herramientas con Docker siempre desde el punto de vista de la seguridad.

Happy Hacking Hackers!!!

Autores:

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

 Contactar con Fran Ramírez en MyPublicInbox

Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además del blog CyberHades. Puedes contactar con Rafael Troncoso en MyPublicInbox.

Contactar con Rafael Troncoso en MyPublicInbox

Entrevista a Felix Brezo de @ElevenPaths

Durante estas navidades, Felix Brezo y Yaiza Rubio publicaron el "Manual de ciberinvestigación en fuentes abiertas: OSINT para analistas", y aprovechando esta ocasión he querido hacer una entrevista a Felix, con el que tengo la suerte de poder trabajar desde hace años en ElevenPaths, CDO y Telefónica. Felix es una mente inquieta.

Figura 1: Entrevista a Felix Brezo de ElevenPaths

Lo podrás ver dando una conferencia, escribiendo un libro, discutiendo en un bar de ideologías o resolución de problemas en el mundo, apoyando a un proyecto de software libre o haciendo campaña por la liberación del código fuente de cualquier proyecto. Es un luchador con mucha guerra dentro.

Figura 2: Contactar con Felix Brezo con MyPublicInbox

Y si pones a uno del Athletic de Bilbao, brillante intelectualmente, luchador, y enreda en una única persona, te sale alguien tan insólito y único como Felix Brezo. Como ves, también puedes contactar con él a través de su buzón público en MyPublicInbox.

Saludos Malignos!

Entrevista a Felix Brezo

1.- Vale, la primera de todas, hablemos de tu libro que habla de una disciplina de la que bebemos researchers, pentesters, analistas de malware o analistas de ciberseguridad, nuestro querido OSINT (Open Source INTelligence). ¿Qué es lo que comprende este libro que habéis publicado Yaiza y tu, titulado "Manual de Ciberinvestigación en Fuentes Abiertas?

El libro "Manual de Ciberinvestigación en Fuentes Abiertas: OSINT para Analistas" es una recapitulación de técnicas sobre una disciplina en la que venimos trabajando desde hace un montón de años: la investigación en fuentes abiertas. El libro no se limita a ser una recpitulación de herramientas de búsqueda, sino que pretende ayudar a los analistas a explotar los recursos que están a su disposición para sacarle el máximo partido a toda esa información que está ahí pero que a veces no caemos en que podemos recoger. 

Figura 3: Manual de Ciberinvestigación en Fuentes Abiertas: OSINT para Analistas

Esta es una disciplina no necesariamente reservada a los técnicos y de la que muchos ámbitos y profesionales pueden sacar partido en su día a día.

2.- Por supuesto, que sepas que te hago la entrevista solo porque sé que habéis hablado de mi FOCA, aunque yo sé que tú eres mucho más de GNU/Linux. ¿Cuáles son para ti las 5 herramientas que han cambiando la ciberinvestigación en los últimos años?

- Los metadatos siguen siendo un filón de fenómenos indiciarios. FOCA y Exiftool son dos herramientas de referencia en este ámbito que nos pueden dar muchas por error u omisión de quienes publican imágenes o PDF en situaciones de estrés.

Figura 4: Libro de Pentesting con FOCA

- El dominio de las búsquedas avanzadas (o el hacking con buscadores) es fundamental y ser capaz de ir aún más allá de Google (eligiendo Yandex o Baidu cuando el entorno lo requiere o acotando las buscadores con buscadores personalizados) es clave.

- El kit de herramientas que a mí me gusta llamar la "máquina del fango" de las redes sociales: la combinación de las páginas de archivado con las búsquedas ad hoc como las búsquedas avanzadas que permite Twitter combinando el from: y el to: en la búsqueda. Son un auténtico filón para buscar tweets controvertidos sobre personalidades públicas o para empezar a relacionar a personas, incluso sobre perfiles privados de quienes no puedes leer sus tweets pero sí lo que les escriben otras personas.

- La búsqueda inversa de imágenes y el Error Level Analysis a través de herramientas como Fotoforensics o Forensically nos ayudan a la hora de identificar imágenes que han podido ser manipuladas o publicadas en otro contexto.

- Las búsquedas por nombres de usuario y herramientas como Usufy (o Sherlock, Datasploit o SpiderFoot) intentan explotar nuestra falta de originalidad y ganas de mantener nuestra presencia online fácilmente identificable. Ahora algunos gobiernos empiezan a pedir este tipo de información a la hora de entrar a los países, pero las herramientas las tenemos a mano desde hace unos cuantos años y comprobar que existen, nos ayuda a tomar consciencia de nuestra exposición.

3.- Eres doctor por la Universidad de Deusto, y además en ciberseguridad. ¿De qué fue el trabajo de investigación en el que dedicaste tus años de doctorando?

En mi caso, tuve mucha suerte. El Dr. Pablo García Bringas - el mismo que tuviste en el tribunal de presentación de tu tesis doctoral, Chema ! -, entonces director del S3Lab de la universidad admitió en un mes de febrero en su equipo de investigación a un chaval de cuarto de carrera al que le quedaban quinto y sexto que entró preguntando por trabajo en materia de seguridad. 

Caí un equipo que entonces no era demasiado grande todavía y en el que ya estaban los dos Igor, Borja, Mikel, Carlos, Javi, Agustín y Sendoa que yo recuerde y a los que luego se sumaron muchos otros. Ahí ya aprendí las consecuencias de no bloquear el ordenador y los fundamentos de la modelización de datos, a programar en Python y las diferencias entre el aprenzidaje automático supervidado y no supervisado a base de muchos experimentos con Weka.

Fruto de ese trabajo, tuve la suerte de empezar a encarrilar mi trabajo de fin de carrera y de dar mi primera conferencia en un evento internacional (ESSOS 2010, en Pisa, probablemente la conferencia de la que menos orgulloso estaré en mi vida por culpa de lo nervioso que estaba) para luego orientar lo que había ido aprendiendo en distintos proyectos en los que iba colaborando a la detección de tráfico de control de botnets empleando modelos de aprendizaje automático. 

En pocas palabras, y con la ayuda incalculable de compañeros como Sete, empezamos a plantear una batería de muestras de tráfico benigno que anonimizamos y cruzamos con tráfico malicioso de diferentes botnets. Con sus limitaciones, la aproximación que se proponía era ser capaces de extraer patrones relevantes de ese tráfico malicioso para identificarlo entre muestras de tráfico legítimo.

4.- Señor Felix Brezo Fernandez, nacido en Santander, ¿de qué equipo de fútbol dices que eres?

Como dicen que los de Bilbao nacemos donde queremos, soy socio del Athletic Club desde el 7 de enero de 1988, 32 añitos ya. Eso sí, en este tiempo solo hemos levantado una Supercopa y algunos estamos deseando desempolvar la gabarra de una vez por todas. Los días grandes de partido, no es extraño verme también por Oeste 1 con el que es mi verdadero traje de los domingos, es decir, el de la camiseta del Athletic.

5- Este no es tu primer libro, también eres autor del libro de BitCoin & Blockchain de 0xWord. ¿Te vas a animar a seguir escribiendo?

Tengo varias ideas en la cabeza sobre temas relacionados con la impresión 3D y la seguridad física y otras más técnicas sobre desarrollo de plugins de navegador y extensiones. Entiendo que no son temas precisamente mainstream, pero mi idea es aprovechar para sintetizar cosas que me he ido haciendo por mi cuenta, completarlas y ordenarlas de una forma estructurada en que sí le pueda servir a otros. Me frustra bastante acumular documentos y ver que quedan en una carpeta perdida más y creo que esta es buena forma de darles salida.

6.- Y hablando de BitCoin y las Criptodivisas. ¿Crees que el mundo evolucionará hacia métodos de pago más privados basado en ellas o que por el contrario desaparecerá el dinero físico como dicen algunos y todas las transacciones serán controladas por el gobierno para acabar con el fraude?

Es la pregunta del millón y no tiene una respuesta sencilla. Los que creemos en la importancia de los servicios públicos somos conscientes de que estos hay que financiarlos con impuestos y la lucha contra el fraude es una herramienta fundamental. Mientras que el origen del dinero en efectivo es difícil de rastrear, parecía que el uso del dinero digital podría ayudar a la lucha contra el fraude a través de servicios más o menos de centralizados en torno al ecosistema bancario tradicional. Y eso asumiendo las concesiones en materia de privacidad ante los gestores de dichas operaciones.

Figura 5: BitCoin: La tecnología Blockchain y su investigación

Pero la llegada de las criptodivisas lanzaba nuevas posibilidades para presentar métodos de pago alternativos que no necesitan de entornos centralizados y que introducen la tecnología como una herramienta de pago anónima que puede escapar, si no se usa de acuerdo a la ley, a la vigilancia global. Esta cuestión tiene mucho que ver con uno de los debates de las próximas décadas acerca de cuál es el límite tolerable de intromisión de un estado democrático en nuestras vidas y cómo se gestiona esa información.

Y lo estamos viviendo ya. ¿Nos plantearíamos si es correcto el uso de la información de nuestros móviles para identificar posibles focos de infección por coronavirus y mitigar los riesgos? ¿Y el registro de todas nuestras operaciones financieras para combatir el fraude? ¿Es transparente y auditable el uso de esas tecnologías por ciudadanos anónimos para prevenir posibles abusos? Cada pregunta puede tener su propia respuesta pero todas ponen de manifiesto que los avances tecnológicos tienen que ir de la mano de valores éticos acorde con el uso que les queremos dar respetando, siempre, siempre, los derechos de las personas.

7.- ¿Eres de los que prefieres un mundo gratuito pagado con tus datos y tu tiempo, o pagar por tus servicios - todos ellos -?

Para mí es más una cuestión de soberanía que de modelos de financiación. A mi encantaría tener la información adecuada acerca del tratamiento que se da a mi información cuando no soy yo el que la gestiona. Puedo estar dispuesto a participar en ambos modelos, pero la prioridad pasa por estar bien informado sobre las consecuencias de cada uno de ellos para mis datos.

Desde el punto de vista de la soberanía, una de las cosas que más rabia me da son las trampas que hacen muchas organizaciones a la hora de facilitar el proceso de darse de baja o la gestión de los permisos en un servicio. Proyectos como justdelete.me (recomendable visita) recogen los enlaces para borrarse de diferentes plataformas, pero creo que ponen de manifiesto la falta de voluntad de muchas organizaciones a la hora de renunciar a nuestros propios datos.

En este sentido, en 2018 Yaiza y yo propusimos en un Internet Draft (en Github y en IETF) la creación de un fichero oblivion.txt a imagen y semejanza del robots.txt, del humans.txt o del security.txt en el que se recogiera de forma estructurada los enlaces para darse de baja, desactivar la cuenta o para recuperar el control de tus propios datos.

A veces tengo la sensación de que no hay una voluntad real de ofrecer ese derecho de verdad y, como reconozco que me enfada, me siento más cómodo con modelos que apuestan por soluciones libres y que huyen del modelo Service as a Software Substitute. ¡Quiero tener la opción de poderme complicar la vida gestionando mis servicios y mis plataformas!

8.- ¿League of Legends o Clash Royal? ¿Cuál prefieres? ¿Son gratuitos o de pago?

Yo soy de Clash Royale con un récord de copas de 6171 trofeos que es bastante digno pero del que uno no sabe si debería estar demasiado orgulloso. Son gratuitos pero tienen un modelo de micropagos por skins y boosteos para acelerar las subidas de nivel de cartas. Su éxito seguramente ha sido encontrar el equilibrio entre un modelo de micropagos y dando con la tecla para que personas de tu entorno puedan colaborar y jugar contigo y no contra ti sin sentirse frustrados. 

En PC, juego de vez en cuando al PUBG con algún compi y amiguetes a los que se les da mucho mejor que yo, pero con los que me lo paso bien jugando en equipo y comentando las noticias mientras jugamos. Y sí, uso Windows para el PUBG, el SAP (en la oficina me entenderán) y Microsoft Office. De la implementación de los estándares ISO para documentos ofimáticos o de los tipos de letra propietarios hablamos en otro post.

9.-Desde que te conozco eres una persona con muchas inquietudes en tu cabeza. Te encanta meterte en nuevos proyectos e ideas. ¿En qué andas pensado ahora?

Técnicamente, estoy bastante implicado con la descentralización. Últimamente estoy leyendo bastante sobre mesh networking (proyectos como Briar), herramientas F2F como Retroshare o Freenet y sistemas federados tipo Mastodon o Matrix.org. Todo lo desplegable y usable a priori apetece.

Figura 6: Deep Web: Privacidad y anonimato

A nivel personal, tengo un año y poco de la carrera de derecho y me gustaría encontrar este año tiempo para retomarla. Creo que es importante que los más técnicos nos impliquemos en la definición de las normas que van a regir las relaciones de las personas los próximos años y tenemos mucho que aportar para que quienes deciden se equivoquen lo menos posible. 

Además, muchos juristas comparten actitudes con quienes trabajan en la parte técnica cuando tratan de reversear las leyes y adecuarlas a cada caso. ¿O cómo podríamos llamar a la posibilidad de saltarnos los controles adicionales que establece el artículo 168 de la Constitución Española para la reforma de algunos artículos de especial protección cuando el título que otorga dicha protección no se protege a sí mismo? ¡Las leyes también pueden ser hackeadas y por eso hay que bastionar nuestros derechos!

10.- Recomiéndanos tres libros -no políticos- que hayan cambiando la forma de ver la vida o el mundo a Felix Brezo.

Más que de libros te hablaré de series y personajes. Uno de los que me despertó la curiosidad por el mundo de los detectives era el personaje de Flanagan, un chaval barcelonés que protagonizaba la serie de libros de detectives de Andreu Martín y Jaume Ribera. 

Ya algo más mayor, me enganché a la serie de libros del Capitán Alatriste. Esa España llena de claroscuros que empezaba a dejar de ser hegemónica para terminar con episodios casi decadentes pero a los que aún quedaba algo de brillo heroíco que sacar tiene un no sé qué romántico que me sigue llegando ("El honor era luchar, sin la esperanza de vencer...").

Figura 7: Obras completas de El Capitán Alatriste

Si un género me gusta es el del espionaje. Me trago todo. Si es ficción, me da casi igual que sea Tom Clancy o Le Carré, el nuevo Bond de Anthony Horowitz o el Criptonomicón de Neal Stephenson. Cuando está de por medio la criptografía y los secretos de estado y además se entremezcla con esas historias reales pero que parecen de película de la guerra fría ya me tienen ganado.

Figura 8: El criptonomicón

De todas formas, por quedarme con uno, lo haría con "El huevo del Cucko" de Clifford Stoll. Es una historia real sobre una intrusión que detectó por accidente en su laboratorio y sus primeros contactos con un organismo entonces bastante desconocido como la NSA. Se cuenta con lo que hoy parecería una ingenuidad casi infantil para muchos profesionales cómo se empiezan a valorar las vulnerabilidades en las aplicaciones y el rastreo de la identidad de la atacante y eso engancha aunque estén hablando de 1986.

11.- ¿Qué le recomendarías a jóvenes que comienzan su carrera profesional en el mundo de la tecnología?

Encontrar un ámbito en el que te sientes cómodo y sientes que haces cosas por los demás es importante porque te mantiene motivado. Los gustos de cada uno son muy personales pero la curiosidad y las ganas de leer y de buscar y de volver a buscar tienen que ir en el pack sí o sí.

Por incidir en otros aspectos que no son en absoluto técnicos y que muchas veces nos dan pereza pero que rentan a la larga: organizarse bien las tareas que tienes pendientes (checklists, apps, etc., hay de todo), hacer un verdadero esfuerzo por escribir bien tu idioma y documentar lo que haces para poder repetirlo cuando lo necesites y darle caña al inglés porque sigue siendo lengua vehicular en internet. Perdiendo el miedo a leer, entender y preguntar se hacen también relaciones.

The Punisher & The Most Secure FTP Server [Spoiler Alert] #ThePunisher #SpoilerAlert

Normalmente me gusta prestar mucha atención a lo que está pasando en las series. Me encanta ver Elementary e intentar descubrir al asesino antes que Sherlock Holmes - de esta serie hay algunos capítulos fantásticos que tienen que ver con tecnología, como el de la IA del que os hablaré en algún momento-, o fijarme que el Sistema Operativo de Robocop está basado en un MS-DOS pero con el punto cambiado en el Command.com, o que en Mr. Robot no usaba passcode para el iPhone en el primer episodio de la primera temporada o, como os dejé hace poco, en Stranger Things usan una tabla periódica del futuro.

Figura 1: The Punisher & The Most Secure FTP Server [Spoiler Alert]

Ahora estoy disfrutando The Punisher, y ayer noche, en el carrusel de capítulos que me enchufé, me topé con una escena que me encantó. Si la quieres ver, para aquí, porque puede que te haga algo de SPOILER, así que como aún no la ha visto mucha gente, no está permitido desvelar cosas sin avisar. No como con el final de los Sopra... [Fade to black]

Me encanta The Punisher. La tengo que ver a escondidas de mi Hacker & Survivor, que se asustan }:)

A post shared by Chema Alonso (@chemaalonso) on Nov 19, 2017 at 10:21am PST

[Spoiler Alert Begins Here]

En la escena, Micro (uno de los personajes principales de la serie) está a punto de subir un fichero a un servidor FTP para enviar un correo electrónico con un enlace al fichero a una persona de la NSA. Se supone que nuestro amigo Micro es miembro de la NSA, y para ello tiene una cuenta en The Most Secure FTP Server. La imagen y estética de la web del servidor FTP es espectacular.

Figura 3: El servicio FTP más seguro de la red: Ouh, yeah!!

La he subido a alta resolución por si queréis revisar todos los detalles con cuidado, que las carpetas y ficheros sin nombre en el desktop también tienen su gracia. Sin duda, lo más curioso es el navegador, la web del servicio FTP y la lista de medidas de seguridad que dice disfrutar el sitio, que podemos revisar una a una:

- Supports an Unicode Password: Esta es buena, se supone que puedes poner contraseñas con caracteres no imprimibles, lo que le da una gran seguridad a la contraseña para que alguien la averigüe. Por supuesto, para hacer más compleja la contraseña, a la derecha, debajo del login tenemos información de que la contraseña debe ser de más de 12 caracteres. 

Al final, está metiendo una contraseña compleja a un servicio online como forma de autenticación segura, algo que no es ni de lejos lo más seguro. Lo suyo es una autenticación multifactor, utilizando Tokens OTP o algo como Latch, certificados digitales, e incluso biometría - aunque esto iría un poco contra la privacidad - pero desde luego no meter contraseñas complejas, algo que tenemos que erradicar de los servicios online dando prioridad a los 2FA.

-  Completely anonymous e2e encryption: A lo largo del proceso no se ve muy claro cómo hace el e2e encryption, ni si se refiere a cuando el fichero se sube al servidor FTP o cuando se envía el correo electrónico vía enlace en un e-mail al destinatario, pero desde luego, para hacer el e2e el fichero debe ser cifrado en el cliente y descifrado en la máquina del destinatario, algo para lo que se necesita algún intercambio de claves entre emisor y receptor. Por supuesto, esto no pasa en ningún momento en la escena, así que el cifrado de las comunicaciones lo hacen reguleramente.

Figura 4: El servidor envía un e-mail cifrado con un enlace

Además, hay dos momentos en los que habría que cifrar. El primero cuando se sube el fichero al servidor FTP para que no quedara una copia un-encrypted en el disco duro del FTP, y una segunda cuando se cifra el e-mail. Dos veces en los que se debería usar la clave de cifrado del destinatario, algo que no aparece por ningún sitio. Raro, raro. Deberían dar un repaso al libro de Criptografía y cifrado de las comunicaciones digitales. 

- Free and Open Source: Genial. Eso significa que es Free and Open Source y por tanto, se supone que el código puede ser revisado por cualquiera para garantizar que no tiene bugs o puertas traseras - aunque luego pase como con TrueCrypt y toda la polvoreda de especulaciones que se levantó -. Ahora bien, eso tendría que comprobarlo el emisor en el cliente a la hora de cifrar y destinatario a la hora de descifrar, pero lo que haya en el servidor Web/FTP puede estar manipulado por cualquiera, así que está muy bien que lo pongan en la web de login, pero tiene poco sentido. Eso sí, da color.

- Metadata Protection: Esta es buena. Un hook a la memoria americana y el caso de las filtraciones de Edward Snowden con las políticas de Metadata Retention y el famoso PRISM que otorgaba a la NSA acceso a conexiones y llamadas de teléfono entre personas. En el caso del servidor FTP, se supone que ¿no guardan logs de conexión? 

Está claro que aunque el servidor no guarde logs de conexión, por el medio hay muchos dispositivos de red que pueden guardar logs del proceso, por lo que lo suyo sería no fiarse y conectarse vía TOR de forma segura - y desde una conexión que no esté en tu casa mejor que mejor -.

Además, el servidor está bajo un dominio .NET, lo que implica que no está en un hidden service y está sujeto a una legislación que debe cumplir y que si no lo hace, puede ser intervenido. Vamos, que lo del anonimato en las conexiones está regulera también.

- Antispam & Blacklist filters: Esta parte la he tenido que tomar con mucha imaginación para darle algo de sentido. He querido ver que, como se envía un mensaje de correo electrónico con el enlace al fichero en el servidor FTP Super-Seguro, el servidor tenía medidas para garantizar que el mensaje de correo electrónico que se envía ¿se va a saltar los filtros antispam y las listas negras?

Figura 5: El fichero ha sido enviado con un link vía AES. Oh, tell it again!

Desde luego no diréis que no he hecho un ejercicio de imaginación para interpretar estas medidas de seguridad en un servidor FTP. Aún así, garantizar que el mensaje va a saltarse eso es muy complicado, ya os dejé un artículo que explicaba ¿por qué mi correo electrónico llega como spam? Además, que se use AES para recibir el enlace al fichero ¿significa que se utiliza AES en el cifrado e2e del correo?

- Clock & Time-Zone Spoofing: Otra buena. Con mucha imaginación he querido ver que alguien se había leído los trabajos de investigación de mi amigo Sergio de los Santos para medir las zonas horarias de los archivos usando los metadatos del sistema operativo y del fichero ZIP. Vamos, que están preocupados por herramientas como nuestro GMTCheck de ElevenPaths, y que hacen una modificación de estos metadatos antes de cifrar e2e los ficheros. Esa herramienta se utilizó para investigar WannaCry. Mola, ¿no?

Figura 6: GMTCheck de ElevenPaths

- Multiples instances of server: Esta debe ser para evitar los ataques DDOS y ser resiliance ante intentos de eliminar el servicio de la red. Algo que si se basa en el nombre de dominio DNS no tiene mucho sentido para nada. Pero... vamos a jugar al pacto de ficción. Esto, además, será necesario para enviar el fichero desde 16 direcciones IP aleatorias para evitar que alguien en un man in the middle pueda recomponer el fichero cifrado. Rebuscado.

- Quick, encrypted set up: Configuración rápida y, eso sí, cifrada. Para que cuando te des de alta en tu cuenta gratuita todo vaya rápido, muy rápido y cifrado, muy cifrado.

Después de ver las medidas, me acordaba de este servidor FTP del ejercito de los Estados Unidos de América que tenía un mejor sistema de seguridad. Uno muy claro: Este servidor es inseguro pero ni lo toques.

Figura 7: Este servidor es inseguro

Visto todo esto, al final como era de esperar nada más ver lo anterior, el malo de la NSA descubre inmediatamente quién ha enviado este correo con ese archivo - goodbye e2e encryption y anonimato-, y a la mañana siguiente van a por él para matarle. Eso sí, toma la precaución de ponerse el smartphone en el bolsillo del corazón que detiene la bala cuando es disparado como ya ha pasado en la realidad. Un hacker precavido siempre guarda el smartphone ahí.

Figura 8: Al final la tecnología salva la vida de Micro parando la bala

Dicho esto, Micro se supone que es un hacker experto, así que lo de utilizar este servidor FTP tan seguro vía una web en HTTPs es cuanto menos poco creíble. Menos aún que envíe un CD/DVD con el vídeo - ¡ni tan siquiera un pendrive! - o que no haya hecho un análisis de los metadatos del mp4 antes de enviarlo ¡hombre, será posible!.

[Spoiler Alert Ends Here]

Esto no es nada más que una curiosidad. La serie mola mucho. El protagonista lo hace tan bien como lo hizo en Walking Dead y en la segunda temporada de Daredevil. Me encanta. Eso sí, no la veas con niños menores a los que les gusten los superhéroes si no conoces bien a Frank Castle, porque la sangre y los asesinatos son un continuo.Ya sabéis, si quieres saber dónde está The Punisher, solo debes seguir el rastro de cadáveres. Recuerda, If you are guilty...

Saludos Malignos!

Tunelizar conexiones con Proxychains

El concepto de tunelizar y saltar entre máquinas puede parecer, en algunas ocasiones complejo. Esto no es así, tal y como se verá en este artículo. Además, proporciona cierto anonimato, lo cual podría ser utilizado por un atacante para preservar la dirección IP desde la que está trabajando. Pero esto también puede ser bueno para un pentester en caso de que este conectado desde una dirección que esté bloqueada y necesite saltar el bloqueo. Vamos a ver cómo se puede pivotar tunelizando conexiones y saltando entre máquinas.

Figura 1: Tunelizar conexiones con proxychains

El concepto de pivoting entre máquinas también viene asociado a esto y es que si proponemos un escenario de pentesting en el que:

• Máquina A no tiene conectividad con la máquina C: Hay un firewall que nos bloquea.
• Máquina B si tiene conectividad con la máquina C.
• Túnel de A a C, pasando por B: Si logramos acceso a la máquina B, podremos utilizarla para desde la máquina A pasar por la máquina B y lograr conectividad con la C.

Figura 2: Esquema del escenario. La máquina del atacante está bloqueada.

El esquema representa el escenario anterior. Por alguna razón no tenemos conectividad con la máquina que queremos auditar / atacar, pero encontramos una máquina que tiene permiso para conectar con el objetivo. Utilizaremos una forma de pivotar nuestras peticiones.

¿Cómo logro acceso a la máquina pivote?

Esto es un debate siempre en los cursos, hay muchas formas, y es que habrá que auditarla y conseguir acceso a esa máquina. Generalmente, mediante el aprovechamiento de una vulnerabilidad en la máquina intermedia utilizando algún exploit. Existen otras formas menos directas como es el robo de alguna credencial de dicha máquina o, incluso, la realización de fuerza bruta en busca de alguna debilidad. Sea como sea partimos de que tenemos control sobre dicha máquina.

Utilizaremos conexiones SSH para acceder a la máquina con las siguientes opciones:

• El parámetro –N: Le decimos a la máquina remota que no ejecute ningún comando a través de la sesión abierta de SSH.
• El parámetro –f: Deja la conexión SSH en background una vez nos autenticamos.
• El parámetro –D: Crea un túnel para realizar port-forwarding. Este es el parámetro dónde se está creando el servidor SOCKS. El puerto que se queda abierto en nuestra máquina es el que se indica con el parámetro –D, por ejemplo utilizaremos 1080. Todo lo que enviemos desde nuestra máquina al puerto 1080 será redirigido hacia el túnel SOCKS que estamos creando.

Preparando el pivote

La instrucción que se ejecuta es ssh –NfD [puerto a la escucha en local] [user ssh]@[ip]. Como se puede ver en la imagen, la dirección IP del primer pivote acaba X.X.9.95. Este es un detalle para más adelante.

Figura 3: Configuración de ssh en la máquina pivote

Tras autenticarnos tenemos la conexión y el túnel montado entre nuestro puerto 1080 y una máquina remota. Utilizaremos proxychains para pasar por la máquina intermedia. Editando el fichero de configuración que se encuentra en /etc/proxychains.conf tenemos que tener en cuenta la dirección IP a la que enviar el tráfico, en este caso será nuestro propio localhost y el puerto a la escucha, en este caso el 1080.

Hay que recalcar que este tipo de acciones se pueden hacer con pivotes, por ejemplo, obtenidos con Metasploit y aprovecharnos del potencial de un Meterpreter a través de varios saltos, pero eso será cuestión de otro artículo.

Figura 4: Configuración de proxychains.conf

En la imagen anterior se ve la configuración de proxychains. La que ahora mismo está preparada es la del puerto 1080. Utilizaremos proxychains para sacar el tráfico por la conexión. La sintaxis es sencilla en un terminal podemos escribir proxychains [nombre programa] y la aplicación sacará su tráfico por el túnel montado.

Para hacer un ejemplo rápido ejecutamos en Kali Linux el comando proxychains iceweasel. Al navegar a un sitio de consulta de dirección IP pública veremos que acaba en 9.95, por lo que es la dirección IP de la máquina pivote.

Figura 5: Navegando a través de la máquina pivote

Si desde Iceweasel intentamos abrir una conexión HTTP con otra máquina y en esa máquina tenemos acceso podríamos ver con tcpdump una captura de red y ver la dirección IP origen. El resultado es igual, la dirección IP origen es la que acaba en 9.95, por lo que volvemos a ver que el receptor de las peticiones ve como emisor a otra dirección IP.

Figura 6: Tráfico capturado por tcpdump a través del máquina pivote

De este modo, el caso del bloqueo del firewall quedaría resuelto, si la dirección IP acabada en 9.95 tiene permiso.

Metiendo más saltos: Chain++

Meter más máquinas en la conexión es sencillo con proxychains. Simplemente tenemos que añadir al fichero de proxychains.conf una nueva dirección IP, la cual seguirá siendo nuestro localhost de nuevo, y un nuevo puerto. Es importante que los puertos no coincidan, por lo que ahora utilizaremos el 1081.

Figura 7: Añadiendo otro salto en proxychains.conf

Abriendo una conexión SSH entre la máquina pivote 1 y pivote 2, será proxychains el que hará que el tráfico pase primero al privote 1, luego al pivote 2 y posteriormente llegue al destino. En la siguiente imagen se puede ver un ejemplo claro y sencillo de ello. Utilizando el programa curl pedimos el recurso al dominio ip.appspot.com, el cual sencillamente te da la dirección IP que hace la solicitud.

Cuando hacemos la petición sin proxychains vemos que nos proporcionan una dirección IP X.X.9.148, mientras que cuando utilizamos proxychains obtenemos una dirección IP X.X.6.9, la cual no es la que teníamos antes (que se quedó siendo el primer pivote). Ahora en el destino obtenemos que el tráfico viene de la dirección IP del segundo pivote.

Figura 8: petición curl vía proxychains a ip.appspot.com

Como se ha podido ver es fácil encadenar máquinas y pivotes para sacar tráfico de forma anónima o utilizar las cadenas para bypassear mecanismos de seguridad en una auditoría. Esto se puede juntar con Metasploit y obtener un gran potencial de la mano de un Meterpreter en una post-explotación, pero como dije anteriormente: queda para otro artículo.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”