Home

Lab write-ups

Initialization

$ cd lab/json

First, create the owned file with TRACY's password:

$ cat owned
Tracy:password:Spring2025

General analysis

Take a look first on TRACY's rights. We can see that she is in the group MARKETING and she inherits the right GenericAll on WEBSITE$.

griffon *.json --select tracy

By visualizing the ACL graph (griffon *.json --graph), we can see that the computer WEBSITE$ is not very interesting.

It's also possible to view user descriptions (griffon *.json --desc). Sometimes we can find interesting things, ... but there is nothing here. We need another entrypoint!

Let's go deeper in the analysis. If we list groups, we have two high value groups: SYS and MAINTENERS. They are both in yellow so it means there is a path to domain admin if are in one of these groups. Moreover SYS has a GenericWrite on a GPO. Actually Griffon doesn't propagate ACLs from GPOs (TODO), so we don't know here if we modify the GPO we will find a path to DA.

griffon *.json --groups [--members]

If we list OUs, we can see that the GPO is applied on the OU SERVERS. There 3 computers: PROD$, DATABASE$ and PREPROD$. They are all in yellow too.

griffon *.json --ous --members

Now re-list users. PREPROD$ has a contrained delegation with protocol transition (flag T) to DATABASE$ and can also read the password of the service user SVC$. It means that with PREPROD$ we have two possible scenarios. PROD$ is practically the same as PREPROD$. The difference is that PROD$ doesn't have the flag T so this is a constrained delegation without protocol transition (this delegation is bit more complicated to exploit). Finally, DATABASE$ has only an unconstrained delegation. The keyword many is set by Griffon to tell that the user can impersonate everyone.

griffon *.json

If we look again on user's rights, we can see that two users have an interesting flag: AGENT is kerberoastable (K) and PREPROD_USER has the flag PASSWORD_NOTREQUIRED (!R). The last flag means that the user can set his password to but this is not always the case. We have then two possible entrypoints.

Exploitation

There are many possibilities in this lab. We will exploit only tree paths that cover all the rights excepted the ReadGMSAPassword. In this lab our entrypoints are AGENT and PREPROD_USER. We can use the option --fromv (from vulnerables) to achieve this. In other labs we could have used --fromo (from owned users set in the file) or --from <USER> (test a path from a user)

griffon *.json --fromv --da

You can generate automatically the commands to exploit the path:

griffon *.json --fromv --da --script <NUMBER>

Scenario 1: blank password

We will exploit this path:

• we need to check if PREPROD_USER has its password empty
• perform an RBCD on PREPROD$ by adding a new computer. Other scenarios are possibles, take a look into config.ml: you can comment the line you don't want.
• constrained delegation with protocol transition from PREPROD$
• unconstrained delegation from DATABASE$
• dcsync

Scenario 2: kerberoasting and RBCD

We will exploit this path:

• kerberoast AGENT and crack the TGS to retrieve its password
• add AGENT in the group MAINTENERS
• change the password of SVC$ (more scenarios in config.ml)
• perform an RBCD on PROD$. It's not necessary to add a computer here because we already have a user with a SPN, it's less intrusive.
• constrained delegation without propagate transition from PROD$
• unconstrained delegation from DATABASE$
• dcsync

Scenario 3: kerberoasting and GPO

We will exploit this path:

• kerberoast AGENT and crack the TGS to retrieve its password
• modify the GPO and choose the scenario the shortest scenario with GPOAddLocalAdmin
• unconstrained delegation from DATABASE$
• dcsync