Huy Kha | Arquitecto Senior de Identidad y Seguridad

El dilema del intruso es la otra cara del dilema del defensor, que explica los retos de la defensa de la ciberseguridad. Mientras que la defensa del Directorio Activo (AD) contra todas las técnicas de ataque posibles es el reto para los defensores, los atacantes tienen un problema diferente: una vez que irrumpen, tienen que evitar que les pillen.

Puede que los atacantes sólo necesiten encontrar un punto débil para acceder, pero pasar desapercibidos es mucho más difícil. Necesitan mantener el acceso, moverse lateralmente, escalar privilegios y ejecutar sus objetivos sin activar alarmas o ser bloqueados.

¿Y si pudiéramos convertir el dilema del intruso en nuestra ventaja?

Cómo convertir un ataque en una defensa AD práctica

Comprender las formas en que los malos actores buscan y utilizan las vulnerabilidades es fundamental para la defensa AD. Para ilustrar el valor de este conocimiento, señalemos un método común de ataque a la identidad que aprovecha las desconfiguraciones de los certificados.

Los ataques contra los servicios de certificación de Active Directory (AD CS) han recibido una gran atención después de que SpecterOps publicara una investigación sobre cómo se pueden explotar las configuraciones erróneas en AD CS para la escalada de privilegios y la persistencia. Su informe Certified Pre-Owned1 describía varias técnicas, como ESC1, ESC4 y Golden Certificates, que permiten a los atacantes abusar de la autenticación basada en certificados para comprometer cuentas privilegiadas. Desde que se publicó esta investigación, los actores de amenazas y los equipos rojos han utilizado cada vez más estas técnicas comoarmas2 , lo que convierte a AD CS en un objetivo de gran valor.

Aquí es donde los defensores pueden cambiar las tornas. Cuando se configura un honeypot -como una plantilla de certificado señuelo que parece vulnerable- los atacantes se ven obligados a tomar una decisión. Pueden intentar explotar lo que parece un error de configuración, arriesgándose a exponerse en el proceso, o ignorarlo y buscar otra forma de escalar privilegios.

Imagine que un atacante que busca plantillas de certificados mal configuradas encuentra una en la que tiene derechos de modificación. Puede intentar activar el Supply in Request que les permitiría especificar una identidad privilegiada en una solicitud de certificado.

La trampa está preparada.

DESCARGO DE RESPONSABILIDAD: Desplegar una plantilla de CA señuelo y hacerla intencionadamente vulnerable a ataques como ESC1 y ESC4 amplía la superficie de ataque. Sin embargo, con los mecanismos de seguridad adecuados para detectar y corregir estas amenazas, puede ser un enfoque eficaz.

Creación de una trampa honeypot con una plantilla de certificado señuelo: Ejemplo 1

La figura 1 muestra lo que encuentra un atacante cuando utiliza una herramienta como Certify3 para buscar plantillas de certificados explotables.

Figura 1. Esta plantilla de certificado vulnerable otorga a los ordenadores de dominio control total, lo que permite su modificación.

Este certificado, CiscoSSLVPNadmite la autenticación de clientes y permite la inscripción de equipos de dominio. Pero como msPKI-Certificate-Name-Flag no está configurado como ENROLLEE_SUPPLIES_OBJECTel ataque ESC1 no funcionará.

Cuando el atacante mira los atributos AD del CiscoSSLVPN certificado (Figura 2), ven que el msPKI-Certificate-Name-Flag se establece en 134217728que corresponde a SUBJECT_ALT_REQUIRE_DNS. Esto significa que el Supply in Request no está activada.

Figura 2. Salida de PowerShell Esta salida de PowerShell muestra CiscoSSLVPN atributos de plantilla de certificado, con msPKI-Certificate-Name-Flag ajustado a 134217728indicando SUBJECT_ALT_REQUIRE_DNS.

Dado que en este ejemplo concedimos a los ordenadores de dominio control total sobre esta plantilla de CA, nuestro atacante podría aprovecharse de msDs-MachineAccountQuota (Figura 3), que se establece en 10 por defecto, para crear un nuevo objeto de ordenador, autentifíquese como la cuenta del ordenador y, a continuación, modifique la Plantilla CA.

Figura 3. Salida de PowerShell Esta salida de PowerShell muestra el uso de Powermad para crear una nueva cuenta de máquina (TestPC) aprovechando msDs-MachineAccountQuotaque se fija en 10 por defecto en AD.

A continuación, el atacante se autentica como la cuenta del ordenador y modifica la plantilla CA para hacerla vulnerable a ESC1(Figura 4).

Figura 4. Esta sesión PowerShell nos ejecuta como el TestPC$ cuenta de la máquina, modificando el msPKI-Certificate-Name-Flag en el CiscoSSLVPN plantilla de certificado para hacerla vulnerable a ESC1.

Ahora, nuestro atacante comprueba los atributos AD de la plantilla CA modificada. Ellos ven que el msPKI-Certificate-Name-Flag ha cambiado (Gráfico 5), que refleja la modificación que lo hace explotable.

Figura 5. Esta salida de PowerShell muestra el CiscoSSLVPN plantilla de certificado, donde el msPKI-Certificate-Name-Flag ha cambiado, haciéndolo vulnerable a ESC1.

En el lado de la defensa de AD: En Directory Services Protector DSP)ahora puede ver una entrada que registra el cambio de AD en la plantilla de CA señuelo(Figura 6), resaltando el atributo específico que se modificó.

Figura 6. Nuestro registro DSP muestra la modificación del CiscoSSLVPN plantilla de certificado, donde el msPKI-Certificate-Name-Flag lo que permite investigar más a fondo la cuenta responsable de la acción.

DSP también muestra quién modificó la plantilla CA(Figura 7), lo que le permite investigar la cuenta responsable del cambio y detectar cualquier otra actividad sospechosa.

Figura 7. Nuestro registro DSP también confirma que el CiscoSSLVPN plantilla de certificado fue modificada por el TestPC$ cuenta de ordenador.

Creación de una trampa honeypot con una plantilla de certificado señuelo: Ejemplo 2

En WebServer se utiliza habitualmente para emitir certificados SSL/TLS para Windows Server Update Services (WSUS), Active Directory Federation Services (ADFS), servidores web de Internet Information Services (IIS) y equilibradores de carga. Garantiza la comunicación cifrada a través de HTTP. Por defecto, está configurado con Supply in Requestpero como el uso extendido de claves (EKU) está fijado en Server AuthenticationESC1 no puede explotarse (Figura 8).

Figura 8. Aquí, PowerShell muestra los atributos de la etiqueta WebServer plantilla de certificado, mostrando que Supply in Request (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) está activado, pero el EKU está ajustado a Server Authentication.

Para preparar nuestra trampa, puedes empezar duplicando el archivo WebServer y dándole un nombre realista para que parezca legítima. A continuación, modifica la DACL para que parezca una configuración legítima permitiendo una cuenta de equipo falsa, como por ejemplo WSUS-2016para inscribirse.

Al mismo tiempo, desconfigura intencionadamente la plantilla concediendo permisos de escritura a los usuarios autenticados(Figura 9), lo que crea una oportunidad de explotación.

Figura 9. Salida de PowerShell Nuestra salida PowerShell muestra la plantilla de certificado WebServer modificada, donde una cuenta de equipo falsa (WSUS-2016$) tiene permisos de Enroll, y los Usuarios Autenticados han sido mal configurados con permisos de Escritura, haciendo la plantilla vulnerable a la explotación.

Figura 10 muestra cómo se ve el reconocimiento para un atacante que identifica plantillas de CA explotables, donde los Usuarios Autenticados tienen permisos de Escritura en el señuelo. WSUSSSLCert plantilla.

Figura 10. Esta salida de PowerShell muestra WSUSSSLCert plantilla de certificado, en la que los usuarios autenticados tienen WriteProperty lo que les permite modificar atributos como EKU.

Ahora, nuestro atacante examina los valores de atributo AD actuales de esta plantilla CA, centrándose específicamente en el atributo msPKI-Certificate-Application-Policy que define el uso permitido del certificado (Figura 11).

Figura 11. Salida de PowerShell que muestra los atributos del archivo WSUSSSLCert plantilla de certificado, destacando el msPKI-Certificate-Application-Policy valor. El identificador de objeto 1.3.6.1.5.5.7.3.1 corresponde a Autenticación del servidor.

Ahora, modifican esta plantilla de CA para hacerla explotable ESC1, luego comprueban cómo el msPKI-Certificate-Application-Policy cambios de valor (Gráfico 12).

Figura 12. PowerShell muestra la modificación del WSUSSSLCert plantilla de certificado, donde el msPKI-Certificate-Application-Policy ha pasado a ser 1.3.6.1.5.5.7.3.2activando la autenticación de cliente. Este cambio hace que la plantilla sea vulnerable a ESC1.

En Gráfico 13 espectáculos, el msPKI-Certificate-Application-Policy se ha actualizado a un identificador de objeto diferente, que ahora corresponde a la autenticación de cliente.

Figura 13. PowerShell muestra la actualización WSUSSSLCert plantilla de certificado, donde el msPKI-Certificate-Application-Policy se ha cambiado a 1.3.6.1.5.5.7.3.2habilitando la autenticación de cliente. Ahora, la plantilla no sólo es vulnerable, sino que también es explotable para ESC1.

El último paso que da nuestro atacante es conceder permisos de inscripción en la plantilla de CA, lo que le permite explotarla(Figura 14).

Figura 14. Este fragmento muestra cómo el atacante ha concedido a los usuarios autenticados permisos de inscripción en la carpeta WSUSSSLCert plantilla utilizando PowerView.

En el lado de la defensa AD: En DSP, ahora hay una entrada en el registro de cambios AD que indica que alguien ha modificado este atributo AD específico en la plantilla CA(Figura 15).

Figura 15. Nuestro registro DSP muestra una modificación del WSUSSSLCert plantilla de certificado, donde el msPKI-Certificate-Application-Policy se ha cambiado de Autenticación de servidor a Autenticación de cliente.

Se registrará otra entrada en DSP indicando que se ha modificado el atributo Security Descriptor en la plantilla de CA señuelo(Figura 16).

Figura 16. El registro DSPrevela la modificación del Descriptor de Seguridad en el WSUSSSLCert Plantilla CA.

La clave de los señuelos en la defensa AD: Crear una regla de notificación en DSP

En DSP, puede crear una regla de notificación para las plantillas de certificados señuelo(Figura 17), de modo que cualquier cambio que se realice en ellas active una alerta.

Figura 17. Esta regla de notificación DSP , establecida para el WSUSSSLCert plantilla de certificado, está configurado para activar una alerta cada vez que se realice una modificación en el msPKI-Certificate-Application-Policy atributo.

Una vez que alguien modifique este atributo AD en la plantilla CA señuelo, DSP enviará una notificación por correo electrónico que incluirá detalles sobre quién realizó el cambio, en qué Controlador de Dominio se produjo y otra información relevante(Figura 18).

Figura 18. Una notificación por correo electrónico DSP le avisa de los cambios realizados en la plantilla de CA señuelo.

Instantánea de Semperis

Para las organizaciones que utilizan ADCS, la creación de trampas de honeypot puede ser una forma valiosa de detectar a los atacantes antes de que puedan escalar privilegios. Las configuraciones erróneas de ADCS se explotan cada vez más en ataques reales, como destaca el informe de Mandiant4 sobre las tácticas de post-explotación de Ivanti. Mediante el despliegue de plantillas de certificados señuelo que parezcan vulnerables pero que estén estrechamente vigiladas, los defensores de AD pueden atraer a los atacantes para que se revelen en el momento en que intenten la explotación.

Más información sobre la defensa proactiva de Active Directory

Referencias

  1. https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
  2. https://attack.mitre.org/techniques/T1649/
  3. https://github.com/GhostPack/Certify
  4. https://cloud.google.com/blog/topics/threat-intelligence/ivanti-post-exploitation-lateral-movement