Search for a command to run...
Ansible automation for pentesting environments
I was testing commands in my VM one afternoon, running through some privilege escalation techniques, when I accidentally typed tee /etc/passwd followed by random garbage instead of the command I actually intended to run. The moment I hit enter, I knew something was wrong, and within seconds the system became completely unresponsive and unrecoverable. I hadn't lost any data—my notes and projects were still there somewhere on the disk—but the entire configuration was destroyed, and there was no way to boot the system or access anything without /etc/passwd intact.
As I stared at the fresh Kali installation screen for what felt like the hundredth time, I started mentally cataloging everything I'd need to reinstall and reconfigure: Ghidra with my custom settings, Neovim with all my plugins and keybindings, Tmux with my preferred layouts, my directory structure, my custom scripts, and dozens of other small tweaks that made the environment actually mine. The prospect of spending another three or four hours rebuilding everything from scratch was exhausting, and I realized I'd been approaching this problem entirely wrong.
That's when I decided to automate the entire configuration process and, more importantly, to separate my environment from my actual work so that no matter how badly I broke a VM, my data would always be safe and accessible. That night, instead of manually rebuilding everything, I started writing Ansible playbooks that could recreate my entire pentesting environment from a fresh install.
The playbook starts with the basics—setting up my timezone, configuring my French keyboard layout (with swapescape options) , and enabling passwordless sudo.
Then it moves on to the tools I actually use: Ghidra, GDB (with pwntools & GEF), Binary Ninja and so on. There's also support for Go-based security tools like nuclei, httpx, though I keep those disabled by default since I don't always need them.
But the real value isn't in the tool installation. It's in the workflow automation—the small scripts that save me countless hours of repetitive setup and configuration.
I built three custom tools that handle the repetitive parts of security work.
The first one, lab, manages my training workflow. When I'm tackling a new CTF challenge, I just run lab ctf, pick a category, and it creates a properly organized directory structure. For HackTheBox, TryHackMe or other machines, lab box does the same thing. No more wondering where I put that web challenge from last week or manually creating the same folders over and over.
The second script, host-entry, solves a problem every CTF player knows: managing /etc/hosts entries. It backs up my original hosts file, adds new CTF entries in a clearly marked section, and makes cleanup trivial when the challenge is over.
The third script, create-structure, builds out my entire workspace on a fresh install if i need it. (but i rarely do since my work directory is persistent).
work/
├── pentests/
│ ├── clients/
│ └── internal/
├── training/
│ ├── boxes/
│ ├── labs/
│ └── challenges/
├── tools/
│ ├── built/
│ ├── custom/
│ └── utils/
├── configs/
│ ├── vpn/
│ ├── ssh/
│ └── clipboard/
├── reports/
├── wordlists/
└── archive/
Here's the clever part: this directory structure lives outside my VM. When I spin up a new machine, I just mount this working directory, run my setup, and everything's back—all my notes, all my scripts, all my ongoing projects. The VM is disposable. My work isn't.
Here's how this actually plays out. I spin up a fresh Kali VM, download the repository, run make setup, and go make coffee. Ten minutes later, I return to a fully configured pentesting environment—my preferred terminal setup, all my tools installed, my custom scripts ready to go.
A new HackTheBox machine drops. I type lab box, enter the machine name, and I'm immediately in a properly structured directory with folders for reconnaissance, exploitation, and notes. The cognitive load of "where should I put this" is gone.
I'm working on a CTF challenge that needs a custom hosts entry. Instead of sudo vim /etc/hosts and carefully editing around existing entries, I run sudo host-entry add 10.10.10.10 deadcode.thm ctf.deadcode.thm. When the CTF ends, cleanup is just as 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 to a different machine, I just mount my work directory again, run make setup, and I'm back to where I left off in minutes.
The implementation uses Ansible roles, each handling a specific piece of the puzzle. The system role manages basic configuration. The tools role handles package installation. Nvim and tmux roles configure my development environment exactly how I like it. The dotfiles role manages all my configuration files.
This modular approach means I can pick what I need. Running on a minimal cloud instance? Skip the desktop environment roles. Need just the core tools? Disable the optional Go tooling.
The entire thing runs on Kali Linux without issues—that's where I do most of my testing. Parrot OS works too, though their repositories can be problematic.
The real insight here isn't about automation for automation's sake. It's about separating what's disposable from what's not.
Your VM configuration? Disposable. Automate it. Your actual work—the reconnaissance notes, the exploit code you've been refining, the reports you're writing? That needs to persist.
When I accidentally nuked /etc/passwd, I learned this lesson the hard way. Now when a VM breaks, corrupts, or needs rebuilding, I'm back to work in the time it takes to make coffee. Mount the work directory, run make setup, and I'm exactly where I left off. Same tools, same configs, same workflow, all my data intact.
This is what infrastructure as code should look like for security work.
The complete setup is available on GitHub. Clone it, run make setup, and see if it changes your workflow the way it changed mine. Even if you don't use my exact configuration, the approach is worth considering: keep your environment disposable and your work persistent.
That deleted /etc/passwd file turned out to be one of the best mistakes I ever made. Sometimes you need to lose everything before you figure out the right way to keep it.