The first thing that is needed when setting up Pacu is to ensure that Git, Python 3, and Pip 3 are installed. When that's done, you can follow a simple three-step process to get Pacu installed and running. From the CLI of your operating system (we are using Kali Linux), run the following commands:

git clone https://github.com/RhinoSecurityLabs/pacu.git 
cd pacu/ && bash install.sh 
python3 pacu.py 

Now Pacu should start up and go through the process of configuration and database creation. It should first tell you that it created a new settings.py file, followed by a message that it created a new local database file. Finally, it will ask you for a name for your new Pacu session. In this example, we named the session ExampleSession:

Now our new session is created; session within Pacu is essentially a way to isolate data, activity, and credentials between different projects that you are working on. Pacu uses a local SQLite database to manage sessions and the data within them, and it allows the creation of any number of sessions. As a pentester, sessions can be thought of as engagements or companies, in the sense that you can be working on two different AWS pentests at once, so you will need two Pacu sessions to separate the two. Each Pacu session will then hold all the data, activity, and credentials that belong to that specific engagement or company. This allows you to work with the same data across multiple different uses of Pacu, requiring fewer API calls to the AWS API, meaning you are that much more hidden in the logs.

The SQLAlchemy Python library is used to manage interaction between Pacu and the database, but we will jump into that later on.

The next thing you should see is a large output of help information from Pacu that explains the different commands and abilities that Pacu has enabled. We'll skip that for now and come back to it later.

After that, if you are running Kali Linux like we are, you should see a message that is similar to the following:

Just as we discussed in Chapter 16, GuardDuty, this message is shown because Pacu detects that it is running on a Kali Linux host. GuardDuty can detect when AWS API calls are made from a Kali Linux server, and flags an alert based on that, so Pacu automatically resolves this by modifying the user agent that is sent to the AWS servers. As a result, GuardDuty won't alert us immediately when we start attacking. This same check and solution process applies to Parrot and Pentoo Linux as well.

After that, you should land in the Pacu CLI, which looks like the following:

   Pacu (ExampleSession:No Keys Set) > 

This line is waiting for us to enter a command, and it is showing us that we are in the ExampleSession Pacu session, without any AWS keys set. For most of Pacu's functionality, a set of AWS keys is required, so we will go ahead and add some in with the set_keys Pacu command. While running this, we will be asked for the key alias, access key ID, secret access key, and session token of our AWS credentials. As we have previously discussed in the book, the session token field is optional, because only temporary AWS credentials use a session token. Regular IAM users only have an access key ID and secret access key, so in that case, you will leave the session token field empty. The key alias is an arbitrary name that we can assign to the set of access keys that we are adding in. It is for our (and Pacu's) reference only, so choose something that makes sense to you. The following screenshot shows the output and input provided when running the set_keys command to add our AWS access tokens in the Pacu database. In our example, we chose ExampleUser, because that is the username of the user that the keys were created for:

As you can see, we have named the set of keys as ExampleUser, which then replaced No Keys Set at the Pacu CLI prompt, which indicates that the ExampleUser key pair is our active set. The active set of keys is used for any authentication that Pacu makes with the AWS APIs. You can add additional sets of keys with the same set_keys command, but with a different key alias. If you specify an existing key alias when setting a pair of keys, it will overwrite any existing values under that key alias with what you input.

If we wanted to swap between key pairs while within Pacu, we can use the aptly named swap_keys Pacu command. This will allow us to choose from a list of key pairs we have set up within this Pacu session. Let's say that for this example we have ExampleUser and SecondExampleUser set up as key pairs within Pacu and we want to switch from ExampleUser to SecondExampleUser. All we will need to do is run the swap_keys command and select our desired key pair:

As you can see in the preceding screenshot, ExampleUser on the Pacu CLI changed to SecondExampleUser, which indicates that we have a new set of activated AWS keys.

Pacu is essentially set up and ready to go at this point, but there are a few more things that we can do to customize our session if we wish, but we will cover that in the next section as we pass by those commands.