Automating Red Team Homelabs: Part 1 – Kali Automation

Homelab infrastructure got you down? Well, not anymore! This is the first post of a 3-part series that will talk about how to automate your home lab, from your kali box to all your vulnerable and domain-joined test vms. It will teach you how to keep your infrastructure dynamic, idempotent, and resilient (a necessity for when you crash all those services during exploitation). You can even take these practices to your pentesting job, because all the tools that will be included in these posts can be used with public cloud infrastructure as well!

Starting with the basics

To start out, we will need something to do pentesting with, and as anyone in security knows that usually means we start out with kali (except for web applications, then it is SamuraiWTF).  As you scour the web there are countless videos on how to install kali, and normally they include the process of updating your system (i.e. apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y), but it becomes difficult to regularly maintain (I like at least monthly updates). Depending on your Internet connection, how many packages you have to install, computer quality, etc.. it could take a long time. When a repetitive task takes me more than a total of 10 minutes, my answer is to always script it! Wait…script an installation? Why yes, script an installation…in a way.

Tools

We have our great friends at Hashicorp to thank for the majority of these tools to help automate our installation process. These tools were originally designed for devops engineers, but why not have the devops community support tools the red team community can use to attack them faster than before? Tons of people use these tools in the devops community for production environments, so these tools should be here for the foreseeable future.

 

For this blog post, we will go over the tools packer and vagrant, and then I will give you links for things to play with for the next post. Packer is used for “scripting” the installation process (from iso to ova), while vagrant is the ecosystem we are putting our kali image into and pulling down from the vagrant cloud.

 

Process

Here is what it would look like.

packer_vagrant_eco
packer vagrant ecosystem

You build your customized kali linux image with packer, fully up to date with all of the latest tools you want, and after you are done provisioning, you would push the image up to vagrant cloud. Once there is a new image available on vagrant cloud for your kali machine, you will get a message that notifies you the next time you start your virtual machine (vagrant checks every time you start a vm to see if there is an updated one so you can be notified if there is). When you get the notification, you would run the box update command to pull down the new image, while still using the one you have downloaded. Then once the new image is downloaded, you can destroy the one you are currently using and use the freshly updated kali box.

Resources

When dealing with vagrant boxes it is best not to reinvent the wheel, so vagrant cloud is amazing. Some common vagrant boxes that have been created are made are ubuntu (from canonical), hashicorp (the people who created these tools), and bento (made and maintained by chef). We aren’t getting into the nitty gritty of things this time, but we will get acquainted with the tools first. Naturally for any technical blog, good documentation is king, packer and vagrant aren’t exceptions. They are extremely well documented! So if you have any questions that I don’t address in the documentation on my github repo, then checkout their documentation. If you have further questions, submit an issue on github to me. I will be more than happy to help!

I know I am a hands on learner, so before we wrap this up I am going to give you some basic commands you can use to play with vagrant. Once we have a box we like (*cough**cough*…like the one I built, and will show you how to build), then we will initialize the vagrant environment.

…till next time

CAUTION: When dealing with vagrant and pulling down vms, or creating development environments, it can get out of hand quickly…your Vagrantfiles will be everywhere! So, initially, I would have a centralized location where you put all your Vagrantfiles (which is created when you initialize your environment). Also, these are boxes built by other people, so be sure to inspect their source code before installing them on your machine(s). We don’t want another docker incident. This is why I am showing you how to build your own.

 

So once you install vagrant and virtualbox, run these two commands:

$ vagrant plugin install vagrant-vbguest

$ vagrant init elrey741/kali-linux_amd64


The first command will install a plugin to manage the virtualbox guest additions installed in the vagrant box you download, if it has a different version. The second will prepare you to download the box while giving you a message that says something like this:

A `Vagrantfile` has been placed in this directory. You are now

ready to `vagrant up` your first virtual environment! Please read

the comments in the Vagrantfile as well as documentation on

`vagrantup.com` for more information on using Vagrant.


So far we have the following directory structure:

/home/$USER/vagrant
└── blog_post
    └── Vagrantfile


From here, check out the Vagrantfile that was created. This is what vagrant uses to control your vm, and you can do more configuration to your vm through this file. You would want to do this to ensure that if you destroy the box then it will still have the same configuration the next time you start up the vm. So let’s provision this box a bit. In the Vagrantfile there should be a line that looks like this:

# config.vm.provision "shell", inline: <<-SHELL


Edit the line to match the following. Ensure you have everything spaced properly for vagrant to read it correctly ( you can run
vagrant validate to ensure that your file is good)

config.vm.provision "shell", path: "prov.sh"


You might be wondering…what is
prov.sh? Well, we are about to create it! In kali the metasploit framework is essential, and you will almost always have to initialize the database when you start a new kali image. To make things easier for you, we will create a script to do just that and let vagrant run it for us. We will name it prov.sh (to match the Vagrantfile) and include the following:

#!/usr/bin/env bash

# initializing the msf db
msfdb init
# start up after reboot
systemctl enable postgresql.service


So now when you start up the vm it will always initialize the msfdb, and that is one less thing you have to do.

 

If you would like to view this all together, checkout my github repo, and if you want to keep playing around with vagrant, I would suggest looking at vagrant’s getting started guide. That will go into a lot more detail than I did. But, you have now completed your first steps toward an automated home lab! I look forward to explaining how to automatically build your own customized kali image in the next post. I will also talk more in depth about advanced vagrant configurations so you can do even less work in the future. Happy hacking!

 

4 thoughts on “Automating Red Team Homelabs: Part 1 – Kali Automation”

  1. Hi Alex,

    Thank you for a great article.
    I have one suggestion though.
    I don’t fully understand the necessity of prov.sh script.
    Seems to me that enabling the db on startup – “systemctl enable postgresql.service” – is an easier way of starting msfdb.

    My two cents.

    1. Hey Alex,
      Thank you for the comment!

      So two things to comment on what you said:

      1st, the reason why I do msfdb init instead of systemctl enable/start postgresql.service is because the msfdb command is actually a script that initializes some database values to prepare for metasploit. If you only did the systemctl command that would only start and then enable the database. I will probably include the systemctl enable postgresql.service command as well though, so when rebooted the (already established database from the msfdb command) will come back up automatically. Thanks for the improvement 🙂

      2nd, the reason why I mention about the prov.sh script is that vagrant goes through a process of what is called “provisioning” when the virtualbox image(ova) is imported. In that step you can configure the script to do whatever you want, I will get more into the detail of this in the next post, but essentially whatever you put in prov.sh is automatically executed after import. So if you use that prov.sh script and put in there the update command (apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y), it will grab any updates to packages that have happened since I created the kali image. All of this will happen without you have to type anything into the vm’s terminal at all, and before you even enter the vm during the vagrant up command.

      Just to summarize, I use the prov.sh script in general to have the vm provisioned how I would like it, before I even ssh into the vm. I use the msfdb init command to initialize variables specific to metasploit into the database, but I will be using your idea of including systemctl enable postgresql.service. Sorry for such a long response…just trying to be thorough.

      P.S. if you want you me to I can include you github name in the comment of my commit for the revision, or if you want to you can submit a pull request with that fix (if you don’t know how to that is perfectly fine as well), just email me at alex(at)secureideas.com if you want me to.

      Thank you again for the comment! Hope you have a great day!

Leave a Comment

Your email address will not be published. Required fields are marked *