Changing passwords should not be done unless there is no other way. It is not good practice, practically speaking. In the real world, it might cause unintended lose of privileges.
If you look at bloodhound, you will find another means of owning the target account.
Privesc was not as intuitive as i though by looking at bloodhound, but thanks to some hints I got it to work. Foothold was pretty straight forward. DM if you need a nudge
Still stuck on the user flag. i have two kerberoastable but can not crack it. i also have access to the db and i am able to execute commands with xp_cmdshell but i canât find anything interesting.
Iâm having issues, not sure if its a bug but when trying to login in with sql creds I get: âSwitching to TLS
Unable to login because its an untrusted domainâ any ideas? my nmap scan outputted a few rsa certsâŚwondering if it had something to do with that?
This was a fun box and very fustrating at times, but here are a few hints to help people:
User:
Remember to check the machine description for the default credentials
Enumerate everything. If you struggling to open a certain file, trying unzipping it and reading the contents of these files and it may reveal what youâre looking for
Accessing a certain service might not work with one method, but another method may prove useful
Configuration files are your friend
You can never go wrong with password spraying
Root:
As this is an AD enviornment, there is a particular user who we want to own once inital access has been established who may issue certificates. Make sure to run Bloodhound against the target, identify this user and abuse the recommended commands
Certipy is your friend
You may require the -dns [Target IP] and -dc-ip [Target IP] on your flags for one of the final commands
Feel free to drop me a message if you would like any further pointers Make sure to include what youâve found out already!