Chainalysis pasó en cinco días de no ver credenciales expuestas a confirmar las de todos sus usuarios

El 30 de octubre, Chainalysis informó de que un actor externo, valiéndose de lo que llamó «offensive agentic techniques» (técnicas agénticas ofensivas), había accedido a datos de identidad de los usuarios de su plataforma: identificadores, nombres, correos y etiquetas de rol. Según recogió The Block, el aviso publicado por la empresa añadía que no había indicios de acceso a contraseñas en claro, secretos de MFA ni tokens de sesión.

A las once de la noche del 4 de noviembre, hora del este de EE. UU., esa misma página admitía que Chainalysis sabía desde el lunes 2 que estaban expuestos los nombres, los nombres de usuario, los hashes de contraseña y los tokens activos de todos sus usuarios.

Chainalysis vende análisis de cadenas de bloques a policías, agencias gubernamentales, entidades financieras, aseguradoras y empresas de criptoactivos, según BleepingComputer. Su producto KYT (Know Your Transaction) lo usan plataformas de intercambio de criptoactivos y bancos para cribar operaciones contra el blanqueo, a menudo conectado por API a sus propios sistemas. Para esos clientes, cada versión del aviso pedía una respuesta distinta. Con la del 30 de octubre lo indicado era avisar a los usuarios y activar el doble factor. Con la del 4 de noviembre había que rotar cada clave de API y suponer que otra persona podía haber manejado las integraciones.

¿Qué ha contado Chainalysis sobre cómo entró el atacante?

Poco, y ese poco hay que separarlo de la especulación. Chainalysis ha descrito dos elementos, sin detalle técnico de ninguno de ellos.

¿A qué llama la empresa técnicas agénticas ofensivas?

Chainalysis no ha definido la expresión, que en el uso habitual designa agentes de IA que encadenan acciones por su cuenta: reconocimiento, intentos de acceso, movimiento lateral entre herramientas internas. La empresa tampoco ha dicho qué vulnerabilidad o credencial se usó, qué sistemas alcanzó el intruso ni cuánto tiempo mantuvo el acceso.

Una nota de investigación de la Cloud Security Alliance, elaborada con asistencia de IA y sin revisión formal de la organización, señala que se desconoce si el atacante usó un marco de código abierto o herramientas propias. También considera sin confirmar las versiones que sitúan la entrada en un ataque de relleno de credenciales.

En octubre, Microsoft relacionó el marco de código abierto ARTEX con el grupo Storm-0940 y con la intrusión en ConnectWise, un caso que repasamos en el análisis sobre Storm-0940 y ARTEX. The Hacker News sitúa a Chainalysis entre los ataques apoyados en IA de las últimas semanas, aunque precisa que no se sabe quién está detrás.

¿En qué consiste el ataque en ruta?

En la mañana del 4 de noviembre, Chainalysis atribuyó la exposición de una parte de las contraseñas a un ataque en ruta (on-path): un atacante situado en el camino entre el usuario y el servicio, capaz de leer lo que circula por él. BleepingComputer lo equipara a un ataque de intermediario (MITM). La empresa no ha precisado dónde se produjo la interceptación y afirma que esa vía está controlada y corregida.

Tampoco ha revelado con qué algoritmo protegía las contraseñas. Como señala The Register, sin ese dato no se puede estimar si los hashes se rompen con facilidad. Para el cliente, la hipótesis de trabajo es que el atacante conoce las contraseñas.

¿Cómo creció el alcance de una actualización a otra?

La página del incidente se ha ido ampliando con entradas fechadas. Leídas en orden, muestran cómo creció el alcance y qué se hizo en cada paso:

• 30 de octubre: la empresa informa de una intrusión detectada en octubre, con acceso a identificadores, nombres, correos y roles, y sin indicios de acceso a contraseñas en claro, secretos de MFA ni tokens de sesión. Recomienda activar el doble factor.
• 2 de noviembre: desconecta por precaución Reactor, su plataforma de investigación, y Data Solutions, su servicio de datos de amenazas, mientras especialistas externos evalúan la seguridad.
• 4 de noviembre, 9:50: anuncia que un ataque en ruta ha expuesto parte de las contraseñas, bloquea las cuentas afectadas y exige cambiarlas.
• 4 de noviembre, 10:30: tras detectar actividad anómala, desconecta KYT (interfaz y API), los demás productos de cribado de direcciones y la página de inicio de sesión. El cambio de contraseña deja de funcionar temporalmente.
• 4 de noviembre, 23:00: confirma que el lunes 2 descubrió la exposición de los nombres, los nombres de usuario, los hashes y los tokens activos de todos los usuarios, y empieza a avisar a los clientes cuyas cuentas de KYT parecen haber sido objeto de acceso no autorizado.
• 6 y 7 de noviembre: reabre KYT y el cribado de direcciones por fases, tras pedir a cada cliente sus IP de confianza para una lista de permitidas y exigir el cambio de contraseña y la rotación de claves de API. El 7 vuelve también Reactor.

De la cronología importan sobre todo dos cosas. La primera es la distancia entre el hallazgo y su comunicación: según la entrada nocturna del día 4, la exposición total se conocía desde el lunes 2 y, aun así, la entrada de la mañana del miércoles seguía hablando de una parte de las contraseñas. Puede que Chainalysis quisiera confirmar el alcance antes de anunciarlo. Para el cliente, el motivo da igual, porque durante dos días actuó con un aviso que ya no describía el incidente.

La segunda es que la exposición pudo convertirse en uso: Chainalysis habla de cuentas de KYT que parecen haber sufrido accesos no autorizados. La empresa mantiene que no tiene pruebas de acceso a sus datos de investigación ni de manipulación de sus datos de atribución.

¿Por qué el cliente apenas ve este uso desde sus sistemas?

Las credenciales expuestas no pertenecían al directorio corporativo de los clientes. Eran cuentas de la plataforma y tokens emitidos por Chainalysis (la empresa no ha precisado de qué tipo), almacenados y validados en su infraestructura; por precaución, exige además rotar las claves de API. Ningún registro de Entra ID u Okta habría mostrado el uso de un token o una clave robados contra KYT. Un inicio de sesión federado, si existía, algo que no se ha detallado, solo habría dado visibilidad sobre los accesos con contraseña.

Con las claves de API el problema es mayor. En un banco o una plataforma de criptoactivos, la integración con KYT se ejecuta a menudo en un servidor que envía transacciones a cribar de forma automática, con una clave creada hace tiempo por alguien que quizá ya no está en el equipo. Son identidades no humanas que muchas organizaciones no tienen inventariadas con responsable y caducidad. Usado desde fuera, un token válido genera un tráfico muy parecido al de la integración legítima. Quien está en posición de distinguirlo es el proveedor, que fue quien detectó la actividad anómala.

El incidente de ConnectWise citado más arriba siguió el mismo patrón. En su servicio Cloud Backup (SkyKick), a partir de una credencial comprometida de la aplicación, Huntress detectó inicios de sesión con éxito en más de 300 inquilinos de Microsoft 365, y los clientes dependieron igualmente de la información que publicaba el proveedor.

¿Qué puede revisar el cliente por su cuenta?

La telemetría principal está en manos del proveedor, pero varias comprobaciones dependen solo del cliente y no deberían esperar a la siguiente actualización:

• Inventario de cuentas y claves: quién tenía cuenta en la plataforma y con qué rol, qué integraciones usan claves de API, en qué servidores se guardan y quién puede rotarlas.
• Rotación que alcance todas las copias. Chainalysis exige a todos los usuarios cambiar la contraseña y rotar las claves; la medida debe llegar también a las copias guardadas en herramientas de gestión de configuración, entornos de pruebas o scripts de conciliación.
• Reutilización de contraseñas. La empresa pide cambiarlas en todos los servicios donde se hubieran repetido. En el lado corporativo, eso supone vigilar los intentos de acceso a la VPN, al correo y al inicio de sesión único dirigidos contra esos usuarios, porque los hashes que se consiguen romper suelen acabar en campañas de credenciales comprometidas.
• Registros de salida. El proxy o el cortafuegos muestran qué sistemas internos llamaban a la API y con qué volumen, pero no el uso hecho desde otra infraestructura. Para eso hay que pedir al proveedor la actividad de cada clave desde octubre.
• Resultados de cribado. Si alguna cuenta de KYT se usó sin autorización, el área de cumplimiento debe revisar las alertas cerradas, los cambios de reglas y las transacciones enviadas durante el periodo, aunque Chainalysis no haya descrito qué hizo el intruso con esas cuentas.
• Suplantación del proveedor. Los nombres y roles expuestos señalan a los analistas de cumplimiento e investigación de cada cliente, blanco previsible de fraudes telefónicos (vishing) y de correos falsos con instrucciones de «reconexión», justo cuando Chainalysis está enviando instrucciones reales por correo.

Cambiar una contraseña resulta insuficiente mientras sigan vivos los tokens de sesión emitidos antes del cambio. El informe de la ANSSI sobre la DGFiP lo mostró con claridad, como explicamos en el análisis «Cambiar la contraseña no cierra la sesión».

¿Puede la vigilancia de credenciales expuestas adelantarse al aviso del proveedor?

Puede adelantarse en parte. La vigilancia de credenciales e información expuesta rastrea de forma continua los registros de infostealers, los mercados de accesos, los foros, los canales de Telegram y los sitios de volcado. Busca en ellos los dominios, los correos corporativos, los tokens y los proveedores críticos de una organización. No ve lo que el atacante guarda sin publicar, como los hashes de Chainalysis, pero sí señales que suelen rodear una brecha así:

• Credenciales de empleados con acceso a la plataforma del proveedor en registros de infostealers, una vía de entrada habitual en las brechas de servicios SaaS.
• Anuncios de venta de accesos o de datos que mencionan al proveedor o a sus clientes.
• Correos corporativos y contraseñas en listas combinadas, útiles para probar la reutilización contra la VPN o el correo.
• Dominios parecidos al del proveedor, registrados para enviar instrucciones falsas de reconexión.

Los registros de infostealers pesan más de lo que parece. Según el resumen del DBIR 2025 de Verizon, el 54 % de las víctimas de ransomware analizadas tenía su dominio en volcados de credenciales, y el 46 % de los equipos comprometidos con accesos corporativos no estaba gestionado por la empresa.

La vigilancia no sustituye el aviso del proveedor ni la rotación de credenciales, y solo aporta valor si cada hallazgo se verifica antes de convertirlo en alerta. Hard2bit la presta como servicio anual dentro de su servicio de inteligencia de amenazas, con alertas que incluyen contexto y acción recomendada.

¿Qué debería estar pactado con el proveedor antes del próximo incidente?

Chainalysis reabrió el servicio con listas de IP permitidas, cambio obligatorio de contraseñas y rotación de claves. Varios de esos controles podrían haber estado activos de antemano si el contrato y la configuración los hubieran previsto, y adelantar esas decisiones es buena parte del trabajo de gestión del riesgo de terceros.

Para las entidades financieras sujetas a DORA, el artículo 30 del Reglamento (UE) 2022/2554 obliga a que los contratos con proveedores TIC incluyan su asistencia ante un incidente relacionado con el servicio, sin coste adicional o con un coste fijado de antemano. Si el servicio sostiene funciones críticas o importantes, el contrato debe recoger también los plazos de preaviso y las obligaciones de información del proveedor.

Una herramienta de cribado integrada en el proceso de prevención del blanqueo es una candidata probable a esa clasificación, aunque la decisión corresponde a cada entidad y debe constar en el registro de información que exige DORA. Fuera del sector financiero, la Directiva NIS2 incluye la seguridad de la cadena de suministro entre las medidas de gestión de riesgos de su artículo 21.

Cuatro preguntas merecen entrar en la próxima revisión de proveedores críticos:

• ¿Admite el servicio inicio de sesión federado con nuestro proveedor de identidad, y lo usamos? Con cuentas locales, la política de contraseñas, el MFA y la revocación de sesiones dependen del proveedor.
• ¿Podemos limitar ya las claves de API por IP de origen y ponerles fecha de caducidad?
• ¿Por qué canal y en qué plazo nos avisará el proveedor, y quién recibe ese aviso fuera del horario laboral?
• ¿Tenemos un procedimiento, probado al menos una vez, para rotar en pocas horas todas las credenciales de un proveedor?

A esas preguntas se suma una regla interna: el aviso de brecha de un proveedor debe tener un responsable con nombre en el procedimiento de respuesta a incidentes, que lo relee en cada actualización hasta el cierre formal y reabre las decisiones cuando cambia el alcance. Ya vimos que tres de cada cuatro avisos de brecha no explican cómo entró el atacante. Chainalysis añade otro límite: el alcance anunciado puede crecer en días.

¿Hay datos que Chainalysis aún no haya explicado?

Sí. A 9 de noviembre, Chainalysis no ha explicado la vía de entrada inicial, el punto donde se produjo la interceptación, el algoritmo de los hashes, la vida útil de los tokens expuestos ni de qué tipo eran, y no ha atribuido el ataque. Tampoco ha publicado cuántas cuentas de KYT sufrieron accesos no autorizados, y su última actualización, del 7 de noviembre, no confirma el regreso de Data Solutions.

El aviso del 30 de octubre era coherente con lo que se sabía ese día, pero las decisiones tomadas con él se volvieron obsoletas cinco días después. Lo que el cliente controla es otra cosa: tener inventariadas sus integraciones, poder rotar claves sin improvisar y asignar a alguien la vigilancia del aviso. Quien ya tenía ese inventario pudo dedicar la semana a rotar credenciales; quien no, tuvo que empezar por averiguar cuáles tenía.

Fuentes y atribución: este análisis se basa en las actualizaciones públicas de Chainalysis entre el 30 de octubre y el 7 de noviembre de 2026 y en la cobertura de BleepingComputer, The Register, The Hacker News y The Block, con la información disponible a 9 de noviembre de 2026. La empresa ha divulgado el incidente por sí misma. Las expresiones «técnicas agénticas ofensivas» y «ataque en ruta» proceden de ella; la vía de entrada y la autoría siguen sin aclararse, así que esta información puede cambiar.

Aviso: las comprobaciones y cláusulas propuestas son orientativas y deben adaptarse al contrato y al entorno de cada organización. Las referencias a DORA y NIS2 tienen carácter informativo y no constituyen asesoramiento jurídico.