Preguntas de entrevista de OSCP
The hands-on offensive certification — practical exploitation and a gruelling 24-hour exam.
En un host Linux encuentras un archivo escribible por todos, propiedad de root y con el bit SUID activado. ¿Cuál es el riesgo y tu acción?
Un binario SUID-root se ejecuta con privilegios de root, y si es escribible por todos un atacante puede reemplazarlo o modificarlo para ejecutar código arbitrario como root — una vía clásica de escalada de privilegios local. Retira el bit SUID, corrige el propietario y los permisos, e investiga cómo apareció esta mala configuración, ya que puede indicar un compromiso. Cifrar el archivo deja intacta la ruta ejecutable, y renombrarlo solo traslada el problema sin eliminar la escalada. Ninguna de estas opciones aborda la causa raíz.
Un servicio de producción crítico para el negocio parece vulnerable a un exploit de corrupción de memoria que podría hacerlo caer. ¿Qué haces?
Las reglas de enfrentamiento suelen excluir la denegación de servicio en producción, y una caída no planificada causa un daño real al negocio y puede anular el compromiso. Verifica primero el alcance; si una prueba de concepto destructiva no está autorizada, demuestra la vulnerabilidad por medios más seguros y documenta claramente el impacto probable. Lanzar el exploit por una captura de pantalla es temerario. Ejecutarlo repetidamente por «métricas de fiabilidad» multiplica la caída. Omitirlo en silencio oculta al cliente un riesgo serio y explotable.
Estás cerrando un compromiso en el que subiste webshells y creaste cuentas de prueba. ¿Qué debes hacer?
Los compromisos profesionales terminan con una limpieza completa y un inventario de artefactos, para no dejar nueva superficie de ataque ni enturbiar el entorno del cliente. Dejar shells o cuentas para que el cliente las encuentre es negligente y peligroso: un atacante real podría reutilizarlas. Mantener una puerta trasera «para la próxima» es poco ético y probablemente ilegal. Borrar tus propios registros de actividad destruye la pista de auditoría que el cliente necesita para validar la prueba y reconstruir lo que hiciste.
Descifras la contraseña de una cuenta de servicio a partir de un hash capturado. ¿Cuál es el siguiente paso de mayor valor para demostrar el riesgo?
Lo que importa es el impacto: una credencial de servicio reutilizada o con privilegios excesivos que desbloquea el admin del dominio o sistemas críticos es el hallazgo relevante, así que prueba la reutilización y mapea los privilegios y la ruta de movimiento lateral. Descifrar primero todos los demás hashes es trabajo inútil que retrasa lo importante. Cambiar la contraseña de la cuenta de servicio es destructivo, rompe producción y alerta a los defensores. Enviar una credencial activa en texto plano por correo es en sí una exposición y mala seguridad operativa.
Durante la prueba encuentras indicios de que un atacante REAL ya está dentro del entorno del cliente. ¿Y ahora qué?
Descubrir una intrusión activa es una emergencia fuera de banda: las reglas de enfrentamiento deben definir una ruta de escalada, así que invócala de inmediato, preserva las pruebas y evita contaminar un incidente en curso. Seguir probando puede interferir con el atacante real o destruir las pruebas que necesitan los respondedores. Intentar expulsar tú mismo al atacante queda fuera de alcance, es arriesgado y puede alertarlo. Esperar al informe final podría significar días de brecha continua y pérdida de datos.
Tienes inyección SQL en una aplicación en producción y podrías volcar toda la base de datos de clientes para probar el impacto. ¿Cuál es la prueba responsable?
Demuestra la vulnerabilidad sin perjudicar al cliente ni acumular sus datos: muestra que puedes leer datos arbitrarios mediante la versión de la base, el esquema o una sola muestra anonimizada, y detente ahí. Volcar todo el conjunto de datos personales genera responsabilidad de notificación de brecha y de tratamiento para ambas partes. Eliminar una tabla es destructivo y va mucho más allá de una prueba de concepto. Cifrar la base y exigir una recompensa es extorsión, no una prueba: es un delito, no un hallazgo.
A mitad de la prueba descubres un host explotable que claramente NO está en el alcance acordado. ¿Qué haces?
La autorización define el compromiso: probar fuera del alcance acordado es potencialmente ilegal e infringe las reglas de enfrentamiento, por muy tentador que sea el objetivo. Documenta lo que viste, detente y obtén la aprobación escrita del cliente antes de continuar. Explotarlo por «más hallazgos» nunca justifica un acceso no autorizado. Explotarlo en silencio confiando en que no te pillarán es a la vez poco ético y un delito, y ampliar el alcance por tu cuenta priva al cliente de su consentimiento informado.
Tu prueba XSS con alert() se dispara pero la ventana emergente está vacía: ¿qué te dice eso?
Confirma el XSS. Si alert() se disparó siquiera, el navegador analizó y ejecutó tu JavaScript inyectado en el contexto de la página: esa es la vulnerabilidad. Una ventana vacía solo significa que el argumento de cadena que pasaste no se mostró como esperabas (el manejo de comillas, la codificación o la alteración del contexto rompieron el mensaje), no que el payload esté bloqueado. El punto de ejecución está activo; a partir de ahí refinas el payload.
¿Activar CORS te protege del CSRF?
No. CORS no es una defensa contra el CSRF: en realidad afloja la política del mismo origen para que una página pueda leer respuestas entre orígenes que de otro modo no podría. El CSRF no necesita leer la respuesta; solo necesita que el navegador de la víctima envíe una petición autenticada que cambie el estado. Las defensas reales son los tokens anti-CSRF, el atributo de cookie SameSite y comprobar Origin/Referer.
En un firewall, ¿preferirías que un puerto estuviera filtrado o cerrado?
Filtrado. Un puerto filtrado descarta el paquete en silencio, así que el escáner no obtiene respuesta y debe esperar un tiempo de espera: no aprende nada sobre si el host siquiera existe, y el escaneo se ralentiza drásticamente. Un puerto cerrado devuelve un RST de TCP, que confirma que el host está vivo y respondiendo, entregando gratis al atacante valor de reconocimiento.
¿HTTPS previene por completo los ataques de hombre en el medio?
No por sí solo. HTTPS previene el MITM solo cuando la validación del certificado se exige estrictamente y el cliente llega al sitio por HTTPS desde el principio. Si una CA fraudulenta es de confianza (proxy corporativo, raíz instalada por malware), si el usuario pasa por alto las advertencias de certificado, o si el SSL stripping degrada la conexión a HTTP antes de que arranque TLS, un atacante todavía puede situarse en el medio.
¿Cuándo recurres a Ghidra o IDA frente a un depurador como x64dbg, y cómo se complementan?
Un desensamblador como Ghidra o IDA te da el mapa estático completo: referencias cruzadas, pseudocódigo decompilado y cada ruta de código se ejecute o no. Un depurador como x64dbg te permite ejecutar el ejemplar bajo control — poner breakpoints, inspeccionar registros y memoria, observar el descifrado ocurrir, y seguir la ruta que el código toma realmente con entradas reales. Se lee la estructura y la intención estáticamente, luego se adjunta el depurador para resolver lo que el análisis estático no puede: cadenas descifradas en tiempo de ejecución, APIs resueltas dinámicamente, cargas útiles empaquetadas y qué rama toma una condición. Los dos juntos cierran sus mutuas carencias.
Explica las técnicas comunes de inyección de procesos y las firmas de API y de comportamiento que las revelan.
La inyección de procesos ejecuta código malicioso dentro de otro proceso para ocultarse y heredar su confianza. La inyección remota clásica reserva memoria en un objetivo con VirtualAllocEx, escribe una carga útil vía WriteProcessMemory y la ejecuta con CreateRemoteThread. Las variantes incluyen la inyección de DLL vía LoadLibrary, el process hollowing que desmapea un proceso legítimo suspendido y reemplaza su imagen, la inyección APC que encola código en un hilo, y la carga reflexiva o mapeada manualmente que evita LoadLibrary por completo. Se detectan por las secuencias de API reveladoras, la memoria RWX en un proceso normalmente limpio, los hilos sin archivo de respaldo en disco y las anomalías padre-hijo.
Describe cómo desempaquetas una muestra packed para llegar al código original.
El desempaquetado recupera el código original que el packer ocultó. Para packers conocidos usas el desempaquetador correspondiente o un emulador. Para packers personalizados desempaquetas manualmente: ejecutas la muestra en un depurador, dejas que el stub descomprima el payload en memoria, encuentras el momento en que salta al original entry point (a menudo poniendo un breakpoint en memoria que pasa a ser ejecutable, o en el tail jump), luego vuelcas la imagen del proceso desde memoria y reconstruyes la import address table con una herramienta como Scylla o PE-sieve. El resultado es un PE ejecutable o analizable que contiene el payload real.
¿Cómo estructuras una prueba de aplicación web usando la OWASP WSTG?
La WSTG es una metodología respaldada por una lista de verificación que recorre una aplicación a través de categorías de prueba: recopilación de información, configuración y despliegue, identidad y autenticación, autorización, gestión de sesiones, validación de entradas (inyección/XSS), gestión de errores, criptografía, lógica de negocio y lado cliente. Ofrece cobertura sistemática con identificadores de prueba estables, de modo que los hallazgos son reproducibles y no se omite nada obvio.
Explícame una metodología de pruebas de penetración como PTES.
PTES define siete fases: pre-engagement (alcance, reglas de enfrentamiento, autorización), recopilación de inteligencia (OSINT, reconocimiento), modelado de amenazas, análisis de vulnerabilidades, explotación, post-explotación (pivoteo, datos de valor, persistencia) e informe. La estructura hace que los proyectos sean repetibles, defendibles y ligados al riesgo de negocio en lugar de hacking improvisado. El pre-engagement y el informe son las fases que los junior subestiman.
¿En qué se diferencia un ejercicio de red team de una prueba de penetración?
Un pentest busca cobertura amplia — encontrar tantas vulnerabilidades como sea posible en un objetivo delimitado. Un red team es emulación de adversario dirigida por objetivos: elegir una meta (p. ej. alcanzar los datos más valiosos), emular los TTP de un actor de amenaza concreto, mantenerse sigiloso para probar la detección y la respuesta, y evitar el escaneo ruidoso. El red teaming mide al equipo azul y a toda la organización, no solo al activo; ambos requieren reglas de enfrentamiento estrictas y autorización.
¿Cómo abordas una revisión de código segura?
Empieza por entender el modelo de amenazas de la aplicación y dónde maneja entradas no confiables, secretos, autenticación y autorización. Usa SAST para escanear ampliamente y DAST contra la aplicación en ejecución, pero trata la salida de las herramientas como pistas, no como hallazgos — descarta falsos positivos. Luego dedica el tiempo humano a las áreas de alto valor y dependientes del contexto que las herramientas pasan por alto: lógica de autorización, lógica de negocio, uso de criptografía y fronteras de confianza. Rastrea el flujo de datos desde la fuente hasta el sink.
Explícame cómo enumeras una máquina objetivo recién aparecida.
Se empieza con un escaneo completo de puertos TCP y luego se enumera en profundidad cada servicio abierto —banners, versiones, credenciales por defecto, acceso anónimo y contenido web— antes de tocar ningún exploit. La mayoría de las máquinas caen por una enumeración minuciosa, no por exploits ingeniosos, que es el núcleo de la mentalidad «try harder».
¿Por qué escanear los 65535 puertos y cómo hacerlo de forma eficiente con nmap?
El escaneo nmap por defecto solo cubre los 1000 puertos más comunes, así que un servicio en un puerto alto pasaría totalmente desapercibido. El patrón eficiente es un escaneo SYN rápido de los 65535 puertos primero, y luego un escaneo dirigido de versiones y scripts por defecto solo contra los puertos hallados abiertos.
Tienes un shell de bajos privilegios en una máquina Linux. ¿Cómo escalas?
Enumera de forma sistemática: revisa sudo -l, los binarios SUID/SGID, las tareas cron, la versión del kernel y del SO, los archivos escribibles en rutas privilegiadas, las capabilities y las credenciales almacenadas. Herramientas como LinPEAS automatizan el barrido, pero aun así verificas cada hallazgo contra GTFOBins o una técnica conocida.
¿Cómo encuentras y usas de forma segura un exploit público contra un objetivo?
Identifica el servicio y la versión exactos, busca en Exploit-DB o searchsploit un PoC que coincida, y luego lee el código línea por línea antes de ejecutarlo: corrige la IP objetivo, el puerto y la dirección del reverse shell, regenera cualquier shellcode y entiende qué hace para que no se vuelva en tu contra.
Has volcado algunos hashes de contraseñas. ¿Cómo los crackeas?
Primero identifica el formato del hash (hashid o contexto) y luego ejecuta hashcat o John con el modo correcto contra un diccionario como rockyou, aplicando reglas para mutar los candidatos. Usa el flag de formato correcto (NTLM, sha512crypt, NetNTLMv2, etc.) para que la herramienta hashee los intentos igual que lo hizo el objetivo.
Has comprometido un host con una segunda interfaz de red. ¿Cómo pivotas?
Usa el host comprometido como relé hacia la subred inalcanzable. Configura una redirección de puerto para un único servicio, o un proxy SOCKS dinámico (SSH -D o chisel) y enruta tus herramientas a través de él con proxychains, para que tu máquina atacante alcance los hosts internos por el pivote.
¿Qué compruebas cuando encuentras SMB y SNMP abiertos en un host?
Para SMB, enumera los recursos compartidos, comprueba el acceso anónimo/sesión nula, lista los usuarios e identifica la versión para CVE conocidas. Para SNMP, prueba community strings por defecto como «public» y recorre la MIB para extraer nombres de usuario, procesos en ejecución, software instalado y detalles de red.
Consigues un reverse shell pero es inestable. ¿Cómo lo mejoras?
Se lanza un pseudoterminal (normalmente python -c 'import pty; pty.spawn("/bin/bash")'), se envía a segundo plano con Ctrl-Z, se ejecuta stty raw -echo en el lado local, se trae al primer plano y se reinician TERM y el número de filas/columnas. Así obtienes un TTY completo con control de trabajos, autocompletado con tabulador y editores funcionales.
¿Cómo enumeras un servidor web que nunca has visto antes?
Identifica la stack a partir de las cabeceras y el código fuente, y luego haz fuerza bruta de directorios y archivos con gobuster o feroxbuster usando un buen diccionario y las extensiones relevantes. Busca paneles de administración, copias de seguridad, archivos de configuración y puntos de subida, y comprueba los hosts virtuales cuando el sitio responde a un nombre de host.
¿Cómo abordas la escalada de privilegios en un objetivo Windows?
Enumera los privilegios actuales (whoami /priv), los servicios mal configurados (permisos débiles, rutas de servicio sin comillas), AlwaysInstallElevated, las tareas programadas, las credenciales almacenadas y los parches que faltan. WinPEAS o PowerUp automatizan el barrido; los abusos de privilegios de token como SeImpersonate son victorias frecuentes de alto valor.
Muéstrame cómo combinarías fallos web comunes —digamos inyección SQL y XSS— para lograr un impacto que vaya más allá de un único hallazgo.
Por separado, la SQLi expone o modifica datos y puede llegar al RCE; la XSS almacenada secuestra sesiones en el navegador de las víctimas. Encadenadas, puedes usar la SQLi para plantar una carga XSS almacenada que se dispara en la sesión de un admin, robar su sesión y escalar al control total de la aplicación.
Explícame el Kerberoasting paso a paso: cómo funciona, por qué es posible y cómo lo detienen los defensores.
Cualquier usuario autenticado del dominio puede solicitar un ticket de servicio Kerberos (TGS) para cualquier cuenta con un SPN. Ese ticket se cifra con el hash de contraseña NTLM de la cuenta de servicio, así que lo extraes y crackeas la contraseña sin conexión — sin necesidad de acceso privilegiado para empezar, y es casi silencioso.
Explica la diferencia entre el reconocimiento pasivo y el activo, con ejemplos de cada uno.
El reconocimiento pasivo reúne información sin interactuar directamente con los sistemas del objetivo — OSINT, registros DNS, transparencia de certificados. El reconocimiento activo toca el objetivo, como el escaneo de puertos o la captura de banners, que es más ruidoso pero aporta más detalle.
Explícame las fases de una prueba de penetración, desde el inicio hasta la entrega.
Una pentest avanza por el precompromiso (alcance y reglas de enfrentamiento), el reconocimiento, el escaneo y la enumeración, la explotación, la postexplotación y el informe. Cada fase alimenta la siguiente, y el informe es donde realmente se entrega el valor al cliente.
Has comprometido un host en una red segmentada. Explica cómo pivotas para alcanzar sistemas que no puedes tocar directamente.
El pivoting convierte un host comprometido en un relé para alcanzar segmentos internos a los que tu máquina no puede enrutar. Usas reenvío de puertos, un proxy SOCKS sobre tu canal C2 (p. ej. Chisel, el reenvío dinámico de SSH) o enrutamiento por agente, y luego ejecutas herramientas a través de ese túnel para atacar la siguiente subred.
Tienes una shell con pocos privilegios en una máquina Linux. Explícame cómo escalarías a root.
Enumera primero: privilegios actuales, derechos de sudo, binarios SUID/SGID, tareas cron, archivos escribibles en el PATH, versión del kernel y credenciales almacenadas. Luego explota la ruta más sencilla y fiable — a menudo una regla de sudo mal configurada o un GTFOBin SUID — antes de recurrir a un exploit del kernel.
Has conseguido una shell con pocos privilegios en un host Windows. ¿Cómo escalas privilegios?
Enumera los privilegios de la cuenta y las malas configuraciones del host: privilegios de token como SeImpersonate, rutas de servicio sin comillas, permisos de servicio débiles, AlwaysInstallElevated y credenciales almacenadas. Luego abusa del más fiable — la suplantación de token (ataques Potato) es una vía común a SYSTEM.
Explica las reverse shells frente a las bind shells y cuándo elegirías cada una.
Una bind shell abre un puerto de escucha en el objetivo y espera a que te conectes a él. Una reverse shell hace que el objetivo se conecte hacia fuera a un listener que tú controlas. Las reverse shells suelen ganar porque el tráfico saliente esquiva las reglas de cortafuegos entrantes y el NAT.
El trabajo técnico está hecho. ¿Qué se incluye en un informe sobre el que el cliente realmente actuará?
Un buen informe sirve a dos públicos: un resumen ejecutivo que encuadra el riesgo de negocio para la dirección, y hallazgos detallados y reproducibles con evidencias, calificaciones de riesgo precisas y remediación priorizada para el equipo técnico. El informe — no el exploit — es el entregable.
¿Cuáles son los principales tipos de inyección SQL?
La inyección SQL permite que la entrada de un atacante altere una consulta. Las técnicas en banda devuelven datos directamente: la basada en UNION añade un UNION SELECT para extraer columnas adicionales, y la basada en errores filtra datos a través de los mensajes de error de la base de datos. Cuando no hay salida visible, los atacantes usan SQLi a ciegas — la booleana infiere datos de las diferencias de respuesta verdadero/falso, y la basada en tiempo usa retrasos como SLEEP() para leer datos bit a bit.
Consigue 100 preguntas de entrevista de ciberseguridad + respuestas
Déjanos tu correo y te enviaremos el pack en PDF gratuito y el mazo de flashcards.
Sin spam. Cancela tu suscripción cuando quieras.