- 1. Privilegios administrativos heredados
- 2. Vías de ataque heredadas recreadas
- 3. Divulgación de credenciales durante la migración
- 4. Uso indebido de SID-History
- 5. LCC defectuosas o excesivamente permisivas
- 6. Fallos en las cuentas de servicio y privilegios ocultos
- 7. Colisiones de identidades y asignaciones erróneas
- 8. La coexistencia que amplía el impacto de las brechas
- 9. Deficiencias en materia de cumplimiento y auditoría
- 10. Puntos ciegos forenses tras la transición
- 11. Un bosque nuevo con viejas puertas traseras
- Convierte tu migración de AD en una transformación de seguridad
- Más información sobre cómo realizar una migración de AD con éxito
La migración de tu dominio de Active Directory no ha mejorado tu seguridad. En muchos entornos, ocurre justo lo contrario.
«¿Cómo lo sabes?»
Esa es la pregunta incómoda a la que siempre vuelvo cuando hablo con organizaciones que están planificando fusiones, transiciones a la nube y proyectos de modernización.
Con demasiada frecuencia, las empresas invierten millones en un proyecto de migración y consolidación de Active Directory (AD) y lo tratan como si se tratara de un simple traslado de datos: trasladan los usuarios, los grupos y las aplicaciones a un nuevo bosque, dan el proyecto por concluido y dan por hecho que lo más difícil ya ha pasado.
Pero si se repiten los mismos errores de delegación, el anidamiento de grupos, las relaciones de confianza y las cuentas con privilegios excesivos, se pueden recrear las mismas vías de ataque en un nuevo entorno —y, en ocasiones, hacer que sean más difíciles de detectar—. Una transición limpia no implica necesariamente una postura de seguridad sólida.
A continuación, te presento once riesgos habituales que observo en las migraciones típicas de Active Directory. Si abordas la migración de Active Directory con una mentalidad que anteponga la seguridad, podrás reducir la exposición a riesgos heredados en lugar de arrastrarlos al nuevo entorno.
1. Privilegios administrativos heredados
Una migración de Active Directory puede convertirse en un motor de escalada de privilegios cuando los derechos heredados de administrador de dominio o de administrador de empresa se transfieren al entorno de destino sin ser revisados. Lo que parece una simple continuidad es, en realidad, la transferencia de antiguos errores administrativos a un nuevo entorno que debería haberse diseñado siguiendo las prácticas de seguridad actuales.
He visto cómo las migraciones han perpetuado estructuras de privilegios que databan de hace décadas. Si los antiguos privilegios perduran, los antiguos riesgos también perduran con ellos.
2. Vías de ataque heredadas recreadas
Si se mantienen los atajos de anidamiento de grupos, delegación y coexistencia sin analizar las relaciones de privilegios antes de la transición, los atacantes podrán seguir utilizando las mismas vías de movimiento lateral que ya tenían. La migración puede ser perfecta desde el punto de vista operativo, pero desde el punto de vista de la seguridad, la vía de ataque sigue siendo la misma.
En algunos casos, la migración da lugar a una situación aún más peligrosa: un puente entre un entorno de origen comprometido y el de destino. Lo que no se comprueba durante la migración suele convertirse más adelante en un incidente para otra persona.
3. Divulgación de credenciales durante la migración
Los periodos de migración son inestables. Se comparten credenciales, se añaden relaciones de confianza, la sincronización se amplía y los cambios legítimos generan suficiente ruido como para ocultar actividades maliciosas a plena vista.
En abril de 2026, Microsoft modificó la configuración predeterminada del KDC de Kerberos para dar prioridad al cifrado AES en las cuentas que no tuvieran una configuración de cifrado explícita, un cambio que puede provocar fallos en las cuentas de servicio que dependan de RC4 durante la coexistencia si los equipos no han identificado esas dependencias con antelación. Tal y como explico en mi entrada «RC4 y la migración de AD: descubre los escenarios de fallo que se esconden en tu dominio de origen», los proyectos de migración están especialmente expuestos a este riesgo, ya que las herramientas estándar pueden trasladar una cuenta sin tener en cuenta sus supuestos de cifrado.
Si a esto le sumamos el riesgo de que los atacantes se aprovechen de las relaciones de confianza —o incluso creen «bosques fantasma» para obtener acceso mientras los equipos se centran en la transición—, queda claro que el periodo de migración es una de las fases de mayor riesgo en el ciclo de vida de la identidad.
4. Uso indebido de SID-History
El atributo «SID-History» resulta útil para garantizar la continuidad, pero puede ser peligroso si no se gestiona adecuadamente. Los evaluadores de seguridad lo han utilizado meses después de la migración para acceder a recursos heredados a través de identidades que ya no deberían tener relevancia.
En la práctica, un atacante puede asignar el historial de SID de una cuenta administrativa a una cuenta con menos privilegios y recuperar así el acceso efectivo en el entorno de origen. Lo que es peor, estos SID heredados suelen permanecer durante años, ya que las organizaciones nunca los eliminan por completo.
5. LCC defectuosas o excesivamente permisivas
La traducción de las listas de control de acceso (ACL) sin validación es una de las formas más rápidas de provocar una deriva de permisos. Los datos confidenciales de recursos humanos o finanzas pueden quedar al alcance de amplios grupos de usuarios, y las organizaciones a menudo no se dan cuenta hasta que falla una auditoría o un usuario ve datos a los que nunca debería haber tenido acceso.
En entornos grandes y caóticos, con un gran número de grupos, es fácil que se produzca esa deriva, a menos que se seleccione cuidadosamente lo que realmente hay que destacar.
6. Fallos en las cuentas de servicio y privilegios ocultos
Las dependencias de identidad de los servicios suelen estar mal documentadas, lo que explica que las aplicaciones de negocio puedan fallar días después de una migración. Pero los problemas con las cuentas de servicio no se limitan a cuestiones de disponibilidad. A menudo ponen de manifiesto contraseñas obsoletas, derechos excesivos, dependencias no documentadas y rutas de autenticación que nadie tenía intención de mantener.
Si no se asignan correctamente las cuentas de servicio, no se actualizan las ACL en los servicios y los objetos COM, y no se tienen en cuenta las identidades gestionadas por el sistema, es posible que se apague el sistema de origen y se descubra demasiado tarde que las aplicaciones críticas del sistema de destino siguen dependiendo de él. En ese momento, la «migración completada» se convierte en una «interrupción del negocio en curso», y es posible que los privilegios antiguos sigan estando integrados en el nivel de servicios.
7. Colisiones de identidades y asignaciones erróneas
Una lógica de coincidencia deficiente puede provocar peligrosas colisiones de identidades. Un ejemplo sencillo es asociar al director general de una empresa adquirida con alguien que tenga un nombre similar en el entorno de destino. La persona equivocada puede heredar un alias, una dirección de correo electrónico o pertenencias a grupos incorrectos.
Esto va más allá del simple mantenimiento de los directorios. Una asignación incorrecta de objetos da lugar a accesos inadecuados, a la exposición de datos y a problemas de autenticación difíciles de rastrear, lo que socava la confianza en toda la migración.
8. La coexistencia que amplía el impacto de las brechas
La conectividad durante la migración puede agravar las consecuencias de una brecha de seguridad. Si el origen y el destino no están suficientemente aislados durante la coexistencia, la propia infraestructura de migración puede convertirse en el puente que los atacantes utilizan para extender la infección desde el bosque heredado al nuevo.
La coexistencia resulta útil desde el punto de vista operativo, pero es peligrosa si se da por sentado que es fiable. Un bosque reconstruido no es automáticamente un bosque reforzado.
9. Deficiencias en materia de cumplimiento y auditoría
Cuando los auditores preguntan quién tuvo acceso durante la migración, por qué se modificaron los permisos o cuándo se añadió el historial de SID, «no estamos seguros» no es una respuesta aceptable.
Si la migración carece de flujos de trabajo auditables y de informes comprensibles, los equipos de seguridad no pueden demostrar que controlan los cambios de identidad. Esto se convierte en una conversación especialmente difícil con los auditores, los equipos jurídicos y las aseguradoras cibernéticas, que exigen pruebas, no suposiciones.
10. Puntos ciegos forenses tras la transición
El registro de eventos no es opcional durante la migración. Si semanas más tarde se detecta una actividad sospechosa y los registros están incompletos, son confusos o faltan, se pierde la posibilidad de reconstruir lo que ocurrió y cómo logró entrar el atacante.
Si no puedes cuantificar la vía de ataque con certeza, tampoco podrás demostrar que la has eliminado. Esa es una postura difícil de defender tras un incidente.
11. Un bosque nuevo con viejas puertas traseras
Todos estos riesgos más generales se derivan del mismo error: seguir acumulando defectos porque nadie quiere cambiar nada ahora.
Las cuentas inactivas, los SID huérfanos y las configuraciones dudosas sobreviven al traslado. La deuda de seguridad permanece oculta hasta que una auditoría posterior, una iniciativa en la nube o una filtración de datos sacan a la luz el problema.
Y esa es la suposición más peligrosa de todas: creer que un entorno reconstruido es seguro simplemente por ser nuevo. La verdadera prueba de una migración de AD no es si los usuarios pueden iniciar sesión el lunes, sino si el nuevo entorno es sustancialmente más difícil de comprometer que el que ha sustituido.
Convierte tu migración de AD en una transformación de seguridad
Las migraciones a Azure son una de las mejores oportunidades que una organización tendrá jamás para reducir las vías de ataque, eliminar la exposición de los sistemas heredados y modernizar la seguridad de las identidades. Pero eso solo ocurre si la seguridad se integra en el plan de migración desde el principio, y no se trata como una tarea de limpieza posterior al cambio de sistema.
Si su organización tiene previsto llevar a cabo una migración de Active Directory, una integración tras una fusión o adquisición, o un proyecto de modernización del bosque, este es el momento de decidir si se limita a trasladar la infraestructura o si mejora sustancialmente su nivel de seguridad.
En Semperis, consideramos la migración como un evento de seguridad, no como un simple traslado sin modificaciones. Ayudamos a las organizaciones a reducir los riesgos asociados a los sistemas heredados durante el proceso de migración, en lugar de arrastrarlos y tener que hacer frente a sus consecuencias más adelante. Obtenga más información sobre nuestros servicios de migración de Active Directory.
Más información sobre cómo realizar una migración de AD con éxito
- Migración y consolidación de AD
- Migración y consolidación de Active Directory centradas en la seguridad
- Por qué la modernización de AD es fundamental para su programa de ciberseguridad
- Migración de RC4 y AD: descubre los escenarios de fallo que se esconden en tu dominio de origen
- Migración a Active Directory: 15 pasos para el éxito
