Hola a todos,
Continuamos con el tercer post del taller, en este caso con la enumeración del directorio activo teniendo en cuenta el entorno Windows que comentamos en el primer post.
Cabe recordar que nuestro punto de partida (para los olvidones xd):
- Máquina workstation-01 bajo el dominio brihuega.local
- Usuario -> v.lozano:
- No es administrador local
- Usuario del dominio brihuega.local sin permisos destacables.
- Restriciones habilitadas: AV, CLM y AMSI
Antes de pasar a las herramientas de apoyo para esta labor, se va a ver la manera más «rudimentaria» a la par que útil. Desde la propia consola de cmd en una máquina en dominio se pueden hacer consultas al DC. A continuación, se muestran algunos casos:
Enumeración de usuarios del DA:
Enumeración de los grupos del DA:
Mientras para ver los usuarios de un grupo. En este caso, se van a listar los usuarios del grupo top «Domain Admins»:
Para llevar a cabo la enumeración del directorio activo clásicamente se hace uso de las siguientes herramientas:
Obviamente ambas herramientas están super «trilladas» por los AV’s y enseguida lo van a pillar de ahí que haya que tunearlas con las herramientas o mecanismos que vimos en el post anterior.
En primer lugar, emplearemos Powerview.ps1 con autollamada haciendo uso de la herramienta powershellveryless que vimos anteriormente. ¿En qué consiste la autollamada en powershell? Se basa en escribir al final del script la llamada a la función que queramos. A continuación, se muestra un ejemplo:
De tal manera, que al cargar el script en memoria ya realizará la llamada a la función obteniendo el resultado directamente. En la siguiente imagen se puede ver la enumeración de usuarios (Get-NetUser):
Enumeración de grupos del DA (Get-NetGroup):
Enumeración de los equipos (Get-NetComputer):
Enumeración del dominio:
Enumeración sesiones (Get-NetSessions) y usuarios logueados (Get-NetLoggedon)
Buscar logones de administradores (Find-LocalAdminAccess):
Otra función muy interesante es la búsqueda de carpeta compartidas públicas (Find-DomainShare -CheckShareAccess), aunque en este caso, no hay resultados.
Una vez visto esto, se puede deducir cuáles son los targets finales (Domain Admins):
- n.brihuega
- a.adams
Para ello, se tendrá que chequear si se han dejado algún logon en alguna máquina diferente al DC, la cual sería se sumaría a la lista de objetivos, o bien existe algún tipo de delegaciones (Unconstrained or constrained). Para esta labor es muy útil Bloodhound.
En el taller, se explicaron las diferentes queries y el uso y filtrado de la interfaz gráfica. Para no hacer más largo el post se deja algunas referencias:
- https://bloodhound.readthedocs.io/en/latest/index.html
- https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/bloodhound
- https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-with-bloodhound-on-kali-linux
- https://www.pentestpartners.com/security-blog/bloodhound-walkthrough-a-tool-for-many-tradecrafts/
A continuación, se va a enumerar posibles abusos de funcionalidades de Kerberos respecto a kerberoasting y asreproast que se vio en el primer post. Para ello, se usarán los siguientes scripts, entre ellos, el Rubeus que se tuneó en el post anterior.
Kerberoasting
- Invoke-Kerberoast.ps1. Este script enumerará aquellos usuarios con el SPN (Service Principal Name) habilitado. Dada la limitación de CLM es necesario emplear las herramientas de los posts anteriores, así como con autollamada.
Este script a día de la realización del taller no estaba siendo detectado por el defender, pero sí se pone nervioso y quiere enviar una muestra para analizar.
- Powerview.ps1. Mediante la función Get-DomainUser -SPN:
- Morenus: Se deja la captura con el AV para que se vea que no os engaño xd
Como se aprecia en cualquier de las tres maneras, se obtiene la cuenta «mssql_svc» y el hash del kerberos. Ahora la idea sería aplicar fuera bruta contra lo obtenido a ver si hay suerte.
Cabe recordar que las cuentas con el atributo SPN habilitado está más enfocado a cuentas de servicios, por lo que no deberían encontrar cuentas de usuarios,… otra cosa es la realidad en entornos empresariales.
Asreproast
- Invoke-Asreproast.ps1 (Este no va siempre muy fino)
- Morenus:
Como se observa hubo suerte y se obtiene el usuario a.rodriguez. Ahora se aplica fuerza bruta sobre el hash de kerberos y en esta ocasión sí hubo suerte y se obtiene su contraseña (vamos!).
Hay que recordar que para llevar a cabo esta enumeración tan sólo ha sido necesario disponer de una cuenta de usuario en el dominio sin ser necesario escalar privilegios de manera local.
¿Cuál es el siguiente paso? Buscar si el usuario a.rodriguez tiene acceso a otras máquinas del dominio, y en tal caso ver si en esas máquinas puede existir algún logon de un domain admin.
En el siguiente post, se seguirá desde este punto y se detallará el proceso de movimiento lateral, las herramientas que harían falta y cómo evitar las medidas de protección de Windows.
Referencias
https://www.tarlogic.com/es/blog/tickets-de-kerberos-explotacion/
https://www.tarlogic.com/es/blog/como-funciona-kerberos/
https://www.tarlogic.com/es/blog/como-atacar-kerberos/
https://zer1t0.gitlab.io/posts/attacking_ad/
https://gist.github.com/HarmJ0y/184f9822b195c52dd50c379ed3117993
https://zflemingg1.gitbook.io/undergrad-tutorials/powerview/powerview-cheatsheet
Nos vemos en el siguiente.
La mejor defensa es un buen ataque.
N4xh4ck5