Windows usa un proveedor de credenciales y un SSPI para proporcionar la funcionalidad. La SSPI se comunica a través de un servicio web a los puntos finales de Microsoft. Los puntos finales se configuran almacenándolos en una DLL firmada por el código que se inserta a través de Windows Update. La SSPI cargará la DLL, verificará su código firmado por Microsoft y analizará los puntos finales necesarios.
Cuando el SSPI se conecta a los puntos finales, compara el certificado SSL con un valor almacenado en la DLL de configuración. No estoy seguro de si es solo una comparación temática o si están haciendo comparaciones clave, pero si la comparación falla por cualquier motivo, se rechaza la solicitud.
Además, el proceso está protegido por un secreto de cliente. Las credenciales enviadas al punto final se cifran utilizando un secreto local que los puntos finales de Microsoft conocen. No estoy seguro si es una clave simétrica o una clave asimétrica. Sin embargo, la clave asimétrica podría ser más probable. Esta clave se comparte durante el proceso de arranque que se produce cuando registra la computadora como Live ID habilitado.
Para una medida adicional, la forma en que realiza el inicio de sesión único en los sitios habilitados para Live es mediante el almacenamiento de una cookie con un token de corta duración en uno de los dominios de Live ID. Una vez que la SSPI ha autenticado a un usuario, se envía una solicitud a otro servicio web para obtener un token de dispositivo. El servicio está autenticado por una confianza federada a Live ID. Si tiene un token de Live ID que se emite a su dispositivo, puede llamar a este servicio para obtener otro token. Este token de dispositivo se serializa a algún formato particular y se escribe en una cookie dentro de la sesión de Windows del usuario. La próxima vez que el usuario navegue a un sitio de Live ID, la cookie estará presente, validada y no se le solicitarán las credenciales. Hay algo más que esto, pero eso es lo esencial del proceso.
Por lo tanto, con respecto a la falsificación o la manipulación, Microsoft utiliza la fijación de certificados para evitar MITM, y utiliza un secreto compartido para evitar que los clientes no autorizados realicen solicitudes de autenticación.
Editar: Si el certificado adecuado no está en la DLL, la solicitud fallará. Un administrador podría falsificar la DLL pero necesitaría firmarla con las claves de firma de código de Microsoft, y bueno, problemas más grandes y todo eso si pudieran hacer eso. Si el administrador adquiere la clave compartida de alguna manera, podría falsificar una solicitud usando su token, pero eso significa que tienen que adquirir el token de alguna manera, lo que se hace mucho más difícil dado el anclaje del certificado. En ese momento, podría ser más fácil instalar un proveedor de credenciales falso y recopilar las credenciales.