Orchestrating deployment of the hacklab (Part 3): Adding more targets

Expand the target list in your hacklab by adding some more vulnerable and some not so vulnerable users.

Orchestrating deployment of the hacklab (Part 3): Adding more targets

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.

Orchestrating deployment of @myexploit2600′s Hacklab with Ansible
Deploy your hacklab using Ansible for fast, repeatable results. Building on the work by @myexploit2600, we’re going to use Ansible to handle the manual steps of constructing a domain and vulnerable users.

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.

- hosts: server
  gather_facts: true

  - name: Add user with AES-256 encrypted service tickets # next task switches tickets to AES-256
      name: user3
      state: present
      password: Passw0rd!
      update_password: on_create
      - Enterprise Admins
  - name: Switch ticket encryption type for user3 to AES-256
    win_shell: Set-ADUser -Identity "user3" -KerberosEncryptionType AES256

  - name: Create SPN for user with AES-256 tickets
    win_shell: Set-ADUser -Identity user3 -ServicePrincipalNames @{Add='http/server1.hacklab.local:81'}

  - name: Add user with pre-authentication disabled (AS-REP roastable) # next task disables the pre-auth
      name: user4
      state: present
      password: Passw0rd!
      update_password: on_create
      - Backup Operators
  - name: Disable pre-auth for user4
    win_shell: |
      $User = Get-ADUser -Identity "user4" -Properties DoesNotRequirePreAuth
      $User.DoesNotRequirePreAuth = "True"
      Set-ADUser -Instance $User
  - name: Create SPN for user with pre-auth disabled
    win_shell: Set-ADUser -Identity user4 -ServicePrincipalNames @{Add='http/server1.hacklab.local:82'}

  - name: Add Key Delegation Service root key if there isn't one (required for gMSA)
    win_shell: |
      if ((Get-KdsRootKey | Select-Object -Expand Count) -ne 1) { Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10)) }

  - name: Add Group Managed Service Account (gMSA) if doesn't exist
    win_shell: |
      if (!(Get-ADServiceAccount -Filter "Name -eq 'user5'")) { New-ADServiceAccount -Name "user5" -DNSHostName "user5.hacklab.local" -Enabled $True -ServicePrincipalNames "http/server1.hacklab.local:83" -ManagedPasswordIntervalInDays 30 }

  - name: Add user with very strong password
        name: user6
        state: present
        password: "ADqxdFe_#yiq4:DM+9B#l0Z,-x&k)_FF*SqcLgMTYZQ2WKOKaOtpDp#VY).9:AKY"
        update_password: on_create
        - Domain Admins
  - name: Create SPN for user with strong password
    win_shell: Set-ADUser -Identity user6 -ServicePrincipalNames @{Add='http/server1.hacklab.local:84'}

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.

Build, Attack, Defend, Fix – Paving the way to DA
While most of us in the world of offensive security love getting domain administrator (DA) when doing assessments. How many of you know how the issue occurs, how to defend against it and how to properly remediate it?

As always, if you've got questions, I've got answers.

Masthead image credit: Helen Cook, target