La comunidad de TI recordó a fines de junio de 2017, debido a la infección masiva de muchas empresas e instituciones gubernamentales más importantes en Ucrania, Rusia, Alemania, Francia y algunos otros países con un nuevo ransomware Petya (NotPetya). En la mayoría de los casos, tras su penetración en una red corporativa Petya se extendió rápidamente a todos los ordenadores y servidores de un dominio, paralizando así hasta 70-100% de toda la infraestructura de Windows. Aunque uno de los métodos que Petya usó para propagarse a las computadoras de la red fue el exploit EternalBlue (como en el caso del malware WannaCry), no fue el canal principal de distribución del ransomware. A diferencia de WCry, que se propaga solo debido a la vulnerabilidad SMBv1, NotPetya había sido diseñado para atacar redes corporativas. Una vez que el sistema se había infectado, el malware obtuvo las credenciales (contraseñas, hashes) de los usuarios de la computadora con la ayuda de los disponibles Mimikatz herramienta y los usó para expandirse más en la red a través de WMI y PsExec, hasta un control total sobre el dominio. Entonces, para protegerse, no fue suficiente instalar la actualización de seguridad MS17-010.
En este artículo, veremos las técnicas básicas para defender los sistemas Windows en el dominio de Active Directory contra ataques de herramientas similares a Mimikatz.
Usando el módulo sekurlsa, Mimikatz permite extraer contraseñas y hashes de los usuarios autenticados que se almacenan en LSASS.EXE (Servicio de subsistema de seguridad local ) proceso del sistema. Ya hemos tenido un artículo que da el ejemplo del uso de mimikatz para obtener las contraseñas de los usuarios en texto claro (de WDigest, LiveSSP y SSP).
Cómo evitar la obtención de privilegios de depuración
En el artículo que sigue al enlace anterior, puede ver cómo el uso del privilegio de depuración permite a Mimikatz obtener acceso al proceso del sistema LSASS y extraer las contraseñas.
De forma predeterminada, los permisos para usar el modo de depuración se otorgan al grupo de administradores locales (BUILTIN Administrators). Aunque en el 99% de los casos los administradores no utilizan esta función (por regla general, es necesaria para los programadores del sistema), por lo que por motivos de seguridad es mejor deshabilitar SeDebugPrivilege. Puedes hacerlo usando GPO (local o de dominio). Ir Configuración de la computadora -> Configuración de Windows -> Configuración de seguridad -> Políticas locales -> Asignación de derechos de usuario y habilitar la política Programa de depuración. Agregue el grupo de usuarios de dominio que pueden necesitar privilegios de depuración (como regla, estos son los desarrolladores) o deje este grupo vacío para que nadie tenga estos privilegios.
Ahora, si intenta obtener privilegios de depuración usando mimikatz, aparecerá el siguiente error:
ERROR kuhl_m_privilege_simple ; RtlAdjustPrivilege (20) c0000061
Deshabilitar WDigest
El protocolo WDigest apareció en Windows XP y se usó para realizar la autenticación HTTP Digest que usaba contraseñas de usuario en texto sin cifrar. La función para prohibir totalmente el almacenamiento de contraseñas en texto sin cifrar en LSASS apareció en Windows 8.1 y Server 2012 R2. Para prohibir el almacenamiento de WDigest en la memoria, en estos sistemas operativos existe el parámetro DWORD con el nombre UseLogonCredential y el valor 0 en la siguiente rama del registro: HKEY_LOCAL_MACHINE System CurrentControlSet Control SecurityProviders WDigest.
Si desea deshabilitar completamente el método de autenticación WDigest, establezca el valor de Negociar parámetro a 0 en la misma rama registral (HKEY_LOCAL_MACHINE System CurrentControlSet Control SecurityProviders WDigest).
Para habilitar esta función en Windows 7, 8 y Windows Server 2008 R2 / 2012, instale KB2871997 actualice y luego configure estas claves en el registro. En el entorno de dominio, es más fácil distribuir las claves de registro mediante GPO.
Consejo. Si desea deshabilitar el almacenamiento de WDigest en la memoria, primero pruebe si los usuarios y las aplicaciones están correctamente autenticados en sus servidores IIS.
Protección LSA contra la conexión de módulos de terceros
En Windows 8.1 y Windows Server 2012 R2, apareció una oportunidad para habilitar la protección LSA que brindaba protección a la memoria LSA y evitaba que los procesos desprotegidos tuvieran acceso a ella. Para habilitar este tipo de protección, cree RunAsPPL parámetro con el valor 1 en la siguiente rama registral: HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control LSA.
Después de que se haya aplicado este parámetro, un pirata informático no podrá acceder a la memoria LSA y mimikatz devolverá el siguiente error a securlsa :: contraseña de inicio de sesión mando:
ERROR kuhl_m_securlsa_acquireLSA : Handle on memory (0x00000005).
Cómo deshabilitar LM y NTLM
Un protocolo obsoleto de autenticación LM, un almacenamiento de hashes LM, respectivamente, debe desactivarse usando Seguridad de red: no almacenar el valor hash de LAN Manager en el siguiente cambio de contraseña política de grupo (en el nivel de la política de dominio predeterminada).
Entonces debe dejar de usar al menos el protocolo NTLMv1 (la política en la sección Configuración de la computadora -> Políticas -> Configuración de Windows -> Configuración de seguridad -> Políticas locales -> Opciones de seguridad – Seguridad de red: restringir NTLM: autenticación NTLM en este dominio), o NTLMv2 también, que es incluso mejor.
Si la desactivación de NTLMv1 normalmente no presenta ningún problema, tendrá que esforzarse un poco para desactivar NTLMv2. En las grandes infraestructuras, por regla general, llegan al escenario de máxima restricción en el uso de NTLMv2. Significa que la autenticación Kerberos debe usarse siempre que sea posible (tendrá que dedicar algún tiempo a configurar la autenticación Kerberos en IIS y SQL), y el resto de los sistemas deben conservar NTLMv2.
Cómo deshabilitar el cifrado reversible
Debe prohibir explícitamente el almacenamiento de contraseñas de usuario en AD en texto sin cifrar. Para hacerlo, habilite la política de dominio Almacene la contraseña mediante cifrado reversible para todos los usuarios del dominio en Configuración de la computadora -> Configuración de Windows -> Configuración de seguridad -> Políticas de cuenta -> sección Política de contraseña y establezca su valor en Discapacitado.
Grupo de seguridad de usuarios protegidos
Al usar el nivel funcional del dominio de Windows Server 2012 R2, puede usar un grupo de seguridad especial Usuarios protegidos para proteger a los usuarios privilegiados. En particular, estas cuentas están protegidas contra el riesgo debido al hecho de que los miembros del grupo pueden autenticarse solo usando Kerberos (no NTLM, WDigest o CredSSP, etc.). Siga el enlace de arriba para obtener más información. Es mejor agregar las cuentas de los administradores de dominios y servidores a este grupo. Esta función está disponible en los servidores y estará disponible en Windows Server 2012 R2 (para Windows Server 2008 R2 tendrá que instalar lo mencionado anteriormente KB2871997 actualizar).
Cómo prevenir el uso de contraseñas guardadas
Puede evitar que los usuarios del dominio almacenen sus contraseñas en Credential Manager para acceder a los recursos de la red.
Para hacerlo, habilite Acceso a la red: no permita el almacenamiento de contraseñas y credenciales para la autenticación de red. política en la sección Configuración del equipo -> Configuración de Windows -> Configuración de seguridad -> Políticas locales -> Opciones de seguridad.
Nota. Tenga en cuenta que el almacenamiento de contraseñas también estará prohibido para los trabajos del Programador de tareas.
Cómo deshabilitar el almacenamiento en caché de credenciales
Una de las funciones de mimikatz es obtener hashes de contraseñas de usuario de HKEY_LOCAL_MACHINE SECURITY Cache clave del registro, donde se guardan los hashes de contraseña de los últimos 10 (de forma predeterminada) los usuarios del dominio que han iniciado sesión. Por lo general, estos hash se pueden utilizar para autenticar a los usuarios en el sistema si el controlador de dominio no está disponible.
Se recomienda prohibir el almacenamiento de las credenciales en caché habilitando Inicio de sesión interactivo: número de inicios de sesión anteriores en caché (en caso de que el controlador de dominio no esté disponible) política en Configuración de la computadora -> Configuración de Windows -> Política local -> Opciones de seguridad cambiando el valor de su parámetro a 0.
Además, para acelerar el borrado de la memoria LSASS de las credenciales de los usuarios desconectados, cree un parámetro DWORD con el nombre TokenLeakDetectDelaySecs y el valor de 30 en HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Lsa. Significa que la memoria se borrará en 30 segundos después de que el usuario haya cerrado la sesión. En Windows 7, 8 / Server 2008R2, 2012, deberá instalar la actualización KB2871997 mencionada anteriormente para que esta clave funcione.
Guardia de credenciales
En Windows 10 Enterprise, Windows Server 2016 ha aparecido un nuevo componente, Credential Guard, que permite aislar y proteger LSASS del acceso no autorizado. Para obtener más información, haga clic aquí.
Conclusión
Los métodos considerados anteriormente permiten restringir considerablemente las oportunidades de mimikatz y otras herramientas para obtener contraseñas y hashes de los administradores de LSASS y del registro del sistema. De todos modos, si decidió implementar estas políticas y métodos, debe hacerlo paso a paso con pruebas obligatorias.
En el próximo artículo consideraremos las mejores prácticas para mejorar la seguridad en las redes de Windows debido a las restricciones de uso de cuentas de administrador que deberían mejorar la protección del dominio de Windows contra tales ataques a nivel técnico y organizacional. ¡Esté atento a las actualizaciones!
