Agradecimientos: Gracias especiales a Charlie Clark (@exploitph) por ayudarme a modelar las amenazas de los ataques de esta serie y por su trabajo en la refactorización de SharpRMS. Gracias a Aaron Margosis y Sean Metcalf por dar retroalimentación que afinó tanto la precisión como el argumento de esta investigación. Y gracias a Susannah Matt por su ayuda en la revisión, el formato y la publicación de este artículo.
La parte 1 de esta serie cubrió la arquitectura de Active Directory Rights Management Service (AD RMS), el modelo de confianza de certificados y licencias, y cómo cualquier usuario del dominio puede descubrir la implementación e identificar qué archivos están protegidos por RMS solo con reconocimiento. En este artículo ocurre el ataque.
Si no leíste la parte 1, la versión corta es: cada documento que protege una implementación de AD RMS está vinculado a una sola clave raíz, la clave privada del Server Licensor Certificate (SLC), cuyo certificado tiene un período de validez de 255 años, mientras que la clave en sí no tiene fecha de vencimiento ni mecanismo de rotación. Este artículo muestra cómo llegar a esa clave, qué hacer con ella y por qué el acceso persiste mucho después de que te vayas.
Una corrección de enfoque de entrada, para nivelar expectativas: este ataque no es el equivalente de un DCSync. La clave del SLC no son credenciales de AD, y esto no es un compromiso del dominio. Es un compromiso total y permanente de todo lo que protege el servicio RMS, para todos los usuarios, lo cual es algo distinto y es el tema del resto de este artículo.
Una nota sobre el trabajo previo y el alcance
Los ataques del lado del cliente contra AD RMS, en los que alguien que ya tiene permitido abrir un documento protegido usa un cliente no conforme para eliminar su protección y anular las restricciones de solo lectura, sin impresión, sin copia y de vencimiento, fueron desarrollados hace años por Martin Grothe, Christian Mainka, Paul Rösler y Jörg Schwenk en su investigación DisARMS en WOOT 2016. Ese trabajo es la base sobre la que se construye esta serie, y es lo que la inspiró. Para conocer los ataques del lado del cliente, lee su artículo; esta serie no los vuelve a cubrir. Lo que agrega es el lado del servidor: recuperar la clave raíz en sí y todo lo que sigue una vez que la clave está en tus manos. Porté su código original del lado del cliente a un solo binario unificado, SharpRMS, junto con las nuevas capacidades del lado del servidor, de modo que una sola herramienta cubre ambas mitades de la superficie.
El laboratorio y el elenco
La parte 1 construyó este laboratorio en detalle. Aquí está en una sola imagen, ya que la parte 2 se apoya en ella constantemente. El servicio corre en VESUVIO, con la base de datos de configuración en SQL en BARONE. El elenco es pequeño. Tony, miembro de un Service Group, es la puerta a la superficie de administración y a la clave. Silvio tiene una concesión de contenido. Paulie es un usuario de dominio común sin nada. El resto de este artículo trata de esos tres intentando alcanzar, o siendo rechazados de, lo que protege AD RMS.
Figura 1: El laboratorio de Nueva Jersey y su elenco. El servicio corre en VESUVIO, con la base de datos de configuración en SQL en BARONE. El panel inferior muestra quién alcanza qué. Solo los miembros del Service Group alcanzan la superficie administrativa y la clave, Silvio tiene un permiso de contenido y Paulie es un usuario del dominio común sin nada.
La clave que no puedes rotar
El SLC es la raíz de todo lo que hace AD RMS. Toda licencia de publicación que la implementación emitió alguna vez lleva una clave de contenido cifrada con la clave pública del SLC, y el servidor descifra esa clave de contenido con la clave privada del SLC cada vez que se abre un documento. Quien tenga la mitad privada tiene la clave maestra de todo documento que la implementación haya protegido alguna vez, dondequiera que todavía exista una copia: archivos extraídos de un recurso compartido hace tiempo, correo eliminado del servidor, documentos en máquinas que ya fueron dadas de baja. El contenido protegido en sí nunca llega a los servidores RMS, así que la clave, y no ninguna copia almacenada en el servidor, es todo el juego.
Las mismas fechas aparecen de forma independiente desde el endpoint del servidor:
Figura 2: Relaciones entre certificados y licencias en AD RMS. Redibujado a partir de Enrique Saggese, "Licenses and Certificates, and how AD RMS protects and consumes documents," Microsoft TechNet Information Protection blog (archivado en Microsoft Tech Community); el SLC marcado como la raíz del clúster de 255 años.
La comparación que enmarca la gravedad: el SLC es para AD RMS lo que KRBTGT es para Kerberos y lo que la clave de respaldo de dominio de DPAPI es para el cifrado de credenciales. Las tres son raíces de clúster de larga vida que protegen todo lo demás. Las diferencias importan:
Dos claves y un certificado que sobreviven al dominio
Clave | Validez | Rotación | Qué desbloquea |
|---|---|---|---|
| Sin vencimiento automático; los tickets emitidos duran ~10h | Un doble reinicio invalida todos los Golden Ticket. Es una clave de firma pura, así que el KDC simplemente deja de confiar en la anterior. | Tickets de Kerberos |
Clave de respaldo de dominio DPAPI | Sin vencimiento; se genera una sola vez al crear el dominio | No hay rotación compatible con Microsoft (su recomendación es construir un dominio nuevo). Herramientas no oficiales pueden establecer una nueva clave preferida, pero todo secreto ya respaldado sigue siendo descifrable con la clave anterior. | Secretos cifrados con DPAPI, en todo el dominio |
AD RMS SLC | ~255 años | Un nuevo SLC cambia solo lo que se emite de ahí en adelante. No existe una revocación que proteja retroactivamente el contenido ya sellado, así que todo documento sellado con la clave anterior sigue siendo descifrable con ella para siempre. | Todo documento que el clúster haya protegido alguna vez |
La ventana de 255 años no es un error de configuración. Cada servidor de AD RMS se inscribe como la hoja de una cadena de certificados fija de Microsoft que viene incluida en el producto: una Raíz de Producción DRM, una CA de Producción y una CA de Inscripción de Servidor de Producción, que emite el certificado del Server Self Enrollment Service, el cual a su vez firma el SLC de tu servidor. El servidor genera su propio SLC al inscribirse y hereda textualmente la ventana de validez de ese certificado de autoinscripción, el lapso que Microsoft fijó entre el 5 de diciembre de 2002 y el 3 de marzo de 2258. La decisión de diseño es la forma de todo el sistema: un certificado que en la práctica nunca vence, que certifica un par de claves que está en la raíz de cada operación criptográfica que realiza el servicio. Las fechas no son algo que SharpRMS calcule. Están en el XrML sin procesar de la cadena del emisor de licencias que viaja en la licencia de publicación de cada documento que protege la implementación, que es donde SharpRMS las lee.
Del certificado de la CA de inscripción que recibe cada implementación de AD RMS, incrustado en la licencia de publicación de cada documento que protege:
<!-- Microsoft DRM Server Self Enrollment Service certificate, embedded verbatim -->
<!-- in the Publishing License of every document this cluster protects. -->
<OBJECT type="MS-DRM-Server">
<NAME>Microsoft DRM Server Self Enrollment Service</NAME>
</OBJECT>
<RANGETIME>
<FROM>2002-12-05T01:07</FROM>
<UNTIL>2258-03-03T21:33</UNTIL>
</RANGETIME>
Las mismas fechas aparecen de forma independiente desde el endpoint del servidor:
Figura 3: La misma ventana de 2002 a 2258, leída directamente del endpoint del servidor. Una segunda fuente, las mismas fechas que la CA de inscripción incorporó.
Esa ventana es, en la práctica, "nunca", y por diseño. El número exacto es arbitrario; Microsoft podría haber fijado 150 años o 3.000, y el significado práctico es el mismo: el certificado dura toda la vida de la implementación. La comparación con los Golden Ticket de Kerberos es ilustrativa, pero apunta en una dirección específica. La validez de un Golden Ticket la establece el atacante en el momento de la falsificación, y Mimikatz usa 10 años por defecto porque es un número redondo que encaja en el campo de duración de Kerberos. La ventana del SLC se fija al inscribirse y se hereda de la cadena de Microsoft, así que ningún cmdlet ni opción de consola puede cambiar la fecha. La duración del certificado no es el problema. La clave privada que certifica sí lo es, porque esa clave no tiene ninguna vía de rotación.
Puedes dar de baja el clúster y reconstruirlo, y el nuevo clúster recibe un nuevo SLC. Pero todo documento protegido con el SLC anterior sigue siendo descifrable con la clave anterior, para siempre. Si la clave fue extraída antes de la reconstrucción, nada cambia.
El objetivo: un documento que solo Tony y Silvio pueden abrir
Antes de cualquier cálculo de claves, aquí está el documento del que trata el resto de esta publicación: protegido por AD RMS, pensado para dos identidades y nadie más. Todo lo que sigue es si esa protección se mantiene.
Figura 4: Restringiendo BOARD_MINUTES_2026.docx como tony.soprano. Archivo > Información > Proteger documento > Restringir acceso abre el cuadro de diálogo de permisos, donde Tony se otorga a sí mismo Control total y a silvio.dante Lectura.
Figura 5: BOARD_MINUTES_2026.docx protegido. Observa el banner "amarillo" que indica ACCESO RESTRINGIDO.
Un documento protegido para tony.soprano y silvio.dante, creado por Tony, guardado en la estación de trabajo. La protección es visible en los bytes sin procesar del archivo, antes de que Word siquiera se ejecute:
Figura 6: Un .docx normal es un ZIP, que empieza con 50-4B-03-04 (PK). Un .docx protegido con RMS está envuelto en un archivo compuesto OLE, que empieza con D0-CF-11-E0-A1-B1-1A-E1, con Primary (la licencia de publicación) y flujos EncryptedPackage dentro. Así que puedes rastrear un recurso compartido o buzón en busca del valor mágico D0-CF más esos flujos de DRM para identificar exactamente los documentos que valen la pena atacar. Reconocimiento barato, señal alta.
Esto es lo que pasa cuando paulie.gualtieri, un simple miembro de Domain Users sin derechos de RMS, intenta abrirlo:
Figura 7: paulie.gualtieri se le niega el acceso a BOARD_MINUTES.docx por AD RMS, no por Word. Abrir el documento activa al cliente RMS para autenticar a Paulie ante el clúster y solicitar una licencia de uso para su identidad. La aplicación de la política vive en la capa de autorización de AD RMS, no en Word; el clúster, no la aplicación, decide si se emite una licencia.
Figura 8: El clúster resuelve los derechos de Paulie del lado del servidor, no encuentra ninguno y se niega a emitir una licencia. Word solo transmite esa decisión: "No iniciaste sesión en Office con una cuenta que tenga permiso…", y lo remite a solicitar permiso a [email protected]. El contenido permanece cifrado.
¿Este clúster tiene la clave basada en software?
Antes de extraer nada, confirma que la clave privada del SLC se guarda en software. Una implementación respaldada por HSM mantiene la clave en hardware, fuera del alcance de las rutas de extracción que se cubren aquí. La operación administrativa keyprotection responde esto como miembro del Service Group:
Figura 9: keyprotection se ejecuta como miembro del Service Group. IsServicePrivateKeySoftwareBased: true es la señal de inicio, y la llamada devuelve la cadena de conexión de la base de datos al salir. La cadena no lleva credenciales (integrated security=SSPI); nombra el servidor SQL y la base de datos, y funciona solo para un llamador ya autorizado para esa base de datos.
IsServicePrivateKeySoftwareBased: true es la luz verde. La clave privada de la SLC vive en la base de datos de configuración en BARONE (SQL), accesible por las rutas de abajo. El DatabaseConnectionString también te da la fuente de datos, es decir, el servidor SQL (data source=BARONE) y el nombre de la base de datos, que es exactamente lo que usa la ruta de extracción SQL. Ambos datos vuelven a un miembro del Service Group.
Si el campo dice false, la clave está en un HSM. La ruta de exportación TPD que se muestra aquí puede seguir funcionando, porque la exportación se ejecuta del lado del servidor y puede acceder a una clave respaldada por HSM cuando el administrador ha permitido la exportación. Las rutas que en cambio leen el material de la clave directamente, el blob SLC cifrado en la base de datos de configuración, no pueden, porque un HSM nunca libera la clave privada en forma utilizable.
Extracción de la clave: la ruta de exportación TPD
AD RMS expone una operación de exportación de dominio de publicación de confianza (TPD) a través de su superficie SOAP administrativa. La exportación TPD está pensada para migración y confianza entre organizaciones: empaqueta el material de la clave privada de la SLC de una implementación para que una segunda implementación de AD RMS pueda importarlo y emitir o abrir licencias como si fuera la primera. Un dominio de usuario de confianza solo comparte certificados públicos, pero un dominio de publicación de confianza comparte la clave privada en sí, que es exactamente por qué la exportación es el vector de extracción. La puerta de autenticación es la membresía en el Service Group de AD RMS, un rol privilegiado por sí mismo. Dada esa membresía, la exportación es una sola llamada SOAP autenticada a la superficie administrativa.
Vale la pena ver esa división. El pipeline del cliente está abierto a cualquier usuario del dominio, y la superficie administrativa, donde vive la exportación, es la mitad restringida.
Figura 10: La superficie del protocolo SOAP de AD RMS. El pipeline del cliente (certificación, licencias, distribución de plantillas) responde a cualquier usuario del dominio. La superficie administrativa, donde vive la operación de exportación TPD, está restringida a la membresía en el Service Group de AD RMS. Servicio en VESUVIO, base de datos de configuración en BARONE.
La exportación cifra el blob de la clave con una contraseña. La implementación predeterminada usa una clave SHA-256 derivada de esa contraseña, un IV codificado de forma fija, y AES-128-CBC. El IV es:
IV (hardcoded): 01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F-10
El IV es idéntico en cada instalación de AD RMS. No es exclusivo de tu implementación; está codificado de forma fija en la implementación del servidor. Combinado con una clave AES que es solo un SHA-256 de una sola pasada y sin sal de la contraseña de exportación, la exportación de TPD es el eslabón más débil en la cadena de protección de claves. Esa debilidad se aplica a las copias de seguridad almacenadas, no al ataque en vivo: un archivo de copia de seguridad de TPD dejado en un recurso compartido accesible y protegido con una contraseña débil o adivinable puede desbloquearse sin conexión, sin acceso al servidor.
En la ruta de ataque, la contraseña la elige el atacante, ya que tú la defines en la llamada de exportación, por lo que la derivación débil de claves es irrelevante para la extracción en vivo. Sí importa para las copias de seguridad almacenadas. La guía de Microsoft para migrar de AD RMS a Azure Information Protection indica a los administradores que exporten los dominios de publicación de confianza, señalando que "los dominios de publicación de confianza incluyen las claves del certificado de licencia del servidor (SLC) para descifrar archivos protegidos anteriormente". Cada archivo .xml exportado es, por lo tanto, una copia protegida con contraseña de la clave privada SLC. La instrucción de Microsoft es "especificar y confirmar una contraseña segura", el control que falla cuando esa contraseña es débil o reutilizada, y proteger el archivo: "sin embargo, almacenes estos archivos, usa las mejores prácticas de seguridad para protegerlos porque estos datos incluyen tu clave privada". Ese es el punto clave. Una exportación de TPD es material de clave privada, así que mantenla fuera de cualquier recurso compartido de uso general y restringe los permisos del recurso compartido y de NTFS a las pocas cuentas que realmente necesitan acceso, porque un archivo protegido con permisos solo para administradores es mucho más difícil de alcanzar que uno en un recurso compartido legible por todos.
Todo lo que sigue asume que las credenciales de Tony ya están en manos del atacante. Esta publicación da ese compromiso por sentado; cómo se obtuvieron las credenciales no es el punto, y dejaré esa parte a la imaginación de los pentesters y los red teamers 😀. Lo que importa es que Tony es miembro del grupo de servicio de AD RMS, un rol privilegiado por derecho propio y, en la práctica, un administrador del servicio RMS. Esa membresía por sí sola es toda la puerta de entrada.
Ejecutando como Tony desde SATRIALES, una estación de trabajo del dominio, la extracción es una sola llamada a la superficie de administración:
.\SharpRMS.exe extract /method:tpd /server:http://vesuvio.newjersey.sopranos.local /user:NEWJERSEY\tony.soprano /password:Gabagool123! /exportpassword:SharpRMS2026 /outfile:slc.bin
Figura 11: Exportación de TPD con SharpRMS, ejecutada como tony.soprano desde SATRIALES. Sale el blob de clave privada SLC de 1172 bytes. Nota que tenemos un nuevo archivo depositado en el escritorio (slc.bin)
La salida es un PRIVATEKEYBLOB CAPI de 1172 bytes: un contenedor estándar de clave privada RSA de Windows en formato little-endian. Su SHA-256 es a1e7afd5…ece9e5a. Los primeros 8 bytes del módulo (big-endian) son CA-10-CF-24-3A-30-6B-9D. Estas son las huellas digitales verificables de la clave raíz de este clúster.
¿Qué registra esta operación?
Nada evidente. La base de datos de registro de AD RMS (DRMS_Logging en BARONE, la instancia de SQL) registra seis tipos específicos de solicitudes: GetLicensorCertificate, Certification.Certify, Certification.Precertify, TemplateDistribution (ambas variantes), y GroupExpansion. AcquireLicense no está entre ellos, ni tampoco Publish.
La superficie SOAP de administración, incluida la operación ExportTrustedPublishingDomain , no aparece en ese registro. No hay un ID de evento de Windows que se active por defecto ante la exportación de un TPD. Los registros de IIS registran el POST a /_wmcs/admin/, pero ese endpoint maneja muchas operaciones y el nombre de la operación específica está en el cuerpo del protocolo SOAP, no en la URL. Una organización que monitoree los registros de IIS en busca de solicitudes POST a la ruta de administración y analice los cuerpos del protocolo SOAP podría detectar la exportación.
La lectura práctica: la extracción del TPD no deja ninguna entrada en la base de datos de la aplicación de RMS. El registro W3SVC de IIS registra el POST a /_wmcs/admin/, incluido el usuario autenticado, la IP de origen y el user agent, pero rara vez se analiza para detectar llamadas SOAP de administración. No se activa ningún ID de evento de Windows. El único artefacto duradero es el archivo slc.bin en la máquina del atacante. Veremos la detección más adelante.
El resultado: lo que hace SLC.BIN y Paulie no puede
La misma máquina, la misma cuenta, el mismo archivo. SharpRMS se ejecuta solo con slc.bin y el documento protegido:
.\SharpRMS.exe decrypt /keyfile:slc.bin /infile:BOARD_MINUTES_2026.docx /outfile:PAULIE_cracked.docx
Figura 12: SharpRMS decrypt ejecutándose como paulie.gualtieri con el slc.bin proporcionado. La clave se carga (módulo CA-10-CF-24), la clave de contenido y la clave de paquete se desenvuelven, y el PAULIE_cracked.docx sin restricciones se guarda en el escritorio como OOXML válido. Sin contacto con el servidor, sin credenciales, sin derechos de RMS.
Figura 13: PAULIE_cracked.docx abierto en Word. Observa que no hay aviso de ACCESO RESTRINGIDO.
Dos cosas a destacar en la salida del descifrado:
Cada documento lleva su propia clave de contenido y clave de paquete, generadas de forma única en el momento de la protección.
El único
slc.binlo desenvolvió, porque su clave de contenido estaba sellada con la misma clave pública SLC.
Esa es la generalización: una sola clave SLC no solo abre todos los documentos que el despliegue haya protegido alguna vez, sino que elimina la protección y escribe una copia limpia y sin cifrar en el disco, sin importar qué usuario creó el documento, qué política de derechos llevaba, o si ese usuario todavía existe. Eso es más de lo que puede hacer cualquier lector autorizado. Silvio puede abrir y leer el documento, pero no puede guardar una copia sin protección sin la clave; la clave SLC produce exactamente eso.
Falsificación de XrML: acuñar una identidad en la que el clúster confía
Aquí es donde las cosas se ponen interesantes. Con la clave privada SLC en mano, puedes acuñar credenciales que AD RMS trata como propias: un Rights Account Certificate para cualquier identidad que nombres, firmado de modo que el servidor no pueda distinguirlo de uno real. El resultado es que dejas de necesitar la clave o la sesión de una víctima. Le pides al servidor una licencia de uso como esa identidad, y la emite. El resto de esta sección arma esa falsificación pieza por pieza: la firma, el certificado y, finalmente, una solicitud de licencia completa que el servidor acepta.
La clave privada SLC no es solo una clave de descifrado, también es una clave de firma. Todo certificado en la jerarquía de confianza de AD RMS, desde los Rights Account Certificates (RAC) que identifican a los usuarios hasta las licencias que otorgan acceso, es un documento XrML firmado por la SLC. Con la clave privada en disco, puedes producir esa firma tú mismo, y el servidor no puede notar la diferencia.
La firma sigue un estándar una vez que conoces la codificación. La entrada son los bytes crudos en UTF-16LE del elemento BODY, sin canonicalización XML. Se calcula un hash con SHA-256, se firma con RSA PKCS#1 v1.5, y la firma es válida. SharpRMS hace esto de forma nativa, sin ningún SDK de RMS en la máquina. El código de Microsoft solo interviene como paso de verificación: cuando está presente Microsoft.RightsManagementServices.Shared, la DLL del servidor RMS, la falsificación coteja su firma contra RsaCapiKey.Sign de esa biblioteca, y ambas coinciden byte por byte. La coincidencia es esperable, ya que la clave SLC es la misma, y ese es precisamente el punto. Confirma que el firmante nativo creado desde cero reproduce la salida de Microsoft sin ninguna particularidad de codificación que haga que el servidor rechace la falsificación.
El cotejo es el único paso que toca la DLL de Microsoft. Esa DLL, Microsoft.RightsManagementServices.Shared, es un componente de servidor que el rol de AD RMS instala en el GAC, por lo que no está presente en una estación de trabajo del dominio de forma predeterminada. En principio, podrías copiarla a una estación de trabajo y cargarla ahí, ya que es un ensamblado administrado, pero no hay ninguna razón para hacerlo. /verifydll es una comprobación única de que el firmante nativo coincide con el de Microsoft byte por byte, no un paso del ataque. La falsificación en sí no necesita ningún código de Microsoft, así que en un compromiso real no cargas con nada. La comprobación solo tenía que ejecutarse una vez, en una máquina donde ya residía la implementación de referencia.
Esto no significa que la falsificación se comporte de otra manera ahí. La firma nativa es determinista: los mismos bytes en cualquier máquina. El servidor fue simplemente el lugar donde pudimos comparar nuestra salida con la de Microsoft. Esto es una verificación de nuestra herramienta, no un paso del ataque.
SharpRMS falsifica el certificado, un certificado XrML firmado bajo la SLC, usando solo criptografía estándar de .NET, y se ejecuta por completo en la estación de trabajo sin ningún SDK de RMS en la máquina. Ese es todo el punto. Como la firma se produce con la clave privada SLC, no es una imitación convincente de la firma del servidor: es una firma SLC genuina, criptográficamente la del propio servidor. Una estación de trabajo común, al poseer la clave, acuña certificados que el servidor acepta como auténticos, y no necesita nada de Microsoft para hacerlo.
La propia documentación del SDK de AD RMS de Microsoft es explícita sobre la base de esa confianza. Describe que el RAC lleva una firma "creada mediante la clave privada del servicio de activación de AD RMS", respaldada por una cadena de certificados de licenciante de servidor hasta la raíz. La firma es la confianza. Reprodúcela y el clúster no tiene ninguna otra prueba a la que recurrir.
Figura 14: Microsoft.RightsManagementServices.Shared en VESUVIO. La implementación de referencia es un ensamblado de servidor firmado por Microsoft, versión 10.0.20348.1, instalado en el GAC por el rol de AD RMS. Está presente en el servidor y ausente en una estación de trabajo del dominio, por lo que el cotejo de la siguiente figura solo puede ejecutarse aquí.
.\SharpRMS.exe forge /keyfile:slc.bin /verifydll
Figura 15: La falsificación nativa, cotejada contra esa DLL del servidor con /verifydll.
SharpRMS firma el BODY de XrML desde cero con la clave SLC extraída, y luego compara su firma contra el propio RsaCapiKey.Sign de Microsoft. La coincidencia es byte por byte. La firma falsificada no es solo válida, es idéntica a una que el servidor produciría, por lo que no se puede distinguir de un certificado legítimo inspeccionando la firma. El cotejo de /verifydll se ejecuta donde está presente la DLL de Microsoft, como el servidor; la falsificación en sí usa RSA y SHA comunes y se ejecuta en la estación de trabajo.
Falsificar un RAC parte de uno real. SharpRMS clona el sobre de un RAC genuino, su bloque emisor y su cadena de certificados, y cambia solo tres campos. El RAC genuino proviene del propio servidor: Precertify acuña un RAC para cualquier identidad nombrada y, al igual que la exportación, requiere las mismas credenciales privilegiadas del Service Group. Aquí acuña uno para Silvio:
.\SharpRMS.exe impersonate /target:[email protected] /sid:S-1-5-21-877797059-2172394321-2911316366-1110 /server:http://vesuvio.newjersey.sopranos.local /user:NEWJERSEY\tony.soprano /password:Gabagool123! /outfile:silvio_precert.xml
Figura 16: Se emite un archivo PRECERT XML para silvio.dante, un RAC legítimo emitido por el servidor. forgerac lo toma como plantilla, reescribe la identidad a la que queremos, inserta una clave pública que generamos, establece una validez de nuestra elección, y vuelve a firmar el BODY con la clave SLC extraída.
Hasta aquí esto solo produce un precertificado vinculado a una clave que tiene el servidor, no una identidad utilizable. Precertify nunca pidió una clave; el servidor generó el par de claves del RAC él mismo, así que silvio_precert.xml está vinculado a una clave pública cuya mitad privada se queda en el servidor. Solicita una licencia de uso contra ese precertificado y la clave de contenido vuelve sellada a una clave que solo el servidor puede abrir. Forjar el RAC soluciona exactamente esto. El comando forgerac toma silvio_precert.xml como plantilla, mantiene intactas la identidad y la cadena de certificados de Silvio, inserta un par de claves que tú controlas, establece una validez a tu elección y vuelve a firmar el BODY con la clave SLC extraída. El resultado es un RAC en el que el servidor sigue confiando, vinculado a una clave privada que tú posees, de modo que una licencia de uso emitida para él vuelve sellada a una clave que puedes abrir. Eso es lo que convierte un precertificado propiedad del servidor en una credencial que realmente puedes descifrar:
.\SharpRMS.exe forgerac /keyfile:slc.bin /template:silvio_precert.xml /target:[email protected] /sid:S-1-5-21-877797059-2172394321-2911316366-1110 /until:2036-07-08T00:00 /outfile:forged_rac.xml
Figura 17: forgerac construye un RAC completo para Silvio a partir de la plantilla silvio_precert.xml, con las claves cambiadas a un par de claves que poseemos (guardado en forged_rac_priv.bin) y firmado con la clave SLC extraída. Ambas verificaciones cruzadas pasan, incluida la que se hace contra la clave pública SLC que usa el clúster, así que su verificación de firma aceptará la falsificación como genuina.
El RAC falsificado es un XML firmado ordinario, no algo cifrado. Recortado y comentado, es un RAC genuino con tres campos cambiados y nada más.
Figura 18: Un RAC falsificado, recortado y abreviado. Es un RAC genuino con tres campos cambiados: la identidad, la clave pública y la validez. La cadena de certificados y todo lo demás se copian textualmente de uno real. La firma es una firma SLC real sobre este cuerpo, por lo que el clúster la acepta.
Una firma solo es interesante si el servidor la acepta, así que el comando goldenrac arma toda la solicitud. Forja una RAC para cualquier identidad, con un par de claves que genera, arma una solicitud real de AcquireLicense a partir de la licencia de publicación propia del documento y la presenta al servidor. Un solo comando, ejecutado desde la estación de trabajo como paulie.gualtieri. Paulie no tiene ningún derecho propio de RMS, ningún permiso sobre este documento y ninguna membresía que le dé acceso. Lo que sí tiene es la clave SLC extraída, obtenida antes mediante el compromiso del Service Group, y esa clave es todo su poder aquí. El objetivo es un documento restringido a tony.soprano y silvio.dante. Paulie ejecuta goldenrac para falsificar a Silvio, fija la validez que elige y solicita una licencia.
El sobre que goldenrac clona de una RAC genuina es solo una estructura pública: el bloque del emisor y la cadena de certificados. Obtener uno no requiere ningún privilegio: actívate como cualquier usuario y conserva tu propia RAC como plantilla, o haz que Precertify genere una para cualquier identidad, lo cual sí requiere credenciales del Service Group con privilegios muy altos. De cualquier forma, el sobre es solo una plantilla; lo que hace funcionar la falsificación es la clave SLC extraída que vuelve a firmar el cuerpo.
.\SharpRMS.exe goldenrac /keyfile:slc.bin /template:forged_rac.xml /infile:BOARD_MINUTES_2026.docx /server:http://vesuvio.newjersey.sopranos.local
/target:[email protected] /sid:S-1-5-21-877797059-2172394321-2911316366-1110 /until:2036-07-08T00:00 /outfile:use_license.xml /keyout:forged_rac_priv.bin
Figura 19: goldenrac ejecutado como paulie.gualtieri. La RAC falsificada para silvio.dante está firmada por la clave SLC extraída, se presenta al clúster en vivo, y el clúster emite una licencia de uso. El clúster nunca emitió esta RAC. Confía únicamente en la firma SLC.
El servidor emite una USE LICENSE que nombra a silvio.dante como el licenciatario y sella la clave de contenido con la clave pública que generó goldenrac. Solo tú tienes la clave privada correspondiente, así que descifras con ese par de claves generado más la propia licencia del servidor. La clave maestra SLC nunca descifra el documento en sí; solo firmó la RAC falsificada que hizo que el servidor emitiera la licencia.
Un detalle que vale la pena destacar: Microsoft documenta que "cada RAC está vinculado al certificado de máquina del equipo en el que se activa el usuario" y que un usuario "no puede transferir un RAC entre equipos." Ese vínculo es un lockbox del lado del cliente: la clave privada de la máquina que está detrás del RAC está "almacenada de forma segura, protegida por claves criptográficas relacionadas con las credenciales de inicio de sesión del usuario y la configuración del equipo," de modo que la clave privada del RAC no se puede desenvolver en otra máquina. Nada de eso es una verificación que realice el servidor de licencias. El RAC falsificado no tenía ningún vínculo con una máquina, y el servidor emitió una licencia de todos modos, porque el servidor valida únicamente la firma del SLC y los derechos de la identidad, nunca a qué máquina pertenece el RAC. Dado que goldenrac genera su propio par de claves, no hay vínculo de máquina alguno que satisfacer, para empezar.
.\SharpRMS.exe decrypt /keyfile:forged_rac_priv.bin /uselicense:use_license.xml /infile:BOARD_MINUTES_2026.docx /outfile:silvio_read.docx
Figura 20: El resultado. El documento se publicó solo para tony.soprano y silvio.dante, y paulie.gualtieri no es ninguno de los dos.
Al falsificar a Silvio y solicitar una licencia de uso, Paulie obtiene la clave de contenido y abre el documento en texto claro en su propia sesión, lo cual se muestra con su cuenta en la esquina superior derecha y en la barra de título de Word. No hay ningún aviso de restricción de RMS porque Paulie ahora tiene contenido descifrado, no un archivo protegido. Recuperar un documento de Office válido de esta forma demuestra que la clave era correcta; una clave incorrecta produce bytes aleatorios, no un archivo legible.
El control negativo confirma que esto es robo de identidad, no una omisión generalizada. Al falsificar a paulie.gualtieri, un usuario que no está en ninguna lista de acceso, el servidor devuelve NoRightsForRequestedPrincipal. La identidad falsificada de Paulie se aceptó por completo; el servidor lo rechazó únicamente porque consultó sus derechos reales y no encontró ninguno.
.\SharpRMS.exe goldenrac /keyfile:slc.bin /template:forged_rac.xml /infile:BOARD_MINUTES_2026.docx /server:http://vesuvio.newjersey.sopranos.local /target:[email protected] /sid:S-1-5-21-877797059-2172394321-2911316366-1111 /until:2036-07-08T00:00
Figura 21: La misma falsificación para paulie.gualtieri, quien no tiene derechos sobre el documento. La identidad falsificada es confiable, pero el servidor resuelve sus derechos y no encuentra ninguno. Falsificar una identidad no es lo mismo que falsificar una autorización.
Ese control es toda la diferencia, y vale la pena decirlo con claridad porque no le resultará obvio a nadie que haya atacado Kerberos.
Esto no es exactamente un Golden Ticket
Si has atacado Kerberos, la clave SLC te resultará familiar. Es la clave de firma raíz, el KRBTGT del dominio de confianza de RMS: quien la tenga puede acuñar certificados que el clúster acepta para cualquier identidad, válidos durante el tiempo que quiera. Así que resulta tentador llamar a un RAC falsificado un Golden Ticket. Sin embargo, vale la pena ser precisos, porque la analogía se rompe en un punto importante.
Un Golden Ticket falsifica identidad y autorización juntas. El PAC viaja dentro del ticket y el KDC confía en él, así que te autoautorizas: coloca el SID de Domain Admins en el PAC y la cuenta pasa a ser Domain Admin, porque la membresía se transporta, no se consulta.
Un RAC falsificado solo falsifica la identidad. El RAC indica quién eres: un SID, un correo electrónico, una clave pública. No lleva derechos ni lista de grupos. Cuando el cliente lo presenta, el clúster resuelve la autorización por su cuenta; verifica la identidad contra la política de derechos del documento, y para las políticas basadas en grupos consulta al servicio GroupExpansion para buscar las membresías reales de ese principal en Active Directory. Por eso silvio devolvió una licencia y texto plano, mientras que paulie devolvió NoRightsForRequestedPrincipal. Ambas identidades falsificadas fueron confiables por completo. Solo una estaba autorizada. No hay ningún PAC que rellenar.
La consecuencia es un patrón de ataque distinto. No escalas a través del certificado, escalas eligiendo a quién suplantar: para leer un documento restringido a un grupo, falsifica un RAC para un miembro real de ese grupo. Ambos caminos usan la misma clave SLC extraída, así que la diferencia no está en la clave, sino en cómo se usa. El descifrado sin conexión desbloquea la clave de contenido directamente, sin solicitud de licencia, sin verificación de derechos y sin ningún contacto con el servidor: acceso silencioso e incondicional a cualquier documento sellado con esa clave. El RAC falsificado, en cambio, firma una identidad que el servidor activo luego acepta, de modo que el propio servidor emite una licencia de uso a un principal que en realidad no existe. Ese es un resultado distinto, no un camino más largo hacia el mismo: el descifrado sin conexión demuestra que la clave rompe la confidencialidad, y el RAC falsificado demuestra que se puede hacer que el servicio en ejecución confíe en una identidad falsificada y la licencie.
Así que la etiqueta más precisa es un híbrido. Falsificado con la clave raíz como un Golden Ticket, razón por la cual el clúster acepta la falsificación. Con la forma de un "Silver Ticket", porque lleva identidad y hereda la autorización real de la víctima en lugar de inyectar la suya propia.
Y esa clave, a diferencia de KRBTGT, nunca se puede recuperar. Un hash de KRBTGT robado es sobrevivible; restablécelo dos veces y todo Golden Ticket falsificado con la clave anterior deja de funcionar. El KDC acepta el KRBTGT actual y el anterior, así que un solo restablecimiento deja válido el anterior; el segundo restablecimiento lo elimina, y las falsificaciones mueren retroactivamente. Ayuda que Kerberos solo protege tráfico de red transitorio: una vez que se elimina la clave anterior, no queda nada persistido que un ticket obsoleto pueda desbloquear. El SLC no te da ninguna de esas concesiones. Es a la vez una clave de firma y la clave de descifrado raíz, y lo que protege persiste durante años. La clave de contenido de cada documento protegido está sellada con la clave pública del SLC, y ese texto cifrado ya está escrito en cada copia del archivo, en cada recurso compartido, buzón y copia de seguridad. Acuñar un nuevo SLC no cambia ninguno de esos bytes. Ninguna operación vuelve a sellar el contenido existente con una clave nueva, y eliminar la clave anterior solo significa que ya no podrás leer tus propios documentos, así que debe permanecer archivada en un dominio de publicación de confianza para siempre. La copia extraída del atacante sigue siendo válida contra todo eso, para siempre. Puedes rotar KRBTGT para expulsar a un intruso. No puedes rotar el SLC para deshacer la filtración de un documento.
Por qué falsificar un RAC y no el SLC
La confianza en AD RMS fluye hacia abajo desde el SLC, exactamente como en cualquier PKI, y esa dirección lo es todo.
Nota lo que el ataque no hace: no falsifica un nuevo SLC. El valor está en la clave privada extraída del SLC real, cuyo certificado público es de todas formas público. Un SLC nuevo que generes tú mismo, una raíz fraudulenta, no vale nada: nada en el entorno apunta a él, y para que signifique algo tendrías que insertarlo en el almacén de confianza de cada cliente y servidor que quisieras engañar, lo cual es ruidoso, exige privilegios altos y es contraproducente, porque para entonces ya controlarías las máquinas que intentabas engañar. Crear una raíz nueva no te da nada. Tener la clave privada de la raíz real te lo da todo.
Un RAC falsificado es una hoja. Está firmado con la clave extraída del SLC, así que se encadena directo a la raíz que el servicio ya confía. No expandes el grafo de confianza, explotas el que ya existe. El servidor valida la firma, ve una cadena que termina en su propia raíz de confianza y emite una licencia de uso.
Esa clave te da dos cosas a la vez: puedes firmar certificados hoja que el servidor no puede distinguir de los suyos, lo que te permite falsificar cualquier identidad en la que el servidor confíe. Y puedes desproteger cualquier contenido que la implementación haya protegido, descifrándolo sin conexión y sin solicitar licencia. Ambos poderes vienen de la misma clave extraída.
Consideración | SLC falsificado (raíz fraudulenta) | RAC falsificado (hoja bajo la raíz real) |
|---|---|---|
Ancla de confianza | Ninguna. No se encadena a nada confiable. | La clave SLC robada y genuina. Se encadena a la raíz que ya es de confianza. |
Para convertirlo en arma | No puedes. La importación valida la firma del SLC contra la raíz de inscripción de Microsoft, así que una raíz autogenerada se rechaza sin importar el privilegio. Es una barrera criptográfica, no de permisos. | Presentarlo. Nada más. |
Radio de impacto | Solo lo que ya controlas. | Suplantación en vivo de cualquier identidad en el clúster emisor. El clúster emite licencias de uso a un par de claves que tenemos, así que leemos el contenido de ese usuario en nuestra propia sesión. |
Veredicto | No vale la pena falsificarlo. | El arma real. |
Remediación
Estos son los controles que realmente marcan la diferencia, en orden de impacto:
Gestiona el grupo de servicio de AD RMS como un grupo de alto privilegio
Este es el cambio individual más importante. El grupo de servicio otorga la superficie de exportación del TPD, la vía de extracción remota, así que debe gestionarse con el mismo rigor que aplicas a cualquier grupo de alto privilegio: usuarios protegidos, requisito de estación de trabajo de acceso privilegiado, revisión trimestral de membresía y alertas ante cualquier cambio. Un miembro del grupo de servicio puede extraer la clave raíz de la implementación con una sola llamada remota al protocolo SOAP, sin necesitar acceso local al servidor RMS. Trata al grupo en consecuencia.
Los archivos de respaldo del TPD son material de clave, no respaldos
Si tu organización exportó sus dominios de publicación de confianza (Trusted Publishing Domains), como indica Microsoft, esos archivos quedan donde un administrador los haya guardado, ya sea un recurso compartido, una estación de trabajo o una unidad USB, así que trátalos como el equivalente de todos los secretos que contiene la implementación de AD RMS, incluida la clave privada del SLC: almacenamiento cifrado, auditoría de acceso y nunca un recurso compartido de archivos de propósito general. Un archivo TPD protegido con una contraseña débil o fácil de adivinar es, en la práctica, una copia sin protección de la clave privada del SLC. Y rotar la contraseña no revierte la exposición: si ese archivo alguna vez estuvo en un recurso compartido accesible, volver a exportarlo con una nueva contraseña no protege nada, porque cualquier copia que un atacante ya haya obtenido sigue siendo válida para siempre. Las únicas respuestas reales son eliminar el archivo expuesto y reforzar los permisos del recurso compartido y de NTFS, y reconocer que, una vez filtrada la clave, no se puede rotar para dejarla fuera de circulación.
Usa TLS y Extended Protection for Authentication (EPA, autenticación extendida)
El servidor VESUVIO predeterminado de esta serie se ejecuta solo con HTTP. Por HTTP sin cifrar, el tráfico del protocolo SOAP viaja en texto claro, incluido el material de clave exportado, y el protocolo de enlace NTLM puede reenviarse (relay). TLS es el mínimo indispensable. EPA (vinculación de canal NTLM) evita el reenvío de credenciales de la superficie administrativa. Ninguna de las dos medidas cambia el radio de impacto de un SLC extraído, pero ambas elevan el costo de obtener las credenciales necesarias para llegar a la superficie administrativa en primer lugar.
HSM para la clave privada del SLC
Un clúster respaldado por HSM configura IsServicePrivateKeySoftwareBased: false. Las rutas de exportación de TPD y de extracción por DPAPI/SQL no producirán material de clave utilizable a partir de un HSM. La operación de exportación puede seguir funcionando (el HSM firma y devuelve la clave envuelta), pero el blob que devuelve está protegido por el HSM de una forma que no se puede desenvolver sin el hardware. Esta es la medida de remediación que realmente cierra la ruta de extracción por software. Requiere planificación (adquisición del HSM, configuración de AD RMS) y no ayuda si el clúster usó claves por software en algún momento de su historia, ya que los documentos protegidos antiguos siguen siendo descifrables con cualquier material de clave extraído antes de instalar el HSM.
Lo que no se puede corregir
Si la clave privada del SLC fue accesible en software en algún momento, cualquier documento protegido durante ese periodo queda permanentemente descifrable con esa clave. Reconstruir la implementación emite un nuevo SLC, pero los documentos antiguos siguen sellados con la clave anterior. Dar de baja y volver a proteger cada documento sensible es la única forma de cerrar de verdad esa ventana, y eso resulta operativamente impráctico para la mayoría de las organizaciones. La vigencia del certificado, de alrededor de 255 años, es en la práctica "para siempre", y no es un error de configuración que puedas cambiar: es un plazo fijo heredado de la cadena de inscripción de Microsoft, no una ventana que alguien establezca o pueda acortar.
Azure Information Protection y HYOK
Esta serie trata sobre AD RMS on-premises. El hallazgo no se aplica a Azure Information Protection ni a Microsoft Purview en su configuración predeterminada. La clave de inquilino de Azure reside en la infraestructura de Microsoft, o en un Azure Key Vault administrado por el cliente para implementaciones de tipo bring your own key (BYOK). No es alcanzable desde un endpoint on-premises comprometido. Un miembro del grupo de servicio en una estación de trabajo on-premises no puede exportar una clave de inquilino de Purview a través de la superficie SOAP administrativa de AD RMS, porque no existe tal superficie en una implementación exclusivamente en la nube.
La excepción notable: las implementaciones de conserva tu propia clave (HYOK). HYOK permite que las organizaciones respalden las etiquetas de confidencialidad de Azure con un clúster de AD RMS on-premises, por lo general para su contenido más sensible. En una implementación HYOK, la clave se mantiene deliberadamente on-premises, lo que significa que cae bajo el mismo modelo de confianza que cubre esta serie. Las organizaciones más preocupadas por que sus datos salgan de la infraestructura de Microsoft son, en muchos casos, las mismas cuyo key raíz es alcanzable desde un miembro del grupo de servicios on-premises. Vale la pena decirlo con claridad: la protección completa de Purview en la nube no queda expuesta aquí. HYOK, la opción más consciente de la seguridad, sí.
Próximamente en la parte 3
La parte 2 cubrió la superficie de ataque de una sola implementación de AD RMS: extraer la clave, descifrar cualquier cosa sin conexión y falsificar una identidad en la que el servidor confía.
Todo eso era una sola implementación. Las organizaciones reales operan varias, conectadas entre sí mediante confianza, y lo que significa una clave robada e imposible de rotar una vez que esa confianza entra en juego es el tema de la parte 3.
Referencias
- Enrique Saggese: Licenses and Certificates, and how AD RMS protects and consumes documents (https://techcommunity.microsoft.com/t5/security-compliance-and-identity/licenses-and-certificates-and-how-ad-rms-protects-and-consumes/ba-p/247309) (Microsoft TechNet Information Protection blog, archived on Microsoft Tech Community)
- Enrique Saggese: AD RMS Infrastructure Concepts, Part 1 (https://techcommunity.microsoft.com/t5/Enterprise-Mobility-Security/AD-RMS-Infrastructure-Concepts-Part-1/ba-p/247305) (Microsoft TechNet Information Protection blog, archived on Microsoft Tech Community)
- Grothe, Mainka, Rösler & Schwenk: How to Break Microsoft Rights Management Services (https://www.usenix.org/system/files/conference/woot16/woot16-paper-grothe.pdf) (DisARMS, USENIX WOOT '16, Ruhr-Universität Bochum)
- RUB-NDS: MS-RMS-Attacks (https://github.com/RUB-NDS/MS-RMS-Attacks)(reference implementation for the DisARMS attacks)
- Microsoft: Rights Account Certificates (https://learn.microsoft.com/en-us/previous-versions/windows/desktop/adrms_sdk/rights-account-certificates) (AD RMS SDK)
- Migrate from AD RMS to Azure Information Protection - Phase 2 (https://learn.microsoft.com/en-us/azure/information-protection/migrate-from-ad-rms-phase2)
- Rights Account Certificates (AD RMS SDK) (https://learn.microsoft.com/en-us/previous-versions/windows/desktop/adrms_sdk/rights-account-certificates)
- Preguntas frecuentes sobre RMS: certificados, claves y cifrado (https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-rights-management-services-rms/cc747725(v=ws.10))
