Descargo de responsabilidad: esta publicación documenta algunos de mis hallazgos al llevar a cabo mi propia investigación y comprender la amenaza del agarre de las credenciales. Esto también fue para proporcionar conciencia a la comunidad informática del usuario final con respecto a este problema. Los enlaces a las herramientas y algunos de los detalles sobre el ataque se han omitido deliberadamente de este artículo. Sin embargo, debe tener el conocimiento y la habilidad apropiados del uso de herramientas de prueba de exploit y vulnerabilidad antes de aventurarse en el camino de jugar con herramientas de explotación de seguridad. ¡Cualquier uso es bajo su propio riesgo! Introducción Recientemente leí sobre Mimikatz y quería entender lo fácil que era obtener el nombre de usuario y la contraseña a través de una sesión remota. Sesión remota: Terminal Services/RemotedeskTOpServices/Protocolo RDP. En este artículo, observamos cómo funciona Mimikatz y la exposición a Windows 365, el escritorio virtual de Azure y los usuarios tradicionales de MSTSC. Luego echamos un vistazo a cómo podemos reducir el riesgo de algo llamado captura de credenciales. Primero busque para poder probar Mimikatz, debe descargar la herramienta Mimikatz. Como puede ver en la captura de pantalla a continuación, la protección del defensor antivirus en tiempo real bloquea esto como un valor predeterminado. Sin embargo, al deshabilitar el antivirus de defensor de Microsoft, podemos descargar la herramienta de prueba. Como puede ver en la captura de pantalla a continuación, podría lanzar Mimikatz sin interrupción de Endpoint Security/Microsoft Defender. Cuando miraba a mi alrededor dentro de Mimikatz, por defecto pude extraer mucha información sobre el usuario, la sesión SID, etc. No es algo que desee compartir o poner a disposición. La buena noticia es que puede evitar la extracción de datos de LSA utilizando una clave de registro (protección LSA). La clave para establecer es: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlset \ Control \ lSA y establecer el valor de la clave de registro para: «RunAsPPL» = DWORD: 00000001. Puede leer más sobre la protección de LSA aquí: https://docs.microsoft.com/windows-server/security/credentials-potection-and-management/configuring-additional–protection La captura de pantalla a continuación muestra la entrada del registro que se aplica. Una vez que haya aplicado la entrada del registro y haya reiniciado su máquina, recibo el siguiente error al intentar generar información LSA, como se muestra en la captura de pantalla a continuación. Ahora que hemos resuelto este problema de generar LSA, echemos un vistazo a las credenciales de descarga de los servicios terminales. El vertido de credenciales antes de ingresar a este tema, al momento de la escritura, no hay forma de detener el vertido de credenciales si el mal actor obtiene acceso al sistema para MSTSC, el escritorio virtual de Azure y Windows365. Por lo tanto, la única forma de evitar que este problema ocurra es endurecer la seguridad cuando sea posible para restringir/evitar que los malos actores obtengan acceso a los sistemas. Como puede ver en la captura de pantalla a continuación, tuve éxito en descargar mis credenciales en Windows365, Azure Virtual Desktop y MSTSC. No tengo la intención de entrar en los detalles de cómo se obtienen estas credenciales, pero según tengo entendido, hoy no es una forma de prevenir el ataque usando Mimikatz. También observo que los proveedores de seguridad han tomado medidas en un intento de evitar que los usuarios descarguen y ejecuten Mimikatz, sin embargo, eso no resuelve el problema. También anotará de las comunidades de seguridad, evitar AV no es demasiado difícil de lograr. El otro punto que quería abordar era, ¿qué detiene una exploit creada que puede lograr el mismo objetivo que Mimikatz? Mimikatz es una herramienta de prueba de explotación utilizada para comprender el riesgo/impacto y probar el ataque, sin embargo, los troyanos y otras técnicas probablemente serán más difíciles de detectar. Incluso con encender todas las campanas y silbatos, como la seguridad del sistema operativo Harding, el lanzamiento de confianza y otros como Credential Guard, Mimikatz aún podía obtener esas credenciales. Puede ver en la captura de pantalla a continuación, pude volcar los detalles de mi cuenta de prueba después de pasar tiempo endureciendo el sistema operativo. El siguiente tweet detalla algunas de las pruebas completadas en el intento de fortalecer la seguridad, pero solo para demostrar el punto, no importa cuántas capas adicionales de protección agregan aquí, el agarre de las credenciales aún es posible. RD Web Client Al principio no pude obtener las credenciales utilizando el WebClient. Sin embargo, después de enviar mensajes a Benjamin Delpy, pudo actualizar la versión de Mimikatz, en menos de 13 horas. Los tweets a continuación muestran mis hallazgos iniciales de no poder extraer los credículos del usuario y el segundo tweet muestra que @gentilkiwi puede recopilar credenciales remotas del cliente web. No estoy, así que, si se trata de una conexión de consola, no está relacionado con RDP. Este ejemplo fue para mostrar que no hay protección de credencial u otra protección de procesos. Como puede o no saber, muchos proveedores hoy han construido sus soluciones alrededor de RDP. Si un mal actor puede obtener acceso a su sesión remota, sus credenciales podrían ser obtenidas. ¿Qué puedes hacer para reducir el riesgo? La pregunta dorada … Así que aquí voy a cubrir algunas cosas para ayudarlo a reducir el riesgo, sin embargo, estos consejos no evitan la captura de credenciales. Autenticación de factores múltiples: se recomienda que use la autenticación de dos factores. Algunos pueden decir que esto es tan útil como una guardia de fuego de chocolate, sin embargo, es mejor tener una segunda verificación que ninguna. Credenciales de administración: asegúrese de que los usuarios solo tengan los permisos requeridos para el escritorio. En la mayoría de los entornos VDI, aparte de las computadoras de escritorio persistentes, no existe una necesidad real de permisos de administración. Evite la interacción con Microsoft Defender Antivirus: evitar que el usuario acceda a la consola AV puede ayudar y, si el administrador, debe considerar evitar que los usuarios accedan al antivirus de defensor de Microsoft. Protección de LSA: agregue la clave de registro para la protección de LSA como se cubre en este artículo. Endurecimiento de seguridad del sistema operativo: aplique el endurecimiento de seguridad según lo recomendado por Microsoft. Locker de aplicaciones: evite el software no deseado con el bloqueador de aplicaciones. Detección / respuesta del punto final o detección y respuesta extendida: con el aumento significativo de las amenazas en los últimos años, se recomienda encarecidamente que considere una solución integrada de seguridad de punto final que combina el monitoreo continuo en tiempo real y la recopilación de datos de punto final con capacidades automatizadas de respuesta y análisis automatizadas basadas en reglas. Las sugerencias anteriores ayudarán a reducir el riesgo de un mal actor de acceso a los sistemas, sin embargo, no detiene la capacidad de obtener credenciales. Benjamin Delpy también hizo algunas recomendaciones de las que debe tomar nota. 1. Al no usar contraseñas (Hello / Smartcards) 2. Mediante el uso de Guard de credencial/Guardia de credencial remota (y depende … Mimilib también es un proveedor de autores) 3. Al preguntarle a Microsoft por qué deben mantener la credencial aquí cuando incluso LSASS no las necesita. Comenzamos a buscar extraer información de LSA sobre el usuario, cómo prevenirla y luego pasar al tema principal del agarre de credenciales. Se estableció que al momento de escribir se puede evitar que la credencial se acumule en Windows365, escritorio virtual de Azure y MSTSC (probado). Sin embargo, puede aplicar controles de seguridad y técnicas de endurecimiento para reducir el riesgo de que un mal actor obtenga acceso para ejecutar dichos ataques en su red. ¡Este fue un trabajo bastante interesante que tengo que decir, y un gran agradecimiento a Benjamin Delpy y Marc-André Moreau por contribuir y proporcionar información!