# CWES ## Introducción La Certified Web Exploitation Specialist (CWES) de Hack The Box es una certificación centrada en pentesting web black-box con una orientación claramente práctica. Aunque durante un tiempo se la conoció como CBBH, el cambio de nombre refleja bastante mejor lo que realmente evalúa: no está pensada como una certificación de bug bounty, sino como una validación de capacidades en evaluación de seguridad de aplicaciones web con un enfoque muy cercano a un escenario de auditoría real. Frente a certificaciones más generalistas, la principal diferencia del CWES es que aquí todo gira alrededor del ataque a aplicaciones web, la enumeración metódica, el encadenamiento de vulnerabilidades y la documentación profesional de hallazgos. No hay cambios de contexto constantes hacia Active Directory, post-explotación en red interna o privilegios locales como eje principal del examen. Eso no hace la certificación más sencilla, sino más especializada. Esta review pretende ofrecer una visión seria, completa y útil del CWES: qué cubre el path, si la preparación oficial es suficiente, cómo es el examen, qué papel juega el reporte, qué errores suelen cometerse y cómo conviene afrontar la certificación si se busca no solo aprobar, sino sacarle verdadero valor formativo. ## Qué es realmente el CWES El CWES es una certificación orientada a profesionales o estudiantes avanzados que quieren demostrar competencia en: * enumeración web * explotación manual de vulnerabilidades * encadenamiento de fallos * acceso a distintos niveles de privilegio dentro de aplicaciones web * redacción de informes técnicos con formato profesional Su propuesta de valor está en que no se limita a validar conocimiento teórico de vulnerabilidades concretas, sino que exige aplicar una metodología de testing sobre aplicaciones en las que no se indica qué tipo de fallo existe. Ese matiz es importante, porque separa bastante bien el laboratorio guiado del trabajo real de auditoría. En ese sentido, es una certificación que encaja especialmente bien para perfiles que: * quieren especializarse en web pentesting * ya tienen una base técnica y desean profundizar en aplicaciones web * buscan una alternativa más enfocada que certificaciones generalistas * necesitan practicar la parte de reporting profesional, a menudo descuidada en otras certs ## El contenido del path: amplitud y calidad Uno de los puntos fuertes del CWES es que el path formativo cubre de forma amplia y ordenada la mayor parte de las áreas relevantes del pentesting web moderno. Entre los temas que suele abarcar se encuentran: * peticiones web y funcionamiento del protocolo HTTP * uso de proxies como Burp Suite o ZAP * information gathering orientado a web * fuzzing y enumeración * JavaScript deobfuscation * Cross-Site Scripting * SQL Injection * uso avanzado de SQLMap * Command Injection * File Upload Attacks * SSRF, SSTI, SSI * login brute force * broken authentication * XXE, IDOR y otros ataques web comunes * file inclusion * session security * ataques contra APIs y servicios web * WordPress * proceso de bug bounty y reporting La sensación general que transmiten varias reviews coincide en algo: el contenido está bien explicado, es claro y útil, y en líneas generales no deja grandes vacíos en cuanto a técnicas de explotación. Hack The Box suele hacer un buen trabajo en la parte pedagógica cuando estructura rutas técnicas, y en este caso ocurre lo mismo. ### Lo mejor del material * Explica correctamente las bases y el flujo de explotación. * Tiene una progresión razonable entre módulos. * Permite consolidar conceptos con laboratorios y ejercicios. * La cobertura temática es suficientemente amplia para una certificación web seria. * El contenido resulta aplicable y no se queda únicamente en teoría académica. ### El principal problema del path Aquí aparece la crítica más importante, y probablemente la más repetida por quienes han pasado la certificación: el path enseña técnicas, pero no reproduce del todo el contexto del examen. Los *skills assessments* de cada módulo son útiles, pero tienen una limitación estructural: el alumno ya sabe qué tipo de vulnerabilidad está trabajando. Si está en el módulo de Command Injection, espera una command injection. Si está en XXE, espera XXE. Eso reduce enormemente la incertidumbre y orienta la búsqueda. En el examen, en cambio, esa pista desaparece. Y esa diferencia cambia por completo el ejercicio técnico. No es lo mismo comprobar una hipótesis concreta que enfrentarse a una aplicación sin saber si el fallo relevante será autenticación rota, SSRF, subida de archivos, una lógica débil de reseteo de contraseña o una cadena de dos vulnerabilidades. Ahí entra la metodología real de black-box testing, y esa parte no siempre queda suficientemente entrenada solo con el path. ### Veredicto sobre el path La conclusión más razonable sería esta: Sí, el path oficial es suficiente para aprobar.\ Pero no siempre es suficiente para hacerlo con soltura, confianza y criterio de auditoría real si no se complementa con práctica adicional. ## ¿Es suficiente la preparación oficial? La respuesta seria no es un sí o un no absoluto, sino un “sí, pero”. #### Sí es suficiente porque: * las técnicas que aparecen en el examen están cubiertas por el contenido * la certificación no exige magia negra ni conocimiento externo imposible * el material de HTB prepara correctamente la base conceptual y práctica #### Pero conviene complementar porque: * falta práctica de tipo capstone o entorno final verdaderamente black-box * los módulos finales no siempre reproducen la ambigüedad del examen * el examen premia mucho la metodología, no solo el conocimiento de vulnerabilidades * ciertas “trampas” o pequeños giros de explotación se entienden mejor con experiencia externa Dicho de otra forma: con el path puedes llegar preparado; con práctica adicional llegas mucho mejor armado. ## Cómo complementar la formación de forma inteligente Si el objetivo es maximizar la preparación, hay dos complementos especialmente valiosos. ### 1. PortSwigger Web Security Academy Es probablemente el complemento más recomendable. ¿Por qué? Porque permite reforzar precisamente lo que más se necesita en una certificación web seria: * razonamiento sobre comportamiento de aplicaciones * explotación manual * repetición de patrones reales * comprensión de variantes de una misma vulnerabilidad * trabajo fino sobre requests, responses, estados de sesión, flujos y bypasses Además, los labs de PortSwigger son excelentes para consolidar: * autenticación y autorización * XSS en diferentes contextos * SSRF * XXE * CSRF * SQLi * file upload * lógica de negocio * deserialización * web cache poisoning, según el nivel que se quiera profundizar No sustituyen el path del CWES, pero lo complementan de forma muy natural. Podría decirse que HTB enseña bien el mapa y PortSwigger te obliga a caminarlo sin GPS. ### 2. Máquinas o labs externos con foco web realista También es muy recomendable practicar con: * máquinas HTB con entrada web real * laboratorios de estilo boot2root con vector inicial web * entornos donde no se indique de antemano qué vulnerabilidad buscar La razón es sencilla: hace falta entrenar la fase de descubrimiento, no solo la de explotación. Lo importante al seleccionar práctica externa es evitar laboratorios excesivamente artificiales o demasiado centrados en encontrar exploits públicos de software obsoleto. Para este examen aporta más valor un entorno donde haya que: * enumerar con criterio * entender la lógica de la aplicación * probar hipótesis * encadenar fallos * documentar hallazgos ## Naturaleza del examen El examen del CWES está planteado como una experiencia prolongada, más parecida a una pequeña auditoría que a un examen tradicional cronometrado de pocas horas. ### Rasgos más relevantes * no requiere reserva compleja ni suele tener formato proctorizado tradicional * dispone de un periodo amplio de trabajo * exige obtención de flags y entrega de un informe profesional * el tiempo de examen incluye también el tiempo de reporting Ese último punto es importante: el reporte no va después del examen; forma parte del examen. ### La experiencia práctica del examen Las valoraciones más consistentes coinciden en varios puntos. #### 1. El entorno es realista Las aplicaciones no se sienten diseñadas únicamente para ser “resueltas”. Tienen una construcción más cercana a entornos con usuarios, funcionalidades, relaciones internas y lógica de negocio. Eso obliga a mirar la aplicación como un sistema completo y no como una máquina de vending de CVEs. #### 2. La dificultad es alta, pero justa La dificultad del examen puede considerarse media-alta o alta, según el perfil del candidato, pero en esencia es una dificultad exigente y bien calibrada, no arbitraria ni punitiva. No busca sorprender con técnicas exóticas ni evaluar la memorización de payloads, sino medir criterio técnico real. Lo que lo hace complejo no es la rareza del contenido, sino la combinación de varios factores: la necesidad de enumerar correctamente, la ausencia de pistas explícitas, el encadenamiento lógico de hallazgos y la presión constante de documentar mientras se avanza. Es, en ese sentido, un entorno más cercano a un escenario profesional que a un ejercicio académico guiado. Resultará más asequible para quienes ya tengan experiencia previa en laboratorios web, soltura con herramientas como Burp Suite, capacidad de pensar en términos de flujos completos y cierta práctica redactando hallazgos de forma estructurada. En cambio, será sensiblemente más duro para quienes provengan únicamente de módulos guiados, no hayan trabajado en contextos reales de caja negra, improvisen su metodología o no tengan interiorizada una rutina de reporting. En definitiva, la dificultad no reside en trucos ocultos, sino en la exigencia sostenida de autonomía, constancia, criterio, orden y documentación. Es un examen que evalúa cómo trabajas, no solo lo que sabes. #### 3. El examen premia la flexibilidad mental Un patrón muy repetido por quienes lo han cursado es que quedarse bloqueado demasiado tiempo en un objetivo suele ser mala estrategia. Cambiar de aplicación, volver luego con otra perspectiva y dejar madurar ideas suele ser mucho más rentable que intentar forzar un único vector durante horas. ## Los 7 días: ¿son demasiados o adecuados? A primera vista, siete días pueden parecer mucho. En la práctica, es un margen muy razonable. De hecho, bien gestionados, dan de sobra para completar el trabajo. El problema no suele ser la duración en sí, sino cómo se distribuye el esfuerzo dentro de esos siete días. ### Recomendación clara de planificación Lo más recomendable es empezar en fin de semana, idealmente viernes por la tarde o sábado por la mañana. La razón es estratégica: * dispones de dos días completos al principio * puedes coger velocidad sin interrupciones laborales * llegas al tercer día con una visión más clara del escenario * puedes decidir cómo repartir el resto del tiempo según resultados reales y no según expectativas Ese arranque fuerte es importante porque los dos primeros días suelen definir el tono del examen. Si esos días avanzan bien, el resto se gestiona con mucha más serenidad. Si no avanzan como esperabas, todavía te queda margen suficiente para reorganizar estrategia, cambiar prioridades y dedicar más tiempo a enumeración o reporting. En otras palabras: no se trata de trabajar como si te persiguiera un *race condition*, sino de aprovechar bien la ventana inicial para tomar decisiones informadas. ## Gestión del tiempo durante el examen Una estrategia madura para este examen debería incluir tres frentes paralelos: ### 1. Enumeración sistemática No improvisar. Tener un orden claro para revisar: * superficie pública * endpoints ocultos * parámetros * funcionalidades críticas * mecanismos de autenticación * subida de archivos * interacciones con APIs * diferencias entre roles * comportamientos extraños o inconsistentes ### 2. Explotación progresiva No intentar llegar al final desde el minuto uno. Primero hay que construir hipótesis pequeñas y validar superficie. Muchas veces el acceso o el siguiente paso no llega por una vulnerabilidad espectacular, sino por una debilidad aparentemente menor bien entendida. ### 3. Reporting continuo Este punto es decisivo. Dejar el reporte para el final es una mala idea. Cuando pasan horas o días, se pierden: * contexto * orden de pasos * evidencia * capturas * outputs exactos * matices importantes para explicar la explotación La recomendación más sensata es ir documentando conforme se descubren hallazgos, no al terminar. ## El papel del reporte: probablemente el elemento más infravalorado Muchas personas enfocan este tipo de certificaciones como si el objetivo fuera únicamente obtener flags. En el CWES eso es un error. El examen no solo evalúa si has sido capaz de explotar, sino también si sabes comunicar profesionalmente el resultado de una auditoría. ### Qué implica eso No basta con entregar algo que diga: “Encontré una SQLi, luego ejecuté esto y saqué la flag”. Eso sería útil en un writeup informal, pero no en un informe profesional. Un reporte válido debe incluir, entre otras cosas: * descripción clara del hallazgo * impacto técnico y de negocio * evidencia reproducible * pasos de explotación * explicación comprensible * referencias al riesgo * recomendaciones de mitigación Además, debe estar bien presentado, bien redactado y estructurado con lógica. ### SysReptor: por qué es una opción especialmente recomendable Para este examen, SysReptor resulta una herramienta muy cómoda y práctica. Facilita bastante el trabajo porque: * ofrece una estructura profesional * ayuda a mantener consistencia entre findings * permite trabajar con una plantilla clara * mejora la presentación final * reduce fricción en el formato En una certificación donde el reporte pesa mucho, usar una herramienta que elimine problemas de maquetación es una decisión muy sensata. ### Recomendación importante No conviene descubrir SysReptor durante el examen. Lo ideal es: * instalarlo antes * revisar la plantilla * entender su estructura * decidir cómo se van a rellenar las secciones * practicar con algún laboratorio previo Esto ahorra tiempo, errores y frustración. La improvisación está bien para jazz; para reporting de certificación, bastante menos. ### Qué reportar realmente Este es uno de los puntos más importantes y donde conviene ser muy explícito: No se deben reportar únicamente los hallazgos que llevan directamente a flags. Lo correcto es reportar todo hallazgo relevante identificado durante la evaluación, incluso aunque: * no haya sido necesario para obtener una flag * no se haya conseguido explotar hasta impacto máximo * no forme parte de la cadena final de compromiso * haya quedado como una debilidad confirmada pero no completamente desarrollada Esto se parece mucho más a una auditoría real. En una evaluación profesional, el cliente no quiere saber solo qué te permitió llegar a “root” o a “admin”. También quiere conocer: * fallos independientes * debilidades de diseño * riesgos potenciales * exposición adicional detectada * vectores que no se explotaron completamente pero existen Ese enfoque también transmite madurez técnica: demuestra que no estás jugando a capturar banderas, sino analizando seguridad. ### Cómo construir buenos findings Un buen finding no debe limitarse a una secuencia de pantallazos. Debe contar una historia técnica coherente: 1. qué se observó 2. por qué era sospechoso 3. cómo se validó 4. cuál fue el impacto 5. qué evidencia lo respalda 6. cómo se remedia Eso implica que cada hallazgo debería incluir, cuando proceda: * resumen ejecutivo del fallo * descripción técnica * activos afectados * precondiciones * pasos de reproducción * evidencia visual * comandos utilizados * resultados obtenidos * impacto * severidad justificada * recomendaciones ### Evidencias: por qué no basta con capturas de Burp Otro punto clave que merece atención específica: No es recomendable depender solo de capturas de Burp Suite. Burp es central en pentesting web, sí, pero un informe sólido gana mucho cuando la evidencia combina varias formas de validación. #### Qué conviene incluir * capturas de Burp con request y response relevantes * pruebas manuales usando `curl` * outputs completos de comandos * explicación de lo que devuelve cada comando * cuando proceda, evidencia del efecto logrado en la aplicación o en el sistema #### Por qué esto mejora el informe Porque aporta: * reproducibilidad * claridad técnica * independencia de herramienta * mejor comprensión de la explotación * más solidez probatoria Por ejemplo, una captura de Burp puede demostrar que una petición fue manipulada. Pero una ejecución manual con `curl`bien documentada demuestra además que entiendes exactamente qué cabeceras, parámetros y condiciones fueron necesarias para reproducir el fallo. Eso eleva mucho la calidad del informe. #### Recomendación práctica Cada vez que sea razonable, no limitarse a insertar una captura. Conviene añadir algo como: * petición relevante * comando `curl` equivalente * explicación de parámetros * salida obtenida * interpretación de la salida Esto hace que el hallazgo sea mucho más útil para revisión interna, validación posterior y remediación. #### Explicar la salida de los comandos Este punto suele pasarse por alto, pero marca diferencia entre un informe correcto y un informe verdaderamente bueno. No basta con lanzar un comando y pegar su salida. Hay que explicar qué demuestra esa salida. Por ejemplo: * si un `curl` devuelve un `200 OK`, hay que aclarar por qué eso implica éxito en el bypass o acceso indebido * si una respuesta muestra datos sensibles, hay que señalar exactamente qué dato es relevante * si una ejecución confirma RCE, hay que explicar qué evidencia lo confirma * si una subida de archivo ha funcionado, debe mostrarse no solo la carga sino la ejecución o acceso posterior El reporte no debe obligar al revisor a deducirlo todo. Debe conducirlo. ## Metodología: lo que realmente separa al candidato fuerte del candidato correcto Una de las conclusiones más claras que deja el CWES es que la certificación no distingue solo entre “sabe vulnerabilidades” y “no sabe vulnerabilidades”, sino entre: * quien conoce técnicas * y quien sabe trabajar una aplicación web de forma metódica Las capacidades que realmente marcan la diferencia son: * mantener orden durante la enumeración * formular hipótesis realistas * no perder tiempo en callejones sin salida infinitos * correlacionar comportamientos entre funcionalidades * entender el flujo de negocio * identificar relaciones entre usuarios, roles, objetos y acciones * documentar desde el principio Ese último punto vuelve a aparecer porque es esencial. En un examen largo, la mala documentación no solo perjudica el informe: también perjudica la explotación, porque hace que olvides pruebas realizadas, condiciones probadas y resultados negativos útiles. ### Comparación con otras certificaciones Sin entrar en comparaciones absolutas, el CWES se posiciona bien frente a otras certificaciones de seguridad ofensiva por su especialización. #### Frente a certificaciones generalistas Tiene la ventaja de que profundiza mucho más en web. Si alguien quiere especializarse en aplicaciones web, el CWES ofrece una experiencia más alineada con ese objetivo que rutas donde web es solo una parte pequeña del temario. #### Frente a certificaciones web más orientadas a laboratorio guiado El CWES destaca por el componente de auditoría continua y por exigir un reporte serio, además de plantear un escenario con más espacio para metodología real. #### Frente a exámenes muy comprimidos en pocas horas Aquí el valor está en que el examen se parece más a un trabajo profesional: tienes que organizarte, investigar, explotar y reportar durante varios días. Eso le da un carácter muy distinto. ### Principales fortalezas del CWES #### 1. Especialización clara en web Es una certificación pensada para validar habilidades concretas en pentesting web, no para cubrir demasiados dominios superficialmente. #### 2. Buen contenido formativo La calidad del path es alta y la explicación de técnicas suele ser clara, directa y útil. #### 3. Examen realista La experiencia se parece más a una evaluación real que a un simple CTF encubierto. #### 4. Reporting serio Obliga a desarrollar una habilidad crítica en el mundo profesional: escribir informes útiles y con calidad comercial. #### 5. Buena relación entre teoría y práctica No se queda en conceptos abstractos. El alumno termina el recorrido con una base bastante aplicable. ### Principales debilidades o aspectos mejorables #### 1. Falta de un capstone verdaderamente black-box al final del path Es probablemente la carencia más clara. Haría mucho mejor puente entre formación y examen. #### 2. Los skills assessments condicionan demasiado la búsqueda Son útiles, pero entrenan menos la fase de descubrimiento libre. #### 3. La práctica extra es casi imprescindible para ir con seguridad No invalida la formación, pero sí indica que la preparación oficial podría incluir un entorno final más abierto. #### 4. Riesgo de subestimar el reporte No es una debilidad del examen en sí, pero sí una trampa frecuente del candidato: pensar que sacar flags basta. ### Recomendaciones prácticas para afrontar el CWES #### Antes del examen * completar el path con atención real, no en modo checklist * rehacer o revisar skills assessments importantes * reforzar práctica con laboratorios dePortSwigger * practicar enumeración web sin pistas previas * preparar entorno de trabajo y notas * instalar y probar SysReptor con antelación * definir una plantilla personal de toma de notas #### Durante el examen * empezar en fin de semana * aprovechar los dos primeros días para ganar tracción * alternar objetivos si uno se bloquea * documentar inmediatamente cada hallazgo * guardar comandos, outputs y peticiones importantes * no depender solo de Burp como evidencia * reproducir y validar manualmente con `curl` cuando aporte valor * reportar también hallazgos relevantes que no den flag #### Al redactar * explicar cada finding como una vulnerabilidad real, no como una walkthrough de CTF * dejar claro impacto, reproducción y mitigación * añadir capturas con contexto * incluir comandos manuales y explicar sus salidas * revisar gramática, claridad y consistencia * releer con cabeza fresca antes de entregar ## Valoración final El CWES es una certificación muy recomendable para quien quiera formarse de verdad en seguridad ofensiva web y validar no solo explotación, sino también metodología y reporting. Su mayor acierto es que obliga a pensar como auditor y no solo como jugador de laboratorio. Su principal limitación es que el path, aunque muy bueno, podría preparar mejor la transición hacia un escenario final verdaderamente black-box. Aun así, esto se corrige bastante bien complementando la formación con laboratorios de Burp y práctica adicional en entornos web realistas. ### En resumen * Sí, el path es suficiente para aprobar. * No, no es lo ideal si quieres llegar realmente cómodo sin práctica adicional. * Los labs de Burp son un complemento excelente. * Los 7 días están bien y, bien gestionados, sobran. * Conviene empezar en fin de semana para aprovechar dos días completos y ajustar el resto según el progreso inicial. * SysReptor es una opción muy cómoda y práctica para el reporte. * Hay que reportar no solo lo que lleva a flags, sino todo hallazgo relevante. * Las evidencias deben ir más allá de Burp: incluir `curl`, pruebas manuales y explicación de salidas mejora claramente la calidad del informe. ## Conclusión El CWES no destaca porque enseñe vulnerabilidades “más raras” que otras certificaciones, sino porque te obliga a hacer algo más difícil: trabajar bien. Trabajar bien significa enumerar con orden, pensar con criterio, cambiar de enfoque cuando toca, documentar mientras avanzas y escribir un informe que sirva realmente a un cliente o a un equipo técnico. Esa combinación es la que da valor al examen. Por eso, más que una certificación para “sumar una línea en el CV”, el CWES es una certificación que puede aportar una mejora real a quien quiera dedicarse seriamente al pentesting web. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://beafn28.gitbook.io/beafn28/reviews-certificaciones/cwes.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.