Los atacantes ya no necesitan hacer ruido para comprometer una empresa. Muchas veces no entran desplegando malware, explotando una vulnerabilidad crítica o lanzando una campaña visible de ransomware desde el primer minuto. Entran con una cuenta válida, una contraseña robada, un acceso VPN olvidado, una sesión cloud sin MFA o una llamada convincente al helpdesk. Y cuando eso ocurre, gran parte de la seguridad tradicional llega tarde.
El último informe global de Kaspersky Security Services vuelve a señalar esta tendencia: las técnicas basadas en credenciales e identidad figuran entre las más efectivas observadas en 2025. En su análisis, la adivinación de contraseñas aparece con una tasa de conversión a incidente confirmado del 34,8 %, seguida muy de cerca por la creación de cuentas locales, con un 34,7 %, y el abuso de cuentas válidas, con un 34,5 %. La manipulación de cuentas alcanza el 32 % y el descubrimiento de servicios de red, el 31,2 %.
El problema: una cuenta legítima parece una cuenta legítima
El abuso de credenciales funciona porque se parece demasiado a la actividad normal. Un EDR puede detectar un binario sospechoso, un antivirus puede bloquear una muestra conocida y un firewall puede cortar una conexión extraña. Pero cuando el atacante inicia sesión con un usuario real, desde un servicio corporativo y usando herramientas administrativas legítimas, la señal es mucho más débil.
La técnica no es nueva, pero su eficacia sigue siendo alta porque muchas empresas arrastran los mismos fallos: contraseñas reutilizadas, cuentas antiguas activas, MFA incompleto, servicios expuestos, usuarios con más privilegios de los necesarios y baja visibilidad sobre cambios de identidad. Kaspersky interpreta este patrón como un desplazamiento estratégico: menos malware ruidoso y más acceso legítimo reutilizado para evitar detección.
MITRE ATT&CK describe esta técnica como el uso de cuentas válidas para obtener acceso inicial, persistencia, escalada de privilegios o evasion. Su peligro está precisamente en que el atacante no siempre necesita romper nada. Puede autenticarse, moverse, consultar recursos y ampliar control con credenciales que el sistema acepta como buenas.
| Técnica destacada por Kaspersky | Tasa de conversión |
|---|---|
| Adivinación de contraseñas | 34,8 % |
| Creación de cuentas locales | 34,7 % |
| Abuso de cuentas válidas | 34,5 % |
| Manipulación de cuentas | 32,0 % |
| Descubrimiento de servicios de red | 31,2 % |
La creación de cuentas locales es un ejemplo claro de persistencia. Una vez dentro, el atacante puede generar un usuario nuevo para no depender del acceso inicial. Si se desactiva la cuenta comprometida, el intruso conserva otra puerta. La manipulación de cuentas sigue la misma lógica: reactivar usuarios deshabilitados, añadir pertenencia a grupos privilegiados o modificar permisos sin desplegar herramientas externas.
Cuatro ejemplos reales que explican el riesgo
El caso Colonial Pipeline sigue siendo una lección básica para cualquier equipo de seguridad. En 2021, su consejero delegado explicó ante el Senado de Estados Unidos que los atacantes accedieron mediante una contraseña robada asociada a un sistema VPN heredado sin autenticación multifactor. No fue un exploit sofisticado contra una tecnología desconocida. Fue una cuenta con un único factor de autenticación en una infraestructura crítica.
Microsoft vivió otro ejemplo relevante en 2024 con Midnight Blizzard, el grupo también conocido como Nobelium o APT29. Según la propia compañía, los atacantes utilizaron password spray contra una cuenta heredada de un tenant de prueba no productivo que no tenía MFA. Desde ahí, el incidente escaló hasta permitir acceso a correos corporativos. La lección es incómoda: los entornos “no productivos” también forman parte de la superficie de ataque.
El incidente de Snowflake en 2024 mostró otro ángulo del mismo problema. Mandiant identificó una campaña de robo de datos y extorsión contra instancias de clientes de Snowflake, atribuida a UNC5537, en la que se usaron credenciales robadas, en muchos casos obtenidas mediante malware infostealer. Mandiant señaló que las cuentas comprometidas no solían tener MFA habilitado y que no había indicios de que la actividad se debiera a una brecha en la plataforma de Snowflake. El punto educativo es importante: en SaaS, la seguridad del proveedor no compensa una identidad de cliente mal protegida.
Los ataques de ingeniería social contra helpdesks añaden otra capa. Okta alertó en 2023 de una campaña en la que atacantes llamaban a personal de soporte para convencerlo de restablecer todos los factores MFA de usuarios con privilegios elevados. Una vez logrado el acceso a cuentas de superadministrador, los atacantes abusaban de funciones legítimas de federación de identidad para suplantar usuarios dentro de la organización. No hacía falta vulnerar Okta como producto: bastaba con manipular el proceso de soporte.
Estos ejemplos tienen algo en común. El atacante no entra siempre por donde el equipo espera. Puede aprovechar una cuenta vieja, un tenant olvidado, una credencial filtrada, un portátil infectado por un infostealer o un operador de helpdesk presionado por una llamada urgente. Por eso la defensa ya no puede centrarse solo en endpoints y perímetro.
Señales que un SOC no debería ignorar
El abuso de credenciales rara vez aparece como un único evento espectacular. Suele construir una cadena. Primero hay intentos fallidos de acceso. Luego una autenticación correcta desde una ubicación nueva. Después, exploración de servicios internos. Más tarde, cambios de grupos, creación de usuarios, registro de nuevos dispositivos MFA o uso anómalo de herramientas administrativas.
Un SOC debería tratar estas señales como piezas de una misma historia. Una cuenta local creada fuera de horario puede no ser grave si la ha creado un administrador conocido durante una ventana de mantenimiento. Pero si aparece después de varios intentos fallidos, desde una IP inusual y seguida de consultas a recursos internos, el contexto cambia por completo.
También conviene vigilar los cambios de identidad con más atención que antes: reseteos de MFA, incorporación de nuevos dispositivos, reactivación de cuentas deshabilitadas, cambios en roles privilegiados, creación de aplicaciones OAuth, generación de tokens API, cambios en reglas de correo, nuevas claves SSH, nuevos secretos en repositorios y accesos a consolas cloud desde ubicaciones no habituales.
En entornos híbridos, el reto se complica. Una empresa puede tener Active Directory local, Entra ID, Okta, Google Workspace, AWS IAM, cuentas de SaaS críticas, VPN y herramientas de administración remota. Si cada sistema registra eventos por separado y nadie los correlaciona, el atacante puede avanzar por huecos de visibilidad.
Qué controles ayudan de verdad
El primer paso es asumir que la identidad es una superficie de ataque principal. MFA debe ser obligatorio, especialmente en accesos remotos, cuentas privilegiadas, paneles cloud, SaaS críticos y herramientas administrativas. Pero MFA por sí solo no basta, como demuestran los ataques contra helpdesks. Hay que proteger también los procesos de restablecimiento, alta de dispositivos y recuperación de cuentas.
La segunda medida es reducir privilegios. Las cuentas administrativas permanentes deberían ser excepcionales. El acceso privilegiado debe estar limitado por tiempo, justificado, registrado y revisado. Las cuentas locales tienen que inventariarse y monitorizarse. Las cuentas inactivas deben deshabilitarse de verdad y comprobarse periódicamente.
La tercera es controlar el comportamiento, no solo la autenticación. Un inicio de sesión correcto puede ser malicioso. Por eso importan las reglas de detección basadas en riesgo: ubicación extraña, ASN desconocido, imposible travel, cambio de dispositivo, acceso fuera de horario, actividad anómala tras reset de MFA o uso de herramientas administrativas por usuarios que nunca las emplean.
La cuarta es proteger las credenciales en los puestos de usuario. Las campañas como la de Snowflake muestran el impacto de los infostealers. Un equipo comprometido puede robar tokens de sesión, claves guardadas en navegadores, credenciales de herramientas cloud o accesos a plataformas corporativas. La higiene del endpoint sigue siendo necesaria, pero debe conectarse con la protección de identidad.
La quinta es probar los procedimientos humanos. El helpdesk no puede ser el atajo que salta todos los controles técnicos. Los procesos de recuperación de cuentas deben incluir verificación fuerte de identidad, aprobación adicional para usuarios privilegiados, bloqueo temporal ante señales extrañas y alertas cuando se restablecen factores MFA de cuentas sensibles.
La conclusión para administradores, equipos SOC y responsables de seguridad es clara: si un atacante puede entrar con una cuenta válida, crear otra cuenta, elevar privilegios y moverse por la red sin ser detectado, el problema no es solo de contraseñas. Es de arquitectura de identidad, telemetría y respuesta.
La defensa moderna debe partir de una idea incómoda: una credencial válida no demuestra que el usuario sea legítimo. Solo demuestra que alguien ha superado una puerta. Lo importante empieza justo después: entender quién actúa, desde dónde, con qué patrón, sobre qué recursos y con qué intención.
Preguntas frecuentes
¿Qué es el abuso de credenciales en ciberseguridad?
Es el uso de cuentas legítimas, robadas o comprometidas, para acceder a sistemas corporativos y operar como si el atacante fuera un usuario autorizado.
¿Por qué el abuso de credenciales es difícil de detectar?
Porque muchas acciones parecen normales: inicio de sesión, acceso a aplicaciones, cambios de permisos o uso de herramientas administrativas. La detección depende del contexto y la correlación.
¿MFA evita por completo estos ataques?
No. MFA reduce mucho el riesgo, pero debe acompañarse de protección del helpdesk, control de dispositivos, detección de anomalías, mínimo privilegio y revisión de cuentas.
¿Qué ejemplos reales muestran este problema?
Colonial Pipeline, Microsoft Midnight Blizzard, las campañas contra clientes de Snowflake y los ataques de ingeniería social contra tenants de Okta muestran cómo credenciales, cuentas antiguas o procesos de soporte débiles pueden abrir la puerta a incidentes graves.
vía: Open Security
