Estimados amigos de Inseguros !!!
En los dos posts anteriores ya hemos ido construyendo la idea. Viste el último?
Hoy quiero ir a la parte fea. La parte útil de verdad. Porque una cosa es decir que un rol es peligroso. Y otra muy distinta es entender qué puede hacer un atacante si compromete una cuenta con ese rol. Y aquí es donde mucha gente se da cuenta de que estaba midiendo mal el problema. Porque no hablamos solo de “una cuenta con permisos altos”. Hablamos de cuentas que pueden cambiar las reglas del juego. Eso es Tier 0.
Un atacante que entra en una cuenta normal quiere avanzar. Un atacante que entra en una cuenta Tier 0 puede rediseñar el entorno para que avanzar le resulte mucho más fácil.
Escenario 1. Compromiso de un Global Administrator
Este es el caso más evidente y también el más destructivo.
Si un atacante obtiene acceso a una cuenta Global Administrator, ya no necesita demasiada imaginación. Tiene control administrativo casi total sobre el tenant y puede empezar a construir una operación completa a su medida.
Puede resetear contraseñas.
Puede crear nuevas cuentas privilegiadas.
Puede cambiar configuraciones de seguridad.
Puede registrar persistencia.
Puede tocar políticas.
Puede alterar la administración del entorno.
En otras palabras, ya no estamos en un incidente de acceso. Estamos en un incidente de control.
Lo más grave de este escenario no es solo lo que puede hacer en el minuto uno. Lo más grave es que puede crear nuevas vías de acceso, repartir privilegios a otras cuentas y dejar preparado el terreno para seguir operando aunque le descubran una parte del acceso inicial.
Por eso, cuando alguien dice “solo tenemos unos pocos Global Admin”, mi respuesta no es “ah, perfecto”.
Mi respuesta es “vale, ahora cuéntame cómo los protegéis”.
Escenario 2. Compromiso de Application Administrator o Cloud Application Administrator
Aquí empieza una parte que muchas empresas siguen sin tomarse suficientemente en serio.
Si un atacante cae sobre una cuenta con privilegios fuertes sobre aplicaciones, puede empezar a usar Entra ID no solo como directorio, sino como plataforma de persistencia.
Puede crear una aplicación maliciosa.
Puede generar secretos o certificados.
Puede otorgarle permisos elevados.
Puede usar consentimiento administrativo.
Puede aprovechar identidades de aplicación para acceder a datos sin depender de sesiones interactivas de usuario.
Y esto tiene muy mala pinta por una razón concreta: muchas veces pasa más desapercibido que el abuso directo de una cuenta humana.
Un atacante podría, por ejemplo, crear una aplicación con permisos potentes sobre correo, ficheros o directorio, autenticarse con ella de manera silenciosa y empezar a exfiltrar datos sin necesidad de “entrar como usuario” todo el rato.
Eso es muy peligroso porque mezcla privilegio, persistencia y sigilo.
Hay mucha gente obsesionada con proteger contraseñas de usuarios privilegiados, pero no mira con el mismo respeto el plano de aplicaciones. Y eso es un error.
Escenario 3. Compromiso de Conditional Access Administrator
Este escenario es una maravilla para el atacante.
Porque aquí no se trata solo de entrar. Se trata de quitar obstáculos.
Si comprometo una cuenta con capacidad de modificar Conditional Access, puedo empezar a desmontar barreras de seguridad muy importantes del tenant.
Puedo relajar MFA.
Puedo crear exclusiones.
Puedo permitir acceso desde ubicaciones que antes estaban restringidas.
Puedo dejar fuera de control determinadas cuentas.
Puedo bloquear a administradores legítimos mientras me dejo un camino cómodo para mí.
Esto convierte a este rol en algo muy delicado.
Porque el atacante no necesita levantar demasiado ruido. Le basta con cambiar un par de políticas clave para convertir un tenant razonablemente protegido en un entorno mucho más amable para su operación.
Y además tiene una ventaja psicológica: muchas veces los cambios en políticas se entienden como “administración”, no como “ataque”, y eso puede retrasar la respuesta.
Escenario 4. Compromiso de Privileged Authentication Administrator
Este es uno de mis favoritos cuando quiero explicar que Tier 0 no va solo de quién manda más, sino de quién puede romper la confianza.
Imaginad que el atacante compromete una cuenta con este rol.
No tiene todavía el Global Administrator.
Pero puede tocar los métodos de autenticación de cuentas críticas.
Y aquí es donde la cosa se pone seria.
Podría resetear los factores MFA de una cuenta privilegiada.
Podría forzar un nuevo registro.
Podría posicionar sus propios métodos de autenticación.
Podría secuestrar el acceso de una cuenta mucho más sensible sin necesidad de romper su contraseña de forma clásica.
Es decir, no va por la puerta principal del privilegio. Va por la puerta de la autenticación.
Y una vez dentro, el resultado puede ser el mismo.
Este escenario demuestra muy bien por qué proteger el MFA no consiste solo en “tener MFA activado”. También importa muchísimo quién puede administrarlo.
Escenario 5. Compromiso de Privileged Role Administrator
Este escenario es bastante directo y por eso mismo bastante peligroso.
Si el atacante controla un rol que puede asignar privilegios, la escalada está prácticamente servida.
Puede añadirse a sí mismo a un rol más potente.
Puede dar privilegios a otra cuenta que controle.
Puede modificar la estructura administrativa del tenant.
Puede tocar elementos sensibles de PIM si el entorno está mal gobernado.
Esto significa que una cuenta que quizá sobre el papel no parece “la más poderosa” puede convertirse en el trampolín perfecto hacia el control total.
Y este es otro mensaje importante: no hace falta que el atacante robe directamente la llave maestra si puede fabricársela.
Escenario 6. Compromiso de Hybrid Identity Administrator
Aquí entramos en territorio especialmente serio para entornos híbridos.
Si un atacante compromete este rol, puede tocar la relación entre el mundo on-premise y la nube. Y eso abre escenarios muy delicados: cambios de sincronización, manipulación de confianza, alteraciones de federación, abuso del puente entre entornos.
Cuando alguien controla identidad híbrida, ya no está jugando solo con usuarios cloud. Está jugando con la arquitectura de confianza del entorno.
Y eso puede acabar en escenarios muy feos, porque además mezcla dos mundos donde la investigación puede ser más compleja: lo local y lo cloud.
Si la organización tiene sincronización, federación o dependencias híbridas relevantes, este rol merece muchísimo respeto.
Escenario 7. Compromiso de Security Administrator
Este rol a veces no se entiende bien porque no siempre da “control total instantáneo”.
Pero ojo, porque da algo que a un atacante serio le encanta: visibilidad defensiva.
Puede ver alertas.
Puede entender políticas.
Puede conocer parte de la postura de seguridad.
Puede, en ciertos contextos, suavizar o manipular elementos relacionados con detección y respuesta.
Y esto tiene un valor enorme.
Porque un atacante no solo quiere permisos. También quiere contexto.
Quiere saber qué detectas.
Quiere saber por dónde haces hunting.
Quiere saber qué actividad puede delatarle.
Quiere saber qué caminos están más vigilados y cuáles menos.
En algunos casos, controlar esta visibilidad puede ser casi tan útil como controlar directamente un privilegio más alto.
El verdadero problema: persistencia y rediseño del entorno
Aquí está el punto que me interesa remarcar.
Cuando una cuenta Tier 0 cae, el problema no es solo la acción inmediata que puede hacer el atacante.
El problema real es que puede cambiar el entorno para que el compromiso dure más, sea más difícil de detectar y resulte más costoso de erradicar.
Y por eso este tema no se arregla solo con decir “tenemos MFA” o “tenemos pocos Global Admin”.
Hace falta mucho más…
Hace falta revisar asignaciones reales.
Hace falta entender impacto.
Hace falta gobernar privilegios.
Hace falta monitorizar cambios delicados.
Hace falta separar cuentas.
Hace falta PIM.
Hace falta reducir permanencia.
Hace falta tratar ciertas cuentas como material de máxima sensibilidad.
Porque si no haces eso, el atacante no tiene que ganar muchas veces.
Le basta con acertar una.
Cómo revisaría yo esto en una auditoría* ya sabes que nosotros somos expertos en esto*
Si yo tuviera que mirar esto en un tenant, no me quedaría en un simple listado de roles.
Porque el problema no está solo en la existencia del rol. Está en cómo se usa, cómo se protege y cuánto tardarías en darte cuenta de que alguien lo ha comprometido.
Y el resumen, para mí, es bastante simple. Si una cuenta puede cambiar identidad, privilegio, autenticación o confianza, esa cuenta no es “un admin más”. Esa cuenta es una pieza nuclear del entorno. Y como tal hay que tratarla.
Si queréis aprender ciberseguridad Microsoft, hardening, identidad, defensa y auditoría práctica, podéis echar un vistazo a los cursos de la academia:
https://www.seguridadsi.com/todos-cursos
Gracias por leerme !!!
