Panorama#

La identidad (2.2) presentó los datos de brechas como «la técnica más valiosa» del oficio; este capítulo la lleva a su forma completa y, al hacerlo, cierra la Parte 2 y el bloque rojo del manual. La idea central es un cambio de postura: en lugar de consultar servicios que indexan brechas ajenas, el investigador arma su propia colección offline de datos filtrados y la interroga con sus propias herramientas. Y de ahí la lección más importante, la que sobrevive a cualquier dataset: lo durable no son las URLs de descarga —caducan cada semana— sino la cadena de herramientas de línea de comandos para limpiar y consultar volcados de gigabytes sin una base de datos indexada.

El material se ordena en cuatro capas de invasividad creciente. Los leaks son datos que nunca debieron publicarse así —padrones, listas de spam, scrapes masivos—. Las breaches son bases robadas que incluyen credenciales. Los stealer logs son la fotografía completa de una máquina infectada por malware. Y los volcados de ransomware son terabytes de documentos internos publicados por extorsión. Cada capa expone más y pertenece a una zona legal y ética más delicada, y el capítulo entero está gobernado por un encuadre explícito —el que Bazzell llama Pre-Crime unit—: se ingiere el dato para notificar a los comprometidos y desanonimizar criminales, nunca para acceder a cuentas ni redistribuirlo. Ese encuadre no es un adorno moral: es la línea legal y, como se verá al cierre, la puerta directa al trabajo del analista azul.

flowchart TD
  L["Leaks\n(padrones · spam · scrapes)"]
  B["Breaches\n(+ credenciales)"]
  S["Stealer logs\n(máquina infectada completa)"]
  R["Ransomware\n(volcados por extorsión)"]
  L --> B --> S --> R
  L -.->|"email → dossier"| P["Portal interno\n(email → nombre → DL →\ndirección, en segundos)"]
  B -.->|"reúso de contraseña"| P
  S -.->|"HWID → todas las cuentas"| P
  R -.->|"OCR de IDs escaneados"| P
  P -.->|"notificar / atribuir"| BLUE["workflow blue (P5)"]
  classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0;
  class L,B,S,R,P,BLUE n;

La cadena de herramientas: consultar terabytes sin base de datos#

El investigador no depende de una base indexada: descarga el volcado y lo procesa con utilidades de Unix. La secuencia es siempre la misma. Se fusionan los archivos (cat * > salida.txt), se busca con Ripgreprg -aFiN patrón, donde -a trata el binario como texto, -F toma el patrón literal, -i ignora mayúsculas y -N omite el número de línea—, que recorre terabytes a máxima velocidad sin índice, y se adelgaza el dataset para acelerar las consultas siguientes. sed sustituye y limpia (normaliza separadores, quita comillas), cut -d, -f4,5,20 extrae solo las columnas útiles de un CSV de doscientas (con LC_ALL=C por delante para evitar el error de secuencia de bytes), y sort -u deduplica. Cuando el dato viene en JSON —un registro puede ocupar varias pantallas—, jq lo aplana a una línea por entrada. Dominar este puñado de comandos convierte un volcado de 118 GB en un .txt manejable, y es lo único que no caduca.

# fusionar, buscar sin índice, adelgazar cat * > breach.txt rg -aFiN objetivo@ejemplo.com breach.txt # búsqueda literal a máxima velocidad rg -aFiN "Michael" breach.txt | rg -aFiN "Bazzell" # AND encadenando pipes LC_ALL=C cut -d, -f4,5,20 *.csv > columnas.csv # extraer solo lo útil sort -u -b -i -f columnas.csv > final.txt # deduplicar + ordenar # aplanar JSON a una línea por registro jq --raw-output '"\(.data.first_name),\(.data.work_email),\(.data.mobile_phone)"' people.json > people.txt

Leaks y open databases: de un email a un dossier#

Un leak convierte un identificador en un perfil que ningún sitio público entrega: una lista de spam liga un correo a nombre real, ciudad e IP; el breach de Snapchat resuelve username a teléfono y —a diferencia de los sitios que exigen el dato exacto— permite búsqueda parcial (topher4* devuelve candidatos); el scrape de LinkedIn de 2021, con cientos de millones de perfiles, enlaza URL de perfil, correo y celular. Un pariente cercano son las open databases: instancias de Elasticsearch mal configuradas, halladas en Shodan (product:elastic port:9200) y leídas por URL (_cat/indices lista los índices, _search?size= muestra los registros) —el mismo tipo de exposición en la nube que rastreó la infraestructura (2.4)—.

Aquí la línea legal se estrecha. Leer un dato que ya es público es reconocimiento de fuentes abiertas; pero manipular una URL para extraer de una base ajena, y sobre todo usar el dato para vender, extorsionar o publicar, cae bajo leyes de intrusión informática como la CFAA, cuyo alcance es deliberadamente amplio. La proporcionalidad y las reglas de enganche de 2.1 aplican con máxima fuerza en todo este capítulo: cuanto más sensible es la fuente, más estrecho el margen entre la investigación legítima y el delito.

Breaches y la técnica estrella: el reúso de contraseña#

Las breaches son bases robadas que incluyen credenciales, y los combo-lists —como COMB, con miles de millones de pares correo:contraseña de muchas brechas fusionadas— las concentran. Sobre ellas opera la técnica que Bazzell llama, sin matices, la más exitosa que ha aplicado: el reúso de contraseña. Dado el correo de un objetivo, se obtiene su contraseña y luego se busca esa contraseña en la colección (rg -aFiN <clave>); lo que aparece son las demás cuentas que la reúsan, incluido el correo personal que se escondía detrás de un burner. La confianza escala con la unicidad de la clave: password1234, que aparece en cientos de sitios, no prueba nada; una contraseña compleja compartida entre dos cuentas es casi con certeza la misma persona. La misma consulta por dominio (rg -aFiN @empresa.com) devuelve todas las credenciales de una organización.

Cuando la brecha guarda la contraseña hasheada —transformada por una función de una vía—, hay un paso previo. Se identifica el tipo de hash con herramientas como Name-That-Hash (MD5 y SHA-1 son frágiles; SHA-256/512 con salt son duros o casi imposibles) y se revela el texto plano buscándolo contra los archivos de hashes ya descifrados (hashes.org, HashMob) o con servicios en línea. Con la contraseña en claro se re-pivota por reúso. Este descifrado de hashes es el mismo procedimiento que la cosecha de credenciales (4.5) aplica sobre los volcados de NTDS.dit con hashcat: en ambos lados, un hash filtrado es una contraseña que todavía no se leyó.

Stealer logs: la fotografía completa de una máquina infectada#

Los stealer logs son lo que un infostealer —Redline, Raccoon, Vidar— exfiltra de un Windows infectado (a través de software pirata o una web maliciosa), y son la fuente más completa del capítulo. Cada víctima produce una carpeta cuyo nombre lleva país, identificador de hardware (HWID) y fecha, y dentro está todo: los Autofills del navegador (nombre, dirección, fecha de nacimiento, tarjetas), las Cookies —que permiten el robo de sesión: con la cookie de una cuenta no hace falta la contraseña—, un Passwords.txt con todas las credenciales guardadas en el navegador, la lista de software instalado (qué VPN o qué juegos usa, base para un pretexto de ingeniería social), una captura del escritorio y los datos de hardware con la IP. Se distribuyen en canales de Telegram que regalan muestras como promoción, y se pivotan por correo, por contraseña o —el salto único— por HWID o nombre de dispositivo: un solo identificador de máquina destapa todas las cuentas de esa persona.

Este es también el punto donde el capítulo se vuelve, sin transición, un indicador de compromiso. La presencia de un correo corporativo en un stealer log no es un dato de perfil: significa que una máquina de la organización está infectada por malware, y —crucial— que el atacante tiene las cookies de sesión, de modo que la respuesta no es solo cambiar la contraseña sino invalidar las sesiones, porque una cookie robada replica el acceso saltando incluso el MFA. Ese robo de cookie de sesión es el primo web del pass-the-hash que estudió el web moderno (3.5) con la sesión y el token.

Ransomware: doble extorsión y la industrialización del cruce#

La cuarta capa es el ransomware de doble extorsión: cuando la víctima no paga —porque tiene copias de seguridad—, el grupo publica todo en leak-sites alojados en Tor, localizables con rastreadores públicos (ransomwatch, deepdarkCTI, darkfeed). Los volcados son terabytes de documentos, bases de datos y, sobre todo, escaneos de identificaciones. El salto metodológico que Bazzell describe es industrial: aplicar OCR a las imágenes y leer el código de barras del reverso de las licencias produce texto estructurado —nombre, fecha de nacimiento, número de licencia, dirección— que se ingiere a una base interna capaz de alertar cuando aparece un cliente. Todo converge en un portal que, de un solo correo, cruza en segundos el nombre real (de una breach), la licencia (de un volcado de ransomware) y la dirección (de un people-search y el WHOIS histórico de 2.4). La lección defensiva que el propio capítulo inserta es directa: nunca permitir que una empresa escanee un documento de identidad, porque terminará filtrado en el próximo ataque.

Ética, encuadre púrpura y cierre del bloque rojo#

Bazzell dedica el cierre del capítulo a justificar el acceso, y su argumento es el que gobierna toda la Parte 2: «podemos dejar que solo los criminales usen estos datos para hacernos la vida más difícil, o usarlos como herramienta para exponer a esos criminales que de otro modo quedarían ocultos». De ahí las reglas invariables: jamás iniciar sesión en una cuenta ajena (es delito), jamás redistribuir el dato, aislar los volcados —que contienen malware— en una máquina dedicada, no guardarlos en la nube, y verificar las leyes locales y las políticas del empleador antes de tocar nada. Ese encuadre es exactamente el puente al bloque azul.

flowchart LR
  subgraph RED["Cadena de suministro de ataques a credenciales (red)"]
    A["combo-lists"] --> B["credential stuffing /\npassword spraying"]
    C["cookies de stealer logs"] --> D["robo de sesión /\npass-the-cookie (salta MFA)"]
    E["InstalledSoftware +\nscreenshot"] --> F["pretexto de\ningeniería social"]
  end
  subgraph BLUE["Pre-Crime: el workflow blue (P5)"]
    G["exposición propia en\nHIBP / COMB / stealer logs"] --> H["rotación + MFA"]
    I["empleado en stealer log\n= infección de host"] --> J["revocar SESIONES,\nno solo password"]
    K["leak-sites de Tor"] --> L["¿se publicó nuestra data?\n→ notificar afectados"]
  end
  classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0;
  class A,B,C,D,E,F,G,H,I,J,K,L n;

Del lado ofensivo (red), este capítulo es la cadena de suministro de los ataques a credenciales e identidad: los combo-lists alimentan el credential stuffing y el password spraying —probar los pares reusados contra otros servicios es exactamente el reúso que aquí se explota offline—, las cookies de los stealer logs permiten el pass-the-cookie que salta el MFA, y el software instalado más la captura de pantalla dan el pretexto perfecto de ingeniería social.

Del lado defensivo (blue / CTI), este capítulo es, casi literalmente, el flujo de trabajo azul —el que Bazzell llama Pre-Crime—: (1) buscar los correos y dominios propios en las brechas, los combo-lists y los stealer logs mide qué credenciales del personal están vivas y fuerza rotación y MFA; (2) la presencia de un empleado en un stealer log es la señal directa de una infección de host, que exige respuesta de endpoint y revocación de sesiones/cookies, no solo un cambio de contraseña —el análisis de infostealers pertenece ya a la detección y análisis de malware (5.8)—; (3) monitorear los leak-sites de Tor avisa si la propia organización fue publicada y permite triar el volcado para notificar a los afectados; y (4) los combo-lists, stealer logs y leak-sites son fuente de colección para la atribución y el aviso temprano de un programa de threat intelligence. La higiene que el capítulo deja clara es la contramedida de todo: gestor de contraseñas dedicado —no el del navegador—, MFA resistente a phishing, y no entregar el documento de identidad para su escaneo.

En MITRE ATT&CK el capítulo cubre el reconocimiento de credenciales (T1589.001) y anticipa su uso: T1078 (Valid Accounts), T1110.004 (Credential Stuffing) y T1550.004 (Use Alternate Authentication Material: Web Session Cookie, el pass-the-cookie). Sus mitigaciones son la MFA (M1032), las políticas de contraseña (M1027) y la formación del personal (M1017).

Con este capítulo se cierra la Parte 2 (6/6) y, con ella, todo el bloque rojo del manual —la explotación (P3), Active Directory (P4) y el reconocimiento (P2)—. Y no es casual que el cierre del bloque ofensivo sea, en su cara defensiva, el flujo de trabajo del analista azul: el Pre-Crime de este capítulo es la primera puerta del bloque blue (P5), donde la misma inteligencia que arma un ataque se convierte en la que lo detecta, lo atribuye y lo responde.

Referencias#

  • osint/bazzell-osint/cap-07Leaks, breaches, stealer logs y ransomware: la cadena de herramientas offline (cat/Ripgrep rg -aFiN/sed/cut/sort/jq/LC_ALL=C), los leaks y las open databases (Elasticsearch en Shodan y la línea CFAA), las breaches y el reúso de contraseña con combo-lists (COMB) e identificación y descifrado de hashes (Name-That-Hash, hashes.org/HashMob), los stealer logs (Redline/Raccoon/Vidar, Cookies y robo de sesión, pivote por HWID, distribución por Telegram), el ransomware de doble extorsión (leak-sites de Tor, OCR y códigos de barras de IDs) y el encuadre Pre-Crime.
  • Michael Bazzell, OSINT Techniques (10ª ed., 2023), sección de breach data; inteltechniques.com —recordando que las fuentes de descarga caducan y lo durable es la cadena de herramientas y el método de pivoteo—.
  • Herramientas: ripgrep, jq, Name-That-Hash, y Have I Been Pwned como consulta pública de exposición y comunalidad de contraseñas.
  • MITRE ATT&CK — Reconnaissance (TA0043) y su uso posterior: T1078 (Valid Accounts), T1110/004 (Credential Stuffing) y T1550/004 (Web Session Cookie), con mitigaciones MFA (M1032) y políticas de contraseña (M1027).