Obfuscating Payloads
the fun part 😊
Last updated
Was this helpful?
the fun part 😊
Last updated
Was this helpful?
Now that we have a successful workflow, we can start messing around with removing Indicators of Compromise (IOCs) and obfuscating our payloads with a variety of methods. We will re-use our Seatbelt example from the previous section
Create a build step to check for Indicators of Compromise (IOC)
Use Powershell to remove the IOC from our project
Obfuscate our payload using ConfuserEx
Check the payload against ThreatCheck
Obfuscate Go Binaries
Periodic Scanning with VirusTotal*
We will be using Ligolo-ng and Seatbelt
Before we begin, we will need to install some tools that will detect our payload - which we can later use within our build steps to pass or fail the project before publishing an artifact.
YARA is a file analysis tool which dissects and searches for bad characters based on a set of rules. Rules can be downloaded from many sources - for our demo, we have included the rules that we will be using.
Test the rule against a Seatbelt artifact:
To install it, clone the repository to your directory of choice, compile it using Visual Studio 2019 or through dotnet.exe - I will be using VS 2019 for this
Open the solution in Visual Studio, then select Release and build
Once built, you will find the binary in the bin folder
C:\Tools\ThreatCheck\ThreatCheck\bin\Release
In order for ThreatCheck to work properly, we need to disable Windows Defender on our system so that the data isn't being deleted during analysis
Now that we know how basic detections can screw up our payload, let us see how we can bypass them. The first step is removing the hard-coded GUID string in Seatbelt\Properties\AssemblyInfo.cs (The same applies for Rubeus and the rest)
Then move the build step above the compilation step using the Reorder Build Steps option
Now, we need to add a parameter to our builder which includes the TeamCity project name using %system.teamcity.projectName%
Save this, then build the project. Check the file using YARA afterwards - you should see from the build logs that our GUID changed from aec32155-d589-4150-8fe7-2900df4554c8 to a9d35d54-019f-45dd-839d-6243648dcac6
We can confirm this change using YARA
...and dnSpy
ConfuserEx templates are written in XML , and can be referenced at:
A basic template which uses an aggressive preset can be written as follows
The project element describes where the file will reside after ConfuserEx runs. The rule element refers to which rules it should use, packer specifies what type of packer ConfuserEx should utilise, and module is for the target path. ConfuserEx lets you specify multiple rules and modules, and can cover both DLLs and binary files alike - which can be useful for DLL type payloads.
safe: ConfuserEx would detect debugger/profiler using managed API (default)
win32: ConfuserEx would detect debugger/profiler using unmanaged WinAPI (Incompatible with OS other than Windows)
In XML form, it will look like this
This allows us to beef up some of our default rules when it comes to templates and automating the obfuscation process
Before creating our pipeline, let's first use the GUI tool to examine the before and after of our Seatbelt executable. This will help us understand what to expect once a build has been completed. We will also testing our executable against ThreatCheck to confirm that it worked
Start the ConfuserEx application located in C:\Tools\ConfuserEx\ConfuserEx.exe (the directory you've extracted to), and create a new folder within the Tools directory where you will store the output - I've included our payload from the previous build inside of our output folder for comparison
Drag and drop your binary into the modules tab, then click on Settings. You should be able to see your binary's name displayed in the list. Click on this, then press the plus button to add a rule. Click on the packer check box as well.
Press the Edit button on the left to bring up the rules you want to use - for this, we will be using the basic Aggressive preset - experiment on your own to see what works well for you
Click Done once you're happy with the settings, then go to the Protect tab on the main interface and hit Protect to start packing your binary. Once it's complete, run ThreatCheck on your test binary, and the one you've packed to see the difference
You can decrease the detected bytes through other means as well - such as running the executable through a loader, or by using more protections/rules through ConfuserEx.
Instead of doing this manually, we can integrate ConfuserEx's template into our build pipeline with the use of a PowerShell script. Create the following scripts inside the C:\Tools\ConfuserEx directory, and save it as aggressive_template.ps1
Where:
$path is where the release directory is
$projectName is the project name
These variables will be used in TeamCity as such:
Create a new build step for ConfuserEx using the PowerShell runner
Specify the script file and the arguments TeamCity should execute
Run the build step, then verify that it worked by using dnSpy
The last step (for now) is to check the artifact against ThreatCheck to make sure that it's properly obfuscated. To do this, we will create a new PowerShell script with the following:
Then, repeat the previous execution arguments for TeamCity
To test our build step we will run our program twice - once with our ConfuserEx step, and once without.
We can see that there is a fixed message when a bad segment is detected by Threat Check, we can use this to create a filter which fails our build in case the program is not obfuscated
In your build's Failure Conditions, add a new failure condition to match the message received - you can also add other messages if ThreatCheck has other failure messages
Text to look for: [!] Identified end of bad bytes at offset
Test this on our last build step to see if it works
We can also test this by re-running our build
Re-enable your obfuscation step and you're done! The next steps would be to
Publish artifacts to central file share
Copy your build step into a global configuration
Check artifact hashes against VirusTotal (Using their API) daily to make sure the binaries aren't burned
Create a tool to download your artifact onto your operations machine or into your Command and Control team server
Your own creativity :)
- Use this instead since it's newer
Download the binary from the link above, then place it in a reachable directory. I will store all of the tools we're using in C:\Tools to keep things organised. After extracting YARA, download the rules from and place them inside YARA's root folder. It should look like this
We can see that YARA found the which is included in Seatbelt's original project - we will need to remove this IOC if we want to be slightly stealthier.
is a tool developed by Daniel Duggan (RastaMouse) which cuts up binaries and detect the exact bytes which AV solutions hate. We can use this tool to detect if anything needs to be patched post obfuscation
In our Seatbelt build configuration, add a new build step and select Powershell, we will use a small script to generate a random GUID, then replace the old one with it (Slightly modified from )
The Powershell template being used can be re-used for the other projects. This method is not sufficient to not get detected by ThreatCheck - though our next method will
is a .NET obfuscation tool which hides symbols and makes it difficult to understand what a C# executable does statically. To get started, download the latest binary (ConfuserEx.zip) from the Release page, and save it in your Tools folder (Mine is in C:\Tools)
You can also add more protections listed in the
Some protections take additional parameters as well, such as the anti debug protection which takes 3 arguments (taken from )
antinet: ConfuserEx would detect debugger/profiler using by @0xd4d
