This is a Cobalt StrikeBOF file, meant to use two or three arguments (path to DLL, and/or a third argument [all | fancy])
If a third argument is supplied:
all extracts the values, and creates a string representation of a valid .DEF file for the provided DLL
fancy uses the work of @anthemtotheego) to create an NTFS transaction to provide a memory-residing copy of the corresponding data, which is then synchronized to your Cobalt Strike downloads view.
What problem are you trying to solve?
During recent conversations with colleagues in regard to DLL-based attacks; sideloading, proxying, insert-vector-here, it came to my attention that there are certain instances in which having the exact path to the trueDLL to offload requests was necessary.
I wanted to support both 32-bit AND 64-bit executable images.
I wanted the Base to be represented properly, as not all ordinal base values begin at 1. I wanted the values to be accurate.
I wanted an operator to understand how many functions in total are exported from a given executable, so they can make a better determination of whether to download a copy, send the output of this application to the Beacon console, or download an "in memory" variant of the contents.
How do I build this?
In this case, you have two options:
Use the existing, compiled object file, located in the dist directory (AKA proceed to major step two)
Compile from source via the Makefile
cd src
make clean
make
Load the Aggressor file, in the Script Manager, located in the dist directory
How do I use this?
From a given Beacon:
Any known downsides?
We're still using the Win32 API and Dynamic Function Resolution. This is for you to determine as far as "risk".
You may attempt to incur a privileged action without sufficient requisite permissions. I can't keep you from burning your hand.
There are absolutely bugs in this code; these may or may not come down in the future. I wrote this as a PoC. JohnLaTwC is my hero.