Tools are an integral part of modern cyber security attacks and therefore also of red teaming engagements. The open-source community is both a blessing and a curse – it freely develops and shares tools that automate many painful manual steps, benefiting attackers and defenders alike, allowing attackers to use well-known tools like SharpHound. Naturally, defenders know and mark these tools as suspicious. Therefore, the tools themselves are usually blocked by modern AV/EDR systems. For an attacker to still be able to use them, obfuscation and evasion techniques come into play. This article shows how we automated this obfuscation and evasion process.

Introduction

This chapter will give an introduction into malware obfuscation and why it is relevant and necessary in today’s red teaming engagements. Additionally, it will briefly explain what obfuscation and evasion are, how it is done on a high level, and what led us to automate the obfuscation process. Throughout this article, the term malware is used broadly to include offensive security tools and frameworks commonly used in red team engagements.

Why Obfuscation (And Evasion) Matters in Red Team Engagements

As mentioned above, the use of known tools is necessary to automate manual labor, therefore keeping costs for clients to a minimum and still having a dedicated solution for each client. Manually developing custom tooling for every engagement is neither practical nor cost-effective, though it can be done if the situation requires it. The reuse of well-known open-source tools is therefore essential. Since the source code for most of these tools is publicly available, it is easy for defenders to recognise them and act upon detection. Responses can range from blocking to isolating the threat. Detection itself has evolved significantly – starting with Anti Virus (AV) systems and advancing towards the more modern Endpoint Detection and Response (EDR), which protects systems by applying a variety of detection techniques. For an attacker to still be able to use these known tools, the concept of evasion has to be applied. We previously published an article on evading anti virus software. While not a prerequisite, it serves as a valuable complement to this article.

What is Evasion and Obfuscation, and How To Do It

Evasion combines different techniques to prevent malware from being detected or blocked by security solutions. These techniques include, for example sandbox evasion, disabling different detection capabilities, but also obfuscation. Obfuscation describes techniques to change malware’s attributes in a way that they are no longer recognised by an AV/EDR system. These attribute-changes can lead to the malware changing its signatures, changing its behaviour or even modifying its own code dynamically. The obfuscation technique chosen is usually dependent on the security solution applied to the target environment and what detection techniques they depend on. An example for such obfuscations could include encrypting parts of the code and decrypting it during runtime, to change the control flow of the malware or to hash each function name and resolve calls at runtime using a lookup table. Since these techniques are more valuable if they are not known, the community tends not to overshare them. Still, there are great books, papers and articles covering EDR evasion. The following are recommended, without going into further depth here:

• MITRE ATT&CK Technique T1027
• Evasive Malware (Book Kyle Cucci, 2024)
• Evading EDR (Book Matt Hand, 2024)
• MalDevAcademy (online platform)

Painpoints of Manual Obfuscation

Manual obfuscation involves many iterative manual steps. To properly obfuscate and ensure the malware evades detection, especially in the case of widely used well-known open-source malware like SharpHound or Seatbelt, even obfuscated examples are likely recognised. This is because defenders signature not only the original tools but also their commonly obfuscated variants. Upon recognition, the next obfuscation method has to be tried. This is frustrating and time-consuming, especially during client projects with limited time budgets. Therefore, we aimed to automate this by introducing a malware obfuscation CI/CD pipeline, which will be explained in the following chapter.

Implementation

To create such a pipeline, several different requirements were defined to ensure the pipeline, especially in its initial stage, covers the most relevant use cases. The following requirements were established:

• The pipeline must support obfuscation of at least C#/.NET and PowerShell scripts
• The pipeline should follow a modular approach, to allow easy modification and addition of other types of programs, obfuscation and evasion methods and additional obfuscation scripts and tools as well as detection solutions
• Obfuscated malware must be validated against AV/EDR solutions
• Obfuscated malware that pass the AV/EDR validation are automatically pushed to the internal repository for deployment
• Obfuscation must be conducted on working copies, the original files should not be changed
• If possible, checks should be conducted to see if the obfuscation broke the malware
• The pipeline must log all activities to allow reconstruction of what was done per pipeline run
• Pipeline usage, setup and troubleshooting must be documented

Approach

Based on the established requirements, a minimal concept of the pipeline was first outlined. As mentioned it was decided to use a continuous integration and continuous delivery/deployment (CI/CD) pipeline. It is a software development practice that automates different stages such as build, test, and release of the development lifecycle. These pipelines originate from the DevOps movement. A more thorough explanation on CI/CD pipelines can be found at GeeksForGeeks. Based on the requirements and the concept, the architecture and tools were chosen for this pipeline, in addition to certain configuration decisions. Afterwards, a flow of the pipeline was established. The following subchapters will explain the results of these steps at a high level.

Concept

To apply the iterations of obfuscating malware to a pipeline, the iteration itself has to be deconstructed and split into single reproducible steps. Each of those steps needs to have a clear input and output. Additionally, each step should only focus on a specific task. This allows modularity, as a specific step is easier to adjust than an entire program. The overarching steps required are:

1. Deploy repository to an obfuscation machine
2. Copy malware to working directory
3. Obfuscate malware copies
4. Validate obfuscated malware
   1. If detected, redo obfuscation
   2. If not detected, push obfuscated malware to the internal repository

Pipeline Architecture, Tooling and Configuration

First, the overall tooling had to be chosen. As already explained, CI/CD was the preferred approach, with Gitea being the platform of choice. Gitea is an open-source alternative to GitHub, which integrates CI/CD functionality through their Gitea act runner. The act runner itself needs to be installed on a target system to deploy and interact with the software. Windows was chosen, since most of the malware used in red teaming engagements is targeted towards Windows systems. To build and transform the malware, the act runner can either deploy Docker containers or run directly on the host system. Direct deployment on the host was chosen, as Windows Docker container support proved unreliable in our setup. The act runner will need to be installed on the Windows system and registered on the Gitea instance.

Other tools include malware obfuscation tools like CodeCepticon or yetAnotherObfuscator as well as detection solutions like DefenderCheck, yara or THOR Lite. These must be installed on the Windows system and configured accordingly. Lastly, since DefenderCheck and other tools need the Windows Defender running to work, it is left enabled, though exceptions for the malware repository and transformation folders should be created. Additionally, the Automatic Sample Submission feature of Microsoft Defender needs to be disabled, as it risks rendering the sample immediately identifiable by Microsoft.

Pipeline Flow Overview

The following high-level pipeline flow was established:

It starts with the Gitea actions pipeline on the Gitea web interface. All steps the pipeline is taking are documented in the file .gitea/workflows/runner.yaml. This YAML file contains every step, where the steps should run, and secrets needed for pulling and pushing the file. The file in use will not be provided in this article. Manually triggering the pipeline was preferred over automatic scheduling for this implementation. During this manual start, a few optional parameters can be entered. Such parameters include the building architecture that should be chosen or if all malware files should be obfuscated.

First, it pulls the current repository containing the malware. Afterwards, it conducts a few availability checks to ensure that all needed programs such as the compiler, detection solutions and obfuscation tools are present. Then, it starts the first loop. The first loop is a dedicated step that checks whether each malware file compiles successfully and whether it is already flagged by the detection solutions. If compilation is required and fails, there are likely errors within the malware that should be addressed before obfuscation. Secondly, if the malware is not recognised, there is technically no need for obfuscation. This can be overruled by the parameter given to the pipeline. The entire process is repeated for all available malware files. All malware files in need of obfuscation get copied into an obfuscate directory. Afterwards, it checks for suitability for obfuscation of the malware. There are some known errors with some malware. Therefore, these cases should be detected and the affected malware removed from the queue.

Next, it will start another loop that will attempt the obfuscation and validation. Running both in the same step avoids the overhead of inter-step communication. If no specific parameters were set when starting the pipeline, the loop starts with the first malware file located in the obfuscate directory. It will obfuscate it with the first technique and test it directly against the detection solutions. The technique in use is represented by the counter j. The obfuscation round is represented by the counter i. Since an obfuscation technique does not always produce the same output, it can be worth repeating the same technique on a fresh copy of the file. This approach was suggested by Pavel Tsakalidis during his Talk about CodeCepticon. The same obfuscation technique is repeated up to five times. Afterwards, a different technique is applied, j is increased and i is reset to one. If five techniques fail, the pipeline marks the malware as failed and moves on. If the obfuscation worked, the pipeline copies the obfuscated malware along with supporting files such as a mapping file for function names to the Gitea repo folder. As soon as all malware has been handled, the Gitea repo is pushed and cleanup tasks are run to prepare the system for the next run.

Pitfalls

It is important to note that this pipeline has its limitations and flaws. There are two main pitfalls with such a pipeline; broken code and post-obfuscation detection.

The larger concern is that the malware code is broken after the obfuscation and can therefore not be used. Additionally, it is not possible to verify that every obfuscated malware is working as it is intended to, as certain malware requires specific prerequisites to function, such as an Active Directory forest. Furthermore, test cases for each malware file would be highly specific and require updating with each update of the malware.

The smaller concern is the detection of the malware even after obfuscation. This can happen very frequently and is also the reason why validation was introduced to the pipeline flow. Even after successfully evading detection during validation, an obfuscated malware can be detected due to a variety of reasons, for example by an EDR system that has more context or by a manual investigation and through the addition of new signatures. This is straightforward to address, as the pipeline can simply be re-run to generate a new obfuscated variant.

An alternative approach , based on Azure DevOps, was documented by Chester Adams.

Conclusion

The pipeline is established and has significantly reduced the manual effort required from our testers, though it still requires manual checking, tweaking, modification and error fixing from time to time, particularly with complex or highly targeted malware. With time and experience, this will further improve. It is planned to extend the pipeline with more obfuscation techniques and tools, more granular obfuscation options to address specific payloads, a sandboxing integration as well as other detection solutions, code signing, layered obfuscation, and support of other operating systems or architectures.

Through the implementation of red and purple team projects, we have been able to demonstrably increase our clients’ resilience against targeted and sophisticated cyberattacks. This is partly due to the establishment of the obfuscation pipeline described in this article.

About the Author

Yann Santschi completed an apprenticeship as a systems engineer at the Swiss Stock Exchange and then worked as a cyber security consultant at one of the Big Four consulting firms. He is currently pursuing his Bachelor’s degree in Information and Cyber Security with a major in Attack Specialist and Penetration Testing at HSLU. His focus is on web applications, network security, and social engineering.

Links

• https://about.gitea.com/
• https://attack.mitre.org/techniques/T1027/
• https://blog.xpnsec.com/building-modifying-packing-devops/
• https://docs.gitea.com/usage/actions/act-runner
• https://github.com/0xb11a1/yetAnotherObfuscator
• https://github.com/GhostPack/Seatbelt
• https://github.com/SpecterOps/SharpHound
• https://github.com/matterpreter/DefenderCheck
• https://github.com/sadreck/Codecepticon
• https://maldevacademy.com/
• https://nostarch.com/evading-edr
• https://nostarch.com/evasive-malware
• https://virustotal.github.io/yara/
• https://www.geeksforgeeks.org/devops/what-is-ci-cd/
• https://www.nextron-systems.com/thor-lite/
• https://www.scip.ch/?labs.20230413
• https://www.youtube.com/watch?v=zIeBD4GsnFg