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 Active Directory environment with servers and workstations through Vagrant, workstation, and Ansible.
Part 1 will be about the goals I set myself for the lab, and in a later part we’ll see how to implement them, and the issues I had to resolve on the way.
How to be a good pentester: have a scalable and maintainable practice environment
I didn’t have much fun with all the somewhat recent exploits, as I was busy developing a pretty big tool, which I hope will be in a state where I can post about it in a few months.
To put my mind off coding, and also to not fall too far behind the new stuff, and also because I have a few engagements coming up, I wanted to have a lab in which I could use as a practice environment.
Having your own lab, with multiple VM and a whole dummy AD, is becoming more and more important, as complete information system take over is switching more and more from abusing traditional exploits (the most famous ones being MS17-010, MS08-67) to authentication relay attacks (such as PetitPotam). And, to test the later, just one VM is not enough, and having a whole AD at your disposal make it way easier to train on those.
The problem with traditional labs
As a matter of fact, I already had a lab, that I created the old fashioned: installing isos by hand, configuring the network, installing the basic tools, etc.
However, such a lab proved to be really hard to maintain, and to grow. What if you somehow broke your AD setup ? May be you took a snapshot of your virtual machines, but then you’ll have to manually roll back all of them.
Also, what if you want to test an exploit that is specific to, let’s say, windows 7 workstation ? And you only have a Windows 10 at your disposal ? Then you have to do everything manually once again : download the ISO, install it, configure the OS, the networking, install the basic tools, etc.
The solution: Infrastructure as Code
IT people that manage non-trivial infrastructure have an elegant solution to that: infrastructure as code
Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. The IT infrastructure managed by this process comprises both physical equipment, such as bare-metal servers, as well as virtual machines, and associated configuration resources.
Definition from Wikipedia
Instead of installing and configuring components of our lab through the means of interactive GUI and such, we can follow the IaC paradigm, and produce code that will do it for us. Once the code is done, we can launch as many lab setup from scratch as we want.
While IaC will help us creating a scalable and maintainable lab, this approach does take a lot more time initially, but that is often the case with coding, security, and to be fair, everything in life.
The technologies: Vagrant and Ansible
For those as new to Vagrant as I was two month ago, Vagrant will manage your hypervisor for you. Instead of installing and configuring you VM through, for example, VMWare workstation, you can use Vagrant to produce code that will do it.
I decided to go with Vagrant with the lab. One reason is that the projects I based my lab on already used Vagrant, and also, Vagrant is said to be optimal for small local setup, while for example TerraForm is preferably used to manage whole datacenters.
As such, Vagrant will be used for the download, creation, and provisioning of the VMs.
One provisioned, the VMs will be configured through Ansible, which will allow us to produce reusable configurations for the servers and workstations, and not have to redo it everytime we want to add one machine.
With those things in mind, here’s the laboraty I set up. As to the technical details on how, I’ll cover that in part 2 :-).