If you've been following the guidance from my other two blogs about automating @myexploit2600's hacklab, firstly using Ansible and then Vagrant, or if you already have a hacklab set up, you might now want to add some more vulnerable (and not vulnerable) users to test your tools and tradecraft against.
We're going to employ Ansible again to add 4 more users to the domain. As usual, let's get the playbook and then explore the important parts.
The first user we add to the domain is configured to use AES-256 for Kerberos ticket encryption. However, it still uses a weak password. Simply changing the encryption type in use does not mitigate the risk of kerberoasting.
The second new user has the domain pre-authentication requirement disabled. This means that the user is susceptible to an attack termed AS-REP roasting. In short, you can kerberoast this user without domain credentials. Get yourself onto a logical network location where you can simply communicate with a domain controller and you can now recover kerberos tickets for any user with pre-authentication disabled.
The third user is a group managed service account, meaning that its password is managed automagically. The password set is 240 bytes (120 characters) and is generated in a cryptographically secure fashion. If you crack the password on this account, please let me borrow your access to the NSA's cracking farm.
Important: In order to add the Key Delegation Server root key, we need to be a Domain Administrator, instead of a built-in Administrator on the DC. We can achieve this in one of two ways. We can promote the
vagrant user we've been using for Ansible (which is a built-in admin) or we can change our entry for the DC in our inventory to use
user1 instead as it is already a Domain Admin. It's up to you which way you'd like to do this.
The fourth and final user added has a complex, 64-character, alphanumeric and symbol laden password. Short of adding this password directly to your cracking dictionary, this would be resistant to cracking attempts. Despite the fact the user is still using RC4 encryption for Kerberos tickets, it is exceedingly unlikely that even a brute-force guessing attack would recover the plaintext.
The idea for the accounts added here was inspired by the second instalment of @ZephrFish's Paving the way to DA series, which I highly recommend if you'd like a delicious wine pairing to go with this blog. I'll be rolling another post out soon for adding a victim machine to the domain susceptible to the SYSVOL password storage issue discussed in part 1 of Zephr's series. You can also expect a follow up to this post as Zephr continues his series.
As always, if you've got questions, I've got answers.
Masthead image credit: Helen Cook, target