Search for a command to run...
Ansible automation for pentesting environments
I was working on privilege escalation techniques in my VM when I made a really dumb mistake. I meant to run one command, but instead I typed tee /etc/passwd followed by random text. The second I pressed enter, I knew I'd messed up. The system froze immediately and wouldn't boot anymore. My files were still on the disk somewhere, but without a working /etc/passwd file, I couldn't access anything.
So there I was, staring at a fresh Kali installation screen again. I started counting all the things I'd need to set up from scratch: Ghidra with my custom settings, Neovim with all my plugins, Tmux the way I like it, my directory structure, my scripts, and probably fifty other small tweaks. The idea of spending three or four hours doing this all over again made me want to quit for the day.
That's when it hit me - I'd been doing this completely wrong. Instead of manually reinstalling everything again, I decided to automate the whole thing. Even better, I'd keep my actual work separate from the VM, so no matter how badly I broke things, my data would always be safe. That night, I started writing Ansible playbooks to recreate my entire setup automatically.
The playbook handles the boring stuff first - timezone, French keyboard layout (with escape key swapped), and passwordless sudo. Then it installs the tools I actually use: Ghidra, GDB with pwntools and GEF, Binary Ninja, and more. I also added support for Go-based tools like nuclei and httpx, though I keep those turned off by default since I don't always need them.
But honestly, the real value isn't just installing tools. It's the custom scripts that automate all the repetitive stuff I used to do manually.
I built three simple tools that handle the boring parts of security work.
The first one is called lab. When I'm starting a new CTF challenge, I just type lab ctf, choose a category, and it creates all the folders I need. For HackTheBox or TryHackMe machines, lab box does the same thing. No more creating the same folders over and over or forgetting where I saved last week's work.
The second script is host-entry, which fixes a problem every CTF player knows well. It backs up my original hosts file, adds new entries in a clearly marked section, and makes cleanup easy when I'm done with a challenge.
The third script, create-structure, builds my entire workspace on a fresh install. Though I rarely need it anymore since my work directory stays separate from the VM.
Here's the smart part: this directory lives outside my VM. When I create a new machine, I just mount this folder, run my setup script, and everything's there - all my notes, scripts, and ongoing projects. The VM can break or be deleted anytime. My work is always safe.
Let me show you how this actually works in practice. I start a fresh Kali VM, download the repository, run make setup, and go make coffee. Ten minutes later, everything's ready - my terminal setup, all my tools, and my custom scripts.
A new HackTheBox machine comes out. I type lab box, enter the machine name, and I'm already in a properly organized directory with folders for recon, exploitation, and notes. I don't have to think about where to put things anymore.
I'm working on a CTF that needs a custom hosts entry. Instead of opening /etc/hosts and carefully editing it, I just run sudo host-entry add 10.10.10.10 deadcode.thm ctf.deadcode.thm. When the CTF ends, cleanup is simple: sudo host-entry clean.
When I'm done for the day, I shut down the VM. Tomorrow, if I need to rebuild or switch machines, I just mount my work directory again, run make setup, and I'm back to work in minutes.
The setup uses Ansible roles, where each role handles one specific thing. The system role manages basic configuration. The tools role installs packages. Nvim and tmux roles set up my development environment exactly how I like it. The dotfiles role manages all my configuration files.
This modular design means I can choose what I need. Running on a minimal cloud server? Skip the desktop environment. Only need core tools? Turn off the optional Go tooling.
It runs perfectly on Kali Linux - that's where I test everything. Parrot OS works too, though their package repositories can sometimes cause issues.
The main point here isn't just about automation. It's about knowing what you can throw away and what you need to keep.
Your VM setup? You can rebuild it anytime. Automate it. Your actual work - the recon notes, the exploit code you've been working on, the reports you're writing? That stuff needs to stick around.
When I accidentally destroyed /etc/passwd, I learned this the hard way. Now when a VM breaks or needs rebuilding, I'm back to work in the time it takes to make coffee. I mount the work directory, run make setup, and everything's exactly where I left it. Same tools, same config, same workflow, all my data intact.
This is what infrastructure as code should look like for security work.
The complete setup is on GitHub. Clone it, run make setup, and see if it helps your workflow like it helped mine. Even if you don't use my exact setup, the idea is worth trying: keep your environment disposable and your work safe.
That deleted /etc/passwd file ended up being one of the best mistakes I ever made. Sometimes you have to lose everything before you figure out the right way to protect it.
