Defendiendo un dominio de Windows de ataques con mimikatz

Buen día comunidad, me encontré con esta gran información realizada por la gente de woshub (http://woshub.com/defending-windows-domain-against-mimikatz-attacks/) y traducido al español por Pamela Martinez Ruiz de Castilla (https://www.linkedin.com/pulse/defensa-del-dominio-de-windows-contra-los-ataques-pamela/) de donde tomó textualmente toda la información así que todos los créditos para ellos, yo solo quiero compartirles esta información que me pareció súper relevante ya que cada vez es más común este tipo de ataques en nuestras redes Microsoft.

Sin más que añadir y dejando claro los créditos de los autores pasó a compartirles este gran contenido:

La comunidad de TI conocida desde fines de junio de 2017, debido a la infección masiva de muchas de las compañías más grandes e instituciones gubernamentales en Ucrania, Rusia, Alemania, Francia y algunos otros países con un nuevo ransomware Petya (NotPetya). En la mayoría de los casos, después de su penetración en una red corporativa, Petya se extendió rápidamente a todas las computadoras y servidores de un dominio, paralizando hasta el 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), pero no fue el principal canal de distribución de ransomware. A diferencia de WCry, que se propaga solo debido a la vulnerabilidad SMBv1, NotPetya se diseñó para atacar redes corporativas. Después de que el sistema se infectó, el malware obtuvo las credenciales (contraseñas, hashes) de los usuarios de computadoras con la ayuda de la herramienta pública Mimikatz y las usó para extenderse más en la red a través de WMI y PsExec, hasta el control total del dominio . Entonces, para protegerse contra esto, no fue suficiente solo instalar la actualización de seguridad MS17-010.

En este artículo, veremos las técnicas básicas para defender los sistemas de Windows en el dominio de Active Directory contra los ataques de herramientas similares a Mimikatz. Al usar el módulo sekurlsa, Mimikatz permite extraer contraseñas y hash de los usuarios autenticados que están almacenados en el proceso del sistema LSASS.EXE (Servicio de Subsistema de Seguridad Local). Ya hemos tenido un artículo que da el ejemplo del uso de mimikatz para obtener contraseñas de usuario en texto claro (de WDigest, LiveSSP y SSP).

Cómo evitar tener privilegios de depuración

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 usan esta característica (como regla, es necesario para los programadores del sistema), por lo que para fines de seguridad es mejor desactivar SeDebugPrivilege. Puede hacerlo usando GPO (local o dominio uno). Vaya a Configuración del equipo -> Configuración de Windows -> Configuración de seguridad -> Políticas locales -> Asignación de derechos de usuario y habilite el programa de depuración de políticas. Agregue el grupo de dominio de usuarios 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 utilizando mimikatz, aparecerá el siguiente error:

ERROR kuhl_m_privilege_simple; RtlAdjustPrivilege (20) c0000061

Nota. Sin embargo, las restricciones de esta política se pueden eludir fácilmente. Ver artículo: http://woshub.com/obtain-sedebugprivilege-debug-program-policy-enabled/

Deshabilitando WDigest

El protocolo WDigest apareció en Windows XP y se utilizó para realizar autenticación HTTP Digest que usaba contraseñas de usuario en texto claro. La función para prohibir totalmente el almacenamiento de contraseñas en texto claro en LSASS apareció en Windows 8.1 y Server 2012 R2. Para prohibir el almacenamiento de WDigest en la memoria, en estos SO está 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 por completo el método de autenticación WDigest, establezca el valor del parámetro Negociar en 0 en la misma rama de registro (HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SecurityProviders \ WDigest).

Para habilitar esta función en Windows 7, 8 y Windows Server 2008 R2 / 2012, instale la actualización KB2871997 y luego configure estas claves en el registro. En el entorno de dominio, es más fácil distribuir las claves de registro usando GPO.

Tip: Si desea deshabilitar el almacenamiento de WDigest en la memoria, primero compruebe si los usuarios y las aplicaciones están autenticados correctamente en sus servidores IIS.

En Windows 8.1 y Windows Server 2012 R2, apareció la oportunidad de habilitar la protección LSA que proporcionaba protección de memoria LSA y evitaba que los procesos desprotegidos accedieran a ella. Para habilitar este tipo de protección, cree el parámetro RunAsPPL con el valor 1 en la siguiente rama de registro: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ LSA.

Después de aplicar este parámetro, un hacker no podrá acceder a la memoria LSA, y mimikatz devolverá el siguiente error al comando securlsa :: logonpassword:

ERROR kuhl_m_securlsa_acquireLSA: Manejar en la memoria (0x00000005).
Cómo deshabilitar LM y NTLM

Cómo deshabilitar LM y NTLM

Un protocolo obsoleto de autenticación LM, un almacenamiento de hash LM, respectivamente, debe deshabilitarse usando Seguridad de red: No almacenar valor hash de LAN Manager en la próxima contraseña Cambiar la política de grupo (en el nivel de la Política de dominio predeterminada).

Luego debe dejar de usar al menos el protocolo NTLMv1 (la política en la sección Configuración del equipo -> Políticas -> Configuración de Windows -> Configuración de seguridad -> Políticas locales -> Opciones de seguridad - Seguridad de red: Restringir la autenticación NTLM: NTLM en este dominio), o NTLMv2 también, que es aún mejor.

Si la deshabilitación de NTLMv1 normalmente no tiene ningún problema, deberá esforzarse para deshabilitar NTLMv2. En las grandes infraestructuras, como regla, llegan al escenario de máxima restricción en el uso de NTLMv2. Significa que la autenticación Kerberos debe usarse donde sea posible (tendrá que dedicar algún tiempo a configurar la autenticación Kerberos en IIS y SQL), y el resto de los sistemas debe conservar NTLMv2.

Comentarios

  • Cómo deshabilitar el cifrado reversible

    Debería prohibir explícitamente el almacenamiento de contraseñas de usuario en AD en texto claro. Para hacerlo, habilite la contraseña de dominio de la política de dominio usando cifrado reversible para todos los usuarios en el dominio en la Configuración del equipo -> Configuración de Windows -> Configuración de seguridad -> Políticas de cuenta -> Política de contraseña y establezca su valor en Desactivado.

    Grupo de seguridad de usuarios protegidos

    Al utilizar el nivel funcional del dominio de Windows Server 2012 R2, puede usar un grupo de seguridad especial Usuarios protegidos para proteger a los usuarios con privilegios. En particular, estas cuentas están protegidas contra el riesgo debido al hecho de que los miembros del grupo pueden autenticarse solo con Kerberos (sin 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 dominio y servidores a este grupo. Esta característica está disponible en los servidores y estará disponible en Windows Server 2012 R2 (para Windows Server 2008 R2 deberá instalar la actualización KB2871997 mencionada anteriormente)

    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 el acceso a la red: no permita el almacenamiento de contraseñas y credenciales para la política de autenticación de red en Configuración del equipo -> Configuración de Windows -> Configuración de seguridad -> Políticas locales -> sección 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 características de mimikatz es obtener hashes de contraseñas de usuarios de la clave HKEY_LOCAL_MACHINE \ SECURITY \ Cache del registro, donde se guardan los hash de contraseñas de los últimos 10 (por defecto) registrados en los usuarios del dominio. Por lo general, estos valores hash se pueden usar para autenticar usuarios en el sistema si el controlador de dominio no está disponible.

    Se recomienda prohibir el almacenamiento de las credenciales almacenadas en caché habilitando el Inicio de sesión interactivo: Número de inicios de sesión anteriores en la política de caché (en caso de que el controlador de dominio no esté disponible) en Configuración del equipo -> Configuración de Windows -> Política local -> Opciones de seguridad cambiando el valor de su parámetro a 0.

    Además, para acelerar la eliminación de la memoria LSASS de las credenciales de 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 antes mencionada para hacer que esta clave funcione.

    Credencial Guardia

    En Windows 10 Enterprise, Windows Server 2016 apareció un nuevo componente, Credential Guard, que permite aislar y proteger LSASS del acceso no autorizado. Para más información, haga clic: http://woshub.com/virtual-secure-mode-vsm-in-windows-10-enterprise/

    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 el registro del sistema. De todos modos, si decidió implementar estas políticas y métodos, debe hacerlo paso a paso con las pruebas obligatorias.

    Información realizada por la gente de woshub (http://woshub.com/defending-windows-domain-against-mimikatz-attacks/) y traducido al español por Pamela Martinez Ruiz de Castilla (https://www.linkedin.com/pulse/defensa-del-dominio-de-windows-contra-los-ataques-pamela/) de donde tomó textualmente toda la información así que todos los créditos para ellos

  • Excelente post, algunos detalles menores de la traducción pero entiendo que querías dejarlo tal cual como la chica de linkedin, saludos
Accede o Regístrate para comentar.