How to be a good pentester: have a scalable and maintainable practice environment (Part 2)
In the “How to be a good pentester” series, I share my thoughts on what makes a pentester good, and what I do to try to be one.
In this particular entry, we’ll delve into making a dummy AD environment with servers and workstations through Vagrant, workstation, and Ansible.
Part 2 will be about the technical implementations how such a lab, and is a follow up on my thoughts on what makes a good practice environment.
I took absolutely no measure to secure this lab, and as such, it should not be connected to any real environment.
Do not reinvent the wheel
The set up I went with is based on those three projects : https://github.com/jckhmr/adlab https://github.com/alebov/AD-lab The reason I could not got with one of those projects as is, is because I wanted Vagrant to be installed with my setup; that’s to say a windows based host with vmware pro installed. My set up here :
- Workstation Pro on a Windows Host
- A VM with Kali (or any other OS supported by Ansible) installed within Workstation Pro
- I guess you can also manage that VM through Vagrant/Ansible, but I figured that since I use that VM outside of my lab activities it was not needed to do so
- Vagrant installed on Windows
- (Optional) the git client on the windows Host
- Also, since the target lab has at least 4 VM that can be running at the same time:
- At least 16 Go of RAM (more is actually recommended)
- A pretty good multi core CPU
On the Windows Host
vagrant plugin install vagrant-vmware-desktop
cd [[PATH TO INSTALLATION INSIDE HOST]]
git clone https://github.com/frisch-raphael/AD-lab
On the Kali guest
cd [[PATH TO INSTALLATION INSIDE KALI GUEST]]
ansible-playbook -i hosts labsetup.yml
How to add a new box
I somewhat reworked the Vagrant file so that it is easier to add a new box to the lab.
- Choose a Vagrant box on their site
- Modify the windows_servers_config variable from the VagrantFile
- Go to the root of the project in a command line
- Launch the vm through “vagrant up”
- Create a .yml file with the apprioriate roles (here’s an example for the domain controler)
- Add its ip in the hosts file
- Configure the box with ansible-playbook -i hosts [[name_of_the_yml_file]]
How to modify the configuration of a box
If the configuration applies to all boxes, modify the main.yml file from the common roles folder.
If it applied to only servers, modify the main.yml file from the win_server roles folder
If it applied to the DC, modify the main.yml file from the win_domain_controller roles folder
If it’s a new box, create a new role
How to debug an Ansible Task
Sometimes, an Ansible Task fails and you don’t want to go through every previous task just to get to the one you want to debug.
Having done that too many times before finding this trick, I figured I’d write it here.
If an ansible task doesn’t work, you can just use the –start-at-task parameter with the task’s name as its value.
For exemple :
ansible-playbook -i hosts domain_controller.yml –start-at-task “Configure DNS” -vvv
What could be better
- Install roles. For example, I wanted to test the new ADCS relay attack from ntlmx, and wanted to add the CA and CA web enrollment roles manually.
- I could not install those through Ansible win_feature plugin. Actually, I think it is because after install, those roles need to be configured through the GUI ?
- I figured it was not too bad since those roles are quite specific to the PetitPotam exploit
- Still, if anyone manage to install/configure those roles through Ansible, by all means tell me how you did it
- Configure bloodhound exploitable path to domain admin through Ansible