Bienvenidos a esta Guía: Reporte del Pentest, Remediación y Seguimiento. Comparte este articulo y síguenos para recibir más capítulos, guías y cursos.

Esta guía es parte de un curso mucho más grande en donde te enseñamos a convertirte en hacker de 0 a 100. Desde los conocimientos más básicos hasta conseguir empleo.

Para saber más comente a continuación, respondemos todos y cada uno de los comentarios.

Índice

¿Te gustaría enterarte de cuando lanzamos descuentos y nuevos cursos?

Documentación de las actividades realizadas durante el pentesting.

La documentación es una parte crucial del proceso de pentesting y contribuye a la transparencia, claridad y seguimiento del trabajo realizado. Aquí hay una descripción de cómo se documentan las actividades durante el pentesting:

Informe de Alcance: Detalla los objetivos, limitaciones, y el alcance del pentesting. Define claramente lo que está permitido y lo que no.
Reconocimiento: Incluye resultados de escaneo de información pública, WHOIS, DNS, y cualquier otro método utilizado para recopilar información sobre el objetivo.
Escaneo de Vulnerabilidades: Lista de vulnerabilidades encontradas utilizando herramientas de escaneo automatizado.
Exploits Utilizados: Detalle de exploits empleados y cómo se llevaron a cabo, incluyendo cualquier ajuste o personalización necesaria.
Resultados de Pruebas de Penetración: Documenta las pruebas manuales realizadas, incluyendo la explotación de vulnerabilidades y el acceso a sistemas.
Registro de Actividades del Sistema: Detalles de las acciones realizadas en los sistemas objetivo. Incluye comandos ejecutados, cambios realizados, y cualquier actividad relevante.
Capturas de Pantalla y Evidencia: Imágenes que respaldan los resultados y demuestran la explotación exitosa o la identificación de vulnerabilidades.
Recopilación de Datos: Detalles sobre cualquier información confidencial o sensible recopilada durante el pentesting.
Recomendaciones de Mitigación: Propuestas para abordar y corregir las vulnerabilidades encontradas. Incluye pasos específicos y mejores prácticas.
Conclusiones y Resumen Ejecutivo: Un resumen general de las actividades, hallazgos clave, y una evaluación del riesgo. Dirigido a un público no técnico.
Firmas y Autorizaciones: Incluye firmas del equipo de seguridad y las partes autorizadas que respaldan la validez y el alcance del informe.
Revisión con el Cliente: Sesión para revisar el informe con el cliente, aclarar dudas y discutir los resultados.

La documentación precisa y completa es esencial para garantizar la efectividad y la integridad de las pruebas de penetración, así como para proporcionar a los clientes la información necesaria para mejorar su postura de seguridad.

Resumen Ejecutivo

El resumen ejecutivo está dirigido a la alta dirección y debe ser conciso y directo. En este apartado se describe la razón del ejercicio, los principales hallazgos y el impacto potencial de las vulnerabilidades encontradas.

Contenido Clave:

Propósito del ejercicio: Breve explicación de por qué se llevó a cabo el ejercicio Red Team (evaluación de la seguridad, cumplimiento normativo, simulación de amenazas avanzadas).
Principales vulnerabilidades: Resumen de las vulnerabilidades más críticas descubiertas durante el ejercicio.
Impacto: Descripción del impacto que estas vulnerabilidades podrían tener en la seguridad, operaciones y reputación de la organización.
Recomendaciones clave: Las acciones más urgentes que la organización debería tomar para mitigar las vulnerabilidades encontradas.

Crear un informe de pentesting

Es una pregunta muy habitual entre profesionales que están empezando a trabajar en pentesting y aunque hay plantillas que se pueden encontrar fácilmente en internet y algunas herramientas los generan automáticamente, como profesionales debemos seguir ciertas normas a la hora de elaborar los documentos que debo entregar a los clientes tras finalizar los trabajos.

Nociones básicas

La elaboración de informes es una de las cuestiones más importantes en cualquier auditoría y en ellos se debe reflejar de forma clara y concisa los descubrimientos y conclusiones a las que has llegado. Cualquier informe normalmente debe incluir como mínimo lo siguiente:

Portada:

La portada del documento suele ser genérica e incluye entre otras cosas, información sobre la empresa, fecha en la que se entrega el documento y detalles básicos.

Índice:

En el índice es común incluir enlaces o accesos directos para que sea fácil moverse por las diferentes secciones del documento. Ejemplo:

CONTENIDO

ALCANCE……………………………………………………………………………………………………………………………………….4

HOJA DE REVISION………………………………………………………………………………………………………………………….5

OBJETIVOS y METODOLOGÍA DE TRABAJO…………………………………………………………………………………………6

Descripción General de Pruebas por Fase de Pentesting……………………………………………………………………..7

Explotación ……………………………………………………………………………………………………………………………………9

Calificación global del riesgo ………………………………………………………………………………………………………….10

NIVEL ALTO – Ausencia de fichas (tokens) Anti-CSRF …………………………………………………………………………11

CONSECUENCIAS……………………………………………………………………………………………………………………….12

SOLUCIÓN ………………………………………………………………………………………………………………………………..13

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………14

NIVEL ALTO – Content Security Policy (CSP) Header Not SeT ……………………………………………………………..15

CONSECUENCIAS……………………………………………………………………………………………………………………….16

SOLUCIÓN ………………………………………………………………………………………………………………………………..17

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………18

NIVEL ALTO – Missing Anti-clickjacking Header…………………………………………………………………………………19

CONSECUENCIAS……………………………………………………………………………………………………………………….20

SOLUCIÓN ………………………………………………………………………………………………………………………………..21

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………22

NIVEL MEDIO – Application Error Disclosure …………………………………………………………………………………….23

CONSECUENCIAS……………………………………………………………………………………………………………………….24

SOLUCIÓN ………………………………………………………………………………………………………………………………..25

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………26

NIVEL MEDIO – Cookie No HttpOnly Flag…………………………………………………………………………………………27

CONSECUENCIAS……………………………………………………………………………………………………………………….28

SOLUCIÓN ………………………………………………………………………………………………………………………………..29

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………30

NIVEL MEDIO – Cookie Without Secure Flag…………………………………………………………………………………….31

CONSECUENCIAS……………………………………………………………………………………………………………………….32

SOLUCIÓN ………………………………………………………………………………………………………………………………..33

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………34

NIVEL MEDIO – Cookie Without Secure Flag…………………………………………………………………………………….35

CONSECUENCIAS……………………………………………………………………………………………………………………….36

SOLUCIÓN ………………………………………………………………………………………………………………………………..37

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………38

NIVEL MEDIO – Permissions Policy Header Not Set……………………………………………………………………………39

CONSECUENCIAS……………………………………………………………………………………………………………………….40

SOLUCIÓN ………………………………………………………………………………………………………………………………..41

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………42

NIVEL MEDIO – SSL/TLS usa algoritmos hashing y cifrado débiles ……………………………………………………….43

CONSECUENCIAS……………………………………………………………………………………………………………………….44

SOLUCIÓN ………………………………………………………………………………………………………………………………..44

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………46

NIVEL MEDIO – Strict-Transport-Security Header Not Set…………………………………………………………………..47

CONSECUENCIAS……………………………………………………………………………………………………………………….48

SOLUCIÓN ………………………………………………………………………………………………………………………………..49

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………50

NIVEL MEDIO – X-Content-Type-Options Header Missing…………………………………………………………………..51

CONSECUENCIAS……………………………………………………………………………………………………………………….52

SOLUCIÓN ………………………………………………………………………………………………………………………………..53

EVIDENCIA Y REFERENCIAS …………………………………………………………………………………………………………54

Información General …………………………………………………………………………………………………..55

Análisis de IP ………………………………………………………………………………………………………………59

Análisis DEL DOMINIO …………………………………………………………………………………………………61

Búsqueda Inversa de IP………………………………………………………………………………………………..58

Análisis de Servicios…………………………………………………………………………………………………….70

Análisis de Puertos ……………………………………………………………………………………………………..62

SSL…………………………………………………………………………………………………………………67

Control de versiones:

El control de versiones debe incluir como mínimo, una descripción de los cambios introducidos en cada modificación del documento con una fecha y autor. Ejemplo:

HOJA DE REVISION

Versión	Fecha	Encargado	Notas
1.0	17/08/2023	Laprovittera Carlos	Auditoría Externa

Disclaimer y confidencialidad de la información

ALCANCE

El alcance del presente trabajo consistió en la evaluación del riesgo de seguridad y su grado de exposición a través de técnicas de intrusión. Se utilizaron herramientas de seguridad, analizadores de vulnerabilidades y metodologías de recolección de información del mismo modo que serían utilizadas por los atacantes.

Las tareas llevadas a cabo comprenden el reconocimiento activo de sistemas con el fin de evaluar los riesgos potenciales de los mismos. Finalmente se realizó un análisis e intento de intrusión sobre los sistemas activos, con el propósito de hallar las potenciales vulnerabilidades que puedan afectarlos. Los objetivos realizados para el Pentest son la selección del dominio, sistemas, servicios y aplicativos sobre las siguientes direcciones IP y Dominios:

200.190.180.170: webdelcliente.com

El cliente contrató a Router ID para llevar a cabo una auditoría externa contra sus sitios y aplicativos webs para proporcionar una demostración práctica de la eficacia de sus sistemas y metodología de seguridad, así como para proporcionar una estimación de su susceptibilidad a la explotación, integridad, exposición o perdida de datos.

La prueba se realizó de acuerdo con el Método de Pruebas de Penetración de Seguridad de la Información de Router ID. El Analista de Seguridad de la Información (ISA) de Router ID llevó a cabo La auditoría en coordinación con los miembros del personal de Tecnología de la Información (TI) del cliente para garantizar pruebas seguras, ordenadas y completas dentro del alcance aprobado.

Contemple la gran importancia de solucionar estas brechas de seguridad que permiten un gran riesgo de violación de cumplimiento y potencialmente sujeto a multas y pérdida de reputación empresarial.

El presente Informe contiene información confidencial, no debe ser enviado vía mail, fax o cualquier otro medio electrónico a menos que este se encuentre específicamente aprobado por las políticas de seguridad de la Compañía. Todas las copias electrónicas o en papel del presente documento deben ser guardadas en un sitio protegido.

No comparta la información contenida en este documento, a menos que la otra persona esté autorizada para ello. router-id.com da permiso para copiar este informe con el fin de difundir información dentro de su organización o cualquier agencia reguladora.

Metodologías utilizadas

OBJETIVOS Y METODOLOGÍA DE TRABAJO

Este documento detalla la evaluación de seguridad referido al Pentesting externo. El objetivo de este trabajo fue identificar las vulnerabilidades dentro del alcance acordado entre las partes, y los riesgos que pueden causar en el negocio de la empresa.

Es su responsabilidad implementar las recomendaciones que se harán, con el objetivo de aumentar la seguridad en los dominios (desarrollo de aplicaciones, soporte de infraestructura), así como gestionar el nivel de exposición a los riesgos de la organización y la adecuación a las cuestiones regulatorias.

Si usted no dispone de personal calificado para esta tarea nosotros podemos llevarla a cabo. Consulte por nuestro servicio de corrección de fallas de seguridad y hardening.

Los Objetivos específicos son:

• Detectar vulnerabilidades y problemas de seguridad que puedan ser aprovechados por atacantes.

• Evaluar la efectividad y respuesta de los sistemas de seguridad implementados (Firewalls, detección de intrusos y otros sistemas).

• Analizar y determinar el nivel de exposición de la infraestructura tecnológica de los sistemas de acuerdo con las vulnerabilidades detectadas.

• Presentar recomendaciones concretas que permitan corregir los problemas y brechas de seguridad detectados y minimizar los riesgos asociados.

Contexto de la auditoría y nociones generales

DESCRIPCIÓN GENERAL DE PRUEBAS POR FASE DE PENTESTING

1. Advanced SQL Injection

2. Análisis de IP

3. Análisis de metadatos

4. Análisis de Puertos

5. Análisis de Servicios

6. Análisis de servicios web

7. Análisis del Dominio

8. Análisis SSL

9. Apache no soportado

10. Application Error Disclosure

11. Archivo robots y sitemap

12. Archivos de backup

13. Ataque al Host Header

14. Ausencia de CAPTCHA

15. Ausencia de fichas (tokens) Anti-CSRF

16. Autenticación

17. Autocomplete

18. Búsqueda Inversa de IP

19. Componentes cliente desactualizados

20. Comprobación de tokens anti-CSRF

21. Configuración de la red de prueba / infraestructura

22. Configuración Incorrecta de CORS / Cross-Origin Resource Sharing

23. Confusión de Ruta Relative

24. Contenido HTTPS Disponible vía HTTP

25. Content Security Policy (CSP) Header Not SeT

26. Contraseña de texto claro

27. Cookie No HttpOnly Flag

28. Cross Site Scripting

29. Cross-Domain JavaScript Source File Inclusion

30. Definición de Roles

31. Descarga de documentos sin sesión válida

32. Desconfiguración de Dominio Cruzado / Control de acceso HTTP

33. Detección y fortaleza del Firewall

34. Divulgación de información – Directivas inseguras de PHP

35. DIVULGACIÓN DE INFORMACIÓN – Manejo de errores inapropiados

36. DIVULGACIÓN DE INFORMACIÓN – mediante »X-Powered-By»

37. Divulgación de información – Mensajes de error de depuración

38. Divulgación de la marca de hora – Unix

39. Divulgación de Proxy

40. Divulgación de versión IIS y .NET

41. Entrada de usuario o login

42. Esquema de autorización de omisión

43. Esquema de gestión de sesión

44. Fuga de información

45. HSTS Missing From HTTPS Server (RFC 6797)

46. HTTP TRACE Methods Allowed

47. Información General

48. Inyección NoSQL – MongoDB

49. Inyección Remota de Comandos del Sistema Operativo

50. Inyección XSLT

51. Listado de directorios

52. Mapas del sitio web

53. Missing Anti-clickjacking Header

54. Path Traversal

55. Permissions Policy Header Not Set

56. PHP múltiples vulnerabilidades

57. Política de Usuario débil o no forzada

58. Private IP Disclosure

59. Redirecciones no controladas

60. Reunión de la Información Reconocimiento en Motores de Búsqueda

61. Saltando 403

62. Secure Pages Include Mixed Content

63. Server-side template injection

64. SQL Injection

65. SSL/TLS, SSLv2 y SSLv3 detección

66. Strict-Transport-Security Header Not Set

67. SUB RESOURCE INTEGRITY ATTRIBUTE MISSING

68. Unauthenticated Blind SSRF via DNS Rebinding

69. Uploading de archivos sin restricción

70. Variables de sesión expuestas

71. WordPress, Temas Y Plugins Desactualizados

72. X-Content-Type-Options Header Missing

EXPLOTACIÓN

La fase de explotación consiste en realizar todas aquellas acciones que puedan comprometer al sistema auditado, a los usuarios o a la información que maneja. Principalmente se comprueba que no se puedan realizar ataques tipo:

• Inyección de código

• Inclusión de ficheros locales o remotos

• Evasión de autenticación

• Carencia de controles de autorización

• Ejecución de comandos en el lado del servidor

• Ataques tipo Cross Site Request Forgery

• Control de errores

• Gestión de sesiones

• Fugas de información

• Secuestros de sesión

• Comprobación de las condiciones para realizar una denegación de servicio

• Carga de ficheros maliciosos

Estos tipos de ataques se realizan adaptando el desarrollo de cada ataque, técnicas en uso y las últimas tecnologías disponibles.

Post explotación

En caso de encontrarse una vulnerabilidad que permita realizar otras acciones en el sistema auditado o en su entorno, se realizarán controles adicionales con el objetivo de comprobar la criticidad de esta. En función de las posibilidades que permita una vulnerabilidad concreta, se intentarán realizar las siguientes acciones de post-explotación:

• Obtención de información confidencial

• Evasión de mecanismos de autenticación

• Realizar acciones del lado de los usuarios

• Realizar acciones o ejecutar comandos en el servidor que aloja la aplicación

• Privilegios disponibles en el servidor (si se consigue acceso al mismo)

• Otros sistemas o servicios accesibles desde la aplicación comprometida

• Realizar acciones sin el consentimiento del usuario

La posibilidad de encadenar varias vulnerabilidades para conseguir un acceso de mayor nivel o para evadir los controles de seguridad también serán escenarios valorados a la hora de realizar el análisis de riesgos. Utilizamos varias metodologías, pero nos vamos a centrar en OWASP TOP 10 – 2021. OWASP es una organización sin ánimo de lucro a nivel mundial dedicada a mejorar la seguridad de las aplicaciones y del software en general.

https://owasp.org/Top10/es

CALIFICACIÓN GLOBAL DEL RIESGO

Habiendo considerado los resultados potenciales y los niveles de riesgo evaluados para cada actividad de prueba documentada, Hackware considera que la exposición global al riesgo con respecto a los intentos de actores maliciosos de violar y controlar los recursos dentro de su entorno de información es ALTO (según lo determinado utilizando la Clasificación del riesgo Puntuación CVSSv3).

https://www.incibe-cert.es/blog/cvss3-0

La tabla que figura a continuación proporciona una clave para la denominación de los riesgos y los colores utilizados a lo largo de este informe para ofrecer un sistema de puntuación de riesgos claro y conciso.

Cabe señalar que la cuantificación del riesgo empresarial global planteado por cualquiera de los problemas detectados en las pruebas queda fuera de nuestro alcance. Esto significa que algunos riesgos pueden considerarse elevados desde un punto de vista técnico, pero, como resultado de otros controles que desconocemos, pueden ser críticos o no desde un punto de vista empresarial.

Risk Rating	CVSSv3 Score	Descripción
CRITICAL	9.0 – 10	Se ha descubierto una vulnerabilidad crítica. Es necesario resolverla lo antes posible.
HIGH	7.0 – 8.9	Se ha descubierto una vulnerabilidad alta. Esto requiere una resolución a corto plazo.
MEDIUM	4.0 – 6.9	Se ha descubierto una vulnerabilidad media.Debe resolverse a lo largo del proceso de mantenimiento.
LOW	0.1 – 3.9	Se ha descubierto una vulnerabilidad baja. Esto debe abordarse como parte de las tareas de mantenimiento rutinario.
INFO	0	Se ha producido un descubrimiento que se notifica a título informativo. Debe abordarse para cumplir con las prácticas líderes.

Pruebas realizadas, descubrimientos y pruebas de concepto. (lo veremos en más profundidad)
Conclusiones y recomendaciones. (lo veremos en más profundidad)

En la introducción y contexto del documento, se describen detalles sobre la auditoría a realizar y su alcance, algo que evidentemente también se debe de encontrar reflejado en el acuerdo firmado con el cliente. Esta parte del documento pretende informar al lector sobre cuáles son las pruebas que se han realizado sin entrar en demasiados detalles, a modo de resumen ejecutivo.

Otro detalle importante que es necesario tener en cuenta en cualquier informe, es la sección correspondiente a las metodologías utilizadas, las cuales en todo caso dependerán de la auditoría a realizar. Es altamente recomendable implementar metodologías que ya han sido depuradas y tengan una buena aceptación por parte de la industria. Por ejemplo, algunas metodologías interesantes se listan a continuación, aunque evidentemente aplican en función del tipo de auditoría realizada:

Penetration Testing Execution Standard (PTES)
PCI (Payment Card Industry) Penetration testing guide
Open Source Security Testing Methodology Manual (OSSTMM)
OWASP Top 10
OWASP Testing Guide
OWASP Mobile Top 10
OWASP API Top 10

El contenido propiamente dicho del documento debe de incluir las pruebas que se han realizado, explicando cada una de las etapas de la auditoría, herramientas y técnicas utilizadas, así como los resultados de cada una. Se trata de una sección en donde es importante incluir los detalles de la forma más clara y concisa, evitando redundancias y bloques de código o salidas de log demasiado extensas con el fin de favorecer la legibilidad del documento.

En el caso de que sea necesario incluir dichos elementos, sería recomendable abordarlos en anexos independientes para que el lector los pueda revisar por separado. En este punto, probablemente lo más importante es que la información aporte valor. Es decir, no sirve de nada incluir cada una de las pruebas de concepto que se han ejecutado si no han producido los resultados esperados. Solo se debe incluir información relevante y de interés para el objeto de la auditoría.

De nada sirve dedicar 2 o 3 páginas del informe explicando que se ha lanzado un exploit para el Apache (por poner un ejemplo) si dicho exploit no ha funcionado debido a que probablemente el servicio no es vulnerable. Incluye sólo información que aporte valor.

Finalmente, en la sección de recomendaciones viene bien incluir algunos puntos a tener en cuenta para mejorar la seguridad del sistema auditado, aunque también se pueden resaltar aquellas configuraciones y/o buenas practicas que se están llevando a cabo con el fin de que el cliente siga haciendo uso de ellas y alentar a su mantenimiento.

Si se encuentran vulnerabilidades es muy importante incluir contramedidas o recomendaciones que sean útiles para mitigarlas o mecanismos de protección que ayuden a solucionar los problemas detectados. Ojo, el hecho de incluir esas contramedidas no es vinculante y no significa que seas tu quien las va a implementar. Te han contratado para ejecutar una auditoría y detectar problemas, implementar las soluciones es algo que debe valorar el cliente.

Tipo de auditoría

Se pueden crear diferentes tipos de informes dependiendo de las necesidades del cliente, las cuales han tenido que quedar reflejadas en el acuerdo. Es posible que la auditoría a realizar se centre en uno de los siguientes escenarios:

Pentesting perimetral/externo.
Pentesting interno.
Pentesting wireless

Dependiendo de cada caso hay que tener en cuenta factores adicionales que deben quedar reflejados en el documento, por ejemplo cuando un cliente pide un enfoque mixto y una parte de la auditoría será externa y otra parte interna.

Informe técnico e Informe ejecutivo

Con todo lo anterior claro, lo primero que hay que tener en cuenta es que no todos los clientes son iguales y en algunos casos es necesario desarrollar 2 o más informes que reflejen las tareas realizadas. Es importante adaptarse y entender el público objetivo. Es decir, si la persona que va a leer el informe es personal técnico le interesará que esté orientado a describir las vulnerabilidades, defectos y recomendaciones que aporta el documento.

En este caso será revisado por una persona que como mínimo, tiene unos conocimientos básicos y entenderá lo que cuentas pero si por ejemplo, ese mismo documento lo lee un directivo, responsable de área o personal no técnico, evidentemente lo más probable es que entienda poco o nada. Imagina por un instante que un experto en finanzas (por poner un ejemplo) te pasa un informe técnico de una auditoría financiera, crees que tendrás el criterio suficiente para decir si eso que te han enviado está «bien» o «mal»? probablemente pasarás de leerlo y se lo enviarás a alguien que sea experto en el tema.

Dependiendo del alcance y lo que se haya hablado con el cliente es probable que tengas que elaborar un informe orientado al personal técnico y otro a «decision makers» o directivos/responsables, en cada caso el lenguaje que utilizas y el mensaje que transmites debe ser lo suficientemente claro para el lector objetivo.

Las plantillas no hacen un buen informe.

Puedes usar plantillas disponibles en Internet o las que a lo mejor se encuentran disponibles en la empresa en la que trabajas, por supuesto que es algo perfectamente valido pero no deja de ser una base que te ayuda a ahorrar tiempo en definir un diseño y «maquetar» secciones. Puedes (y debes) adaptar la plantilla a la auditoría que estás realizando, no es algo estático que debes seguir a rajatabla. Si te hace falta añadir, quitar o mover secciones lo haces y ya está. Que la plantilla que utilices no se convierta en un problema, se ha creado precisamente para que puedas hacer el trabajo más rápido.

Elaboración de informes claros y concisos.

Cómo Redactar un Informe de Pentesting con Éxito

1. Planificación en la Redacción: Evita dejar la redacción del informe para el último momento. Documenta hallazgos durante la auditoría y elimina información innecesaria para evitar un informe extenso pero carente de valor.

2. Revisión por Pares: La redacción es un arte. Pide a un colega que lea el informe antes de entregarlo. La claridad para ti puede no ser igual para los demás. Obtener una segunda opinión ayuda a detectar errores y mejorar la comprensión del mensaje.

3. Facilita la Lectura con Elementos Visuales: Incorpora capturas de pantalla para ilustrar puntos clave. Mantén la calidad sobre la cantidad; la concisión es clave. Evita detalles irrelevantes y enfócate en la información esencial.

4. Niveles de Criticidad: Asigna niveles de gravedad a cada vulnerabilidad según el modelo de CVS. Destaca la urgencia de solucionar problemas críticos y distingue aquellos menos preocupantes.

5. Buenas Prácticas en la Redacción: Atiende a detalles ortográficos para una presentación profesional. Incluye información de contacto, horarios y canales de comunicación. Consulta con el cliente antes de sugerir actualizaciones en servicios desactualizados.

6. Recomendaciones Prácticas: En las capturas, preserva la privacidad evitando información sensible. Adjunta PoCs y exploits en anexos. Usa enlaces para conceptos técnicos. Facilita recomendaciones en formato de «checklist» y proporciona referencias e instrucciones adicionales.

7. Evita Excesos y Opiniones Personales: Ajusta la cantidad de capturas para evitar excesos. Sé neutral; evita opiniones personales. Mantén un equilibrio para que el informe no parezca un álbum de fotos, sino un documento de calidad.

8. Historial de Eventos: Incluye un historial con cambios de alcance, organizativos, disposición de sistemas y eventos relevantes. Proporciona un contexto cronológico que mejore la comprensión del proceso de auditoría.

9. Herramientas y Plantillas Útiles: Utiliza plantillas de PurpleSec, Pentest-hub, TCM Security, Offensive Security y TGB Security. Explora la herramienta PWNDoc para una gestión eficiente de informes.

Comunicación de las vulnerabilidades encontradas y recomendaciones de mitigación

Ejemplos de Vulnerabilidades encontradas, pruebas, consecuencias y recomendaciones de mitigación

NIVEL ALTO – AUSENCIA DE FICHAS (TOKENS) ANTI-CSRF

No se encontraron fichas (tokens) Anti-CSRF en formularios HTML. Esto permite una solicitud falsa entre sitios en un ataque que compromete y obliga a una víctima a enviar su solicitud HTTP a un destino objetivo sin su conocimiento o intención para poder realizar una acción como si fuera el usuario legitimo. La causa es la funcionalidad oculta de la aplicación utilizando acciones de URL/formulario que pueden ser adivinados de forma repetible.

La naturaleza del ataque es que CSRG explota la confianza que un sitio web proporciona a un usuario. Por el contrario, las cadenas de comandos de los sitios cruzados (XSS) explotan la confianza que un usuario proporciona en un sitio web.

Al igual que XSS, los ataques CSRG no tienen por qué ser de sitios cruzados, pero hay la posibilidad de que puedan serlo. La falsificación de las solicitudes ente los sitios también se conoce como CSRF, XSRG y ataques con un solo clic. Los ataques de CSRG son muy efectivos en varias situaciones, que incluyen:

• La victima tiene una sesión activa en el sitio de destino.

• La víctima se autoriza por medio de la autenticación HTTP en el sitio de destino.

• La víctima se encuentra en la misma red local que el sitio de destino.

CSRF se ha utilizado especialmente para poder realizar una acción contra un sitio objetivo utilizando los privilegios de la víctima, pero se han revelado técnicas recientes para difundir información al obtener el acceso a la respuesta.

El riesgo de divulgación de información aumenta de forma drástica cuando el sitio de destino se encuentra vulnerable a XSS, porque XSS se puede utilizar como una plataforma para CSRF, lo que le permite al atacante que opere desde adentro de los límites de la misma política de origen.

CONSECUENCIAS

Cuando se lleva a cabo con éxito, un ataque CSRF puede tener una amplia variedad de repercusiones, según los privilegios de la víctima. Si el objetivo es un usuario estándar, es probable que toda su cuenta se vea comprometida, desde su información personal hasta sus privilegios en el sitio.

Y eso no es nada comparado con el impacto de un ataque CSRF en la cuenta de un administrador: podría paralizar todo el sitio. Dada la magnitud de un posible ataque CSRF, es esencial que cualquier paquete de seguridad web pueda proteger contra él.

El objetivo más común de un ataque CSRF es el robo de datos, identidad o dinero. Estos son algunos de los usos más comunes de CSRF:

• Puede comprometer todo el sistema de administración de contenido: Puede agregar o eliminar contenido en un sitio web. Si la víctima es el administrador, el atacante toma el control de todo el sitio.

• Cambiar la contraseña de un usuario: Si la víctima ha iniciado sesión en su cuenta, el atacante puede falsificar una solicitud para cambiar su correo electrónico. Después de eso, puede falsificar una solicitud de restablecimiento de contraseña y tomar el control total de la cuenta de la víctima.

• Agregar artículos al carrito de un usuario o cambiar la dirección de entrega de un pedido: En el caso de un ataque CSRF, el atacante puede modificar esta información. En el sitio web, la víctima aparece como autora de estas modificaciones.

SOLUCIÓN

Utilice una biblioteca o marco comprobado que no acepte que ocurra esta debilidad o que proporcione construcciones que permitan que esta debilidad sea más sencilla de evitar. Por ejemplo, utilice el paquete anti-CSRG como el CSRGuard de OWASP.

Asegúrese de que su aplicación esté libre de fallas de secuencias de comandos entre sitios, ya que la mayoría de las defensas de CSRF pueden detenerse por medio del uso de secuencias de comandos manejadas por el atacante.

Origine un nonce único para cada uno de los formularios, colóquelo en el formulario y confirme la independencia al obtener el formulario. Asegúrese de que el nonce no sea predecible (CWE-330). Debe tener en cuenta que esto puede pasar desapercibido utilizando XSS.

Identificar las operaciones que sean especialmente peligrosas. Cuando el usuario desarrolla una operación peligrosa, envíe una solicitud de confirmación de forma separada para poder garantizar que el usuario tenga la intención de desarrollar esa operación.

Utilice el control de gestión de la sesión de ESAPI. Este control introduce un elemento para CSRF y no utilice el método GET para ninguna de las solicitudes que puedan desencadenar un cambio de estado. Revise que la solicitud se creó en la página esperada.

Un token anti-CSRF es un valor oculto que se envía con las cookies y la solicitud del usuario en particular. Así es como funciona:

El servidor web genera este token y se coloca como un campo oculto en el formulario.
Cuando el usuario completa y envía el formulario, el token se incluye en la solicitud POST.
El servidor comparará el token generado y el token enviado por el usuario.
Si coincide, la solicitud será válida. Si no coincide, la solicitud se considera inválida. Esto evita que se produzcan ataques CSRF.
O mediante plugins: Headers Security Advanced & HSTS WP

https://wordpress.org/plugins/headers-security-advanced-hsts-wp/embed/#?secret=H6hhdHRTIP#?secret=tZ882GfuY7

EVIDENCIA Y REFERENCIAS

REFERENCIAS

• https://wordpress.org/plugins/headers-security-advanced-hsts-wp

• https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control.html

• https://owasp.org/www-project-web-security-testing-guide/v42/4– Web_Application_Security_Testing/06-Session_Management_Testing/05- Testing_for_Cross_Site_Request_Forgery

• http://projects.webappsec.org/Cross-Site-Request-Forgery

• http://cwe.mitre.org/data/definitions/352.html

• https://owasp.org/Top10/A01_2021-Broken_Access_Control/

• https://kinsta.com/es/base-de-conocimiento/hsts-missing-from-https-server/

EJEMPLO 2:

NIVEL MEDIO – SSL/TLS usa algoritmos hashing y cifrado débiles

SSL (Secure Sockets Layer) y TLS (Transport Layer Security) son protocolos de seguridad utilizados para cifrar y proteger las comunicaciones en línea entre un cliente (como un navegador web) y un servidor. Estos protocolos garantizan la confidencialidad y la integridad de los datos transmitidos a través de Internet.

Los algoritmos de hash y cifrado son componentes esenciales de SSL/TLS, pero si se utilizan algoritmos débiles, la seguridad de las comunicaciones puede estar comprometida.

Algoritmos de Hash: Los algoritmos de hash son funciones matemáticas que convierten un conjunto de datos en una cadena de caracteres de longitud fija. Se utilizan para generar resúmenes únicos (hashes) de los datos, que luego se pueden comparar para verificar la integridad de los datos.

Algoritmos de Cifrado: Los algoritmos de cifrado son utilizados por SSL/TLS para cifrar los datos transmitidos, de modo que solo el destinatario legítimo pueda descifrarlos. Estos algoritmos aseguran la confidencialidad de la información.

CONSECUENCIAS

Consecuencias de Hashing Débil: Si se utilizan algoritmos de hash débiles, un atacante podría calcular fácilmente colisiones (dos conjuntos diferentes de datos que generan el mismo hash), lo que comprometería la integridad de la comunicación. Esto podría llevar a la manipulación de datos en tránsito sin ser detectado.

Manipulación de Datos: Un atacante podría modificar los datos en tránsito sin ser detectado, ya que podría generar un nuevo conjunto de datos que produzca el mismo hash que el conjunto original.
Integridad Comprometida: Las verificaciones de integridad se vuelven ineficaces, ya que los hashes no garantizan que los datos no hayan sido alterados.

Consecuencias de Cifrado Débil: Si se utilizan algoritmos de cifrado débiles, la información podría ser descifrada fácilmente por atacantes, lo que expondría los datos sensibles a la interceptación y el robo.

Intercepción de Datos: Atacantes pueden descifrar y robar información confidencial, como contraseñas y datos financieros.
Exposición a Ataques: Algoritmos de cifrado débiles pueden ser vulnerables a ataques de fuerza bruta y otros métodos de criptoanálisis.

SOLUCIÓN

Para garantizar una conexión segura con SSL/TLS, es importante:

Utilizar Algoritmos Fuertes: Se deben usar algoritmos de hash y cifrado robustos y actualizados que sean resistentes a los ataques actuales y futuros.
Actualizar Versiones: Utilizar las versiones más recientes de SSL/TLS, ya que implementan mejoras de seguridad y retiran el soporte a algoritmos obsoletos.
Configurar Ajustes de Seguridad: Configurar adecuadamente los ajustes de seguridad en el servidor para deshabilitar algoritmos débiles y priorizar aquellos más seguros.
Evaluar y Monitorear Regularmente: Realizar evaluaciones de seguridad periódicas para identificar posibles debilidades y mantenerse informado sobre las últimas amenazas y soluciones.

La elección de algoritmos de hash y cifrado sólidos es fundamental para asegurar que las comunicaciones a través de SSL/TLS sean seguras y confiables.

Solucion de Hashing Débil:

Utilizar Algoritmos Fuertes: Implementar algoritmos de hash robustos y resistentes a colisiones, como SHA-256 o superior, que sean menos susceptibles a ataques.
Actualizar Software: Mantener actualizado el software y las bibliotecas de criptografía para asegurarse de que estén utilizando las últimas y más seguras implementaciones de algoritmos de hash.

Consecuencias de Cifrado Débil:

Priorizar Algoritmos Fuertes: Configurar los servidores para priorizar el uso de algoritmos de cifrado seguros y resistente, como AES en modo Galois/Counter Mode (AES-GCM) o ChaCha20-Poly1305.
Desactivar Algoritmos Débiles: Eliminar del conjunto de algoritmos permitidos aquellos que sean considerados débiles o inseguros.
Actualizar Protocolos: Utilizar versiones actualizadas de TLS, como TLS 1.3, que han eliminado algoritmos de cifrado obsoletos y débiles.

EVIDENCIA Y REFERENCIAS

EJEMPLO 3

Resultados Detallados

Este es el núcleo técnico del informe, donde se detallan las vulnerabilidades descubiertas, cómo se explotaron y el impacto potencial de cada una.

Formato de Presentación:

Descripción de la vulnerabilidad: Descripción técnica clara y precisa de la vulnerabilidad encontrada. Cada vulnerabilidad debe incluir:
- Identificación (ID)
- Descripción
- Severidad (por ejemplo, crítica, alta, media, baja)
- Sistema o aplicación afectada.
Técnicas de explotación: Descripción de cómo el Red Team logró explotar la vulnerabilidad. Aquí se incluyen detalles sobre las herramientas utilizadas, los pasos técnicos seguidos, y las consecuencias inmediatas de la explotación.
Impacto: Evaluación del impacto de la explotación. ¿Qué consecuencias tendría para la organización si un atacante real explotara esa vulnerabilidad? ¿Podrían robar datos, tomar control de sistemas o realizar movimientos laterales?
Evidencia: Capturas de pantalla, logs o cualquier otro tipo de evidencia que respalde los hallazgos.

Ejemplo:

Vulnerabilidad: Configuración errónea en el servidor web.
- Descripción: El servidor Apache en el dominio example.com permite la lista de directorios, lo que puede exponer archivos sensibles.
- Severidad: Alta.
- Técnicas utilizadas: Mediante un escaneo con DirBuster, se identificaron directorios ocultos en /admin/.
- Impacto: Un atacante podría obtener acceso a archivos confidenciales sin autenticación previa.

Ejemplo de hoja de Resultados detallados

NIVEL ALTO – Advanced SQL Injection

La inyección SQL avanzada es una técnica más sofisticada que la inyección SQL básica, que utiliza técnicas más complejas y avanzadas para explotar vulnerabilidades en las aplicaciones web.

Esto puede incluir la manipulación de los datos de entrada de la aplicación, la identificación de patrones de filtrado, la explotación de errores en la aplicación y la utilización de herramientas automatizadas para la inyección de código malicioso.

La inyección SQL avanzada puede tener consecuencias graves, como la exposición de información confidencial, el robo de datos, la alteración de la información almacenada en la base de datos y la pérdida de datos importantes.

Por lo tanto, es importante que las empresas y desarrolladores de aplicaciones web implementen medidas de seguridad adecuadas para evitar este tipo de ataques.

CONSECUENCIAS

Las consecuencias de una inyección SQL Avanzadas pueden incluir:

Pérdida o alteración de datos: el atacante puede eliminar, modificar o extraer información de la base de datos.
Inestabilidad del sistema: el código malicioso puede causar que la base de datos deje de funcionar correctamente, lo que puede resultar en tiempos de inactividad y pérdida de disponibilidad.
Dificultad para detectar y mitigar el ataque: debido a que el código malicioso se inserta en una consulta SQL legítima.
Posibilidad de propagación del ataque: si el atacante tiene acceso a datos sensibles, como contraseñas de usuario, puede utilizarlos para propagar el ataque a otros sistemas.
Acceso no autorizado: un atacante podría obtener acceso no autorizado al sistema o a la aplicación web, lo que le permitiría acceder a información confidencial o realizar acciones maliciosas en el sistema.
Modificación de datos: un atacante podría modificar, eliminar o agregar datos al sistema, lo que podría tener graves consecuencias en la integridad y exactitud de los datos.
Ejecución de código malicioso: un atacante podría ejecutar código malicioso en el sistema, lo que podría resultar en la toma de control del sistema o en el robo de información confidencial.
Denegación de servicio: un atacante podría utilizar la inyección de comando para sobrecargar el sistema y hacer que se vuelva inoperable.

La no corrección de esta falla puede causar divulgación no autorizada de su información y la de sus clientes que podría dar lugar a fraude, usurpación de identidad y a sanciones reglamentarias.

Para evitar la inyección de comandos, es importante validar y filtrar todas las entradas de usuario en las aplicaciones web, y evitar el uso de comandos de shell en aplicaciones web.

Además, es importante mantener todas las aplicaciones y sistemas actualizados y parcheados para evitar que se exploten vulnerabilidades conocidas.

SOLUCIÓN

Para prevenir y solucionar la inyección SQL avanzada, se pueden tomar las siguientes medidas:

Validar y sanitizar todas las entradas de datos: Asegúrese de que todas las entradas de datos, ya sean proporcionadas por los usuarios o por otras fuentes, sean validadas y sanitizadas adecuadamente antes de ser utilizadas en una consulta SQL.
Utilizar consultas parametrizadas: En lugar de construir una consulta SQL dinámicamente utilizando cadenas de texto, utilice consultas parametrizadas que permitan que los parámetros sean pasados como argumentos separados. Esto reducirá la posibilidad de inyección SQL, ya que los valores de los parámetros son tratados como datos, no como parte de la consulta SQL.
Limitar los permisos de la base de datos: Asegúrese de que los usuarios de la base de datos tengan solo los permisos necesarios para realizar sus funciones y nada más. Esto limitará el alcance de cualquier posible ataque.
Utilizar herramientas de seguridad y pruebas de penetración: Realice pruebas regulares de seguridad y pruebas de penetración en la aplicación para identificar posibles vulnerabilidades y errores de seguridad. También puede utilizar herramientas de seguridad de terceros para proteger la aplicación contra la inyección SQL.
Actualización y parcheo del software de la base de datos y uso de firewalls de aplicación web (WAF)

Es una tarea difícil determinar si una cadena de usuario es maliciosa o no. Por lo tanto, la mejor manera de hacerlo es “escapar” de los caracteres especiales en la entrada del usuario. Puede escapar una cadena antes de construir la consulta en PHP usando la función mysql_escape_string(). O en MySQL usando la función mysqli_real_escape_string().

Mientras se muestra la salida como HTML, también tendrá que convertir la cadena para asegurarse de que los caracteres especiales no interfieren con el marcado HTML. Puede convertir caracteres especiales en PHP usando la función htmlspecialchars().

Alternativamente, puede usar sentencias preparadas para evitar las inyecciones de SQL. Una sentencia preparada es una plantilla de una consulta SQL, en la que se especifican los parámetros en una etapa posterior para ejecutarla. Aquí hay un ejemplo de una declaración preparada en PHP y MySQLi.

$query = $mysql_connection->prepare(«select * from user_table where username = ? and password = ?»);

$query->execute(array($username, $password));

En resumen, para solucionar y prevenir la inyección SQL avanzada, es necesario validar y sanitizar todas las entradas de datos, utilizar consultas parametrizadas, limitar los permisos de la base de datos y utilizar herramientas de seguridad y pruebas de penetración.

EVIDENCIA Y REFERENCIAS

Introduce las capturas y demostración de la ejecución de la inyección. Como ejemplo te damos estos enlaces de referencia.

NOTA: Esto en es solo un ejemplo y NO ALCANZA con mostrar la “evidencia” mostrada por un programa. Elegimos este ejemplo justamente para mostrar el caso de que, a pesar de una aplicación encuentre un fallo, será usted quien deberá verificar, a veces manualmente, si efectivamente esa falla existe.

Evaluación del Rendimiento del Blue Team

Una parte fundamental del informe de Red Team es la evaluación del rendimiento del Blue Team (si estuvo involucrado). El Red Team debe documentar cómo y cuándo el Blue Team detectó (o no) los ataques, y cómo respondió.

Puntos Clave:

Tiempo de detección: ¿Cuánto tiempo tardó el Blue Team en detectar los ataques? ¿Se detectaron en tiempo real o tras varios intentos?
Respuesta: ¿Cómo respondió el Blue Team ante el ataque? ¿Pudieron contener el ataque y mitigar sus efectos?
Herramientas utilizadas: ¿Qué herramientas utilizaron para la detección y respuesta (por ejemplo, SIEM, IDS/IPS)?
Recomendaciones: Sugerencias específicas para mejorar la capacidad de detección y respuesta del equipo de seguridad.

Impacto Potencial

En esta sección, se debe evaluar el impacto potencial de las vulnerabilidades descubiertas en función de los activos críticos de la organización. El informe debe priorizar las vulnerabilidades más peligrosas y detallar las consecuencias para la organización en caso de explotación.

Puntos Clave:

Impacto en la confidencialidad: ¿Podría un atacante acceder a información sensible o datos confidenciales?
Impacto en la disponibilidad: ¿Podría el atacante interrumpir servicios críticos o sistemas?
Impacto en la integridad: ¿Podría un atacante modificar datos, afectando la integridad de la información?

Ejemplo de hoja de impacto y clasificación global del riesgo

Habiendo considerado los resultados potenciales y los niveles de riesgo evaluados para cada actividad de prueba documentada, consideramos que la exposición global al riesgo con respecto a los intentos de actores maliciosos de violar y controlar los recursos dentro de su entorno de información es ALTO (según lo determinado utilizando la Clasificación del riesgo Puntuación CVSSv3).

https://www.incibe-cert.es/blog/cvss3-0

Risk Rating	CVSSv3 Score	Descripción
CRITICAL	9.0 – 10	Se ha descubierto una vulnerabilidad crítica. Es necesario resolverla lo antes posible.
HIGH	7.0 – 8.9	Se ha descubierto una vulnerabilidad alta. Esto requiere una resolución a corto plazo.
MEDIUM	4.0 – 6.9	Se ha descubierto una vulnerabilidad media. Debe resolverse a lo largo del proceso de mantenimiento.
LOW	0.1 – 3.9	Se ha descubierto una vulnerabilidad baja. Esto debe abordarse como parte de las tareas de mantenimiento rutinario.
INFO	0	Se ha producido un descubrimiento que se notifica a título informativo. Debe abordarse para cumplir con las prácticas líderes.

Durante las pruebas, Se encontraron 21 tipos diferentes de vulnerabilidades con 28.358 fallas de las cuales 681 son de alto riesgo.

Vulnerabilidades	High	Medium	Low	Info
Tipo	9	12	0	7
Cantidad	681	27677	0	35

Anexos

En los anexos se incluyen detalles técnicos adicionales que respaldan los hallazgos y pruebas descritos en el informe principal. Estos pueden incluir:

Capturas de pantalla de herramientas utilizadas (por ejemplo, logs de SIEM, resultados de escaneos).
Archivos de logs de herramientas como Nmap, Nessus, o Metasploit.
Scripts o exploits personalizados utilizados en el ejercicio.
Material de referencia o cualquier otro contenido que amplíe la información presentada.

Puede incluir una carpeta con Archivos que contengan los escaneos en bruto así como capturas de imágenes que complementaran el informe.

Herramientas utilizadas

A continuación, se enumeran las herramientas utilizadas durante el análisis:

Offline

Acunetix
Amass
Burp
Curl
Dirb
DirSearch
DNSEnum
DNSRecon
Fiddler
Nessus
NetCat
NetSparker
Nikto
Nmap
SmartScaner
SQLmap
SSLScan
SSLyze
Sublist3r
TLSSLed
Wafw00f
Wget
WhatWeb
WPScan
ZAP

Online

Builtwith
Buscadores Bing, Google, DuckDuck
Censys
DNSDumpster
Domaintools
Mxtoolbox
Netcraft
Pentest-tools
Robtex
Securityheaders
Shodan
Sitecheck
SSLLabs
Viewdns
Web Archive
Virustotal
Whoisxmlapi
Wprecon
Wpsec

La Remediación de Fallas de Seguridad tras un Informe de Pentesting

El verdadero valor del pentesting no radica solo en encontrar fallas, sino en cómo se abordan y solucionan esas vulnerabilidades. La etapa de remediación tras la entrega del informe es crucial para reforzar la seguridad y evitar futuros incidentes.

1. Comprensión del Informe de Pentesting

Antes de iniciar la remediación, es vital comprender plenamente el informe de pentesting. Este documento incluye:

Descripción de vulnerabilidades: Detalla cada falla encontrada, cómo se descubrió y su ubicación.
Impacto potencial: Describe las consecuencias de explotar la vulnerabilidad, como robo de datos o acceso no autorizado.
Recomendaciones: Proporciona pasos específicos para mitigar o eliminar el problema.
Priorización de riesgos: Clasifica las vulnerabilidades por su criticidad (alta, media, baja), lo que ayuda a planificar la remediación.

Un análisis claro del informe asegura que todas las partes involucradas tengan una comprensión común de las fallas y de cómo abordarlas.

2. Priorización de Vulnerabilidades

No todas las vulnerabilidades tienen el mismo impacto. Algunas requieren atención inmediata, mientras que otras pueden esperar. Para priorizar:

Matriz de Riesgos:

Evaluar cada vulnerabilidad según dos factores:

Probabilidad de explotación: ¿Qué tan fácil sería para un atacante aprovechar esta falla?
Impacto: ¿Qué tan dañina sería si se explotara?

Clasificación de vulnerabilidades comunes:

Usar estándares como el Common Vulnerability Scoring System (CVSS) para medir la severidad de las fallas.

Ejemplo:

Críticas: Vulnerabilidades que permiten acceso remoto o comprometen datos confidenciales.
Medias: Problemas de configuración que requieren acceso interno.
Bajas: Fallas estéticas o problemas que no impactan directamente en la seguridad.

3. Desarrollo de un Plan de Acción

Con una lista priorizada, el siguiente paso es crear un plan detallado para abordar las vulnerabilidades. Este plan debe incluir:

Asignación de responsabilidades: Determinar qué equipo o persona es responsable de cada remediación.
- Equipo de redes para vulnerabilidades relacionadas con firewalls o routers.
- Equipo de desarrollo para problemas en aplicaciones o código.
Definición de plazos: Establecer fechas límite para solucionar cada vulnerabilidad según su criticidad.
Establecimiento de pasos claros: Detallar las acciones necesarias para mitigar o eliminar la falla.

4. Ejecución de la Remediación

La ejecución puede variar según el tipo de vulnerabilidad. Aquí hay algunos ejemplos de estrategias comunes:

Parches y Actualizaciones

Problema: Software desactualizado con vulnerabilidades conocidas.
Solución: Instalar las últimas actualizaciones o parches del proveedor.

Configuración Segura

Problema: Configuraciones débiles en servidores, aplicaciones o dispositivos de red.
Solución: Aplicar configuraciones seguras, como deshabilitar servicios innecesarios o restringir accesos.

Revisión de Código

Problema: Vulnerabilidades en el código fuente, como inyecciones SQL o XSS.
Solución: Revisar y corregir el código afectado, implementando validación de entrada y protección contra inyecciones.

Fortalecimiento de Políticas

Problema: Contraseñas débiles o falta de control de acceso.
Solución: Implementar políticas estrictas de contraseñas, autenticación multifactor y segmentación de redes.

5. Validación y Verificación

La remediación no está completa hasta que se haya verificado su efectividad. Esto incluye:

Pruebas posteriores: Realizar pruebas para confirmar que las vulnerabilidades han sido eliminadas sin introducir nuevos problemas.
Revisión por terceros: Solicitar a un equipo externo que valide las correcciones, si es posible.
Auditoría interna: Revisar la implementación y los registros para garantizar que las soluciones son efectivas.

6. Documentación de la Remediación

Es fundamental documentar todo el proceso, incluyendo:

Vulnerabilidad original: Descripción del problema y su impacto.
Acciones tomadas: Detalle de las soluciones implementadas.
Resultados: Evidencia de que el problema fue resuelto (capturas de pantalla, reportes, logs, etc.).

La documentación no solo sirve como registro, sino que también puede ser útil para auditorías futuras o certificaciones de seguridad.

7. Mejora Continua

El proceso de remediación no termina con la solución de las fallas. Es importante aprender de las vulnerabilidades identificadas para prevenir problemas futuros:

Lecciones aprendidas: Identificar patrones comunes y problemas subyacentes.
Capacitación: Entrenar a los equipos en prácticas seguras de desarrollo, administración de sistemas y respuesta a incidentes.
Monitoreo continuo: Implementar herramientas de monitoreo para detectar vulnerabilidades emergentes.

8. Comunicación con las Partes Interesadas

Mantener informadas a las partes interesadas, incluidos los clientes y la alta gerencia, es esencial para garantizar la transparencia y la confianza. Proporcionar informes de progreso claros y mostrar el impacto de las remediaciones realizadas.

El Seguimiento tras un Pentesting: Más Allá del Informe y la Remediación de Fallas

El verdadero valor del pentesting no termina con la entrega del informe ni con la remediación de las fallas encontradas. Es el seguimiento adecuado el que asegura que los hallazgos se traduzcan en mejoras tangibles y sostenibles para la seguridad de la organización.

1. La Importancia del Seguimiento

El seguimiento tras un pentesting garantiza que:

Las vulnerabilidades detectadas sean debidamente mitigadas o eliminadas.
Las soluciones implementadas no introduzcan nuevas debilidades.
Los aprendizajes del proceso sean utilizados para fortalecer la infraestructura y las políticas de seguridad.

Sin un seguimiento adecuado, las organizaciones corren el riesgo de dejar vulnerabilidades sin resolver o de abordar los problemas de manera superficial.

2. Gestión del Informe de Pentesting

El informe entregado por los pentesters es el punto de partida del seguimiento. Este documento contiene información crítica como:

Descripción de vulnerabilidades: Detalles de las fallas encontradas y cómo pueden ser explotadas.
Impacto de las fallas: Gravedad de cada vulnerabilidad y sus posibles consecuencias.
Recomendaciones: Sugerencias específicas para abordar los problemas identificados.
Priorización de riesgos: Clasificación de las vulnerabilidades según su criticidad.

Buenas prácticas para gestionar el informe:

Reunión inicial: Organizar una reunión con los responsables del pentesting y los equipos internos para discutir los hallazgos y aclarar cualquier duda técnica.
Asignación de responsabilidades: Identificar quién será responsable de abordar cada vulnerabilidad, ya sea el equipo de desarrollo, redes, infraestructura o un proveedor externo.
Plan de acción: Crear un plan detallado que priorice las vulnerabilidades críticas y establezca plazos claros para su remediación.

3. Remediación de Fallas Identificadas

La remediación de las vulnerabilidades es el siguiente paso clave. Este proceso incluye:

Priorización de Vulnerabilidades

Críticas: Fallas que permiten comprometer sistemas sensibles, exfiltrar datos o ejecutar código remoto.
Medias: Problemas que requieren un contexto específico o acceso limitado para ser explotados.
Bajas: Vulnerabilidades menores que presentan riesgos reducidos.

Ejecución de la Remediación

Instalación de parches: Actualizar software y sistemas para eliminar vulnerabilidades conocidas.
Revisión de configuraciones: Ajustar configuraciones de seguridad en sistemas, redes y aplicaciones.
Corrección de código: Identificar y solucionar problemas en el código fuente que podrían ser explotados.
Refuerzo de políticas: Implementar medidas como autenticación multifactor (MFA), políticas de contraseñas robustas y segmentación de redes.

4. Validación de las Soluciones Implementadas

Una vez completada la remediación, es crucial validar que las vulnerabilidades hayan sido eliminadas correctamente y que no se hayan introducido nuevas fallas en el proceso.

Retesting (Pruebas de Revalidación)

El equipo de pentesting debe realizar un conjunto de pruebas enfocadas exclusivamente en las áreas corregidas para confirmar que las vulnerabilidades han sido resueltas.

Evaluación de Impacto

Revisar si las soluciones aplicadas han afectado el rendimiento, la funcionalidad o la experiencia del usuario en los sistemas afectados.

Auditoría Interna

Involucrar a un equipo interno o a un tercero independiente para verificar la efectividad de las remediaciones.

5. Documentación del Proceso

El seguimiento adecuado incluye la documentación de todas las acciones realizadas. Esto es útil no solo para mantener un registro, sino también para demostrar cumplimiento ante auditorías o normativas de seguridad.

Descripción de la vulnerabilidad original: Cómo se descubrió y su impacto potencial.
Soluciones implementadas: Detalle de las acciones correctivas tomadas.
Evidencia de la solución: Pruebas, logs o capturas de pantalla que confirmen la eliminación de la vulnerabilidad.

6. Aprendizaje y Mejora Continua

Cada pentesting debe ser una oportunidad para aprender y mejorar los procesos internos de seguridad. Algunas recomendaciones para fomentar esta mejora continua incluyen:

Análisis de Lecciones Aprendidas

¿Qué permitió la aparición de las vulnerabilidades?
¿Podrían haberse detectado antes a través de otros métodos, como pruebas automatizadas o revisiones de código?

Actualización de Políticas

Revisar y actualizar políticas de seguridad para reflejar los aprendizajes del pentesting. Por ejemplo:

Incorporar revisiones de seguridad en el ciclo de desarrollo (DevSecOps).
Implementar escaneos de vulnerabilidades periódicos.

Capacitación del Personal

Ofrecer formación específica a los equipos técnicos para prevenir la reaparición de vulnerabilidades similares.

7. Monitoreo Continuo

El seguimiento no termina con la validación de las correcciones. Las organizaciones deben adoptar un enfoque de seguridad proactivo que incluya:

Escaneos regulares de vulnerabilidades: Automatizar la búsqueda de nuevas fallas.
Pentesting recurrentes: Realizar pruebas de penetración al menos una vez al año o tras cambios significativos en la infraestructura.
Monitoreo de amenazas: Usar sistemas de detección de intrusos (IDS) y herramientas de análisis de amenazas para identificar actividades sospechosas.

8. Comunicación con las Partes Interesadas

Mantener informadas a todas las partes interesadas es esencial para garantizar la transparencia y el compromiso con la seguridad. Esto incluye:

Actualizar a los equipos internos y a la gerencia sobre el estado de las remediaciones.
Proporcionar informes resumidos que expliquen cómo se han mitigado los riesgos detectados.
En el caso de proveedores externos, asegurarse de que estén alineados con las mejores prácticas de seguridad.

Palabras finales

La documentación de un ejercicio de Red Team debe ser minuciosa, técnica y, a la vez, accesible para una variedad de públicos dentro de la organización. Al seguir una estructura bien definida, se garantiza que todos los aspectos del ejercicio —desde los hallazgos críticos hasta las recomendaciones de mitigación— estén claramente explicados y respaldados por evidencia técnica. Una buena documentación no solo ayudará a la organización a comprender las vulnerabilidades actuales, sino que también servirá como una hoja de ruta para mejorar su seguridad en el futuro.

Hemos concluido con el estudio de esta guía. Happy Hacking!!!

No te detengas, sigue avanzando

Aquí tienes un propósito que debes considerar seriamente: si has querido mejorar tus habilidades en hacking, Ciberseguridad y programación ahora es definitivamente el momento de dar el siguiente paso. ¡Desarrolla tus habilidades aprovechando nuestros cursos a un precio increíble y avanza en tu carrera! El mundo necesita más hackers…

Hacker de 0 a 100 desde las bases hasta conseguir empleo

¿Quieres iniciarte en hacking y ciberseguridad pero no sabes por dónde empezar? Inicia leyendo nuestra guia gratuita: Cómo Iniciarse en Hacking y Ciberseguridad en 2025 que te lleva de 0 a 100. Desde los fundamentos más básicos, pasando por cursos, recursos y certificaciones hasta cómo obtener tu primer empleo.

Hemos creado una ruta de 0 a 100. Un plan de desarrollo que va desde las bases: cómo aprender hacking, qué aprender, en qué orden; pasando por las areas técnicas necesarias como Linux, Redes, Programación y los conocimientos necesarios en ciber seguridad, hacking, pentesting hasta la práctica y el inicio laboral: Crear tu propio laboratorio, certificaciones, adquirir experiencia e iniciarse laboralmente.

Este es un mega post. Una guía con más de 300 artículos que te llevaran por el camino del hacker. Esta guía es gratuita y esta creada gracias al esfuerzo y al trabajo combinado de Alvaro Chirou y mío (Laprovittera Carlos).

Creamos esta guía (futuro curso) para que puedas iniciarte en este mundo. Puedes arrancar ahora, GRATIS, solo necesitas un PC, conexión a internet y paciencia (Ser hacker NO ES un camino de la noche a la mañana).

El Hacking y la ciberseguridad es una carrera divertida, emocionante y gratificante que te recompensará y desafiará por igual. Sin embargo, para quienes buscan adentrarse en este campo en auge y en constante evolución, puede resultar difícil saber por dónde empezar. ¡Ahí es donde entra en juego nuestra guía en ciberseguridad!

Esta es la hoja de ruta hacia el trabajo de ciberseguridad de tus sueños. Te ayudará a entender qué conocimientos, habilidades y certificados son necesarios para alcanzar tus metas profesionales y tener una carrera próspera. Si quieres ser consultor de ciberseguridad, analista de malware, evaluador de penetración, analista de SOC o cualquier otro puesto de ciberseguridad, esta guía es lo que necesitas.

Lo que vas a aprender en esta guía de Hacking y Ciberseguridad

Esta guía va a tener una actualización constante durante todo el año. Para no hacer de esta guía un post maratónicamente largo voy a dividirlo en varios capítulos que van desde como iniciar en hacking y ciberseguridad, pasando por conocimientos básicos como Redes, Linux, Programación, Hasta como obtener certificaciones y trabajo. Cada capítulo contiene links a otros posts en donde desarrollo mejor cada tema y a webs externas que complementan este material.

Esta es la guía completa de Cómo Iniciarse en Hacking y Ciberseguridad en 2025:

Aprende con nuestros más de 100 cursos que tenemos disponibles para vos

Todos los Cursos

¿Te gustaría enterarte de cuando lanzamos descuentos y nuevos cursos?

Sobre los autores

Álvaro Chirou

Yo soy Álvaro Chirou, tengo más de 20 Años de experiencia trabajando en Tecnología, eh dado disertaciones en eventos internacionales como OWASP, tengo más de 1.800.000 estudiantes en Udemy y 100 formaciones profesionales impartidas en la misma. Puedes seguirme en mis redes:

Laprovittera Carlos

Soy Laprovittera Carlos. Con más de 20 años de experiencia en IT brindo Educación y Consultoría en Seguridad de la Información para profesionales, bancos y empresas. Puedes saber más de mi y de mis servicios en mi sitio web: laprovittera.com y seguirme en mis redes:

Compartimos estos recursos para ayudar a la comunidad de hacking y ciberseguridad. COMPARTE y Siéntete libre de agregar más sugerencias en los comentarios a continuación, respondemos todos y cada uno de los comentarios.