Cuando unas credenciales robadas abren la puerta a información sensible, debemos plantear dos preguntas: ¿a quién dejamos entrar y qué le permitimos hacer una vez dentro?
Comenzó con algo que hacemos todos los días. Confiar en alguien.
Imagina que estás en el trabajo y alguien se comunica contigo diciendo que pertenece al departamento de TI de tu empresa.
Suena profesional. Sabe lo suficiente de tu organización como para parecer legítimo. Te dice que hay un problema con tu cuenta y que necesita tu ayuda para resolverlo.
Tú colaboras.
Después de todo, es de TI. ¿Verdad?
Solo que no lo es.
Y lo que parece una interacción habitual puede convertirse en el inicio de una falla de seguridad extraordinaria.
Según un informe de noviembre de 2026 de DataBreachToday, un ciberataque contra Marathon Health pudo afectar a casi 5.7 millones de personas.
La secuencia reportada es inquietantemente sencilla. Un atacante se hizo pasar por un trabajador de TI, obtuvo las credenciales de un empleado y las utilizó para acceder a una aplicación alojada en la nube. Posteriormente se exportó información.
Piensa en eso.
Casi 5.7 millones de personas potencialmente afectadas.
No necesariamente porque alguien explotara una vulnerabilidad de software hasta entonces desconocida.
No necesariamente porque el atacante venciera todos los controles de seguridad que protegían a la organización.
Sino porque un atacante logró aprovecharse de la confianza, obtener credenciales y acceder a información sensible.
Y eso plantea una pregunta que no hacemos con suficiente frecuencia.
Cuando alguien presenta credenciales válidas, ¿estamos verificando a la persona o simplemente confiando en las credenciales?
Una credencial válida no convierte a alguien en legítimo
Durante décadas, buena parte de la seguridad digital ha funcionado bajo una suposición sencilla.
Si alguien proporciona el nombre de usuario y la contraseña correctos, debe ser la persona autorizada para utilizarlos.
Las credenciales coinciden. El sistema abre la puerta.
Pero hay una falla evidente en ese razonamiento.
¿Y si las credenciales fueron robadas?
El sistema puede reconocer perfectamente la contraseña. Lo que no necesariamente puede reconocer es que quien la introduce es un impostor.
Saber la contraseña de alguien no te convierte en esa persona.
Sin embargo, los atacantes han construido toda una industria en torno a explotar precisamente esa distinción.
¿Para qué pasar semanas intentando superar defensas de seguridad sofisticadas si puedes convencer a alguien de que te entregue las llaves?
El phishing, la suplantación, el robo de credenciales y la ingeniería social funcionan porque las personas y los sistemas a veces confunden familiaridad con legitimidad.
Y en el incidente de Marathon Health, el uso reportado de credenciales comprometidas ilustra cómo un atacante puede aprovechar un proceso legítimo de autenticación para obtener acceso no autorizado.
Las credenciales podían ser válidas.
La persona que las utilizaba no lo era.
Pero hay otra parte de esta historia que merece la misma atención.
Una AUTH no basta. Y tampoco un inicio de sesión correcto.
Según los reportes, el atacante no se limitó a entrar en una aplicación alojada en la nube.
Se exportó información.
Son dos hechos distintos y deberían plantear dos preguntas de seguridad diferentes.
La primera es la autenticación.
¿Quién eres? ¿Puedes demostrar que eres quien dices ser?
La segunda es la autorización.
Ahora que has establecido una identidad, ¿a qué tienes realmente permitido acceder o qué puedes hacer?
Es una distinción que suena técnica, pero el principio es muy sencillo.
Piensa en entrar a un edificio de oficinas.
Tu credencial de empleado puede permitirte pasar por la puerta principal. Eso es autenticación.
Pero eso no significa que también deba abrir las oficinas ejecutivas, el departamento de nómina, la sala de servidores y todos los archiveros cerrados.
Esos permisos son una cuestión de autorización.
E incluso si tienes permiso para entrar al departamento de nómina, eso no significa necesariamente que debas poder salir cargando los expedientes confidenciales de todos los empleados.
Pasar por la puerta principal nunca debería significar tener acceso sin restricciones a todo lo que hay dentro.
Ahora aplica ese mismo razonamiento al incidente de Marathon Health.
Según se informó, un atacante obtuvo credenciales legítimas de un empleado y accedió a una aplicación.
La primera decisión de seguridad no logró distinguir al atacante del empleado autorizado.
Pero ¿qué ocurrió con la segunda?
¿A qué información tenía permitido acceder esa cuenta? ¿Qué restricciones se aplicaban a la exportación de datos? ¿Las acciones especialmente sensibles estaban sujetas a verificación adicional?
La información pública no permite responder todas esas preguntas.
Pero son precisamente las preguntas que deberían hacerse las organizaciones.
Porque autenticación y autorización no son lo mismo.
Y una autenticación correcta nunca debería interpretarse como autorización ilimitada.
Autorización: la decisión de seguridad que continúa después del inicio de sesión
Aquí es donde la distinción cobra especial importancia.
Los sistemas tradicionales de autorización suelen asignar permisos según la función de un empleado.
Un contador puede acceder a registros financieros.
Un profesional de la salud puede acceder a determinada información de pacientes.
Un administrador puede tener privilegios más amplios en los sistemas.
Eso tiene sentido.
Pero considera qué ocurre cuando un atacante compromete una cuenta que ya tiene derechos legítimos de acceso.
El atacante puede heredar esos mismos permisos.
Si el empleado puede exportar registros sensibles, el atacante quizá también pueda hacerlo.
Por eso la autorización no puede ser simplemente una lista estática de permisos que se establece una vez y después se olvida.
Debe poder evaluar qué intenta hacer alguien, la sensibilidad de la información involucrada y si la acción es adecuada dadas las circunstancias.
Por ejemplo, un empleado que normalmente consulta registros individuales podría intentar de pronto descargar miles.
Una solicitud podría provenir de un dispositivo desconocido.
Una sesión podría mostrar un comportamiento inusual.
O alguien podría intentar una operación técnicamente permitida por su función, pero incompatible con sus responsabilidades habituales.
Esas circunstancias deberían importar.
Las organizaciones pueden aplicar permisos de mínimo privilegio, restringir exportaciones masivas, evaluar el riesgo de sesiones y dispositivos, y exigir una verificación más sólida antes de operaciones especialmente sensibles.
En algunos casos, la respuesta adecuada es denegar la acción por completo.
Hay otra salvaguarda importante que merece consideración. Para operaciones especialmente sensibles, la autorización puede exigir una nueva verificación de la presencia del usuario legítimo mediante un mecanismo de autenticación confiable y vinculado a su dispositivo. Esto puede incluir una comprobación biométrica realizada localmente en el dispositivo del usuario, que permita utilizar una credencial criptográfica protegida sin exponer el dato biométrico a la aplicación.
Piensa en lo que eso significa para un atacante que ha robado las credenciales de acceso de alguien. Aunque esas credenciales permitan el acceso inicial, quizá no basten para autorizar la extracción de información sensible. Sin acceso al dispositivo confiable del usuario legítimo ni la capacidad de cumplir sus requisitos de verificación, el atacante podría encontrarse con que se deniega precisamente la acción que pretendía realizar. La primera decisión de seguridad puede haberse visto comprometida, pero la segunda ofrece una oportunidad independiente de detener el ataque.
Por supuesto, ningún sistema de autorización puede garantizar que se detectará toda acción maliciosa. Una cuenta comprometida todavía puede utilizarse para realizar actividades que estén dentro de sus permisos legítimos.
Pero eso no es un argumento contra la autorización.
Es un argumento a favor de hacerla más precisa, contextual y sensible al riesgo.
La autenticación determina si una identidad puede entrar. La autorización determina qué puede hacer esa identidad.
Ambas decisiones importan.
Y ninguna debería tratarse como un ejercicio de confianza que se realiza una sola vez.
Hay otro problema. ¿Quién autentica a la otra parte?
Hasta ahora hemos examinado qué ocurre cuando un atacante presenta credenciales robadas y accede a un sistema.
Pero volvamos al comienzo del incidente de Marathon Health.
Según se informó, el atacante se hizo pasar por un trabajador de TI.
Antes de que se robaran las credenciales, alguien tuvo que creer que la persona que las solicitaba era legítima.
Eso nos lleva a una cuestión más amplia.
Dedicamos enormes cantidades de tiempo y dinero a pedir a los usuarios que demuestren su identidad.
- Contraseñas.
- Códigos de verificación.
- Aplicaciones de autenticación.
- Biometría.
- Preguntas de seguridad.
Pero ¿con qué frecuencia hacemos la otra pregunta, igual de importante?
¿Qué ha hecho la persona, el sitio web o la aplicación que solicita nuestras credenciales para demostrarnos su propia identidad?
Piensa en la última vez que entraste a tu cuenta bancaria.
Se esperaba que demostraras quién eras.
Pero ¿cómo estableciste que realmente te estabas comunicando con tu banco?
¿Verificaste el destino de manera independiente o confiaste en el sitio porque te resultaba familiar?
Los atacantes comprenden este desequilibrio.
Crean páginas de acceso convincentes. Suplantan a empleados de confianza. Envían mensajes que parecen provenir de organizaciones legítimas.
Saben que las personas están acostumbradas a responder cuando alguien que afirma tener autoridad les pide autenticarse.
Y esa es la debilidad fundamental de la confianza unilateral.
Exigimos pruebas al usuario mientras, con demasiada frecuencia, esperamos que dé por sentada la legitimidad de quien se las pide.
Eso no es una relación de confianza equilibrada.
Y ciertamente no es la base sobre la que deberíamos construir el futuro de la identidad digital.
La Confianza Mutua cambia la conversación
La confianza debería ser una relación de dos vías.
Lo entendemos instintivamente en el mundo físico.
Si alguien toca a tu puerta diciendo que representa a tu banco, no lo invitas automáticamente a entrar porque sabe tu nombre.
Haces preguntas.
Pides identificación.
Quizá llamas al banco a un número que sabes por tu cuenta que es legítimo.
Verificas antes de confiar.
Sin embargo, en el mundo digital a menudo se nos pide hacer lo contrario.
- Haz clic en el enlace.
- Introduce tu contraseña.
- Aprueba la notificación.
- Proporciona el código.
Y da por sentado que la parte que solicita toda esa información es legítima.
No tiene por qué funcionar así.
La Autenticación Mutua establece la legitimidad de ambas partes que participan en un intercambio de autenticación digital.
El usuario demuestra su identidad al servicio.
El servicio demuestra su identidad al usuario o al mecanismo de autenticación confiable del usuario.
Ninguna de las partes tiene que depender únicamente de las apariencias o de una afirmación no verificada.
Los métodos modernos de autenticación criptográfica pueden ayudar a hacerlo posible sin exigir que los usuarios se conviertan en expertos en ciberseguridad.
Y cuando esos métodos son resistentes al phishing, pueden dificultar considerablemente que los atacantes capturen o reutilicen credenciales de autenticación mediante sitios fraudulentos.
Pero la Autenticación Mutua no es una solución universal contra la suplantación.
Una conexión criptográficamente verificada con una aplicación legítima no demuestra automáticamente que alguien que dice ser empleado de TI por teléfono sea legítimo.
Esas interacciones requieren sus propios procedimientos confiables de verificación.
Sin embargo, el principio sigue siendo el mismo.
No debería esperarse que nadie entregue información sensible ni conceda acceso simplemente porque la otra parte afirma ser confiable.
La identidad debe establecerse.
Y ambas partes deben ganarse la confianza.
La MFA es importante. Pero más autenticación no significa automáticamente más confianza.
La autenticación multifactor ha hecho una contribución importante a la ciberseguridad.
Exigir un factor adicional a la contraseña puede reducir considerablemente el riesgo de acceso no autorizado a las cuentas.
Pero no todos los métodos MFA ofrecen la misma resistencia a los ataques.
Algunos códigos de verificación pueden capturarse mediante phishing.
Algunas solicitudes de autenticación pueden manipularse mediante ingeniería social.
Cierta información de sesión puede robarse después de la autenticación.
Y un evento MFA correcto no significa necesariamente que deba confiarse en cada acción posterior.
Por eso creo que debemos dejar de pensar en la autenticación como una colección de obstáculos que los usuarios deben superar.
Añadir más pasos no equivale a establecer mayor confianza.
Un enfoque más sólido combina autenticación resistente al phishing, verificación adecuada del servicio, protecciones del dispositivo y de la sesión, y controles de autorización que reflejen la sensibilidad de la acción solicitada.
El objetivo no es dificultar cada inicio de sesión.
El objetivo es dificultar la suplantación y hacer más difícil completar acciones no autorizadas.
Son objetivos muy distintos.
Y conducen a una conversación mucho más productiva sobre seguridad.
La confianza no debería terminar en la pantalla de inicio de sesión
Esta es la lección más amplia que extraigo del incidente de Marathon Health.
La seguridad no es una única decisión que se toma cuando alguien introduce un nombre de usuario y una contraseña.
Es una serie de decisiones a lo largo de una interacción digital.
- ¿Quién solicita acceso?
- ¿Es legítima esa identidad?
- ¿Es legítimo el propio servicio?
- ¿Qué información se está solicitando?
- ¿Está autorizada la acción solicitada?
- ¿Justifica el contexto un examen adicional?
Estas preguntas no deberían desaparecer simplemente porque un inicio de sesión fue correcto.
Considera cómo podría ser una seguridad más sólida.
- Un usuario se autentica mediante un método resistente al phishing que no expone credenciales reutilizables.
- El proceso de autenticación verifica que el usuario se comunica con el servicio legítimo.
- La organización concede únicamente los permisos necesarios para las responsabilidades del usuario.
- Cuando se solicita información especialmente sensible, los controles de autorización evalúan si esa acción es adecuada.
- Y cuando las circunstancias indican un riesgo inusual, el sistema puede exigir verificación adicional, restringir el acceso o denegar la operación.
Nada de esto garantiza que se evitarán todos los ataques.
Pero reduce el número de suposiciones de las que puede depender un atacante.
Y, quizá lo más importante, cambia nuestra forma de pensar sobre la confianza.
La confianza no es un privilegio permanente que se otorga al iniciar sesión. Es una relación que debe establecerse, protegerse y reevaluarse cuando las circunstancias lo justifiquen.
Esa es una base mucho más sólida para la seguridad digital.
Detrás de 5.7 millones de registros hay 5.7 millones de personas
Es fácil volverse insensible a los titulares sobre ciberseguridad.
Otra filtración.
Otra cuenta comprometida.
Otra organización que investiga un acceso no autorizado.
Otra cifra medida en millones.
Pero detrás del incidente reportado de Marathon Health hay casi 5.7 millones de personas cuya información personal pudo verse afectada.
Personas que confiaron información sensible a una organización con la expectativa razonable de que estaría protegida.
Personas que quizá ahora deban monitorear sus cuentas, estar atentas a comunicaciones sospechosas o preocuparse por el uso indebido de su información.
La mayoría no tuvo nada que ver con la interacción que, según se informó, permitió al atacante acceder.
No respondieron al impostor.
No revelaron las credenciales.
No autorizaron la exportación.
Y aun así pueden enfrentar las consecuencias.
Por eso creo que esta conversación trata de algo más que tecnología de autenticación.
Trata de responsabilidad.
Cuando las organizaciones recopilan y mantienen información sensible, asumen la obligación de protegerla.
Y cumplir esa obligación requiere más que comprobar si alguien tiene la contraseña correcta.
Requiere decisiones cuidadosas sobre identidad, acceso, autorización y legitimidad de las partes involucradas.
La confianza no es simplemente una función de ciberseguridad. Es una responsabilidad que tenemos con las personas cuya información conservamos.
Dos AUTH. Un principio fundamental.
El incidente de Marathon Health ilustra por qué debemos cuestionar algunas suposiciones arraigadas sobre la seguridad digital.
Una credencial válida no significa necesariamente que quien la presenta sea legítimo.
Un inicio de sesión correcto no significa necesariamente que deba permitirse cada acción posterior.
Y una solicitud de autenticación no significa automáticamente que la persona o el servicio que la realiza sea confiable.
Son tres problemas diferentes, pero comparten un mismo hilo conductor.
La confianza no puede basarse únicamente en la posesión, las apariencias o las suposiciones.
La autenticación debe establecer la identidad.
La autorización debe determinar qué puede hacer esa identidad.
La Autenticación Mutua debe ayudar a garantizar que ambas partes del intercambio de autenticación sean legítimas.
Y los controles adecuados deben seguir protegiendo la información sensible después del acceso inicial.
No podemos afirmar con certeza que una sola de estas medidas hubiera evitado el incidente de Marathon Health. Los hechos reportados públicamente no respaldan esa conclusión.
Pero sí podemos decir que el incidente plantea preguntas importantes sobre cómo las organizaciones establecen y hacen cumplir la confianza.
Y esas preguntas merecen respuestas serias.
Durante demasiado tiempo nos hemos concentrado en mejorar la forma de pedir a las personas que demuestren quiénes son.
Ahora debemos tomar con la misma seriedad la verificación de quién lo pide, qué acceso está justificado y qué acciones deben permitirse.
Porque una credencial puede abrir una puerta.
Pero no puede, por sí sola, decirnos quién la está cruzando.
E incluso cuando alguien ha entrado legítimamente al edificio, eso no significa que deba tener las llaves de todas las habitaciones.
Una AUTH no basta™.
Y tampoco la confianza unilateral.
La confianza comienza aquí™.