Inline-Execute-PE

DISCLAIMER:

This project is complex and failure to understand how it works and adequately test it can result in you crashing Beacons and losing access!

I highly encourage you to read all of the documentation up until the "Design Considerations and Commentary" section!

Introduction

Inline-Execute-PE is a suite of Beacon Object Files (BOF's) and an accompanying Aggressor script for CobaltStrike that enables Operators to load unmanaged Windows executables into Beacon memory and execute them, retrieving the output and rendering it in the Beacon console.

This enables Operators to use many third party tools (Mimikatz, Dsquery, Sysinternals tools, etc) without needing to drop them to disk, reformat them to position independent code using a tool like Donut, or create a new process to run them.

These executables are mapped into Beacon memory so that they can be ran repeatedly without needing to send them over the network, allocate new memory, and create a new conhost.exe process each time.

Executables loaded into Beacons are accessible and able to be ran by all CobaltStrike Clients connected to the CobaltStrike Team Server.

Inline-Execute-PE was designed around x64 Beacons and x64 Windows C or C++ executables compiled using Mingw or Visual Studio. This project does not support x86 executables or x64 executables written in a different language or compiled using a different compiler.

Setup

Clone the repository and optionally run make in order to recompile the BOF's.

Load Inline-Execute-PE.cna into the CobaltStrike client. Ensure the directory that CobaltStrike is running from is writable by your user; Inline-Execute-PE creates a text file there (petable.txt) in order to ensure availability of the data required by Inline-Execute-PE to function.

Commands

Inline-Execute-PE comprises of 3 target-facing commands which run BOF's, and 3 internal commands that manipulate the project data-structure:

Target-facing:

1. peload
2. perun
3. peunload

Internal data-structure:

1. petable
2. peconfig
3. pebroadcast

peload

peload is the beginning of Inline-Execute-PE. This command is used to load a PE into Beacon memory. It performs the following major actions:

1. Sends the specified PE over the network to Beacon OR sends the name of the PE to read from disk on the target machine
2. Creates a structure in Beacon memory to hold various pointers and handles required by Inline-Execute-PE throughout it's lifecycle
3. Allocates memory in Beacon and writes PE to it with RW protection
4. XOR encrypts PE in memory using a user-specified key
5. Allocates another chunk of memory and copies the XOR encrypted PE to it. This is necessary in order to be able to "revert" the PE for subsequent executions
6. Spawns a conhost.exe child process under Beacon in order to initialize stdin/stdout/stderr
7. Redirects stdout and stderr to an anonymous pipe so that PE output may be captured

perun

perun is the second step in Inline-Execute-PE. It performs the following major actions:

1. Sends command line arguments over the network to Beacon
2. XOR decrypts PE in memory
3. Fixes the PE's Import Address Table, hooking certain API's related to command line arguments and exiting processes
4. Changes PE memory protection to RWX
5. Run's PE in it's own thread
6. Captures output from PE and returns it to CobaltStrike
7. Reverts PE memory protection to RW
8. Overwrites the PE in memory with the XOR'd copy that was made during peload

peunload

peunload is called to remove the PE from Beacon memory when an Operator is done with it or wishes to load a different PE. It performs the following major actions:

1. Closes handles and file pointers created during peload
2. Terminates the conhost.exe process created during peload
3. Zeroes out and then frees both copies of the PE in memory
4. Tries to unload any DLL's loaded by the PE into the Beacon process (optional)

petable

petable is used to display information regarding all PE's currently loaded into Beacons.

Each CobaltStrike Client has their own petable; Inline-Execute-PE goes to great lengths to ensure the synchronicity of its data between all connected CobaltStrike Clients so that PE's may be used by all Operators. For more on this, see "Design Considerations and Commentary".

peconfig

peconfig is used to configure options pertaining to how Inline-Execute-PE functions. The two current options that may be altered are:

1. Timeout. This dictates how long perun will wait for the PE to complete execution before terminating it. This exists as a safeguard in the event that incorrect arguments are given to a PE that cause it to never return/finish execution. This setting is 60 seconds by default but may be modified to accommodate longer-running PE's.
2. UnloadLibraries. This option controls whether peunload will try to free DLL's from the Beacon process that were loaded by the PE. This is set to TRUE by default. Some PE's cause issues when DLL's are unloaded from the Beacon process and can cause Beacon to crash, in which case it is better to leave all DLL's loaded by the PE in the Beacon process. This has been observed when using powershell.exe (perhaps due to it loading the .Net CLR into the Beacon process).

pebroadcast

pebroadcast can be used to manually broadcast the contents of a Client's petable to all other connected CobaltStrike Clients.

Every other CobaltStrike Client will update their petable with the data broadcasted. This shouldn't ever really be necessary, but the feature exists just in case.

Usage

Use peload to load a PE into Beacon memory

Alternatively, if there is a PE on the target machine you would like to use without creating a new process, provide the path and the --local switch

Call perun, passing any arguments to the loaded PE

Double quotes in arguments must be escaped using backslashes

If you have identified that a PE causes issues when trying to free DLL's during unload, use peconfig to set unloadlibraries to false

Once you are done using a PE, call peunload to clean it up from Beacon

A different PE now may be loaded into the Beacon

perun timeout

You must be careful about the command line arguments you pass to the PE; some PE's will crash outright if given wrong arguments, while others will run endlessly causing Beacon to never call back even though the process is still running.

This can be seen with Mimikatz.exe when 'exit' isn't specified at the end of the list of arguments

...