🕵️Dark web monitoring: cómo saber si las credenciales de tu empresa fueron filtradas

El patrón se repite: una empresa recibe una alerta de acceso sospechoso, investiga, y descubre que la credencial del usuario comprometido estaba circulando en foros underground desde hace 6 meses. Nadie lo supo antes porque nadie estaba mirando. Cuando finalmente la rotaron, el atacante ya había estado dentro por semanas.

El dark web monitoring no previene que tus credenciales se filtren — los breaches ocurren en terceros que no controlás. Lo que hace es comprimir brutalmente el tiempo entre "mi credencial está comprometida" y "lo supe". De meses a horas. Y en ese delta se juega casi todo: una credencial comprometida que rotás en 24 horas es incidente; la misma credencial ignorada por 6 meses es breach.

Este artículo explica cómo funciona el monitoreo real (no la versión marketing), qué fuentes cubre, qué hacer cuando aparece una credencial tuya, y cómo encaja en un programa de identidad moderno.

Por qué las credenciales filtradas son el vector #1

Los reportes anuales de incidentes (Verizon DBIR, IBM Cost of Breach, Mandiant M-Trends) muestran el mismo patrón año tras año: las credenciales válidas son el método de acceso inicial en más del 70% de los breaches. Superan al phishing directo, a los exploits de software y al insider malicioso combinados.

¿Por qué? Porque es el camino de menor resistencia:

• No requiere exploit: el atacante no tiene que encontrar vulnerabilidad técnica. Usa credencial legítima.
• Evade la mayoría de controles: firewall, WAF, IDS no detectan login con credenciales válidas.
• Escala trivialmente: con un dump de millones de credenciales, el atacante prueba automáticamente en cientos de servicios (credential stuffing) con ROI positivo.
• Tiempo de dwell alto: el promedio entre compromiso y detección cuando el acceso fue por credencial válida es medido en meses.

Eso es el problema macro. El problema específico de tu empresa: ¿están tus credenciales ya ahí afuera esperando que alguien las use?

Cómo llegan las credenciales al mercado

Las credenciales no salen solo de "breaches famosos". Vienen de cuatro fuentes bien distintas, y entender cada una es clave para evaluar un servicio de monitoreo.

Fuente 1: breaches publicados

Un sitio es hackeado, la base de datos se roba, y eventualmente se publica (en paste sites, foros, dumps masivos tipo "Collection #1"). Es la fuente más visible y la que la mayoría de servicios cubre.

Limitación: entre el hackeo y la publicación pasan típicamente 3-9 meses. Durante ese tiempo la credencial ya fue vendida privadamente y usada.

Fuente 2: logs de infostealers

Este es el mercado más dinámico y peligroso. Un infostealer (RedLine, Vidar, Lumma, Raccoon) es malware que infecta computadoras personales y extrae todo: contraseñas guardadas en navegador, cookies de sesión, wallets, archivos sensibles. Los operadores venden acceso a los logs en Telegram, típicamente actualizados diariamente.

Lo que sale de un infostealer es devastador: credenciales corporativas guardadas en navegador de empleados + cookies de sesión activas + autocompletado de formularios + listas de URLs visitadas. Para el atacante es una radiografía completa de la víctima.

Limitación: requiere acceso a los canales correctos (pagos, reputación). Los servicios serios tienen operaciones dedicadas a ingerir estos logs.

Fuente 3: combolist y ULP

Combolist = archivo email:password generado por combinación de múltiples dumps, destinado a credential stuffing automatizado. ULP = URL:Login:Password, formato similar pero con la URL del servicio incluida.

Estos no son breaches originales — son agregaciones. Pero son lo que los atacantes de volumen realmente usan. Si tu credencial aparece en una combolist grande, está siendo intentada automáticamente contra cientos de servicios en este momento.

Fuente 4: marketplaces y venta privada

Credenciales específicas de alto valor (acceso a panel admin, cuentas con privilegios, VPN corporativa) se venden privadamente en marketplaces (Genesis Market antes de su takedown, sucesores actuales) o directamente en foros con reputación.

Limitación: estas credenciales rara vez llegan a monitoreo público porque se usan privadamente por el comprador. El monitoreo puede detectar el listado antes de la venta, pero no siempre.

Cómo funciona el monitoreo en la práctica

Un servicio de dark web monitoring serio tiene tres componentes:

1. Ingestión continua

Operación 24/7 que absorbe datos de las cuatro fuentes anteriores:

• Crawlers en sitios paste, foros abiertos y feeds de dumps.
• Cuentas operativas en canales de Telegram de infostealers.
• Acceso (con operadores humanos) a foros underground con paywall o reputación.
• Monitoreo de marketplaces activos.

La calidad del servicio se mide por cobertura de fuentes y latencia de ingestión. Un servicio que solo lee Pastebin está cubriendo 5% del mercado real.

2. Normalización y enrichment

Los datos crudos son ruido. El servicio los normaliza:

• Parsea formatos (cada dump tiene el suyo).
• Extrae campos (email, username, password hash, URL).
• Deduplica contra datos previos.
• Correlaciona con breaches conocidos (¿de dónde salió esta credencial?).
• Enriquece con contexto (¿es credencial fresca o combolist reciclada?).

3. Matching y alerta

El servicio compara los datos ingeridos contra tu lista de monitoreo:

• Dominios corporativos (@tuempresa.com).
• Emails específicos (ejecutivos, service accounts, ex empleados críticos).
• Dominios de login (tu panel admin, tu VPN).

Cuando hay match, dispara alerta con contexto: qué credencial, fecha estimada de compromiso, qué fuente, qué otros datos asociados aparecen.

Qué hacer cuando llega la alerta: playbook de 24 horas

Una alerta de dark web no es un evento — es el inicio de un incidente. El playbook estándar:

Hora 0-1: contención inmediata

1. Identificar cuenta afectada con precisión. Email + sistema + timestamp de la credencial.
2. Rotar la credencial en el sistema original. No "comunicar al usuario y esperar" — rotar vos primero.
3. Invalidar todas las sesiones activas del usuario. Forzar logout global.
4. Verificar 2FA: si no estaba activo, activarlo ahora como parte de la rotación.

Hora 1-4: evaluación de alcance

5. Revisar logs de los últimos 90 días del usuario. Buscar anomalías: logins desde IPs no típicas, horarios raros, endpoints nunca consultados, cambios de configuración.
6. Verificar reutilización: ¿esa contraseña o una variante se usó en otros sistemas corporativos? Si sí, rotar en todos.
7. Si el usuario tiene privilegios elevados: auditoría de todos los cambios que hizo en el período, especialmente cambios de configuración, nuevos usuarios creados, permisos asignados.

Hora 4-24: forense e investigación

8. Determinar el origen si es posible. ¿Aparece en un breach conocido de un servicio que el usuario usaba? ¿Es log de infostealer (implica que su dispositivo estaba comprometido)?
9. Si es infostealer: el dispositivo del usuario probablemente todavía está comprometido. Aislar, forense, re-imagen. Cualquier credencial que el usuario guardó en ese dispositivo está potencialmente comprometida también.
10. Notificar al usuario con instrucciones claras y sin alarmismo. El usuario no es culpable por default — el mensaje debe ser constructivo.

Hora 24-72: cierre del ciclo

11. Post-mortem interno: ¿por qué no lo detectamos antes? ¿hubo acceso malicioso que pasó desapercibido?
12. Actualizar baseline del usuario en el sistema de detección de anomalías — puede tener señales nuevas que considerar.
13. Comunicación a equipos relevantes: legal si hay implicaciones regulatorias, operaciones si el sistema afectado toca clientes.

Qué NO hacer (errores frecuentes)

• Ignorar la alerta porque "2FA está activo": 2FA no cubre cookies robadas, phishing con proxy, ni escala a otros sistemas donde la contraseña fue reutilizada.
• Solo rotar sin investigar: el atacante pudo haber tenido acceso por meses. La rotación cierra la puerta pero no te dice qué hicieron mientras estuvo abierta.
• Esperar al usuario para rotar: los usuarios están en reunión, dormidos, de vacaciones. La rotación es tu responsabilidad inmediata, no la del usuario.
• No monitorear ex empleados: sus credenciales pueden seguir apareciendo años después y ellos conocían credenciales compartidas.
• Elegir servicio por precio sin validar fuentes: un monitoreo barato que solo lee Pastebin te va a dar tranquilidad falsa.
• No integrar con el resto del stack: alerta de dark web que no se correlaciona con logs de acceso es ruido; la misma alerta correlacionada con un login anómalo reciente es incidente crítico.

Cómo el monitoreo se integra con otras capas

Dark web monitoring por sí solo es detección post-fuga. Su valor se multiplica cuando se integra con el resto del programa de identidad:

Integración con vault (password manager de equipo)

Cuando una credencial del vault aparece en dark web, la rotación puede ser automática:

• Generar nueva contraseña aleatoria.
• Actualizar en el sistema de destino.
• Actualizar en el vault.
• Notificar al usuario.

Sin integración, el flujo es manual y toma horas. Con integración, minutos.

Integración con 2FA/passkeys

Si aparece credencial de un usuario que todavía no tiene 2FA obligatorio, la alerta dispara política de forzado: 2FA activado en la siguiente sesión o bloqueo.

Integración con detección de anomalías

Si hay match dark web + acceso anómalo del mismo usuario en las últimas 72 horas, severidad escala a crítica automáticamente. Es señal casi definitiva de compromiso activo, no solo credencial filtrada.

Integración con SIEM/SOAR

Cada alerta debería ser un evento estructurado que entra al SIEM con los campos correctos (usuario, sistema, fuente, timestamp, severidad). Desde ahí dispara playbooks automatizados en el SOAR.

Cómo evaluar un servicio de monitoreo

Checklist honesto para comparar:

• [ ] Cobertura de fuentes declarada explícitamente (las 4 mencionadas arriba).
• [ ] Latencia de ingestión con SLA numérico (no "continuo").
• [ ] Soporte para monitoreo por dominio, no solo por email individual.
• [ ] Matching contra credenciales hasheadas (no solo plaintext).
• [ ] Deduplicación inteligente (no te alerta 30 veces por la misma credencial en combolists distintas).
• [ ] Contexto en la alerta (fecha de compromiso estimada, fuente, credenciales asociadas).
• [ ] API para integración con vault, SIEM, SOAR.
• [ ] Histórico consultable (¿apareció esta credencial antes? ¿en qué fecha?).
• [ ] Monitoreo de ex empleados como feature explícita.
• [ ] Transparencia sobre fuentes que NO cubren (ningún servicio cubre 100%).

Si un proveedor no puede responder a más de 7 de estos puntos concretamente, el servicio es superficial.

Límites reales del monitoreo

Honestidad intelectual: el dark web monitoring no es magia. Tiene límites:

• No detecta credenciales vendidas privadamente y nunca publicadas. Si tu empresa fue target de ataque dirigido y las credenciales se usaron sin circular, el monitoreo no lo va a ver.
• Falsos positivos por combolist reciclados: una credencial vieja de 2019 puede aparecer "nueva" en una combolist 2026. Servicios buenos correlacionan; servicios malos te alertan cada vez.
• Lag estructural: incluso con ingestión continua, hay ventana inevitable entre fuga y publicación + detección.
• Cobertura incompleta de fuentes cerradas: foros con paywall alto, grupos privados por invitación, Discord servers específicos — siempre hay mercado más oscuro que el que se cubre.

Estos límites no invalidan el monitoreo — lo posicionan. Es capa necesaria, no suficiente. Combinado con 2FA, detección de anomalías y vault con rotación automática, cierra un porcentaje enorme del vector de credenciales comprometidas. Sin esas otras capas, queda solo como feed de información que llega tarde.

Cierre

Las credenciales comprometidas son el vector #1 de ataques exitosos y seguirán siéndolo. La probabilidad de que credenciales de tu empresa estén ya circulando en algún lado es alta — mucho más alta de lo que la mayoría asume. El dark web monitoring no cambia esa realidad, pero cambia cuándo te enterás: de meses a horas. Ese cambio de delta es la diferencia entre "rotamos antes de que la usaran" e "investigamos cómo nos pasó esto". Comprimí el tiempo de detección, integralo con el resto de tus controles de identidad, y convertí la inevitabilidad del compromiso en incidente gestionable.