Defendiendo el Relevo de las Tres Cabezas

May 10 2022
Un blog conjunto escrito por Andrew Schwartz, Charlie Clark y Jonny Johnson Introducción Durante las últimas semanas se ha hecho evidente que Kerberos Relaying se ha convertido en uno de los temas de debate más candentes para la comunidad de InfoSec. Aunque este ataque no es nuevo y fue descubierto hace meses por James Forshaw, recientemente ha despegado porque ha aparecido una nueva herramienta llamada KrbRelayUp que toma el trabajo de James y automatiza ese proceso para cualquiera que quiera explotar esta actividad.

Un blog conjunto escrito por Andrew Schwartz , Charlie Clark y Jonny Johnson

Introducción

Durante las últimas semanas se ha hecho evidente que Kerberos Relaying se ha convertido en uno de los temas de debate más candentes para la comunidad de InfoSec. Aunque este ataque no es nuevo y fue descubierto hace meses por James Forshaw , recientemente ha despegado porque ha aparecido una nueva herramienta llamada KrbRelayUp que toma el trabajo de James y automatiza ese proceso para cualquiera que quiera explotar esta actividad. Sin embargo, esta herramienta no solo explota el trabajo de James, sino también el trabajo de Elad Shamir en torno a S4U2Self/S4U2Proxy , mientras usa el código de Rubeus de Will Schroeder .. Nosotros, como grupo (Andrew, Charlie y Jonny), encontramos esto interesante, ya que vimos muchas detecciones de "Kerberos Relay" que en realidad podrían no detectar "Kerberos Relay" si la acción se realizó por sí misma, sino más bien después de la explotación. acciones, digamos en la actividad S4U.

Durante esta publicación de blog, echaremos un vistazo a Kerberos Relay, desglosaremos las diferentes rutas de ataque que se podrían tomar y hablaremos sobre las diferentes oportunidades defensivas vinculadas a esta actividad y otras actividades previas a Kerberos Relay o posteriores.

Explicación de la retransmisión de Kerberos

La retransmisión de Kerberos se describió en detalle en la publicación del blog de James Forshaws " Uso de Kerberos para ataques de retransmisión de autenticación ".”. El objetivo principal de la retransmisión de Kerberos es interceptar un AP-REQ y retransmitirlo al servicio especificado dentro del nombre principal del servicio (SPN) utilizado para solicitar el vale de servicio (ST). El mayor descubrimiento dentro de la investigación de James es que, al usar ciertos protocolos, se puede obligar a un cliente víctima a autenticarse ante un atacante que usa Kerberos y, al mismo tiempo, permitir que se especifique un SPN que difiera del servicio al que se está conectando el cliente. Esto significa que el cliente solicitará un ST para un SPN elegido por el atacante, creará un AP-REQ que contenga ese ST y se lo enviará al atacante. Luego, el atacante puede reenviar este AP-REQ al servicio de destino, ignorar el AP-REP resultante (a menos que el atacante necesite retransmitirlo al cliente por algún motivo) y, en este punto, establecer una sesión autenticada como el cliente víctima.

Si bien existen otras posibles formas en que puede ocurrir la retransmisión de Kerberos (es decir, como ataques de intermediario (MITM), el enfoque principal de esta publicación será obligar a un cliente a autenticarse ante el atacante como método de recepción el AP-REQ. El proceso es esencialmente el siguiente:

El atacante obliga a la autenticación del cliente víctima con el SPN del servicio de destino -> el cliente solicita ST al SPN especificado -> el cliente envía AP-REQ al atacante -> el atacante extrae AP-REQ y lo envía al servicio de destino -> el atacante establece una sesión como cliente víctima

Hay algunas advertencias en este proceso. El primero son las protecciones habilitadas en el servicio de destino. Al igual que con la retransmisión NTLM, si el servicio de destino tiene firma/sellado o vinculación de canales, la autenticación Kerberos de retransmisión no funcionará. La segunda advertencia son las protecciones admitidas por el cliente. Con algunos protocolos de destino, si el cliente indica soporte para ciertas protecciones, el servidor habilitará esas protecciones, nuevamente haciendo que la retransmisión de Kerberos no sea posible sin algún otro error en la implementación.

Posibles rutas de ataque con Kerberos Relay

Hay varias rutas de ataque potenciales que permite la retransmisión de Kerberos. Muchos de estos fueron documentados por James en su publicación inicial de blog. Como se mencionó anteriormente, hay 2 consideraciones principales cuando se analizan las rutas de ataque de retransmisión de Kerberos:

  1. El protocolo utilizado para activar la autenticación del cliente víctima.
  2. El protocolo utilizado por el servicio al que se retransmite la autenticación.

Como se mencionó, el requisito principal para el protocolo de activación es la capacidad del atacante de especificar un SPN arbitrario, o al menos un SPN parcialmente controlado por el atacante, al activar la autenticación. Los protocolos que se sabe que potencialmente tienen este requisito son:

  • IPSec y AuthIP
  • MSRPC
  • DCOM
  • HTTP
  • LLMNR
  • MDNS

Según las protecciones habilitadas en el servidor, se sabe que los siguientes protocolos son protocolos de servicio de destino para la retransmisión de Kerberos:

  • LDAP/LDAPS
  • HTTP
  • PYME

Detección de retransmisión de Kerberos

Antes de sumergirnos directamente en las detecciones, las consultas y los indicadores de actividad para estos comportamientos, creemos que es importante tocar qué estamos buscando para la detección y por qué. Es bastante fácil tomar una herramienta que realiza algún comportamiento e inmediatamente mirar los registros para ver qué telemetría existe. Este no es un enfoque terrible, simplemente no es el único ni el que tomamos.

A nosotros (Charlie, Andrew y Jonny) nos gusta abordar esta pieza de detección de manera un poco diferente al dividir la capacidad de una herramienta, comprender lo que está tratando de lograr, comprender las tecnologías vinculadas a un ataque y sus capacidades e identificar qué acciones (si es necesario). cualquiera) se aplican a otras técnicas. Luego, nos gusta encontrar el comportamiento central en el que se basa el ataque e identificar qué partes de esa acción son o pueden ser controladas por un atacante. Este proceso nos ayuda a identificar qué comportamientos están relacionados explícitamente con el ataque y cuáles podrían estar relacionados con una acción que se realizó antes o después del ataque. Una cosa que no queremos hacer es crear una detección vinculada explícitamente a la herramienta, sino al ataque.

Dicho esto, cada ataque tendrá una acción previa, intra y posterior. Estas acciones se extraen durante el proceso de investigación y nos ayudan a evaluar qué capacidades estamos tratando de detectar. Vamos a explicar.

Para que se ejecute un ataque, un atacante debe hacer algo que le dé la capacidad de realizar esa acción. Esto podría ser una serie de cosas, usemos lo siguiente como un ejemplo de actividad previa a la acción:

  • Obtener acceso a un usuario de dominio
  • Comprometer/obtener un punto de apoyo en una caja
  • Ejecute una consulta LDAP para el reconocimiento
  • Escalar a un administrador local/Alta IL
  • Kerberoast
  • Volcar LSASS
  • Suplantación de token de acceso
  • Inicia sesión como usuario
  • Suplanta al usuario

Esto nos permite aplicar un enfoque de capas de detección al crear detecciones para estos comportamientos porque va a haber algo dentro de la acción previa que podemos relacionar con la acción interna y, de manera similar, la acción interna con la acción posterior. Debido a esto, podemos cambiar un poco el diagrama:

Como probablemente ya sepa, cada acción posterior conduce a una acción previa. Reinicia el flujo de ataque. Vemos esto a continuación con Kerberos Relay. Una posible acción posterior es realizar S4U2Self/S4U2Proxy. Kerberos Relay ahora se ha convertido en una acción previa a esta actividad y una acción posterior podría ser que un atacante esté usando esa capacidad para iniciar sesión, hablar con el SCM para crear un servicio y ejecutar un proceso como SISTEMA.

Si solo ejecutamos el ataque y observamos directamente los registros, es fácil comenzar a hacer suposiciones. Entonces, antes de ejecutar el ataque, podemos romper lo que estamos buscando y luego ir a buscarlo. Esto nos permite comprender verdaderamente qué capa estamos aplicando una detección, lo que inherentemente nos ayudará a comprender qué nivel de cobertura tenemos.

Ahora podemos aplicar esto a Kerberos Relay en la siguiente sección.

Consultas de detección

Algunos de los ataques dentro de las acciones pre/intra/post se aplicaron debido a cómo KrbRelayUp estaba explotando esta actividad. El atacante no siempre tiene que tomar estas rutas exactas y algunos de los detalles pueden cambiar, por ejemplo: a continuación, mostramos una detección para la inicialización del servidor COM/conexión TCP. Un atacante podría usar un protocolo diferente como HTTP/LDAP. Aunque no creamos consultas para cada uno de estos escenarios, queríamos compartir las diferentes detecciones previas, intra y posteriores a la acción que alguien podría crear.

Detecciones de retransmisión previas a Kerberos:

  • Punto de apoyo inicial del usuario del dominio (no se agregó detección ya que hay muchas opciones)
  • Consultas LDAP para identificar posibles SPN disponibles
  • Cuenta de computadora agregada a través de LDAP (usando Microsoft Defender para Endpoint DeviceEvents)
  • DeviceEvents
    | where ActionType contains “LdapSearch” and (InitiatingProcessParentFileName !has (“services.exe”) or InitiatingProcessAccountName !in (“local service”, “system”))
    | extend SearchFilter= extractjson(“$.SearchFilter”, AdditionalFields)
    | where SearchFilter contains “sAMAccountName” and SearchFilter contains “$”
    | summarize count() by Timestamp, InitiatingProcessAccountName,InitiatingProcessParentFileName, InitiatingProcessFileName, SearchFilter, InitiatingProcessCommandLine, AdditionalFields, InitiatingProcessLogonId
    

  • Cuenta de computadora añadida a través de Splunk y Windows Security Event ID 4741:
  • index=windows sourcetype=Security EventCode=4741 AND SAM_Account_Name = “*$”
    

    index=windows (EventCode=4741 MSADChangedAttributes=*(*HOST/*) AND *(*RestrictedKrbHost/*) New_UAC_Value=0x80) OR (EventCode=4673 Privileges=SeMachineAccountPrivilege) 
    | eventstats values(Process_Name),values(Privileges),values(EventCode) as EventCode by Logon_ID 
    | search EventCode=4741
    | rex field=_raw “(Message=(?<Message>[a-zA-z ].*))” 
    | eval datetime=strftime(_time, “%m-%d-%Y %H:%M:%S.%Q”) 
    | stats count values(datetime),values(Process_Name),values(Privileges),values(EventCode),values(MSADChangedAttributes),values(Message),values(Account_Domain),values(Security_ID),values(SAM_Account_Name),values(DNS_Host_Name) by Logon_ID 
    | search count >=2 
    | rename values(*) as * 
    | eval Effecting_Account=mvindex(Security_ID,1) 
    | eval New_Computer_Account_Name=mvindex(Security_ID,0) 
    | table datetime,Account_Domain,Effecting_Account,Logon_ID,New_Computer_Account_Name,DNS_Host_Name,Message,MSADChangedAttributes,Process_Name,Privileges,EventCode
    

  • Conexión del servidor DCOM con conexión TCP a localhost (usando Splunk y Windows Security Event ID 5156):
  • index=windows sourcetype=Security EventCode=5156 Direction=Inbound AND Source_Address=::1 AND Destination_Address=::1 AND Process_ID !=4 AND Protocol=6
    

  • Explotación de RBCD (usando Splunk y Windows Security Event ID 5136/4768/4769)
  • index=windows sourcetype=”Security” ((EventCode=5136 AND “msDS-AllowedToActOnBehalfOfOtherIdentity”) AND (Type=”Value Added” OR Type=”Value Deleted”)) OR EventCode=4768 OR EventCode=4769 
    | eval alt_type=mvindex(Type,2) 
    | eval datetime=strftime(_time, “%m-%d-%Y %H:%M:%S.%Q”) 
    | bucket _time span=11m
    | stats dc(EventCode) as eventcodes,values(EventCode),values(datetime),values(LDAP_Display_Name),values(host),values(Account_Domain),values(Client_Address),values(Service_Name),values(Service_ID),values(Ticket_Options),values(Class),values(Ticket_Encryption_Type),values(alt_type) by _time 
    | rename values(*) as *
    | where eventcodes >=3
    | table _time,datetime,host,Account_Domain,Client_Address,Service_Name,Service_ID,Ticket_Options,Ticket_Encryption_Type,Class,LDAP_Display_Name,alt_type,EventCode,eventcodes
    

Mitigaciones

  1. Limite el atributo MAQ y/o restrinja SeMachineAccountPrivilege a un grupo específico en lugar de Usuarios autenticados
  2. Protección ampliada para autenticación (EPA) /Firma de protocolo/Sellado y enlace de canales
  3. Deshabilitar mDNS/LLMNR
  4. Requerir IPsec/IKEv2 autenticado
  5. Deshabilitar Deshabilitar NTLM

Conclusión

Durante este artículo, queríamos dar una breve explicación de Kerberos Relay, cómo se puede explotar y los diversos niveles de detección/prevención que se pueden aplicar. Aunque no analizamos todos los escenarios previos y posteriores a la explotación que un atacante podría tomar, queríamos resaltar la importancia de pensar en los ataques desde una perspectiva previa, intra y posterior a la acción. Esto nos ayuda a identificar el alcance de nuestras detecciones, lo que luego nos permitirá identificar a qué profundidad estamos aplicando la detección.

Esperamos que esto haya sido útil y muchas gracias a James Forshaw nuevamente por su trabajo anterior en esto.

Referencias

  • https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html
  • https://googleprojectzero.blogspot.com/2021/10/windows-exploitation-tricks-relaying.html
  • https://dirkjanm.io/relaying-kerberos-over-dns-with-krbrelayx-and-mitm6/
  • https://github.com/Dec0ne/KrbRelayUp
  • https://github.com/cube0x0/KrbRelay

© Copyright 2021 - 2022 | unogogo.com | All Rights Reserved