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.
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
- 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.
- 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.
- 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.
- Alcance mínimo por credencial. Una credencial, una función, un cliente. Si una se quema, no debería arrastrar a las demás.
- 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.