Dark web monitoring: cómo saber si las credenciales de tu empresa fueron filtradas | Drokio Blog | Drokio
Identidaddark webcredential stuffingidentidad
🕵️Dark web monitoring: cómo saber si las credenciales de tu empresa fueron filtradas
El 80% de los breaches empiezan con una credencial ya filtrada en dark web meses antes. Cómo funciona el monitoreo continuo, qué fuentes cubre, y por qué comprimir el tiempo entre fuga y detección es el único control realista frente a reutilización de contraseñas.
Drokio··10 min de lectura
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.
La diferencia entre "dark web" (término marketing) y las 4 fuentes reales donde aparecen credenciales.
Por qué el tiempo de detección es la única métrica que realmente importa.
Infostealers, combolist, dumps y ULP: el léxico del mercado de credenciales.
Qué hacer en las primeras 24 horas después de una alerta.
Cómo el monitoreo se integra con vault, 2FA y detección de anomalías para cerrar el ciclo.
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:
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
Identificar cuenta afectada con precisión. Email + sistema + timestamp de la credencial.
Rotar la credencial en el sistema original. No "comunicar al usuario y esperar" — rotar vos primero.
Invalidar todas las sesiones activas del usuario. Forzar logout global.
Verificar 2FA: si no estaba activo, activarlo ahora como parte de la rotación.
Hora 1-4: evaluación de alcance
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.
Verificar reutilización: ¿esa contraseña o una variante se usó en otros sistemas corporativos? Si sí, rotar en todos.
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
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)?
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.
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
Post-mortem interno: ¿por qué no lo detectamos antes? ¿hubo acceso malicioso que pasó desapercibido?
Actualizar baseline del usuario en el sistema de detección de anomalías — puede tener señales nuevas que considerar.
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.
[ ] 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.
Preguntas frecuentes
¿Dark web monitoring previene el breach original?
No. El breach ya ocurrió, probablemente meses antes de que la credencial aparezca en dark web. Lo que el monitoreo hace es comprimir el tiempo entre la fuga y tu detección, de meses a horas. Ese tiempo comprimido es lo que te permite rotar la credencial antes de que el atacante la use contra vos en credential stuffing o phishing dirigido. Es control de detección, no de prevención.
¿Cuánto tardan las credenciales en aparecer en dark web después de un breach?
Varía enormemente. Algunos breaches se publican dentro de las 24 horas para maximizar notoriedad del actor. Otros se venden privadamente durante 6-18 meses antes de publicarse, y en ese período son usados por el comprador original. Los peores (desde tu lado) son los que nunca se publican y circulan solo en círculos cerrados — esos no los detecta ningún monitoreo. En promedio, credenciales aparecen públicamente en 3-9 meses post-breach.
Si todas mis credenciales tienen 2FA, ¿para qué monitoreo dark web?
Por tres razones. Primero, 2FA no es universal — hay sistemas donde no lo podés activar (legacy, algunos SaaS pequeños). Segundo, phishing con proxy rompe 2FA en tiempo real — si el atacante sabe que la credencial es válida por el dump, el phishing es mucho más efectivo. Tercero, el SOC necesita saber qué empleados están comprometidos para vigilar su comportamiento con más atención, independiente de que 2FA esté activo.
¿Qué diferencia hay entre 'dark web' y las fuentes reales donde aparecen las credenciales?
'Dark web' es término marketing. Las fuentes reales son cuatro tipos: (1) dumps públicos en sitios tipo paste, (2) canales de Telegram con logs diarios de infostealers, (3) foros underground con acceso por reputación, (4) marketplaces con compra por cripto. Las credenciales más frescas y relevantes están en los logs de infostealers de Telegram, no en la 'dark web' clásica. Un servicio de monitoreo serio cubre los 4 tipos; uno débil solo cubre el primero.
¿El monitoreo cubre también credenciales de ex empleados?
Depende del diseño. Lo correcto es monitorear el dominio corporativo completo más una lista explícita de emails históricos relevantes. Si un ex empleado reutilizaba su email corporativo en servicios personales, esas credenciales pueden seguir apareciendo años después del offboarding — y si nunca rotaste las credenciales compartidas que esa persona conoció, son vector activo. Monitoreo por dominio continuo cubre esto automáticamente.
¿Cada cuánto se actualiza el monitoreo?
Los servicios serios operan con ingestión continua (minutos a horas). Los más básicos actualizan semanalmente. La diferencia importa: un atacante que compra un dump usa las credenciales en las primeras 48-72 horas cuando todavía son frescas. Si tu monitoreo tiene lag semanal, la probabilidad de que el atacante ya haya actuado antes de tu alerta es alta. Pedí SLA explícito de tiempo de detección — no 'monitoreamos continuamente' sin número.
Producto mencionado
🔑
Llave
Higiene de credenciales medible
Mide qué tan riesgosa es tu higiene de credenciales — claves expuestas, riesgo promedio/peor y banda por sitio — sin guardar nunca un secreto. $9/mes.
Análisis de comportamiento en sesiones autenticadas: la nueva frontera
Detección de anomalías en el login es territorio conocido. La frontera 2026 es detectar anomalías después del login, dentro de la sesión autenticada. Cómo funciona UBA moderno, qué señales importan, cómo se entrena el modelo por usuario y por qué es el único control efectivo contra sesiones secuestradas.
