Panorama#

Cuatro identificadores anclan a una persona en línea: su correo electrónico, su username, su nombre real y su teléfono. Ninguno se investiga aislado: cada uno pivota a los otros —de un correo se sacan usernames y nombres, de un username las redes donde reaparece, de un nombre reales direcciones y parientes, de un teléfono el titular—, y el oficio de la identidad OSINT no consiste en «buscar a una persona» sino en convertir cada identificador en el siguiente. Este capítulo desarrolla la rama de identidad de persona del árbol de pivoteo que la metodología (2.1) presentó: es el recorrido concreto de ese grafo, con la disciplina de captura y el OPSEC de aquel capítulo dados por sentados.

De los cuatro anclas, el correo es el preferido, y por una razón estructural: es único. Buscar «John Smith» devuelve miles de personas; john.smith.77089@yahoo.com identifica exactamente a una. Por eso el flujo de identidad casi siempre arranca en el correo, y por eso la técnica que Bazzell llama la más valiosa de su carrera —el cruce con datos de brechas— opera sobre él. El principio que ordena todo el capítulo es que un identificador confirmado vale por dos cosas a la vez: prueba que la cuenta es real y dice hacia dónde pivotar —en qué servicios está registrada la persona, qué otros perfiles tiene, dónde vive—.

flowchart TD
  EM["Correo\n(único = ancla)"]
  UN["Username\n(reuso cross-platform)"]
  RN["Nombre real"]
  TEL["Teléfono"]
  DOS["Dossier\n(dirección · parientes ·\nperfiles · dominios)"]
  BR["Datos de brecha\n(¿real? ¿qué servicios?)"]
  EM -->|"parte local + permutar"| UN
  EM -->|"people-search / breach"| RN
  UN -->|"perfil → nombre / correo"| RN
  UN -->|"nuevos correos a permutar"| EM
  RN -->|"people-search"| TEL
  RN -->|"people-search"| DOS
  TEL -->|"caller-ID → titular"| RN
  EM -.->|"HIBP + Dehashed + stealer logs"| BR
  BR -.->|"multiplica cada salto"| DOS
  classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0;
  class EM,UN,RN,TEL,DOS,BR n;

El correo como ancla: buscar, verificar, permutar#

El primer movimiento con un correo es literal: buscarlo entre comillas en varios motores —Google, Bing, Yandex— tanto en el contenido indexado como en el código fuente de las páginas, y buscar por separado la parte local (el username del correo), porque quien usa mpulido007@gmail.com probablemente reusa mpulido007 como nombre de pantalla en otros sitios. Esa parte local es ya un puente hacia la enumeración de usernames de más abajo.

El segundo movimiento es verificar. La consulta única más rentable es Emailrep.io: en una sola respuesta entrega la reputación del correo, si el dominio es spoofable (el estado de sus registros SPF y DMARC), su antigüedad (first_seen / last_seen), si aparece en brechas (data_breach, credentials_leaked) y qué perfiles tiene asociados —YouTube, GitHub, Twitter—, un detalle que, en palabras de Bazzell, «no encontramos en ningún otro lado». Lo complementan verificadores más simples como Email Hippo (responde OK/BAD sobre si la casilla existe), el módulo de Cybernews y el Friends Check de Avast —en su variante que no notifica al dueño de la casilla—.

El tercer movimiento es asumir y permutar. Conocido un username, se prueba el mismo en otros proveedores —jay112003 en @gmail, @hotmail, @live— y se verifican todos con las herramientas anteriores. Para correos corporativos la permutación se vuelve sistemática: se adivina el patrón de la empresa (jstewart@, jay.stewart@, j.stewart@) o se lo deduce con Email-Format (infiere la estructura de una organización a partir de direcciones ya confirmadas) y Hunter (verifica direcciones y muestra dónde aparecieron, incluso en páginas ya borradas de la web). El resultado tiene peso operativo: convierte una lista de nombres de LinkedIn o Facebook en una lista de correos verificables —el insumo exacto de una campaña de phishing dirigido, motivo por el que este paso reaparece en el recon ofensivo (2.5)—. Un puente lateral menor pero útil: Gravatar liga un correo a su avatar (gravatar.com/site/check/<correo>), que alimenta una búsqueda inversa de imagen.

Datos de brecha: la técnica más valiosa#

«Los datos de cuentas comprometidas son, en definitiva, la técnica más beneficiosa que he usado en mis investigaciones en los últimos cinco años.» — M. Bazzell

El cruce con datos de brechas —breach data: los volcados de credenciales de servicios que sufrieron una intrusión— sirve para dos cosas simultáneas. Confirma que un correo es válido, activo y de cierta antigüedad (un correo que aparece en una brecha de 2013 existe desde entonces), y dice qué servicios investigar: si todd007@gmail.com figura en las brechas de Dropbox y LinkedIn, hay que ir a buscar esos perfiles. La verificación y el pivoteo, otra vez, en la misma consulta.

Las dos fuentes base son complementarias y se usan siempre juntas. Have I Been Pwned (HIBP) lista en qué brechas conocidas aparece un correo, con la descripción de cada una y sus DataClasses —qué campos se filtraron: contraseñas, direcciones, teléfonos—; su URL estática unifiedsearch/<correo> devuelve un JSON citable en un reporte. Dehashed es más agresivo e incluye brechas menores que HIBP no cataloga. Bazzell es explícito: «uno no debería consultarse nunca sin el otro».

A partir de ahí hay una escalera de contraseñas, y aquí empieza la zona de cautela. LeakPeek y BreachDirectory muestran contraseñas parciales o el hash SHA-1 de la contraseña; ese hash suele revertirse en un servicio como md5decrypt sin necesidad de descargar la brecha completa, entregando la contraseña en claro. Spycloud devuelve conteos sin identidad. Hudson Rock marca la presencia del correo en stealer logs —los registros que dejan los infostealers—, lo que significa algo más grave que una brecha de servicio: la máquina del propio dueño fue comprometida por malware. IntelligenceX y LeakIX completan el arsenal (este último expone, por ejemplo, usuarios de WordPress vía una vieja CVE de la API REST). El detalle de las brechas, los stealer logs y los grandes corpus de credenciales es el tema del capítulo de filtraciones y brechas (2.6).

Ver contraseñas puede exceder el OSINT. Acceder a credenciales filtradas —aunque sean públicas— puede rebasar el alcance de una investigación de fuentes abiertas y, según la jurisdicción y las políticas del empleador, constituir un problema legal. La regla de proporcionalidad de 2.1 aplica aquí con fuerza: confirmar que un correo aparece en una brecha es una cosa; recuperar y usar la contraseña asociada, otra muy distinta. Documentar la presencia en la brecha suele ser suficiente para el objetivo del análisis.

Pastebin, WHOIS, Proton y la imitación#

Alrededor del correo hay un conjunto de técnicas de pivoteo que no dependen de brechas. PSBDMP (psbdmp.ws) monitorea Pastebin y, lo valioso, recupera el texto de pastes ya borrados de Pastebin a través de su API (/api/search/<correo> devuelve el id, y pastebin.com/<id> el contenido); Bazzell recuperó así un doxing de un cliente que Pastebin ya había removido. OCCRP (data.occrp.org), el archivo del periodismo de investigación, devuelve documentos asociados a un correo y extrae otros correos de esos documentos —un salto de identificador gratis—.

Como muchos actores usan Proton Mail por su cifrado, saber la fecha de creación de una casilla Proton importa: un burner reciente creado para un solo fin es sospechoso. La fecha se lee del timestamp de la clave PGP pública de la cuenta, que Proton publica (api.protonmail.ch/pks/lookup?op=index&search=<correo> devuelve el Unix timestamp). La búsqueda WHOIS inversa por correo (Whoxy, Whoisology, AnalyzeID) lista los dominios registrados con esa dirección, incluidos históricos —un puente directo a la infraestructura (2.4), donde un correo de contacto delata una red de dominios relacionados—. ScamSearch marca la asociación del correo con estafas conocidas.

La imitación es una de las técnicas más productivas del capítulo. Intentar crear una cuenta con el correo del objetivo en Apple, Live, Facebook o un proveedor local de servicios devuelve, si la dirección ya está en uso, un mensaje «already in use» que confirma que ese servicio existe para el objetivo —y a veces lo ubica geográficamente: saber que su correo controla una cuenta de una cablera local acota drásticamente la zona donde vive—. La regla operativa es tajante: nunca completar la creación de la cuenta; el valor está en el mensaje de error, no en registrarse. El proveedor de correo, por su parte, se obtiene del registro MX del dominio (MXToolbox), útil para ligar varios objetivos a una misma shell company por proveedor compartido.

El username: reuso cross-platform#

Un internauta activo tiende a reusar el mismo username en muchos sitios, y —como se vio— la parte local de un correo suele ser ese nombre de pantalla. Enumerar dónde reaparece un username convierte un solo dato en decenas de perfiles. Los agregadores hacen el barrido: KnowEm consulta más de 500 redes por categoría (checkusernames.php / checksocialnames.php), y CheckUserNames, NameCheckr (con enlaces directos) y UserSearch (que muestra solo perfiles reales) cubren el resto. Del lado del tooling de la máquina de investigación —el arsenal de línea de comandos de 2.1— están sherlock, WhatsMyName, blackbird, maigret, socialscan (disponibilidad en redes y correo a la vez) y holehe (en qué servicios está registrado un correo, sin tocar la contraseña).

# username → perfiles en cientos de sitios sherlock mpulido007 maigret mpulido007 # ¿en qué servicios está registrado ESTE correo? (no revela contraseñas) holehe target@example.com # disponibilidad de un handle en redes + correo socialscan mpulido007 target@example.com

El pivoteo se cierra en bucle: cada perfil nuevo puede exponer un nombre real o un correo distinto, y ese correo vuelve a la permutación del inicio. Es la enumeración cíclica de la metodología de pentest (3.1) aplicada a personas: no se puede pivotar desde el identificador que no se enumeró.

People-search: del nombre real al dossier#

Cuando el pivoteo produce un nombre real, los people-search engines lo convierten en un dossier. Son bases especializadas en personas —sobre todo de Estados Unidos— que, a partir de un nombre, devuelven direcciones actuales y previas, teléfonos (incluidos celulares), correos, parientes y asociados. El orden de utilidad que recomienda Bazzell empieza por TruePeopleSearch (el mejor gratuito, su primera parada) y sigue por FastPeopleSearch —que consulta la misma base pero de la que menos gente hizo opt-out, así que a veces aparece quien se borró del primero—, Nuwber, XLEK, FamilyTreeNow (especialista en parientes), CyberBackgroundChecks, That’sThem (que a veces trae el VIN de un vehículo, la IP domiciliaria o un correo), Intelius, Radaris, Spokeo (freemium: solo el preview, con ?loaded=1 para saltar la animación), AdvancedBackgroundChecks, Yasni (internacional, fuerte en alemán) y ZabaSearch. Todos se consultan por URL directa, lo que permite automatizarlos con herramientas propias que abren la misma consulta en varios sitios a la vez.

Dos advertencias operativas. La primera: muchos de estos sitios bloquean las IPs de VPN en su guerra contra el scraping, de modo que un error «access denied» casi siempre significa que la VPN está bloqueada, no que el dato no exista —tema delicado, porque el OPSEC de 2.1 exige la VPN encendida—. La segunda: nunca pagar el premium antes de agotar todo lo gratuito; la mayoría de lo que venden los background checks de pago está disponible sin costo con algo más de trabajo.

El teléfono en tres fases#

Un número de teléfono se trabaja en tres fases de creciente especificidad. La primera identifica el tipo y el operador: si es fijo, celular o VOIP, y qué proveedor lo sirve. Free Carrier Lookup es el mejor para desenmascarar VOIP (traduce un genérico «Broadband» en Google Voice o Twilio), y Scout devuelve line_type, si el número fue portado (ported) y un risk_rating —VOIP, desvío de llamadas o número enmascarado elevan el riesgo, señal de que el número no está asignado a una persona real sino a un servicio descartable—.

La segunda fase busca al titular (nombre y dirección) a través de las bases de reverse caller-ID —el nombre que muestra el identificador de llamadas, hoy disponible también para celulares—. Twilio Lookup entrega el CALLER NAME y el operador por unos centavos por consulta (su crédito inicial de registro alcanza para más de mil), Apeiron ofrece CNAM gratuito, y sobre todo está Truecaller, cuya base es colaborativa (crowd­ sourced): se arma con los contactos que millones de usuarios subieron al instalar la aplicación.

La lógica de Truecaller explica por qué un número «secreto» aparece igual. Bazzell consultó el número de su teléfono oficial esperando cero resultados y recibió «Mike Bazell»: alguien de su círculo —otro empleado— tenía el número en sus contactos y había instalado la aplicación. En un caso de homicidio, un número devolvió «Drug Dealer Matt», la etiqueta con que un cliente del objetivo lo había guardado. Este dato de identificador de llamadas, dice Bazzell, «ha eliminado la necesidad de citaciones judiciales» en muchos casos —y es también la razón por la que la higiene de contactos importa del lado defensivo—.

La tercera fase es la más simple y a menudo la más fructífera: buscar el número en los motores y en las redes, entre comillas y en sus variantes de formato, para descubrir dónde lo publicó el propio objetivo —un anuncio, un perfil, un currículum— y abrir nuevos pivotes.

Defensa, encuadre púrpura y detección#

Este capítulo es dual-use de manera transparente, y su lente púrpura se lee en dos direcciones.

Del lado ofensivo (red), la cosecha de identidad es la fase de perfilado que precede a la ingeniería social y a los ataques de credenciales. De un correo o un username se obtiene en qué servicios está registrada la persona (holehe, HIBP), sus contraseñas viejas (BreachDirectory → crack) para credential stuffing y password spraying, sus otros perfiles (reuso de username), su nombre real, dirección y teléfono (people-search) y el operador de ese teléfono (para smishing y vishing). El formato de correo corporativo (Email-Format, Hunter) genera la lista de destinatarios de una campaña de phishing contra una empresa. Todo esto desemboca en el recon ofensivo de 2.5 y encadena con la cosecha de credenciales que abre la explotación.

flowchart LR
  subgraph RED["Recon ofensivo"]
    A["correo / username"] --> B["servicios + contraseñas viejas"]
    A --> C["nombre · dirección · teléfono"]
    B --> D["credential stuffing / spray"]
    C --> E["smishing / vishing / phishing"]
  end
  subgraph BLUE["Defensa de identidad propia"]
    F["correos corporativos\nen HIBP / Dehashed /\nHudson Rock"] --> G["rotación forzada + MFA"]
    H["huella de ejecutivos\n(people-search + reuso)"] --> I["opt-out / remoción"]
    J["SPF / DMARC\n(que Emailrep reporta)"] --> K["anti-spoofing del dominio"]
  end
  classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0;
  class A,B,C,D,E,F,G,H,I,J,K n;

Del lado defensivo (blue / CTI), las mismas técnicas se invierten. Para la inteligencia de amenazas y el DFIR, el pivoteo por brechas, la WHOIS inversa y Truecaller sirven para atribuir un actor a partir de su correo, su alias o su teléfono, y la fecha de una casilla Proton delata la infraestructura descartable de una campaña. La presencia de un correo corporativo en stealer logs (Hudson Rock) no es un dato de perfil sino una alerta directa de compromiso: significa que una máquina de la organización tiene un infostealer, y debe tratarse como incidente. Para el defensor de la identidad propia, correr estas técnicas contra la propia organización —el self-recon de 2.1— mide la exposición: buscar los correos del personal en HIBP, Dehashed y Hudson Rock cuantifica cuántas credenciales están filtradas (y fuerza rotación y MFA sobre las expuestas), el reuso de username y los people-search muestran la huella de los ejecutivos (que se reduce con programas de remoción y opt-out en TruePeopleSearch y Nuwber), y el estado de SPF/DMARC que reporta Emailrep.io señala si el dominio es spoofable y hay que endurecerlo contra la suplantación.

En términos de MITRE ATT&CK, este capítulo cubre la táctica de reconocimiento: T1589.001 (Gather Victim Identity Information: Credentials), T1589.002 (Email Addresses), T1589.003 (Employee Names) y T1596 (Search Open Technical Databases). Como toda la fase de recon, su mitigación es Pre-compromise —no se «detecta» en el perímetro, se reduce la superficie que expone—: precisamente el trabajo que la lente púrpura de este capítulo convierte en programa defensivo.

Referencias#

  • osint/bazzell-osint/cap-04 — Identidad de persona: correo (búsqueda, verificación con Emailrep.io, permutación y formato corporativo con Email-Format/Hunter, Gravatar), datos de brecha (HIBP + Dehashed, LeakPeek/BreachDirectory → SHA-1 → crack, Spycloud, Hudson Rock/stealer logs), Pastebin/OCCRP, Proton Mail y WHOIS inverso, imitación y MX; usernames (KnowEm/sherlock/WhatsMyName/holehe); people-search engines (TruePeopleSearch/FastPeopleSearch y el bloqueo de VPN); y el teléfono en tres fases (Free Carrier Lookup/Scout, Twilio/Truecaller crowdsourced, contenido web).
  • Michael Bazzell, OSINT Techniques (10ª ed., 2023), capítulos de correo, usernames, people search y teléfono; el sitio inteltechniques.com para las herramientas —recordando que los pasos concretos caducan y lo durable es el método de pivoteo por identificadores—.
  • Have I Been Pwned y su API unifiedsearch; Hudson Rock para stealer logs; herramientas de la máquina de investigación: holehe, maigret, sherlock.
  • MITRE ATT&CK — Reconnaissance (TA0043): T1589 (Gather Victim Identity Information) y T1596 (Search Open Technical Databases), con mitigación Pre-compromise.