--- title: "Clonaron la voz de un compañero por teléfono y comprometieron 27 cuentas de clientes de Retool" description: "Atacantes clonaron la voz de un empleado de Retool, pidieron un código de doble factor por teléfono y comprometieron 27 cuentas de clientes del sector cripto." slug: "legal-retool" url: "https://catalizadora.ai/blog/legal-retool" cluster: "casos-ia" author: "Pablo Estrada" published_at: "2026-08-26T22:39:42.809+00:00" updated_at: "2026-08-26T22:39:43.054431+00:00" read_minutes: "7" lang: "es" --- # Clonaron la voz de un compañero por teléfono y comprometieron 27 cuentas de clientes de Retool > Atacantes clonaron la voz de un empleado de Retool, pidieron un código de doble factor por teléfono y comprometieron 27 cuentas de clientes del sector cripto. ## Qué pasó Alguien llamó por teléfono a un empleado de Retool. Del otro lado sonaba la voz de un compañero de trabajo. En el transcurso de la llamada, ese «compañero» pidió un código de doble factor. El empleado lo dictó. La voz era sintética. Con ese código, los atacantes entraron y terminaron comprometiendo 27 cuentas de clientes, todas del sector cripto. Un reporte posterior vinculó el incidente con el robo de 15 millones de dólares. Retool atribuyó el alcance de la brecha a la función de sincronización en la nube de Google Authenticator, según [BleepingComputer](https://www.bleepingcomputer.com/news/security/retool-blames-breach-on-google-authenticator-mfa-cloud-sync-feature/). Vale la pena separar las dos mitades del caso: una voz clonada abrió la puerta, y una configuración de alcance decidió cuántas habitaciones había detrás de esa puerta. ## Por qué pasó Un segundo factor existe para que robar la contraseña no alcance. Todo su valor descansa sobre una suposición: que ese código solo puede estar en manos de quien lo generó. En el momento en que el código se puede pedir hablando, la suposición se cae, y con ella el factor. Durante décadas el teléfono funcionó como prueba de identidad porque imitar la voz de una persona conocida era difícil. Ya no lo es. Lo que cambió no es la seguridad del código: es que el canal por el que se pedía dejó de probar nada. El procedimiento interno, en cambio, siguió igual. Ese desfase es el fallo, y es de proceso, no de tecnología. Hay una segunda capa. Un solo código no debería abrir 27 puertas. Cuando el alcance de una credencial es más ancho que la tarea que autoriza, un error puntual de una persona se convierte en un incidente que toca a decenas de clientes. ## Dónde te puede pasar a ti - Una mesa de ayuda que restablece contraseñas o desvincula el doble factor con una llamada y dos datos que están públicos en LinkedIn. - Cambios de cuenta bancaria de un proveedor confirmados «por teléfono con el contacto de siempre». - Un audio de WhatsApp del director pidiendo algo urgente fuera de horario. - Un código de acceso a un sistema compartido dictado por llamada porque la otra persona «va manejando». - Un técnico externo que pide credenciales para «resolver una incidencia» y suena exactamente como el técnico de siempre. Nada de esto exige que tu empresa use inteligencia artificial. Exige que alguien más la use. ## Cómo se evita 1. **Regla sin excepciones: los códigos y las aprobaciones no viajan por voz.** Ni por llamada, ni por audio, ni en videollamada. Si un código se dictó, ese código se cancela. 2. **Verificación de vuelta por otro canal, iniciada por quien recibe la petición.** No devuelvas la llamada al número que te llamó: busca a la persona en el directorio interno y llámala tú, o confírmalo por el canal corporativo. 3. **Factores resistentes al phishing** —llaves físicas o passkeys— en las cuentas administrativas. No hay nada que dictar, porque el factor está atado al dispositivo y al dominio. 4. **Alcance mínimo por credencial.** Una credencial, una función, un cliente. Si una se quema, no debería arrastrar a las demás. 5. **Ventana de espera para cambios sensibles:** alta de cuenta bancaria nueva, desvinculación del doble factor, cambio de correo de recuperación. Unas horas de retraso obligatorio desactivan la urgencia, que es la única herramienta real del atacante. ## Cómo lo hacemos en Catalizadora En los sistemas que operamos, ninguna credencial ni segundo factor se transmite por voz ni por chat: los secretos entran por un flujo propio que los propaga a los gestores, y su valor nunca pasa por una conversación. Los accesos administrativos usan llave atada al dispositivo, y cada credencial queda acotada a un solo proyecto: si una se quema, no arrastra a los demás clientes. Los cambios sensibles quedan registrados con autor y fecha. ## Preguntas frecuentes ### ¿Cómo entraron los atacantes a Retool? Llamaron por teléfono a un empleado usando la voz clonada de un compañero de trabajo y le pidieron un código de doble factor. Con ese código llegaron a comprometer 27 cuentas de clientes del sector cripto. ### ¿Cuánto dinero se vinculó al incidente? Un reporte vinculó el caso con el robo de 15 millones de dólares. Las 27 cuentas comprometidas eran todas del sector cripto. ### ¿Sigue sirviendo el doble factor? Sí, pero deja de proteger en el momento en que el código se puede pedir hablando. Los factores resistentes al phishing, como las llaves físicas o las passkeys, no tienen nada que dictar por teléfono. ### ¿Cuál es la regla más simple para no caer? Que ningún código ni aprobación viaje por voz. Y que la verificación de vuelta la inicie quien recibe la petición, buscando a la persona en el directorio interno, nunca devolviendo la llamada al número que llamó. --- Source: https://catalizadora.ai/blog/legal-retool Author: Pablo Estrada — AI Catalysts, LLC (catalizadora.ai)