Mitigar los ataques Pass The Hash (PtH Attack) – Parte III

Continuando con la serie de mitigación de ataques Pass The Hash (PtH Attack), hoy trataremos de respuestas a estos incidentes, y como las organizaciones pueden protegerse.

Una organización puede preparar distintas estrategias para llevar a cabo esta mitigación. El objetivo es prevenir tanto el movimiento horizontal, es decir, que un usuario pueda acceder a otros equipos de la organización con las credenciales obtenidas mediante el ataque PtH, como de la escalada de privilegios, movimiento vertical. Para lograr estos objetivos se deberá disminuir el impacto del robo de credenciales o reutilización ilícita en los equipos Windows.

Las medidas que presentamos no tienen unos requisitos previos importantes, por lo que se pueden implementar de forma rápida en la organización con el fin de mitigar estos ataques y otras posibles amenazas relacionadas.

• Restringir y proteger las cuentas privilegiadas del dominio. Por ejemplo, no utilizar la cuenta de administrador de dominio en equipos de usuarios o servidores no importantes, ésta podría ser cacheada por el proceso lsass.exe, por lo que podría "ser encontrada" por un usuario malicioso. Con esta acción se evita el movimiento vertical, escalada de privilegios, pero no el movimiento horizontal.
• Restringir y proteger las cuentas locales que disponen de privilegios administrativos. Se fortalece la política contra el movimiento horizontal del usuario malicioso.
• Restringir el tráfico de entrada mediante el Firewall de Windows. Con esta acción se fortalece la política contra el movimiento horizontal.

Hay que indicar que implantar estas tres mitigaciones no son tarea sencilla, al menos en dos de ellas. El esfuerzo requerido para implantar la restricción de cuentas privilegias en el dominio y la restricción del tráfico es importante. Por otro lado, la restricción y protección de cuentas locales con privilegios requiere un esfuerzo bajo en comparación con las anteriores. Eso sí, las tres mitigaciones expuestas anteriormente son bastante eficientes a la hora de protegerse contra este tipo de ataque.

Por otro lado existen unas recomendaciones interesantes que complementan a las tres soluciones expuestas anteriormente:

• Eliminar a los usuarios estándar del grupo de administradores. Con esta recomendación, la cual es eficiente y lógica, permite luchar contra la escalada de privilegios.
• Limitar el número y uso de las cuentas privilegiadas en un dominio. Otra capa más para evitar la escalada de privilegios.
• Configurar el proxy para denegar la salida a Internet de cuentas privilegiadas. De nuevo otra capa más para evitar la escalada de privilegios.
• Asegurar que las cuentas administrativas no disponen de cuentas de e-mail.
• Utilizar herramientas de gestión que no coloque las credenciales en la memoria del equipo remoto. De nuevo intentamos evitar la escalada de privilegios, ya que un usuario podría capturar las credenciales en memoria.
• Evitar los inicios de sesión de los equipos menos seguros que sean potencialmente comprometidos en el futuro.
• Mantener los sistemas operativos y aplicaciones actualizados.
• Securizar y gestionar los Domain Controllers.
• Eliminar los LM Hashes. Este hecho es difícil en muchas compañías, por temas de compatibilidad entre distintas versiones de sistemas operativos.

Por último, comentar que existen otras mitigaciones que tienen una menor efectividad, pero que pueden ayudar y mucho a los administradores a securizar su entorno empresarial y mitigar el impacto de PtH Attack.

• Deshabilitar el protocolo NTLM. Este hecho no será posible en muchas ocasiones, se requiere de un gran esfuerzo por parte de la empresa y su efectividad es mínima.
• Uso de SmartCard y segundo factor de autenticación.
• Reinicio de equipos de trabajo y servidores. Las estaciones de trabajo podrán ser reiniciadas, para "olvidar" las credenciales cacheadas y disponibles en memoria, a la espera que de el usuario maliciosa las capture, pero el reinicio de un servidor es bastante más complejo, sobretodo si su rol es de producción.

Tras el resumen vamos a entrar en detalle con la primera mitigación.Mitigación 1: Restringir y proteger las cuentas privilegiadas del dominioLas organizaciones suelen permitir que las cuentas de privilegio alto o privilegiadas, como por ejemplo los usuarios que son miembros del grupo Administradores de dominio, se utilicen para llevar a cabo tareas generales de administración, para conectarse a escritorios de usuario u otros sistemas utilizados para el correo electrónico y/o navegación por Internet. Este hecho expone que estas credenciales puedan ser robadas por atacantes mediante la exploración de la memoria del sistema.Es altamente recomendable restringir el uso de este tipo de cuentas para que sólo se puedan utilizar para iniciar sesión en los sistemas controlados y seguros que lo requieran. Además, permitir el uso de la delegación de Kerberos con cuentas privilegiadas puede hacer que sea más fácil para un atacante reutilizar dichas credenciales. El objetivo principal de esta mitigación es reducir el riesgo de que los administradores sin saberlo expongan sus credenciales con altos privilegios en los equipos de mayor riesgo, que suelen ser las estaciones de trabajo de los empleados y los servidores no críticos.Para completar con éxito esta primera mitigación, se proponen distintas tareas:

• Restringir las cuentas de administrador de dominio y otras cuentas privilegiadas en servidores y estaciones de trabajo de confianza baja.
• Proporcionar a los administradores la posibilidad de realizar sus tareas administrativas con otras cuentas de usuario normales.
• Asignación de puestos de trabajo dedicados a tareas administrativas.
• Marcar las cuentas privilegiadas como sensibles y que no se puedan delegar en Active Directory.
• No configurar servicios o tareas que puedan utilizar cuentas de dominio con privilegios en sistemas de confianza baja, como las estaciones de trabajo de los empleados.

Hay que tener en cuenta que los administradores de dominio que se loguean en un equipo vulnerable o comprometido todavía pueden exponer sus credenciales incluso si se cumplen las tareas recomendadas. Los atacantes podrán capturar dichas credenciales durante la conexión a pesar de que la cuenta no esté autorizada a iniciar sesión.En conclusión, un atacante no puede robar las credenciales de una cuenta si las credenciales no se utilizan en el equipo comprometido. El uso de esta mitigación reduce bastante el riesgo de que un atacante obtenga este tipo de credenciales.En el siguiente artículo hablaremos en detalle de la mitigación dos y tres, y continuaremos tratando este interesante tema, que afecta a todas las empresas con redes Microsoft.