Llegamos a la última lección del Módulo 2. Hasta aquí hemos aprendido a recopilar información de forma pasiva (02-01), a confirmarla y ampliarla de forma activa (02-02) y a hacerlo con las herramientas adecuadas orquestadas en un flujo (02-03). El resultado es un inventario largo pero desordenado: subdominios, IPs, hosts vivos, versiones, correos, usuarios, tecnologías. Un montón de datos, sí, pero todavía no una superficie de ataque.

Esta lección hace dos cosas. Primero, incorpora la disciplina del OSINT (Open Source Intelligence) en su vertiente más rica y delicada: la que gira en torno a las personas (correos, credenciales filtradas, huella digital) y a la exposición moderna (nube, buckets, repositorios de código). Segundo, y sobre todo, consolida todo lo recogido en el módulo en un mapa de superficie de ataque priorizado: el entregable que dice al pentester —y al Módulo 3— por dónde empezar. Como el OSINT toca datos personales, dedicaremos un apartado central a su marco ético y legal (RGPD), coherente con las RoE de TechNova.

1. Qué es OSINT y cómo encaja en el reconocimiento
2. OSINT de personas: correos, empleados y huella digital
3. Credenciales filtradas en brechas
4. Exposición en la nube: buckets y servicios
5. Repositorios de código y secretos
6. Marco ético y RGPD del OSINT sobre personas
7. Consolidar: el mapa de superficie de ataque
8. Priorizar la superficie de ataque de TechNova
9. Errores comunes y consejos
10. Ejercicios
11. Conclusión

OSINT es la disciplina de obtener y analizar información de fuentes abiertas (públicas) para producir inteligencia: no datos sueltos, sino conocimiento accionable. En pentesting, OSINT es la capa que da contexto humano y organizativo a la infraestructura que ya mapeamos.

Conviene situar bien los términos:

• Todo lo que hicimos en 02-01 es, en sentido amplio, OSINT (fuentes abiertas).
• Pero cuando hablamos de "OSINT" como disciplina propia, solemos referirnos a lo más orientado a personas y exposición indirecta: quién trabaja en la empresa, qué correos tienen, si sus credenciales aparecen en brechas, qué han subido sin querer a la nube o a GitHub.

Es información que rara vez está en el DNS o en un certificado, pero que abre vectores muy reales (phishing dirigido, reutilización de contraseñas, acceso a datos expuestos). Casi todo el OSINT es pasivo; su riesgo no es técnico, sino ético y legal, porque trabajamos con datos de individuos.

Las organizaciones dejan una huella de personas: perfiles profesionales, autores de artículos, ponentes en eventos, firmantes de documentos. A partir del patrón de correo que dedujimos en lecciones anteriores ([email protected], visto en jlopez, mgarcia, sistemas@), podemos construir y validar listas de correos corporativos.

A partir de aquí se elabora un mapa de personas con rol y correo. ¿Para qué sirve, dentro del alcance?

• Vector de phishing/ingeniería social (solo si el scope lo autoriza): el correo de rrhh@ o de un administrador es un objetivo típico.
• Semilla para ataques a credenciales (Módulo 4): usuarios probables para pruebas autorizadas.
• Comprensión organizativa: quién administra qué ayuda a interpretar la infraestructura.

Contrapartida defensiva: formación en concienciación anti-phishing, no publicar organigramas técnicos detallados y usar alias de rol (soporte@) en lugar de nombres personales donde sea posible.

Con el tiempo, multitud de servicios sufren brechas de datos y las credenciales acaban en volcados públicos. Si un empleado usó su correo corporativo en un servicio de terceros que fue comprometido, ese correo —y a veces una contraseña o su hash— aparece en esos volcados. Consultar estas fuentes es pasivo (interrogamos una base de datos de terceros como Have I Been Pwned), pero es de lo más sensible del módulo.

Lectura: el correo [email protected] aparece en dos brechas que incluyen contraseñas. Esto importa por la reutilización de contraseñas: si jlopez usó la misma contraseña en ForoTech2019 que en la VPN de TechNova, un atacante entra sin explotar ninguna vulnerabilidad técnica.

Encuadre imprescindible:

• Solo verificamos exposición, no usamos las contraseñas filtradas fuera del alcance ni contra terceros.
• El uso de credenciales concretas para intentar acceso (credential stuffing) pertenece al Módulo 4 y solo si el contrato lo autoriza explícitamente.
• Manejar volcados de contraseñas reales tiene implicaciones legales serias; en una auditoría real se trata con extremo cuidado y asesoría legal.

Contrapartida defensiva: MFA en todos los accesos, políticas que prohíban reutilizar contraseñas corporativas en servicios externos y monitorización de credenciales expuestas.

La infraestructura moderna vive en la nube, y una fuente enorme de fugas son los buckets de almacenamiento mal configurados (S3 de AWS, Blobs de Azure, GCS) dejados como públicos. Suelen seguir convenciones de nombre predecibles a partir del nombre de la empresa: technova-backups, technova-dev, technova-assets.

Un código 200 (en lugar de 403 Forbidden) sugiere que el bucket es accesible. Si además permite listar su contenido, podríamos ver ficheros expuestos:

Un db_dump_2023.sql o un fichero .env (que suele contener credenciales de base de datos y claves de API) es un hallazgo crítico. Importante de alcance: el bucket debe pertenecer a TechNova y estar dentro del contrato. Encontrar un bucket con su nombre no autoriza a descargar su contenido si el alcance no lo incluye; documenta la exposición y consulta antes de ir más allá.

Contrapartida defensiva: bloquear el acceso público por defecto, revisar políticas de bucket periódicamente y no almacenar secretos ni volcados en almacenamiento accesible.

Los desarrolladores a veces publican código en repositorios (GitHub, GitLab) que filtra información: claves de API, contraseñas, tokens, rutas internas, direcciones IP. Recordemos que en 02-02 apareció un git.technova.lab. Buscar por el nombre de la organización o el dominio en repositorios públicos es OSINT pasivo muy productivo.

Ejemplo de hallazgo (fragmento ficticio encontrado en un commit antiguo):

Lectura: un desarrollador subió credenciales reales que, aunque luego "borrara", siguen en el historial de commits. Vemos el host interno db-interno.technova.lab (coincide con el 10.10.10.40 de la transferencia de zona de 02-02), un usuario de BD y una contraseña. Herramientas como buscadores de secretos automatizan la detección de estos patrones en repos. Todo esto se documenta como exposición; su uso para acceder es materia del Módulo 4 y solo dentro del alcance.

Contrapartida defensiva: escaneo de secretos en CI/CD (pre-commit hooks), rotación inmediata de cualquier secreto que llegue a un repo y política de nunca versionar ficheros de configuración con credenciales.

El OSINT sobre personas es legal y potente, pero pisa terreno de datos personales, regulados en la UE por el RGPD. Que algo sea accesible públicamente no significa que su uso sea libre. Principios que deben guiar tu trabajo:

• Base y finalidad legítimas. La única razón para recoger estos datos es la auditoría autorizada de TechNova. No los uses para nada más.
• Minimización. Recoge solo lo necesario para el objetivo. No acumules datos personales "por si acaso".
• Alcance estricto. OSINT sobre empleados solo de la organización objetivo y solo si el contrato lo contempla. Nada de familiares, terceros o proveedores fuera del scope.
• No dañar. Encontrar la vida privada de un empleado no autoriza a exponerla, contactarla ni usarla fuera de lo pactado. Nada de acoso ni ingeniería social no autorizada.
• Seguridad y borrado. Guarda estos datos cifrados, con acceso restringido, y bórralos según lo acordado al cerrar el proyecto.
• Transparencia en el informe. Documenta qué recogiste y por qué; el cliente debe poder entender y justificar el tratamiento.

En resumen: el límite del OSINT no es técnico (casi todo es alcanzable), es ético-legal. Un profesional se distingue precisamente por respetar ese límite. Ante la duda, consulta el contrato y, si hace falta, asesoría legal.

La superficie de ataque es el conjunto de todos los puntos por los que un atacante podría intentar entrar: cada host, servicio, subdominio, cuenta, credencial o dato expuesto. Consolidar el módulo consiste en reunir todo lo recogido (02-01 a 02-04) en un único mapa.

El mapa distingue tres capas: externa (lo accesible desde Internet), interna (la red 10.10.10.0/24) y humana/datos (personas, credenciales, exposición en nube y código). Los nodos en rojo marcan lo más crítico.

Un mapa no basta: hay que priorizar para que el Módulo 3 sepa por dónde empezar. Un criterio sencillo combina valor (qué se gana si cae) y exposición/facilidad (cómo de accesible y débil parece). La siguiente tabla ordena la superficie de TechNova:

Cómo se lee esta priorización:

• Lo crítico combina alto valor y evidencia fuerte de debilidad: un db-interno con credenciales ya filtradas y un bucket público con un volcado de BD.
• La tienda es prioridad alta por ser el objetivo principal del alcance, estar en Internet y correr software sin soporte (PHP 7.2).
• Los entornos de staging/dev suben de prioridad porque suelen estar peor protegidos que producción.

Esta tabla priorizada es el entregable que conecta el reconocimiento con el escaneo. No hemos explotado nada: hemos dibujado dónde mirar primero.

• Confundir "público" con "de uso libre". Que un dato personal sea accesible no autoriza cualquier uso; el RGPD y el contrato mandan.
• Salirse del alcance con OSINT. Investigar a familiares de un empleado, a un proveedor o usar credenciales filtradas contra servicios de terceros es cruzar la línea. Cíñete a la organización y al scope.
• Acumular datos personales innecesarios. Recoge lo mínimo; guarda cifrado; borra al cerrar. La minimización te protege a ti y al cliente.
• Entregar un inventario sin priorizar. Una lista de 200 hosts no ayuda; un mapa con 5 prioridades sí. El valor está en el análisis, no en el volumen.
• Usar hallazgos de OSINT para explotar en esta fase. Recon documenta; la explotación (usar esas credenciales o ese secreto) es de módulos posteriores y solo dentro del contrato.
• Consejo: al priorizar, cruza siempre valor y exposición. Un fallo grave en un sistema inaccesible pesa menos que uno medio en un sistema expuesto a Internet.

Ejercicio 1. Encuentras que [email protected] aparece en una brecha de datos con contraseña. Enumera qué puedes hacer con ese dato en la fase de reconocimiento y qué no puedes hacer (y en qué módulo y bajo qué condición podría hacerse lo segundo).

Ejercicio 2. Ordena por prioridad estos tres hallazgos para el Módulo 3 y justifica con los criterios de valor y exposición: (a) un intranet interno solo accesible desde dentro; (b) la tienda en Internet con PHP 7.2 sin soporte; (c) un bucket technova-backups público con un db_dump.sql.

Ejercicio 3. Un compañero propone investigar los perfiles personales en redes sociales de la pareja del administrador de sistemas "para tener más contexto". Explica por qué esto es inaceptable, citando al menos dos principios del marco ético/RGPD.

Solución 1. Puedo: documentar que el correo aparece en una brecha, anotar el vector (posible reutilización de contraseña) y reflejarlo en el mapa de superficie como riesgo, informando a TechNova. No puedo: usar esa contraseña para intentar acceder a la VPN, la intranet o cualquier sistema. Ese intento (credential stuffing) pertenece al Módulo 4 y solo si el contrato lo autoriza explícitamente. En reconocimiento solo se verifica y documenta la exposición, nunca se emplea la credencial.

Solución 2. Orden: 1.º (c) el bucket público con db_dump.sql (valor muy alto —un volcado de BD— y exposición máxima —accesible desde Internet sin autenticación—: crítico e inmediato). 2.º (b) la tienda con PHP 7.2 (valor alto —objetivo principal del alcance— y exposición alta —Internet + software sin soporte, propenso a vulnerabilidades conocidas—). 3.º (a) la intranet interna (aunque su valor sea relevante, su exposición es baja: solo alcanzable desde dentro, así que requiere primero pisar la red). El criterio: a igualdad de valor, prioriza lo más expuesto y fácil de alcanzar.

Solución 3. Es inaceptable porque: (1) viola el alcance/scope: la pareja del administrador es un tercero ajeno a la organización objetivo y no está en el contrato; (2) incumple la minimización del RGPD: no es un dato necesario para la finalidad de auditar la seguridad de TechNova; y (3) vulnera el principio de no dañar/no acosar: investigar la vida privada de personas no relacionadas es intrusivo y potencialmente ilícito. El OSINT de personas se limita a empleados de la organización objetivo, solo si el contrato lo contempla y solo con datos pertinentes al objetivo técnico.

Con esta lección cerramos el Módulo 2. Hemos completado el reconocimiento incorporando la dimensión OSINT —personas y correos, credenciales filtradas en brechas, exposición en la nube y secretos en repositorios— siempre bajo un marco ético y de RGPD estricto, y hemos hecho lo más importante: consolidar y priorizar todo lo recogido en un mapa de superficie de ataque. Ya no tenemos un inventario disperso, sino una lista razonada de objetivos con su prioridad, distinguiendo superficie externa, interna y humana.

Recapitulando el módulo: partimos de cero sobre TechNova y ahora conocemos su dominio y contactos (02-01), qué hosts están vivos y qué versiones corren (02-02), con qué herramientas orquestar el recon (02-03) y cómo se ve —y por dónde empezar— su superficie de ataque priorizada (02-04). El reconocimiento ha cumplido su función: nos dice dónde mirar.

Ahora toca mirar de verdad. En el Módulo 3: Escaneo y Enumeración, cogeremos esa lista priorizada —empezando por la tienda, los entornos expuestos y los hosts vivos de 10.10.10.0/24— y pasaremos del "qué existe y dónde" al "qué puertos, servicios y versiones exactas hay, y qué vulnerabilidades presentan". La primera lección, 03-01 Escaneo de Puertos, retoma justo donde dejamos el nmap -sn: ahora sí, abriremos los puertos en profundidad.