Achieving Persistence

In the previous chapters, we have looked at examples of different ways to gain a reverse shell on the system, as well as tools such as Empire, which help us with things like privilege escalation. The next step is achieving and maintaining persistent access to systems. When performing a red-team exercise, there is occasionally a Blue team whose goal is to detect and prevent the attacks from being carried out by the red team. In these cases, persistence comes into play.

Persistence can be achieved in two major ways:

Disk persistence: This technique uses methods that end up writing files to the victim's physical drive. This is less recommended because when a file is written to the disk, there is a higher chance that an antivirus may flag it or the user may find it.
In-memory or fileless persistence: This technique utilizes ways of executing payloads in...

Technical requirements

Metasploit Framework (MSF)
PGSQL (Postgres)
Oracle Java 1.7 or above
Cobalt Strike
Empire
Armitage

Persistence via Armitage

We have already covered this in previous chapters, but in this section we will look at some of the Windows exploitation scripts that allow us to achieve persistence on the victim host. We can look for all available exploits by searching for the keyword persistence in Armitage, as shown in the following screenshot. We can see that there are different exploits available that allow us to achieve persistence. Some of these are as follows:

Cron_persistence: This module will work on a *nix-based system and create a cron job that executes our payload.
Registery_persistence: This module creates a payload that is run either when a user logs on or on system startup, through the registry value in CurrentVersion\Run (depending on privilege). This payload is completely installed in the registry.
Vss_persistence: This module creates a persistent payload in a new volume...

Persistence via Empire

Empire has a lot of inbuilt modules that allow us to use persistence on a system while performing a red team activity. These modules are divided into four main areas:

PowerBreach: This is a series of in-memory PowerShell backdoors that provide triggers for various options
userland: These are backdoors that execute on reboot without needing admin rights
elevated: These are backdoors that execute on reboot with admin rights
debugger triggers: These are backdoors that execute on a particular trigger (an example of this is sticky keys)

In this section, we will cover some of the modules for Linux, Windows, and macOS systems.

For Windows:

Assuming we have an agent connected on our empire from a Windows Machine:

To view a list of available persistence modules, we interact with agents using the interact <agent name> command.

Next, to view the available...

Persistence via Cobalt Strike

In Cobalt Strike, we can achieve persistence with the help of Aggressor Scripts. We have already learned about Aggressor Scripts in previous chapters.

Some of the Aggressor Scripts are already available on GitHub; we will use the following one:

https://github.com/harleyQu1nn/AggressorScripts/tree/master/Persistence

Here, we download the scripts on our system and import them into our Cobalt Strike client through the script manager, as shown in the following screenshot:

In the preceding screenshot, we loaded Persistence_Menu. This script creates a new entry in the Beacon menu with all the scripts we downloaded. These scripts can be accessed by right-clicking on the host | Red Team | Persistence, as shown in the following screenshot:

Let's look at the following example. Here, we will use HKCU Run Registry PowerShell Persistence (User Level)...

Summary

In this chapter, we learned about achieving persistence using Armitage's inbuilt exploit modules, then we learned how to do the same via Empire on Windows, Linux, and macOS machines. In the last section, we learned how to persist sessions in Cobalt Strike with the help of Aggressor Scripts.