Overlooked tools of the infosec trade: Packer

We spend a lot of time talking about the obvious infosec tools like fuzzers, VPNs, key loggers, and the “sexy” things. However, there are quite a few useful tools out there that can be used to maintain your lab, help your research, and help you get stuff done faster.


Packer by Hasicorp is for building machine images that you can deploy on most any cloud or virtualization platform (Digitalocean, AWS, Hyper-V, VMware, you name it). Why does this matter?

Instead of the tedious process of maintaining a fleet of golden images that quickly go out of date and can be hard to pack for a series of different environment or maintaining storage for a bunch of said images (which can get costly if they’re large or numerous), you simply use a packer script to build it shortly before you want to deploy it. Packer also allows you to build the same image suitable for a variety of virtualization environments. Have a packer script that you use for DO but want to use it in a VMware lab? Simple: Just change 2-3 lines and run it again.

Speed matters

Let’s say you don’t want to pay the money to keep an SSH proxy, SFTP, or some other service running full time. Or maybe it was a pain in the butt to configure. Or maybe you have already automated the configuration through the world’s most complex Cloud-init script ever, but don’t want to wait 30 minutes for it to deploy. You want it NOW! If you’re using a pre-baked image that you built with packer, your deployment and configuration time is only limited by how fast the platform and deploy a machine. For Digitalocean or Amazon, that’s under a minute.

Repeatability matters

I have bad news for you: You’re probably human. I’m sorry. And if you’re human, you make mistakes (very sorry). Even in a process you’ve done a hundred times before (very very sorry). Therefore, we do our best to do it right once and then automate the process thereafter.

Packer also allows us to use our favorite tools like Ansible, Puppet, Chef, or terrible shell scripts to build the machines. Complicated tasks get boiled down to a couple lines of code!

Sharing is caring

Have a packer build that you like? Have one that someone else wants? Put it in git, let them clone it down. Much easier than trying to share a VM image.

Your first packer build

We’re going to build our first Digitalocean image and rip instructions straight from Packer’s website to do it. One small difference: Their guide uses AWS. We’ll use DO instead.

I’m going to assume you can read instructions and figure out how to install it from their guide. If you’re on MacOS, it’s just brew install packer.

Now, let’s create a directory for our packer config. This can be within an existing project if you like. For example, you may have an application you want to deploy and frequently want to spin up virtual machines that are configured to use it. You can add a packer/ directory that builds your application in an image and spits something out that’s ready to use. Nifty, huh?

Before we write the config, it’s probably best to obtain your API creds. Log into DigitalOcean and get creds here: https://cloud.digitalocean.com/settings/api/tokens (or click your profile pic in top right > settings > API. Tokens is default pane). Stash those creds somewhere safe for a moment, we’ll need them soon.

Drop the following config in a file named something like my_super_awesome_packer_image.json:

  "builders": [{
	  "type": "digitalocean",
	  "api_token": "aaaabbbbccccdddd1111222233334444",
	  "image": "ubuntu-16-04-x64",
	  "region": "nyc2",
	  "size": "512mb",
	  "snapshot_name": "baseline-{{timestamp}}"

Let’s breakdown what we’re looking at. First, notice the whole thing is in JSON. Not much to explain there.

Next, notice that there are two top-level keys: builders and provisioners. Those two are the basis of the whole packer config: builders is an array of configs for each platform you want to build against. If you want to build the same config at the same time against AWS and DO, just add two builder fields after the builder key. The other is provisioners. Provisioners are what do the work of configuring the machine, and they run in order, first to last. You can use shell scripts, ansible, puppet, chef, or in-line shell commands. Notice here that I used a shell script.

Now run packer build my_super_awesome_packer_image.json (assuming you have a script in scripts/base.sh. If not, just remove that provisioner block) and let packer create the image for you!

From here, you can go do the DO control panel, select the “Images” and you’ll see your packer build available as a snapshot, ready to deploy.


What would this be useful for in a pentesting/hacking enviornment?

1 Like

You’re really only limited here by your creativity, but here are a couple of examples off the top of my head:

  1. Quick and disposable C2 infrastructure
  2. Reusable/sharable lab VMs (such as demonstrating an exploit)
  3. Creating a poisoned image and tricking someone into running it in their infra

This topic was automatically closed after 30 days. New replies are no longer allowed.

Reopened this to comment:

I am creating a pentest box in GCP with packer.

So I can run “hackbox now” and it’ll give me a pentest environment premade. This is going to be invaluable for pentests.


What advantage would this have over say docker?

Apologies for digging up this thread I saw it was reopened and I assumed it was less than 30 days ago.

1 Like

Packer is completely different.

Packer is for creating images on servers.

That is very good to know. I will have a deeper look into this.

Thanks fraq, I have been just cussing out having to keep on burning DVDs for my vm images
I will have to check packer out.


This topic was automatically closed after 3 days. New replies are no longer allowed.