Get File Drive Sub Modulo

Module 1: Introducción al
pentesting
2018
CYBER GRADUATE -
- ICSP v.2 -
iHackLabs Certified Student Penetration Tester
Copyright ..........................................................................................................................3
Módulo 1 - Introducción ............................................................................................4
¿Qué es un Pentest? ................................................................................................. 5

Pasos Previos .........................................................................................................................................................................6
Tipos de Pentest ............................................................................................................................................................. 7
Auditoría de Caja Negra (Black Box)......................................................................................................................................................... 7
Auditoría de Caja Blanca (White Box) ...................................................................................................................................................... 7
Auditoría de Caja Gris (Grey Box) ............................................................................................................................................................... 8
Terminología ..........................................................................................................................................................................9
Evaluación de Vulnerabilidades ......................................................................................................................... 10
Test de Penetración – Pentest ............................................................................................................................... 11
Metodologías ....................................................................................................................................................................... 12
OWASP (Open Web Application Security Project) .................................................................................. 12
OSSTMM (Open Source Security Testing Methodology)...................................................................... 13
ISSAF (Information System Security Assessment Framework) ........................................................ 13
PTES (Penetration Testing Execution Standard) ....................................................................................... 14
Fases de un pentest ........................................................................................................................................................ 15

Pasos Previos ................................................................................................................................................................. 16
Recopilación de Información ................................................................................................................................17
Análisis de Amenazas.............................................................................................................................................. 20
Análisis de Vulnerabilidades ................................................................................................................................ 22
Fase de Explotación .................................................................................................................................................. 26
Post-Explotación ......................................................................................................................................................... 27
Informes ................................................................................................................................................................................. 28
Generación de Informes ........................................................................................................................................ 29
Como No Redactar un Informe....................................................................................................................................................................32
Planificación de un Informe.................................................................................................................................. 33
Recopilación de información ........................................................................................................................................................................33
Borradores ................................................................................................................................................................................................................33
Revisión final........................................................................................................................................................................................................... 34
Plantillas ........................................................................................................................................................................... 34
Diseño Corporativo ............................................................................................................................................................................................ 34
Portada del Informe ........................................................................................................................................................................................... 34
Propiedades del Documento ....................................................................................................................................................................... 35
Control de Versiones ......................................................................................................................................................................................... 35
Tipos de Informes ....................................................................................................................................................... 35
Informes Ejecutivos............................................................................................................................................................................................. 35
Informes Técnicos ............................................................................................................................................................................................... 36
Informes Mixtos ..................................................................................................................................................................................................... 36
Estructura de un Informe........................................................................................................................................ 37
Informe Ejecutivo .................................................................................................................................................................................................. 37
ICSP v2
iHackLabs Ltd. © 2018
All Rights Reserved 1
- ICSP v.2 -
Informe Técnico ................................................................................................................................................................................................... 38
Entrega de Informes ....................................................................................................................................................... 40

Entrega a Cliente ........................................................................................................................................................ 40
Entrega a la Empresa ............................................................................................................................................... 40
Recomendaciones ...................................................................................................................................................... 41
Checklist Rápida ......................................................................................................................................................... 42
ICSP v2
- ICSP v.2 -
Copyright
HM Revenue & Customs
Registrar of Companies for England and Wales
IHACKLABS Ltd.
Company Number 10246354
All rights reserved. No part of this publication may be reproduced, distributed, or transmitted
in any form or by any means, including photocopying, recording, or other electronic or
mechanical methods, without the prior written permission of the publisher, except in the case
of brief quotations embodied in critical reviews and certain other noncommercial uses
permitted by copyright law.
For permission requests, write to the publisher, addressed “Attention: Permissions Coordinator,”
at the address info@ihacklabs.com
Copyright © 2018 by IHackLabs
ICSP v2
- ICSP v.2 -
Módulo 1 - Introducción
El propósito de este curso es consolidar los conocimientos del alumno en el demandado y
competitivo ámbito laboral de la seguridad informática.
Dentro del área de la seguridad el curso se centra en profundidad en la metodología y el

desarrollo de las pruebas de penetración dentro del área de infraestructura.
Aun siendo el curso orientado a análisis de infraestructura se ha considerado imprescindible

para un nivel profesional el añadir módulos de introducción a aplicaciones web y exploiting
para beneficio y aprendizaje del alumno.
Esperamos que este curso sea de su agrado, que disfruten en los laboratorios y que apliquen
con éxito a su carrera profesional los conocimientos adquiridos.
ICSP v2
- ICSP v.2 -
¿Qué es un Pentest?
El término pentest (Penetration Test) es utilizado en el ámbito de la seguridad cuando se
realiza una prueba de intrusión o test de penetración en una empresa a través de sus
sistemas de manera controlada.
Estas pruebas de intrusión son realizadas por un equipo o por una persona que evalúa el
estado de la seguridad de los sistemas e infraestructura de una empresa.
Existen multitud de razones por las que una empresa debe realizar pruebas de penetración
periódicamente, ya sea por normativa como la GDPR, ya sea porque han tenido intentos de
intrusión reales o a nivel preventivo.
Cuando una empresa solicita un pentest es porque quiere conocer el estado de seguridad
de su infraestructura y desea evaluar su nivel de riesgo y exposición ante un ataque real o
una intrusión no autorizada.
El objetivo de un pentest es la de acceder al sistema o lograr un objetivo previamente

establecido con el cliente.
Cualquier prueba de pentest sobre sistemas ajenos que previamente no se haya acordado
y pactado mediante contrato es ilegal y puede llevar a la empresa a tomar medidas contra
la persona o grupo de individuos que estén realizando las pruebas. Por lo tanto, la teoría de
voy a buscar vulnerabilidades en internet puede resultar siendo una aventura muy cara.
Antes de comenzar el pentest los profesionales habrán realizado un análisis de los sistemas
y servicios instalados que están expuestos a ser atacados, una vez iniciado el pentest el
profesional intentará por diferentes medios acceder a los sistemas burlando de esta manera
la seguridad de la empresa.
Una vez logrado el acceso, se procederá a la explotación de los sistemas o de los servicios
que se están ejecutando y finalizado el pentest se entregará al cliente un detallado informe
del estado de su seguridad, las vulnerabilidades encontradas y las recomendaciones para
mitigarlas.
Estos profesionales que realizan las pruebas de penetración deben estar preparados para
analizar, evaluar y explotar las vulnerabilidades que han sido detectadas durante el
transcurso de este, así como presentar la información de manera clara y concisa al cliente.
Por lo tanto, la fase de documentación y explicación de los hechos es realmente importante,

y debe de ser la parte donde más tiempo debemos dedicar nuestra atención, puesto que un
informe mal presentado o incompleto puede provocar que no contraten de nuevo a nuestra
empresa o a nosotros en el caso de ser autónomos.
ICSP v2
- ICSP v.2 -
Pasos Previos
A nivel corporativo es necesario que ambas partes tengan decidido qué tipos de prueba y
cómo van a llevarse a cabo para poder presentar propuestas comerciales, definir su
duración y el coste de este, de ahí la importancia de tener claramente definidos los diferentes
puntos que se van a analizar antes de comenzar.
Cada cliente tiene unas necesidades diferentes, pero por lo general estos son algunos de los
puntos comunes que se estudian en la planificación.
Ámbito.
Debe definirse que parte de la infraestructura va a analizarse como Wi-Fi, aplicaciones

móviles, intranet, aplicaciones web etc.
Debe definirse el entorno a analizar, no es lo mismo atacar un entorno de preproducción que

un entorno producción real que puede ver afectado su servicio.
Es necesario definir cómo se van a tratar las vulnerabilidades que se encuentren en servicios
de terceros.
Tipo de pentest.
Caja negra, caja blanca o gris, el tipo de pentest debe decidirse y quedar por escrito, así
como los medios que van a proporcionarse al auditor y el lugar de realización de este, tanto
si es remoto como si local debe definirse en el alcance o propuesta de trabajo.
Nivel de intrusión.
Hay que definirlo también, no es lo mismo acceder como root a los sistemas que
simplemente obtener información de ellos explotando parte de una vulnerabilidad.
Medios de comunicación.
Es necesario saber quién va a tener acceso a los resultados finales y su nivel de

confidencialidad. Hay que definir qué personas van a estar involucradas en las pruebas, con
qué frecuencia van a presentarse los resultados y a quienes deben ser entregados.
Planificación.
Horarios, ámbito y localización en los que se puede realizar el pentest y los días para de este
modo poder calcular las jornadas/hombre que son necesarios. Es necesario por lo menos,
reservar un día extra para la redacción del informe.
Contrato.
Una empresa de seguridad a nivel legal, entre otros tiene unas responsabilidades sobre
confidencialidad, exclusividad y tratamiento de datos que deben cumplirse sin excepción
independientemente de los contratos comerciales que se firmen posteriormente con el
ICSP v2
- ICSP v.2 -
cliente. Del mismo modo debemos de cumplir a estrictamente la protección de datos y la

nueva ley GDPR, para evitar multas o sanciones por parte de la administración.
Los departamentos legales y comerciales junto con los gerentes de cuenta y los clientes
definen este tipo de detalles. Los contratos deben quedar firmados por ambas partes antes
de comenzar las auditorías.
Aunque el Pentester no interviene en estas negociaciones es imprescindible que sepa que se

ha acordado para poder preparar su trabajo, de no tener esta información es necesario
solicitarla a quien corresponda.
Tipos de Pentest
Existen diferentes tipos de prueba de penetración que se pueden realizar, basados en el lugar
en el que se realizan, la información de la que se dispone y el tipo de ataque que se simula.
Auditoría de Caja Negra (Black Box)

Una auditoría de caja negra es muy demanda por que simula un ataque real de un hacker
con malas intenciones.
En este tipo de auditoría al profesional no se le proporciona ningún tipo de documento

técnico, mapas de red o usuarios del sistema. Suelen realizarse en remoto.
Puesto que el ataque a ciegas una multinacional puede llevar meses, para optimizar el
tiempo las empresas suelen entregar una IP o un rango de IPs para que sean analizadas.
Con las direcciones IP recibidas debemos ser capaces de crear un mapa aplicativo, un mapa
organizativo y utilizando la información recabada debemos tener éxito en la intrusión.
Al no disponer de información sobre la infraestructura que forma la empresa el auditor

deberá por tanto ir generándola a lo largo del pentest redactando un borrador donde se
almacenará la información para luego catalogarla y analizarla.
Es por ello por lo que es muy importante seguir bien las fases que componen un pentest y
ser muy estrictos y organizados con la información que vayamos encontrando y recopilando
evidencias según se vayan encontrando.
Por lo tanto, el tiempo de la auditoría puede ser largo o corto y el éxito de la auditoría se
basará en el ingenio y los conocimientos usados por el auditor para explotar los sistemas
con éxito.
El CTF del laboratorio de Hacking es el mejor ejemplo de Black Box puesto que el alumno no
dispone de información de la infraestructura o los sistemas que la componen.
Auditoría de Caja Blanca (White Box)

Llegamos a la parte en la que el auditor tiene más trabajo, pero tiene más probabilidades de
éxito en su pentest.
ICSP v2
- ICSP v.2 -
En esta auditoría se dispondrá de toda la información necesaria para realizar la prueba de

intrusión, usuarios con diferentes privilegios, mapas de red, firewalls, aplicativos...
Este tipo de prueba se demora en el tiempo porque se deben de analizar muchos

componentes de la infraestructura al igual que realizar una prueba exhaustiva del software,
revisión de código y las versiones instaladas en los sistemas.
Al disponer de información sobre los sistemas, usuarios, información sobre la arquitectura y

diseño de la infraestructura los vectores de ataques se multiplican por tanto es necesario
analizar y evaluar cada uno de ellos demorando de este modo los resultados de la auditoría.
No debemos de olvidar que todos los test de penetración que se realicen tendrán siempre el
mismo procedimiento y es el de recopilar, analizar y explotar el sistema vulnerable para llegar
al objetivo marcado, no el de evaluar las vulnerabilidades y el de valorar sus riesgos.
Este concepto puede resultar extraño, pero más adelante veremos la diferencia entre
evaluación de las vulnerabilidades y un pentest.
Auditoría de Caja Gris (Grey Box)

Nos encontramos entre una auditoría de caja blanca y una auditoría de caja negra.
Suelen realizarse parte en remoto y parte en las oficinas del cliente.
Normalmente este tipo de auditorías suelen evaluar el nivel de salud en el que se encuentran
en la organización ante un ataque externo o interno.
Este tipo de auditorías mixtas se solicitan para poner a prueba la infraestructura externa sin
descuidar la seguridad interna de la compañía.
Se proporcionarán datos de infraestructura, cuentas de usuario habitualmente sin privilegios,

información general sobre las aplicaciones a analizar y seguramente instrucciones concretas
de las partes que deseen ser analizadas.
Según los datos analizados por especialistas, es más común una fuga de datos desde dentro
de la empresa que desde un ataque externo.
Normalmente los ataques internos o la fuga de datos se deben en gran parte a empleados
descontentos que disponen de acceso a información sobre la infraestructura y acceso a los
sistemas, habitualmente con usuarios limitados.
La información proporcionada permite al auditor conocer mejor la infraestructura de modo

que le facilita la prueba de intrusión, aunque también habrá que tener en cuenta que son
más los componentes que se deben analizar.
No hay que olvidar que este tipo de pruebas tienen repercusiones legales dependiendo del
país en el que las realicemos, esto es debido a que una prueba de un pentest es una
simulación de un ataque real y por consecuencia una posible intrusión en un sistema.
ICSP v2
- ICSP v.2 -
Terminología
Llegados a este punto antes de continuar es importante tener claro algunos de los conceptos
de seguridad.
Es importante comprender la diferencia que existe entre el término pentest respecto al

término evaluación de vulnerabilidades, ambos términos están ligados pero su finalidad es
diferente.
Una evaluación de vulnerabilidades consiste en el proceso de evaluación de la eficacia de

los controles de seguridad de los sistemas, el ámbito de este proceso es descubrir todas las
vulnerabilidades a través de herramientas automáticas y acciones manuales.
Una prueba de penetración tiene un objetivo definido con el cliente y es logrado cuando se
explota una o más vulnerabilidades, independientemente de las que puedan existir en el
sistema.
El pentest se enfoca en una meta en concreto mientras la evaluación de vulnerabilidades

abarca el espectro más amplio posible del sistema.
Cada área requiere de técnicos especializados diferentes, estándares, certificaciones y

metodologías distintas.
Un ejemplo podría ser el de una persona que nos pide que comprobemos la seguridad de
su casa:
En un análisis de vulnerabilidades comprobaríamos la alarma, los cierres de las ventanas, las

rejas del patio, cerraduras, las copias de las llaves que existen, en un pentest buscaríamos la
manera de entrar rompiendo un cristal o a través de un butrón desde la casa contigua, una
vez dentro no importaría que otras maneras de acceder podríamos haber utilizado.
ICSP v2
- ICSP v.2 -
Evaluación de Vulnerabilidades
La evaluación de vulnerabilidades tiene por objetivo identificar y cuantificar la exposición de
un sistema ante el riesgo de ataques internos o externos.
Las empresas realizan estas evaluaciones para conocer en qué estado se encuentran a nivel
de seguridad para determinar y priorizar la solución de las vulnerabilidades según su
criticidad y riesgo con mayor precisión.
Cuantos más puntos de vulnerabilidad se encuentren más completo será el análisis,

otorgando un mejor enfoque y un mayor grado de entendimiento del estado en el que se
encuentra la organización.
El auditor presenta un informe completo con todas las vulnerabilidades encontradas,

categorizadas por impacto y riesgo.
Esta información permite definir con el cliente un plan de actuación según las
recomendaciones y según los riesgos con mayor precisión y realismo.
La frecuencia de estas evaluaciones debiera ser continua y puede ser realizado por personal
interno de la empresa.
La evaluación de vulnerabilidades no tiene como objetivo transgredir la seguridad de un

sistema.
ICSP v2
- ICSP v.2 -
Test de Penetración – Pentest

Está diseñado para lograr un objetivo concreto que no es otro que el de simular la posición
de un atacante real.
El objetivo de un pentest no es el de encontrar y analizar todas las vulnerabilidades al detalle

sino no acceder al sistema a través de ellas.
Este tipo de pruebas suelen ser solicitadas por clientes que conocen la salud de sus sistemas
y desean verificar el estado de estos.
Por otra parte, hay normativas que obligan a realizar estas pruebas periódicamente con
multas por incumplimiento, por ejemplo, en entornos bancarios el PCI DSS (Payment Card
Industry Data Security Standard) requiere un testeo anual y otro si se realizan cambios
importantes en la infraestructura.
Al finalizar el pentest se entregará un informe que será la prueba donde se expondrán las
evidencias de la explotación de las vulnerabilidades a las que se ha tenido acceso para
lograr el objetivo acordado, el resto de las vulnerabilidades halladas y categorizadas y su
posible impacto en el negocio.
Las pruebas de penetración son realizadas habitualmente por personal ajeno e

independiente a la compañía por lo que su precio suele ser elevado.
Resumiendo:
Evaluación de Vulnerabilidades Test de Penetración

•Exámen de vulnerabilidades •Exámen y explotación de una o mas vulnerabilidades
•Tareas automatizables •Tareas no automatizables o complicadas de automatizar
•Requiere de acciones manuales para evitar falsos positivos •Las acciones se realizan paso a paso manualmente
•Test básico / Test no intrusivo •Test en profundidad / Test intrusivo
•Coste medio •Coste elevado
•Registro y categorización de todas las vulnerabilidades de •Explotación de una o mas vulnerabilidades para lograr la
un sistema intrusión al sistema
•Tests periódicos y frecuentes •Tests y restests anuales
•Orientado a abarcar todo el espectro del sistema analizado •Orientado a lograr un objetivo en concreto
•Puede ser realizado por personal interno o departamento •Realizado habitualmente por consultores externos
de la empresa
ICSP v2
- ICSP v.2 -
Metodologías
Como en cada industria la nuestra también se rige por estándares, metodologías y marcos
de trabajo. Estos referentes, criterios y normas estructuran nuestras tareas y nuestras
actividades diarias.
Para realizar un pentest debemos de seguir una metodología, de este modo nuestro trabajo
puede ser ratificado y reconocido por otros profesionales. Es cortesía indicar que
metodología se ha seguido para realizar un pentest, facilita los re-test posteriores y da una
coherencia general a los resultados finales.
Vamos a hacer un repaso a las metodologías más utilizadas en la industria de la seguridad

informática, en las que colaboran profesionales de diferentes países.
OWASP (Open Web Application Security Project)

Esta metodología es empleada en todo el planeta y aceptada
internacionalmente para ser aplicada sobre las pruebas de penetración y
auditorías que se realizan sobre todo tipo de dispositivos e infraestructuras.
Posiblemente la más utilizada por todo tipo de profesionales del área de la

seguridad, sus guías son marcos de referencia para todo tipo de pentesters, desarrolladores,
consultores, administradores de sistemas y auditores de seguridad, entre otros.
Durante la lectura de la guía de OSWAP podemos ver con todo detalle los puntos que deben
de ser analizados en una aplicación web al igual que se explican los medios y técnicas que
se deben de utilizar para verificar dichos puntos.
OWASP dispone de diferentes guías y software desarrollado por una comunidad abierta y sin
ánimo de lucro.
Las guías más utilizadas son las siguientes:

 Guía OWASP para aplicaciones Web Seguras
 Guía de Testing OWASP
 Guía de Desarrollo OWASP
 OWASP Top 10 Aplicaciones Web
También dispone de Cheat Sheet o chuletas donde se recopila información concisa según
tópicos concretos.
https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
OWASP tiene diferentes proyectos abiertos donde es posible colaborar con ellos.
https://www.owasp.org/index.php/Category:OWASP_Download
ICSP v2
- ICSP v.2 -
OSSTMM (Open Source Security Testing Methodology)

Estándar internacional para el análisis y Security Testing.
Esta metodología cubre en profundidad partes como el área de

inteligencia competitiva y pone énfasis en el área de negocio. Otorga
certificaciones e imparte cursos.
Es una comunidad de código abierto y todo el material puede ser

descargado, utilizado y distribuido, dispone de plantillas para
prácticamente todas las pruebas que describe, también dispone de herramientas y sus
propias métricas, llamadas RAVs (Risk Assessment Value)
Estos RAVs distinguen tres categorías para elaborar sus resultados, combinados dan como
resultado un valor de seguridad del 0 al 100:
 Seguridad Operacional
 Control de Pérdidas (Interactivas, Clase A – Procesos, Clase B)
 Limitaciones de Seguridad
Merece la pena estudiar esta metodología en profundidad.
 http://www.isecom.org/research/osstmm.html
ISSAF (Information System Security Assessment

Framework)
Si bien existen metodologías y marcos de evaluación de seguridad de
la información estándar que hablan de qué áreas de la seguridad
deben ser consideradas no contienen información específica sobre
cómo y por qué se debe evaluar las medidas de seguridad existentes,
ni se recomiendan controles para salvaguardarlas.
La metodología ISSAF está diseñada para evaluar la red corporativa al igual que la
infraestructura que componen sus sistemas y sus aplicaciones. Para ello, según esta
metodología se emplean controles que abarcan las certificaciones de seguridad IEC/ISO
27001:2005(BS7799).
La metodología incluye tres fases siguientes:
 PRE ASSESSMENT Fase de planificación y preparación

 ASSESSMENT Fase de evaluación
 POST ASSESSMENT Fase posterior a la evaluación
http://sourceforge.net/projects/isstf/
ICSP v2
- ICSP v.2 -
PTES (Penetration Testing Execution Standard)

Este estándar contiene una serie de secciones que deben de realizarse
durante un pentest. Estas secciones abarcan todo lo relacionado con una
prueba de intrusión.
Este estándar cubre la comunicación con el cliente para hacerle entender el razonamiento
que existe detrás de un pentest, de este modo el cliente puede comprender como se lleva a
cabo las pruebas y como se investigan las mismas al igual que entender la explotación y
posterior explotación comprendiendo mejor la lógica de las pruebas
Al final de dicha prueba se escribe un informe orientado a un mayor entendimiento por parte
del cliente, proporcionándole un mayor valor al mismo.
Las siguientes secciones son las definidas para las pruebas y la ejecución de estas sirven
dentro de un pentest para evaluar el riesgo de seguridad de la organización que está siendo
auditada.
Apartados del estándar PTES.
 Pre-compromiso.
 Recopilación de información.
 Análisis de las amenazas.
 Análisis de vulnerabilidades.
 Explotación de vulnerabilidades.
 Post-Explotación.
 Informes.
Podemos acceder a su portal web y descargar la guía completa al igual que leer
documentación interesante sobre este tipo de estándar.
http://www.pentest-standard.org
ICSP v2
- ICSP v.2 -
Fases de un pentest
Como ya hemos comentado a principio del curso es muy importante llevar a cabo todas las
fases de un pentest y realizar de este modo test de intrusión de una manera coherente y
ordenada.
Por ello es necesario conocer las fases que lo componen e implementarlas de forma correcta
para no dar lugar a problemas o errores durante la misma.
Una vez se tiene claro cuál es el objetivo del pentest y después que quede definido por
contrato el alcance de las pruebas y sus posibles consecuencias se procederá a realizar el
mismo.
No todos los clientes a los que vamos a dirigirnos tienen una formación técnica avanzada
por lo que es importante hacer entender nuestros procesos, como van a llevarse a cabo y
dar una visión realista de los resultados que se van a obtener.
ICSP v2
- ICSP v.2 -
Pasos Previos
Esta fase suele presentarse habitualmente redactada como propuestas comerciales y
customizada para el cliente, aquí se define la preparación de la prueba y las actividades
previas al propio pentest. Se define qué debe de ser analizado, cómo y cuándo debe de ser
analizado.
Es habitual entregar al cliente cuestionarios que tendrán que rellenar y devolver firmados,
durante esta fase se establece un compromiso con el cliente.
En estos cuestionarios se definirán los ámbitos de trabajo, el alcance de las pruebas, sus
costes y sus posibles repercusiones legales. Se define también el tiempo necesario para
cada actividad y el número de personas que van a trabajar en ello, así como los horarios de
las pruebas, método de comunicación, entregables, formato…
Si la auditoría es larga puede definir un calendario de reuniones donde se expondrán

periódicamente los avances.
Es tarea del cliente ponerse en contacto con sus terceras partes para evitar repercusiones
legales, igualmente deben de ponerse en contacto con los servicios en la nube que puedan
tener contratados y con sus proveedores de servicios.
Por nuestra parte, hay detalles que es mejor tener previstos de antemano, nos ahorrará
muchas molestias.
Si la auditoría es presencial y aunque no es obligatorio, es recomendable escribir un mail de

presentación al cliente un par de días antes del comienzo o asegurarnos que vamos a tener
lo que necesitamos para poder comenzar sin retrasos.
Los tiempos de análisis y trabajo están pactados de antemano por lo que si hay demoras
vamos a tener que trabajar más rápido o peor. Tampoco está de más revisar la noche
anterior que tenemos nuestro equipo completo (cargadores, dispositivos de prueba…)
En una auditoría de caja blanca suelen proporcionarse de antemano los usuarios, los
accesos y las Urls que van a auditarse por lo que suele ser conveniente comprobarlos si es
posible.
Habitualmente se analiza software de terceros por lo que bajar una versión de prueba o trial
puede ayudarnos a familiarizarnos con el producto.
Aunque la información se haya proporcionado anteriormente es conveniente adjuntar

nuestros datos personales, matrícula del coche, teléfonos de contacto y confirmar el día y la
hora y el contacto de la persona que va a recibirnos. También debemos saber a quién
dirigirnos en caso de necesitar asistencia técnica.
Si hay un responsable de equipo, este será el encargado de asignar el trabajo, pero si vamos
a trabajar con más compañeros es importante saber y tener definidas de antemano las
tareas que va a realizar cada uno para poder compartir información si las actividades están
relacionadas.
ICSP v2
- ICSP v.2 -
Tenemos que tener en cuenta que la explotación de una vulnerabilidad puede afectar a
diferentes niveles y corremos riesgo de bloquear el trabajo de otros compañeros. Debemos
de ser conscientes del impacto de nuestras acciones si se trata de un servicio en producción
y realizarlas fuera de horario, acordado anteriormente con el cliente.
Recopilación de Información
Esta fase es importante y no se debe de escatimar en tiempo en ella ya que cuanta más
información tengamos más posibilidades de éxito tendremos en nuestro pentest.
Es importante crear una línea de tiempo para el proyecto de modo que siempre sepamos
que estamos cumpliendo con los tiempos marcados y con los objetivos de modo que el
pentest sea realizado en el tiempo estimado.
Para comenzar a recopilar información es conveniente apoyarse en un esquema en el que

iremos añadiendo la información recopilada para después analizarla y donde podamos ir
apuntando nuestras notas.
Es importante que aparte de catalogar la información recolectada del sistema,

cataloguemos y documentemos nuestras acciones, puede evitarnos problemas en un futuro.
Cualquier acción que hagamos contra el sistema debe de ser registrada con fecha, hora y
pantallazos y evidencias de las acciones tomadas y las herramientas ejecutadas, tampoco
está de más registrar nuestra hora de conexión y desconexión de la red corporativa y la IP
que hemos utilizado.
De nuevo hay que repetir que cualquier acción debe de quedar documentada, pueden
culparnos posteriormente de cualquier malfuncionamiento del servicio o de la red por lo que
es necesario tener evidencias de nuestras acciones.
Y por supuesto, para evitar corromper o machacar ficheros originales y provocar problemas
de rendimiento es necesario conocer a fondo las herramientas que estamos usando y haber
ensayado nuestras técnicas antes de ponerlas en marcha en un entorno de producción en
un cliente final.
ICSP v2
- ICSP v.2 -
Pasemos ya a la parte de recopilación y enumeración:
Existen dos tipos de reconocimiento, activo y pasivo. Vamos a ver primero el pasivo.
Para este caso podemos apoyarnos en Maltego junto con Shodan, dos herramientas que al
fusionarse aportan gran información y nos permitirán recopilar información de dominio
público que podremos emplear a continuación en el pentest.
Adicionalmente estas herramientas nos proporcionaran la posibilidad de organizar la

información de forma sencilla y esquematizada.
La información más relevante en un pentest de infraestructura es, entre otros, la siguiente:
 Rangos de IPs  Direcciones de e-mail

 Perfil de infraestructura externa  Tecnologías utilizadas
 Accesos remotos  Aplicaciones utilizadas
 IDS/IPS utilizados  Metadatos de documentos
Una vez recopilada debemos organizar la información para preparar de este modo nuestro
ataque con mayor posibilidad de éxito.
En los vídeos del curso se ven estos puntos con ejemplos prácticos de uso y combinación de
herramientas de esta fase.
Entre las técnicas más comunes para recopilar información es la de hacer “hacking con
buscadores”. Estas técnicas se basan en el uso de buscadores para hacer Google hacking,
Bing hacking o la de usar Shodan para detectar servicios operativos.
Además, debemos de saber que existe una base de datos que contiene mucha información
sobre Google Hacking GHDB donde podemos recopilar parámetros de búsqueda que
podemos usar para intentar localizar información interesante.
Se puede consultar aquí: http://www.hackersforcharity.org/ghdb/
Se puede hacer uso de herramientas online para el análisis de DNS o de otras herramientas
que nos ayuden a realizar un cronograma de la aplicación analizada.
Algunas de las herramientas que pueden servirnos se encuentran en las siguientes

direcciones.
 www.archive.org
 www.netcraft.com
Antes de volvernos locos y comenzar a lanzar un escáner que nos proporcione información
sobre puertos y versiones de los sistemas operativos, etc. es conveniente analizar toda la
información pública de los servidores.
Ya hemos mencionado que técnicas o que direcciones públicas pueden servirnos para
recopilar información, existen muchas más que podemos ir localizando y usando.
Otro de los aspectos que no podemos obviar son los documentos públicos encontrados ya
que en ellos podemos obtener información valiosa como códigos de usuario, direcciones de
ICSP v2
- ICSP v.2 -
email o el software empleado para crear el documento al igual que rutas internas del
creados.
Este tipo de datos se llaman metadatos y si no se ha tenido el cuidado necesario antes de

subirlos a los servidores web puede proporcionar mucha información valiosa al atacante.
FOCA es una herramienta desarrollada por informatica64 ahora “ElevenPath” la cual nos
ayuda no solo a encontrar información publicada en los buscadores más famosos, sino
también a extraer los posibles metadatos de los ficheros públicos de la compañía es útil en
ciertas auditorías.
Esta información es de gran valor como ya hemos comentado antes ya que podemos
encontrar datos interesantes como usuarios de sistema, nombres de máquinas, versiones
de software usados etc.
Una vez tengamos toda la información recopilada y catalogada de modo pasivo, pasamos
al modo activo.
Debemos de comenzar a recopilar y enumerar información de forma activa de la

infraestructura de red, enumerando o escaneando vulnerabilidades en servicios abiertos,
buscando directorios no publicados, ficheros, servidores…
Para estas tareas podemos emplear aplicaciones como Nmap, Nessus, OpenVAS, Nexpose
de Rapid, Metasploit u otras y apoyarnos en Faraday para abrir nuestro espacio de trabajo y
tener toda la información unida.
Estas herramientas deben servirnos de apoyo, no basar nuestro trabajo en el resultado de

ellas.
No obstante, se puede mencionar este site que recopila links, tools y recursos de OSINT (Open
Source Intelligence)
http://www.onstrat.com/osint/
ICSP v2
- ICSP v.2 -
Análisis de Amenazas
Una vez terminada la fase de recopilación debemos de organizar toda la información de la
que disponemos para comenzar a preparar el plan estratégico que usaremos para el
pentest.
El análisis de amenazas trata en determinar y definir el negocio del cliente y analizar qué
parte del negocio puede ser más atractivo para un atacante. Estos bienes y activos son los
que deben de ser evaluados a nivel de negocio, no a nivel técnico.
A la hora de presentar detalles al cliente, existe un método de análisis de riesgo con su propio
framework llamado CORAS en el que podemos apoyarnos para desarrollar nuestra tarea.
 The CORAS Method - SourceForge
Determinando el modelo de negocio podemos realizar una matriz de evaluación de

amenazas y su posibilidad de actuación.
Las campañas de Ciber Vigilancia por parte de un cliente específico incluyen la

monitorización de redes sociales, (Twitter, Facebook) canales de comunicación como IRC y
operaciones especiales por parte de grupos de hacktivismo organizado. No hay que olvidar
que simulamos un ataque real por lo que debemos centrarnos en los objetivos que tendría
un atacante.
Una empresa genérica puede ser atacada por una empresa rival, un estatuto
gubernamental puede ser objeto de ataques por parte de crimen organizado, empresas
petroleras o eléctricas pueden ser objetivo de grupos hacktivistas...
Ahora tenemos que determinar la probabilidad de que estos hechos ocurran. Hay múltiples
modelos para cuantificar estos datos basados en la habilidad del atacante para usarlos y
la facilidad o dificultad de acceso a los mismos.
ICSP v2
- ICSP v.2 -
Una matriz de riesgo habitualmente tiene este aspecto:
Aquí tenemos información detallada e interesante para profundizar en nuestro análisis.
 Threat Assessment & Remediation Analysis (TARA)

 Application Threat Modeling - OWASP
Una vez evaluadas las amenazas el siguiente paso es planificar las contramedidas, existen
métodos como ASF y STRIDE para determinarlas y luego decidir cómo mitigarlas.
Lo que realmente quiere ver el cliente es esta información traducida a números que puedan
impactar su negocio, sin el enfoque apropiado un cliente puede rechazar o no tener en
cuenta la importancia de las amenazas si no las percibe como tal (pérdida de reputación o
de beneficios)
ICSP v2
- ICSP v.2 -
Análisis de Vulnerabilidades
Durante el análisis de vulnerabilidades buscamos fallos en la infraestructura, en la red, en los
sistemas y en aplicaciones para posteriormente explotarlos y aprovecharnos de ellos para
conseguir nuestro objetivo.
Para realizar el análisis de las vulnerabilidades hacemos uso de todo tipo de herramientas
de pentest que nos ayuden a identificar vulnerabilidades en las aplicaciones y los servicios
expuestos.
Como hemos visto anteriormente, hemos usado herramientas que nos proporcionarán
información valiosa que nos permitirán identificar agujeros de seguridad.
De nuevo se pueden separar los análisis en activo y pasivo.
Activo y automatizado con escáner de infraestructura, red, web y pasivo de nuevo con
análisis de metadatos, monitorización de tráfico habitualmente entre switches y routers.
En los vídeos veremos cómo validar los datos que encontramos contrastando los resultados
entre diferentes herramientas.
Además de las herramientas, un profesional debe ser capaz de realizar estas tareas a mano,
comprender el trasfondo de estas y ser capaz de desensamblar y analizar código, así como
poder programar exploits para abrirse paso dentro de una red o un sistema.
Recopilación de información general:
 Sistemas desactualizados.
 Servicios vulnerables.
 Incorrectas configuraciones de sistemas.
 Versiones de software obsoletas.
Recopilación de información de portales web:
 Tecnología empleada.
 Tipo de servidor de aplicaciones.
 Ficheros de configuración expuestos.
 Ficheros backup o antiguos.
 Consolas de administración.
 Versión de CMS.
ICSP v2
- ICSP v.2 -
Después de categorizar y analizar todas las vulnerabilidades de los servicios detectados

procedemos junto con las herramientas que estén en nuestra disposición a planificar el
ataque.
Un correcto análisis de las vulnerabilidades nos facilitará tener mayor éxito cuando
tengamos que comenzar con la explotación de estas.
A continuación, se encuentra un listado de herramientas que podemos usar para el análisis

de vulnerabilidades.
Debemos de ser capaces de realizar la auditoría de forma manual y explotar las

vulnerabilidades con métodos manuales.
Tenemos que siempre tener en cuenta que el uso de herramientas automáticas es para
ayudarnos en el proceso no para quedarnos únicamente en los datos extraídas de ellas.
ICSP v2
- ICSP v.2 -
Metasploit es el Framework más avanzado que puede ser usado

para el pentest, existen versiones de usuario y de empresa. Este
Framework permite el análisis de vulnerabilidades en
aplicaciones web, servidores, sistemas, etc. Creado con el objetivo
de explotación y pre-explotación, en la actualidad la herramienta por excelencia de los
pentesters.
http://www.metasploit.com/
Wireshark es un sniffer perfecto para el análisis de red e

imprescindible herramienta si queremos capturar tráfico y
analizar los paquetes de red.
https://www.wireshark.org
Nessus es un escáner que nos dará mucho juego, a través de

sus plugins nos ayudará a encontrar vulnerabilidades de
sistema y de servidores web.
http://www.tenable.com/products/nessus-vulnerability-scanner
Burp Suite es una herramienta imprescindible para el análisis de

aplicaciones web.
Este proxy nos permite capturar el tráfico entre nuestro cliente y

el servidor permitiéndonos modificar su contenido y manipular las
peticiones web en busca de fallos de seguridad en aplicaciones web o en aplicaciones móvil.
https://portswigger.net/burp/
Zed Attack Proxy (ZAP) su función es la misma que Burp Suite,

pero esta versión es de OWASP.
Con esta herramienta podemos analizar y explotar

vulnerabilidades detectadas en aplicaciones web.
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Acunetix es una plataforma que nos permite el análisis automático

de vulnerabilidades web, manipular peticiones y analizar web
services.
http://www.acunetix.com/
ICSP v2
- ICSP v.2 -
Aquí tenemos una lista de las herramientas más utilizadas para la

enumeración, recopilación de información, escaneos de puertos,
fuerza bruta…
http://www.kitploit.com/
La más completa hasta la fecha, integra los resultados de todas

ellas creando reportes y centralizando la información
https://www.faradaysec.com
Todas estas herramientas también son válidas para los análisis y explotación posterior.
 John The Ripper Crackeador de Passwords.

 Sqlmap Herramienta de Pentest vía SQL Injection.
 Canvas Herramienta de Exploiting.
 Social Engineer Toolkit Ingeniería Social.
 Sqlninja Herramienta de SQL Injection
 Nmap Análisis de Red.
 BeEF Herramienta de Pentest para Navegadores Web.
 Dradis Repositorio de Información.
 Hydra Herramienta de Ataque de Fuerza Bruta.
 Veracode Análisis y Monitorización de Red, Tools y Dispositivos.
 SATAN Herramienta de Análisis de Red.
 SHODAN Motor de Búsqueda de Dispositivos Interconectados.
 Aircrack-ng Herramientas para auditar Redes Wireless.
 Arachni Escáner de seguridad de Aplicaciones Web.
 IBM AppScan App de IBM para Web y Móviles.
 Nikto Web Server Escáner.
 Maltego Recopilación de Información.
 OpenVAS Escáner de Vulnerabilidades.
 Ettercap Ataques Man in the Middle.
Cada herramienta es un mundo en sí misma, es necesario instalarlas y familiarizarse con

todas sus opciones y posibilidades.
De nuevo conviene recordar que estas herramientas son un apoyo, no debemos basar
nuestro pentest exclusivamente en el resultado de estas.
ICSP v2
- ICSP v.2 -
Fase de Explotación
Una vez tengamos identificadas las vulnerabilidades el siguiente paso es clasificarlas y
buscar la manera de explotarlas, lo ideal es que sea un ataque preciso y que el impacto en
los sistemas sea el menor posible.
Esta es la fase donde los conocimientos y la experiencia del auditor juegan un gran factor,
es la parte más interesante de un pentest y donde podemos exhibir nuestras habilidades.
Se pueden hacer uso de exploits públicos o privados o crear los nuestros propios, vulnerar
sistemas a través de SQLi, podemos utilizar ingeniera social o cualquier técnica que esté
dentro de lo pactado con el cliente para lograr nuestro objetivo final.
En esta fase Metasploit toma ventaja sobre sus competidores y su base de datos de exploits
nos permite tomar el control de muchos sistemas a través de aplicaciones vulnerables, pero
en muchos casos no siempre es posible tomar el acceso del control con un exploit y es
necesario aprovecharse de una incorrecta configuración, un fallo de programación o un
permiso incorrecto.
También debemos de tener en cuenta que si ganamos acceso lo habitual es tener un acceso
limitado o básico y por ello necesitaremos elevar privilegios en el servidor hasta hacernos
con el control de este.
Esta parte la veremos en el curso y realizaremos pruebas de concepto.
En ocasiones cuando explotamos una vulnerabilidad tenemos acceso directo a nuestro

objetivo, pero no siempre va a resultar tan sencillo y es más que probable que tengamos
que esforzarnos para lograr nuestro objetivo o cambiar de estrategia para conseguirlo.
Existen diferentes técnicas que iremos viendo durante el curso, pero en esta parte del pentest
interviene mucho la creatividad y la imaginación del Pentester.
Cada pentest es diferente por lo que supone un reto interesante cada vez que en uno de
ellos se llega a la meta final.
No debemos de olvidarnos de los sistemas de prevención que pueden estar en los sistemas
auditados y que tendremos que saber cómo evadir sus medidas de defensa.
Estos sistemas son Firewalls, antivirus, IDS o WAFs y debemos también intentar realizar el
pentest haciendo el menor ruido posible para no ser detectados y bloqueados.
En algunos pentest se pacta como objetivo no ser detectados por los sistemas de seguridad
por lo que es importante también realizar ataques con métodos menos evasivos, como
intentar cifrar las comunicaciones una vez tengamos acceso al servidor.
Aunque cada auditor es un mundo y cada uno tiene sus métodos personales es
recomendable combinar el uso de herramientas con las pruebas manuales.
ICSP v2
- ICSP v.2 -
Si el auditor tiene más experiencia es probable que se le ocurran más escenarios y sepa
emplear más técnicas de ataque o incluso entienda como combinar varias de ellas para
poder hacerse con el objetivo.
En cualquier caso, es necesario ir documentando el proceso paso a paso y realizar capturas

de los sistemas para poder realizar la documentación más completa posible.
Post-Explotación
En la primera fase, habremos determinado con el cliente que nivel de intrusión vamos a
realizar y debemos asegurarnos de que ambas partes estamos de acuerdo con los
procedimientos a seguir.
Llegados a este punto si hemos tenido éxito ya tendremos acceso al sistema y nuestro
objetivo será el de intentar hacernos con el mayor control posible.
Esta fase tendrá como objetivo reconocer configuraciones de equipos, métodos de

comunicación y la relación de nuestra máquina comprometida respecto a las cercanas.
En un sistema que ha sido comprometido podemos subir herramientas o usar las

herramientas locales, enumeración desde la red interna, ataques de fuerza bruta,
enumeración de servicios, ataques a servicios, ejecución de exploits remotos.
Desde el sistema que hemos comprometido podremos intentar hacer port forwarding,
ejecutar exploits remotos, tratar de acceder a otros puntos de la red…
Estos datos los usaremos para poder pivotar sobre la red, escalar privilegios, acceder a
información sensible y controlar el mayor número posible de elementos del sistema.
Toda esta información debe de ser presentada al cliente con evidencias y detalles para que
sea consciente de cómo un atacante puede llegar al mismo objetivo.
Durante esta fase no debemos exponer los sistemas del cliente a riesgos innecesarios ya
sean directos o indirectos.
Cualquier acción que hagamos debe de quedar documentada con evidencias, fecha y hora
de la realización de estas.
Hay que establecer con el cliente el método de comunicación que se va a emplear en caso
de vulnerar software de terceros.
No se deben de modificar logs en los que haya evidencias de nuestras acciones y es

recomendable hacer una copia de seguridad de ellos.
Las evidencias que recopilemos debemos de conservarlas en un lugar seguro y encriptado,

no podemos exponernos a una fuga de información por perder un pendrive.
En los capítulos posteriores del curso se hablará ampliamente de esta fase, donde se
detallará un análisis de infraestructura completo (análisis de red, servidores DNS, servicios
de red, programas instalados, servicios activos…)
ICSP v2
- ICSP v.2 -
Es necesario advertir que debemos saber dar marcha atrás a nuestras acciones una vez
terminadas y dejar los sistemas tal y como los hemos encontrado (o como determine el
cliente) pero debidamente documentado.
Al final de esta fase, debemos borrar las cuentas de usuarios que hemos usado para el
pentest, desinstalar RootKit, eliminar puertas traseras, dejar los valores que hemos
modificado a su estado original, borrar scripts, carpetas o programas que hemos podido
crear.
Cualquier modificación en caliente que solicite el cliente debe de quedar escrita y firmada
por ambas partes.
Informes
Hasta el momento la parte de un pentest más pasada por alto es la parte de redacción de informes.
Una vez finalizado un pentest, se entregará al cliente una serie de informes en los que se expondrá el resultado
del trabajo realizado.
Estos informes son en ocasiones lo único tangible que recibe el cliente y por lo que el cliente realmente está
pagando y muchas veces la única manera de justificar el coste que han desembolsado, por otro lado, esta
presentación de resultados son la cara visible y la imagen de la empresa de seguridad por lo que conviene que
sea la mejor imagen posible.
Entonces... ¿por qué no se le da la importancia y la atención necesaria? La respuesta es fácil: Todo el mundo los
odia.
Por parte del profesional de seguridad por el tiempo que consumen. La recopilación, clasificación y la manera de
procesar y presentar la información consume más tiempo que la prueba de penetración en sí, sin contar con las
revisiones posteriores.
A la empresa de seguridad le supone un gasto, aunque asumido, su manejo, custodia y tratamiento legal.
Los clientes por su parte, tanto técnicos como ejecutivos deben enfrentarse al resultado de ellos no suele ser fácil
de digerir ya sean los resultados todo lo buenos o todo lo malos que se esperaban.
Que un cliente afronte que sus sistemas son vulnerables y están expuestos a ataques y que va a ser necesario (y
a veces costoso) solucionarlo no es plato de buen gusto para nadie.
Como profesionales debemos presentar la información, la exposición de los hechos y las estrategias posteriores
con la mayor profesionalidad posible de una manera clara y directa de manera que podamos hacer llegar la
información correcta a la persona adecuada.
ICSP v2
- ICSP v.2 -
Generación de Informes
Un informe bien presentado es la imagen de la empresa y a partir de él pueden contratarnos el desarrollo e
implementación de labores posteriores, de ahí que tenemos que dedicarle una importancia extrema.
El informe final es por lo que paga el cliente y lo que el cliente percibe de nuestra empresa, muchas empresas
consultoras de seguridad dan más importancia a la presentación del informe que al contenido de sus datos.
Una de las tareas más odiosas y más si no se dispone de parte de la tarea automatizada es crear los informes
técnicos y ejecutivos. Redactar informes no es ciencia exacta todo lo contrario, más bien es un arte.
El informe técnico debe de contener todas las evidencias que hemos recopilado, imágenes, métodos, versiones
del software explotado, vulnerabilidades localizadas… debe de estar escrito en un lenguaje que cualquier colega
de gremio pueda entender.
El informe ejecutivo debe de ser un resumen del informe técnico, con gráficos y redactado en un lenguaje sencillo
y comprensible orientado a personas de alta dirección, que son los que tomarán las decisiones finales sobre
implementaciones y correcciones en el sistema.
Seguramente nuestra empresa nos pida un informe de esos informes presentados por lo que hay que estar
preparado y tener esta labor asumida, después de una auditoría de seguridad hay que dedicar al menos una
jornada entera para la redacción de informes.
Lo último que una persona puede querer al salir de su trabajo es ponerse a redactar un informe, pero si dedicamos
un poco de tiempo al final del día a ir creando el boceto e ir organizando la información recolectada en el día de
trabajo, al final no se hace tan pesada la tarea.
Es importante ser organizado en el trabajo de un pentest para no dejar nada pendiente ni pasar nada por alto. No
hay que olvidar que nos van a pedir resúmenes, explicaciones y recomendaciones finales, por lo que nuestro
trabajo debe de quedar impecable para poder defenderlo.
Una de las herramientas utilizadas para guardar información es KeepNote, es una herramienta sencilla y realiza
bien su función por lo que vale para el día a día, adicionalmente se pueden usar otras como Dradis o Evernote.
Conviene crearnos nuestro propio código de nombres de ficheros y nuestra manera de clasificarlos para luego
tener nuestro repositorio propio completo y organizado.
En KeepNote es aconsejable usar una página por cada una de las vulnerabilidades que vamos detectando e ir
anotando las ideas, notas o pensamientos que nos vayan surgiendo durante la auditoría para finalmente pasarlo
todo al informe final de manera organizada y clara.
Por supuesto siempre se puede programar una herramienta que sirva de ayuda a la creación automática de
informes, usando una plantilla de Word y algo de Python se puede hacer maravillas.
También podemos apoyarnos en las bases de datos de CVE para extraer la información que necesitemos.
https://cve.mitre.org/
Otro punto importante es que, si el pentest se realiza sobre un servidor web, debemos de seguir y basarnos en la
metodología de OWASP y por lo tanto las vulnerabilidades estarán categorizadas en 7 subcategorías en las que
dentro de cada cual añadiremos la vulnerabilidad que corresponda.
Esto no es un estándar y en cada organización o cliente tendrán sus plantillas de informes y sus herramientas de
presentación de resultados, lo importante es tener la información de modo que presentarla en cualquier formato
nos sea fácil y rápido.
En algunos lugares no se clasifica por categoría y únicamente se añaden todas las
vulnerabilidades según su criticidad.
En cualquier caso, para documentar y escribir sobre la vulnerabilidad lo más habitual es usar una caja donde se
va añadiendo toda la información recopilada durante la auditoría.
ICSP v2
- ICSP v.2 -
Un ejemplo podría ser la siguiente imagen la cual contiene dentro el apartado, la descripción
la URL y los parámetros afectados.
Esta caja es genérica y se puede aumentar o añadir más campos o simplemente quitar los
que creamos que no son necesarios.
En el reporte o informe es importante exponer el grado de complejidad del ataque para que
el cliente entienda el grado de exposición de sus sistemas y la dificultad de llevar acabo la
vulneración de este, además, el reporte debe de contener un factor de impacto que califique
en vulnerabilidad (Crítica, alta, media o baja).
Tenemos que tener claro en qué tipo de criticidad se asocia cada vulnerabilidad al igual que
categorizar la dificultad de explotación en (Trivial, Moderado, difícil).
En el área de recomendaciones se debe proporcionar una información clara e imparcial

sobre cómo mitigar las vulnerabilidades detectadas de modo que pueda priorizar las tareas
según su criticidad.
ICSP v2
- ICSP v.2 -
El impacto de la actividad y la facilidad de categorización de explotación pueden ilustrarse

en tablas como las siguientes.
Para el análisis, categorización o métodos de pruebas se pueden emplear metodologías

como OSSTM y usar la misma plantilla modificándola en el caso de que nos soliciten
únicamente un pentest sobre los sistemas y no sobre las plataformas web.
Existen varias metodologías para ponderar los riesgos, entre otras tenemos también DREAD
(Risk Assessment model), STRIDE (Microsoft), FAIR (Factor analysis of information Risk) o la
guía OWASP Risk Rating Methodology
Aunque los informes técnicos y ejecutivos sean diferentes suelen tener una cosa en común,
habitualmente solo se suele leer el impacto de las vulnerabilidades críticas, el resumen y las
recomendaciones.
El tono del informe debe de ser neutral, exponiendo los hechos de una manera clara y concisa
sin opiniones que no sean relevantes o que sean inadecuadas.
Con un adecuado control de versiones el informe original puede reutilizarse si se piden

pruebas posteriores, indicando el estado anterior y señalando el nuevo resultado.
Hay que cuidar mucho la presentación del informe y también hay que tener cuidado con la
reutilización de estos, para no dejar datos como logos o información del cliente anterior.
Para finalizar, el informe se recomienda que una vez terminado se exporte en formato PDF y
se firme digitalmente con un certificado de la organización que audita para certificar la
integridad del documento y la proveniencia de este al igual que anotar la clave checksum
del documento en el caso de que sea modificado poder identificar su veracidad.
ICSP v2
- ICSP v.2 -
Como No Redactar un Informe

Muchos informes están correctamente redactados, pero fallan a la hora de expresar su
contenido, insistimos en que transmitir la información correcta es un arte y cada uno tiene
su estilo, pero hay informes que no son redactados ni presentados de manera profesional.
Aunque usemos plantillas, cada informe debe de ser personalizado para el cliente. Hay que
evitar a toda costa reescribirlos, si reutilizamos informes corremos el riesgo de pasar por alto
detalles de formato del documento y podemos incluso dejarnos el nombre de la empresa
anterior o contenido de la auditoría de otro cliente.
Tampoco es profesional entregar el informe con estilos de fuentes diferentes de distintos

corta-pegas. Por favor, las faltas de ortografía... es conveniente añadir lenguaje técnico a
nuestro diccionario para poder pasar el corrector con tranquilidad.
Cuidado también con incluir descripciones o recomendaciones de vulnerabilidades

genéricas encontradas por internet o salidas de herramientas automáticas porque aparte
de ser obvias y ser poco elegante se nos puede acusar de plagio. No es broma.
No conviene sobrecargar el informe con 40 páginas de imágenes de colores o 40 páginas

de texto sin formato que nadie quiera leer, tiene que estar equilibrado.
Por supuesto cuidado con la redacción y la coherencia del documento puesto que algo que
se ve mucho en los informes es como a veces se escribe en primera persona y en tercera
persona en el mismo documento.
Los informes deben basarse en evidencias, no podemos entregar informes basados en

especulaciones, sin evidencias, sin comprobar realmente las vulnerabilidades (no vale saber
que esa versión es vulnerable).
Se debe incluir absolutamente todo lo que se encuentre por pesado que sea, no hay que
omitir vulnerabilidades porque luego sea complicado o pesado explicárselas al cliente, es
más común de lo que se piensa.
Los informes no deben incluir recomendaciones de compra de productos, ofrecer nuestros

servicios o publicidades comerciales, por muy sutiles que sean.
Por muy orgullosos que nos sintamos después de encontrar una vulnerabilidad compleja, si
nuestro público no tiene conocimientos técnicos no van a entender la grandeza de nuestros
logos por lo que es mejor dejar esos detalles para los informes técnicos que es donde
corresponden.
El informe no debe usarse como lienzo para exponer nuestras quejas si algo no nos ha
gustado, porque no nos hayan dado la tarjeta en seguridad esa mañana, por que creamos
que la seguridad es muy débil o que haya exceso de fallos y no debe de ser redactado en
tono agresivo o alarmista sin motivo.
ICSP v2
- ICSP v.2 -
Planificación de un Informe
Vamos a ver cómo se puede organizar la redacción para que consuma el menor trabajo
posible, la mayoría de las veces se planifican las horas contratadas para el pentest, pero no
se deja el tiempo adecuado para redactar el informe por lo que puede convertirse en un
problema adicional puesto que se realizarán rápidamente y de mala manera en ocasiones.
Recopilación de información
Cuando nos asignan un pentest, vemos que hay que analizar y nos podemos hacer una idea
del tiempo que nos va a llevar el informe, por lo habitual se tarda casi el doble del tiempo
redactando el informe que la auditoría en sí.
Si llevamos nuestro esqueleto de carpetas preparado de antemano, ahorramos tiempo que

podemos dedicar al pentest.
Borradores
Es muy recomendable que mientras se vayan recopilando y almacenando evidencias se
vaya escribiendo un borrador o dedicar media hora antes de salir a la redacción de un
boceto.
No es la primera vez que un cliente pone una reunión antes de finalizar la jornada para ver
que se ha ido haciendo, no es obligatorio presentar nada y menos entregarlo si no está
firmado antes, pero les gusta ver o en ocasiones comentar lo que se ha ido haciendo durante
la jornada.
Otra de las cosas que no querría tener que hacer nadie es al final la jornada de trabajo y
llegar a casa ponerse a redactar un informe, pero ahorra mucho trabajo al final si se va
teniendo al día.
Si son auditorías de sistemas o aplicativos muy genéricos podemos crear nuestras propias
plantillas con los datos que hay que sustituir, hay que resaltar bien los campos que deben
de ser rellenados para evitar errores.
ICSP v2
- ICSP v.2 -
Revisión final
La idea de ir haciendo borradores es que a la hora de repasar se pueden ver mejor los
errores, si hacemos el informe del tirón y luego lo repasamos, seguramente no veamos nada
mal redactado.
Lo ideal sería contar con la revisión de un equipo de calidad como tienen las empresas
grandes de seguridad. También se puede pedir si se autoriza a que un compañero revise el
informe, pero no es habitual por motivos de seguridad.
Plantillas
Diseño Corporativo
Las plantillas de diseño del documento en el que será presentado el informe deben ser
atractivas visualmente, pero sin sobrecargar puesto que lo importante es la información que
contiene. No hay que olvidar que son la cara visible de nuestra empresa.
Las plantillas por lo general llevan en el encabezado el logo de la empresa auditora, el logo
del cliente y alguna referencia al ámbito que se está analizando.
En el pie de página por lo general se incluye alguna referencia al documento como el número
de versión de este.
Las plantillas de informes genéricos deben tener todos las mismas fuentes, formatos y diseño,
tanto los genéricos como los personalizados para cada cliente si es posible.
Otros clientes solicitan informes customizados, informes rápidos al final del día o pueden
solicitarlos en otros formatos como por ejemplo un listado en Excel con todas las
vulnerabilidades encontradas.
Estos informes que nosotros entregamos deben tener nuestro mismo look and feel
corporativo, aunque sea hecho a medida para un cliente especifico.
Hay clientes que entregan sus propias plantillas con sus propios formatos y solo tenemos
que rellenar la información, aquí no podemos ni debemos modificar nada.
Los datos que usamos son los que se utilizan habitualmente, pero se deben adaptar según
nuestras necesidades.
Portada del Informe

En la portada o carátula del informe debe mostrarse la información relativa al documento.
El nombre del informe, su versión, la fecha, el ámbito analizado, el nombre de la empresa que
ha realizado la prueba de penetración y en ocasiones se añade el código interno del
documento de la compañía.
ICSP v2
- ICSP v.2 -
Propiedades del Documento

En este apartado se incluye la información del documento como parte del proyecto.
El nombre del cliente, el nombre del documento, su nivel de confidencialidad, su código

interno, el autor….
Control de Versiones
La normativa que engloba la gestión documental es la Norma UNE-ISO 30301
En el control de versiones se incluye el número de versión del documento, su fecha, el autor,

el nombre de la persona que lo ha validado, los cambios de versión que ha sufrido, la revisión
que se ha hecho....
El control de versiones en la gestión documental puede ser pesado y confuso incluso a nivel
personal. Existen multitud de herramientas comerciales como Nuxeo o Documentum y de
código libre como Subversion y su cliente TortoiseSNV que podemos usar, junto con unas
buenas políticas y procedimientos de gestión.
Tipos de Informes
Los informes habitualmente se separan en informes ejecutivos e informes técnicos, ambos
dirigidos a un público diferente por lo que deben de ser redactados teniendo en cuenta su
público y entregados a las personas correctas.
Un informe es una foto del estado del sistema, una instantánea de cómo se encuentra ese
sistema en el momento del análisis y los resultados serán iguales en ambos informes solo
que serán presentados de una manera diferente.
Informes Ejecutivos
Los informes ejecutivos irán dirigidos a miembros en puestos de dirección que tienen poder
de decisión para implementar cambios, realizar acciones y aprobar presupuestos.
Las personas que ocupan puestos de dirección tienen una visión más amplia del negocio y
por lo general poco tiempo que malgastar.
ICSP v2
- ICSP v.2 -
Los informes ejecutivos deben ser visualmente atractivos y concisos. Deben ser resumidos
de manera simple y directa sin entrar en detalles técnicos.
Se trata de presentar un informe en el que de un vistazo puedan verse las vulnerabilidades

descubiertas, su severidad y las recomendaciones. Se recomienda exponerlos con gráficos
y diagramas para que puedan ser analizados más rápidamente por parte del cliente.
Conviene repasar el informe ejecutivo para poder resumirlos fácilmente si nos toca exponer
los resultados o a la hora de defenderlos, nos pueden pedir detalles por lo que debemos
llevar preparado de antemano que queremos transmitir.
Muchas veces el personal ejecutivo tiene en mente el área de negocio únicamente, pero
debemos recordarles que pueden exponerse a multas o acciones legales si no se cumple la
legislación actual en materia de protección de datos.
Se debe resaltar el impacto de las vulnerabilidades críticas en el negocio sin alarmismos

innecesarios, teniendo preparadas las evidencias que nos soliciten en ese momento,
conviene llevar repasado el informe para poder responder a cualquier pregunta que puedan
realizarnos.
Informes Técnicos
Los informes técnicos van dirigidos, entre otros profesionales, a desarrolladores,
administradores de sistemas, project managers, consultores de seguridad y en muchas
ocasiones son usados por compañeros que repiten la misma auditoría para el mismo cliente
en test periódicos posteriores.
Aquí debemos incluir todos los detalles técnicos, la manera de reproducir cada fallo y las
recomendaciones para solucionarlo. También se incluyen recomendaciones y conclusiones.
Todo lo que incluyamos en el informe debe estar respaldado por evidencias, todos los
detalles deben de quedar registrados desde la fase inicial de recopilación.
Para que una vulnerabilidad pueda corregirse es necesario documentarla desde el inicio al
final para que pueda ser reproducida por la persona encargada de solucionarla.
Informes Mixtos
En este caso no se entregan informes separados, el ejecutivo y el técnico van juntos en el
mismo documento.
En este caso se redacta un “Resumen Ejecutivo” que irá al comienzo del documento. Este
resumen contendrá que se ha hecho, sus resultados y su impacto de manera breve y
resumida y a continuación el informe técnico en detalle.
De nuevo, en el resumen ejecutivo lo que se necesita es claridad, qué se ha encontrado (no

como se ha encontrado) el impacto que puede suponer al negocio y cómo solucionarlo.
Se puede enriquecer el resumen ejecutivo con gráficos e ilustraciones.
ICSP v2
- ICSP v.2 -
Vulnerabilidades
Alta Crítica
6% 2%
Media
12%
Info
49%
Baja
31%
Info Baja Media Alta Crítica
Estructura de un Informe
Un informe se compone de diferentes apartados los cuales están claramente referenciados
y cada uno de ellos tiene su propósito. Para comprender mejor su tipología y estructura se
ha separado el contenido en informe ejecutivo y en informe técnico.
Informe Ejecutivo
Descripción del propósito del pentest.
Descripción del sistema que se ha auditado y que resultados se han obtenido.
Resumen de Vulnerabilidades
A partir de los datos obtenidos construiremos tablas y gráficos con las vulnerabilidades,
encontradas catalogadas por impacto o riesgo.
Es recomendable que las mostremos en un gráfico o una tabla para que puedan ser
fácilmente interpretadas, este resumen general pretende dar una visión general de los
problemas detectados.
Las vulnerabilidades detalladas corresponden al informe técnico.
Impacto de las Vulnerabilidades
Al describir el impacto de las vulnerabilidades es conveniente redactar el texto en un lenguaje

no técnico pero sencillo y directo, se pueden usar más diagramas o gráficos para enriquecer
el informe.
Se espera ofrecer una visión global de la exposición de la compañía ante la explotación de

esas vulnerabilidades.
ICSP v2
- ICSP v.2 -
Conclusiones
Las conclusiones para que sean claras deben de ser redactadas centrándose en la
disponibilidad del servicio, en que tipos de datos pueden ser atacados, en los problemas
legales que pueden acarrearles y si puede suponerles perdidas de reputación o pérdidas
financieras.
Si las conclusiones no se exponen de forma adecuada el cliente puede quedar

decepcionado y con la sensación de haber tirado el dinero y no volver a contratarnos de
nuevo, aunque se hayan encontrado fallos graves de seguridad en el sistema.
Informe Técnico
Introducción
Aquí debemos describir que sistema o aplicación vamos a analizar y que vamos a hacer, si
se trata de una revisión de código, si es una auditoría Wifi, si es una herramienta de intranet…
Los entornos que se van a analizar, desarrollo, preproducción, producción… las direcciones
IP de estos (si son muchas pueden ir en un anexo aparte) los nombres de los servidores y
sus modelos, los nombres de los hosts.
En caso de aplicaciones su nombre, su versión y su utilidad. Nos evitaremos confusiones para

nosotros y de cara al cliente.
Objetivo
El propósito del pentest. Que queremos probar, si es accesible desde el exterior, si es

vulnerable a ataques maliciosos, si pueden transferirse datos desde la aplicación…
Debemos hacer una descripción del sistema que vamos a auditar, si se trata de un trabajo
en remoto o en local y las fechas y horas a las que se van a realizar las pruebas, si estas se
modifican deben indicarse posteriormente y las fases en las que va a dividirse el trabajo.
Advertencias
Esta sección no suele aparecer en algunos informes, pero no debiera ser excluida.
Aquí se indican los problemas que hemos encontrado que nos han retrasado o impedido
analizar un entorno.
Metodologías
No es obligatorio, pero si recomendable mencionar que metodología se ha usado, no hay

que olvidar que las auditorías son periódicas y se repiten, es necesario para mantener una
coherencia a la hora de realizar informes anuales, por ejemplo.
Información Recopilada
Descripción de la información capturada y que método se ha usado para ello, si ha sido

manual y si se han utilizado herramientas.
ICSP v2
- ICSP v.2 -
Si se han utilizado herramientas automáticas hay que proporcionar un listado.
Resumen de Vulnerabilidades
Aquí vamos a mostrar un resumen de las vulnerabilidades encontradas, podemos

programarnos una macro de Word o crear alguna herramienta que nos facilite la tarea si no,
podemos tardar mucho. Es recomendable que las mostremos en un gráfico o una tabla para
que puedan ser catalogadas y fácilmente interpretadas.
Vulnerabilidades
Cuando encontramos una vulnerabilidad, sea cual sea su severidad, tiene que ser
documentada al detalle.
Debemos explicar cuál es el fallo de seguridad que se ha encontrado, en que

entorno/aplicación se ha localizado, el impacto que puede suponer si esa vulnerabilidad es
explotada y por qué es importante o no.
Sus evidencias: como ha sido localizada, de qué manera se ha explotado y los pasos para
reproducirla, con pantallazos, logs y cualquier otro registro que podamos presentar.
Si se hace referencia a alguna vulnerabilidad, esta debe provenir de una fuente fiable como
recomendaciones del suministrador del producto, referencias en la guía OWASP o portales
de reconocida reputación.
Si se hace muy largo, se debe añadir una sección de información adicional
Recomendaciones
Se plantearán las soluciones a las vulnerabilidades priorizando las más urgentes, después se
propondrá una hoja de ruta con acciones a corto, a medio y a largo plazo.
Conclusiones
Aquí es donde tenemos que demostrar nuestra profesionalidad a la hora de presentar un

informe porque tenemos que exponer el resultado de nuestra prueba y el cliente espera
nuestra opinión profesional al respecto.
Se trata de exponer que supone lo que se ha encontrado, no como lo hemos encontrado por
lo que los tecnicismos deben de ser evitados en esta sección.
En esta parte también se puede decir si hemos encontrado niveles de seguridad correctos o
buenas prácticas de seguridad implementadas.
Al ser lo último que se escribe se puede caer en la tentación de pensar que se han leído el
informe entero que hemos entregado y están correctamente informados por lo que esta
parte se escribe sin la atención adecuada, pero es todo lo contrario.
Se suele dar un vistazo general a ver si hay vulnerabilidades críticas, las recomendaciones y
las conclusiones y en muchas ocasiones, el cliente solamente lee la parte de las conclusiones
puesto que es aquí donde espera encontrar el impacto que puede suponer para su negocio.
ICSP v2
- ICSP v.2 -
No está de más, si hay vulnerabilidades graves, mencionar de nuevo las recomendaciones.
Entrega de Informes
Entrega a Cliente
Se habrá acordado de antemano con el cliente la frecuencia, el medio y las personas a las
que serán entregados estos informes. Hay que tener en cuenta la clasificación de cada
informe, si se trata de información crítica, reservada…
Si se entregan copias en papel deben de ser entregadas en mano y firmadas por parte de
la persona que la recibe. Una pequeña lista con los nombres y las firmas es suficiente.
Si la información se entrega en papel y es clasificada a alto nivel, aparte de la firma de la

persona que lo recibe se puede poner una marca de agua en el documento con el nombre
de la persona a la que ha sido entregado y su cargo, en caso de producirse filtraciones. La
marca de agua puede quitarse, pero suele ser disuasorio.
Hay que evitar usar las impresoras del cliente.
Si se entregan por email, en el cuerpo del correo suele incluirse un pequeño resumen de
vulnerabilidades, los datos del equipo de probadores, la descripción del ámbito de analizado
y la conclusión más relevante.
El correo debe enviarse encriptado y los documentos deben ir comprimidos con contraseña,
la contraseña no se incluirá ni en el mail.
Se recomienda que una vez terminados los informes se exporten en formato PDF y se firme
digitalmente con un certificado de la organización que audita para certificar la integridad
del documento y la proveniencia de este al igual que anotar la clave checksum del
documento en el caso de que sea modificado poder identificar su veracidad. Hash en los
documentos.
Entrega a la Empresa
Para una empresa de seguridad lo peor que puede ocurrir es que sea insegura. Una fuga de
datos supone un golpe humillante y la confianza de cara al cliente queda totalmente dañada,
a veces de manera irrecuperable.
Nosotros somos responsables del manejo de los informes que generamos, hay que tener
cuidado de no dejar información confidencial en discos duros extraíbles, prestar pendrives
con documentación dentro y respetar siempre las políticas de la empresa.
ICSP v2
- ICSP v.2 -
La empresa de seguridad es responsable de la custodia de estos informes confidenciales.,

deben de tomarse las medidas necesarias para garantizar la seguridad y la confidencialidad
del material con contenido sensible. Una empresa que no cumpla las leyes de protección de
datos en materia de LOPD se expone multas severas.
https://www.servipymelopd.es/lopd/riesgos
http://www.agpd.es/
Recomendaciones
Basadas en experiencias personales, esta es una pequeña recopilación de detalles que
suceden en la vida real que conviene tener en cuenta para que no nos pillen de sorpresa.
Si somos los responsables de una auditoría y tenemos que presentar un informe final basado
en diferentes informes de diferentes auditores hay que tener un cuidado especial en la
coherencia global del documento.
Cada auditor redacta con un estilo propio y diferente, el informe final debe ser entregado al
cliente con un tono de redacción uniforme.
Si somos responsables de un grupo de auditores y sobre todo si se trata de personal de

nueva contratación en la empresa hay que evitar la tentación de darles informes de
auditorías pasadas como ejemplo para que los usen de entrenamiento o aprendizaje puesto
que contienen contactos, infraestructura y vulnerabilidades reales de clientes.
En reuniones con el cliente o a la hora de presentar el informe ejecutivo pueden surgir

malentendidos a la hora de tratar la severidad de una vulnerabilidad.
Aunque la información esté contenida en las páginas del informe no exponerlo de una
manera correcta puede provocar quejas por parte del cliente a nuestra empresa o peor aún,
que sea pasada por alto, sea explotada y el cliente nos exija responsabilidades o
indemnizaciones.
Algunos clientes pueden presionarnos para cambiar el nivel de riesgo de las vulnerabilidades
encontradas para que no aparezcan muchas, por motivos de presupuesto o por motivos
internos de la empresa. No es una tontería y es más frecuente de lo que parece.
En este aspecto debemos mantenernos muy firmes puesto que puede crear problemas
graves a nuestra empresa, nosotros firmamos y entregamos una información determinada,
si la manipulamos puede ir en contra nuestra muy seriamente en un futuro en caso de
ataque.
En muchas ocasiones los clientes andan a nuestro alrededor supervisando el pentest y si

surge alguna vulnerabilidad grave pueden pedirnos que se corrija en ese mismo instante.
Esto es delicado puesto que se están haciendo cambios en un entorno de producción que
pueden no haberse acordado ni firmado anteriormente.
Aquí depende de cada persona, se puede pedir el visto bueno a nuestra empresa con una
rápida llamada de teléfono a nuestro responsable para que confirme con el cliente y ambos
ICSP v2
- ICSP v.2 -
se ponen de acuerdo, cualquier cosa que se modifique en caliente debe constar con
evidencias anteriores y posteriores y documentadas en los informes correspondientes.
Aunque es un área totalmente diferente y puede parecer que no tiene relación, como
profesionales a veces por parte de clientes o personal no especializado se nos puede requerir
algún tipo de conocimiento forense.
No es la primera vez que se encuentra en un pentest que el sistema ya ha sido vulnerado y

los datos ya están comprometidos.
De nuevo hay que tener mucha mano izquierda y mucho tacto a la hora de exponerlo al
cliente y darles una idea inicial aproximada o una explicación lógica mientras se pone en
manos de expertos.
Checklist Rápida
Tabla 1: Formato del Documento
Cuestiones Revisado
¿Hemos usado una plantilla en blanco para empezar un informe nuevo?
¿Hemos revisado los logos, los encabezados y los pies de página?
¿Están las zonas de relleno sin información previa?
¿Hay datos confidenciales de otros clientes en las plantillas?
¿Tenemos los contactos actualizados?
Tabla 2: Contenido del Documento
Cuestiones Revisado
¿Se corresponden los gráficos del informe ejecutivo con los datos
correctos?
¿Tiene el informe ejecutivo un lenguaje demasiado técnico?
¿Se pueden explicar de modo sencillo?
¿Tiene el informe técnico el lenguaje apropiado?
¿Tiene cada vulnerabilidad su evidencia?
¿Se puede reproducir correctamente cada vulnerabilidad?
¿Se ha mencionado que estándar hemos usado?
ICSP v2
- ICSP v.2 -
¿Se ha indicado el tipo de herramientas que se han usado?
¿Tiene el re-test un formato correcto?
Tabla 3: Vulnerabilidades
Cuestiones Revisado
¿Está bien descrita la vulnerabilidad?
¿Tenemos todas las evidencias?
¿Tenemos su CVS o sus referencias?
¿Se ha incluido en ambos informes?
¿Funcionan correctamente los links del informe?
¿Están añadidas sus recomendaciones?
¿Han aparecido vulnerabilidades nuevas después de un re-test?
¿Son realistas y realizables las recomendaciones en un plazo correcto?
Tabla 4: Entrega del Documento
Cuestiones Revisado
¿Tenemos informes anteriores? ¿Están localizables?
¿Sabemos a quién debemos remitir cada informe?
¿Sabemos cómo deben de ser entregados (medio, encriptación)?
¿Está debidamente convertido a PDF y con su marca de agua?
¿Existe SLA de entregas?
ICSP v2

Get File Drive Sub Modulo

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Get File Drive Sub Modulo

Cargado por

Copyright:

Formatos disponibles

Module 1: Introducción al

Módulo 1 - Introducción ............................................................................................4

¿Qué es un Pentest? ................................................................................................. 5

Fases de un pentest ........................................................................................................................................................ 15

Informe Técnico ................................................................................................................................................................................................... 38

Entrega de Informes ....................................................................................................................................................... 40

Registrar of Companies for England and Wales

Company Number 10246354

Copyright © 2018 by IHackLabs

Dentro del área de la seguridad el curso se centra en profundidad en la metodología y el

Aun siendo el curso orientado a análisis de infraestructura se ha considerado imprescindible

El objetivo de un pentest es la de acceder al sistema o lograr un objetivo previamente

Por lo tanto, la fase de documentación y explicación de los hechos es realmente importante,

Debe definirse que parte de la infraestructura va a analizarse como Wi-Fi, aplicaciones

Debe definirse el entorno a analizar, no es lo mismo atacar un entorno de preproducción que

Es necesario saber quién va a tener acceso a los resultados finales y su nivel de

cliente. Del mismo modo debemos de cumplir a estrictamente la protección de datos y la

Aunque el Pentester no interviene en estas negociaciones es imprescindible que sepa que se

Auditoría de Caja Negra (Black Box)

En este tipo de auditoría al profesional no se le proporciona ningún tipo de documento

Al no disponer de información sobre la infraestructura que forma la empresa el auditor

Auditoría de Caja Blanca (White Box)

En esta auditoría se dispondrá de toda la información necesaria para realizar la prueba de

Este tipo de prueba se demora en el tiempo porque se deben de analizar muchos

Al disponer de información sobre los sistemas, usuarios, información sobre la arquitectura y

Auditoría de Caja Gris (Grey Box)

Suelen realizarse parte en remoto y parte en las oficinas del cliente.

Se proporcionarán datos de infraestructura, cuentas de usuario habitualmente sin privilegios,

La información proporcionada permite al auditor conocer mejor la infraestructura de modo

Es importante comprender la diferencia que existe entre el término pentest respecto al

Una evaluación de vulnerabilidades consiste en el proceso de evaluación de la eficacia de

El pentest se enfoca en una meta en concreto mientras la evaluación de vulnerabilidades

Cada área requiere de técnicos especializados diferentes, estándares, certificaciones y

En un análisis de vulnerabilidades comprobaríamos la alarma, los cierres de las ventanas, las

Cuantos más puntos de vulnerabilidad se encuentren más completo será el análisis,

El auditor presenta un informe completo con todas las vulnerabilidades encontradas,

La evaluación de vulnerabilidades no tiene como objetivo transgredir la seguridad de un

Test de Penetración – Pentest

El objetivo de un pentest no es el de encontrar y analizar todas las vulnerabilidades al detalle

Las pruebas de penetración son realizadas habitualmente por personal ajeno e

Evaluación de Vulnerabilidades Test de Penetración

Vamos a hacer un repaso a las metodologías más utilizadas en la industria de la seguridad

OWASP (Open Web Application Security Project)

Posiblemente la más utilizada por todo tipo de profesionales del área de la

Las guías más utilizadas son las siguientes:

OSSTMM (Open Source Security Testing Methodology)

Esta metodología cubre en profundidad partes como el área de

Es una comunidad de código abierto y todo el material puede ser

Merece la pena estudiar esta metodología en profundidad.

ISSAF (Information System Security Assessment

La metodología incluye tres fases siguientes:

 PRE ASSESSMENT Fase de planificación y preparación

PTES (Penetration Testing Execution Standard)

Apartados del estándar PTES.

Si la auditoría es larga puede definir un calendario de reuniones donde se expondrán

Si la auditoría es presencial y aunque no es obligatorio, es recomendable escribir un mail de

Aunque la información se haya proporcionado anteriormente es conveniente adjuntar

Para comenzar a recopilar información es conveniente apoyarse en un esquema en el que

Es importante que aparte de catalogar la información recolectada del sistema,

Pasemos ya a la parte de recopilación y enumeración:

Adicionalmente estas herramientas nos proporcionaran la posibilidad de organizar la

La información más relevante en un pentest de infraestructura es, entre otros, la siguiente:

 Rangos de IPs  Direcciones de e-mail