RedTeamNotes started as a mini project to try and make a better note taking application than what was currently available. The big issue for me with apps such as Obsidian or OneNote was that whilst they have great note taking capability, they struggle to show how different notes relate to each other – unless you follow every link and manually piece it together.
Whilst doing CRTO, I often found myself in a position where I was trying to achieve an objective but would struggle to remember all of the various ways of achieving this. For example, to move laterally, I would likely remember that I could:
Dump LSASS to obtain AES256 keys
Obtain the plaintext password and perform overpass-the-hash
Use Rubeus to monitor for TGTs using the /monitor command
But would I remember that I could also use the following?
NTLM Relaying, if I have control of an device with unconstrained delegation
ADCS to obtain a certificate, then leverage THEFT5
And several other options..
Dun Dun Dun
So I decided to build my own note taking application – RedTeamNotes!
I had a few aims for this tool:
It should be possible to reuse the notes in other applications.
i.e. Use JSON
Try to avoid dependencies on too many tools just to build the application
I don’t want to have to download Node and 100 dependencies if I want to play around in HackTheBox
The relationships between notes should be very clear
With a few known limitations:
The tool wont handle editing the notes or relationships
The notes will be intentionally quite brief and will mainly signpost other resources
After many changes, I ended up choosing a few great JavaScript libraries to help me out. The graphing UI is handled by Drawflow. Positioning the various nodes turned out to be one of the hardest parts of the project, as it is very easy to know what the correct graph looks like, but it is very hard to actually implement in an automated way from my experience! Luckily I found Dagre’s GraphLib, which I believe uses the ‘Dagre’ algorithm to sort the nodes, but this might well be wrong!
Aside from these two libraries, the rest was blood, sweat, tears and swearing at CSS selectors.
On the right, we can view information on our selected technique, which currently supports:
Description
OPSEC considerations
Links
Code examples
Defensive guidance
This data would be represented with the following JSON:
"constrained_delegation" : {
"name": "Constrained Delegation",
"description": "Constrained delegation is a feature of AD which allows a service to act on behalf of another user to specific other services. If we can compromise a service with constrained delegation enabled, we can potentially steal cached TGTs",
"opsec" : ["Make sure the msdspn value (If using Rubeus) is a valid SPN which we can delegate to, only specific SPNs will be allowed."],
"code_examples": [
{
"description" : "Find machines with uncontrained delegation enabled via BloodHound",
"code" : "MATCH (c:Computer), (t:Computer), p=((c)-[:AllowedToDelegate]->(t)) RETURN p"
},
{
"description" : "Find machines with constrained delegation enabled via LDAP",
"code" : "(&(objectCategory=computer)(msds-allowedtodelegateto=*))"
},
{
"description" : "Find SPNs we can delegate to via PowerView",
"code" : "Get-DomainComputer -Identity PC_NAME | Select-Object -Expandproperty msds-allowedtodelegateto"
}
],
"links" : ["https://www.guidepointsecurity.com/blog/delegating-like-a-boss-abusing-kerberos-delegation-in-active-directory/"]
}
Using our earlier example of pass-the-ticket, we can see how this is represented below. Notice the 6 lines leading into the left of ‘Pass The Ticket’, showing 6 techniques which could get us to that position.
I decided to make a node for some of the ‘tactics’ (As MITRE ATT&CK would refer to them), which helps Dagre to better position the nodes. This has the added benefit of being able to help me perform a pseudo-checklist when I am stuck on a machine.
For example, below are a set of the privilege escalation techniques I have currently added into the tool:
The tool also can handle quite a lot of nodes. Especially considering that the relationships are quite complex, there is no caching, and it is not a super-efficient algorithm!
Searching
The tool has a search bar which will query the title and description of all the nodes on the current page, which is performed using FuzzySort. For example, lets look for techniques related to ‘tgt’:
We can then click on the top item “Dump TGT’s” and be taken to the relevant node
We can also switch between multiple datasets. For now, I currently have 3 datasets within my notes:
With code samples, we can click on the clipboard emoji, and the example text will be copied to the clipboard.
Hopefully this serves as some inspiration as to what can be done to make note-taking a bit more user-friendly and usable. I’m hoping to develop this idea into a few other directions in the coming weeks and months, as I think this style of program could be useful for a few other applications!
The inspiration for this post came from the excellent talk by Harmj0y at SO-CON 2020. I have been meaning to dig into using Jenkins to automate the building of red team tooling for some while now, but having recently completed the RTO exam, I felt it was time to have a play!
Before starting this mini project, my aim was to build a reasonably simple CI pipeline to:
Get the latest version of Rubeus
Perform some obfuscation
Compile it.
Have a less detectable Rubeus executable
With an aim to be able to take this code and re-use it on various other projects/repos as we wish, so modularity is a key aim here.
There are a fair amount of similarities between this post and the OffensivePipeline project, but I wanted to expand my knowledge within Jenkins rather than using C#, which I am already pretty comfortable with. I also feel Jenkins is likely to offer more flexibility in the future as I expand this project further.
An important caveat before we begin, I realise this guide only touches on some very basic obfuscation. The resulting binary will still be easily detectable, but this guide should highlight some of the basics!
Initial Jenkins Configuration
There are plenty of guides out there for installing Jenkins, so I wont labour the point here. A blog post from XenoSCR helped me at the start to install and configure Jenkins, as well as setting up a basic pipeline.
As stated earlier I wanted to be able to compile the projects within Jenkins, so naturally MSBuild was going to be the main candidate to do this. As usual, StackOverflow contains a guide on how to setup MSBuild in Jenkins, which I will cover below.
First, lets go to Manage Jenkins -> Plugin Manager. I didn’t have an MSBuild entry in my Global Tool Configuration page, so I had to go and install it from the Plugin Manager
When this has downloaded, we will add our configuration by going to Manage Jenkins -> Global Tool Configuration and scrolling down to the MSBuild section.
Click on ‘Add MSBuild’ and fill in the details for the path to MSBuild. Ensure you use the path to MSBuild for your installation of Visual Studio, I originally set it to the path for v4.0.3019 but I had a lot of issues with it failing to compile the project correctly.
Jenkins Pipeline
As described by Will in his talk, we will use ‘Pipelines’ to perform this compilation. From the Jenkins Dashboard we can click on New Item, and then select ‘Pipeline’.
For a basic project, lets use the code sample below. This will download Rubeus from GitHub and then show the contents of the folder.
Click on Save, and then on Build Now. We can then click on ‘Console Output’ to show us what Jenkins is doing. This should reveal the information below, which will show us the root directory of our Rubeus directory – proving we can clone the repository via code!
Now we can prove that we can actually run a job and it will execute code, lets try to automate a bit more of this. We currently are pulling the repo and running dir, lets try to actually compile this code into an executable.
Compiling Rubeus
Thanks to us configuring MSBuild earlier, we can now refer to it from within our pipeline – no need to mess around with remembering the path all of the time!
First off, MSBuild has a *fairly* complex command line structure, so I first got this working in the command line before porting it across to Jenkins. This isnt helped by Rubeus using .NET v4.0 which is no longer officially supported by Microsoft, so I was unable to find a legit download of the binary. Due to this, I used .NET v4.8 which isnt the best option for us in terms of compatibility, but we can always change that down the road!
After a lot of trial and error with MSBuild and the various command line options, my final command was:
Lets now change our jenkinsfile up so that it will compile the tool using MSBuild. We will wrap that earlier MSBuild command in a new stage to help keep our project nice and modular:
I also added in a temporary stage to print out the contents of the Rubeus\bin\Release folder. This helped me test that it had actually compiled the executable and saved me a few clicks as I debugged the pipeline.
With these additions, our jenkinsfile now looks like the code below. You can see I have added some more environment variables, which will help me to reuse this code for other repositories.
We can assess our progress by uploading our binary to VirusTotal. Whilst I wouldnt do this on a live test, it is handy for assessing how well this pipeline works. We will test this again at the end of this post, but for now our binary is only detected by 41 vendors – even though it is totally unobfuscated.
Jenkins Shared Libraries
We now have a good base to build from, as we can pull the latest version of Rubeus and compile it just from a click of a button! Our aim now is to remove some well known strings from the Rubeus executable. This will be the first baby steps towards us obfuscating our executable file.
To do this, we will use Shared Libraries to bundle up samples of code which we will reuse. For example, this will be stuff such as changing the default GUIDs, removing comments and so on. Conceptually, this is very similar to using functions when programming.
First off, we will create a shared library by creating a folder structure as shown below. I based my library on this blog post.
def call(String name = 'User') {
echo "Welcome, ${name}."
}
Annoyingly, we can’t include a local path to a Shared Library in Jenkins, as it expects us to load it from Git. There is a nice hacky workaround where we can load a local Git repository using the file:// protocol handler, as described here.
To prep my library for this, I created a new git repository and committed my code to it. You have to remember to commit your code after every change to your library!
We will then go to Manage Jenkins -> Configure System -> Global Pipeline Libraries, and add our library in.
We can choose a name here, I will go for obfuscation-lib, and then we set the project repository to point at the location of our newly created git repository.
Back in our pipeline’s jenkinsfile, we now have to import this library using the name we just set (At the top of the above photo). We import it with the following code:
@Libary('LIBRARY_NAME')_
Don’t forget the underscore after the bracket, else it wont work!
To summarise, with our shiny new library, this gives us the following very basic pipeline below. Whilst you don’t have to use variables in our function call, I wanted to ensure it would work.
Putting this altogether, lets use our obfuscation-lib library to obfuscate something useful within our target repository. To do this, we will build a pretty basic string replacement function. We will use this to replace any phrases which are known to set off EDR/AV alerts. A basic example would be replacing any mention of ‘mimikatz’.
Firstly, lets get the path to the Jenkins workspace. Ideally we will do this without having to manually specify it for each function call. Luckily we can use ${WORKSPACE} within our shared library to get this path. We can now update our library and it will print the directory out.
def call(String name = 'User') {
echo "Welcome, ${name}. Workspace is ${WORKSPACE}"
}
Commit our changes and re-run the pipeline, and we get the following:
From here, we will use some code from this post to create a simple find and replace tool.
//Heavily adapted from http://www.ensode.net/roller/dheffelfinger/entry/groovy_script_to_find_and
def call(String extension = '*.cs', String findText = '', String replaceText = '') {
//Navigate to the current workspace
def currentDir = new File("${WORKSPACE}");
def backupFile;
def fileText;
currentDir.eachFileRecurse({
file ->
for (ext in exts){
if (file.name.endsWith(extension)) {
fileText = file.text;
backupFile = new File(file.path + ".bak");
backupFile.write(fileText);
fileText = fileText.replaceAll(findText, replaceText)
file.write(fileText);
}
}
})
}
We will now add another stage into the pipeline, called “Obfuscate“. We will attempt to obfuscate the version number to demonstrate our function works. Also I will modify the “Echo Post Compilation” step to instead run Rubeus so we can check if the version number changed or not. This leaves us with these two new stages below.
stage('Obfuscate') {
steps {
replaceAll(".cs", "v2.0.2", "NO_SIGNATURES_PLZ")
}
}
stage('Execute Post Compilation') {
steps {
bat """C:\\ProgramData\\Jenkins\\.jenkins\\workspace\\MSBuildTest\\${env.PROJECT_NAME}\\bin\\${CONFIG}\\Rubeus.exe"""
}
}
After running this, it with an error relating to “expected to call java.io.File.eachFileRecurse but wound up catching org.jenkinsci.plugins.workflow.cps.CpsClosure2.call error“. This is explained here, but basically we need to add @NonCPS to the top of our custom function.
//Heavily adapted from from http://www.ensode.net/roller/dheffelfinger/entry/groovy_script_to_find_and
@NonCPS
def call(String extension = '.cs', String findText = '', String replaceText = '') {
//Navigate to the current workspace
def currentDir = new File("${WORKSPACE}");
def fileText;
currentDir.eachFileRecurse({
file ->
if (file.name.endsWith(extension)) {
fileText = file.text;
fileText = fileText.replaceAll(findText, replaceText)
file.write(fileText);
}
})
}
Now when we run our pipeline, we can see that we have modified the version number which Rubeus puts out to the console:
Extending Our Custom Function (Again)
We can further extend this function to create a basic function which performs some common OPSEC considerations for a C# projects. There is a lot of different checks which could be built in here, but we will focus on two main ones just to prove the point:
Change the GUID of the binary
Remove assembly information
Changing the GUID
As we can see from the AssemblyInfo.cs file, Rubeus uses a GUID of 658c8b7f-3664-4a95-9572-a3e5871dfc06.
This will tip off any analyst that we are using Rubeus, as we can see from Googling the GUID:
We will first use a regex to escape this. I found https://www.freeformatter.com/java-regex-tester.html a great resource when developing these Java regexes, and it saves re-running the pipeline over and over again! To save you from having to write Java regex, below is my code:
After committing our changes and running the pipeline, we can see that the AssemblyInfo.cs file has been modified, and we have a new GUID.
We can then extend our function to clear all the assembly values, only leaving a version number. This follows a very similar pattern to the function above:
@NonCPS
def call() {
//Replace the default GUID & assembly info
sanitiseAssemblyInfo();
}
@NonCPS
def sanitiseAssemblyInfo(){
def assemblyInfoFile = new File("${WORKSPACE}\\${PROJECT_NAME}\\Properties\\AssemblyInfo.cs");
def assemblyInfoText = assemblyInfoFile.text;
//Replace the default GUID (e.g. "[assembly: Guid("658c8b7f-3664-4a95-9572-a3e5871dfc06")]")
def newGUID = "[assembly: Guid(\"${UUID.randomUUID().toString()}\")]"
assemblyInfoText = assemblyInfoText.replaceAll(/\[assembly:\sGuid.*/, newGUID)
//Replace any entry beginning with "[assembly: Assembly", removing the value within the brackets.
//I.e. [assembly: AssemblyTitle("Rubeus")] ==> [assembly: AssemblyTitle("")]
//See https://stackoverflow.com/a/38296697 for more info
assemblyInfoText = assemblyInfoText.replaceAll(/(\[assembly:\sAssembly.*\(\").*/, '$1\")]')
//Finally, we will set the AssemblyVersion value to be 1.0.0.0 just to make it look a bit more legit
assemblyInfoText = assemblyInfoText.replaceAll(/\[assembly:\sAssemblyVersion.*/, "[assembly: AssemblyVersion(\"1.0.0.0\")]")
//And write it all to the file :)
assemblyInfoFile.write(assemblyInfoText);
}
Now if we view the AssemblyInfo.cs file, we can see that the assembly information has been stripped out successfully.
Putting this all together, we have our final jenkinsfile:
In addition to these functions, I then added another find and replace to remove the default help text for Rubeus. After compiling this project, we can now see that only 32 vendors detect the code – meaning we have defeated 9 of them!
What Next?
From this point, there is a lot of different ways which you could take this project. Harmj0y touches on a few within his talk, but some of the easier items I have implemented are:
Changing The Namespace
The Rubeus namespace is very well known, so changing this was one of my first priorities.
This is easily visible within the project:
Removal Of ‘Bad’ Functions
Using our offensive-lib library, I created a new function to remove any functions which are known to be easily detectable. As mentioned before, I used this to remove the default help text functions “ShowLogo” and “ShowUsage” in Rubeus.
For now, I have opted to just replace the function with a single new line, though this could be replaced with C# code, should we need to preserve functionality.
Implementing Automatic AMSI Checking
By using the ThreatCheck project by RastaMouse, we can have our pipeline automatically check itself against AMSI signatures. We will just run the check and manually review the output, but for production use we would likely implement this as a test – so that any code detected by AMSI is not compiled for use.
Slack Intergration
Instead of having to review the output of our builds, we can instead use a plugin and Slack WebHooks to get the data sent straight to us!
Summary
This is just the first baby steps into using Jenkins for OffSecOps, but hopefully it shows the potential use of a system such as this.
Some of the next steps I have planned include implementing more GitHub projects, as well as running multiple pipelines to automatically build my red teaming toolset.