code16: Ansible - Quick Shot

I decided to create this small document to collect few basic ideas about Ansible and how it can be used during a ‘day-to-day’ scenarios for pentest and red team projects. If you’re already familiar with Ansible – this document more likely will be a small ‘cheat sheet’ if you’d like to use Ansible to perform some actions during the projects. Anyhow… Enjoy and have fun! ;) Here we go...

This time we'll start here:

Main Goal

Main goal of this small document was to learn and understand a bit more about Ansible[1] and how it can be used during a quick ‘pentests’ and/or red team scenarios. (The idea was to create something like a cheat sheet rather than a proper full ‘Ansible tutorial’.) Use each paragraph here as a ‘dot’ that will (or at least “should”) in the end ‘connect with other dots’ to create “some more interesting ideas…” ;)

Environment

Similar to the previous adventures already described on the blog[2] – to this exercise I used Ubuntu 20 VM started in VirtualBox. When your VM is ready to go – in a next step you should run those 2 commands to install Ansible:

# apt update
# apt install ansible -y

When apt will finish the installation we should be ready to continue.

Agent or Not (ssh-agent)

At this step – reading multiple online tutorials related to Ansible “for beginners”[3] - you’ll find the part for “configure your ssh-agent”. My goal was to avoid that solution so all examples presented below are not using this ‘opportunity’. (Below you’ll get the idea.

Intro to Ad Hoc

One of my favorite ‘Ansible-feature’ is the possibility of using something that works similar to the one-liners[4] – it’s called “Ad Hoc”[5]. Pretty useful if you want to run one command against (for example) a target host (or hosts; see below for more details). Again I strongly recommend to read the fantastic manual (you can start here[5]):

Example of this kind of (Ansible-)‘one-liner’ is presented below. We’ll try to connect to localhost as a specific (-u) user asking for the password first (-k option to “ask for password”). Using module[6] (-m) called shell we’ll run an example command (-a) “echo $PATH”:

More Ansible modules you can find here [6].

Let’s move forward.

Intro to Inventory

TL;DR - According to the documentation[7]:

“Ansible works against multiple managed nodes or “hosts” in your infrastructure at the same time, using a list or group of lists known as inventory. Once your inventory is defined, you use patterns to select the hosts or groups you want Ansible to run against.”

We’ll use an inventory file later [7, 8, 9].

Quick hint?

Jumping to the next dot...

“Quick-shot” Commands

According to the documentation[1] (and few previous words about the basics of my adventures with Ansible) now we’ll use an inventory file to perform some “basic tasks” against remote host(s). For my case I used only my “local lab/environment” but feel free to extend those tests/tasks to your own networks. Long story short: for now you can think about an inventory that this is our file “with target hosts/IP’s”. ;)

Ad-hoc connection to remote SSH

To connect[5] to my-remote-host I created a new_inventory_file contains few IP’s:

Next I decided to update the file and add few of the ‘Ansible variables’ (you can read more about them here[8]).

Updated file is presented below:

*(One of the reasons I did not “configure” the ssh-agent mentioned above. ;))

Moving forward…

Inventory connection to remote SSH

Connecting to remote SSH using ad-hoc and our created new_inventory_file is presented on the screen below:

At this stage [1, 5, 8] the output should be pretty obvious.

Jumping to another dot…

Intro to Collections

Again, according to the docs[9]:

“Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins.”

If we found a collection we can use for our pentest/redteam scenario(s) – we can install it using ansible-galaxy like it is presented in the docs[10]:

We’ll use that when we’ll later prepare a future scenarios. See this page[10] for more details[11]:

For now we’ll use a basic/default examples but – if needed in the future – we’ll install more to do a specific action. See below for more details…

Intro to Playbooks

“Documentation is the key” so again: following the friendly manuals[12]:

“Ansible Playbooks offer a repeatable, re-usable, simple configuration management (...). If you need to execute a task with Ansible more than once, write a playbook and put it under source control.”

Let’s see some basic example (grabbed somewhere online but modified a bit for our purposes). Very basic “playbook” below:

Let’s run this playbook with our new_inventory_file:

As you can see during this simple test we were able to run command on remote host(s) and get a response if needed. At this stage I strongly recommend to get back to [8] and read about variables and modules[6].

For now – we’re moving forward...

Ansible for Red Teams – Basic Scenarios

While I was reading more and more about Ansible and all the Modules[6] and Collections [10] I started wondering how it can be used to perform a “daily basis tasks” for pentests or red team projects. Few simple examples you’ll find below.

Simple portscan…

First of all – an easy way to use Ansible as a ‘portscanner’? Searching for an online-answers I found an example of a playbook (I modified a bit;) ):

(As you remember from [8] about the “state” variable… ;)) State if sshd on remote host(s) is closed:

Next test – let’s run sshd to see the difference(s) in the response:

State if sshd is started:

At this stage – preparing “more and more advanced examples of the scan” - I will leave to you as an exercise. ;) For example – let’s think about the parser for nmap’s output that is able to prepare an ansible-inventory-file for us… ;]

For now - moving to the next example case…

Example Spray with Ansible

Reading the docs we can easily see that there is an excellent opportunity to prepare a playbook and inventory-file to perform a ‘spraying attack’ [13].

For example let’s think about a linux-based-server-network where you can find hosts with enabled sshd. Let’s use Ansible to check if we are be able to access those hosts using default credentials, like “admin:admin” (or for our case: “tester:tester”).

I created a new inventory file with few IP’s (that I used in examples described before) and few of the “inventory variables” (you can read more about them on this page [7, 8]):

As you can see – this example is pretty similar to the “Intro to Inventory” part of this document – we talked above:

Let's move forward...

Reverse Shell with Ansible

Why we would use a ‘date’ or ‘pwd’ or ‘id’ command when we can use a reverse shell to spray the target network/hosts and graba shell on remote box?

Preparing msfconsole:

Preparing a playbook.yml:

Starting a new playbook with our new inventory file:

More details - below:

New run with new sessions – presented on the screen below:

New playbook - new session(s):

As we mentioned before – we can always use a ‘one liner’ during our spray-attack-scenario[4]:

(Un)Real Life Example: Juniper vs. Ansible

During few of my projects[2] one of the machine on the Client’s network was indeed a Juniper. I decided to check if there is a way to access this box using Ansible[14]. Below you’ll find few notes about it. To not spoil it too much for you - here we go[15]: