OSINT defensivo: qué expone tu equipo sin saberlo

OSINT defensivo es revisar tu organización con las mismas fuentes públicas que usa un atacante antes de moverse: perfiles del equipo, metadatos de documentos, repositorios de código, ofertas de empleo, registros de dominio y filtraciones antiguas. El objetivo no es vigilar a nadie: es reducir lo que se puede deducir gratis.

La mayoría de la información que se usa contra una organización no fue robada. Estaba publicada.

¿Qué es exactamente el OSINT defensivo?

OSINT (Open Source Intelligence) es la obtención de información a partir de fuentes públicamente accesibles. OSINT defensivo es aplicar esa misma disciplina sobre uno mismo, con mandato escrito, para saber qué se puede construir sobre la organización sin tocar ningún sistema.

La distinción importa porque la palabra se usa para tres cosas distintas:

Actividad	Objeto	Marco
OSINT defensivo	La propia organización	Mandato interno, finalidad de reducción de exposición
OSINT de investigación	Un tercero identificado	Encargo específico, base jurídica propia, garantías
Reconocimiento ofensivo	Una víctima	Fase previa de un ataque

Las tres consultan fuentes parecidas. Solo la primera es la que debería estar haciendo tu organización sobre sí misma, y solo con un encargo que diga por escrito para qué.

En MITRE ATT&CK, esta fase es la táctica Reconnaissance: ocurre antes del primer intento de acceso y no genera ninguna alerta en tus sistemas, porque no toca tus sistemas.

¿Dónde está el límite ético y legal?

Trabajamos dentro de un grupo con firma legal propia, así que este apartado no es un adorno. Un encargo de OSINT defensivo se define por lo que no hace:

Sí	No
Consultar contenido público sin credenciales	Crear perfiles falsos para acceder a contenido restringido
Analizar documentos publicados por la organización	Acceder a cuentas personales de empleados
Revisar registros técnicos públicos (DNS, certificados)	Contactar a familiares o entorno privado del personal
Entregar hallazgos agregados y accionables	Entregar dosieres individuales de conducta
Fijar plazo de conservación y borrado del material	Conservar indefinidamente datos personales recogidos

Hay un principio operativo que resume todo: si el hallazgo no se puede convertir en una recomendación técnica u organizativa, no se recoge. Un dato personal que solo sirve para juzgar a una persona no pertenece a una revisión de exposición.

Cuando la organización trata datos de terceros —afiliados, pacientes, clientes— la revisión debe coordinarse con el registro de tratamientos. Es parte del trabajo de privacidad y cumplimiento, no de un ejercicio técnico aislado.

¿Qué fuentes consulta un atacante antes de moverse?

1. Perfiles profesionales del equipo

Un perfil público bien detallado entrega, sin esfuerzo: organigrama real, nombres y apellidos para deducir el formato de correo corporativo, herramientas que se usan internamente (porque están en la sección de aptitudes), antigüedad de cada persona y quién acaba de incorporarse.

Ese último dato es el más explotado: alguien que lleva dos semanas no sabe todavía qué es normal y qué no, ni tiene confianza para cuestionar una petición urgente de dirección.

2. Ofertas de empleo

Una oferta técnica es documentación gratuita de tu arquitectura. «Se requiere experiencia con» seguido de una lista de productos y versiones le dice al atacante qué tecnología tienes, qué versión estás migrando y qué equipo está incompleto. Las ofertas para reforzar un área concreta indican dónde hay menos gente de la necesaria.

3. Metadatos de documentos publicados

Los PDF, hojas de cálculo y presentaciones que la organización publica arrastran metadatos: nombre de autor, software y versión, rutas locales completas, a veces nombres de servidores internos o de unidades de red compartidas. Una ruta interna es una pista de nomenclatura, y la nomenclatura es la mitad de un ataque dirigido.

4. Repositorios de código y su historial

No basta con revisar el estado actual de un repositorio público. Una clave subida por error y «borrada» en el commit siguiente sigue en el historial. Lo mismo aplica a ficheros de configuración de ejemplo con credenciales reales, a comentarios que describen la arquitectura interna y a issues que documentan un fallo no corregido.

5. Registros técnicos públicos

DNS, WHOIS y, sobre todo, los registros de Certificate Transparency definidos en el RFC 9162, que publican cada certificado emitido para cualquier nombre de tu dominio. Un subdominio que nunca se anunció es público desde el momento en que pidió certificado. Este bloque se cruza directamente con la auditoría de superficie de ataque.

6. Filtraciones antiguas de terceros

Una brecha en un servicio externo donde alguien de tu equipo se registró con el correo corporativo entrega una dirección válida y, con frecuencia, una contraseña. La contraseña rara vez sirve tal cual; el patrón sí. Servicios como Have I Been Pwned permiten comprobar la exposición de un dominio propio. La técnica correspondiente en ATT&CK es T1589, Gather Victim Identity Information.

7. Material gráfico y audiovisual

Fotos de oficina publicadas en redes, vídeos corporativos y capturas en presentaciones muestran pantallas con software y versiones, etiquetas de inventario, tarjetas de acceso, planos de planta y, con más frecuencia de la que nadie admite, notas adhesivas.

8. Histórico y archivo web

Páginas retiradas, versiones antiguas del sitio con listados de personal, documentos que se despublicaron pero quedaron archivados. Retirar algo hoy no lo retira del pasado.

¿Cómo se convierte esto en un ataque real?

La cadena típica es aburrida y funciona:

1. Se identifica en un perfil público a una persona recién incorporada al área financiera.
2. Se deduce el formato de correo corporativo a partir de otros perfiles.
3. Se localiza en una oferta de empleo qué software de facturación usa la organización.
4. Se toma de un PDF publicado el nombre del director financiero y su firma de correo.
5. Se envía a la persona nueva una petición urgente, coherente con la herramienta que sí usa, en el tono que sí reconoce, sobre un proceso que sí existe.

En ningún paso hubo intrusión. No hay nada que detectar en los registros hasta que ya pasó.

¿Qué se puede reducir y qué no?

Ser honestos aquí evita gastar dinero en lo imposible.

Se puede reducir	No se puede eliminar
Metadatos en documentos futuros y republicación de los actuales	Copias ya descargadas por terceros
Contenido de las ofertas de empleo	Perfiles profesionales del equipo, que son suyos
Secretos en repositorios propios (con rotación, no solo borrado)	Historial replicado en forks ajenos
Configuración de privacidad de cuentas corporativas	Filtraciones antiguas ya distribuidas
Exposición de subdominios y entornos de prueba	El registro público de certificados

De ahí una regla que conviene interiorizar: ante una credencial expuesta, el borrado no es la respuesta; la rotación lo es. Si una clave estuvo publicada un minuto, se considera comprometida.

Y ninguna de estas medidas convierte a la organización en invisible. Reducen lo que se obtiene sin esfuerzo y encarecen el trabajo del atacante. Eso es todo lo que puede prometerse, y es bastante.

¿Cómo se hace sin convertirlo en vigilancia interna?

Cuatro condiciones que deberían aparecer en el encargo:

• Finalidad declarada y comunicada al equipo. La revisión se anuncia. No es una auditoría sorpresa sobre personas.
• Resultados agregados. El informe dice «el formato de correo es deducible desde perfiles públicos», no «esta persona publica demasiado».
• Recomendaciones voluntarias en lo personal. Lo que un empleado publica en su perfil es suyo. La organización puede formar y recomendar; no puede exigir el borrado de la vida profesional de nadie.
• Plazo de borrado del material recogido, escrito en el encargo y verificable.

Los sectores donde esto se vuelve crítico son los que manejan datos de terceros por definición: medios de comunicación, firmas legales y federaciones y asociaciones con padrones de afiliados. En los tres, una revisión mal encuadrada crea un problema mayor que el que resuelve.

¿Cada cuánto se repite?

La exposición no es un estado, es un flujo. Cada oferta publicada, cada documento subido, cada incorporación y cada baja la modifican. Una cadencia razonable combina una revisión completa periódica con comprobaciones automáticas continuas de lo que sí puede vigilarse sin intervención humana: certificados nuevos para tus dominios, apariciones de tu dominio en filtraciones y secretos en repositorios. Ese seguimiento es parte del trabajo continuo de protección, y el estado de los marcos que aplicamos está publicado en /trust.

Qué hacer ahora

1. Busca tu organización como lo haría un desconocido. Sin sesión iniciada, sin atajos. Anota lo que encuentras en treinta minutos: eso es el mínimo que tiene cualquiera.
2. Revisa las tres últimas ofertas de empleo publicadas y elimina versiones concretas de producto y nombres de sistemas internos.
3. Limpia metadatos antes de publicar. Fija el paso en el proceso de publicación, no en la voluntad de cada persona.
4. Comprueba tu dominio en fuentes de filtraciones y rota lo que aparezca, sin discutir si la contraseña «ya no se usaba».
5. Escribe el encargo antes de empezar: finalidad, alcance, qué no se toca y cuándo se borra el material.

Si quieres una revisión OSINT defensiva con mandato escrito, resultados agregados y plan de reducción priorizado, cuéntanos tu caso en /contacto.