¿Por qué DISA STIG recomienda "Denegar el acceso a esta computadora desde la red" para los administradores de dominio?

  

¿Cómo esta configuración mitiga un ataque de "escalada de privilegios por robo de credenciales"?

La respuesta a la pregunta depende de los detalles precisos de cómo funciona la configuración de Deny access to this computer from the network . Tenemos que entender exactamente qué hace esta configuración antes de poder decir que es útil para mitigar una vulnerabilidad potencial.

¿Qué hace esta configuración?

Esta configuración es un "acceso denegado" forzado para conexiones de red SMB remotas, incluso si las conexiones se permiten por otros medios. Es similar a una entrada "Denegar" en una Lista de control de acceso y se evalúa antes de Allow access to this computer from the network (al igual que con las listas de control de acceso en Windows). Además, es importante comprender que esta configuración no se aplica a las conexiones RDP. Dos ejemplos comunes de conexiones SMB son el comando "Uso de red" y los complementos de MMC, como la herramienta Visor de eventos.

¿Cuál es el riesgo de las conexiones SMB remotas?

Las conexiones SMB remotas no exponen las credenciales en un host remoto. Por lo tanto, esto significa que si me conecto a un sistema comprometido con una cuenta privilegiada utilizando solo una conexión SMB remota (por ejemplo, un complemento MMC), mis credenciales de cuenta privilegiada no están expuestas en el sistema comprometido. / p>

¿Cómo esta configuración mitiga la amenaza de robo de credenciales?

Las conexiones SMB remotas no exponen las credenciales, por lo que no existe amenaza de robo de credenciales. Por lo tanto, la configuración Deny access to this computer from the network no es necesaria para mitigar esta amenaza.

¿Por qué se sugiere esta configuración como remediación para evitar posibles robos de credenciales?

Parece que hay una buena cantidad de malentendidos con respecto a lo que hace Deny access to this computer from the network . Comprendido correctamente, esta configuración no es necesaria para mitigar el robo de credenciales porque las credenciales no están expuestas desde las conexiones SMB remotas.

Explicación a modo de analogía

Supongamos que hay una joven llamada Emilia que ha escuchado que hay una tienda de bolsos que lleva un bolso particular que ella quiere comprar. La tienda está en una parte de la ciudad conocida por un grupo de ladrones que roban sigilosamente las tarjetas de crédito de las personas sin su conocimiento, por lo que la tienda ha intentado reducir algunos precios para aumentar el negocio. Esto sucedió en los días previos a Internet y los sitios web, y ella escucha un comercial en la radio que tienen una bolsa en particular que desea comprar.

Ella quiere verificar el precio por sí misma, por lo que tiene dos opciones: 1) Ir a la tienda y arriesgarse a que le roben su tarjeta de crédito, o 2) llamar a la tienda por teléfono y verificar el precio. (Ella es cuidadosa y se niega a dar su número de tarjeta de crédito por teléfono).

¿Cuál es el riesgo de que le roben el número de su tarjeta de crédito si no conduce físicamente a la tienda de bolsos? Por supuesto, no hay riesgo, ya que su tarjeta de crédito nunca está físicamente allí para ser robada. [Conexión SMB remota: las credenciales no están expuestas] Si ella conduce a la tienda, existe el riesgo de que los ladrones inteligentes le roben su tarjeta de crédito. [Inicio de sesión interactivo = posible robo de credenciales]

En otras palabras, esta pregunta es: si Emilia solo llama a la tienda por teléfono y no da su número de tarjeta de crédito por teléfono, ¿cuál es el riesgo de su crédito? ¿Número de tarjeta que le roban? La respuesta, por supuesto, es que no hay riesgo en ese caso.

Política de procesos frente a política técnica

Parece que DISA recomienda esta configuración para ayudar a las organizaciones a hacer cumplir una buena política de proceso. Esta configuración puede ser útil en ese contexto para evitar que los miembros de Domain Admins se conecten a computadoras remotas utilizando conexiones SMB y busquen otros medios administrativos. Sin embargo, la pregunta se refiere a los detalles técnicos de esta configuración, no a sus procesos . En este momento, parece que la recomendación DISA está dando una descripción técnica incorrecta de esta recomendación, cuando en realidad deberían proporcionar una recomendación de proceso válida.

@ HallowProc tiene una buena respuesta que deseo ampliar más que un comentario.

Lo primero y más importante es que los grupos de administradores de empresas deben estar vacíos y rellenados solo para la rara tarea administrativa.

La única ubicación donde se deben usar las credenciales de administrador de dominio es en los controladores de dominio o en una estación de trabajo administrativa dedicada. Estos sistemas deben ser del más alto nivel de confianza en la organización. El acceso debe estar restringido para que el tráfico administrativo (RDP, WinRM, etc.) solo pueda ser intercambiado por estos sistemas de confianza utilizando IPsec ( Aislamiento de servidor y dominio ). Por lo tanto, solo se exponen los servicios necesarios (Kerberos, LDAP, etc.) a sistemas con un nivel de confianza inferior.

Los sistemas miembros del dominio tienen un nivel de confianza inferior y nunca deben tener un inicio de sesión de administrador de dominio en el sistema. Además, no se debe permitir el acceso a ninguna cuenta de dominio con una amplia gama de permisos de administrador. Un ejemplo de esto es una cuenta con acceso de administrador en todas las estaciones de trabajo miembros del dominio. La amplitud del acceso de administrador debe reducirse a un subconjunto más pequeño.

Al diseñar Active Directory de esta manera, el uso de cuentas privilegiadas se limita a solo unos pocos sistemas. Así que la implementación de este control de seguridad logra lo siguiente:

1. Defensa en profundidad: supongamos que hay una secuencia de comandos que inicia sesión en los controladores de dominio para realizar una tarea ad hoc y hay un error tipográfico. Apuntar el script a una estación de trabajo miembro de un nivel de confianza inferior. Si bien esto debería ser detenido por las reglas de IPsec y otros controles, tener una configuración como esta sería otra capa en la Defensa en profundidad de cebolla. Impide que la cuenta elevada inicie sesión donde se puedan extraer y explotar las credenciales.
2. Limitar movimiento lateral / contención: si bien su pregunta es sobre los administradores de dominio / empresa, la configuración real también incluye las cuentas de administrador local. Esto me lleva a creer que la configuración apunta a mitigar la explotación relacionada con Mimikatz (extracción de token / hash - > Pass-the-Hash / Token). Si Microsoft LAPS se esté utilizando (o algo similar), no estaría tan preocupado por limitar la red Acceso a cuentas de administrador local. Como cada sistema tendría una contraseña única para la cuenta del administrador local. Sin embargo, si una cuenta privilegiada se ve comprometida en una estación de trabajo e intenta acceder a otro sistema, el evento de denegación de inicio de sesión debería generar una alerta. Minimizando el tiempo desde la explotación hasta la contención.
3. Mejora de procesos: mientras que los grandes entornos empresariales son mucho mejores para segregar los privilegios, muchos aún utilizan las credenciales de nivel de administrador de dominio para realizar tareas administrativas en los sistemas miembros. Tener una configuración como esta mejora el proceso, ya que dirige a los administradores de sistemas a separar los permisos en varias cuentas.

En el peor de los casos en que las credenciales de administrador de dominio se ven comprometidas en una estación de trabajo miembro de baja confianza, se puede lograr la contención. Se debe generar una alerta que muestre el uso exitoso de esas credenciales seguido de eventos de acceso denegado. El acceso a la red se bloqueará a los sistemas miembros restantes (a través de esta configuración) y a los controladores de dominio (a través del aislamiento del servidor y del dominio).

Concedido, hay maneras de superar este control en particular, especialmente cuando están involucradas las cuentas Enterprise / Domain Admin. Sin embargo eso significa un adversario mucho más sofisticado. Si ese es el caso, hay más de qué preocuparse entonces esta configuración en particular por sí sola. Creo que esto está dirigido a los escenarios en los que una estación de trabajo de baja confianza se trabaja con helpdesk / sysadmin / one-person-shop. El adversario usa técnicas como las que se usan con mimikatz para probar y girar con esas credenciales (escalada de privilegios).

La configuración no es perfecta, pero ser más específico sería inmanejable para DISA. Cada entorno es diferente y viene con sus propias advertencias. Este ajuste tiene como objetivo lograr el equilibrio.

Estoy de acuerdo con su declaración con respecto a la eliminación del grupo de administradores de dominio del grupo de administradores locales. En su lugar, cree un solo grupo de seguridad global para el grupo de sistemas que se está administrando. Algo así como gs-localadm-room-007. Esto logra que se reduzcan los deberes administrativos, de modo que si esa cuenta estuviera comprometida, no habría ningún efecto en otros silos de seguridad.

Comenzando en la diapositiva 81 de esta presentación por Sean Metcalf de ADSecurity.org - enlace - Sean repasa el AD Admin Tiers y Red Forest concepts.

Si bien Sean no lo menciona, creo que se reduce a configurar Administradores de dominio una vez en un escenario de Nivel-0 / Bosque Rojo y luego usar Políticas de autenticación y silos para bloquear ese concepto de forma permanente. Mark Russinovich y Nathan Ide de la fama de Microsoft los discuten aquí - enlace - y HD Moore de MetaSploit fame (junto con Joe Bialek de Microsoft y Ashwath Murthy de Palo Alto Networks) los analiza en detalle aquí - enlace

Hablando del marco de metasploit, es mejor probar los conceptos aprovechando su marco de ataque, u otros marcos de explotación como PowerShellEmpire, o entre marcos como PowerSploit. Al aprovechar use incognito y más recientemente use kiwi de meterpreter, se puede acceder a los criterios de prueba necesarios para ver dentro de todos los almacenes de credenciales y todo el tráfico de credenciales. Después de ejecutar use kiwi , los comandos kerberos , mimikatz_command -f sekurlsa::logonPasswords -a "full" , msv , livessp , ssp , tspkg y wdigest meterprar están disponibles. Incluso puedes mimikatz_command -f crypto::listStores . Incluso si un usuario como el Administrador de dominio no ha iniciado sesión, puede tomar su ticket pasando el hash con el comando sekurlsa::pth también (aunque necesita el hash de, digamos un paquete NETNTLMv2 o la captura del lado del servicio). Consulte la Guía no oficial de Mimikatz para obtener más información.

Lo interesante de esta recomendación de DISA STIG Deny access to this computer over the network no es que esto evitará que los Administradores de Dominios envíen tráfico NETNTLMv2 al intentar iniciar sesión a través de SMB / CIFS (o cualquier otro protocolo), sino que es una política que pueden No lo haga en primer lugar (si siguen intentando iniciar sesión de forma remota a una política en la que les resulta imposible hacerlo, entonces simplemente están haciendo lo mismo una y otra vez esperando resultados diferentes). Así que es simplemente una política técnica que representa una política y una guía de la vida real: los administradores de dominio no deben iniciar sesión o intentar iniciar sesión en nada a menos que sea para configurar cosas específicas del dominio en un bosque rojo especial u otro escenario de nivel 0.

En realidad, hay formas aún más interesantes de capturar credenciales de administrador de dominio (u otras), como NetRipper , o incluso más con mimikatz (aún más indocumentado). Proteger los secretos de su navegador en un entorno de dominio en BsidesTlv en Tel Aviv recientemente, definitivamente vale la pena echarle un vistazo.

La respuesta a tu pregunta:

  

¿Qué es específicamente una "escalada de privilegios por robo de credenciales"?   ataque en este contexto, ...

es que un ataque de escalada de privilegios por robo de credenciales significa que se obtienen (cosechan) credenciales con privilegios más altos de un sistema al que tiene acceso con un conjunto de credenciales con privilegios más bajos. En este caso, es posible que tenga un administrador local en un sistema, pero si un administrador de dominio inicia sesión y obtiene sus credenciales de ese sistema (a través de Mimikatz, credenciales almacenadas en caché, etc.) ahora ha aumentado los privilegios al robar credenciales de administrador de dominio.

Parte 2:

  

¿Y cómo habilitar esta configuración para mitigarla?

Al evitar que los administradores de dominio inicien sesión en las estaciones de trabajo, mitigará de manera efectiva el riesgo de que las credenciales de DA se puedan obtener de una estación de trabajo. EDIT Además, incluso si las credenciales se recogen de una máquina, este control está diseñado para " disminuye el riesgo de movimientos laterales resultantes de ataques de robo de credenciales ". Entonces, no se trata solo de proteger UNA estación de trabajo, se trata de prevenir el movimiento lateral de una estación de trabajo.

Aunque a veces es difícil descifrar el significado detrás de algunos de los STIG, creo que el concepto principal aquí es que no debe administrar equipos con cuentas de administrador de dominio, dada la naturaleza altamente sensible de esas cuentas.

Esto es del propio STIG:

  

Para las estaciones de trabajo unidas al dominio, el grupo Admins. del dominio debe ser   reemplazado por un grupo de administradores de la estación de trabajo de dominio (ver V-36434 en   el dominio de Active Directory STIG). Restricción altamente privilegiada   Las cuentas del grupo de administradores locales ayudan a mitigar el riesgo.   de la escalada de privilegios resultante de los ataques de robo de credenciales.

Sin embargo, no he probado esta configuración en particular, pero no me sorprendería si esta restricción no tiene ningún efecto. Muchas de las recomendaciones de STIG sobre derechos y privilegios son un poco absurdas y no tienen el efecto deseado y se vuelven automáticamente a los valores predeterminados.

Editar: Esto realmente debe probarse porque no creo que pueda evitar el inicio de sesión del administrador del dominio sin importar la política que establezca o el grupo en el que se encuentren. Los STIG en mi experiencia están mal probados y tienen políticas que no tienen efecto. Por ejemplo, eliminar actuar como parte del sistema operativo de la cuenta del sistema, lo cual no tiene sentido y se revierte automáticamente.

Editar: dado que esta respuesta está siendo rechazada, quiero aclarar que mi respuesta es que estoy de acuerdo con @bill_stewart en que la configuración en cuestión no evita un ataque de robo de credenciales ya que las credenciales no están directamente expuestas. Pero además de eso, estoy diciendo que es probable que la configuración no tenga ningún efecto porque no se puede impedir que un administrador de dominio inicie sesión en una computadora. Mi comentario original [eliminado] sobre los inicios de sesión en caché era una nota al margen y no pretendía ser parte de la respuesta en sí.