El fin de semana del 7 y 8 de febrero de 2026, unos delincuentes accedieron a los sistemas de clientes del operador de telecomunicaciones neerlandés Odido. No mediante un exploit técnico sofisticado, sino a través de personas: primero un correo de phishing para robar las contraseñas de los agentes de atención al cliente, y luego una llamada en la que el atacante se hacía pasar por el departamento de IT interno para sortear el paso de inicio de sesión adicional. El resultado: datos de unos 6,2 millones de clientes (y exclientes) de Odido y su marca Ben — casi toda la base de clientes.
Qué ocurrió exactamente
Odido hizo pública la brecha el 12 de febrero de 2026; el ataque tuvo lugar el fin de semana anterior. Dos semanas después, el 26 de febrero, los delincuentes publicaron parte del botín en la dark web: datos de unas 430 000 personas y 290 000 clientes empresariales.
El conjunto de datos robado era excepcionalmente sensible. Incluía no solo nombres, direcciones, teléfonos, correos y números de cliente, sino también números de cuenta IBAN, fechas de nacimiento y datos de identificación. Algunas notas internas mencionaban incluso acoso, violencia doméstica y direcciones protegidas — información que en malas manos puede poner en peligro la vida.
El acceso se produjo a través del entorno Salesforce que usa atención al cliente. No fue una intrusión en un servidor, sino el abuso de una cuenta válida que un agente entregó él mismo. Bajo el RGPD, una brecha así debe notificarse a la autoridad de control (en España, la AEPD) en un plazo de 72 horas.
Por qué atención al cliente era el objetivo
Los atacantes eligen el camino de menor resistencia. Atención al cliente — a menudo parcialmente externalizada a centros de llamadas — accede a diario a grandes volúmenes de datos de clientes, pero suele recibir menos atención de seguridad que los administradores de IT o los desarrolladores.
Además, ayudar es el trabajo de un agente. Quien se entrena todo el día para ser amable y resolutivo coopera de forma natural cuando 'un compañero de IT' llama con una petición urgente. Esa disposición a ayudar no es una debilidad individual, sino un rasgo que los atacantes explotan a propósito.
Para los responsables de concienciación, esta es la lección central: quienes manejan más datos de clientes no siempre son quienes reciben más formación. Es una brecha que hay que cerrar de forma deliberada.
La MFA no es la meta: así se sorteó el paso adicional
Muchas organizaciones creen que la autenticación multifactor (MFA) las protege de las contraseñas robadas. Es cierto — hasta que una persona aprueba el paso MFA por sí misma. En Odido, el atacante llamó al agente tras el correo de phishing, se hizo pasar por el soporte de IT y pidió confirmar el intento de inicio de sesión. El agente aprobó la notificación y entregó así el segundo factor.
Esto se conoce como fatiga de MFA o elusión de MFA mediante ingeniería social. La tecnología funciona bien; el proceso humano que la rodea es el punto débil. A un atacante le basta con un empleado que pulse 'aprobar' en el momento equivocado.
La MFA sigue siendo una medida básica imprescindible, pero solo si la configuras bien. ¿Quieres saber qué formas de MFA resisten este tipo de ataque y cómo implementarlas? Lee cómo implementar la MFA en tu organización.
La regla que todos deben conocer: el IT real nunca pide tu contraseña, tu código MFA ni que apruebes un inicio de sesión que no iniciaste tú. ¿Recibes una petición así? Cuelga y vuelve a llamar a un número interno conocido.
El daño real llega después: phishing posterior con datos reales
Una brecha no es un punto final, sino un punto de partida. Con datos reales, los delincuentes envían mensajes que cuadran: conocen tu nombre, tu número de cliente, tu operador y a veces tu IBAN. Un correo o SMS de phishing que empieza con datos correctos es mucho más convincente que el clásico 'Estimado cliente'.
Como era de esperar, tras la brecha de Odido llegó una oleada de phishing posterior: mensajes falsos 'de Odido' sobre un pago fallido o una factura pendiente, con enlace a una página de inicio de sesión clonada. Ese es el verdadero modelo de negocio detrás del robo.
Significa que una brecha en una organización eleva el riesgo para todas. Tus empleados y clientes pueden ser atacados con mayor precisión, aunque tus propios sistemas nunca se hayan visto afectados.
Cómo integrarlo en tu programa de concienciación
El incidente de Odido es un caso ideal y cercano para tu programa — precisamente porque no hubo ningún 'hackeo genial', solo una llamada y un correo.
No te centres solo en el personal de oficina. Las mayores ganancias están en los equipos que manejan muchos datos de clientes y mucho contacto entrante: atención al cliente, soporte, recepción y centros de llamadas externos.
- Público + ritmo: da a atención al cliente y soporte un módulo propio con procedimiento de devolución de llamada, y repítelo cada trimestre — la rotación es alta.
- Una regla que todos conozcan: 'IT nunca pide tu contraseña ni aprobación MFA; ante la duda, cuelga y llama al número interno.'
- Practica el escenario en vivo: una simulación de vishing (falsa llamada de IT) enseña más que un módulo de e-learning solo.
- Mide el reporte, no solo el clic: ¿cuántos empleados reportan la llamada sospechosa en 30 minutos?
- ¿Quieres profundizar? Mira cómo abordarlo de forma estructural con la formación en concienciación sobre seguridad.
Artículos relacionados
- El ataque a ChipSoft: el riesgo de proveedores en tu programa
- Marks & Spencer y Scattered Spider: el soporte como puerta de entrada
- Fugas de datos comunes en las organizaciones
Preguntas frecuentes
¿Fue la brecha de Odido un hackeo técnico?
No. Los atacantes no usaron ninguna vulnerabilidad de software, sino ingeniería social: un correo de phishing para robar contraseñas, seguido de una llamada en la que se hacían pasar por IT interno para que se aprobara el paso MFA. Fue un ataque humano, no técnico.
¿Cómo se puede sortear la MFA si está activada?
La MFA protege frente a una contraseña robada, pero no frente a un empleado que aprueba el intento de inicio de sesión. Al llamar haciéndose pasar por IT, el atacante logró que el agente confirmara el segundo factor. La tecnología funcionó; el proceso humano fue el punto débil.
¿Qué deben hacer los empleados ante una 'llamada de IT' sospechosa?
Colgar y volver a llamar a un número interno conocido. El IT real nunca pide tu contraseña, tu código MFA ni que apruebes un inicio de sesión que no iniciaste tú.
¿Por qué una brecha en otra empresa también es mi problema?
Porque con datos reales los delincuentes pueden enviar phishing posterior mucho más convincente. Tus empleados y clientes pueden ser atacados con nombres, números de cliente o datos bancarios exactos, aunque tus sistemas nunca se hayan visto afectados.